RTL Overholdelseskløften
Arabisk og Hebraisk præsenterer en systematisk PII detektionsfejl for organisationer, der bruger værktøjer bygget primært til venstre-til-højre latinske skriftsprog. Problemet er ikke blot retningsbestemt. Højre-til-venstre skriftsystemer kræver forskellig tokenisering, forskellig segmenteringslogik og forskellig enhedsgrænse detektion end LTR-tilgange. Standard NER-systemer trænet på engelske data anvender LTR segmenteringsantagelser, der producerer forkerte enhedsgrænser i arabisk og hebraisk tekst.
Udover retning tilføjer arabisk morfologi en dybere udfordring. Arabisk bruger et rod-baseret system, hvor en enkelt rod kan producere dusinvis af overfladeformer gennem præfikser og suffikser. Et persons navn — Mohammed — kan fremtræde som "Mohammed," "Al-Mohammed," "bin Mohammed," "Mohammed al-Rashid," eller flere bøjningsformer afhængigt af den grammatiske kontekst. Regex-mønstre designet til vestlige navneformater kan ikke fange denne morfologiske variation. En ML-model, der primært er trænet på engelske data, vil gå glip af de alternative overfladeformer.
GDPR anerkender ikke sprog som en overholdelsesgrænse. En EU-virksomhed, der behandler arabisk-sprogede kundekorrespondancer fra MENA-klienter, skal anvende de samme databeskyttelsesstandarder som for fransk-sprogede korrespondancer. Den tekniske fejl ved at detektere arabisk PII er en juridisk overholdelsesfejl under Artikel 32 i GDPR.
KYC Brugssagen
Et fintech-selskab i Dubai, der behandler KYC (Know Your Customer) dokumenter for EU-klienter, illustrerer mønsteret. KYC-dokumenter for arabiske klienter indeholder arabiske kundenavne, UAE Emirates ID (15-cifret format) og adresser på arabisk skrift sammen med engelsk forretningskorrespondance.
Emirates ID-formatet — 784-XXXX-XXXXXXX-X — har en specifik struktur: landekode 784, fødselsår, syvcifret sekvens, kontrolciffer. Vestlige PII-værktøjer, der mangler UAE-specifikke enhedsdefinitioner, kan slet ikke detektere dette identifikatorformat. De arabiske navnefelter behandles af latinske NER, der producerer forkert segmentering. Resultatet: systematisk PII usynlighed i KYC overholdelsesarbejdsgange.
For organisationer under GDPR-forpligtelser, der dækker disse data, skaber den tekniske kløft direkte reguleringsmæssig eksponering. GDPR Artikel 32 kræver "passende tekniske og organisatoriske foranstaltninger" — et system, der ikke kan detektere identifikatorer på 22% af verdens sprog, er ikke en passende teknisk foranstaltning.
Hebraiske og Blandede Sprog Dokumenter
Hebraisk præsenterer relaterede udfordringer. Det hebraiske alfabet skrives fra højre mod venstre; israelske ID-numre har en specifik valideringsalgoritme (Luhn-lignende kontrolsum for 9-cifrede israelske identitetsnumre). Israelske juridiske dokumenter kan inkludere hebraisk tekst, arabisk tekst og engelsk tekst i det samme dokument — især i kommercielle kontrakter, hvor hebraisk er det primære sprog, engelske servicevilkår er indarbejdet ved reference, og arabisk bruges til arabisk talende parter.
Blandede sprog dokumenter med flere skriftsystemer i det samme tekstblok kræver skriftsdetektion før enhedsgenkendelse. Uden skriftsdetektion kan en enkelt NER-gennemgang anvende latin tokenisering på semitiske skriftsystemer, hvilket producerer helt forkert segmentering.
Forskning offentliggjort i Nature Scientific Reports (2025) undersøgte specifikt tvær-sproglig NER-ydeevne for arabisk PII detektion og fandt F1-scorer på 0.60–0.83 for standardmodeller mod 0.88+ for formålsbygget tvær-sproglige tilgange (XLM-RoBERTa fintunet på arabisk NER-data).
Kravet om Tvær-Sproglig Arkitektur
Effektiv arabisk og hebraisk PII detektion kræver tre komponenter, som vestlige først-værktøjer typisk mangler:
RTL tekstbehandling: Unicode tovejs-algoritme overholdelse for korrekt tekstflow rendering, og RTL-bevidst tokenisering, der respekterer ordgrænser i højre-til-venstre tekst.
Morfologi-bevidst NER: Enten en morfologisk analyser (Farasa for arabisk, eller ækvivalent) eller en transformer model fintunet på arabisk/hebraisk NER-data, der har lært morfologisk variation.
Regionsspecifikke enhedsdefinitioner: Emirates ID, israelsk ID, saudiarabisk national ID, egyptisk national ID og andre MENA-specifikke identifikatorformater kræver eksplicitte enhedstype definitioner med format specifikationer.
Kilder: