RTL-efterlevnadsgap
Arabisk och hebreisk utgör ett systematiskt PII-detekteringsfel för organisationer som använder verktyg som främst är byggda för vänster-till-höger latinska skriftspråk. Problemet är inte bara riktat. Höger-till-vänster-skrifter kräver olika tokenisering, olika segmenteringslogik och olika entitetsgränsdetektion än LTR-metoder. Standard NER-system som tränats på engelska data tillämpar LTR-segmenteringsantaganden som ger felaktiga entitetsgränser i arabisk och hebreisk text.
Utöver riktningen tillför arabisk morfologi en djupare utmaning. Arabiska använder ett rotbaserat system där en enda rot kan producera dussintals ytor genom prefix och suffix. En persons namn — Mohammed — kan förekomma som "Mohammed," "Al-Mohammed," "bin Mohammed," "Mohammed al-Rashid," eller flera böjda former beroende på grammatisk kontext. Regex-mönster utformade för västerländska namnformat kan inte fånga denna morfologiska variation. En ML-modell som främst tränats på engelska data kommer att missa de alternativa ytorna.
GDPR erkänner inte språk som en efterlevnadsgräns. Ett EU-företag som behandlar arabisk-språkig kundkorrespondens från MENA-kunder måste tillämpa samma dataskyddsstandarder som för fransk-språkig korrespondens. Det tekniska felet att upptäcka arabisk PII är ett juridiskt efterlevnadsfel enligt artikel 32 i GDPR.
KYC-användningsfallet
Ett fintech-företag i Dubai som behandlar KYC (Know Your Customer) dokument för EU-kunder illustrerar mönstret. KYC-dokument för arabiska kunder innehåller arabiska kundnamn, UAE Emirates-ID (15-siffrig format) och adresser på arabiska tillsammans med engelsk affärskorrespondens.
Emirates ID-formatet — 784-XXXX-XXXXXXX-X — har en specifik struktur: landskod 784, födelseår, sju-siffrig sekvens, kontrollsiffra. Västerländska PII-verktyg som saknar UAE-specifika entitetsdefinitioner kan inte upptäcka detta identifierarformat alls. De arabiska namn fälten behandlas av latinska skript NER som producerar felaktig segmentering. Resultatet: systematisk PII-osynlighet i KYC-efterlevnadsarbetsflöden.
För organisationer under GDPR-åtaganden som omfattar dessa data skapar det tekniska gapet direkt regleringsrisk. GDPR artikel 32 kräver "lämpliga tekniska och organisatoriska åtgärder" — ett system som inte kan upptäcka identifierare på 22% av världens språk är inte en lämplig teknisk åtgärd.
Hebreiska och blandade språk dokument
Hebreiska presenterar relaterade utmaningar. Det hebreiska alfabetet skrivs från höger till vänster; israeliska ID-nummer har en specifik valideringsalgoritm (Luhn-liknande kontrollsumma för 9-siffriga israeliska identitetsnummer). Israels juridiska dokument kan inkludera hebreisk text, arabisk text och engelsk text i samma dokument — särskilt i kommersiella kontrakt där hebreiska är det primära språket, engelska användarvillkor införlivas genom hänvisning, och arabiska används för arabisktalande parter.
Blandade språk dokument med flera skript i samma textblock kräver skriptigenkänning före entitetsigenkänning. Utan skriptigenkänning kan en enda NER-pass tillämpa latinsk tokenisering på semitiska skript, vilket ger helt felaktig segmentering.
Forskning publicerad i Nature Scientific Reports (2025) undersökte specifikt tvärspråklig NER-prestanda för arabisk PII-detektion och fann F1-poäng på 0.60–0.83 för standardmodeller jämfört med 0.88+ för syftesbyggda tvärspråkliga metoder (XLM-RoBERTa finjusterad på arabisk NER-data).
Kravet på tvärspråklig arkitektur
Effektiv arabisk och hebreisk PII-detektion kräver tre komponenter som västerländska verktyg vanligtvis saknar:
RTL-textbehandling: Unicode tvåvägs algoritm efterlevnad för korrekt textflödesrendering, och RTL-medveten tokenisering som respekterar ordgränser i höger-till-vänster text.
Morfologi-medveten NER: Antingen en morfologisk analysator (Farasa för arabisk, eller motsvarande) eller en transformer-modell finjusterad på arabisk/hebreisk NER-data som har lärt sig morfologisk variation.
Region-specifika entitetsdefinitioner: Emirates ID, israeliskt ID, saudiskt nationellt ID, egyptiskt nationellt ID, och andra MENA-specifika identifierarformat kräver explicita entitetstypdefinitioner med format specifikationer.
Källor: