Прогалина у відповідності для текстів із правим написанням
GDPR не закінчується на Босфорі. Компанії ЄС, що використовують інструменти для латиниці, мають сліпу зону. Вона реальна і здебільшого ігнорується.
Проблема — не лише напрямок тексту. Письмо справа наліво потребує іншої токенізації. Інших правил сегментації. Межі між іменованими сутностями працюють інакше, ніж у текстах зліва направо. Системи NER, навчені на англійській мові, застосовують правила LTR. Ці правила ламаються на RTL-тексті. Вони визначають хибні межі сутностей.
Арабська морфологія ускладнює завдання. Мова побудована на коренях. Один корінь дає десятки словоформ. Ім'я на кшталт Мухаммед може з'являтися як «Аль-Мухаммед», «бін Мухаммед» або «Мухаммед аль-Рашид». Регекс-шаблони для західних імен пропускають ці форми. Моделі, навчені на англійській мові, також їх пропускають.
GDPR не розглядає мову як межу відповідності. Компанія ЄС, що обробляє кореспонденцію клієнтів із регіону MENA, повинна дотримуватися тих самих правил, що і для французької пошти. Пропуск персональних даних у RTL-тексті — це правовий збій відповідно до Статті 32 GDPR.
Сценарій використання KYC
Фінтех із Дубая, що обробляє KYC-документи для клієнтів ЄС, наочно ілюструє цю проблему.
KYC-файли для арабських клієнтів містять імена в RTL-письмі, ідентифікаційні картки Emirates ID і RTL-адреси. Вони розміщені поруч із діловим текстом англійською мовою.
Формат Emirates ID: 784-XXXX-XXXXXXX-X. Код країни 784. Рік народження. Сім цифр. Контрольна цифра. Західні інструменти PII без визначення сутностей ОАЕ не можуть знайти цей формат. Поля імен проходять через NER для латинського письма. Сегментація хибна. PII стає невидимим у робочому процесі.
Для компаній із зобов'язаннями GDPR щодо цих даних прогалина створює реальний правовий ризик. Стаття 32 GDPR вимагає відповідних технічних заходів. Інструмент, що пропускає ідентифікатори у 22% мов світу, не є відповідним заходом.
Іврит і документи зі змішаними мовами
Іврит має схожі проблеми. Письмо справа наліво. Ізраїльські ідентифікаційні номери використовують контрольну суму — перевірку за алгоритмом Луна для дев'яти цифр.
Ізраїльські юридичні документи часто поєднують іврит, арабський текст та англійську в одному файлі. Це типово для договорів, де іврит є основною мовою, а англійські терміни включені через посилання.
Файли зі змішаним письмом потребують визначення мови перед 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 для правильного відображення тексту. RTL-сумісна токенізація, що правильно визначає межі слів у тексті справа наліво.
NER з урахуванням морфології: морфологічний аналізатор на кшталт Farasa для арабської або трансформерна модель, донавчена на RTL NER-даних. Модель повинна враховувати морфологічну варіативність.
Сутності, специфічні для регіону: Emirates ID, ізраїльський ID, саудівський національний ID та єгипетський національний ID — кожен потребує явних визначень із правилами формату. Універсальні інструменти для заходу їх не мають.
Дивіться, як наш конвеєр багатомовного NER обробляє визначення мов письма для 48 мов. Повний список типів ідентифікаторів MENA, які ми підтримуємо, — у каталозі сутностей. Наш посібник із відповідності GDPR охоплює, як прогалини у виявленні створюють ризики відповідно до Статті 32.