Medzera v sulade pre pismo zprava dolava
GDPR sa nekončí pri Bospore. Firmy v EU, ktore pouzivaju nastroje pre latinku, maju slepé miesto. Je reálne a z velke] časti prehliadane.
Problem nie je len smer textu. Pismo zprava dolava (RTL) vyzaduje inu tokenizaciu. Vyzaduje inu segmentaciu. Hranice entit funguju inak ako v texte zlava doprava. NER systemy trenovane na anglictine aplikuju pravidla LTR. Tieto pravidla sa na RTL texte lamu. Vysledkom su nespravne hranice entit.
Arabska morfologia situaciu este zhoruje. Jazyk pouziva korene. Jeden koren dava desiatky slovnych foriem. Meno ako Mohammed sa moze vyskytovat ako "Al-Mohammed," "bin Mohammed" alebo "Mohammed al-Rashid." Regexove vzory postavene pre zapadne mena tieto formy nerozpoznaju. Modely trenovane na anglictine ich tiez prehliadaju.
GDPR netraktuje jazyk ako hranicu dodrziavania pravidiel. Firma v EU spracuvajuca zakaznicku postu od klientov z MENA regionu musi splnat rovnake pravidla ako pre francuzsku postu. Presadnutie PII v RTL texte je pravne zlyhanie podla Clanku 32 GDPR.
Pripad KYC
Dubajska fintech spolocnost spracuvajuca KYC dokumenty pre klientov z EU toto jasne ukazuje.
KYC subory pre arabskych klientov obsahuju mena v RTL pisanom pisme, emiratske ID cisla a RTL adresy. Tieto su umiestnene vedla anglickeho obchodneho textu.
Format emiratskeho ID je 784-XXXX-XXXXXXX-X. Kod krajiny 784. Rok narodenia. Sedem číslic. Kontrolna číslica. Zapadne PII nastroje bez definicii emiratskych entit tento format nenajdu. Polia s menom prechádzaju cez NER pre latinku. Segmentacia je nespravna. PII sa v pracovnom toku stáva neviditelnou.
Pre firmy s povinnosťami podla GDPR nad tymito datami táto medzera vytvára reálne pravne riziko. Článok 32 GDPR vyzaduje primerané technicke opatrenia. Nastroj, ktory prehliadá identifikatory v 22 % svetových jazykov, nie je primerané opatrenie.
Hebrejčina a zmesane jazykove dokumenty
Hebrejčina predsavuje podobne problemy. Pismo ide zprava dolava. Izraelske identifikačne cisla pouzivaju kontrolny sucet — test podobny Luhnovmu algoritmu na deviatich cifrach.
Izraelske pravne dokumenty casto miesaju hebrejčinu, arabske pismo a anglictinu v jednom subore. Je to bežne v zmluvach, kde je hlavnym jazykom hebrejčina a anglicke terminy su doplnene odkazom.
Subory s mieszanym pismom vyzaduju detekciu pisma pred NER. Bez toho jeden NER prechod aplikuje latinské pravidla na RTL skripty. Vystup je nespravny.
Vyskum v Nature Scientific Reports (2025) testoval krizovajazycny NER na RTL PII. Standardne modely dosiahli F1 0,60–0,83. XLM-RoBERTa doladeny na RTL NER datach dosiahol 0,88 a vysse.
Poziadavka na krizovajazycnu architekturu
Kvalitna detekcia RTL PII potrebuje tri veci, ktore nastrojom orientovanym na Zapad zvycajne chybaju.
Spracovanie RTL textu: Dodrzanie Unicode bidirekcionalnej normy pre spravny tok textu. RTL-vedomá tokenizácia, ktora nachádza hranice slov v texte zprava dolava.
NER s vedomostou morfologie: Morfologicky analyzator, ako je Farasa pre arabčinu, alebo transformerovy model doladeny na RTL NER datach. Model musi mat naučenu morfologicku variabilitu.
Typy entit specificke pre region: Emiratske ID, izraelske ID, saudske narodni ID a egyptske narodni ID potrebuju explicitne definicie s formatovymi pravidlami. Genericke zapadne nastroje tieto nemaju.
Pozrite sa, ako nasa viacjazyčna NER pipeline riesi detekciu pisma v 48 jazykoch. Uplny zoznam typov identifikatorov z MENA regionu, ktore podporujeme, najdete v katalógu entit. Nas pruvodca dodrziavania GDPR pokryva, ako medzery v detekcii vytvaraju expozíciu podla Článku 32.