Пропастта в RTL съответствието
GDPR не свършва на Босфора. ЕС компаниите, използващи инструменти за латинско писмо, имат сляпо петно. То е реално и до голяма степен игнорирано.
Проблемът не е само посоката на текста. Скриптовете отдясно наляво (RTL) изискват различна токенизация. Изискват различна сегментация. Границите на субектите работят по различен начин от LTR текста. NER системите, обучени на английски, прилагат LTR правила. Тези правила се счупват при RTL текст. Дават грешни граници на субектите.
Арабската морфология усложнява нещата допълнително. Езикът използва корени. От един корен се получават десетки словоформи. Дадено име като Мохамед може да се появи като "Ал-Мохамед", "бин Мохамед" или "Мохамед ал-Рашид". Regex шаблони, изградени за западни имена, пропускат тези форми. Моделите, обучени на английски, ги пропускат също.
GDPR не третира езика като граница на съответствието. ЕС фирма, обработваща клиентска поща от клиенти в MENA, трябва да спазва същите правила, каквито важат за пощата на французки. Пропуснатият PII в RTL текст е правна грешка по GDPR Член 32.
Случаят с KYC
Дубайска финтех компания, обработваща KYC документи за клиенти в ЕС, илюстрира това ясно.
KYC файловете за арабски клиенти съдържат имена в RTL скрипт, Emirates ID на ОАЕ и RTL адреси. Те стоят редом с английски бизнес текст.
Форматът на Emirates ID е 784-XXXX-XXXXXXX-X. Код на страната 784. Година на раждане. Седем цифри. Контролна цифра. Западните инструменти за PII без дефиниции за субекти от ОАЕ не могат да намерят този формат. Полетата с имена преминават през NER за латинско писмо. Сегментацията е грешна. PII става невидим в работния процес.
За фирми с GDPR задължения за тези данни пропастта създава реален правен риск. GDPR Член 32 изисква подходящи технически мерки. Инструмент, пропускащ идентификатори в 22% от езиците по света, не е подходяща мярка.
Иврит и документи на смесен език
Ивритът представя подобни проблеми. Скриптът тече отдясно наляво. Израелските ID номера използват контролна сума - Луан-подобен тест върху девет цифри.
Израелски правни документи често смесват иврит, арабски и английски текст в един файл. Това е характерно за договори, в които ивритът е основен език, а английски термини са добавени чрез препратка.
Файловете на смесен скрипт изискват разпознаване на писмото преди NER. Без него единичен NER проход прилага латински правила към RTL скриптове. Изходът е грешен.
Изследване в Nature Scientific Reports (2025) тества крос-лингвален NER за RTL PII. Стандартните модели отбелязаха F1 от 0,60 до 0,83. XLM-RoBERTa, фино настроен на RTL NER данни, отбеляза 0,88 и по-горе.
Изискването за крос-лингвална архитектура
Добрата RTL PII детекция изисква три неща, които западноцентричните инструменти обикновено нямат.
Обработка на RTL текст: Unicode двупосочно съответствие за правилен текстов поток. RTL-съобразена токенизация, която открива словни граници в текст отдясно наляво.
NER, съобразен с морфологията: Морфологичен анализатор като Farasa за арабски, или трансформерен модел, фино настроен на RTL NER данни. Моделът трябва да е усвоил морфологичните вариации.
Типове субекти, специфични за региона: Emirates ID, израелски ID, национален ID на Саудитска Арабия и египетски национален ID изискват изрични дефиниции с правила за формат. Генеричните западни инструменти не разполагат с тях.
Вижте как нашият многоезичен NER конвейер обработва разпознаването на писмото в 48 езика. За пълния списък с типове идентификатори от MENA, които поддържаме, посетете каталога на субекти. Нашето ръководство за съответствие с GDPR обхваща как пропуските в детекцията създават излагане по Член 32.