Почему ваш инструмент обнаружения PII соответствует...

Скрытый разрыв в соответствии с GDPR

GDPR не имеет языковых предпочтений. Статья 4(1) определяет "персональные данные" без ссылки на язык, на котором они представлены. Немецкий Steuer-ID защищен так же, как и номер социального обеспечения США. Французский NIR регулируется так же, как и номер национального страхования Великобритании.

Но большинство инструментов обнаружения PII были созданы для английского языка.

Исследование, опубликованное на ACL 2024, показало, что гибридные подходы NLP достигают F1-оценок от 0.60 до 0.83 для европейских локалей — но инструменты, работающие только с английским, примененные к неанглийскому тексту, получают почти нулевые оценки для структурированных национальных идентификаторов. Практическое следствие: инструмент анонимизации, развернутый в многонациональной организации, может обнаруживать 95% английских PII, пропуская 40-60% немецких, французских, польских или голландских PII в одном и том же наборе данных.

Это систематический разрыв в соответствии с GDPR, который затрагивает практически каждое многонациональное предприятие, использующее инструменты анонимизации, ориентированные на английский язык.

Почему PII специфичен для языка

Обнаружение PII имеет две составляющие: обнаружение на основе шаблонов (структурированные идентификаторы, такие как налоговые идентификаторы, форматы телефонов) и обнаружение на основе NER (контекстные сущности, такие как имена людей, названия организаций, адреса).

Обе составляющие глубоко специфичны для языка.

Структурированные идентификаторы радикально различаются по странам

Шаблон regex, работающий только с английским для SSN (формат: NNN-NN-NNNN), не будет соответствовать ни одному из этих идентификаторов. Каждый из них требует специфической для страны логики regex и проверки контрольной суммы.

Распознавание именованных сущностей требует моделей, адаптированных к языку

Имена людей на немецком языке следуют другим шаблонам, чем английские имена. "Ханс-Дитер Мюллер" и "Анна-Лена Шрайбер-Кох" распознаются как немецкие имена по контексту — но модель, обученная в основном на английском тексте, часто пропускает их или неправильно классифицирует.

Более проблематично: ложные срабатывания в одном языке могут стать ложными отрицаниями в другом. Трекер проблем GitHub Microsoft Presidio документирует систематические ложные срабатывания для немецких слов, неправильно классифицируемых как английские PII. То же самое слово "Null" (немецкий для "ноль") вызывает ложные срабатывания обнаружения имен в моделях, обученных на английском. Это увеличивает уровень ложных срабатываний до 3 ошибок на 1 реальную сущность в многоязычных производственных средах (Alvaro et al., 2024).

Регуляторные риски

Органы защиты данных ЕС все больше осознают этот разрыв. Несколько национальных DPA выпустили рекомендации или меры принуждения, которые касаются многоязыковой обработки:

Немецкий BfDI: Уточнил, что статья 5(1)(f) GDPR (целостность и конфиденциальность) применяется к данным во всех формах обработки, включая неанглийские данные, обрабатываемые сторонними инструментами.

Французский CNIL: В 2024 году в годовом отчете CNIL отмечались растущие опасения по поводу инструментов ИИ, которые обрабатывают данные на французском языке без возможностей обнаружения PII на французском языке.

Европейские DPA в целом: В соответствии со статьей 25 GDPR (Конфиденциальность по дизайну) технические меры должны быть адекватными для фактических данных, обрабатываемых — что включает неанглийские PII в многонациональных развертываниях.

Практический риск: организация может продемонстрировать 95% эффективности обнаружения PII на английском контенте во время аудита GDPR, но если они также обрабатывают немецкий, французский и польский контент с тем же инструментом, аудит может выявить систематические разрывы для этих языков.

Трехуровневый подход к многоязычному обнаружению PII

Академические исследования и производственные развертывания сошлись на трехуровневой гибридной архитектуре как на наиболее эффективном подходе к многоязычному обнаружению PII:

Уровень 1: Модели spaCy, адаптированные к языку (языки с высоким ресурсом)

spaCy предоставляет обученные компоненты конвейера для 25 языков, включая немецкий, французский, испанский, португальский, итальянский, голландский, русский, китайский, японский, корейский, польский и другие. Эти модели обучены на корпусах на родном языке и понимают морфологию, синтаксис и шаблоны сущностей каждого языка.

Для немецкого: модель spaCy de_core_news_lg понимает составные существительные, склонение и шаблоны имен на немецком. Для французского: fr_core_news_lg обрабатывает шаблоны сущностей на французском, включая титулы, названия мест и форматы организаций.

Модели, адаптированные к языку, достигают значительно более высокой точности и полноты для обнаружения имен, чем кросс-языковые модели, примененные к конкретным языкам с высоким ресурсом.

Уровень 2: Stanza (дополнительные языки)

Библиотека Stanza Стэнфорда предоставляет NER для дополнительных языков, не охваченных коммерческим предложением spaCy, включая хорватский, словенский, украинский и другие. Это расширяет охват языков с меньшими, но все же значительными популяциями говорящих в ЕС.

Уровень 3: XLM-RoBERTa (кросс-языковое покрытие)

Для языков, для которых ни spaCy, ни Stanza не предоставляют обученные модели NER, XLM-RoBERTa обеспечивает кросс-языковую передачу. Обученная на данных Common Crawl на 100 языках, XLM-RoBERTa достигает 91.4% кросс-языковой F1 для обнаружения PII (HuggingFace 2024), обеспечивая разумное обнаружение для языков с низкими ресурсами.

Кросс-языковая модель особенно хорошо обрабатывает код-смешивание (текст на смешанных языках) — свойство, которое становится критически важным для международных организаций, где один документ может содержать текст на нескольких языках.

Специфические для языка типы сущностей

Помимо модели обнаружения, соблюдение требований GDPR требует покрытия типов сущностей для специфических для страны идентификаторов. Многоязычный инструмент должен иметь:

Национальные идентификаторы ЕС:

• DE: Steuer-ID, Sozialversicherungsnummer, Personalausweisnummer
• FR: NIR, SIREN, SIRET, номер телефона
• PL: PESEL, NIP, REGON
• NL: BSN, BurgerServiceNummer
• SE: Personnummer, Samordningsnummer
• ES: DNI, NIE, NIF, CIF
• IT: Codice Fiscale, Partita IVA

Форматы номеров телефонов: Каждая страна ЕС имеет уникальные структуры мобильных префиксов, форматы кодов городов и местные правила набора. +49 (Германия), +33 (Франция), +48 (Польша) требуют специфической для страны проверки.

Форматы адресов: Форматы почтовых кодов радикально различаются — немецкий PLZ (5 цифр), французский код postal (5 цифр, начиная с 01-99), британский почтовый индекс (алфавитно-цифровой, несколько форматов), испанский código postal (5 цифр 01000-52999).

Случай использования: многоязычные документы швейцарской фармацевтической компании

Швейцарская фармацевтическая компания обрабатывает трудовые контракты, содержащие текст на немецком, французском и английском языках в одном и том же документе (в Швейцарии четыре официальных языка). Их текущий инструмент настроен на немецкий и пропускает все PII во французской секции.

Трудовой контракт для сотрудника, работающего в Женеве, ссылается на их французский номер AVS (13 цифр), их швейцарский банковский счет IBAN, их кантон проживания и их имя в французском формате. Инструмент, настроенный на немецкий, пропускает имя во французском формате, не распознает шаблон номера AVS на французском (отличный от формата немецкого AHV-Nummer) и лишь частично распознает IBAN.

Трехуровневый подход обрабатывает документ целиком, автоматически определяя язык для каждого текстового сегмента, применяя модели NER, соответствующие языку, и используя специфические для страны валидаторы regex для каждого типа национального идентификатора — независимо от того, в каком языковом разделе он появляется.

Обработка документов на смешанных языках

Самая сложная проблема многоязычного PII — это внутридокументное смешение языков: документ, который содержит абзацы на разных языках, предложения с код-смешиванием или цитируемый текст на другом языке, чем окружающий контекст.

Примеры:

• Англоязычный контракт немецкой компании с данными о немецких сотрудниках (имена, налоговые идентификаторы)
• Французская форма согласия GDPR, которая включает отрывок политики конфиденциальности на английском языке
• Многоязычный журнал чата службы поддержки, где агент отвечает на английском, но клиент пишет на арабском

XLM-RoBERTa обрабатывает это нативно: его кросс-языковое обучение означает, что он не требует явных языковых деклараций и обрабатывает текст на смешанных языках без необходимости сегментации.

Для производственных развертываний комбинация автоматического определения языка (применяемого на уровне предложений) и кросс-языкового вывода XLM-RoBERTa обеспечивает наиболее надежную обработку документов на смешанных языках.

Практические рекомендации по развертыванию

Аудит языкового охвата вашего текущего инструмента: Попросите вашего текущего поставщика анонимизации предоставить F1-оценки для конкретных языков в ваших данных. "Поддерживает 20 языков" часто означает, что инструмент пропускает текст через Google Translate перед применением NER, обученного на английском — что не то же самое, что обнаружение, адаптированное к языку.

Сопоставьте ваши данные с языками: Проведите инвентаризацию данных, которая включает распределение языков. Многонациональная компания с 70% английских, 20% немецких и 10% французских данных имеет другой риск, чем та, где 95% английских.

Тестирование с образцами национальных идентификаторов: Создайте тестовый набор данных с 10 примерами каждого из национальных идентификаторов, относящихся к вашей деятельности (Steuer-ID, NIR, PESEL, BSN и т.д.), и проверьте уровни обнаружения. Это более быстрый аудит, чем крупномасштабная оценка F1.

Пересмотрите ваши DPIA: Если у вас есть Оценки воздействия на защиту данных, охватывающие ваши инструменты анонимизации, убедитесь, что анализ языкового охвата включен. Неполная DPIA, которая предполагает только охват английским, может потребовать обновления.

Двигатель обнаружения PII anonym.legal использует трехуровневый многоязычный подход: модели spaCy, адаптированные к языку, для 25 языков с высоким ресурсом, Stanza для дополнительного языкового охвата и кросс-языковые трансформеры XLM-RoBERTa для общего охвата 48 языков. Специфические для страны типы сущностей для всех государств-членов ЕС включены.

Источники:

• ACL 2024: Гибридное обнаружение PII для европейских локалей
• Масштабируемая многоязычная аннотационная структура PII (arXiv 2025)
• Бенчмарки кросс-языкового NER XLM-RoBERTa от HuggingFace
• Проблема Microsoft Presidio GitHub #1071 — Ложные срабатывания на немецком
• Руководящие принципы EDPB по статье 25 Конфиденциальность по дизайну
• Годовой отчет CNIL 2024