Проблема соответствия RTL
GDPR не заканчивается у Босфора. Европейские компании, использующие инструменты на основе латинского алфавита, имеют слепое пятно — реальное и по большей части игнорируемое.
Проблема не только в направлении текста. Скрипты с написанием справа налево (RTL) требуют иной токенизации и сегментации. Границы сущностей работают иначе, чем в LTR-текстах. NER-системы, обученные на английском, применяют LTR-правила. Эти правила ломаются на RTL-тексте и дают неверные границы сущностей.
Арабская морфология усложняет задачу дополнительно. Язык использует корневую систему: один корень даёт десятки словоформ. Имя Мухаммад может появляться как «Аль-Мухаммад», «Бин Мухаммад» или «Мухаммад аль-Рашид». Регулярные выражения, созданные для западных имён, пропускают эти формы. Модели, обученные на английском, тоже.
GDPR не рассматривает язык как границу соответствия. Европейская компания, обрабатывающая переписку клиентов из стран MENA, должна соблюдать те же правила, что и для французской переписки. Пропуск PII в RTL-тексте — это правовой сбой по статье 32 GDPR.
Случай использования KYC
Дубайская финтех-компания, обрабатывающая KYC-документы для клиентов из ЕС, наглядно демонстрирует проблему.
Файлы KYC арабских клиентов содержат имена в RTL-скрипте, удостоверения Emirates ID и RTL-адреса — всё это соседствует с деловым текстом на английском.
Формат Emirates ID: 784-XXXX-XXXXXXX-X. Код страны 784, год рождения, семь цифр, контрольная цифра. Западные инструменты PII без определений для ОАЭ не найдут этот формат. Поля имён проходят через латинский NER — сегментация неверна, PII становится невидимым в рабочем процессе.
Для компаний с обязательствами по GDPR в отношении этих данных пробел создаёт реальный правовой риск. Статья 32 GDPR требует надлежащих технических мер. Инструмент, пропускающий идентификаторы на 22% мировых языков, таковой мерой не является.
Иврит и смешанноязычные документы
Иврит создаёт аналогичные проблемы. Скрипт пишется справа налево. Израильские ID используют контрольную сумму — тест, аналогичный алгоритму Луна, для девятизначного числа.
Израильские юридические документы часто смешивают иврит, арабский и английский в одном файле. Это характерно для договоров, где иврит — основной язык, а английские термины добавлены по ссылке.
Смешанноязычные документы требуют определения скрипта перед NER. Без этого единственный проход NER применяет латинские правила к RTL-скриптам — с неверным результатом.
Исследование Nature Scientific Reports 2025 года протестировало кросс-лингвальный NER на RTL-PII. Стандартные модели показали F1 от 0,60 до 0,83. XLM-RoBERTa, дообученная на RTL-данных NER, — 0,88 и выше.
Требование к кросс-лингвальной архитектуре
Качественное обнаружение PII в RTL-текстах требует трёх вещей, которых западно-ориентированным инструментам обычно не хватает.
Обработка RTL-текста: соответствие Unicode Bidirectional Algorithm для корректного потока текста, RTL-совместимая токенизация для поиска границ слов.
NER с учётом морфологии: морфологический анализатор — например, Farasa для арабского — или трансформерная модель, дообученная на RTL-данных NER с учётом морфологических вариаций.
Региональные типы сущностей: Emirates ID, израильский ID, саудовский National ID и египетский National ID — каждый нуждается в явном определении с правилами формата. Универсальные западные инструменты этого не имеют.