Luka w zgodności RTL
Języki arabskie i hebrajskie stanowią systematyczną awarię wykrywania PII dla organizacji korzystających z narzędzi stworzonych głównie dla języków łacińskich pisanych od lewej do prawej. Problem nie dotyczy jedynie kierunku. Skrypty pisane od prawej do lewej wymagają innej tokenizacji, innej logiki segmentacji i innego wykrywania granic encji niż podejścia LTR. Standardowe systemy NER trenowane na danych angielskich stosują założenia segmentacji LTR, które produkują niepoprawne granice encji w tekstach arabskich i hebrajskich.
Poza kierunkowością, morfologia arabska dodaje głębsze wyzwanie. Arabski używa systemu opartego na rdzeniach, gdzie jeden rdzeń może produkować dziesiątki form powierzchniowych poprzez prefiksy i sufiksy. Imię osoby — Mohammed — może występować jako "Mohammed," "Al-Mohammed," "bin Mohammed," "Mohammed al-Rashid," lub w kilku formach fleksyjnych w zależności od kontekstu gramatycznego. Wzory regex zaprojektowane dla zachodnich formatów imion nie mogą uchwycić tej morfologicznej zmienności. Model ML trenowany głównie na danych angielskich przeoczy alternatywne formy powierzchniowe.
GDPR nie uznaje języka jako granicy zgodności. Firma z UE przetwarzająca korespondencję klientów w języku arabskim z klientów MENA musi stosować te same standardy ochrony danych, co w przypadku korespondencji w języku francuskim. Techniczna awaria wykrywania PII w języku arabskim jest awarią zgodności prawnej zgodnie z artykułem 32 GDPR.
Przypadek użycia KYC
Firma fintech w Dubaju przetwarzająca dokumenty KYC (Know Your Customer) dla klientów z UE ilustruje ten wzór. Dokumenty KYC dla klientów arabskich zawierają arabskie imiona klientów, identyfikatory Emirates ID (format 15-cyfrowy) oraz adresy w alfabecie arabskim obok angielskiej korespondencji biznesowej.
Format Emirates ID — 784-XXXX-XXXXXXX-X — ma określoną strukturę: kod kraju 784, rok urodzenia, siedmiocyfrowa sekwencja, cyfra kontrolna. Zachodnie narzędzia PII, które nie mają specyficznych definicji encji dla ZEA, w ogóle nie mogą wykryć tego formatu identyfikatora. Pola z imionami arabskimi są przetwarzane przez NER w alfabecie łacińskim, co prowadzi do niepoprawnej segmentacji. Rezultat: systematyczna niewidoczność PII w procesach zgodności KYC.
Dla organizacji objętych obowiązkami GDPR dotyczącymi tych danych, luka techniczna stwarza bezpośrednie ryzyko regulacyjne. Artykuł 32 GDPR wymaga "odpowiednich środków technicznych i organizacyjnych" — system, który nie może wykrywać identyfikatorów w 22% języków świata, nie jest odpowiednim środkiem technicznym.
Dokumenty hebrajskie i wielojęzyczne
Hebrajski stawia podobne wyzwania. Alfabet hebrajski jest pisany od prawej do lewej; izraelskie numery identyfikacyjne mają określony algorytm walidacji (suma kontrolna podobna do Luhna dla 9-cyfrowych izraelskich numerów identyfikacyjnych). Izraelskie dokumenty prawne mogą zawierać tekst w języku hebrajskim, arabskim i angielskim w tym samym dokumencie — szczególnie w umowach handlowych, gdzie hebrajski jest językiem podstawowym, angielskie warunki świadczenia usług są włączane przez odniesienie, a arabski jest używany dla stron mówiących po arabsku.
Dokumenty wielojęzyczne z wieloma skryptami w tym samym bloku tekstu wymagają wykrywania skryptu przed rozpoznawaniem encji. Bez wykrywania skryptu, pojedyncze przejście NER może zastosować tokenizację łacińską do skryptów semickich, produkując całkowicie niepoprawną segmentację.
Badania opublikowane w Nature Scientific Reports (2025) szczególnie zbadały wydajność NER międzyjęzykowego w wykrywaniu PII w języku arabskim, znajdując wyniki F1 w zakresie 0.60–0.83 dla standardowych modeli w porównaniu do 0.88+ dla specjalnie zaprojektowanych podejść międzyjęzykowych (XLM-RoBERTa dostosowane do danych NER w języku arabskim).
Wymóg architektury międzyjęzykowej
Skuteczne wykrywanie PII w języku arabskim i hebrajskim wymaga trzech komponentów, których narzędzia skoncentrowane na zachodzie zazwyczaj nie mają:
Obsługa tekstu RTL: Zgodność z algorytmem dwukierunkowym Unicode dla poprawnego renderowania przepływu tekstu oraz tokenizacja świadoma RTL, która respektuje granice słów w tekście pisanym od prawej do lewej.
NER świadome morfologii: Albo analizator morfologiczny (Farasa dla arabskiego lub równoważny), albo model transformatora dostosowany do danych NER w języku arabskim/hebrajskim, który nauczył się morfologicznej zmienności.
Definicje encji specyficzne dla regionu: Emirates ID, izraelski ID, saudyjski ID narodowy, egipski ID narodowy i inne formaty identyfikatorów specyficzne dla MENA wymagają wyraźnych definicji typów encji z specyfikacjami formatów.
Źródła: