Datenlecks durch LLM: Wie Sie Firmendaten und Kundendaten schützen

Die meisten Gespräche über KI-Sicherheit enden bei „Füge keine vertraulichen Daten in einen öffentlichen Chat ein“. Das stimmt, aber es ist nur der erste und einfachste Vektor. In Produktionssystemen — Assistenten mit Wissensdatenbank, Agenten mit CRM-Zugriff, Automatisierungen im Kundenservice — gelangen Daten auf weniger offensichtliche Weise nach außen: über den Kontext, den das Modell im Speicher hat, über Logs, die jemand „vorübergehend zum Debuggen“ aktiviert hat, über die Lizenzbedingungen des Modellanbieters. Dieser Artikel zerlegt vier reale Leckage-Vektoren und beschreibt konkrete Abwehrmaßnahmen für jeden von ihnen. Wir versprechen keine „vollständige Dichtheit“ — in der Sicherheit ist ein solches Versprechen ein Warnsignal. Wir zeigen, wie man das Risiko auf ein Niveau reduziert, das sich dokumentieren und rechtfertigen lässt.

Prompt Injection ist das Einschleusen von Anweisungen in Inhalte, die das Modell als Eingabedaten verarbeitet. In einem System mit Wissensdatenbank sieht das Modell in seinem Kontext den System-Prompt, abgerufene Dokumentenausschnitte und — manchmal — Daten anderer Nutzer. Ein Angreifer, der das Modell dazu bringt, diesen Kontext „laut vorzulesen“, extrahiert Dinge, die es nie hätte sehen dürfen: den Inhalt der Systemanweisungen, Fragmente fremder Daten, die Struktur interner Quellen.

Die gefährlichste Variante ist indirekte Injection: Die schädliche Anweisung wird nicht in den Chat eingegeben, sondern in einem Dokument versteckt, das das System selbst in den Kontext lädt (E-Mail, PDF-Datei, Webseite). Das Modell behandelt sie als Teil der Aufgabe. Daher reicht die Validierung dessen, was der Nutzer eingibt, allein nicht aus — man muss auch kontrollieren, was das System von außen einzieht.

Die Abwehr besteht aus drei Schichten. Erste: Der System-Prompt enthält niemals Geheimnisse oder Daten, deren Offenlegung schmerzt — Schlüssel und sensible Daten halten wir außerhalb des Modellkontexts. Zweite: Guardrails am Eingang erkennen Versuche der Manipulation (Muster wie „Ignoriere vorherige Anweisungen“, Versuche, die Sprache als Tarnung zu ändern). Dritte: Isolierung pro Rolle und pro Tenant, damit selbst eine erfolgreiche Injection nicht über die Daten hinausgreift, auf die der Nutzer ohnehin Zugriff hat. Eine detaillierte Liste der Tests beschreiben wir im Artikel über den Sicherheitsaudit eines KI-Assistenten, und die Architektur der Berechtigungen im Text über Sicherheit von KI-Agenten.

Dies ist das häufigste Leck, das wir in der Praxis sehen — und das unspektakulärste. Personenbezogene Daten gelangen völlig legal in das System: Ein Kunde gibt seinen Namen und die Vorgangsnummer ein, ein Mitarbeiter fügt einen Vertragsausschnitt ein. Das Problem beginnt später, wenn diese Daten dorthin wandern, wo sie niemand geplant hat: in die externe Modell-API in Klartextform, in die Anwendungslogs, in die Tabelle „Konversationsverlauf“ ohne Retention-Policy.

Logs sind hier besonders tückisch. Observability ist notwendig, um Probleme zu diagnostizieren, also aktiviert jemand die vollständige Protokollierung der Abfrageinhalte „vorübergehend“ — und es bleibt monatelang so. Nach einem halben Jahr hat man ein Repository mit PII ohne rechtliche Grundlage, ohne Retention und ohne Mechanismus zur Löschung auf Anfrage, wie es die RODO verlangt.

Die Abwehr besteht in der Maskierung von PII vor dem Modell und vor dem Schreiben in das Log. In unserem Ansatz durchläuft die Abfrage eine Pseudonymisierungsschicht, bevor sie an das LLM geht: Namen, PESEL-Nummern, E-Mails und Kontonummern werden durch Tokens ersetzt, und die Originale — falls überhaupt benötigt — bleiben auf der Seite, die Sie kontrollieren. Logs speichern operative Metadaten (Zeit, Status, Token-Kosten), nicht den Inhalt in Reinform. Wie man Firmendaten so vorbereitet, dass diese Schicht von Anfang an funktioniert, beschreiben wir im Text über die Vorbereitung von Firmendaten für KI.

Der dritte Vektor ist konventionell, nicht technisch — und genau deshalb leicht zu übersehen. Wenn Sie eine Abfrage an eine externe Modell-API senden, lautet die entscheidende Frage: Was macht der Anbieter mit diesen Daten nach der Verarbeitung? Werden sie gespeichert? Können sie in den Trainingsdatensatz der nächsten Modellversion gelangen? Werden sie außerhalb des Europäischen Wirtschaftsraums verarbeitet?

Das sind Fragen zur Data-Residency und Retention, und die Antworten verstecken sich in den Lizenzbedingungen, nicht in der technischen Dokumentation. Der Unterschied zwischen „API für geschäftliche Aufgaben mit Zero-Retention-Garantie“ und „kostenlosem Verbraucher-Chat, der aus Gesprächen lernt“ ist aus RODO-Perspektive fundamental und entscheidet oft darüber, ob Sie den Anbieter überhaupt für Kundendaten nutzen dürfen.

Hier macht die Wahl der Architektur den größten Unterschied. Self-Hosting des Modells — das Ausführen auf eigener oder kontrollierter Infrastruktur — eliminiert diesen Vektor an der Quelle: Die Daten verlassen Ihre Umgebung nicht, daher entfällt die Frage „Was macht der Anbieter damit“. Der Preis ist der Wartungsaufwand und meist eine geringere Rohqualität der besten Modelle. Den Kompromiss und die Entscheidungskriterien erläutern wir im Artikel über Self-Hosting von LLM und RODO.

Der vierte Vektor funktioniert umgekehrt: Es geht nicht darum, was Sie in das Modell eingeben, sondern darum, was das Modell an den Nutzer zurückgibt. Ein System mit Wissensdatenbank kann in der Antwort auf ein Dokument zugreifen, für das der Fragesteller keine Berechtigungen hat — und dessen Inhalt zusammenfassen, wobei die gesamte auf Anwendungsebene aufgebaute Zugriffskontrolle umgangen wird. Oder das Modell „ergänzt“ die Antwort mit Daten, die es aus einem vorherigen Gespräch eines anderen Nutzers in einer schlecht isolierten Session erinnert hat.

Die Abwehr kombiniert Zugriffskontrolle mit Guardrails am Ausgang. Die Filterung von Berechtigungen muss auf der Ebene des Kontextabrufs funktionieren (das Modell sieht nur die Fragmente, auf die der Fragesteller Zugriff hat), nicht erst auf der Ebene der Antwort. Am Ausgang selbst scannt eine zweite Guardrail-Schicht die Antwort auf Muster sensibler Daten, bevor sie an den Nutzer geht. Dieselbe Schicht stellt sicher, dass das Modell kein Geheimnis oder PII zitiert, selbst wenn es aus irgendeinem Grund im Kontext enthalten war.

Vier Vektoren erfordern vier verschiedene Abwehrschichten. Die folgende Tabelle zeigt, was wovor schützt — und warum eine einzelne Maßnahme nicht ausreicht.

Keine Zeile deckt die anderen ab. Self-Hosting (Zeile 3) schützt nicht vor Prompt Injection (Zeile 1). Die Maskierung von PII (Zeile 2) stoppt keine Antwort, die ein fremdes Dokument zitiert (Zeile 4). Sicherheit ist die Summe der Schichten — und genau deshalb prüft ein Audit jede einzeln.

Vier technische Schichten funktionieren nur, wenn eine organisatorische Entscheidung dahintersteht: Welche Daten dürfen überhaupt an das Modell übergeben werden, in welcher Form und über welchen Anbieter. Das ist die Domäne des Daten-Governance für KI — Datenklassifizierung, Flussregister und Zuweisung von Verantwortlichkeiten. Ohne sie wird jede technische Schicht ad hoc konfiguriert und driftet mit der Zeit.

Für Kundendaten lohnt es sich zu prüfen, ob die Verarbeitung eine DPIA erfordert — eine Datenschutz-Folgenabschätzung. Das Ergebnis des Audits der Leckage-Vektoren (aus der obigen Tabelle) speist eine solche Bewertung natürlich: Es zeigt, welches Risiko besteht und wie es begrenzt wurde. Die Dokumentationspflichten für das Jahr 2026, die RODO mit dem AI Act verbinden, beschreiben wir im Artikel über Pflichten von Unternehmen gegenüber AI Act und RODO.

Die praktische Implementierungsreihenfolge ist folgende: Zuerst Datenklassifizierung und Anbieterentscheidung (Governance), dann Maskierung von PII und Zugriffskontrolle (technische Schichten, die einmal richtig aufgebaut werden müssen), am Ende Guardrails und Audit als verifizierende Schicht. Der Versuch, mit Guardrails bei einem System zu beginnen, das bereits rohe PII an eine externe API sendet, ist die Behandlung eines Symptoms statt der Ursache.

Das ist notwendig, aber bei Weitem nicht ausreichend für ein Produktionssystem. Wenn Sie einen Assistenten mit Wissensdatenbank oder einen Agenten mit CRM-Zugriff aufbauen, gelangen Daten auf geplante, nicht auf zufällige Weise in das Modell — und genau dort benötigen Sie Maskierung von PII, Zugriffskontrolle und Retention-Policy. Die Regel „Keine vertraulichen Daten einfügen“ schützt vor einem von vier Vektoren.

Es schließt einen konkreten Vektor: Daten gelangen nicht an einen externen Anbieter, daher entfällt das Risiko von Retention und Training mit Ihren Daten. Es eliminiert jedoch weder Prompt Injection, das Lecken von PII in Logs noch die Offenlegung von Daten außerhalb der Berechtigungen in der Antwort — diese hängen von der Architektur ab, nicht vom Hosting-Standort. Self-Hosting vereinfacht die RODO-Compliance, aber das Audit der übrigen Schichten ist unabhängig von der Infrastrukturwahl notwendig.

Das ist eine Schicht, die die Abfrage abfängt, bevor sie zum LLM gelangt, und personenbezogene Daten (Namen, PESEL, E-Mails, Kontonummern) durch Ersatz-Tokens ersetzt. Das Modell arbeitet mit anonymisiertem Inhalt, und die Originaldaten — falls überhaupt für die Antwort benötigt — bleiben auf der Seite, die Sie kontrollieren. Dadurch werden selbst bei einem Kontextleck oder Log mit vollem Inhalt keine realen personenbezogenen Daten offengelegt.

Die Antwort findet sich in den Lizenzbedingungen des Dienstes, nicht in der technischen Dokumentation — suchen Sie nach Klauseln zur Datenretention, zum Training und zur Verarbeitungsstandort (Data-Residency). Bezahlte Business-APIs bieten meist Zero-Retention und Ausschluss vom Training; kostenlose Verbraucherdienste oft nicht. Wenn Sie Kundendaten verarbeiten, behandeln Sie das Fehlen einer eindeutigen Zero-Retention-Garantie als fehlende Erlaubnis, diesen Anbieter zu nutzen.

So viele, wie Sie aktive Vektoren haben. Wenn das System eine externe API nutzt und PII von Kunden verarbeitet, sind alle vier im Spiel — und dann benötigen Sie Maskierung, Guardrails, Zugriffskontrolle sowie eine Entscheidung über Retention beim Anbieter oder Self-Hosting. Die Kosten- und Zeitangaben hängen vom Umfang ab, daher geben wir sie erst nach einer Datenerfassung an; der Ausgangspunkt ist die Klassifizierung, die zeigt, welche Vektoren Sie überhaupt betreffen.