Sichere KI-Softwareentwicklung: Von Threat Modeling bis Release

Das Wichtigste in Kürze: Sichere KI-Softwareentwicklung: KI-spezifische Bedrohungen, Datenflussmodellierung, Schutz von Prompts und Tools, Tests und Betrieb, mit Checkliste.

Ein Chatbot, der Angebote per Function-Call verschickt. Ein internes Tool, das Dokumente aus einer Wissensdatenbank zusammenfasst. Eine Code-Assistenz, die Pakete vorschlägt und automatisch installiert.

Jede dieser KI-Funktionen bringt neue Datenflüsse mit sich. Und neue Wege, wie sie ausgenutzt werden können. Sichere KI-Softwareentwicklung heißt nicht, klassische IT-Sicherheit zu ersetzen. Sie erweitert sie um Bedrohungen, die es ohne generative Modelle so nicht gibt.

Dieser Artikel richtet sich an Geschäftsführung, Operations, IT und Fachbereiche in KMU. Sie bauen KI-Funktionen in eigene Software oder interne Tools ein. Das kann selbst entwickelt sein, mit No-Code-Werkzeugen zusammengesteckt oder extern beauftragt. Der Artikel ordnet die relevanten Bedrohungen entlang des Entwicklungs- und Betriebszyklus ein. Er zeigt ein praktisches Vorgehen für Threat Modeling. Zudem benennt er, was vor einem Release geprüft werden sollte.

Begriffe kurz geklärt

Dieser Abschnitt klärt 4 Begriffe. Threat Modeling ist eine strukturierte Frage. Welche Daten fließen wohin? Wer könnte sie manipulieren oder abgreifen? Was würde das kosten?

Es ist kein einmaliges Dokument, sondern eine Übung. Man wiederholt sie bei jeder neuen KI-Funktion.

Prompt Injection bezeichnet Eingaben, die ein Sprachmodell manipulieren, sodass es vorgegebene Anweisungen ignoriert und stattdessen den Willen der angreifenden Person ausführt. Bei direkter Prompt Injection formuliert die angreifende Person die Eingabe selbst. Bei indirekter Prompt Injection steckt die Anweisung in einem verarbeiteten Inhalt. Das kann eine Webseite sein, ein Dokument oder eine E-Mail, die zusammengefasst werden soll.

Poisoning meint die gezielte Manipulation von Trainings- oder Wissensdaten. Ein Modell soll dadurch bei Auslösern fehlerhaft reagieren. Beispiele: eine eingeschleuste Backdoor. Oder ein manipulierter Eintrag in einer RAG-Wissensdatenbank (Retrieval-Augmented Generation).

Privacy Attacks zielen auf die Rekonstruktion von Informationen. Betroffen sind Trainingsdaten, verarbeitete Daten oder das Modell selbst. Ein Beispiel sind gezielte Eingaben, die auswendig gelernte Trainingsinhalte hervorlocken.

Abgrenzung nach unten: Ein Modell mit einer kleineren Angriffsfläche läuft nur lokal auf öffentlichen, nicht sensiblen Daten. Es bindet keine Systeme oder Aktionen an. Ein Chatbot mit Datenbankzugriff und Function-Calling liegt am anderen Ende der Skala. Der Aufwand für Sicherheitsmaßnahmen sollte sich am tatsächlichen Risiko orientieren, nicht am Maximalszenario.

Welche Bedrohungen sind KI-spezifisch?

Das BSI unterscheidet in seinem Risikokatalog zu generativen KI-Modellen 3 Kategorien. Das sind Risiken bei ordnungsgemäßer Nutzung, Risiken durch missbräuchliche Nutzung und Risiken durch gezielte Angriffe. Für die Softwareentwicklung sind vor allem 3 Angriffsklassen relevant, ergänzt um einen entwicklungsspezifischen Sonderfall.

Evasion Attacks, Manipulation über die Eingabe. Nutzende oder Angreifende verändern die Eingabe. Ziel ist, Sicherheitsmechanismen zu umgehen. Sind diese Mechanismen im Modell selbst verankert, spricht man von Jailbreaking, sind sie über einen System-Prompt realisiert, von Prompt Injection.

Besonders kritisch wird es bei indirekter Prompt Injection. Eine Anwendung verarbeitet dabei Inhalte aus Drittquellen: eine Webseite, ein hochgeladenes Dokument, eine eingehende E-Mail. Darin kann eine Anweisung versteckt sein. Das Modell interpretiert sie dann als Befehl. Eigentlich soll es nur zusammenfassen oder analysieren. Besonders kritisch wird das laut BSI, wenn eine LLM-basierte Anwendung selbstständig Aktionen ausführen kann, etwa das Versenden oder Löschen von E-Mails.

Poisoning Attacks, Manipulation der Daten- oder Wissensbasis. Werden Trainingsdaten automatisiert aus dem Internet gesammelt, können Angreifende gezielt manipulierte Inhalte platzieren. Praktisch relevanter für KMU ohne eigenes Modelltraining ist die Vergiftung einer RAG-Wissensdatenbank. Manche Anwendungen reichern ihre Antworten aus einer Dokumentenablage an. Manipulierte Einträge dort können das Modell zu vordefinierten Falschantworten verleiten.

Privacy Attacks, Extraktion von Daten und Modellwissen. Diese Angriffe zielen auf die Rekonstruktion von Trainingsdaten, im Betrieb verarbeiteten Daten oder Modellinterna. Für den Praxisfall bedeutet das vor allem eines: Was ein Modell über einen System-Prompt oder eine Chat-Historie “weiß”, lässt sich unter Umständen durch geschickte Eingaben extrahieren. System-Prompts sind kein verlässliches Geheimnis.

Der Entwicklungs-Sonderfall: Halluzinierte Paketnamen. LLMs werden zunehmend als Programmierhilfe eingesetzt. Sie schlagen dabei auch Bibliotheken vor. Das BSI beschreibt ein konkretes Angriffsmuster.

Eine angreifende Person fragt ein Modell wiederholt nach Paketen für ein bestimmtes Problem. Irgendwann halluziniert das Modell einen nicht existierenden Paketnamen. Diesen Namen registriert die angreifende Person als echtes, aber schadhaftes Paket in einer öffentlichen Bibliothek.

Später fragt eine entwickelnde Person dasselbe Modell nach einer Empfehlung. Sie kann denselben halluzinierten, jetzt aber real existierenden und schadhaften Namen erhalten und installieren. Das ist kein Zukunftsszenario, sondern ein dokumentiertes Muster. Eine einfache Regel entschärft es: Paketnamen aus KI-Vorschlägen immer gegen die offizielle Paketquelle prüfen, inklusive Download-Zahlen und Historie. Das passiert, bevor sie installiert werden.

Ergänzend bleiben klassische Risiken relevant, die KI-Funktionen verstärken. Dazu gehört fehlende Vertraulichkeit eingegebener Daten. Cloud-Dienste können Ein- und Ausgaben speichern oder weiter trainieren. Auch fehlende Ausgabequalität durch Halluzinationen zählt dazu. Speziell bei generiertem Code kommt ein weiteres Risiko hinzu: die Übernahme bekannter Schwachstellen oder veralteter Bibliotheken. Das passiert, wenn Ausgaben ungeprüft übernommen werden.

Wie modelliert man Datenflüsse?

Threat Modeling für KI-Funktionen unterscheidet sich an einer Stelle vom klassischen Threat Modeling. Es gibt eine zusätzliche, unscharfe Vertrauensgrenze. Sie liegt zwischen dem, was das Modell als Anweisung behandelt, und dem, was es als Inhalt behandelt. Diese Grenze ist beim Modell selbst nicht zuverlässig durchsetzbar. Die Orientierungshilfe der Datenschutzkonferenz empfiehlt für KI-Systeme, den Datenschutz von Anfang an mitzudenken (“data protection by design”). Die Lebenszyklusphasen Design, Entwicklung, Einführung sowie Betrieb und Monitoring sollten jeweils separat auf Anforderungen geprüft werden.

Für die Praxis reicht ein einfaches Modell mit 4 Fragen pro KI-Komponente:

Frage	Woran erkennst du das Risiko?
Was geht als Eingabe hinein?	Nur Nutzertext? Oder auch Dokumente, Webinhalte, E-Mails Dritter, die das Modell “liest”?
Auf welche Systeme kann das Modell zugreifen?	Nur Lesezugriff auf eine Wissensdatenbank? Oder Schreibzugriff, Aktionsausführung, Tool-Aufrufe?
Wer kann die Eingabe beeinflussen, ohne autorisiert zu sein?	Externe Absender, öffentlich einsehbare Dokumente, ungeprüfte Uploads.
Was passiert, wenn die Ausgabe falsch oder manipuliert ist?	Wird sie ungeprüft angezeigt, gespeichert, ausgeführt oder weiterverschickt?

Eigene vereinfachte Vier-Fragen-Matrix Philogic Labs, abgeleitet aus den BSI-Kategorien “ordnungsgemäße Nutzung”, “missbräuchliche Nutzung” und “Angriffe” sowie den DSK-Lebenszyklusphasen.

Der wichtigste Hebel dieser Matrix: Eine KI-Komponente greift manchmal auf ungeprüfte Drittinhalte zu. Sie kann zugleich Aktionen mit Außenwirkung ausführen: E-Mails senden, Datensätze ändern, Zahlungen anstoßen. Dann steigt das Risiko sprunghaft. Genau diese Kombination beschreibt das BSI als Kernursache für die kritischsten Prompt-Injection-Angriffe.

In meiner Praxis ist das der erste Punkt bei jedem KI-Feature-Review: Kann das Modell allein, ohne menschliche Bestätigung, etwas Irreversibles auslösen? Wenn ja, gehört dort ein Prüfschritt hin. Das gilt unabhängig davon, wie gut die übrigen Schutzmaßnahmen sind.

Wie schützt man Prompts und Tools?

Eine verbreitete, aber falsche Annahme: Ein gut formulierter System-Prompt sei eine Sicherheitsgrenze. Das BSI stellt klar: Sprachmodelle unterscheiden grundsätzlich nicht zuverlässig zwischen Herstelleranweisungen und Nutzereingaben. Ein Modell interpretiert alle Eingaben nach demselben Muster. Ein System-Prompt ist eine Verhaltensvorgabe, kein Zugriffsschutz.

Wirksamer Schutz setzt deshalb nicht beim Prompt an, sondern bei diesen 5 Bausteinen der Architektur drumherum:

• Rechte- und Rollenkonzept für angebundene Tools. Jede Funktion, die ein Modell aufrufen kann (Datenbankzugriff, E-Mail-Versand, Dateisystem, externe API), bekommt nur die nötigen Rechte für den konkreten Anwendungsfall. Ein Zusammenfassungs-Bot braucht keinen Schreibzugriff auf das CRM.

• Bestätigungsschritte vor kritischen Aktionen. Aktionen mit Außenwirkung oder finanziellen Folgen sollten nicht allein aufgrund einer Modellausgabe ausgelöst werden. Ein Mensch bestätigt, bevor etwas Irreversibles passiert. Das ist dieselbe Human-in-the-Loop-Logik wie bei der Auswahl von KI-Use-Cases.

• Validierung und Sanitisierung von Eingaben. Inhalte aus Drittquellen (Dokumente, Webseiten, eingehende Nachrichten) werden oft an ein Modell weitergegeben. Sie sollten wo möglich klar von der Nutzeranweisung getrennt werden. Vor der Verarbeitung gehört eine Prüfung auf verdächtige Muster dazu.

• Validierung von Ausgaben vor Weiterverwendung. Eine Modellausgabe wird manchmal automatisch in eine andere Anwendung übernommen: als Code, als Datenbankabfrage, als Text auf der eigenen Website. Dann gehört eine Prüfung dazwischen. Insbesondere generierter Programmcode sollte nie ungeprüft ausgeführt werden, wenn er auf Basis von Nutzereingaben entstanden ist.

• Sparsamer Umgang mit sensiblen Daten im Prompt. Was nicht im Kontext eines Modells landet, kann auch nicht darüber abfließen. Es kann auch nicht extrahiert werden. Vertrauliche Informationen gehören nur dann in einen Prompt oder eine RAG-Wissensbasis, wenn der Anwendungsfall es zwingend erfordert. Dann nur mit geprüftem Anbieter und geklärter Auftragsverarbeitung.

• Zugriffsbeschränkung auf die Wissensbasis. Bei RAG-Systemen entscheidet ein sauberes Rechtekonzept, wer über die Suche an welche Dokumente kommt. Ein Rechte- und Rollensystem über textuelle Anweisungen im Prompt ist keine tragfähige Lösung. Es muss auf Ebene der Datenanbindung selbst greifen.

Welche Tests gehören vor Release?

Vor jedem Release gehören mindestens 5 Testkategorien auf die Liste. Klassische Sicherheitstests (Penetrationstests, Abhängigkeitsprüfung, Code Review) bleiben Pflicht und werden durch KI-spezifische Prüfungen ergänzt, nicht ersetzt:

1. Jailbreak- und Prompt-Injection-Tests. Gezielt versuchen, das System durch manipulierte Eingaben aus seiner vorgesehenen Rolle zu bringen. Verarbeitet die Anwendung Drittquellen, gehört indirekte Injection über Testdokumente oder Test-Webinhalte dazu.

2. Tests mit fehlerhaften und untypischen Eingaben. Rechtschreibfehler, Fremdsprachen, ungewöhnlicher Satzbau, sinnfreie Zeichenketten: Modelle reagieren darauf nachweislich sensibler als auf saubere Eingaben. Das kann zu Fehlfunktionen führen. Es kann auch zu ausnutzbarem Verhalten führen.

3. Prüfung generierter Code-Abhängigkeiten. Jeder von einer KI-Assistenz vorgeschlagene Paketname wird gegen die offizielle Paketquelle geprüft. Geprüft werden Existenz, Verbreitung und Historie. Das passiert, bevor er in ein Projekt übernommen wird. Das ist die direkte Gegenmaßnahme zum weiter oben beschriebenen Halluzinations-Angriffsmuster.

4. Systemweite Tests, nicht nur Modelltests. Das BSI betont: Tests sollten nicht nur das Modell isoliert betreffen. Sie sollten das gesamte System inklusive aller Schnittstellen umfassen. Dazu zählen auch die angebundenen Tools, die Datenanbindung und die Ausgabeverarbeitung.

5. Red Teaming für kritische Anwendungsfälle. Bei Systemen mit Aktionsrechten oder Zugriff auf sensible Daten lohnt sich ein gezielter, ggf. extern unterstützter Testlauf. Er sucht aktiv nach Umgehungswegen, statt nur den vorgesehenen Pfad zu prüfen.

Wichtig für die Einordnung der Ergebnisse: Das BSI weist ausdrücklich darauf hin. Automatisierte Erkennungsmechanismen für KI-generierte oder manipulierte Inhalte sind aktuell nur begrenzt zuverlässig. Ihr Ergebnis ist als Hinweis zu behandeln, nicht als abschließende Entscheidungsgrundlage. Tests reduzieren Risiko, sie eliminieren es nicht.

Wie überwacht man Betrieb?

Ein System, das beim Release sauber getestet wurde, ist nicht dauerhaft sicher. Modelle werden von Anbietern aktualisiert, Angriffsmuster entwickeln sich weiter, und angebundene Datenquellen verändern sich mit der Zeit. Betrieb heißt deshalb kontinuierliche Beobachtung entlang dieser 5 Punkte, nicht einmalige Abnahme:

• Logging von Ein- und Ausgaben sowie internen Aufrufen. Bei LLM-basierten Anwendungen empfiehlt sich ein Logging. Es macht nachvollziehbar, welche Tools aufgerufen wurden. Es zeigt auch, welche Informationsflüsse von der ursprünglichen Eingabe ausgingen. Das gilt unter Beachtung geltender datenschutzrechtlicher Vorgaben.

• Regelmäßige Stichproben zur Ausgabequalität. Auch nach erfolgreichem Pilotbetrieb sollten Ausgaben in Intervallen erneut geprüft werden. So erkennst du Qualitätsverschlechterungen oder Drift frühzeitig.

• Benannte Betriebsverantwortung. Jemand muss zuständig sein, wenn auffälliges Verhalten auftritt. Das gilt unabhängig davon, ob es aus normaler Nutzung, Missbrauch oder einem gezielten Angriff resultiert. Ohne klaren Owner verfällt jede Sicherheitsmaßnahme mit der Zeit.

• Zugriffsbeschränkung und Ratenbegrenzung. Die Anfragen pro Nutzer:in oder Zeitspanne zu begrenzen erschwert automatisierte Angriffe. Es erschwert auch das iterative Austesten von Umgehungswegen für Filtermechanismen.

• Nachbearbeitung kritischer Ausgaben. Bei Ausgaben mit Außenwirkung, etwa Inhalten für die eigene Website oder Kundenkommunikation, lohnt sich ein Abgleich mit weiteren Quellen und eine Freigabe vor Veröffentlichung, statt vollautomatischer Publikation.

Umsetzung: ein realistischer Ablauf

In meiner Arbeit an KI-gestützten internen Tools und MVPs hat sich eine Reihenfolge bewährt. Sie deckt sich mit den BSI-Lebenszyklusphasen. Zuerst die Datenflussmatrix von oben für die geplante Funktion ausfüllen, noch vor der Toolauswahl. Dann Rechte- und Rollenkonzept für alle angebundenen Systeme festlegen, bevor die erste Zeile Integrationscode entsteht. Während der Entwicklung generierten Code grundsätzlich reviewen, insbesondere Abhängigkeiten.

Vor dem Release die oben genannten 5 Testkategorien durchlaufen. Schwerpunkt ist das tatsächliche Risiko der Funktion. Ein reiner Lese-Chatbot ohne Aktionsrechte braucht weniger Aufwand als ein System mit Schreibzugriff auf Kundendaten. Nach dem Go-Live Logging und eine erste Verantwortlichkeit aktivieren, bevor die Nutzung skaliert.

Diese Reihenfolge kostet Zeit gegenüber einem direkten Prototyp-zu-Produktion-Sprung. Der Zeitaufwand hängt stark vom Umfang der angebundenen Systeme ab. Er lässt sich seriös erst nach der Datenflussanalyse beziffern. Als grobe Einordnung liegt ein einfacher Chatbot ohne Aktionsrechte auf der unteren Seite.

Ein System mit mehreren Tool-Anbindungen und Schreibzugriffen liegt deutlich darüber. Wer diesen Schritt überspringt, verlagert die Kosten nicht weg, sondern in die Zukunft. Sie kommen dann als Incident-Response zurück. Oder als Vertrauensverlust, wenn eine manipulierte Ausgabe erst im Betrieb auffällt.

Risiken & Grenzen

Ein paar ehrliche Einschränkungen gehören dazu: Vollständige Sicherheit gibt es bei generativen Modellen nicht. Das BSI benennt selbst, dass viele Restrisiken auf Modelleigenschaften zurückgehen. Diese lassen sich ohne Funktionseinbußen nicht beseitigen. Beispiele sind die grundsätzliche Sensibilität gegenüber Eingabeveränderungen sowie die fehlende zuverlässige Trennung von Anweisung und Inhalt. Wer dir “hundertprozentigen Schutz vor Prompt Injection” verspricht, verkauft dir etwas, das es aktuell nicht gibt.

Zweitens: Automatisierte Detektionsmechanismen für manipulierte oder KI-generierte Inhalte sind laut BSI aktuell in ihrer Zuverlässigkeit begrenzt. Sie sollten nur als Hinweis dienen, nie als alleinige Entscheidungsgrundlage. Drittens gilt für Datenschutz- und AI-Act-Fragen im Zusammenhang mit KI-Systemen: Dieser Artikel ersetzt keine Rechtsberatung (Stand Juli 2026). Bei personenbezogenen Daten oder Hochrisiko-Anwendungsfällen gehört die Prüfung zu einer Datenschutzbeauftragten Person oder juristischer Beratung. Sie orientiert sich an der Orientierungshilfe der Datenschutzkonferenz.

Und viertens: Nicht jede Funktion braucht das volle Programm. Ein internes Tool ohne Zugriff auf personenbezogene Daten und ohne Aktionsrechte hat eine kleinere Angriffsfläche als ein kundenseitiger Chatbot mit Datenbankanbindung. Sicherheitsaufwand sollte sich am Risiko orientieren, alles andere ist entweder Verschwendung oder falsche Sicherheit.

Checkliste: Sichere KI-Softwareentwicklung

Diese 10 Punkte kannst du vor jedem Release durchgehen.

1. Für jede KI-Komponente ist die Datenflussmatrix ausgefüllt: Eingaben, Systemzugriffe, mögliche unautorisierte Einflussnahme, Folgen fehlerhafter Ausgaben.

2. Aktionen mit Außenwirkung (Senden, Löschen, Zahlen, Veröffentlichen) laufen nie allein auf Basis einer Modellausgabe, es gibt einen Bestätigungsschritt.

3. Angebundene Tools und Datenquellen haben ein Rechte- und Rollenkonzept nach dem Minimalprinzip, nicht pauschalen Vollzugriff.

4. System-Prompts werden nicht als Sicherheitsgrenze behandelt, kritische Regeln sind technisch, nicht nur textuell durchgesetzt.

5. Inhalte aus Drittquellen (Dokumente, Webseiten, E-Mails), die ein Modell verarbeitet, sind als potenziell manipulierbar eingestuft.

6. Generierter Code wird reviewt; vorgeschlagene Paketnamen werden vor Installation gegen die offizielle Paketquelle geprüft.

7. Vor dem Release wurden Jailbreak-/Prompt-Injection-Tests und Tests mit fehlerhaften Eingaben durchgeführt, für das Gesamtsystem, nicht nur das Modell.

8. Im Betrieb gibt es Logging von Ein-/Ausgaben und Tool-Aufrufen sowie eine benannte Zuständigkeit für auffälliges Verhalten.

9. Ausgaben mit Außenwirkung durchlaufen eine Prüfung oder Freigabe, bevor sie veröffentlicht oder weiterverarbeitet werden.

10. Bei personenbezogenen oder sensiblen Daten sind Datenschutzanforderungen und Auftragsverarbeitung vor dem produktiven Einsatz geklärt.

Planst du eine konkrete KI-Funktion oder willst ein bestehendes System auf diese Punkte prüfen lassen? Mehr zum praktischen Vorgehen bei internen Tools und MVPs findest du im Themenbereich KI-Softwareentwicklung. Für Teams, die die genannten Risiken im eigenen Unternehmen einordnen wollen, bieten sich Schulungen an. Einen Scope- oder Architektur-Check können wir in einem kostenlosen Erstgespräch besprechen; unser Beratungsangebot findest du auf der Startseite.