PII in LLMs

PII in LLMs (Personally Identifiable Information, also personenbezogene Daten) bezeichnet Namen, E-Mails, Adressen oder Kundennummern, die in Sprachmodell-Systemen (Large Language Models, LLM) auftauchen: in der Eingabe an das Modell (Prompt), in dessen Antwort, in Protokolldateien (Logs), in Zwischenspeichern (Caches), in Suchindizes über eingebettete Textbausteine (Vector-Stores) oder in den Trainingsdaten. An jeder dieser Stellen können die Daten unbeabsichtigt weiterlaufen: das Modell kann sie später wiedergeben (Memorization), sie können ungewollt an Dritte gelangen (Data Leakage) oder in Systeme fließen, die nie dafür freigegeben waren. Der Begriff umfasst zwei Ebenen: die Datenklasse selbst und die Schutz-Mechanik davor, also Ersatz durch Platzhalter (Pseudonymisierung), Erkenner-Werkzeuge wie Microsoft Presidio, Filter auf den Antworten, DSGVO-konforme Aufbewahrung und separat gesicherte Zuordnungs-Tabellen (Token-Maps).

Was ist PII in LLMs?

PII in LLMs ist eine eigene Datenklasse auf Modell- und Verarbeitungs-Ebene. Sie taucht an fünf Stellen im Ablauf eines Sprachmodell-Systems auf und braucht an jeder Stelle eine eigene Kontrolle: erstens im Prompt, also der Eingabe, die die Anwendung an den Anbieter (Provider) des Modells schickt; zweitens in der Modell-Antwort, wenn personenbezogene Daten aus dem Kontext oder aus angehängten Textausschnitten einer Wissensdatenbank (Retrieval-Augmented Generation, RAG) zurückkommen; drittens in den Protokolldateien (Logs) der eigenen Anwendung und des Anbieters, die Ein- und Ausgabe mitschreiben; viertens in Zwischenspeichern (Prompt-Caches) und in Suchindizes, die Textbausteine als mathematische Vektoren ablegen (Vector-Stores mit Embeddings); fünftens in den Trainingsdaten des Anbieters, wenn die eigenen Eingaben in die Weiterentwicklung des Modells einfließen.

Die Datenklassen folgen der DSGVO-Systematik. Direkte Identifikatoren sind Name, E-Mail, Telefonnummer, Adresse, Kunden- und Mitarbeiter-IDs. Indirekte Identifikatoren umfassen IP-Adressen, Geräte-IDs, Standortdaten und Kontodaten, die in Kombination eine Person identifizierbar machen. Besondere Kategorien nach Art. 9 DSGVO (Gesundheit, Religion, ethnische Herkunft, biometrische Daten) tragen verschärfte Anforderungen an Rechtsgrundlage, Zweckbindung und Sicherheitsmaßnahmen.

Zwei Risiko-Mechaniken prägen den Begriff. Memorization bezeichnet die Fähigkeit eines Large Language Models, im Training gesehene Personendaten in späteren Antworten zu reproduzieren; die Forschung um Nicholas Carlini hat den Effekt für GPT-2, GPT-3 und Nachfolge-Modelle systematisch belegt. Data Leakage bezeichnet den ungewollten Übergang personenbezogener Prompts in Provider-Logs, Feintuning-Sets oder Nachbar-Sessions ohne Trainings-Beteiligung. Beide Mechaniken adressieren unterschiedliche Angriffs-Flächen und brauchen unterschiedliche Kontroll-Layer.

Die typische Kontroll-Mechanik vor dem LLM ist eine Pseudonymisierungs-Schicht. Ein Erkenner (Named Entity Recognition, Regex, Domänen-Wörterbücher) findet PII-Spans im Prompt; die Werte werden durch Surrogate ersetzt (deterministisch oder zufällig); eine Token-Map merkt sich die Zuordnung in einer getrennt geschützten Senke; der Provider sieht nur die Surrogate; die Antwort wird über die Token-Map re-mapped, bevor sie den Nutzer erreicht. Diese Schicht sitzt typischerweise in einem LLM-Gateway und wird von OWASP LLM Top 10 (LLM02 Sensitive Information Disclosure) sowie DSGVO Art. 4 Nr. 5, Art. 25 und Art. 32 flankiert.

Abgrenzung zu klassischem PII-Schutz und Nachbar-Begriffen

Die Begriffe rund um PII, KI und Datenschutz werden im Alltag vermischt, obwohl sie unterschiedliche Ebenen adressieren. Die Trennung entscheidet darüber, welcher Kontroll-Layer greift.

Klassischer PII-Schutz operiert auf Tabellen und Spalten. Eine maskierte Spalte im Kundenstamm kann korrekt gesetzt sein, während unmaskierter Freitext aus einem Support-Ticket, einer Chat-Nachricht oder einer E-Mail trotzdem im Prompt landet. Die zwei Ebenen ergänzen sich; ein Modell-Workflow ohne Pipeline-Layer bleibt trotz sauberem Datenbank-Layer angreifbar.

Data Classification ist die Vorstufe. Sie definiert Klassifizierungs-Schemata (öffentlich, intern, vertraulich, streng vertraulich) und PII-Kategorien und markiert Daten im Katalog. Die Klassifizierung liefert den Input, gegen den PII-Erkenner im LLM-Gateway und Egress-Filter in Agent-Systemen matchen; ohne diese Markierung fehlt die Grundlage für automatische Kontrollen.

Data Exfiltration via Agents ist die Nachbar-Klasse auf der Action-Ebene. Sie beschreibt den Abfluss sensibler Daten über tool-nutzende Agenten und nutzt PII-Klassifikatoren als einen von mehreren Defense-Layern. Der Oberbegriff PII in LLMs deckt darüber hinaus die Modell-Ebene (Memorization, Training-Data-Leakage) und alle statischen Ablage-Punkte (Log, Cache, Vector-Store) ab.

Column Masking ist die spezifische Datenspeicher-Technik, die PII in Tabellen zur Abfrage-Zeit maskiert. Sie schützt die Datenbank-Schicht, greift aber nicht in den Prompt-Pfad zum LLM ein. Memorization und Training-Data-Leakage sind die Teilmenge, in der das Modell im Training gesehene Personendaten reproduziert; der Oberbegriff PII in LLMs umfasst zusätzlich die dynamischen Auftrittsstellen (Prompt, Response, Log, Cache).

Beispiel: Pseudonymisierungs-Schicht im LLM-Gateway

Ein interner Support-Assistent bekommt Kundenanfragen als freien Text weitergeleitet und fragt ein externes LLM nach einem Antwort-Entwurf. Ohne Pseudonymisierung landen Namen, Kunden-IDs, Vertragsnummern, Adressen und in Gesundheitsfällen sogar Krankheitsverläufe im Klartext beim Provider, in dessen Logs und im Prompt-Cache. Die Freigabe durch den Datenschutzbeauftragten scheitert an der fehlenden DSFA-Antwort; der Use-Case bleibt zwei Wochen vor Go-Live stehen.

Mit einer Pseudonymisierungs-Schicht im LLM-Gateway greift derselbe Workflow. Microsoft Presidio erkennt PII-Spans über NER-Modelle, Regex-Muster (IBAN, Telefon, E-Mail) und Domänen-Wörterbücher für firmenspezifische Identifikatoren wie Kundennummern und Vertrags-IDs. Die erkannten Werte werden durch deterministische Surrogate ersetzt („Kunde Token-A41" statt „Andrea Sommer"), damit das Modell mehrere Erwähnungen derselben Person korrekt verknüpft. Eine getrennt geschützte Token-Map speichert die Zuordnung. Der Provider sieht nur pseudonymisierten Text. Die Antwort wird über die Token-Map re-mapped, bevor der Nutzer sie liest. Ein separates Audit-Log dokumentiert jeden Aufruf mit Input-Hash, Output-Hash und Zeitstempel für DSFA und Aufsichtsbehörde.