Jaz u RTL usklađenosti
GDPR ne prestaje na Bosforu. EU kompanije koje koriste alate za latinično pismo imaju slepu tačku. Ona je stvarna i uglavnom se zanemaruje.
Problema nije samo smer teksta. Pisma koja se čitaju zdesna nalevo zahtevaju drugačiju tokenizaciju. Potrebna je drugačija segmentacija. Granice entiteta funkcionišu drugačije nego u LTR tekstu. NER sistemi obučeni na engleskom primenjuju LTR pravila. Ta pravila ne funkcionišu na RTL tekstu. Daju pogrešne granice entiteta.
Arapska morfologija sve dodatno komplikuje. Jezik koristi korene. Jedan koren daje desetine oblika reči. Ime poput Mohammed može se pojaviti kao "Al-Mohammed", "bin Mohammed" ili "Mohammed al-Rashid". Regex obrasci napravljeni za zapadna imena propuštaju ove oblike. Modeli obučeni na engleskom ih takodje propuštaju.
GDPR ne tretira jezik kao granicu usklađenosti. EU firma koja obradjuje poštu klijenata iz MENA regiona mora da ispuni ista pravila kao za francusku poštu. Propuštanje PII u RTL tekstu je pravni propust po GDPR članu 32.
Slučaj upotrebe KYC
Dubajski fintech koji obradjuje KYC dokumente za EU klijente jasno pokazuje ovaj problem.
KYC fajlovi za arapske klijente sadrže imena u RTL pismu, UAE Emirates ID-ove i RTL adrese. Oni se nalaze pored engleskog poslovnog teksta.
Format Emirates ID-a je 784-XXXX-XXXXXXX-X. Kôd države 784. Godina rodjenja. Sedam cifara. Kontrolna cifra. Zapadni PII alati bez definicija UAE entiteta ne mogu da pronadju ovaj format. Polja s imenima prolaze kroz latinično-pismeni NER. Segmentacija je pogrešna. PII postaje nevidljiv u toku rada.
Za firme sa GDPR obavezama nad ovim podacima, ovaj jaz stvara stvarni pravni rizik. GDPR član 32 zahteva odgovarajuće tehničke mere. Alat koji propušta identifikatore u 22% svetskih jezika nije odgovarajuća mera.
Hebrejski i višejezični dokumenti
Hebrejski predstavlja slične probleme. Pismo ide zdesna nalevo. Izraelski ID brojevi koriste kontrolnu sumu — test sličan Luhn algoritmu na devet cifara.
Izraelski pravni dokumenti često mešaju hebrejski, tekst u arapskom pismu i engleski u jednom fajlu. To je uobičajeno u ugovorima gde je hebrejski glavni jezik, a engleski termini dodati po referenci.
Fajlovi s mešanim pismom zahtevaju detekciju pisma pre NER-a. Bez nje, jedan NER prolaz primenjuje latinska pravila na RTL pisma. Izlaz je pogrešan.
Istraživanje u Nature Scientific Reports (2025) testiralo je višejezično NER prepoznavanje na RTL PII podacima. Standardni modeli postigli su F1 od 0,60-0,83. XLM-RoBERTa fino podešen na RTL NER podacima postigao je 0,88 i više.
Zahtev za višejezičnom arhitekturom
Dobra RTL PII detekcija zahteva tri stvari koje zapadni alati obično nemaju.
Rukovanje RTL tekstom: Unicode dvosmerna usklađenost za ispravan tok teksta. RTL-svesna tokenizacija koja pronalazi granice reči u tekstu koji se čita zdesna nalevo.
NER svestan morfologije: Morfološki analizator poput Farasa za arapski, ili transformer model fino podešen na RTL NER podacima. Model mora da je naučio morfološke varijacije.
Regionalno specifični tipovi entiteta: Emirates ID, izraelski ID, saudijski nacionalni ID i egipatski nacionalni ID svaki zahtevaju eksplicitne definicije s pravilima formata. Generički zapadni alati ovo nemaju.
Pogledajte kako naš višejezični NER pipeline rukuje detekcijom pisma u 48 jezika. Za potpunu listu MENA identifikatora koje podržavamo, posetite katalog entiteta. Naš vodič za GDPR usklađenost pokriva kako praznine u detekciji stvaraju izloženost po članu 32.