Gap i etterlevelse for hoyre-til-venstre-tekst
GDPR stopper ikke ved Bosporos. EU-selskaper som bruker Latin-skrift-verktoy har et blindt punkt. Det er reelt og i stor grad ignorert.
Problemet er ikke bare tekstretning. Hoyre-til-venstre-skrift krever annen tokenisering. Det krever annen segmentering. Enhetsgrenser fungerer annerledes enn i venstre-til-hoyre-tekst. NER-systemer trenet pa engelsk bruker regler for venstre-til-hoyre-retning. Disse reglene fungerer ikke pa hoyre-til-venstre-tekst. De gir feil enhetsgrenser.
Arabisk morfologi gjor ting vanskeligere. Spraket bruker roter. En rot gir dusinvis av ordformer. Et navn som Mohammed kan vises som "Al-Mohammed", "bin Mohammed" eller "Mohammed al-Rashid". Regex-monster bygd for vestlige navn overser disse formene. Modeller trenet pa engelsk gjor det ogsa.
GDPR behandler ikke sprak som en etterlevelsesgrense. Et EU-selskap som behandler kundepost fra MENA-klienter ma folge de samme reglene som for fransk post. A overse PII i hoyre-til-venstre-tekst er et juridisk brudd under GDPR artikkel 32.
KYC-bruksomradet
En Dubai-basert fintech som behandler KYC-dokumenter for EU-klienter illustrerer dette tydelig.
KYC-filer for arabiske klienter inneholder navn pa hoyre-til-venstre-skrift, UAE Emirates-ID-er og adresser pa hoyre-til-venstre-skrift. Disse ligger ved siden av engelsk forretningstekst.
EmiratesID-formatet er 784-XXXX-XXXXXXX-X. Landskode 784. Fodselsaar. Syv sifre. Kontrollsiffer. Vestlige PII-verktoy uten UAE-enhetsdefinsjoner kan ikke finne dette formatet. Navnefeltene behandles gjennom Latin-skrift NER. Segmenteringen er feil. PII blir usynlig i arbeidsflyten.
For selskaper med GDPR-plikter overfor slike data skaper dette reell juridisk risiko. GDPR artikkel 32 krever passende tekniske tiltak. Et verktoy som overser identifikatorer i 22 % av verdens sprak er ikke et passende tiltak.
Hebraisk og blandede sprakdokumenter
Hebraisk byr pa lignende utfordringer. Skriften gar fra hoyre til venstre. Israelske ID-numre bruker en sjekksum - en Luhn-lignende test pa ni sifre.
Israelske juridiske dokumenter blander ofte hebraisk, arabisk skrift og engelsk i en og samme fil. Dette er vanlig i kontrakter der hebraisk er hovedspraket og engelske begreper er lagt til som referanser.
Filer med blandet skrift krever skript-deteksjon for NER. Uten det anvender en enkelt NER-gjennomgang Latin-regler pa hoyre-til-venstre-skrift. Resultatet blir feil.
Forskning i Nature Scientific Reports (2025) testet tverrspraklig NER pa hoyre-til-venstre PII. Standardmodeller oppnadde F1 pa 0,60-0,83. XLM-RoBERTa finjustert pa hoyre-til-venstre NER-data oppnadde 0,88 og over.
Kravet til tverrspraklig arkitektur
God PII-deteksjon for hoyre-til-venstre-tekst krever tre ting som vestlig-forste verktoy vanligvis mangler.
Haandtering av hoyre-til-venstre-tekst: Unicode bidireksjonell samsvar for korrekt tekstflyt. Hoyre-til-venstre-bevisst tokenisering som finner ordgrenser i tekst som gar fra hoyre til venstre.
Morfologi-bevisst NER: En morfologisk analysator som Farasa for arabisk, eller en transformer-modell finjustert pa hoyre-til-venstre NER-data. Modellen ma ha laert morfologisk variasjon.
Regionspesifikke enhetstyper: Emirates-ID, israelsk ID, saudi-arabisk nasjonal-ID og egyptisk nasjonal-ID trenger eksplisitte definisjoner med formatregler. Generiske vestlige verktoy har ikke disse.
Se hvordan vart flerspraklige NER-rorledningssystem haandterer skript-deteksjon pa tvers av 48 sprak. For hele listen over MENA-identifikatortyper vi stoatter, besok enhetskatalogen. Vaar GDPR-samsvarsguide dekker hvordan deteksjonsgap skaper eksponering under artikkel 32.