Пробел в соблюдении норм RTL
Арабский и еврейский языки представляют собой систематическую неудачу в обнаружении PII для организаций, использующих инструменты, разработанные в основном для языков с латинским алфавитом, читаемых слева направо. Проблема не только в направлении. Скрипты, читаемые справа налево, требуют другой токенизации, другой логики сегментации и другого обнаружения границ сущностей, чем подходы LTR. Стандартные системы NER, обученные на английских данных, применяют предположения о сегментации LTR, которые приводят к неправильным границам сущностей в арабском и еврейском текстах.
Помимо направленности, морфология арабского языка добавляет более глубокую проблему. Арабский язык использует корневую систему, где один корень может производить десятки поверхностных форм через приставки и суффиксы. Имя человека — Мохаммед — может появляться как "Мохаммед," "Аль-Мохаммед," "бин Мохаммед," "Мохаммед аль-Рашид," или несколько измененных форм в зависимости от грамматического контекста. Шаблоны Regex, разработанные для западных форматов имен, не могут захватить это морфологическое разнообразие. Модель ML, обученная в основном на английских данных, пропустит альтернативные поверхностные формы.
GDPR не признает язык как границу соблюдения норм. Компания ЕС, обрабатывающая корреспонденцию на арабском языке от клиентов MENA, должна применять те же стандарты защиты данных, что и для корреспонденции на французском языке. Техническая неудача в обнаружении арабских PII является юридической неудачей в соблюдении норм в соответствии со статьей 32 GDPR.
Случай KYC
Финансовая компания в Дубае, обрабатывающая документы KYC (Знай своего клиента) для клиентов из ЕС, иллюстрирует эту схему. Документы KYC для арабских клиентов содержат арабские имена клиентов, идентификаторы Эмиратов ОАЭ (формат 15 цифр) и адреса на арабском языке наряду с деловой корреспонденцией на английском языке.
Формат идентификатора Эмиратов — 784-XXXX-XXXXXXX-X — имеет специфическую структуру: код страны 784, год рождения, семизначная последовательность, контрольная цифра. Западные инструменты PII, которые не имеют специфических определений сущностей для ОАЭ, не могут обнаружить этот формат идентификатора вообще. Поля с арабскими именами обрабатываются латинским NER, который производит неправильную сегментацию. Результат: систематическая невидимость PII в рабочих процессах соблюдения KYC.
Для организаций, находящихся под обязательствами GDPR, охватывающими эти данные, технический пробел создает прямую регуляторную уязвимость. Статья 32 GDPR требует "соответствующих технических и организационных мер" — система, которая не может обнаружить идентификаторы на 22% языков мира, не является соответствующей технической мерой.
Еврейские и многоязычные документы
Еврейский язык представляет собой связанные проблемы. Еврейский алфавит пишется справа налево; израильские номера удостоверений личности имеют специфический алгоритм проверки (контрольная сумма, подобная алгоритму Луна, для 9-значных израильских номеров удостоверений). Израильские юридические документы могут включать текст на иврите, арабском и английском языках в одном документе — особенно в коммерческих контрактах, где иврит является основным языком, условия обслуживания на английском языке включены по ссылке, а арабский используется для арабоязычных сторон.
Многоязычные документы с несколькими скриптами в одном текстовом блоке требуют обнаружения скрипта перед распознаванием сущностей. Без обнаружения скрипта один проход NER может применить токенизацию на латинице к семитским скриптам, что приводит к совершенно неправильной сегментации.
Исследование, опубликованное в Nature Scientific Reports (2025), специально изучало производительность кросс-языкового NER для обнаружения арабских PII, обнаружив F1-оценки от 0.60 до 0.83 для стандартных моделей против 0.88+ для специально разработанных кросс-языковых подходов (XLM-RoBERTa, дообученный на данных NER для арабского языка).
Требование к кросс-языковой архитектуре
Эффективное обнаружение арабских и еврейских PII требует трех компонентов, которых обычно не хватает инструментам, ориентированным на Запад:
Обработка текста RTL: Соответствие алгоритму Юникода для двунаправленного текста для правильного отображения потока текста и токенизация, учитывающая RTL, которая уважает границы слов в тексте справа налево.
NER, учитывающий морфологию: Либо морфологический анализатор (Farasa для арабского языка или эквивалент), либо трансформер, дообученный на данных NER для арабского/ивритского языка, который изучил морфологическое разнообразие.
Определения сущностей, специфичные для региона: Идентификаторы Эмиратов, израильские удостоверения личности, саудовские национальные удостоверения личности, египетские национальные удостоверения личности и другие форматы идентификаторов, специфичные для MENA, требуют явных определений типов сущностей с спецификациями формата.
Источники: