Mezera v souladu s předpisy pro RTL skripty
GDPR nekončí u Bosporu. Společnosti v EU, které používají nástroje určené pro latinku, mají slepé místo. Je reálné a do značné míry přehlížené.
Problém nespočívá pouze ve směru písma. Skripty psané zprava doleva vyžadují odlišnou tokenizaci. Vyžadují jiná pravidla segmentace. Hranice entit fungují jinak než v textu psaném zleva doprava. Systémy NER trénované na angličtině aplikují pravidla pro LTR. Tato pravidla na RTL textu selhávají a generují nesprávné hranice entit.
Arabská morfologie věc dále komplikuje. Jazyk je postaven na kořenech. Z jednoho kořene vznikají desítky tvarů slov. Jméno jako Mohammed se může objevit jako „Al-Mohammed“, „bin Mohammed“ nebo „Mohammed al-Rashid“. Regulární výrazy navržené pro západní jména tyto tvary přehlédnou. Stejně tak modely trénované na angličtině.
GDPR nepovažuje jazyk za hranici souladu s předpisy. Firma v EU zpracovávající korespondenci od zákazníků z oblasti MENA musí dodržovat stejná pravidla jako při zpracování francouzské pošty. Přehlédnuté OÚ v RTL textu představuje právní pochybení podle článku 32 GDPR.
Případ použití KYC
Dubajský fintech zpracovávající dokumenty KYC pro klienty v EU tento problém ilustruje velmi přesně.
Soubory KYC arabských klientů obsahují jména v RTL skriptu, emirátská čísla Emirates ID a adresy psané zprava doleva. Tyto údaje se nacházejí vedle anglického obchodního textu.
Formát Emirates ID je 784-XXXX-XXXXXXX-X. Kód země 784. Rok narození. Sedm číslic. Kontrolní číslice. Nástroje pro detekci OÚ určené pro západ, které neobsahují definice emirátských entit, tento formát nenaleznou. Pole se jmény procházejí NER pro latinku. Segmentace je nesprávná. OÚ se v pracovním postupu stávají neviditelnou.
Pro firmy, na které se vztahuje povinnost GDPR vůči těmto datům, vzniká reálné právní riziko. Článek 32 GDPR vyžaduje přiměřená technická opatření. Nástroj, který přehlíží identifikátory ve 22 % světových jazyků, přiměřeným opatřením není.
Hebrejština a vícejazyčné dokumenty
Hebrejština přináší obdobné problémy. Skript se píše zprava doleva. Izraelská čísla průkazů totožnosti využívají kontrolní součet — test podobný Luhnovu algoritmu na devíti číslicích.
Izraelské právní dokumenty často mísí hebrejštinu, text v arabském písmu a angličtinu v jediném souboru. Toto je běžné ve smlouvách, kde je hebrejština hlavním jazykem a anglické výrazy jsou doplněny odkazem.
Soubory se smíšenými skripty vyžadují detekci skriptu ještě před spuštěním NER. Bez ní jeden průchod NER aplikuje latinková pravidla na RTL skripty. Výstup je chybný.
Výzkum publikovaný v Nature Scientific Reports (2025) testoval vícejazyčný NER na RTL OÚ. Standardní modely dosáhly F1 skóre 0,60–0,83. XLM-RoBERTa doladěný na RTL NER datech dosáhl hodnoty 0,88 a výše.
Požadavky na vícejazyčnou architekturu
Kvalitní detekce OÚ v RTL textu vyžaduje tři věci, které nástroje primárně zaměřené na západ obvykle postrádají.
Zpracování RTL textu: Soulad s unicodovým bidirektivním standardem pro správný tok textu. RTL tokenizace respektující hranice slov v textu psaném zprava doleva.
NER s morfologickou analýzou: Morfologický analyzátor jako Farasa pro arabštinu nebo transformerový model doladěný na RTL NER datech. Model musí mít naučenou morfologickou variaci.
Typy entit specifické pro daný region: Emirates ID, izraelské číslo průkazu totožnosti, saúdský národní identifikátor a egyptský národní identifikátor vyžadují explicitní definice s formátovými pravidly. Obecné nástroje určené pro západ je neobsahují.
Podívejte se, jak náš vícejazyčný NER kanál zvládá detekci skriptů v 48 jazycích. Úplný seznam identifikátorů MENA, které podporujeme, najdete v katalogu entit. Náš průvodce souladem s GDPR vysvětluje, jak mezery v detekci způsobují expozici podle článku 32.