Luka w zgodności dla skryptów RTL
RODO nie kończy się na Bosforze. Firmy z UE korzystające z narzędzi opartych na piśmie łacińskim mają poważną słabość. Jest ona realna i w dużej mierze ignorowana.
Problem to nie tylko kierunek tekstu. Skrypty pisane od prawej do lewej wymagają innej tokenizacji i innej segmentacji. Granice encji działają inaczej niż w tekście LTR. Systemy NER trenowane na języku angielskim stosują reguły LTR — reguły, które przy tekście RTL dają błędne granice encji.
Morfologia arabska dodatkowo komplikuje sprawę. Język arabski opiera się na rdzeniach, z których jeden korzeń tworzy dziesiątki form wyrazowych. Imię takie jak Mohammed może pojawić się jako „Al-Mohammed”, „bin Mohammed” lub „Mohammed al-Rashid”. Wzorce regex budowane dla zachodnich nazwisk nie rozpoznają tych form — podobnie jak modele trenowane na języku angielskim.
RODO nie traktuje języka jako granicy compliance. Firma z UE przetwarzająca korespondencję klientów z regionu MENA musi spełniać te same wymogi, co przy korespondencji po francusku. Pominięcie PII w tekście RTL jest naruszeniem prawnym na podstawie art. 32 RODO.
Przypadek KYC
Dubajski fintech przetwarzający dokumenty KYC dla klientów z UE dobrze ilustruje ten problem.
Dokumenty KYC klientów arabskich zawierają imiona w piśmie RTL, emirackie dokumenty tożsamości (Emirates ID) oraz adresy w piśmie RTL — obok angielskich tekstów biznesowych.
Format Emirates ID to 784-XXXX-XXXXXXX-X: kod kraju 784, rok urodzenia, siedem cyfr i cyfra kontrolna. Zachodnie narzędzia PII bez zdefiniowanych encji dla ZEA nie rozpoznają tego formatu. Pola z imionami przechodzą przez NER dla pisma łacińskiego z błędną segmentacją. PII staje się niewidoczne w procesie pracy.
Dla firm objętych obowiązkami RODO w zakresie tych danych luka ta tworzy realne ryzyko prawne. Art. 32 RODO wymaga odpowiednich środków technicznych. Narzędzie pomijające identyfikatory w 22% języków świata nie jest odpowiednim środkiem.
Hebrajski i dokumenty wielojęzyczne
Hebrajski stwarza podobne wyzwania. Skrypt biegnie od prawej do lewej. Izraelskie numery identyfikacyjne używają sumy kontrolnej — testu podobnego do algorytmu Luhna, stosowanego do dziewięciu cyfr.
Izraelskie dokumenty prawne często łączą hebrajski, tekst w piśmie arabskim i angielski w jednym pliku. Jest to powszechne w umowach, gdzie hebrajski jest językiem głównym, a angielskie terminy są włączane przez odniesienie.
Dokumenty wieloscryptowe wymagają wykrywania skryptu przed NER. Bez tego jeden przebieg NER stosuje reguły łacińskie do skryptów RTL — z błędnymi wynikami.
Badania opublikowane w Nature Scientific Reports (2025) przetestowały cross-lingual NER na RTL PII. Standardowe modele osiągnęły F1 w zakresie 0,60–0,83. XLM-RoBERTa dostrojony na danych NER dla RTL osiągnął wyniki powyżej 0,88.
Wymagania architektoniczne dla detekcji cross-lingual
Rzeczywista detekcja PII w tekście RTL wymaga trzech elementów, których zwykle brakuje narzędziom tworzonym z myślą o językach zachodnich.
Obsługa tekstu RTL: zgodność z Unicode Bidirectional dla poprawnego przepływu tekstu oraz tokenizacja z uwzględnieniem RTL, która prawidłowo wyznacza granice wyrazów.
NER uwzględniający morfologię: analizator morfologiczny taki jak Farasa dla języka arabskiego albo model transformerowy dostrojony na danych NER dla RTL. Model musi nauczyć się wariantywności morfologicznej.
Typy encji specyficzne dla regionu: Emirates ID, izraelski numer identyfikacyjny, saudyjski IQAMA i egipski numer krajowy wymagają odrębnych definicji z regułami formatu. Ogólne narzędzia zachodnie tych definicji nie posiadają.
Sprawdź, jak nasz wielojęzyczny potok NER obsługuje detekcję skryptów w 48 językach. Pełną listę obsługiwanych identyfikatorów z regionu MENA znajdziesz w katalogu encji. Nasz przewodnik po zgodności z RODO wyjaśnia, jak luki w detekcji tworzą narażenie na podstawie art. 32.