Security-Kolumne
Datum: 

Sicherheitsaspekte bei der Entwicklung von KI-Systemen

Stellen Sie sich vor, Sie arbeiten in der Softwareentwicklung bei einem Fintech-Unternehmen. Ihr neuer KI-Assistent hilft Kundenberaterinnen und -beratern dabei, Anfragen zu beantworten. Eines Morgens beginnt er, subtil falsche Kontoinformationen auszugeben – nicht, weil er gehackt wurde, sondern weil jemand eine einzige Zeile in eine Webseite eingefügt hat, die der Assistent am Vortag gelesen hat. 

Die Sicherheit eines KI-Systems wird maßgeblich schon während dessen Entwicklung zu einem entscheidenden Faktor – und nicht erst im späteren Betrieb. Anders als bei klassischer IT-Security stehen hier nicht nur Code und Infrastruktur im Fokus, sondern gerade die Daten und Modelle selbst.

In diesem Insight beschreiben wir die gängigsten Angriffe auf KI-Modelle, insbesondere große Sprachmodelle (LLMs). Wir denken dabei in Schichten: Von der Sprache als Einstiegspunkt über die Trainingsdaten bis hin zur Infrastruktur, in der Modelle operieren. Jede Schicht hat ihre eigenen Schwachstellen – und jede lässt sich verteidigen.

Die Sprache als Waffe

Prompt Injection – direkter Zugriff auf das Modellverhalten

Ein besonders relevanter und ernstzunehmender Angriffsvektor auf LLMs nennt sich Prompt Injection. Ziel dieses Angriffs ist es, Sicherheitsvorkehrungen und interne Richtlinien eines KI-Systems gezielt zu umgehen, um das Modellverhalten nach den Wünschen des Angreifers zu beeinflussen.

Prompt Injections sind besonders heimtückisch, da sie auf einfache und zugleich effektive Weise durchgeführt werden kann: Cyber-Kriminelle benötigen weder eigene leistungsstarke Hardware noch tiefergehenden technischen Zugang zum KI-System – der bloße Zugang zur Interaktion mit dem Modell reicht bereits aus.

Direkte Prompt Injection

Bei der direkten Prompt Injection manipuliert der Angreifer die Eingabe unmittelbar. Er formuliert seine Prompts so geschickt, dass das Modell Anweisungen ausführt, die es normalerweise strikt verweigern würde – etwa das Preisgeben vertraulicher Systemanweisungen oder das Generieren schädlicher Inhalte.

Indirekte Prompt Injection

Im Gegensatz dazu erfolgt die indirekte Prompt Injection, wenn das KI-Modell externe Quellen ausliest – Webseiten, hochgeladene Dokumente oder Datenbanken – und deren Inhalte automatisch in seine Antworten integriert. Enthalten diese Quellen versteckte Anweisungen, weicht das Modell unbewusst von seinem gewünschten Verhalten ab. Genau das ist das Szenario aus unserem Einstieg.

Jailbreaking

Jailbreaking, eine Unterkategorie der Prompt Injections, verfolgt das gezielte Umgehen aller Schutzmechanismen eines Modells, um dessen Sicherheits- oder Ethikrichtlinien vollständig außer Kraft zu setzen. Prominente Beispiele sind Anfragen nach Anleitungen für gefährliche Aktivitäten oder das Erzwingen der Preisgabe vertraulicher Unternehmensdaten.

Function Calling als Multiplikator

Die Gefahr von Prompt Injections erhöhen sich deutlich, wenn ein KI-Modell aktiv mit anderen Systemen verbunden wird. Beim Function Calling kann ein manipuliertes Modell eigenständig externe Funktionen ansteuern – etwa Anfragen an interne Datenbanken senden oder Prozesse auslösen, die gesonderte Zugriffsrechte voraussetzen. Dadurch wird aus einem Texte-Problem ein Infrastrukturpr

Der vergiftete Brunnen

Data Poisoning – wenn der Lernprozess selbst kompromittiert wird

Ein wichtiger Schritt im Entwicklungsprozess von LLMs ist das Training mit einer möglichst umfangreichen Anzahl an Daten. Genau hier eröffnet sich für Angreifer eine gefährliche Möglichkeit: Durch das gezielte Einschleusen manipulierter Daten kann die Integrität des Modells massiv beeinflusst werden, etwa wenn eine Bibliothek vor der Nutzung systematisch mit falschen oder verfälschten Büchern ausgestattet wird, bevor Studierende mithilfe der Bücher in der Bibliothek lernen.

Diese vergifteten Trainingsdaten können dazu führen, dass sich die Leistungsfähigkeit des Modells erheblich reduziert, es unangemessene oder toxische Antworten liefert oder gar versteckte Hintertüren eingebaut werden. Da bereits eine äußerst geringe Menge manipulierter Daten ausreicht, bleibt ein solcher Angriff oft lange unbemerkt und stellt eine dauerhafte Gefahr dar.

Training Data Extraction – das Modell als unfreiwilliger Zeuge

Während des Trainingsprozesses fließen häufig vertrauliche Daten – persönliche Informationen, Gesundheitsdaten, Geschäftsgeheimnisse – in das Modell ein und werden Teil seines "Gedächtnisses". Durch geschickt formulierte Prompts lassen sich Teile dieser Trainingsdaten aus dem Modell herauslocken, inklusive potenziell sensibler Informationen wie API-Keys oder persönlicher Daten, die im Trainingskorpus enthalten waren.

Dieses Phänomen, bekannt als Training Data Leakage, stellt eine erhebliche Gefahr für die Integrität und Vertraulichkeit unternehmenseigener und personenbezogener Daten dar – mit direkten Konsequenzen für DSGVO- Compliance und den Schutz von Geschäftsgeheimnissen.

Das Modell als Beute

Model Stealing – das immaterielle Gut im Visier

In der Praxis wird häufig auf vortrainierte Modelle, öffentliche Datensätze oder externe Tools zurückgegriffen. Das Modell selbst ist dabei ein sensibles Wertobjekt: Wenn es ungeschützt ausgeliefert oder abgefragt wird, kann es nicht nur kopiert, sondern in Teilen auch nachgebaut werden. Eine strategisch gestohlene Modell-Architektur oder Konfiguration eröffnet Angriffsvektoren und schlägt direkt auf die Wettbewerbsfähigkeit zurück.

Model Stealing erfolgt typischerweise durch systematisches Abfragen einer API: Der Angreifer sammelt eine große Zahl von Eingabe-Ausgabe-Paaren und trainiert damit ein eigenes Ersatzmodell, das das Original imitiert.

Membership Inference – wer war im Training?

Bei einem Membership Inference Angriff versucht der Angreifer herauszufinden, ob ein bestimmter Datensatz im Training des Modells verwendet wurde. Das klingt abstrakt, hat aber sehr konkrete Konsequenzen: So lässt sich beispielsweise prüfen, ob Patientenakten, private E-Mails oder andere sensible Informationen Teil des Trainings waren – ein direktes Datenschutzrisiko mit DSGVO-Relevanz.

Model Inversion – Rekonstruktion aus dem Inneren

Durch systematisches Abfragen eines Modells lassen sich Rückschlüsse auf die Trainingsdaten ziehen. Im Extremfall können dabei Gesichter, Texte oder andere persönliche Informationen aus dem Modell "rekonstruiert" werden. Besonders in Bilderkennungssystemen oder medizinischen KI-Anwendungen ist dieses Angriffsszenario besonders relevant.

Wenn die KI lügt

Halluzinationen als Sicherheitsrisiko

Halluzinationen sind nicht nur ein Qualitätsproblem – sie sind ein Sicherheitsrisiko. Wenn LLMs in sicherheitskritischen Prozessen falsche Fakten mit überzeugender Sicherheit ausgeben, entstehen reale Schadenspotenziale: ein KI-gestützter Rechtsassistent, der Gerichtsurteile erfindet; ein medizinisches System, das falsche Dosierungen empfiehlt; ein Code-Generator, der verwundbare Sicherheitsfunktionen vorschlägt.

Besonders im Kontext von RAG-Systemen (Retrieval-Augmented Generation) ist Wachsamkeit geboten: Wenn das Modell externe Dokumente abruft und verarbeitet, können fehlerhafte oder manipulierte Quellen direkt in vertrauenswürdig wirkende Antworten einfließen.

Insecure Output Handling – der unsichtbare Weiterleitungspfad

LLMs generieren Outputs, die oft direkt in nachgelagerte Systeme fließen: SQL-Queries, Shell-Befehle, HTML. Wird dieser Output nicht konsequent validiert und ggf. bereinigt, entstehen klassische Schwachstellen wie SQL-Injection oder Cross-Site-Scripting – nur diesmal KI-generiert und damit potenziell schwerer zu erkennen.

Das Tückische: Klassische Security-Scanner sind darauf ausgelegt, handgeschriebenen Code zu analysieren. KI-generierte Schwachstellen entziehen sich diesen Prüfmechanismen oft, weil sie kontextabhängig und dynamisch entstehen – jede Anfrage kann eine neue Variante produzieren.

Der Agent, der zu viel darf

Excessive Agency – wenn Autonomie zur Gefahr wird

LLM-Agenten werden zunehmend mit weitreichenden Berechtigungen ausgestattet: Dateizugriff, E-Mail-Versand, Datenbankzugriff, API-Aufrufe. Was als Produktivitätsgewinn gedacht ist, wird zur Angriffsfläche, sobald ein solcher Agent durch Prompt Injection oder einfache Modellfehler manipuliert wird.

Ein reales Szenario: Ein KI-Agent mit E-Mail-Zugriff wird durch eine indirekte Prompt Injection in einer verarbeiteten Webseite angewiesen, sensible Dokumente an eine externe Adresse weiterzuleiten – vollständig autonom, ohne dass ein Mensch eingreift. Das OWASP LLM Top 10 (2025) listet Excessive Agency explizit als kritisches Risiko.

Denial-of-Service auf Inferenz-Ebene

Nicht jeder Angriff zielt auf Datenlecks. Gezielt konstruierte, sehr lange oder rekursiv strukturierte Prompts können Inferenzkosten explodieren lassen – ein wirtschaftlicher Angriff auf API-basierte KI-Dienste. Gerade bei nutzungsbasierter Abrechnung kann dies erheblichen finanziellen Schaden verursachen, bevor es überhaupt bemerkt wird.

Sicherheit als Entwicklungsaufgabe

DevSecMLOps – der ganzheitliche Rahmen

Um derartigen Gefahren vorzubeugen, reicht ein starrer Code-Protection-Ansatz nicht aus. Die gesamte Entwicklungsumgebung muss in das Sicherheitskonzept eingebunden werden. Bewährte Prinzipien aus DevSecOps – der engen Integration von Entwicklung, Sicherheit und Betrieb – lassen sich sinnvoll mit MLOps-Methoden verbinden, die Modelle und Daten im gesamten Lebenszyklus eines KI-Systems überwachen.

Ein Beispiel: Ein Unternehmen, das autonome Fahrassistenz-Systeme entwickelt, könnte die Trainingspipeline so auslegen, dass jedes neue Datenpaket eine Hash-basierte Integritätsprüfung durchläuft. Nur wenn das Paket unverändert ist, wird es automatisch ins Training überführt. Parallel dazu wird ein Data-Governance-Komitee etabliert, das Protokolle prüft und ungewöhnliche Muster erkennt – ähnlich wie bei sicherheitsrelevanten Log-Dateien.

Anerkannte Frameworks und Standards

Die folgenden Frameworks bieten strukturierte Orientierung für die Absicherung von KI-Systemen:

  • OWASP LLM Top 10 (2025)  – die wichtigsten Schwachstellen für LLM-Anwendungen, praxisnah beschrieben
  • NIST AI Risk Management Framework (AI RMF) – systematischer Ansatz zur Risikosteuerung über den gesamten KI-Lebenszyklus
  • EU AI Act – regulatorischer Rahmen mit verpflichtenden Anforderungen für Hochrisiko-KI-Systeme
  • MITRE ATLAS – Taktiken, Techniken und Verfahren für Angriffe auf ML-Systeme (analog zu MITRE ATT&CK)

Kontinuierliches Red Teaming

Ein effektives Mittel zur regelmäßigen Prüfung und Verbesserung der Resilienz von KI-Modellen sind Penetration-Testing -Tools und automatisierte Angriffssimulationen. KI-Modelle sollten gezielt durch adversariales Training auf problematische Eingaben vorbereitet werden – lange bevor sie produktiv eingesetzt werden.

Der Mehrwert erschließt sich auf den zweiten Blick: Wenn Schutzmechanismen von Beginn an verankert sind, verringern sich die Anforderungen an nachträgliche Notfallpläne. Die KI-Systeme werden nicht nur robuster und vertrauenswürdiger, sondern auch auditfähig – was bei gesetzlichen Prüfungen durch DSGVO oder EU AI Act materiell ins Gewicht fällt.

Sicherheit ist kein Feature – es ist das Fundament

Die Angriffsfläche von KI-Systemen wächst mit ihrer Fähigkeit. Je autonomer, vernetzter und einflussreicher ein Modell wird, desto wichtiger ist es, Sicherheit nicht als nachgelagerte Prüfaufgabe zu verstehen, sondern als Designprinzip, das von der ersten Trainingsdatei bis zum letzten API-Aufruf wirksam ist.

Die in diesem Insight beschriebenen Angriffe – von Prompt Injection über Data Poisoning bis hin zu Excessive Agency – sind keine theoretischen Szenarien. Sie sind dokumentierte, aktiv genutzte Vektoren, für die es heute bereits Gegenmaßnahmen gibt. Konkrete Gegenmaßnahmen werden Bestandteil eines weiteren Insights sein.

Die Frage ist nicht mehr, ob KI-Systeme angegriffen werden – sondern ob wir bereit sind, wenn es passiert.

Dieser Artikel wurde verfasst von