# Pseudonymisierung vor LLM — was DSGVO-rechtlich wirklich zählt > Warum Pseudonymisierung nicht gleich Anonymisierung ist, was vor LLM-Calls tatsächlich rechtlich greift und welche technischen Patterns 2026 funktionieren. Quelle: https://www.krynexlabs.de/wissen/pseudonymisierung-vor-llm/ Stand: 2026-05-16 Anbieter: Krynex Labs UG (haftungsbeschränkt) i. G., Chemnitz · https://www.krynexlabs.de --- Technik & Architektur # 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 Sie spezielle Entitäten erkennen müssen (Patientennummern, interne Auftrags-IDs, branchen-spezifische Identifier), trainieren Sie 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.** Nehmen Sie 200 echte Beispiel-Inputs, lassen Sie die Detection laufen, prüfen Sie manuell. Recall (wie viel PII wurde erkannt) ist wichtiger als Precision (wie viele False-Positives). Im Zweifel pseudonymisieren Sie zu viel statt zu wenig. ### 2\. Pseudonymisierungs-Strategie **Token-Replacement.** “Max Mustermann” wird zu “\[PERSON\_001\]”, “[info@firma.de](mailto: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): Generieren Sie 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 legen Sie 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…”), müssen Sie sie rückübersetzen, bevor Sie sie an den Nutzer ausgeben. Die **Mapping-Tabelle** lebt nur in Ihrem 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 Sie gleichzeitig Hunderte Anfragen über ähnliche pseudonymisierte Personen schicken, 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 Ihren 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 brauchen Sie 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 Sie heute nicht tun sollten 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 Sie gar nicht maskieren. 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. ## Dazu bei Krynex Labs Leistung KI-Souveränitäts-Check → https://www.krynexlabs.de/services/ki-souveraenitaet/ Wissen DSGVO-konforme LLMs → https://www.krynexlabs.de/wissen/dsgvo-konforme-llms-2026/ Workshop Workshop On-Premise-LLM → https://www.krynexlabs.de/workshops/on-premise-llm/ ## Passend dazu Insights Wie wir Agent-Evals bauen, die Production-Bugs vorhersagen → https://www.krynexlabs.de/blog/agent-evals/ Insights Ein Prompt, alle Agenten: Was der AgentCorruption-Fall bei AWS über die Standardrechte von KI-Agenten lehrt → https://www.krynexlabs.de/blog/agentcorruption-aws-agentcore-standardrolle-ki-agenten/ Insights Ihr KI-Agent kann jetzt handeln. Wer sagt Nein? → https://www.krynexlabs.de/blog/agenten-governance-wer-stoppt-die-ki/ ## Konkrete Frage zu eurem Setup? Ein 30-Minuten-Erstgespräch klärt meistens schon, ob euer aktueller AI-Stack hält oder wo nachzuarbeiten ist. Kostenlos, ohne Verkaufsdruck. [Erstgespräch buchen](https://www.krynexlabs.de/kontakt/)