PII-Filter für LLM-Pipelines: Personenbezogene Daten erkennen und maskieren

Ein Support-Ticket, ein Vertragsentwurf, ein Gesprächsprotokoll: Fast jeder Text, den ein Unternehmen durch ein Sprachmodell verarbeiten lässt, enthält personenbezogene Daten. Namen, Adressen, Telefonnummern, Kundennummern, gelegentlich auch sensiblere Angaben. Wer solche Texte ungefiltert an eine Modell-API schickt oder in Logs schreibt, verteilt diese Daten über Systeme, die dafür nie vorgesehen waren.

Ein PII-Filter setzt genau hier an: Er erkennt personenbezogene Daten, bevor sie die eigene Infrastruktur verlassen, und ersetzt sie durch Platzhalter. Das klingt nach einem überschaubaren Baustein, ist in der Praxis aber ein eigenes kleines System mit Erkennungslogik, Maskierungsstrategie und einem Rückweg für die Antwort. Und es ist ein System, dessen Grenzen man kennen sollte, bevor man sich auf datenschutzrechtliche Aussagen stützt.

Dieser Artikel zeigt, welche Erkennungsansätze es gibt, wie Maskierung und Pseudonymisierung mit Rückübersetzung funktionieren, warum deutschsprachige Formate besondere Aufmerksamkeit brauchen und wie man das Restrisiko ehrlich einordnet.

Wo personenbezogene Daten in die Pipeline gelangen

Die naheliegende Stelle ist der Prompt selbst: Nutzereingaben, hochgeladene Dokumente, Datensätze aus dem CRM. Weniger offensichtlich sind die Nebenwege. Retrieval-Systeme holen Dokumente aus Wissensdatenbanken, die nie auf personenbezogene Inhalte geprüft wurden. Tool-Aufrufe liefern Datenbankergebnisse zurück in den Kontext. Und die eigene Observability schreibt Prompts und Antworten in Logs, Traces und Analytics-Systeme, oft mit langen Aufbewahrungsfristen und breitem internem Zugriff.

Ein PII-Filter muss deshalb an allen Übergängen ansetzen, an denen Daten die kontrollierte Zone verlassen: vor dem API-Aufruf an den Modellanbieter, vor dem Schreiben in Logs und Traces und vor der Weitergabe an nachgelagerte Systeme. Wer nur den sichtbaren Prompt filtert, hat die halbe Pipeline offen gelassen.

Erkennungsansätze im Vergleich

Für die Erkennung haben sich drei Ansätze etabliert, die sich in Präzision, Aufwand und Kosten deutlich unterscheiden.

Ansatz	Stärken	Schwächen
Regex und Muster	Deterministisch, schnell, gut für strukturierte Daten wie IBAN, E-Mail, Telefonnummern	Erkennt keine Namen und keine kontextabhängigen Angaben
NER-Modelle	Erkennt Namen, Orte, Organisationen im Fließtext, lokal betreibbar	Braucht sprachspezifische Modelle, Fehler bei ungewöhnlichen Namen
LLM-basiert	Versteht Kontext, erkennt indirekte Identifizierung	Teurer, langsamer, und die Daten müssen dafür bereits an ein Modell

In der Praxis bewährt sich die Kombination: Regex für alles Strukturierte, ein NER-Modell für Namen und Orte im Fließtext. Der LLM-basierte Ansatz ist dann sinnvoll, wenn ein lokal oder in kontrollierter Umgebung betriebenes Modell die Vorfilterung übernimmt. Ein externes Modell zur PII-Erkennung zu nutzen, würde das Problem nur verschieben: Die Daten wären genau dort, wo sie nicht hin sollten.

Maskieren, pseudonymisieren, rückübersetzen

Die einfachste Form ist die Maskierung: Erkannte Stellen werden durch generische Platzhalter ersetzt, etwa PERSON oder ADRESSE. Das genügt für Logs und Analytics, zerstört aber oft die Aufgabe. Ein Modell, das ein Anschreiben formulieren oder Bezüge zwischen mehreren Personen auflösen soll, braucht unterscheidbare Referenzen.

Dafür gibt es die Pseudonymisierung mit Rückübersetzung. Jede erkannte Entität bekommt einen eindeutigen Platzhalter, etwa PERSON_1 und PERSON_2, und die Zuordnung wird in einer Mapping-Tabelle gespeichert, die die eigene Infrastruktur nie verlässt. Das Modell arbeitet mit den Platzhaltern, und bevor die Antwort beim Nutzer ankommt, ersetzt die Pipeline sie wieder durch die Originalwerte. Der Nutzer merkt davon nichts, der Modellanbieter sieht die Klardaten nicht.

Zwei Details entscheiden über die Qualität. Erstens Konsistenz: Derselbe Name muss im gesamten Kontext denselben Platzhalter bekommen, auch über mehrere Chat-Runden hinweg, sonst verliert das Modell den Faden. Zweitens die Lebensdauer der Mapping-Tabelle: Sie gehört an die Session gebunden und danach gelöscht, denn eine dauerhaft gespeicherte Zuordnungstabelle ist selbst ein schützenswerter Datenbestand.

Deutsche Namens-, Adress- und Aktenzeichenformate

Viele verfügbare Erkennungswerkzeuge sind auf englischsprachige Daten trainiert und ausgelegt. Im deutschsprachigen Raum fallen sie an vorhersehbaren Stellen durch. Zusammengesetzte Nachnamen, Namenszusätze und Namen mit slawischer, türkischer oder arabischer Herkunft werden von schwachen NER-Modellen häufiger übersehen als gängige englische Namen. Hier lohnt es sich, gezielt Testfälle mit realistischen Namensverteilungen aufzubauen, statt sich auf die Herstellerangaben zu verlassen.

Bei Adressen hilft die Struktur: Straße mit Hausnummer, Postleitzahl und Ort folgen erkennbaren Mustern, die sich mit Regex solide abdecken lassen, wenn man österreichische und deutsche Varianten berücksichtigt. Schwieriger sind branchenspezifische Kennungen. Gerichtliche Aktenzeichen, Sozialversicherungsnummern, Personalnummern und interne Kundennummern folgen jeweils eigenen Formaten, die kein Standardwerkzeug kennt. Wer in einem Umfeld mit solchen Kennungen arbeitet, etwa in Kanzleien oder im Personalwesen, muss diese Muster selbst definieren und pflegen. Das ist unspektakuläre Arbeit, aber genau hier entstehen sonst die Lücken.

Restrisiko ehrlich bewerten

Kein Filter erkennt alles. Es bleiben drei Klassen von Restrisiko. Erstens die schlichte Nichterkennung: ungewöhnliche Schreibweisen, Tippfehler, Namen, die auch gewöhnliche Wörter sind. Zweitens die indirekte Identifizierbarkeit: Auch ein Text ohne Namen kann eine Person eindeutig beschreiben, wenn Rolle, Ort und Umstände zusammen genügen. Ein Filter, der Entitäten ersetzt, ändert daran wenig. Drittens der Ausgang der Pipeline: Modelle können personenbezogene Angaben aus dem Kontext umformulieren oder aus Trainingswissen ergänzen, weshalb auch die Antwort geprüft gehört, nicht nur die Eingabe.

Daraus folgt eine nüchterne Einordnung: Ein PII-Filter ist eine wirksame technische Maßnahme zur Datenminimierung, aber kein Freifahrtschein. Die datenschutzrechtliche Bewertung, welche Daten überhaupt verarbeitet werden dürfen und auf welcher Grundlage, ersetzt er nicht. Er gehört als eine Schicht in ein Gesamtkonzept aus Vertragsgestaltung mit dem Anbieter, sinnvoller Standortwahl der Verarbeitung, Logging-Disziplin und klaren Löschfristen. Wer den Filter zusätzlich mit Metriken betreibt, also Erkennungsraten auf einem eigenen Testkorpus misst und Fehlfälle nachpflegt, kann sein Restrisiko wenigstens beziffern statt nur hoffen.

Fazit

Personenbezogene Daten gelangen über mehr Wege in eine LLM-Pipeline, als man beim ersten Entwurf sieht: Prompts, Retrieval, Tool-Ergebnisse, Logs. Ein guter PII-Filter kombiniert Regex für strukturierte Daten mit NER für Namen, arbeitet mit konsistenten Platzhaltern und einer sessiongebundenen Rückübersetzung und sitzt an beiden Enden der Pipeline. Für den deutschsprachigen Raum kommt man um eigene Muster für Namen, Adressen und Kennungen nicht herum. Und bei aller Technik bleibt ein messbares, aber nicht wegdiskutierbares Restrisiko. Wer das kennt und dokumentiert, hat eine belastbare Grundlage. Wer es ignoriert, hat nur ein gutes Gefühl.