Die RTL-Compliance-Lücke
Arabisch und Hebräisch stellen für Organisationen, die hauptsächlich für von links nach rechts schreibende Sprachen entwickelte Tools verwenden, ein systematisches Versagen bei der PII-Erkennung dar. Das Problem ist nicht nur richtungsabhängig. Von rechts nach links geschriebene Texte erfordern eine andere Tokenisierung, eine andere Segmentierungslogik und eine andere Erkennung von Entitätsgrenzen als LTR-Ansätze. Standard-NER-Systeme, die auf englischen Daten trainiert wurden, wenden LTR-Segmentierungsannahmen an, die in arabischen und hebräischen Texten falsche Entitätsgrenzen erzeugen.
Über die Richtung hinaus stellt die arabische Morphologie eine tiefere Herausforderung dar. Arabisch verwendet ein wortstamm-basiertes System, bei dem ein einzelner Stamm Dutzende von Oberflächenformen durch Präfixe und Suffixe erzeugen kann. Der Name einer Person — Mohammed — kann als "Mohammed," "Al-Mohammed," "bin Mohammed," "Mohammed al-Rashid," oder mehrere flektierte Formen erscheinen, je nach grammatikalischem Kontext. Regex-Muster, die für westliche Namensformate entworfen wurden, können diese morphologische Variation nicht erfassen. Ein ML-Modell, das hauptsächlich auf englischen Daten trainiert wurde, wird die alternativen Oberflächenformen übersehen.
Die DSGVO erkennt Sprache nicht als Compliance-Grenze an. Ein EU-Unternehmen, das arabischsprachige Kundenkorrespondenz von MENA-Kunden verarbeitet, muss dieselben Datenschutzstandards wie für französischsprachige Korrespondenz anwenden. Das technische Versagen, arabische PII zu erkennen, ist ein rechtliches Compliance-Versagen gemäß Artikel 32 der DSGVO.
Der KYC-Anwendungsfall
Ein Fintech-Unternehmen in Dubai, das KYC (Know Your Customer)-Dokumente für EU-Kunden verarbeitet, veranschaulicht das Muster. KYC-Dokumente für arabische Kunden enthalten arabische Kundennamen, UAE Emirates IDs (15-stelliges Format) und arabisch geschriebene Adressen neben englischer Geschäftskorrespondenz.
Das Emirates ID-Format — 784-XXXX-XXXXXXX-X — hat eine spezifische Struktur: Ländercode 784, Geburtsjahr, siebenstellige Sequenz, Prüfziffer. Westliche PII-Tools, die keine UAE-spezifischen Entitätsdefinitionen haben, können dieses Identifikationsformat überhaupt nicht erkennen. Die arabischen Namensfelder werden von lateinisch geschriebenem NER verarbeitet, das falsche Segmentierungen erzeugt. Das Ergebnis: systematische PII-Unsichtbarkeit in KYC-Compliance-Workflows.
Für Organisationen, die unter den DSGVO-Verpflichtungen stehen und diese Daten abdecken, schafft die technische Lücke eine direkte regulatorische Exposition. Artikel 32 der DSGVO verlangt "angemessene technische und organisatorische Maßnahmen" — ein System, das Identifikatoren in 22 % der Sprachen der Welt nicht erkennen kann, ist keine angemessene technische Maßnahme.
Hebräisch und mehrsprachige Dokumente
Hebräisch stellt verwandte Herausforderungen dar. Das hebräische Alphabet wird von rechts nach links geschrieben; israelische ID-Nummern haben einen spezifischen Validierungsalgorithmus (Luhn-ähnliche Prüfziffer für 9-stellige israelische Identitätsnummern). Israelische rechtliche Dokumente können hebräischen Text, arabischen Text und englischen Text im selben Dokument enthalten — insbesondere in kommerziellen Verträgen, in denen Hebräisch die Hauptsprache ist, englische Nutzungsbedingungen durch Verweis einbezogen werden und Arabisch für arabischsprachige Parteien verwendet wird.
Mehrsprachige Dokumente mit mehreren Schriftarten im selben Textblock erfordern eine Schrifterkennung vor der Entitätserkennung. Ohne Schrifterkennung kann ein einzelner NER-Durchlauf lateinische Tokenisierung auf semitische Schriften anwenden, was zu völlig falschen Segmentierungen führt.
Forschung, die in den Nature Scientific Reports (2025) veröffentlicht wurde, untersuchte speziell die Leistung der sprachübergreifenden NER für die Erkennung arabischer PII und fand F1-Werte von 0,60–0,83 für Standardmodelle im Vergleich zu 0,88+ für speziell entwickelte sprachübergreifende Ansätze (XLM-RoBERTa, das auf arabischen NER-Daten feinabgestimmt wurde).
Die Anforderung an die sprachübergreifende Architektur
Eine effektive Erkennung arabischer und hebräischer PII erfordert drei Komponenten, die westlich orientierte Tools typischerweise nicht haben:
RTL-Textverarbeitung: Einhaltung des Unicode-bidirektionalen Algorithmus für die korrekte Textflussdarstellung und RTL-bewusste Tokenisierung, die Wortgrenzen in von rechts nach links geschriebenem Text respektiert.
Morphologie-bewusste NER: Entweder ein morphologischer Analyzer (Farasa für Arabisch oder ein Äquivalent) oder ein Transformermodell, das auf arabischen/hebräischen NER-Daten feinabgestimmt ist und morphologische Variation gelernt hat.
Regionale spezifische Entitätsdefinitionen: Emirates ID, israelische ID, saudische nationale ID, ägyptische nationale ID und andere MENA-spezifische Identifikatorformate erfordern explizite Entitätstypdefinitionen mit Formatangaben.
Quellen: