Nur-Englische PII-Tools: Die DSGVO-Lücke
Die DSGVO hat keine Sprachpräferenz
Die DSGVO erfasst personenbezogene Daten in jeder Sprache. Deutsch, Französisch, Polnisch, Schwedisch — alle sind gleich geschützt. Eine übersehene Steuer-ID erzeugt dasselbe rechtliche Risiko wie eine übersehene Sozialversicherungsnummer. Das Gesetz macht keinen Unterschied bei der Sprache.
Bei den meisten PII-Erkennungstools ist das anders.
Die führenden kommerziellen und Open-Source-Tools wurden für englischen Text entwickelt. Ihre Erkennungsmodule spiegeln das wider. Sie decken US-Sozialversicherungsnummern, US-Führerscheine und NANP-Telefonformate gut ab. Erkennungsmodule für nicht-englische nationale IDs sind weniger genau. Sie werden weniger gepflegt. Sie übersehen echte Identifikatoren häufiger.
Für Unternehmen in EU-Mitgliedstaaten entsteht daraus eine Abdeckungslücke. Das Tool meldet vollständige Erkennung. Aber nicht-englische Identifikatoren verbleiben in den Daten. Diese sind oft die Identifikatoren mit der größten DSGVO-Gefährdung in bestimmten Ländern.
Datenschutzbehörden sehen das. Prüfer achten darauf. Ein Tool kann bei englischen Datensätzen gut funktionieren. Aber wenn es bei deutschen oder französischen Datensätzen versagt, ist es nicht regelkonform. Ein sauberer Bericht ändert das nicht.
Nationale IDs unterscheiden sich in ihrer Struktur
Die Lücke zwischen englischzentrierten Tools und mehrsprachigen Tools liegt nicht daran, dass mehr Regex-Muster fehlen. EU-nationale Identifikatoren sind sehr verschieden voneinander. Sie benötigen länderspezifische Logik, um korrekt erkannt zu werden.
German Steuer-Identifikationsnummer (Steuer-ID): 11 Ziffern. Sie verwendet eine Prüfsumme basierend auf einer Luhn-Formelvariante. Ein generischer SSN-Regex passt nicht darauf. Ein Regex für eine beliebige 11-stellige Zahl erzeugt zu viele falsche Treffer in deutschen Dokumenten.
French NIR (Numéro d'inscription au répertoire): 15 Ziffern. Das Format kodiert Geschlecht, Geburtsjahr, Geburtsmonat und Geburtsort. Es enthält außerdem Geburtsreihenfolge und einen 2-stelligen Kontrollschlüssel. Für eine korrekte Erkennung muss der Kontrollschlüssel validiert werden.
Swedish Personnummer: 10 Ziffern mit einer Luhn-Prüfziffer. Personen, die vor 1990 geboren wurden, verwenden ein +-Trennzeichen statt -. Das verändert das zu erkennende Format.
Polish PESEL: 11 Ziffern. Er kodiert Geburtsdatum, Geschlecht und eine Prüfziffer auf Basis gewichteter Summen. Korrekte Erkennung braucht sowohl Format-Abgleich als auch Prüfsummen-Validierung.
Das sind keine Varianten eines gemeinsamen Musters. Jeder hat eine andere Länge. Jeder verwendet eine andere Prüfmethode. Jeder kodiert Daten in einem anderen Positionsschema. Ein englisch trainiertes NER-Modell, das eine French NIR sieht, erkennt sie nicht als nationalen Identifikator. Es ignoriert sie oder klassifiziert sie falsch.
Das praktische Compliance-Risiko
Stellen Sie sich einen Compliance-Beauftragten bei einem europäischen BPO vor. Er verarbeitet gleichzeitig Daten aus Deutschland, Frankreich, Polen und den Niederlanden. Sein Tool meldet erfolgreiche PII-Anonymisierung.
Aber das Ergebnis ist nicht vollständig. Steuer-IDs in deutschen Datensätzen bleiben erhalten. NIR-Nummern in französischen Datensätzen bleiben erhalten. PESEL-Nummern in polnischen Datensätzen bleiben erhalten. Die Erkennungsmodule des Tools für diese Formate fehlen oder sind zu ungenau.
Später gehen die Daten in die Analyse oder an einen Forschungspartner. Die Daten enthalten weiterhin re-identifizierbare nationale Identifikatoren. Das DSGVO-Problem erscheint nicht in den Output-Logs des Tools. Es taucht auf, wenn eine Auskunftsanfrage einer betroffenen Person eintrifft. Es kann bei einer Prüfung durch eine Datenschutzbehörde auftreten. Es kann nach einer Datenpanne ans Licht kommen.
Forschungen, die hybride mehrsprachige Ansätze mit englischzentrierten Tools verglichen, fanden klare Ergebnisse. Hybride Methoden erzielen F1-Werte von 0,60 bis 0,83 über europäische Locales hinweg. Nur-Englische Tools erzielen nahe null für nicht-englische nationale ID-Formate.
Siehe unsere DSGVO-Compliance-Übersicht dazu, wie diese Lücken auf DSGVO-Verpflichtungen abbilden.
Was vollständige Abdeckung erfordert
Echte mehrsprachige PII-Erkennung für EU-DSGVO-Compliance benötigt drei Schichten.
Sprachspezifische spaCy-Modelle bieten semantisches Verständnis in der Sprache des Textes. Ein auf deutschem Text trainiertes Modell weiß, dass „Müller" ein häufiger deutscher Nachname ist. Modelle gibt es für 25 hochressourcige EU-Sprachen.
Stanza-NLP-Modelle erweitern die Abdeckung auf Sprachen, die nicht in spaCy enthalten sind. Das ergänzt die Reichweite für weitere EU-Sprachgemeinschaften.
Sprachübergreifende Transformer-Modelle (XLM-RoBERTa) behandeln sprachübergreifende Fälle. Ein Name in einem französischen Satz wird als Personenname erkannt. Das funktioniert auch, wenn das Modell nicht speziell auf diesen Namen trainiert wurde.
Regex mit länderspezifischer Validierung deckt strukturierte nationale Identifikatoren ab. Steuer-ID, NIR, PESEL und Personnummer benötigen jeweils ihre eigene Prüfsummenlogik. Das reduziert falsche Treffer. Ziffernfolgen, die länderspezifische Validierungsregeln nicht bestehen, werden herausgefiltert.
Die Lücke ist struktureller Natur. Das Hinzufügen von Wortlisten oder mehr Regex-Mustern bringt nur geringfügige Verbesserung. EU-Identifikatoren von Anfang an einzubauen ist der einzige zuverlässige Ansatz.
Prüfen Sie Ihr aktuelles Tool
Fragen Sie Ihren Anbieter nach F1-Werten für deutsche, französische, polnische und niederländische Datensätze. „Unterstützt mehrere Sprachen" bedeutet oft, dass das Tool zuerst Übersetzung verwendet. Das ist kein natives Scannen. DSGVO-Compliance erfordert natives Scannen.
Testen Sie mit echten nationalen ID-Beispielen. Erstellen Sie einen kurzen Testdatensatz mit 10 Beispielen jedes ID-Typs in Ihren Vorgängen. Steuer-ID, NIR, PESEL, Personnummer. Überprüfen Sie Erkennungsraten. Das ist schneller als ein vollständiger F1-Test und zeigt Lücken schnell auf.
Sehen Sie unsere Sicherheits- und Compliance-Seite dazu, wie anonym.legal diese Anforderungen erfüllt. Für Entity-Typ-Definitionen besuchen Sie die Entities-Referenz.