Die RTL-Compliance-Lücke
Die DSGVO endet nicht am Bosporus. EU-Unternehmen, die Werkzeuge für lateinische Schrift nutzen, haben einen blinden Fleck. Er ist real und wird weitgehend ignoriert.
Das Problem ist nicht nur die Textrichtung. Schriften von rechts nach links brauchen andere Tokenisierung. Sie brauchen eine andere Segmentierung. Entitätsgrenzen funktionieren anders als in LTR-Text. NER-Systeme, die auf Englisch trainiert wurden, wenden LTR-Regeln an. Diese Regeln versagen bei RTL-Text. Sie liefern falsche Entitätsgrenzen.
Die arabische Morphologie macht es noch schwieriger. Die Sprache verwendet Wortwurzeln. Eine Wurzel ergibt Dutzende von Wortformen. Ein Name wie Mohammed kann als „Al-Mohammed", „bin Mohammed" oder „Mohammed al-Rashid" erscheinen. Regex-Muster für westliche Namen verfehlen diese Formen. Modelle, die auf Englisch trainiert wurden, tun es ebenfalls.
Die DSGVO behandelt Sprache nicht als Compliance-Grenze. Ein EU-Unternehmen, das Kundenschreiben von MENA-Klienten verarbeitet, muss dieselben Regeln einhalten wie für französische Post. Das Verfehlen von PII in RTL-Text ist ein rechtlicher Verstoß gemäß DSGVO Artikel 32.
Der KYC-Anwendungsfall
Ein Fintech-Unternehmen in Dubai, das KYC-Dokumente für EU-Kunden verarbeitet, zeigt dies deutlich.
KYC-Dateien für arabische Klienten enthalten Namen in RTL-Schrift, VAE Emirates-IDs und RTL-Adressen. Diese liegen neben englischen Geschäftstexten.
Das Emirates-ID-Format lautet 784-XXXX-XXXXXXX-X. Ländercode 784. Geburtsjahr. Sieben Ziffern. Prüfziffer. Westliche PII-Werkzeuge ohne VAE-Entitätsdefinitionen können dieses Format nicht finden. Die Namensfelder laufen durch lateinisches NER. Die Segmentierung ist falsch. PII wird im Workflow unsichtbar.
Für Unternehmen mit DSGVO-Pflichten über diese Daten erzeugt die Lücke echtes rechtliches Risiko. DSGVO Artikel 32 verlangt geeignete technische Maßnahmen. Ein Werkzeug, das Identifikatoren in 22 % der Weltsprachen übersieht, ist keine geeignete Maßnahme.
Hebräische und mehrsprachige Dokumente
Hebräisch stellt ähnliche Probleme dar. Die Schrift läuft von rechts nach links. Israelische Ausweisnummern verwenden eine Prüfsumme — einen Luhn-ähnlichen Test auf neun Ziffern.
Israelische Rechtsdokumente mischen oft Hebräisch, arabische Schrift und Englisch in einer Datei. Das ist häufig in Verträgen, wo Hebräisch die Hauptsprache ist und englische Bedingungen per Verweis eingebunden werden.
Dokumente mit gemischten Schriften brauchen eine Skripterkennung vor dem NER. Ohne sie wendet ein einzelner NER-Durchlauf lateinische Regeln auf RTL-Schriften an. Das Ergebnis ist falsch.
Forschungen in Nature Scientific Reports (2025) testeten sprachübergreifendes NER bei RTL-PII. Standardmodelle erzielten F1-Werte von 0,60–0,83. XLM-RoBERTa, auf RTL-NER-Daten feinabgestimmt, erzielte 0,88 und mehr.
Die cross-linguale Architektur
Gutes RTL-PII-Erkennen braucht drei Dinge, die westlich-zentrierte Werkzeuge meist nicht haben.
RTL-Textverarbeitung: Unicode-Bidirektionalitäts-Compliance für korrekten Textfluss. RTL-bewusste Tokenisierung, die Wortgrenzen in rechts-nach-links-Text erkennt.
Morphologie-bewusstes NER: Ein morphologischer Analysator wie Farasa für Arabisch oder ein Transformer-Modell, das auf RTL-NER-Daten feinabgestimmt wurde. Das Modell muss morphologische Variation gelernt haben.
Regionsspezifische Entitätstypen: Emirates-ID, israelische ID, saudi-arabische National-ID und ägyptische National-ID brauchen jeweils explizite Definitionen mit Formatregeln. Allgemeine westliche Werkzeuge haben diese nicht.
Sehen Sie, wie unsere mehrsprachige NER-Pipeline die Skripterkennung für 48 Sprachen handhabt. Für die vollständige Liste der MENA-Identifikatortypen, die wir unterstützen, besuchen Sie den Entitätskatalog. Unser DSGVO-Compliance-Leitfaden behandelt, wie Erkennungslücken Artikel-32-Risiken erzeugen.