Den RTL-baserede compliancekløft
GDPR stopper ikke ved Bosporus. EU-virksomheder, der bruger latinskriftsbaserede værktøjer, har en blind vinkel. Den er reel og i vid udstrækning ignoreret.
Problemet handler ikke blot om tekstretning. Højre-til-venstre-skrifter kræver en anden tokenisering. De kræver en anden segmentering. Enhedsgrænser fungerer anderledes end i venstre-til-højre-tekst. NER-systemer trænet på engelsk anvender LTR-regler. Disse regler bryder ned ved RTL-tekst og giver forkerte enhedsgrænser.
Arabisk morfologi gør det endnu vanskeligere. Sproget bygger på rødder. Én rod giver anledning til snesevis af ordformer. Et navn som Mohammed kan optræde som "Al-Mohammed," "bin Mohammed" eller "Mohammed al-Rashid." Regex-mønstre bygget til vestlige navne overser disse former. Modeller trænet på engelsk gør det samme.
GDPR behandler ikke sprog som en compliancegrænse. En EU-virksomhed, der behandler kundepost fra MENA-klienter, er underlagt de samme regler som for fransk post. At overse persondata i RTL-tekst er en juridisk fejl i henhold til GDPR artikel 32.
KYC-anvendelsesscenariet
En Dubai-baseret fintech, der behandler KYC-dokumenter for EU-klienter, illustrerer dette tydeligt.
KYC-filer for arabiske klienter indeholder navne på RTL-skrift, UAE Emirates ID-numre og RTL-adresser. Disse ligger side om side med engelsksprogede forretningstekster.
Emirates ID-formatet er 784-XXXX-XXXXXXX-X. Landekode 784. Fødselsår. Syv cifre. Kontrolciffer. Vestlige PII-værktøjer uden UAE-entitetsdefinitioner kan ikke finde dette format. Navnefelterne behandles via latinskrifts-NER. Segmenteringen er forkert. Persondata bliver usynlig i arbejdsgangen.
For virksomheder med GDPR-forpligtelser over disse data skaber kløften en reel juridisk risiko. GDPR artikel 32 kræver passende tekniske foranstaltninger. Et værktøj, der overser identifikatorer i 22 % af verdens sprog, udgør ikke en passende foranstaltning.
Hebraisk og blandede flersprogede dokumenter
Hebraisk frembyder tilsvarende udfordringer. Skriften løber fra højre mod venstre. Israelske ID-numre anvender en kontrolsum — en Luhn-lignende test på ni cifre.
Israelske juridiske dokumenter blander ofte hebraisk, arabisk skrift og engelsk i én fil. Dette er udbredt i kontrakter, hvor hebraisk er hovedsproget, og engelske termer tilføjes som referencer.
Blandede skriftfiler kræver skriptdetektion inden NER. Uden dette anvender et enkelt NER-gennemløb latinske regler på RTL-skrifter. Resultatet er forkert.
Forskning i Nature Scientific Reports (2025) testede tværsproglig NER på RTL-persondata. Standardmodeller scorede F1 på 0,60–0,83. XLM-RoBERTa finjusteret på RTL NER-data scorede 0,88 og derover.
Kravet om tværsproglig arkitektur
God RTL PII-detektion kræver tre ting, som vestligt-fokuserede værktøjer typisk mangler.
RTL-teksthåndtering: Unicode-tovejsoverholdelse for korrekt tekstflow. RTL-bevidst tokenisering, der finder ordgrænser i højre-til-venstre-tekst.
Morfologibevidst NER: En morfologisk analysator som Farasa til arabisk, eller en transformer-model finjusteret på RTL NER-data. Modellen skal have lært morfologisk variation.
Regionsspecifikke entitetstyper: Emirates ID, israelske ID-numre, Saudi National ID og Egyptian National ID kræver hver sine eksplicitte definitioner med formatregler. Generiske vestlige værktøjer har ikke disse.
Se, hvordan vores flersprogede NER-pipeline håndterer skriptdetektion på tværs af 48 sprog. For den fulde liste over MENA-identifikatortyper, vi understøtter, besøg entitetskataloget. Vores GDPR-complianceguide beskriver, hvordan detektionskløfter skaber eksponering under artikel 32.