RHETRA / Guides / PII & LLMs

PII-Leaks in LLMs stoppen

PII leckt im Moment des Prompts in LLMs: Ein Mitarbeiter fügt einen Kundendatensatz, einen Vertrag, ein Logfile in ein Chat-Fenster ein — und die Daten liegen auf fremder Infrastruktur, bevor irgendeine Netzwerkkontrolle sie sieht. Richtlinien verhindern das nicht, und Netzwerk-DLP kann es meist nicht. Was funktioniert: die Erkennung dorthin verlegen, wo das Leck entsteht — auf das Gerät, vor dem Absenden, mit einem Scanner, der im Zweifel blockt.

1 · Schatten-KI: das reale Bedrohungsmodell

Schatten-KI (Shadow AI) heißt: Mitarbeiter nutzen KI-Tools — öffentliche Chatbots, Browser-Extensions, Code-Assistenten — außerhalb der von der IT freigegebenen Kanäle. Sie tun es, weil es funktioniert. Verbote erzeugen Umgehungen, keine Compliance: private Handys, persönliche Accounts, unbeobachtete Browser. Das realistische Bedrohungsmodell ist deshalb nicht der böswillige Insider, sondern der hilfsbereite Mitarbeiter im falschen Kanal: Kunden-PII im Übersetzungs-Prompt, Quellcode mit eingebetteten API-Keys in der Debugging-Anfrage, Finanzzahlen im „Fass das zusammen"-Paste.

Was das schlimmer macht als klassische Schatten-IT: Die eingefügten Daten liegen nicht in einer nicht freigegebenen App, die sich später auditieren lässt — sie landen in einem Drittmodell, wo Speicherung, Logging und Trainingsnutzung von Bedingungen, Tarif und Konfiguration des Anbieters in genau diesem Moment abhängen.

2 · Warum die klassischen Kontrollen es verfehlen

• Policy-Dokumente regeln Absichten, keine Tastenanschläge. Niemand liest die KI-Richtlinie erneut, bevor er einfügt.
• Netzwerk-DLP steht vor TLS-verschlüsseltem Traffic; Inspektion heißt, Verschlüsselung im großen Stil aufzubrechen — und selbst dann schlagen Freitext-Prompts starre Muster-Regeln: zu viele False Positives, um streng zu bleiben, zu viele Treffer daneben, um ihr zu vertrauen.
• Anbieterseitige Kontrollen (Enterprise-Verträge, Zero-Retention-Tarife) zählen — aber nur für den freigegebenen Kanal. Schatten-KI ist per Definition der andere.
• Timing: Jede Kontrolle, die greift, nachdem der Prompt das Gerät verlassen hat, ist Forensik, keine Prävention.

3 · On-Device-Erkennung: die Architektur, die funktioniert

Der einzige Punkt, an dem Prävention noch möglich ist, ist das Gerät selbst — zwischen Tippen und Absenden. Daraus folgt eine bestimmte Architektur:

• Lokales Scannen: Der Detektor läuft im Browser oder Endpunkt und prüft den Prompt vor dem Absenden — Kreditkarten, IBANs, Ausweisnummern, API-Keys, Namen, Adressen.
• Zero-Egress by design: Der Scanner selbst darf nicht nach Hause telefonieren. Ein PII-Scanner, der Text zur Klassifikation hochlädt, ist ein zweites Leck, keine Kontrolle. Die Erkennung bleibt auf dem Gerät; nichts geht an den Hersteller — RHETRAs Shield ist exakt so gebaut.
• Maskieren statt nur warnen: Den erkannten Wert zu ersetzen (⟨IBAN⟩, ⟨CARD⟩) hält den Mitarbeiter produktiv — der Prompt funktioniert weiter, die Daten bleiben im Haus. Nur-Warnen-Tools trainieren das Wegklicken.

4 · Fail-safe vs. fail-open — das entscheidende Detail

Jeder Scanner trifft irgendwann auf Input, den er nicht verarbeiten kann. Die Designfrage ist, was dann passiert. Fail-open — im Fehlerfall offen — wertet Scanner-Versagen als „kein PII gefunden“ und lässt den Prompt durch: Jeder Bug wird zum stillen Leck. Fail-safe — im Fehlerfall sicher — blockt, wenn der Scanner kein Urteil liefern kann: Jeder Bug wird zur sichtbaren Unannehmlichkeit. Bei personenbezogenen Daten ist die Wahl keine Geschmacksfrage: Unter der DSGVO haften Sie für das Leck, nicht für die Unannehmlichkeit. Stellen Sie jedem Anbieter genau diese eine Frage; die Antwort sortiert den Markt.

5 · Vom einzelnen Browser zur ganzen Organisation

On-Device-Schutz sichert den Endpunkt. Die organisatorische Ebene ist ein Enforcement-Gateway vor jedem freigegebenen KI-Aufruf: Es klassifiziert jede Anfrage, wendet BLOCK / SANITIZE / ALLOW zentral an, routet sensible Workloads auf lokale Modelle und signiert jede Entscheidung in einen Audit-Trail — womit nebenbei die Protokollierungspflichten des EU AI Act erfüllt werden. Die vollständige Architektur — inklusive des Nachweises, wo Ihre KI tatsächlich läuft — steht im Pillar-Guide: Was ist Sovereign AI?

Die Endpunkt-Ebene können Sie sofort testen: Die OSI Shield Community Edition ist kostenlos — installieren, eine Test-Kreditkartennummer in einen beliebigen Chatbot einfügen und zusehen, wie sie nie ankommt.