Sichere KI-Softwareentwicklung: Von Threat Modeling bis Release

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, sondern sie um Bedrohungen zu erweitern, die es ohne generative Modelle so nicht gibt.

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

Begriffe kurz geklärt

Threat Modeling ist die strukturierte Frage: Welche Daten fließen wohin, wer könnte sie manipulieren oder abgreifen, und was würde das kosten? Es ist kein einmaliges Dokument, sondern eine Übung, die man bei jeder neuen KI-Funktion wiederholt.

Prompt Injection bezeichnet Eingaben, die ein Sprachmodell dazu bringen, vorgegebene Anweisungen zu ignorieren und stattdessen den Willen der angreifenden Person auszuführen. Bei direkter Prompt Injection formuliert die angreifende Person die Eingabe selbst; bei indirekter Prompt Injection steckt die Anweisung in einem Inhalt, den das Modell verarbeitet – etwa einer Webseite, einem Dokument oder einer E-Mail, die zusammengefasst werden soll.

Poisoning meint die gezielte Manipulation von Trainings- oder Wissensdaten, damit ein Modell bei bestimmten Auslösern fehlerhaft reagiert – etwa als eingeschleuste Backdoor oder als manipulierter Eintrag in einer Wissensdatenbank für Retrieval-Augmented Generation (RAG).

Privacy Attacks zielen darauf, Informationen über Trainingsdaten, verarbeitete Daten oder das Modell selbst zu rekonstruieren – zum Beispiel durch gezielte Eingaben, die auswendig gelernte Trainingsinhalte hervorlocken.

Abgrenzung nach unten: Ein Modell, das nur lokal auf öffentlichen, nicht sensiblen Daten läuft und keine Systeme oder Aktionen anbindet, hat eine deutlich kleinere Angriffsfläche als ein Chatbot mit Datenbankzugriff und Function-Calling. 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 drei Kategorien: Risiken bei ordnungsgemäßer Nutzung, Risiken durch missbräuchliche Nutzung und Risiken durch gezielte Angriffe. Für die Softwareentwicklung sind vor allem drei Angriffsklassen relevant, ergänzt um einen entwicklungsspezifischen Sonderfall.

Evasion Attacks – Manipulation über die Eingabe. Nutzende oder Angreifende verändern die Eingabe so, dass Sicherheitsmechanismen umgangen werden. 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: Verarbeitet eine Anwendung Inhalte aus Drittquellen – eine Webseite, ein hochgeladenes Dokument, eine eingehende E-Mail – kann darin eine Anweisung versteckt sein, die das Modell als Befehl interpretiert, obwohl es eigentlich nur zusammenfassen oder analysieren soll. Das wird laut BSI besonders kritisch, 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, die keine eigenen Modelle trainieren: die Vergiftung einer RAG-Wissensdatenbank. Reichert eine Anwendung ihre Antworten aus einer Dokumentenablage an, können manipulierte Einträge dort das Modell zu vordefinierten Falschantworten verleiten.

Privacy Attacks – Extraktion von Daten und Modellwissen. Diese Angriffe zielen darauf, Trainingsdaten, im Betrieb verarbeitete Daten oder Modellinterna zu rekonstruieren. Für den Praxisfall bedeutet das vor allem: 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 und 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, bis das Modell einen nicht existierenden Paketnamen halluziniert. Diesen Namen registriert die angreifende Person als echtes, aber schadhaftes Paket in einer öffentlichen Bibliothek. Fragt später eine entwickelnde Person dasselbe Modell nach einer Empfehlung, kann sie denselben halluzinierten – jetzt aber real existierenden und schadhaften – Namen erhalten und installieren. Das ist kein Zukunftsszenario, sondern ein dokumentiertes Muster, das sich mit einer einfachen Regel entschärfen lässt: Paketnamen aus KI-Vorschlägen immer gegen die offizielle Paketquelle und deren Download-Zahlen und Historie prüfen, bevor sie installiert werden.

Ergänzend bleiben klassische Risiken relevant, die durch KI-Funktionen verstärkt werden: fehlende Vertraulichkeit eingegebener Daten (Cloud-Dienste können Ein- und Ausgaben speichern oder weiter trainieren), fehlende Ausgabequalität durch Halluzinationen sowie – speziell bei generiertem Code – die Übernahme bekannter Schwachstellen oder veralteter Bibliotheken, wenn Ausgaben ungeprüft übernommen werden.

Wie modelliert man Datenflüsse?

Threat Modeling für KI-Funktionen unterscheidet sich von klassischem Threat Modeling vor allem an einer Stelle: Es gibt eine zusätzliche, unscharfe Vertrauensgrenze zwischen dem, was das Modell als Anweisung behandelt, und dem, was es als zu verarbeitenden Inhalt behandelt – und 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”) und die Lebenszyklusphasen Design, Entwicklung, Einführung sowie Betrieb und Monitoring jeweils separat auf Anforderungen zu prüfen.

Für die Praxis reicht ein einfaches Modell mit vier 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: Sobald eine KI-Komponente sowohl auf ungeprüfte Drittinhalte zugreift als auch Aktionen mit Außenwirkung ausführen kann (E-Mails senden, Datensätze ändern, Zahlungen anstoßen), steigt das Risiko sprunghaft. Genau diese Kombination beschreibt das BSI als Kernursache für die kritischsten Ausprägungen von Prompt-Injection-Angriffen. In meiner Praxis ist das der erste Punkt, den ich bei jedem KI-Feature-Review prüfe: Kann das Modell allein, ohne menschliche Bestätigung, etwas Irreversibles auslösen? Wenn ja, gehört dort ein Prüfschritt hin – 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, dass Sprachmodelle grundsätzlich nicht zuverlässig zwischen Herstelleranweisungen und Nutzereingaben unterscheiden – 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 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 Rechte, die für den konkreten Anwendungsfall nötig sind. 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 – dieselbe Human-in-the-Loop-Logik, die sich bei der Auswahl von KI-Use-Cases generell bewährt.
• Validierung und Sanitisierung von Eingaben. Inhalte aus Drittquellen (Dokumente, Webseiten, eingehende Nachrichten), die an ein Modell weitergegeben werden, sollten wo möglich klar von der eigentlichen Nutzeranweisung getrennt und auf verdächtige Muster geprüft werden, bevor sie verarbeitet werden.
• Validierung von Ausgaben vor Weiterverwendung. Wird eine Modellausgabe automatisch in eine andere Anwendung übernommen – als Code, als Datenbankabfrage, als Text auf der eigenen Website – 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 oder extrahiert werden. Vertrauliche Informationen gehören nur dann in einen Prompt oder eine RAG-Wissensbasis, wenn der Anwendungsfall es zwingend erfordert – und dann 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 umzusetzen, ist keine tragfähige Lösung – es muss auf Ebene der Datenanbindung selbst greifen.

Welche Tests gehören vor Release?

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 – inklusive indirekter Injection über Testdokumente oder Test-Webinhalte, wenn die Anwendung solche Quellen verarbeitet.
2. Tests mit fehlerhaften und untypischen Eingaben. Rechtschreibfehler, Fremdsprachen, ungewöhnlicher Satzbau, sinnfreie Zeichenketten – Modelle reagieren darauf nachweislich sensibler als auf saubere Eingaben, was sowohl zu Fehlfunktionen als auch zu ausnutzbarem Verhalten führen kann.
3. Prüfung generierter Code-Abhängigkeiten. Jeder von einer KI-Assistenz vorgeschlagene Paketname wird gegen die offizielle Paketquelle geprüft – Existenz, Verbreitung, Historie – 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, dass Tests nicht nur das Modell isoliert betreffen sollten, sondern das gesamte System inklusive aller Schnittstellen – also 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, der aktiv nach Umgehungswegen sucht statt nur den vorgesehenen Pfad zu prüfen.

Wichtig für die Einordnung der Ergebnisse: Das BSI weist ausdrücklich darauf hin, dass automatisierte Erkennungsmechanismen für KI-generierte oder manipulierte Inhalte aktuell nur begrenzt zuverlässig sind und ihr Ergebnis als Hinweis, nicht als abschließende Entscheidungsgrundlage zu behandeln ist. 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. Betrieb heißt deshalb kontinuierliche Beobachtung, nicht einmalige Abnahme:

• Logging von Ein- und Ausgaben sowie internen Aufrufen. Bei LLM-basierten Anwendungen empfiehlt sich ein Logging, das nachvollziehbar macht, welche Tools aufgerufen wurden und welche Informationsflüsse ausgehend von der ursprünglichen Eingabe stattfanden – unter Beachtung geltender datenschutzrechtlicher Vorgaben.
• Regelmäßige Stichproben zur Ausgabequalität. Auch nach erfolgreichem Pilotbetrieb sollten Ausgaben in Intervallen erneut geprüft werden, um Qualitätsverschlechterungen oder Drift frühzeitig zu erkennen.
• Benannte Betriebsverantwortung. Jemand muss zuständig sein, wenn auffälliges Verhalten auftritt – 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 Anzahl der Anfragen pro Nutzer:in oder Zeitspanne zu begrenzen erschwert automatisierte Angriffe und 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 folgende Reihenfolge bewährt, die sich mit den BSI-Lebenszyklusphasen deckt: 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 fünf Testkategorien durchlaufen, mit Schwerpunkt auf dem tatsächlichen 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 und 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 deutlich darüber. Wer diesen Schritt überspringt, verlagert die Kosten nicht weg, sondern in die Zukunft – als Incident-Response 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 beschriebene Restrisiken auf Modelleigenschaften zurückgehen, die sich ohne Funktionseinbußen nicht beseitigen lassen – etwa die grundsätzliche Sensibilität gegenüber Eingabeveränderungen oder 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 und sollten nur als Hinweis, nie als alleinige Entscheidungsgrundlage dienen. 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, orientiert 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

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.

Wenn du eine konkrete KI-Funktion planst oder ein bestehendes System auf diese Punkte prüfen lassen willst: 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.