> Wo du PII in LLM-Pipelines schwärzt, umkehrbare Tokens vs. Maskierung, Presidio und Cloud-DLP, Lücken bei Deutsch und Ungarisch, DSGVO zu Pseudonymisierung, Tests.
>
> Web page: https://balazscsorba.com/de/blog/pii-redaction-llm-pipelines · Language: Deutsch · Also available in: [English](https://balazscsorba.com/blog/pii-redaction-llm-pipelines.md) · [Magyar](https://balazscsorba.com/hu/blog/pii-redaction-llm-pipelines.md)
> Author: Balázs Csorba · Published: 2026-10-02 · Keywords: PII redaction LLM, how to remove PII before sending to LLM, Microsoft Presidio tutorial, PII detection German Hungarian, pseudonymisation vs anonymisation GDPR, reversible tokenization LLM prompts, redact PII in logs and traces, LLM data masking, PII guardrail LiteLLM, test PII detection recall

[Blog](https://balazscsorba.com/de/blog)/Sicherheit & Compliance

# PII-Schwärzung in LLM-Pipelines: wo, wie und was die DSGVO dazu sagt

Wo du PII in LLM-Pipelines schwärzt, umkehrbare Tokens vs. Maskierung, Presidio und Cloud-DLP, Lücken bei Deutsch und Ungarisch, DSGVO zu Pseudonymisierung, Tests.

[Balázs Csorba](https://balazscsorba.com/de/about)·2\. Oktober 2026·12 Min. Lesezeit

-   PII redaction
-   GDPR
-   Microsoft Presidio
-   LLM security
-   Pseudonymisation

![Diagramm: Nutzereingaben durchlaufen vor dem LLM ein Schwärzungs-Gate, ein Token-Tresor stellt nach der Ausgabeprüfung die echten Werte wieder her, Logs und Traces sehen nur geschwärzten Text.](https://balazscsorba.com/images/blog/pii-redaction-llm-pipelines/cover.webp?v=a2981a446d)

## Das Wichtigste in Kürze

-   Schwärze an jeder Grenze, nicht nur einmal: Ingest, Prompt, Ausgabe, Logs und Traces lecken jeweils anders, und Logs und Traces werden am häufigsten vergessen.
-   Umkehrbare Tokens (ein Tresor, der Platzhalter auf echte Werte abbildet) erhalten die Nützlichkeit der Antworten, aber der Tresor selbst wird zum Speicher für personenbezogene Daten und braucht Schlüssel, Zugriffskontrolle und kurze Aufbewahrung.
-   Kein Detektor findet alles. Presidio sagt das selbst, und die Abdeckung für Deutsch ist deutlich besser als für Ungarisch. Miss den Recall pro Sprache auf deinen eigenen Daten, statt einer Herstellerliste zu vertrauen.
-   Nach der DSGVO bleiben pseudonymisierte Daten für den Inhaber des Schlüssels personenbezogen. Das EuGH-Urteil vom 4. September 2025 ergänzt: Für einen Empfänger ohne Möglichkeit zur Re-Identifizierung können sie es nicht sein, aber das muss belegt und nicht angenommen werden.
-   Sieh Schwärzung als Defense in Depth neben Verträgen, EU-Hosting und Zugriffskontrolle, und teste sie wie jedes andere Feature: mit einem gelabelten mehrsprachigen Datensatz, Recall-Zielen und einem Regressions-Gate in der CI.

Auf dieser Seite

1.  [Wo schwärzen: fünf Grenzen](https://balazscsorba.com/#where-to-redact)
2.  [Schwärzen, Maskieren, Tokenisieren: die Technik wählen](https://balazscsorba.com/#techniques)
3.  [Umkehrbare Tokenisierung: nützlich, mit Tresor](https://balazscsorba.com/#reversible-tokens)
4.  [Tools: Presidio, Cloud-Dienste und NER-Modelle](https://balazscsorba.com/#tools)
5.  [Deutsch und Ungarisch: die Abdeckungslücke](https://balazscsorba.com/#german-hungarian)
6.  [False Negatives: der Fehler, der zählt](https://balazscsorba.com/#false-negatives)
7.  [Die DSGVO-Sicht: pseudonymisiert ist nicht anonym](https://balazscsorba.com/#gdpr)
8.  [Schwärzung wie ein Feature testen](https://balazscsorba.com/#testing)
9.  [Was ich zuerst tun würde](https://balazscsorba.com/#first-steps)
10.  [Quellen](https://balazscsorba.com/#sources)

Die meisten Teams bauen PII-Handling in ein LLM-Feature so ein: ein Regex für E-Mail-Adressen vor dem API-Aufruf und eine Notiz im Backlog. Das funktioniert in der Demo und scheitert in Produktion, denn personenbezogene Daten kommen nicht an einer einzigen Stelle in ein LLM-System. Sie stecken in der Nutzernachricht, in den Dokumenten, die du indexierst, in den Tool-Ergebnissen, die ein Agent liest, und werden dann in die Modellausgabe, das Anwendungslog, das Trace-Backend und das Evaluierungs-Set kopiert.

Dieser Artikel zeigt, wie ich die Schwärzung für ein europäisches Unternehmen entwerfen würde: wo die Gates sitzen, welche Technik an welcher Stelle passt, was die Tools können und nicht können (auch für Deutsch und Ungarisch), wie man die aktuelle DSGVO-Lage zu pseudonymisierten Daten liest und wie man das Ganze testet. Das ist Engineering-Rat, keine Rechtsberatung, und ergänzt die Hosting- und Vertragsfragen in [DSGVO und LLM-APIs: EU-Datenresidenz](https://balazscsorba.com/de/blog/gdpr-llm-api-eu-data-residency).

## Wo schwärzen: fünf Grenzen

Sieh die Pipeline als fünf Grenzen, an denen Text in ein System übergeht, das du nicht vollständig kontrollierst oder das länger lebt als die Anfrage. Jede braucht eine eigene Entscheidung.

Das Modell sieht nur Platzhalter. Der Tresor stellt die echten Werte für den Nutzer wieder her und verlässt nie deine Vertrauensgrenze; Logs und Traces sehen nie echte Werte.

-   **Ingest.** Schwärze Dokumente vor dem Chunking und Embedding. Ein Vektorspeicher voller roher personenbezogener Daten ist schwer zu bereinigen und vergrößert jedes spätere Leck. Entscheide pro Quelle, ob du den echten Wert überhaupt brauchst. Die Abwägungen beim Indexieren stehen in [RAG-Pipeline: Chunking, Hybrid-Suche, Reranking](https://balazscsorba.com/de/blog/rag-pipeline-chunking-hybrid-search-reranking).
-   **Prompt.** Nutzernachricht, abgerufener Kontext und Tool-Ergebnisse laufen kurz vor dem API-Aufruf durch das Gate. Das ist die wichtigste Grenze, weil sie bestimmt, was der Provider erhält.
-   **Ausgabe.** Das Modell kann personenbezogene Daten wiederholen, ableiten oder erfinden. Prüfe die Antwort, bevor sie angezeigt oder gespeichert wird, und stelle Tokens nur dort wieder her, wo der Betrachter den echten Wert sehen darf.
-   **Logs.** Anwendungs- und Gateway-Logs sind das klassische Leck. Logge den geschwärzten Prompt oder einen Hash samt Größe, nie die rohe Nachricht.
-   **Traces und Evals.** Observability-Tools speichern Prompts und Completions vollständig, das ist ihr Zweck. Langfuse bietet zum Beispiel Masking-Hooks, die vor dem Export laufen, und reine OpenTelemetry-Setups können in der Anwendung oder in einem Collector maskieren. Evaluierungsdaten aus Produktionsverkehr erben alles, was in den Traces steht.

Ein Gateway wie LiteLLM kann das Gate auf der Prompt-Seite übernehmen. Seine Presidio-Guardrail läuft vor dem Aufruf, nach der Antwort oder nur fürs Logging und kann die Modellausgabe parsen, um maskierte Tokens durch die Originalwerte zu ersetzen. Das ist ein bequemer Start, aber beachte die Grenze: Es deckt Request und Response ab, nicht deinen Ingest-Job und nicht dein Trace-Backend.

## Schwärzen, Maskieren, Tokenisieren: die Technik wählen

Die Erkennung findet die Textstellen, die Technik entscheidet, was sie ersetzt. Die Wahl ist ein Trade-off zwischen Nutzen für das Modell, Umkehrbarkeit und Schaden bei einem Leck. Die Tabelle ist meine Einschätzung auf Basis der Operatoren, die Presidio und Google Cloud Sensitive Data Protection dokumentieren.

Technik

Umkehrbar

Nutzen fürs Modell

Hauptrisiko

Geeignet für

Entfernen (leer oder REDACTED)

Nein

Niedrig: Satzbau bricht

Informationsverlust

Logs, Analytics, alles ohne Bedarf am Wert

Typisierter Platzhalter (PERSON\_1)

Nur mit Tresor

Hoch: Rollen und Beziehungen bleiben sichtbar

Tresor wird zum Datenspeicher

Prompts, Zusammenfassungen, Support-Tickets

Zeichenmaskierung (_\*_\*1234)

Nein

Niedrig bis mittel

Verrät Teilwerte und Länge

Anzeige von Karten- oder Telefonenden

Gesalzener oder geschlüsselter Hash

Nein

Mittel: stabile Joins, unlesbarer Text

Bei wenig Entropie erratbar

Deduplizierung, Join-Schlüssel in Analytics

Deterministische oder formaterhaltende Verschlüsselung

Ja, mit Schlüssel

Mittel bis hoch: gleicher Wert, gleiches Token

Schlüsselverwaltung; Gleichheit sichtbar

Strukturierte Felder, Konsistenz über Dokumente

Realistisches Surrogat (falscher Name)

Nur mit Tresor

Hoch, liest sich natürlich

Falscher Wert kann auf echte Person fallen

Demos, Testdaten, Evals

Presidio bringt Operatoren für replace, redact, hash, mask, encrypt und eigene Funktionen mit, decrypt ist die eingebaute Umkehrung. Google dokumentiert deterministische Verschlüsselung (AES-SIV), formaterhaltende Verschlüsselung (FPE-FFX) und HMAC-SHA-256-Hashing, die ersten beiden umkehrbar, und empfiehlt Schlüssel, die über Cloud KMS gewrappt sind. Mein Standard für Prompts sind typisierte, nummerierte Platzhalter: Das Modell kann weiter schließen, dass PERSON\_1 an PERSON\_2 geschrieben hat, und du entscheidest an der Ausgabegrenze, wer was sehen darf.

## Umkehrbare Tokenisierung: nützlich, mit Tresor

Umkehrbare Tokens lösen das Nutzbarkeitsproblem: Der Nutzer will eine Antwort an einen Kunden, das Modell formuliert sie um PERSON\_1 herum, und dein Gate stellt vor der Anzeige den echten Namen wieder her. Drei Designregeln halten das sicher.

-   **Tokens auf Sitzung oder Request begrenzen.** Eine frische Zuordnung pro Konversation vermeidet eine globale Lookup-Tabelle und verhindert, dass Tokens zu konversationsübergreifenden Kennungen werden.
-   **Tresor verschlüsseln und ablaufen lassen.** Betreibe ihn in deiner eigenen Infrastruktur, verschlüssele ihn mit einem verwalteten Schlüssel und lösche Zuordnungen am Ende der Konversation oder nach kurzer TTL. Er enthält personenbezogene Daten und braucht denselben Löschweg wie der Rest.
-   **Nur am Rand wiederherstellen.** Führe die Rückersetzung in der Schicht aus, die für einen berechtigten Nutzer rendert, nicht innerhalb der Agent-Schleife. Sonst kann ein Tool-Aufruf echte Werte an Orte tragen, die das Modell nicht erreichen sollte.

**Platzhalter können angegriffen werden**

Sieht das Modell PERSON\_1 und geht die Ausgabe an ein Tool, kann eine eingeschleuste Anweisung weiterhin verlangen, dass der echte Wert wiederhergestellt oder abgeflossen wird. Behandle den Tresor als privilegierte Fähigkeit und halte ihn außerhalb der Reichweite des Modells. Die Muster aus [Prompt Injection und die Lethal Trifecta](https://balazscsorba.com/de/blog/prompt-injection-lethal-trifecta-patterns) gelten hier direkt.

## Tools: Presidio, Cloud-Dienste und NER-Modelle

Es gibt keine einzige Antwort, sondern drei Familien, und viele Produktions-Setups kombinieren sie.

-   **Microsoft Presidio** (Open Source, selbst gehostet). Es kombiniert Named-Entity-Recognition, reguläre Ausdrücke, regelbasierte Logik, Prüfsummen und Kontextwörter. Es ist der übliche Startpunkt, weil du kontrollierst, wohin der Text geht, und Recognizer ergänzen kannst. Die Dokumentation ist ehrlich: Weil die Erkennung automatisch erfolgt, gibt es keine Garantie, dass alle sensiblen Informationen gefunden werden.
-   **Cloud-Dienste.** Google Cloud Sensitive Data Protection bietet eine lange Liste von InfoTypes mit einem Ort pro Typ, darunter deutsche wie Reisepass, Personalausweis, Führerschein, Steuer-ID und SCHUFA-ID. Azure Language listet Deutsch und Ungarisch für Text-PII, und die Conversation-PII ist nur für Englisch, Französisch, Deutsch und Spanisch dokumentiert. Amazon Comprehend dokumentiert PII-Erkennung für englischen oder spanischen Text. Das ist verwaltet und leicht zu starten, aber rohen Text an einen Drittanbieter-Detektor zu senden ist selbst eine Übermittlung, die du rechtfertigen musst.
-   **NER-Modelle und Hybride.** Feinabgestimmte Transformer lassen sich lokal betreiben. Eine Forschungsarbeit zu hybrider Erkennung (reguläre Ausdrücke plus LLMs, getestet an 13 ressourcenarmen Sprachen) berichtet einen deutlich besseren gewichteten F1-Wert als feinabgestimmte NER-Modelle und Zero-Shot-LLMs. Nimm sie als Hinweis, deterministische Muster mit kontextsensitiven Modellen zu kombinieren, nicht als fertiges Produkt.

Meine Regel: deterministische Recognizer mit Validierung (IBAN-Prüfsummen, Steuer-ID-Formate) für strukturierte Kennungen, ein NER-Modell für Namen und Orte und einen LLM-basierten Durchlauf nur dort, wo Recall wichtiger ist als Kosten und das Modell innerhalb deiner Grenze läuft.

## Deutsch und Ungarisch: die Abdeckungslücke

Die meisten Detektoren sind in Englisch am stärksten. Für ein Unternehmen in Österreich oder Ungarn ist das das praktische Risiko, denn der Text ist deutsch oder ungarisch, oft gemischt mit Englisch.

-   **Deutsch.** Presidio dokumentiert deutsche Recognizer für Steuer-IDs, Pässe, Personalausweise, Krankenversicherungsnummern und Kfz-Kennzeichen, spaCy liefert trainierte deutsche Pipelines, und LiteLLM nennt Deutsch als unterstützte Guardrail-Sprache. Namen müssen zudem von den vielen großgeschriebenen Substantiven unterschieden werden, teste den Namens-Recall deshalb getrennt auf deutschem Text.
-   **Ungarisch.** In Presidios Entitätsliste und in Googles InfoType-Referenz habe ich keine ungarischen Recognizer gefunden, und spaCy zeigt keine trainierte ungarische Pipeline. Azure listet Ungarisch für Text-PII. Offene Modelle gibt es, etwa ein huBERT-basiertes NER-Modell, feinabgestimmt auf dem NerKor-Korpus mit den Labels PER, ORG, LOC und MISC, aber es steht unter GPL und ist auf 448 Token Eingabe begrenzt, was bei langen Dokumenten zählt.
-   **Sprachspezifischer Kontext.** Presidio-Recognizer unterstützen je eine Sprache, und laut Dokumentation sind Muster wie reguläre Ausdrücke sprachunabhängig, die Kontextwörter, die die Konfidenz erhöhen, aber nicht. Ein deutscher Recognizer braucht Wörter wie „Steuernummer“, ein ungarischer „adószám“ oder „TAJ-szám“, und ungarische Suffixe lassen Namen ihre Form ändern (Péter, Péternek, Péterrel).

Ungarische Kennungen wie Steuernummer oder Sozialversicherungsnummer (TAJ) lassen sich leicht als eigene Muster-Recognizer mit Prüfsummen ergänzen, und dort würde ich anfangen. Namen sind der schwierige Teil und brauchen ein Modell plus eigene Evaluation.

## False Negatives: der Fehler, der zählt

Ein False Positive ersetzt ein harmloses Wort und kostet etwas Qualität. Ein False Negative schickt einen echten Namen an einen Provider und schreibt ihn in ein Log. Optimiere auf Recall bei den wichtigen Entitäten und akzeptiere eine verrauschte Precision.

-   **Namen im Freitext:** Spitznamen, Kleinschreibung im Chat, Namen, die auch Alltagswörter sind, und gebeugte Formen.
-   **Kontextabhängige Kennungen:** Berufsbezeichnung, kleiner Ort und Datum können eine Person identifizieren, ohne dass eine einzelne Entität auffällt.
-   **Formatvarianten:** Telefonnummern mit ungewöhnlichen Leerzeichen, IBANs über mehrere Zeilen, Kennungen in URLs oder Codeblöcken.
-   **Nicht-Text-Eingaben:** OCR-Ausgaben gescannter Dokumente, Tool-Ergebnisse als JSON und Dateinamen.

Wegen dieser Lücken verlass dich nicht allein auf Schwärzung. Ergänze Kontrollen beim Provider (EU-Region, kein Training mit Daten, Zero Retention, wo angeboten), Retrieval mit minimalen Rechten und eine Regel, dass besondere Kategorien (etwa Gesundheitsdaten) nicht an ein allgemeines Modell gehen, es sei denn, es gibt eine dokumentierte Rechtsgrundlage.

## Die DSGVO-Sicht: pseudonymisiert ist nicht anonym

Artikel 4 Nr. 5 DSGVO definiert Pseudonymisierung als Verarbeitung, sodass Daten ohne zusätzliche Informationen keiner bestimmten Person mehr zugeordnet werden können, sofern diese Informationen getrennt aufbewahrt und durch technische und organisatorische Maßnahmen geschützt werden. Es ist eine Schutzmaßnahme, kein Ausstieg aus der Verordnung. Der EDSA hat seine Leitlinien 01/2025 zur Pseudonymisierung am 16. Januar 2025 angenommen und Anfang 2025 konsultiert. Eine Endfassung konnte ich nicht bestätigen, und im Dezember 2025 hielt der EDSA eine Stakeholder-Veranstaltung zum Thema ab, nimm die Leitlinien also als noch in Entwicklung.

Der EuGH hat am 4. September 2025 in EDPS gegen SRB (C-413/23 P) eine Nuance ergänzt. Die Daten im Fall hatte die Single Resolution Board pseudonymisiert und den Schlüssel behalten, bevor sie an Deloitte gingen. Das Gericht bestätigte, dass solche Daten für den ursprünglichen Verantwortlichen personenbezogen sein können, aber nicht zwingend für einen Empfänger ohne vernünftige Mittel zur Re-Identifizierung, und dass die Informationspflicht des Verantwortlichen unabhängig von der Sicht des Empfängers besteht. Kommentatoren raten, zu dokumentieren, warum ein Empfänger nicht re-identifizieren kann, und neu zu bewerten, wenn sich Technik oder Datensätze ändern.

Was das für eine LLM-Pipeline bedeutet, in meiner Lesart: Deine eigenen Systeme, die Tresor oder Schlüssel halten, verarbeiten weiter personenbezogene Daten. Ob der Modell-Provider personenbezogene Daten erhält, hängt davon ab, ob er vernünftige Mittel zur Re-Identifizierung hat, und das ist eine Tatsachenfrage über den Text, den du sendest. Freitext-Prompts, die nach der Schwärzung seltene Detailkombinationen enthalten, sind ein schwacher Beleg. Dokumentiere die Bewertung, halte deine Datenschutzhinweise zur Übermittlung korrekt und nenne Platzhaltertext nicht anonym.

**Das Recht kann sich noch bewegen**

Der Digital-Omnibus-Vorschlag der Kommission vom November 2025 sah eine relative Definition personenbezogener Daten vor und einen Artikel 41a, mit dem die Kommission festlegen könnte, wann pseudonymisierte Daten nicht personenbezogen sind. Ein durchgesickerter Ratskompromiss vom Februar 2026 strich die Neudefinition, und EDSA und EDSB empfahlen, Artikel 41a zu streichen. Das endgültige Ergebnis konnte ich nicht verifizieren, plane also für die heutigen Regeln.

## Schwärzung wie ein Feature testen

Schwärzung ist ein Klassifikator, also teste sie wie einen, und binde sie in dieselben Praktiken ein wie andere LLM-Features (siehe [LLM-Evals für Produkt-Features](https://balazscsorba.com/de/blog/llm-evals-for-product-features)).

1.  Baue pro bediente Sprache einen gelabelten Datensatz mit realistischem Rauschen: Tippfehler, kleingeschriebene Namen, Mischung aus Deutsch oder Ungarisch und Englisch, Tabellen und Codeblöcke.
2.  Berichte Recall und Precision pro Entitätstyp und setze Recall-Ziele für Namen, Kontaktdaten und Kennungen getrennt. Verfolge die Rate übersehener Entitäten, nicht nur den Durchschnitt.
3.  Füge dem Testverkehr Canary-Werte hinzu (erfundene, aber echt aussehende Namen, IBANs und Steuer-IDs) und prüfe in der CI, dass sie nie in Provider-Requests, Logs, Traces oder Caches auftauchen.
4.  Teste den Rundlauf: tokenisieren, Modell aufrufen, wiederherstellen. Prüfe, dass Tokens Umformulierungen überstehen, dass unbekannte Tokens nicht wiederhergestellt werden und dass die Wiederherstellung ohne die richtige Sitzung unmöglich ist.
5.  Führe die Suite bei jeder Änderung von NLP-Modell, Recognizer oder Sprachkonfiguration erneut aus und prüfe Stichproben des Live-Verkehrs manuell, um Drift zu finden.

## Was ich zuerst tun würde

Starte mit einem Gate auf der Prompt-Seite mit Presidio oder Gleichwertigem, typisierten Platzhaltern mit Tresor pro Sitzung, Schwärzung vor dem Indexieren und Maskierung im Trace-Backend. Ergänze eigene Recognizer für deutsche und ungarische Kennungen, miss den Recall auf deinem eigenen Text und kombiniere alles mit EU-Hosting und Verträgen. Ziel ist nicht perfekte Erkennung, die kein Tool verspricht, sondern eine Pipeline, in der ein übersehener Name nicht in fünf Systemen landet.

## Quellen

1.  [Microsoft Presidio: documentation (limitations, methods)](https://presidio.dataprivacystack.org/)
2.  [Presidio: supported entities and country-specific recognizers](https://presidio.dataprivacystack.org/supported_entities/)
3.  [Presidio: supporting additional languages](https://presidio.dataprivacystack.org/analyzer/languages/)
4.  [Presidio: anonymizer operators](https://presidio.dataprivacystack.org/anonymizer/)
5.  [Google Cloud: infoTypes reference](https://docs.cloud.google.com/sensitive-data-protection/docs/infotypes-reference)
6.  [Google Cloud: pseudonymization in Sensitive Data Protection](https://docs.cloud.google.com/sensitive-data-protection/docs/pseudonymization)
7.  [Microsoft Learn: Azure Language PII detection language support](https://learn.microsoft.com/en-us/azure/ai-services/language-service/personally-identifiable-information/language-support)
8.  [AWS: Detecting PII entities with Amazon Comprehend](https://docs.aws.amazon.com/comprehend/latest/dg/how-pii.html)
9.  [spaCy: models and languages](https://spacy.io/usage/models)
10.  [Hugging Face: novakat/nerkor-hubert (Hungarian NER)](https://huggingface.co/novakat/nerkor-hubert)
11.  [arXiv: An Evaluation Study of Hybrid Methods for Multilingual PII Detection](https://arxiv.org/abs/2510.07551)
12.  [LiteLLM: Presidio PII masking guardrail](https://docs.litellm.ai/docs/proxy/guardrails/pii_masking_v2)
13.  [Langfuse: masking](https://langfuse.com/docs/observability/features/masking)
14.  [GDPR Article 4: definitions (pseudonymisation, 4(5))](https://gdpr-info.eu/art-4-gdpr/)
15.  [EDPB: Guidelines 01/2025 on Pseudonymisation](https://www.edpb.europa.eu/our-work-tools/documents/public-consultations/2025/guidelines-012025-pseudonymisation_en)
16.  [IAPP: EDPB publishes draft guidelines on pseudonymization](https://iapp.org/news/a/-what-s-in-a-name-edpb-publishes-draft-guidelines-on-pseudonymization)
17.  [Taylor Wessing: Analysis of the CJEU judgment in C-413/23 P (EDPS v SRB)](https://www.taylorwessing.com/en/insights-and-events/insights/2025/09/analysis-of-the-cjeu-judgment)
18.  [Jones Day: CJEU clarifies scope of personal data in EDPS v SRB](https://www.jonesday.com/en/insights/2025/09/cjeu-clarifies-scope-of-personal-data-in-edps-v-srb-decision)
19.  [IAPP: leaked Council Digital Omnibus compromise drops the revised personal data definition](https://iapp.org/news/a/eu-member-states-leaked-digital-omnibus-compromise-proposal-eliminates-revised-gdpr-definition-of-personal-data)
20.  [Law Health Tech: Pseudonymisation under the GDPR and the Digital Omnibus (May 2026)](https://lawhealthtech.com/2026/05/04/pseudonymisation-under-the-gdpr-where-we-are-what-may-change-under-the-digital-omnibus-and-what-regulators-think/)

## Häufige Fragen

Wie entferne ich PII, bevor Daten an ein LLM gehen?

Setze ein Schwärzungs-Gate zwischen Anwendung und Modell-API. Erkenne Entitäten mit einer Mischung aus Mustern, Prüfsummen und einem NER-Modell (zum Beispiel Microsoft Presidio), ersetze jede durch einen typisierten Platzhalter wie PERSON\_1, sende den geschwärzten Text und bilde die Platzhalter in der Antwort optional zurück ab. Dasselbe Gate gehört vor das Indexieren von Dokumenten sowie vor Logs und Traces.

Was ist der Unterschied zwischen Schwärzung, Maskierung und Tokenisierung?

Schwärzung entfernt den Wert, Maskierung ersetzt Zeichen durch ein Symbol, und Tokenisierung ersetzt den Wert durch einen Stellvertreter, der über einen getrennten Tresor zurückgeführt werden kann. Nur Tokenisierung (oder Verschlüsselung) ist umkehrbar. Hashing ist einseitig, aber bei Werten mit wenig Entropie wie Telefonnummern erratbar.

Sind pseudonymisierte Daten nach der DSGVO personenbezogene Daten?

Für die Stelle, die die zusätzlichen Informationen zur Re-Identifizierung besitzt, ja. Artikel 4 Nr. 5 definiert Pseudonymisierung als Schutzmaßnahme, nicht als Anonymisierung. Der EuGH hat am 4. September 2025 (C-413/23 P) entschieden, dass dieselben Daten für einen Empfänger ohne vernünftige Mittel zur Re-Identifizierung möglicherweise keine personenbezogenen Daten sind. Die Bewertung hängt also von der Perspektive ab.

Unterstützt Microsoft Presidio Deutsch und Ungarisch?

Presidio läuft über die Konfiguration der NLP-Engine auch in anderen Sprachen, und die Dokumentation listet deutsche Recognizer wie Steuer-ID und Personalausweis. Ungarische Recognizer habe ich in der Liste nicht gefunden, und spaCy hat keine trainierte ungarische Pipeline. Für Ungarisch brauchst du also eigene Recognizer oder ein Transformer-Modell und eine eigene Evaluation.

Kann PII-Erkennung garantieren, dass nichts abfließt?

Nein. Presidio schreibt selbst, dass es wegen der automatischen Erkennung keine Garantie gibt, alle sensiblen Informationen zu finden. Namen, Freitext, Tippfehler und kontextabhängige Kennungen erzeugen False Negatives. Schwärzung sollte deshalb eine Schicht neben Zugriffskontrolle, Verträgen und EU-Datenresidenz sein.

Wie teste ich eine PII-Schwärzungs-Pipeline?

Baue einen gelabelten Datensatz in jeder Sprache, die du bedienst, mit realistischem Rauschen, und miss den Recall pro Entitätstyp, denn ein übersehener Name schadet mehr als ein Fehlalarm. Füge Canary-Werte hinzu, die nie in Logs oder Provider-Requests auftauchen dürfen, lass die Suite in der CI laufen und wiederhole sie bei jeder Änderung von Modell, Sprachmodellen oder Recognizern.

Geschrieben von Balázs Csorba

Senior Fullstack & AI Engineer in der Steiermark – über 10 Jahre Vue, Nuxt, Node.js und PHP, heute baue ich Werkzeuge für KI-Agenten.

[KI-Entwicklung & MCP-Server →](https://balazscsorba.com/de/expertise/ai-engineer)[Über mich →](https://balazscsorba.com/de/about)

## Weitere Artikel

-   [KI-Agenten sind Identitäten: Least Privilege für Nicht-Menschen](https://balazscsorba.com/de/blog/ai-agent-identity-least-privilege)
-   [EU AI Act jenseits von Artikel 50: GPAI, Hochrisiko-Fristen und To-dos](https://balazscsorba.com/de/blog/eu-ai-act-gpai-high-risk-2026)
-   [Prompt Injection abwehren: lethal trifecta und sechs Designmuster](https://balazscsorba.com/de/blog/prompt-injection-lethal-trifecta-patterns)
-   [MCP-Sicherheits-Checkliste: Tool-Poisoning, Rug Pulls und OAuth](https://balazscsorba.com/de/blog/mcp-server-security-checklist)

## Klingt nach dem, was du suchst?

Erzähl mir von deinem Projekt oder deiner Stelle – ich freue mich, von dir zu hören.

[Gespräch buchen](mailto:contact@balazscsorba.com) [Auf LinkedIn vernetzen](https://www.linkedin.com/in/balazs-csorba)