A jobbról balra írott szövegek megfelelési rése
A GDPR nem ér véget a Boszporusznál. Az EU-s vállalatok, amelyek latin betűs eszközöket használnak, egy vakfolttal küzdenek. Ez valós probléma, és nagyrészt figyelmen kívül hagyják.
A gond nem csupán a szöveg iránya. A jobbról balra (RTL) írott szövegek eltérő tokenizálást igényelnek. Eltérő szegmentálást igényelnek. Az entitáshatárok másképp működnek, mint a balról jobbra (LTR) írott szövegekben. Az angolra betanított NER-rendszerek LTR-szabályokat alkalmaznak. Ezek a szabályok RTL-szövegen felszínre törnek. Hibás entitáshatárokat adnak eredményül.
Az arab morfológia tovább bonyolítja a helyzetet. A nyelv gyökökre épül. Egyetlen gyökből tucatnyi szóalak képezhető. A Mohammed név megjelenhet „Al-Mohammed”, „bin Mohammed” vagy „Mohammed al-Rashid” formában. A nyugati nevekre épített regex-minták elmulasztják ezeket az alakokat. Az angolra betanított modellek szintén.
A GDPR nem tekinti a nyelvet megfelelési határnak. Egy EU-s vállalat, amely MENA-ügyfelek leveleit dolgozza fel, ugyanazokat a szabályokat köteles betartani, mint a francia levelek esetén. A személyes adatok hiánya RTL-szövegben a GDPR 32. cikke alapján jogi mulasztásnak minősül.
A KYC-esetpélda
Egy dubai fintech cég, amely EU-s ügyfeleknek dolgoz fel KYC-dokumentumokat, jól szemlélteti ezt a problémát.
Az arab ügyfelek KYC-fájljai RTL-szkriptben írt neveket, Emírségek-beli személyigazolványszámokat és RTL-címeket tartalmaznak. Ezek angol üzleti szöveg mellett helyezkednek el.
Az emírségek személyigazolvány formátuma: 784-XXXX-XXXXXXX-X. Országkód: 784. Születési év. Hét számjegy. Ellenőrző számjegy. Az UAE-entitásdefiníciók nélküli nyugati PII-eszközök nem találják meg ezt a formátumot. A névmezők latin betűs NER-en haladnak át. A szegmentálás hibás. A személyes adatok láthatatlanná válnak a folyamatban.
Azon vállalatok számára, amelyek GDPR-kötelezettséggel rendelkeznek e adatokra vonatkozóan, a rés valós jogi kockázatot jelent. A GDPR 32. cikke megfelelő technikai intézkedéseket ír elő. Egy olyan eszköz, amely a világ nyelveinek 22%-ában elmulasztja az azonosítókat, nem tekinthető megfelelő intézkedésnek.
Héber és vegyes nyelvű dokumentumok
A héber hasonló problémákat vet fel. A szöveg jobbról balra fut. Az izraeli személyigazolvány-számok egy ellenőrző összeget — egy Luhn-szerű tesztet alkalmaznak kilenc számjegyre.
Az izraeli jogi dokumentumok gyakran hébert, arab írásos szöveget és angolt kevernek egyetlen fájlban. Ez közönséges jelenség olyan szerződésekben, ahol a héber az alapnyelv, és az angol kifejezések hivatkozásként szerepelnek.
A vegyes írású fájlok szkriptfelismerést igényelnek a NER előtt. Enélkül egyetlen NER-menet alkalmaz latin szabályokat RTL-szkriptekre. A kimenet hibás.
A Nature Scientific Reports (2025) kutatása RTL PII-re vonatkozó keresztnyelvű NER-t tesztelt. A standard modellek F1-értéke 0,60–0,83 között mozgott. Az RTL NER-adatokon finomhangolt XLM-RoBERTa 0,88 fölötti értéket ért el.
A keresztnyelvű architektúra követelménye
A hatékony RTL PII-detektáláshoz három dologra van szükség, amelyek a nyugati eszközökből általában hiányoznak.
RTL szövegkezelés: Unicode kétirányú megfelelőség a helyes szövegfolyamhoz. RTL-tudatos tokenizálás, amely megtalálja a szóhatárokat jobbról balra írott szövegben.
Morfológiatudatos NER: Morfológiai elemző, például Farasa arabhoz, vagy RTL NER-adatokon finomhangolt transzformermodell. A modellnek tanulnia kellett a morfológiai variációkat.
Régióspecifikus entitástípusok: Az Emírségek személyigazolványa, az izraeli személyigazolvány, a szaúdi nemzeti azonosító és az egyiptomi nemzeti azonosító mindegyike explicit definíciót igényel formátumszabályokkal. Az általános nyugati eszközök ezeket nem tartalmazzák.
Tekintse meg, hogyan kezeli a többnyelvű NER-csővezetékünk a szkriptfelismerést 48 nyelven. A támogatott MENA-azonosítótípusok teljes listájához látogasson el az entitáskatalógusba. A GDPR-megfelelési útmutatónk ismerteti, hogyan teremtenek a detektálási hézagok 32. cikk szerinti kitettséget.