Jaz u uskladenosti za RTL skripte
GDPR ne prestaje na Bosporu. EU tvrtke koje koriste alate za latinicne skripte imaju slijepu tocku. Ona je stvarna i uglavnom se ignorira.
Problem nije samo smjer teksta. Skripte koje se citaju s desna na lijevo zahtijevaju drugaciju tokenizaciju. Zahtijevaju drugacije segmentiranje. Granice entiteta funkcioniraju drugacije nego u LTR tekstu. NER sustavi obuceni na engleskom primjenjuju LTR pravila. Ta pravila se ne primjenjuju ispravno na RTL tekstu. Daju pogresne granice entiteta.
Arapska morfologija dodatno otezava stvar. Jezik koristi korijene. Jedan korijen daje desetke oblika rijeci. Ime poput Mohammed moze se pojaviti kao "Al-Mohammed", "bin Mohammed" ili "Mohammed al-Rashid". Regex uzorci izgradeni za zapadnjacka imena propustaju ove oblike. Modeli obuceni na engleskom takoder ih propustaju.
GDPR ne tretira jezik kao granicu uskladenosti. EU tvrtka koja obradjuje korespondenciju od MENA klijenata mora ispunjavati ista pravila kao i za francusku postu. Propustanje PII u RTL tekstu je pravni propust prema GDPR clanku 32.
Slucaj koristenja KYC
Dubajski fintech koji obradjuje KYC dokumente za EU klijente jasno ilustrira ovaj problem.
KYC datoteke za arapske klijente sadrze imena u RTL skripti, UAE Emirates ID-eve i RTL adrese. One su smjestene pored engleskog poslovnog teksta.
Format Emirates ID-a je 784-XXXX-XXXXXXX-X. Kod drzave 784. Godina rodjenja. Sedam znamenki. Kontrolna znamenka. Zapadnjacki PII alati bez UAE definicija entiteta ne mogu pronaci ovaj format. Polja s imenima prolaze kroz latinicni NER. Segmentacija je pogresna. PII postaje nevidljiv u radnom toku.
Za tvrtke s GDPR obvezama za te podatke, ovaj jaz stvara stvarni pravni rizik. GDPR clanak 32 zahtijeva odgovarajuce tehnicke mjere. Alat koji propusta identifikatore u 22% svjetskih jezika nije odgovarajuca mjera.
Hebrejski i dokumenti s mijesanim jezicima
Hebrejski predstavlja slicne probleme. Skripta se cita s desna na lijevo. Izraelski ID brojevi koriste kontrolni zbroj - test nalik Luhn algoritmu na devet znamenki.
Izraelski pravni dokumenti cesto mijesaju hebrejski, tekst arapske skripte i engleski u jednoj datoteci. To je uobicajeno u ugovorima gdje je hebrejski glavni jezik, a engleski termini se dodaju upucivanjem.
Datoteke s mijesanim skriptama zahtijevaju detekciju skripte prije NER-a. Bez toga, jedan NER prolaz primjenjuje latinicna pravila na RTL skripte. Rezultat je pogresan.
Istrazivanje u Nature Scientific Reports (2025.) testiralo je visejezicni NER za RTL PII. Standardni modeli postigli su F1 od 0,60-0,83. XLM-RoBERTa fino podesen na RTL NER podacima postigao je 0,88 i vise.
Zahtjev za visejezicnom arhitekturom
Dobra RTL PII detekcija zahtijeva tri stvari koje zapadnjacki alati obicno nemaju.
RTL rukovanje tekstom: Unicode dvosmjerna uskladenost za ispravni tok teksta. RTL svjesna tokenizacija koja pronalazi granice rijeci u tekstu koji se cita s desna na lijevo.
NER svjestan morfologije: Morfoloski analizator poput Farasa za arapski, ili transformer model fino podesen na RTL NER podacima. Model mora biti naucio morfoloski varijabilnost.
Tipovi entiteta specificni za regiju: Emirates ID, izraelski ID, saudijski nacionalni ID i egipatski nacionalni ID svaki zahtijeva eksplicitne definicije s pravilima formata. Genericni zapadnjacki alati ih nemaju.
Pogledajte kako nas visejezicni NER cjevovod rukuje detekcijom skripte u 48 jezika. Za potpuni popis MENA tipova identifikatora koje podrzavamo, posjetite katalog entiteta. Nas vodic za GDPR uskladenost pokriva kako jaz u detekciji stvara izlozenost prema clanku 32.