The RTL Compliance Gap
Arabic and Hebrew present a systematic PII detection failure for organizations using tools built primarily for left-to-right Latin-script languages. The problem is not merely directional. Right-to-left scripts require different tokenization, different segmentation logic, and different entity boundary detection than LTR approaches. Standard NER systems trained on English data apply LTR segmentation assumptions that produce incorrect entity boundaries in Arabic and Hebrew text.
Beyond directionality, Arabic morphology adds a deeper challenge. Arabic uses a root-based system where a single root can produce dozens of surface forms through prefixes and suffixes. A person's name — Mohammed — can appear as "Mohammed," "Al-Mohammed," "bin Mohammed," "Mohammed al-Rashid," or several inflected forms depending on grammatical context. Regex patterns designed for Western name formats cannot capture this morphological variation. An ML model trained primarily on English data will miss the alternate surface forms.
GDPR does not recognize language as a compliance boundary. An EU company processing Arabic-language customer correspondence from MENA clients must apply the same data protection standards as for French-language correspondence. The technical failure to detect Arabic PII is a legal compliance failure under Article 32 of GDPR.
The KYC Use Case
A fintech company in Dubai processing KYC (Know Your Customer) documents for EU clients illustrates the pattern. KYC documents for Arab clients contain Arabic customer names, UAE Emirates IDs (15-digit format), and Arabic-script addresses alongside English business correspondence.
The Emirates ID format — 784-XXXX-XXXXXXX-X — has a specific structure: country code 784, birth year, seven-digit sequence, check digit. Western PII tools that lack UAE-specific entity definitions cannot detect this identifier format at all. The Arabic name fields are processed by Latin-script NER that produces incorrect segmentation. The result: systematic PII invisibility in KYC compliance workflows.
For organizations under GDPR obligations covering this data, the technical gap creates direct regulatory exposure. GDPR Article 32 requires "appropriate technical and organisational measures" — a system that cannot detect identifiers in 22% of the world's languages is not an appropriate technical measure.
Hebrew and Mixed-Language Documents
Hebrew presents related challenges. The Hebrew alphabet is written right-to-left; Israeli ID numbers have a specific validation algorithm (Luhn-like checksum for 9-digit Israeli identity numbers). Israeli legal documents may include Hebrew text, Arabic text, and English text in the same document — particularly in commercial contracts where Hebrew is the primary language, English terms of service are incorporated by reference, and Arabic is used for Arabic-speaking parties.
Mixed-language documents with multiple scripts in the same text block require script detection before entity recognition. Without script detection, a single NER pass may apply Latin tokenization to Semitic scripts, producing completely incorrect segmentation.
Research published in Nature Scientific Reports (2025) specifically examined cross-lingual NER performance for Arabic PII detection, finding F1 scores of 0.60–0.83 for standard models versus 0.88+ for purpose-built cross-lingual approaches (XLM-RoBERTa fine-tuned on Arabic NER data).
The Cross-Lingual Architecture Requirement
Effective Arabic and Hebrew PII detection requires three components that Western-first tools typically lack:
RTL text handling: Unicode bidirectional algorithm compliance for correct text flow rendering, and RTL-aware tokenization that respects word boundaries in right-to-left text.
Morphology-aware NER: Either a morphological analyzer (Farasa for Arabic, or equivalent) or a transformer model fine-tuned on Arabic/Hebrew NER data that has learned morphological variation.
Region-specific entity definitions: Emirates ID, Israeli ID, Saudi National ID, Egyptian National ID, and other MENA-specific identifier formats require explicit entity type definitions with format specifications.
Sources: