Pseudonymisierung vor LLM-Calls — reicht das wirklich?

Die ehrliche Kurzantwort

Zwei Begriffe, die oft verwechselt werden:

Pseudonymisierung (Art. 4 Nr. 5 DSGVO): Daten werden so verarbeitet, dass sie ohne Zusatzinformationen nicht mehr einer Person zugeordnet werden können. Aber: Pseudonyme Daten bleiben personenbezogene Daten — die Zusatz-Info (Schlüssel) liegt eben woanders. Alle DSGVO-Pflichten gelten weiter.

Anonymisierung (Erwägungsgrund 26 DSGVO): Daten werden so verändert, dass keine Identifizierung mehr möglich ist — auch nicht mit Zusatzinformationen oder Inferenz. Anonymisierte Daten fallen aus der DSGVO heraus.

Bei LLM-Inputs ist echte Anonymisierung praktisch sehr schwierig. Ein LLM zieht Inferenz aus Kontext — selbst nach Entfernen von Name und E-Mail-Adresse kann der Output über Branche, Region, Spezialwissen und Datums-Kontext eine eindeutige Re-Identifikation ermöglichen.

Konsequenz: Pseudonymisierung ist ein wichtiger Schutzbaustein, aber kein DSGVO-Freischuss. Sie kann das Risiko-Niveau senken, hebt aber die Pflichten (AVV, DSFA, Transparenz) nicht auf.

Wo Pseudonymisierung trotzdem viel hilft

Pseudonymisierung vor LLM-Call ist sinnvoll, weil sie zwei reale Probleme mildert:

Datenpannen-Schaden. Wenn der Cloud-Anbieter gehackt wird oder ein Mitarbeiter versehentlich Logs leakt, sind pseudonymisierte Daten weit weniger gefährlich als Klartext. Schadens-Reduktion ist eine zentrale Schutzkategorie nach Art. 32 DSGVO.

Training-Daten-Risiko. Auch wenn der AVV einen Trainings-Opt-Out garantiert, ist es schöner, wenn die Daten selbst bei einem Anbieter-Pannenfall keine PII enthalten. Defense in Depth.

Mitarbeiter-Sicht. Wer als Mitarbeiter sensible Mails an ein LLM schickt, fühlt sich auch persönlich besser, wenn Klar-PII vorab maskiert wurde. Das fördert produktive AI-Nutzung statt heimliches Workaround-Verhalten.

Was 2026 als Pseudonymisierung-Pipeline funktioniert

Drei Komponenten:

1. PII-Detection vor LLM-Call

Microsoft Presidio ist das verbreitetste Open-Source-Tool 2026. Erkennt ~50 Entitäts-Typen (Person, E-Mail, Telefon, IBAN, Adresse, IP, etc.), deutsch-tauglich nach Konfiguration. Tagesarbeit, kein Wochen-Projekt.

spaCy + Custom-NER. Wenn du spezielle Entitäten erkennen musst (Patientennummern, interne Auftrags-IDs, branchen-spezifische Identifier), trainierst du ein eigenes NER-Modell auf 200–500 Beispielen.

Regex-Layer. Für deterministisch erkennbare Patterns (IBAN, Kreditkartennummern, Personal-Nummern) sind Regex schneller und treffsicherer als ML-Modelle. Sollte als erste Schicht laufen.

Eval-Set. Nimm 200 echte Beispiel-Inputs, lass die Detection laufen, prüfe manuell. Recall (wie viel PII wurde erkannt) ist wichtiger als Precision (wie viele False-Positives). Im Zweifel pseudonymisierst du zu viel statt zu wenig.

2. Pseudonymisierungs-Strategie

Token-Replacement. “Max Mustermann” wird zu “[PERSON_001]”, “info@firma.de” zu “[EMAIL_001]”. Konsistent über die ganze Session — wenn ein Name dreimal vorkommt, wird er dreimal mit dem gleichen Token ersetzt. Sonst verliert das LLM Kohärenz.

Format-Preserving Pseudonymization. Für strukturierte Daten (Kundennummern, Bestellnummern): generiere konsistente, aber fiktive Werte gleichen Formats. “K-12345” → “K-AB7DC”. Vorteil: das LLM kann mit dem Format normal arbeiten, ohne dass die echte Nummer leakt.

Kontext-Reduktion. Manchmal ist die beste Strategie, einen Teil der Eingabe ganz wegzulassen. Wenn das LLM nicht wissen muss, dass die Patientin aus Chemnitz kommt und im Quartal 3/2025 behandelt wurde, dann leg diese Felder gar nicht erst rein.

3. Re-Mapping nach LLM-Antwort

Wenn die LLM-Antwort die Pseudonyme enthält (“[PERSON_001] hat angefragt, ob…”), musst du sie rückübersetzen, bevor du sie an den Nutzer ausgibst. Die Mapping-Tabelle lebt nur in deinem Kontext-Speicher (z. B. Session-Cache, maximal Stunden), nie beim Anbieter, nie in den LLM-Calls selbst.

Wo Pseudonymisierung nichts rettet

Strukturelle Inferenz. “Wie behandle ich Patient X mit Beschwerde Y im Kontext Z?” Selbst nach Pseudonymisierung des Namens — wenn das Krankheitsbild extrem spezifisch ist und es deutschlandweit zehn Fälle gibt, ist die Person identifizierbar.

Cluster-Inferenz. Wenn du gleichzeitig Hunderte Anfragen über ähnliche pseudonymisierte Personen schickst, kann der Anbieter (oder ein Lauscher in der Pipeline) Cluster-Muster erkennen, die zur Identifikation führen.

Re-Identifikation aus Output. LLMs können in seltenen Fällen aus Trainings-Daten Klar-PII ausspucken, die zufällig mit deinen pseudonymisierten Daten zusammenpasst. Selten, aber dokumentiert.

Art.-9-Daten. Bei besonders sensiblen Daten (Gesundheit, Religion, Gewerkschaftszugehörigkeit) ist Pseudonymisierung allein niemals der ausreichende Schutz. Hier brauchst du zusätzlich Rechtsgrundlage nach Art. 9 Abs. 2 und meist on-prem-Verarbeitung.

Stand der Anonymisierung 2026

Echte Anonymisierung (im DSGVO-Sinn, also rückführungs-sicher) ist bei LLM-relevanten Daten praktisch nur in zwei Wegen erreichbar:

Differential Privacy. Mathematisch fundierte Methode mit quantifizierbarem Re-Identifikations-Risiko. Wird in der Forschung und in einzelnen Unternehmenskontexten eingesetzt (Apple, Google Statistiken). Für deutsche Mittelstands-LLM-Use-Cases meist Overkill.

Synthetische Daten. Echte Daten werden durch statistische Ersatzdaten ersetzt, die dieselben Verteilungen haben. Funktioniert gut für strukturierte Datenbanken, weniger gut für freitext-LLM-Inputs.

Für die meisten Mittelstands-Szenarien gilt: Pseudonymisierung ist realistisch erreichbar, Anonymisierung ist eher nicht erreichbar. Die DSGVO-Pflichten bleiben — Pseudonymisierung ist ein Risiko-Reduzierer, kein Befreiungs-Schein.

Pragmatische Empfehlung

Drei Schutzschichten kombinieren:

1. PII-Detection + Pseudonymisierung vor jedem Cloud-LLM-Call. Tools: Presidio + spaCy + Regex-Layer.
2. AVV + EU-Region mit dem Anbieter. Beides bleibt nötig auch nach Pseudonymisierung.
3. Klassifizierungs-Routing. Grüne und gelbe Daten ins Cloud-LLM (pseudonymisiert), rote Daten auf on-prem-LLM (auch dort pseudonymisiert, für Defense-in-Depth).

Was vermieden werden sollte:

• “Wir pseudonymisieren, also brauchen wir keinen AVV mehr.” — Falsch.
• “Wir pseudonymisieren, also brauchen wir keine DSFA mehr.” — Falsch.
• “Wir pseudonymisieren, also dürfen Art.-9-Daten ins Cloud-LLM.” — Falsch.

Pseudonymisierung senkt das Schadenspotenzial im Pannenfall und ist Pflicht-Bestandteil eines guten Schutzkonzepts. Sie ändert nichts an Rechtsgrundlage, Anbieter-Pflichten und Aufsichtsbehörden-Erwartung.

Was du heute nicht tun solltest

Keine “Anonymisierung-Lösung” als Marketing-Layer verkaufen, die nur Namen ersetzt. Keinen Use-Case “wegen Pseudonymisierung” für DSGVO-frei erklären. Und keine PII-Detection ohne Eval-Set live schalten — wenn die Detection schlecht eingestellt ist, geht mehr Klar-PII durch als wenn du gar nicht maskierst.

Pragmatischer Einstieg: Presidio aufsetzen, 200 reale Inputs durchspielen, Recall messen, Custom-NER für branchenspezifische Entitäten ergänzen. Eine Woche Arbeit, danach läuft die Pipeline.