Mehrsprachige PII-Erkennung für die DSGVO
Aktualisiert für 2026
Die versteckte DSGVO-Lücke
Die DSGVO hat keine Sprachpräferenz. Artikel 4(1) definiert „personenbezogene Daten", ohne die Sprache zu nennen, in der sie erscheinen. Eine deutsche Steuer-ID ist genauso geschützt wie eine US-Sozialversicherungsnummer. Eine französische NIR ist genauso reguliert wie eine britische National Insurance number.
Die meisten PII-Erkennungstools wurden nur für Englisch entwickelt.
Forschungsergebnisse der ACL 2024 zeigen, dass hybride NLP-Tools F1-Scores von 0,60–0,83 für europäische Locales erreichen. Rein englische Tools erzielen für nicht-englische nationale ID-Formate nahe null. Die Lücke ist gravierend. Ein Tool kann 95 % des englischen PII erkennen. Doch es übersieht 40–60 % des deutschen, französischen, polnischen oder niederländischen PII in derselben Datei. Das ist ein ernstes Problem. Es setzt Unternehmen einem Risiko aus.
Dies ist eine reale DSGVO-Lücke. Sie betrifft nahezu jedes internationale Unternehmen, das englischzentrierte Redaktionstools verwendet. Weitere Informationen finden Sie in unserem DSGVO-Leitfaden.
Warum PII Locale-spezifisch ist
Die PII-Erkennung hat zwei Teile.
Der erste Teil ist die musterbasierte Erkennung. Sie erfasst strukturierte IDs wie Steuernummern und Telefonformate.
Der zweite Teil ist die NER-basierte Erkennung. Sie erfasst kontextbezogene Entitäten wie Namen und Adressen.
Beide Teile hängen vom Locale ab.
Strukturierte IDs unterscheiden sich nach Land
| Land | Steuer-ID | Format | Validierung |
|---|---|---|---|
| Deutschland | Steuer-ID | 11 Ziffern | Modulo-11 |
| Frankreich | NIR | 15 Ziffern + 2-stelliger Schlüssel | INSEE |
| Schweden | Personnummer | 10 Ziffern | Luhn |
| Polen | PESEL | 11 Ziffern | Modulo-10 |
| Niederlande | BSN | 9 Ziffern | Elfproef |
| Spanien | DNI/NIE | 8 Ziffern + Buchstabe | Modulo-23 |
| Italien | Codice Fiscale | 16 Zeichen | Eigene Prüfsumme |
Ein rein englischer Regex für SSNs (NNN-NN-NNNN) passt auf keines dieser Formate. Jedes Format benötigt seinen eigenen Regex. Jedes Format benötigt auch seine eigene Prüfsummenlogik.
NER braucht native Modelle
Deutsche Namen unterscheiden sich von englischen. „Hans-Dieter Müller" ist für ein natives deutsches Modell eindeutig. Ein englisch trainiertes Modell übersieht solche Namen oft.
Falsch-positive Ergebnisse sind ebenfalls ein Problem. Der Microsoft Presidio Issue-Tracker zeigt, dass deutsche Wörter als englisches PII fehlklassifiziert werden. Das Wort „Null" ist ein Beispiel. Es löst falsche Namenserkennungen in englisch trainierten Modellen aus. In der Produktion steigen die Fehlerquoten auf 3 Falsch-Positive pro echter Entität (Alvaro et al., 2024).
Regulatorisches Risiko
Die EU-Datenschutzbehörden sind sich dieses Problems bewusst. Mehrere nationale Datenschutzbehörden haben Leitlinien herausgegeben.
BfDI: DSGVO-Artikel 5(1)(f) gilt für alle Aufzeichnungen. Er erfasst auch nicht-englische Daten, die von Drittanbieter-Tools verarbeitet werden.
Französische CNIL: Der CNIL-Jahresbericht 2024 äußerte Bedenken. Er hob KI-Tools hervor, die französische Datensätze ohne französischsprachige PII-Erkennung verarbeiten.
EU-Datenschutzbehörden allgemein: DSGVO-Artikel 25 (Datenschutz durch Technikgestaltung) erfordert geeignete Schutzmaßnahmen für die tatsächlich verarbeiteten Daten. Dies schließt nicht-englisches PII in globalen Deployments ein.
Das Risiko ist klar. Ein Unternehmen kann bei einem DSGVO-Audit 95 % PII-Erkennung bei englischen Inhalten nachweisen. Wenn es jedoch auch deutsche, französische und polnische Aufzeichnungen mit demselben Tool verarbeitet, werden Lücken sichtbar. Prüfer bemerken das. Bußgelder können folgen. Weitere Informationen finden Sie auf unserer Sicherheitsseite.
Dreistufige Architektur
Forschung und Praxis sind sich einig: Ein dreistufiges hybrides Design ist der beste Ansatz.
Stufe 1: Native spaCy-Modelle
spaCy bietet trainierte Modelle für 25 Locales. Dazu gehören Deutsch, Französisch, Spanisch, Portugiesisch, Italienisch, Niederländisch, Russisch, Chinesisch, Japanisch, Koreanisch und Polnisch. Jedes Modell wird auf nativen Texten trainiert. Sie lernen die Syntax und Entitätsmuster jedes Locales. Das ist wichtig. Natives Training bedeutet bessere Trefferquoten und weniger Falsch-Positive.
Für Deutsch: de_core_news_lg verarbeitet zusammengesetzte Substantive und deutsche Namensmuster.
Für Französisch: fr_core_news_lg verarbeitet französische Entitäten, Titel, Ortsnamen und Organisationen.
Native Modelle schlagen sprachübergreifende Modelle bei der Namenssuche in ressourcenreichen Locales.
Stufe 2: Stanza für weitere Locales
Die Stanza-Bibliothek der Stanford University deckt Locales ab, die spaCy nicht enthält. Dazu gehören Kroatisch, Slowenisch und Ukrainisch. Dies erweitert die Abdeckung auf EU-Sprechergruppen, die spaCy nicht erreicht. Stanza ist kostenlos und Open Source. Es lässt sich gut in den restlichen Stack integrieren.
Stufe 3: XLM-RoBERTa für breite Abdeckung
Für Locales, für die spaCy und Stanza keine NER-Modelle haben, füllt XLM-RoBERTa die Lücke. Es wird auf Common Crawl-Texten aus 100 Locales trainiert. Es erreicht 91,4 % sprachübergreifende F1-Werte für PII-Erkennung (HuggingFace 2024). Es verarbeitet Code-Switching gut. Das ist ein wichtiges Merkmal. Es spielt eine Rolle, wenn ein Dokument Text in mehreren Locales enthält.
Besuchen Sie unsere Token-System-Docs, um zu sehen, wie API-Aufrufe mit multilingualen Volumen skalieren.
Locale-spezifische Entitätstypen
Modelle allein reichen nicht aus. Die DSGVO-Konformität erfordert auch die Abdeckung von länderspezifischen IDs.
EU-Nationale IDs nach Land:
- DE: Steuer-ID, Sozialversicherungsnummer, Personalausweisnummer
- FR: NIR, SIREN, SIRET
- PL: PESEL, NIP, REGON
- NL: BSN
- SE: Personnummer, Samordningsnummer
- ES: DNI, NIE, NIF, CIF
- IT: Codice Fiscale, Partita IVA
Telefonformate: Jedes EU-Land hat einzigartige Präfixstrukturen. +49, +33 und +48 benötigen jeweils ihre eigene Validierungslogik.
Adressformate: Postleitzahlen variieren stark. Deutsche PLZ verwendet 5 Ziffern. Französische Codes verwenden 5 Ziffern (01–99 Bereich). UK-Postleitzahlen sind alphanumerisch. Spanische Codes verwenden 5 Ziffern (01000–52999).
Praxisbeispiel: Schweizer Pharmaunternehmen
Ein Schweizer Unternehmen verarbeitet Arbeitsverträge. Jeder Vertrag enthält deutschen, französischen und englischen Text. Die Schweiz hat vier Amtssprachen. Ihr Tool war nur für Deutsch konfiguriert. Es übersah das gesamte PII in den französischen Abschnitten.
Ein Vertrag für einen in Genf ansässigen Mitarbeiter enthielt eine französische AVS-Nummer (13 Ziffern), eine Schweizer Bank-IBAN und einen Namen im französischen Format. Das nur-deutsche Tool übersah den Namen im französischen Format. Es konnte die französische AVS-Nummer nicht finden. Die deutsche AHV-Nummer hat ein anderes Format. Die IBAN wurde nur teilweise erkannt.
Der Drei-Stufen-Ansatz verarbeitet das gesamte Dokument. Er erkennt das Locale pro Textsegment. Er wendet das richtige NER-Modell auf jeden Teil an. Er validiert jede nationale ID mit der korrekten länderspezifischen Logik.
Gemischte Locale-Dokumente
Der schwierigste Fall ist das Mischen von Locales innerhalb eines Dokuments. Beispiele:
- Der englischsprachige Vertrag eines deutschen Unternehmens mit deutschen Mitarbeiterdaten (Namen, Steuer-IDs)
- Ein französisches DSGVO-Einwilligungsformular mit einem englischsprachigen Datenschutzabschnitt
- Ein Chat, bei dem der Agent auf Englisch antwortet und der Kunde auf Arabisch schreibt
XLM-RoBERTa verarbeitet dies nativ. Es benötigt keine expliziten Locale-Flags. Es verarbeitet gemischte Locale-Texte ohne vorherige Segmentierung. Das spart Zeit. Es vermeidet auch Fehler durch fehlerhafte Splits.
Für den Produktionseinsatz bietet die Kombination aus automatischer Locale-Erkennung (auf Satzebene) und XLM-RoBERTa-Inferenz eine robuste Verarbeitung gemischter Locale-Dokumente.
Praktische Schritte
Prüfen Sie die Abdeckung Ihres Tools. Fragen Sie Ihren Redaktions-Anbieter nach F1-Scores für Ihre spezifischen Locales. „Unterstützt 20 Sprachen" bedeutet oft, dass das Tool Text zuerst durch maschinelle Übersetzung leitet. Das ist keine native Erkennung.
Ordnen Sie Ihre Aufzeichnungen den Locales zu. Führen Sie eine Aufzeichnungsinventur durch, die die Locale-Verteilung enthält. Ein globales Unternehmen mit 70 % Englisch, 20 % Deutsch und 10 % Französisch hat andere Risiken. Eines mit 95 % Englisch ist in einer anderen Lage.
Testen Sie mit nationalen ID-Beispielen. Erstellen Sie ein Testset mit jeweils 10 Beispielen der nationalen IDs in Ihren Betrieb—Steuer-ID, NIR, PESEL, BSN und andere. Überprüfen Sie die Erkennungsraten. Das ist schneller als ein vollständiger F1-Test.
Überprüfen Sie Ihre DPIAs. Prüfen Sie, ob die Locale-Abdeckung enthalten ist. Eine unvollständige DPIA, die nur englischsprachige Aufzeichnungen annimmt, muss möglicherweise aktualisiert werden. Handeln Sie jetzt. Warten Sie nicht auf ein Audit, um die Lücke zu entdecken.
Vollständige Entitätstyp-Definitionen finden Sie in der Entitäts-Referenz und den FAQs. Für Pläne und API-Aufrufkosten besuchen Sie Preise.
anonym.legal's PII-Erkennungsengine verwendet einen dreistufigen mehrsprachigen Ansatz. Es deckt 25 ressourcenreiche Locales über native spaCy-Modelle ab. Stanza bietet zusätzliche Locale-Abdeckung. XLM-RoBERTa Cross-Lingual-Transformer erweitern den Umfang auf 48 Locales. Länderspezifische Entitätstypen für alle EU-Mitgliedstaaten sind enthalten.