RTL Betetze-hutsunearen Arazoa
GDPR-k ez du amaitzen Bosporoan. Latin-alfabetoko tresnak erabiltzen dituzten EBko enpresek itsumenune bat dute. Errealitate hori da, eta neurri handi batean baztertu egiten da.
Arazoa ez da soilik testua idazteko norabidea. Eskuinetik ezkerrerako idazkuntzak tokenizazio ezberdina behar du. Segmentazio ezberdina behar du. Entitate-mugak LTR testuan baino modu ezberdinean funtzionatzen du. Ingelesean entrenatutako NER sistemek LTR arauak aplikatzen dituzte. Arau horiek hautsi egiten dira RTL testuan eta entitate-muga okerrak ematen dituzte.
Arabieraren morfologiak zailtasunak areagotzen ditu. Hizkuntzak erro sistema erabiltzen du. Erro batek hitz forma dozenak sortzen ditu. Mohammed bezalako izen bat "Al-Mohammed," "bin Mohammed" edo "Mohammed al-Rashid" gisa ager daiteke. Mendebaldeko izenendako eraikitako regex ereduak forma hauek galdu egiten ditu. Ingelesean entrenatutako modeloak ere galdu egiten dituzte.
GDPR-k ez du hizkuntza betetze-muga gisa tratatzen. MENA bezeroen posta prozesatzen duen EBko enpresa batek Frantziako postaren arau berberak bete behar ditu. RTL testuan PII galtzea GDPR 32. artikuluaren araberako legezko hutsa da.
KYC Erabilpen-kasua
EBko bezeroentzako KYC dokumentuak prozesatzen dituen Dubai fintech batek argi erakusten du hori.
Arabiar bezeroen KYC fitxategiek RTL idazkuntzako izenak, Arabiar Emirerri Batuetako Emirates IDak eta RTL helbideak dituzte. Hauek ingeles enpresa-testuaren ondoan daude.
Emirates IDaren formatua da 784-XXXX-XXXXXXX-X. 784 herrialde-kodea. Jaiotza-urtea. Zazpi digitu. Kontrol-digitu bat. UAE entitate definizioak ez dituzten mendebaldeko PII tresnek ezin dute formatu hau aurkitu. Izenen eremuak Latin-idazkuntzako NER-etik igarotzen dira. Segmentazioa okerra da. PII ikusezin bihurtzen da lan-fluxuan.
Datu horien gainean GDPR betebeharrak dituzten enpresentzat, hutsuneak benetako arrisku juridikoa sortzen du. GDPR 32. artikuluak neurri tekniko egokiak eskatzen ditu. Munduko hizkuntzen %22an identifikatzaileak galtzen dituen tresna ez da neurri egokia.
Hebreera eta Hizkuntza Mistoko Dokumentuak
Hebreera-k antzeko arazoak ditu. Idazkuntza eskuinetik ezkerrera doa. Israelgo ID zenbakiek checksum bat erabiltzen dute - bederatzi digituen gaineko Luhn-antzeko proba bat.
Israelgo dokumentu juridikoak askotan hebreera, arabiar-idazkuntzako testua eta ingelesa nahasten dituzte fitxategi bakarrean. Hau ohikoa da kontratuetan non hebreera hizkuntza nagusia den eta ingelesezko terminoak erreferentziaz gehitzen diren.
Idazkuntza mistoko fitxategiek idazkuntza-detekzioa behar dute NER-en aurretik. Gabe hori, NER pasarte bakar batek Latin arauak aplikatzen ditu RTL idazkuntzetara. Emaitza okerra da.
Nature Scientific Reports aldizkarian egindako ikerketak (2025) RTL PII gaineko hizkuntzarteko NER probatu zuen. Modelo estandarrek F1 0,60-0,83 lortu zuten. RTL NER datetan fine-tuned XLM-RoBERTa-k 0,88 eta gorago lortu zuen.
Hizkuntzarteko Arkitektura-eskakizuna
RTL PII detekzio egokiak hiru gauza behar ditu mendebaldeko lehen tresnak normalean falta dituztenak.
RTL testu-kudeaketa: Testu-fluxu zuzenererako Unicode bidirektional betetza. RTL testuan hitz-mugak aurkitzen dituen RTL-gai tokenizazioa.
Morfologia-jakitun NER: Arabierarako Farasa bezalako analizatzaile morfologiko bat, edo RTL NER datetan fine-tuned transformer modelo bat. Modeloak aldakuntza morfologikoa ikasi behar du.
Eskualdeko entitate mota espezifikoak: Emirates ID, Israelgo ID, Saudi Nazio ID eta Egiptoar Nazio ID bakoitzak formatu arauak dituzten definizio esplizituak behar ditu. Tresna mendebaldeko generikoek ez dituzte hauek.
Ikusi nola gure NER pipeline multilingüeak idazkuntza-detekzioa kudeatzen duen 48 hizkuntzatan. MENA identifikatzaile moten zerrenda osoaren, bisitatu entitate-katalogoa. Gure GDPR betetze-gida-k azaltzen du nola detekzio-hutsuneak 32. artikuluaren esposizio sortzen duten.