The RTL Compliance Gap
GDPR does not end at the Bosphorus. EU companies that use Latin-script tools have a blind spot. It is real and it is largely ignored.
The problem is not just text direction. Right-to-left scripts need different tokenization. They need different segmentation. Entity boundaries work differently than in LTR text. NER systems trained on English apply LTR rules. Those rules break on RTL text. They give wrong entity boundaries.
Arabic morphology makes things harder. The language uses roots. One root gives dozens of word forms. A name like Mohammed can appear as "Al-Mohammed," "bin Mohammed," or "Mohammed al-Rashid." Regex patterns built for Western names miss these forms. Models trained on English miss them too.
GDPR does not treat language as a compliance boundary. An EU firm processing customer mail from MENA clients must meet the same rules as for French mail. Missing PII in RTL text is a legal failure under GDPR Article 32.
The KYC Use Case
A Dubai fintech processing KYC documents for EU clients shows this clearly.
KYC files for Arab clients hold names in RTL script, UAE Emirates IDs, and RTL addresses. These sit beside English business text.
The Emirates ID format is 784-XXXX-XXXXXXX-X. Country code 784. Birth year. Seven digits. Check digit. Western PII tools with no UAE entity definitions cannot find this format. The name fields go through Latin-script NER. The segmentation is wrong. PII becomes invisible in the workflow.
For firms with GDPR duties over this data, the gap creates real legal risk. GDPR Article 32 requires appropriate technical measures. A tool that misses identifiers in 22% of the world's languages is not an appropriate measure.
Hebrew and Mixed-Language Documents
Hebrew presents similar problems. The script runs right to left. Israeli ID numbers use a checksum — a Luhn-like test on nine digits.
Israeli legal documents often mix Hebrew, Arabic-script text, and English in one file. This is common in contracts where Hebrew is the main language and English terms are added by reference.
Mixed-script files need script detection before NER. Without it, a single NER pass applies Latin rules to RTL scripts. The output is wrong.
Research in Nature Scientific Reports (2025) tested cross-lingual NER on RTL PII. Standard models scored F1 of 0.60–0.83. XLM-RoBERTa fine-tuned on RTL NER data scored 0.88 and above.
The Cross-Lingual Architecture Requirement
Good RTL PII detection needs three things that Western-first tools usually lack.
RTL text handling: Unicode bidirectional compliance for correct text flow. RTL-aware tokenization that finds word boundaries in right-to-left text.
Morphology-aware NER: A morphological analyzer like Farasa for Arabic, or a transformer model fine-tuned on RTL NER data. The model must have learned morphological variation.
Region-specific entity types: Emirates ID, Israeli ID, Saudi National ID, and Egyptian National ID each need explicit definitions with format rules. Generic Western tools do not have these.
See how our multilingual NER pipeline handles script detection across 48 languages. For the full list of MENA identifier types we support, visit the entity catalog. Our GDPR compliance guide covers how detection gaps create Article 32 exposure.
When This Approach Has Limits
RTL-aware tokenization, morphology-aware NER, and region-specific entity definitions close a gap that Western tools leave wide open. But Arabic and Hebrew remain among the harder languages to process, and the result is improvement, not parity.
RTL and morphologically rich languages are genuinely lower-accuracy. Arabic's rich morphology, optional diacritics, and dialectal variation, and Hebrew's unvowelized script, make named-entity recognition harder than in English even with purpose-built models. A dedicated pipeline narrows the gap substantially; it does not bring recall to the level of high-resource Latin-script languages. Expect a residual miss rate and validate it on your own MENA documents rather than assuming the gap is closed.
Structured IDs are reliable; free-text names are not. Emirates ID, Israeli ID, and Saudi National ID have defined formats and are detected well once recognizers exist. Personal names, addresses, and contextual references written in Arabic or Hebrew prose — often transliterated inconsistently into Latin script in the same document — are far harder. Coverage of the national-ID formats does not imply equivalent coverage of free-form personal data in the same files.
Detection is one GDPR Article 32 control, not the whole obligation. Catching RTL identifiers reduces leakage risk, but Article 32 requires appropriate technical and organizational measures across the processing lifecycle — access control, encryption, retention, and the human review that catches what the model misses. Strong RTL detection is necessary for MENA-language compliance; it is not, on its own, sufficient evidence that processing meets the standard.