Datenschutz, Sicherheit & Trust Boundaries

Ein Prompt ist eine Datenübermittlung

Der wichtigste Perspektivwechsel dieses Moduls: Ein Prompt fühlt sich an wie ein Chatfenster, ist technisch aber eine Übermittlung von Daten an ein fremdes System. Alles, was hineinkopiert wird — Kundenname, Vertragsnummer, Krankmeldung, Quellcode, Logauszug — verlässt eure Umgebung.

Damit gelten dieselben Regeln wie für jede andere Auftragsdatenverarbeitung. Neu ist nur, dass die Übermittlung diesmal ohne Formular und ohne Freigabe stattfindet — durch Copy-and-paste, einzeln, tausendfach, unbemerkt.

Verarbeitung — Nach DSGVO jeder Vorgang im Zusammenhang mit personenbezogenen Daten, etwa Erheben, Übermitteln, Speichern, Abfragen oder Löschen. Ein Modellaufruf ist daher nicht bloß Textverarbeitung.

Zeichne den Datenfluss vom Eingabefeld bis zu Anbieter, Logs, Traces, Caches, Eval-Datensätzen und Supportzugriff. Die sichtbare Chatoberfläche ist nur ein Eintrittspunkt. Auch abgeleitete Zusammenfassungen oder Embeddings können personenbezogen bleiben, wenn sie einer Person zugeordnet oder mit Zusatzwissen re-identifiziert werden können. Rechtliche Bewertung gehört zu den Verantwortlichen; technisch musst du Speicherorte und Zwecke überhaupt erst sichtbar machen.

Erstelle für jeden Speicherort eine Lösch- und Auskunftskette. Eine Anfrage kann im Produktdatensatz, Anbieterlog, Telemetriesystem, Backup und manuell exportierten Eval-Set auftauchen. Wenn Korrelation nur über Freitext möglich ist, wird Betroffenenrecht praktisch teuer oder unvollständig. Verwende deshalb kontrollierte IDs und dokumentierte Fristen. Nachteil: Durchgängige Korrelation kann selbst ein Datenschutzrisiko sein; Zugriff und Zweck werden eng begrenzt.

Datenminimierung vor dem Senden

Die wirksamste Maßnahme ist auch die einfachste: nur das senden, was für die Aufgabe gebraucht wird. Um einen Beschwerdetext zu kategorisieren, braucht das Modell den Text — nicht Name, Adresse, Kundennummer und Vertragshistorie.

• Felder gezielt auswählen statt ganze Datensätze durchzureichen — das ist eine Entscheidung im Code, nicht im Prompt.
• Bezeichner durch Platzhalter ersetzen und nach der Antwort zurückübersetzen, wo die Aufgabe sie nicht braucht.
• Anhänge und Historien nicht reflexhaft mitschicken; jedes zusätzliche Feld ist übermittelt, sobald es im Kontext steht.
• Bei Freitextfeldern damit rechnen, dass Nutzer Unerwartetes hineinschreiben — Minimierung greift dort nur teilweise.

Datenminimierung beginnt vor dem Senden. Entferne Felder, die für die konkrete Aufgabe nicht notwendig sind, ersetze Freitext durch engere Attribute und begrenze Zeiträume. Ein Supportfall kann für Kategorisierung den Fehlertext brauchen, aber nicht Namen, Telefonnummer und komplette Vertragshistorie. Preis: Aggressive Reduktion kann Kontext entfernen und Qualität senken; deshalb wird gegen ein minimiertes Eval-Set getestet, welche Felder tatsächlich erforderlich sind.

Clientseitiges Schwärzen oder ein vorgeschalteter Redaction-Service ist nur so gut wie seine Erkennung und Konfiguration. Protokolliere Redaction-Fehlerklassen, nicht die entfernten Geheimnisse. Ein Opt-out im Systemprompt ist keine Minimierung: Die Daten wurden bereits übermittelt, bevor das Modell gebeten wird, sie nicht zu verwenden.

Die vertragliche Grundlage

Wer personenbezogene Daten an einen Anbieter gibt, braucht eine tragfähige Grundlage — im europäischen Rahmen typischerweise einen Auftragsverarbeitungsvertrag samt geregeltem Ort der Verarbeitung und geregelter Weitergabe an Unterauftragnehmer. Diese Prüfung ist Standardarbeit im Einkauf und wird bei KI-Diensten auffällig oft übersprungen, weil der Zugang so niedrigschwellig ist.

Wird mit unseren Eingaben trainiert?

vertraglich ausgeschlossen — nicht nach Marketingaussage, sondern nach Vertragstext

Wo wird verarbeitet und gespeichert?

Ort und Weitergabe an Unterauftragnehmer prüfen

Wie lange werden Eingaben aufbewahrt?

Aufbewahrungsdauer und Zweck der Speicherung klären

Wer beim Anbieter kann Eingaben sehen?

Zugriffsregelungen, etwa für Missbrauchsprüfung, verstehen

Wichtig ist der Unterschied zwischen Verbrauchertarif und Unternehmensvertrag desselben Anbieters: Die technische Oberfläche kann identisch sein, die Bedingungen zur Trainingsnutzung und Aufbewahrung unterscheiden sich regelmäßig deutlich.

Ein Auftragsverarbeitungsvertrag, Rollenverteilung, zulässiger Zweck, Unterauftragnehmer und internationale Übermittlung sind keine Modellparameter. Die technische Architektur muss die vereinbarten Grenzen jedoch umsetzen: richtige Region und Endpunkte, deaktivierte oder vertraglich geregelte Trainingsnutzung, Zugriffskontrolle, Löschung und Export. Marketingaussagen ersetzen nicht die konkret geltenden Vertragsbedingungen.

Was ihr selbst protokolliert

Für Fehlersuche und Qualitätsmessung werden Prompts und Antworten meist mitgeschrieben. Damit entsteht auf eurer Seite eine neue Datenhaltung — häufig mit sensibleren Inhalten als die Fachanwendung selbst, weil Freitext alles enthalten kann.

• Zweck festlegen: Fehlersuche und Evaluation sind Zwecke, „vielleicht später nützlich“ ist keiner.
• Aufbewahrungsdauer und automatische Löschung von Anfang an einbauen, nicht nachträglich.
• Zugriff einschränken — Betriebslogs mit Freitext sind kein Material für den allgemeinen Log-Zugang.
• Testsets aus echten Anfragen sind dieselbe Kategorie und brauchen dieselbe Behandlung.

Eigene Logs sind oft der größere Datenbestand als der Modellanbieter. Vollständige Prompts in APM, Error-Tracking oder Debug-Traces vervielfachen Zugriffspfade und Aufbewahrungsfristen. Definiere eine Allowlist technischer Felder: Request-ID, Modell- und Promptversion, Tokenzahl, Dauer, Fehlerklasse und minimierte Fallkategorie. Inhalte werden nur für einen begrenzten, begründeten Diagnosepfad mit eigener Zugriffskontrolle erfasst.

Löschkonzepte müssen Replikate, Backups und Eval-Kopien berücksichtigen. Preis: Weniger Rohdaten erschweren Debugging. Dafür braucht es reproduzierbare synthetische Fälle, strukturierte Fehlermetriken und einen kontrollierten Break-glass-Pfad statt permanenter Vollprotokollierung.

Telemetry-Sampling wird nach Risiko gestaltet. Fehlerpfade können mehr technische Metadaten brauchen, aber nicht automatisch mehr Inhalt. Ein kurzlebiger, genehmigter Diagnosemodus ist vom normalen Betrieb getrennt und erzeugt einen Audit-Eintrag. Nachteil: Seltene Fehler lassen sich nicht immer nachträglich rekonstruieren; dauerhafte Vollprotokollierung würde dagegen jeden Request zum zusätzlichen Datenbestand machen.

Grenzen der Pseudonymisierung

Namen durch Platzhalter zu ersetzen ist wirksam und richtig — aber es ist keine Anonymisierung. Ein Text bleibt oft identifizierend, auch ohne Namen: „Der Mitarbeiter aus dem Werk Süd, der letzte Woche wegen des Vorfalls an Anlage 3 angehört wurde“ benennt in einem Betrieb mit 40 Personen genau eine Person.

Automatische Erkennung personenbezogener Angaben ist selbst fehlerbehaftet und übersieht regelmäßig Angaben in Freitext, in Anhängen und in Kombinationen. Behandle Pseudonymisierung deshalb als Risikominderung, nicht als Statuswechsel, der eine Rechtsgrundlage entbehrlich macht.

Pseudonymisierung ersetzt direkte Kennungen durch einen Schlüssel oder Alias; die Daten bleiben personenbezogen, wenn eine Zuordnung mit Zusatzinformation möglich ist. Anonymisierung verlangt, dass eine Person unter vernünftigerweise einsetzbaren Mitteln nicht identifizierbar ist. Freitext enthält oft indirekte Merkmale, seltene Ereignisse und Kombinationen, die einfache Namensersetzung unterlaufen. Behaupte daher nicht „anonym“, nur weil offensichtliche Felder fehlen.

Warum die alten Reflexe nicht reichen

In klassischer Software sind Code und Daten getrennt: Ein Programm führt Anweisungen aus, Nutzereingaben sind Werte. Bei einem Sprachmodell existiert diese Trennung nicht. Der Systemprompt, die Nutzerfrage und ein aus einem Dokument geladener Absatz stehen im selben Kontext und sind für das Modell dieselbe Art von Text.

Daraus folgt die zentrale Eigenheit dieser Systeme: Jeder Inhalt, der in den Kontext gelangt, kann das Verhalten beeinflussen. Nicht weil das Modell schlecht gebaut wäre, sondern weil es keine Instanz gibt, die Anweisung von Inhalt unterscheidet.

Klassische Eingabevalidierung bleibt notwendig, reicht aber bei LLM-Systemen nicht aus. Natürliche Sprache kann zugleich fachliche Daten und Anweisungen enthalten. Ein Modell besitzt keine harte interne Trennlinie, die einen Dokumenttext automatisch zu passiven Daten macht. Deshalb liegen Kontrollen an mehreren Grenzen: vor dem Kontext, bei Tool-Auswahl, vor jeder Wirkung und am Ausgabekonsumenten.

Prompt Injection — direkt und indirekt

Direkte Injection ist der offensichtliche Fall: Ein Nutzer versucht, die Systemvorgaben zu überschreiben. Sie ist ärgerlich, aber im Wesentlichen ein Selbstbedienungsproblem — der Nutzer greift Grenzen an, die für ihn gelten.

Indirekte Injection ist der gefährliche Fall: Die Anweisung steckt in einem Inhalt, den das System selbst lädt — ein Ticketkommentar von außen, eine E-Mail, eine Webseite, ein PDF im Anhang, ein Repository-Kommentar. Der Angreifer spricht nicht mit dem System, er hinterlegt seine Anweisung dort, wo das System sie abholen wird.

Direkte Injection

Nutzer greift eigene Grenzen an — Schaden meist auf seine Rechte begrenzt

Indirekte Injection

Fremdinhalt steuert das System — Schaden im Umfang der Systemrechte

Gemeinsame Ursache

Kontext kennt keine Trennung von Anweisung und Inhalt

Indirekte Prompt Injection — Manipulative Anweisungen, die nicht direkt vom Nutzerprompt stammen, sondern etwa aus abgerufenen Webseiten, E-Mails, Dokumenten oder Tool-Ergebnissen in den Modellkontext gelangen.

Prompt Injection lässt sich nicht durch einen geheimen Systemprompt zuverlässig wegdefinieren. Greshake und Kollegen demonstrierten reale indirekte Angriffswege in LLM-integrierten Anwendungen. Behandle externe Inhalte als untrusted, reduziere verfügbare Tools und Daten, verlange Bestätigung für riskante Wirkung und prüfe Ausgaben. Nachteil: Filter können legitime Inhalte blockieren und menschliche Bestätigung erzeugt Reibung; keine einzelne Schicht ist vollständig.

Content-Filter sind ein Signal, keine Sicherheitsgrenze. Sie können bekannte Muster erkennen, aber Angreifer variieren Sprache, Kodierung und indirekte Träger. Umgekehrt erzeugen strenge Filter Fehlalarme bei legitimen Security-Dokumenten. Setze Filter vor allem zur Erkennung, Quarantäne oder Risikostufung ein und begrenze die tatsächliche Wirkung unabhängig. Preis: Defense in Depth betreibt mehrere Kontrollen; sie verhindert die falsche Annahme, ein Prompt- oder Filterupdate habe das Problem grundsätzlich gelöst.

Modellausgaben sind Nutzereingaben

Der zweite große Fehlgriff: die Antwort des Modells als vertrauenswürdig zu behandeln, weil sie aus dem eigenen System kommt. Sie ist Text, der von fremdem Text beeinflusst wurde — und wird sie ungeprüft weiterverarbeitet, gelten alle klassischen Injektionsklassen.

• Ausgabe als HTML rendern — Skript-Injektion, wenn nicht maskiert wird.
• Ausgabe als SQL, Shell-Befehl oder Dateipfad verwenden — dieselben Regeln wie bei jeder Nutzereingabe.
• Ausgabe als Konfiguration oder Code in eine Pipeline geben — braucht Prüfung und Freigabe, nicht Vertrauen.
• Vom Modell erzeugte Links und Bildadressen — potenzieller Abflusskanal für Daten aus dem Kontext.

Ein Modelloutput ist Eingabe für die nächste Komponente. Wird er als HTML, SQL, Shell, Pfad oder URL interpretiert, gelten dieselben Regeln wie für Nutzereingaben: kontextspezifisches Encoding, parametrisierte APIs, Allowlist und Sandbox beziehungsweise enges Tool. Ein generierter Text darf nicht durch eval, Shell-Konkatenation oder ungeprüftes innerHTML Wirkung erhalten.

Auch formal gültiges JSON kann schädlich sein. Ein Schema beweist nicht, dass user_id zum handelnden Nutzer gehört oder ein Betrag zulässig ist. Preis: Downstream-Validierung dupliziert scheinbar Modellwissen als harte Regeln. Genau diese Duplizierung ist beabsichtigt: Sicherheitsinvarianten gehören in deterministisch prüfbaren Code.

Grenzen gehören an die Rechte, nicht in den Prompt

Eine Anweisung im Systemprompt ist eine Bitte mit hoher Erfolgswahrscheinlichkeit — keine Zusicherung. Was der ausführende Dienst technisch darf, ist die tatsächliche Grenze. Diese beiden Sätze tragen den größten Teil der praktischen Sicherheitsarbeit an LLM-Systemen.

• Dienstkonten mit genau den nötigen Rechten, getrennt nach Anwendungsfall.
• Werkzeuge eng zuschneiden — die Werkzeuggrenze begrenzt den Schaden im schlimmsten Fall.
• Rechte des anfragenden Nutzers durchsetzen, nicht die des Dienstes; sonst wird der Assistent zum Umgehungsweg für Zugriffsbeschränkungen.
• Ausgehende Netzverbindungen begrenzen — Datenabfluss braucht einen Weg nach draußen.

Least Privilege begrenzt Funktionalität, Berechtigung und Autonomie getrennt. Ein lesender Assistent erhält keine Schreibmethode. Ein Ticket-Tool darf nur definierte Felder ändern. Die Ziel-API prüft die Identität und Ressource bei jedem Aufruf; der Prompt „nur eigene Tickets ändern“ ist keine Autorisierung. OWASP bezeichnet fehlende vollständige Vermittlung und übermäßige Rechte als Kerntreiber von Excessive Agency.

Der Nachteil enger Rechte ist mehr Tool- und Policy-Design. Ein universelles Admin-Tool ist schneller zu demonstrieren und viel schwerer sicher zu betreiben. Bevorzuge kleine Fähigkeiten, kurzlebige Tokens, mandantenspezifische Identitäten und serverseitige Prüfung. Ein Modellfehler wird dadurch zu einer abgelehnten Anfrage statt zu einem Vorfall.

Geheimnisse und Zugangsdaten

Zugangsdaten haben im Kontext nichts verloren. Sie werden übermittelt, protokolliert, in Testsets übernommen und tauchen in Antworten wieder auf. Ein Modell kann ein Geheimnis nicht „für sich behalten“ — es hat keinen Speicher, der von der Ausgabe getrennt wäre.

Die richtige Bauform: Das Modell erhält nie Zugangsdaten, sondern schlägt einen Werkzeugaufruf vor. Die Anwendung hält die Geheimnisse, authentifiziert sich selbst und gibt nur das Ergebnis zurück.

Geheimnisse gehören in einen Secret Store und werden vom Executor nur an das konkrete Ziel gebunden. Sie stehen weder im Systemprompt noch in Toolbeschreibungen, Chat-Historien oder Fehlermeldungen. Auch die Aufforderung „gib dieses Secret nie aus“ hilft nicht, wenn es bereits Teil des Kontextes ist. Redigiere Zielantworten und verhindere, dass Tokens in den nächsten Modellturn zurückfließen.

Im Check werden deshalb Datenfluss und Wirkungsgrenze gemeinsam bewertet; keine Promptformulierung ersetzt eine technische Zugriffskontrolle.

Ablehnung und Eskalation bleiben normale Ergebnisse, wenn eine sichere Verarbeitung nicht möglich ist.