Det RTL-relaterade efterlevnadsgapet
Arabiska och hebreiska skapar ett systematiskt misslyckande i PII-identifiering för organisationer som använder verktyg byggda primärt för vänster-till-höger latinska skriftsystem. Problemet handlar inte bara om riktning. Höger-till-vänster-skrift kräver annan tokenisering, annan segmenteringslogik och annan entitetsgränsidentifiering än LTR-metoder. Standardbaserade NER-system tränade på engelska data tillämpar LTR-segmenteringsantaganden som ger felaktiga entitetsgränser i arabisk och hebreisk text.
Bortom riktningsproblematiken tillkommer arabisk morfologi som en djupare utmaning. Arabiska använder ett rotbaserat system där en enda rot kan generera dussintals ytformer via prefix och suffix. Ett personnamn — Mohammed — kan förekomma som "Mohammed," "Al-Mohammed," "bin Mohammed," "Mohammed al-Rashid," eller flera böjda former beroende på grammatiskt sammanhang. Regexmönster utformade för västerländska namnformat kan inte fånga denna morfologiska variation. En ML-modell tränad primärt på engelska data missar de alternativa ytformerna.
GDPR erkänner inte språk som en efterlevnadsgräns. Ett EU-företag som behandlar arabiskspråkig kundkorrespondens från MENA-kunder måste tillämpa samma dataskyddsstandarder som för franskspråkig korrespondens. Det tekniska misslyckandet att identifiera arabiska personuppgifter är ett juridiskt efterlevnadsbrott enligt artikel 32 i GDPR.
KYC-användningsfallet
Ett fintech-företag i Dubai som behandlar KYC-dokument (Know Your Customer) för EU-kunder illustrerar mönstret. KYC-dokument för arabiska kunder innehåller arabiska kundnamn, UAE Emirates-ID (15-siffrigt format) och arabiskskriftiga adresser sida vid sida med engelskspråkig affärskorrespondens.
Emirates ID-formatet — 784-XXXX-XXXXXXX-X — har en specifik struktur: landskod 784, födelseår, sjusiffrigt sekvensnummer, kontrollsiffra. Västerländska PII-verktyg som saknar UAE-specifika entitetsdefinitioner kan inte alls identifiera detta ID-format. De arabiska namnfälten behandlas av latinskrift-NER som producerar felaktig segmentering. Resultatet: systematisk PII-osynlighet i KYC-efterlevnadsflöden.
För organisationer med GDPR-skyldigheter som täcker dessa data skapar det tekniska gapet direkt regulatorisk exponering. GDPR artikel 32 kräver "lämpliga tekniska och organisatoriska åtgärder" — ett system som inte kan identifiera identifierare i 22 % av världens språk är inte en lämplig teknisk åtgärd.
Hebreiska och flerspråkiga dokument
Hebreiska medför liknande utmaningar. Det hebreiska alfabetet skrivs höger till vänster; israeliska ID-nummer har en specifik valideringsalgoritm (Luhn-liknande kontrollsumma för 9-siffriga israeliska identitetsnummer). Israeliska juridiska dokument kan innehålla hebreisk text, arabisk text och engelsk text i samma dokument — särskilt i kommersiella avtal där hebreiska är primärspråket, engelska tjänstevillkor inkorporeras som referens, och arabiska används för arabisktalande parter.
Flerspråkiga dokument med flera skriftsystem i samma textblock kräver skriptidentifiering innan entitetsigenkänning. Utan skriptidentifiering kan ett enda NER-pass tillämpa latinsk tokenisering på semitiska skriftsystem och producera helt felaktig segmentering.
Forskning publicerad i Nature Scientific Reports (2025) undersökte specifikt tvärspråklig NER-prestanda för arabisk PII-identifiering och fann F1-poäng på 0,60–0,83 för standardmodeller jämfört med 0,88+ för ändamålsbyggda tvärspråkliga metoder (XLM-RoBERTa finjusterad på arabiska NER-data).
Kravet på tvärspråklig arkitektur
Effektiv arabisk och hebreisk PII-identifiering kräver tre komponenter som västerländska-första verktyg typiskt saknar:
RTL-texthantering: Efterlevnad av Unicode bidirektionell algoritm för korrekt textflödesrendering, och RTL-medveten tokenisering som respekterar ordgränser i höger-till-vänster-text.
Morfologimedveten NER: Antingen en morfologisk analysator (Farasa för arabiska, eller motsvarande) eller en transformatormodell finjusterad på arabiska/hebreiska NER-data som har lärt sig morfologisk variation.
Regionspecifika entitetsdefinitioner: Emirates ID, israeliskt ID, saudiskt nationellt ID, egyptiskt nationellt ID och andra MENA-specifika identifieringsformat kräver explicita entitetstypsdefinitioner med formatspecifikationer.
Källor: