Почему самостоятельные инструменты обнаружения PII не проходят аудиты соответствия
GDPR требует доказательств. Вы должны подтвердить, что обезличивание персональных данных выполнялось одинаково каждый раз. Аудиторы надзорных органов проверяют именно это. Они хотят видеть чёткий и последовательный метод, применяемый ко всем данным.
Самостоятельно развёрнутый Presidio имеет здесь реальную проблему. Это не вопрос конфигурации. Это фундаментальное ограничение самостоятельно развёртываемых NLP-инструментов.
Что такое дрейф окружения?
Самостоятельно развёрнутый Presidio работает в среде разработки, в staging и в продакшне. Каждая из них может вести себя по-разному. Поэтому один и тот же входной документ может давать разные результаты в каждой из них.
Это называется дрейфом окружения. У него четыре основных причины.
Дрейф версий моделей
Модели spaCy версионируются. Модели en_core_web_lg 3.4.4 и en_core_web_lg 3.5.1 обучались на разных данных и имеют разную архитектуру. Поэтому один и тот же документ может давать разные результаты NER с каждой версией.
Типичная картина выглядит так:
- Dev:
en_core_web_lg 3.4.4— установлено при старте проекта - Staging:
en_core_web_lg 3.5.0— обновлено в ходе плановых работ - Prodakшн:
en_core_web_lg 3.5.1— обновлено при патче безопасности
Три среды. Три версии модели. Три разных результата обнаружения. Тесты проходят в staging. Но продакшн использует другую модель. Разрыв остаётся незамеченным.
Дрейф версий зависимостей
spaCy 3.4.x и 3.5.x по-разному разбивают предложения. Это влияет на то, как обнаруживаются имена вблизи границ предложений. Эти изменения зафиксированы в примечаниях к релизам spaCy. Но большинство команд не проверяет их на предмет влияния на обработку персональных данных.
Дрейф конфигурации
Пороги оценки, установленные при разработке, могут не переноситься в продакшн. Пользовательские словари также могут различаться между средами. Такие расхождения распространены. Они редко отслеживаются. О том, что проверяют аудиторы, — в нашем руководстве по соответствию GDPR.
Различия оборудования
Математика в NLP-моделях не одинакова на всех процессорах и GPU. Потребительский ноутбук и сервер могут давать слегка различающиеся результаты оценки. Поэтому некоторые имена могут обнаруживаться на одной машине, но не на другой.
Реальная аудиторская находка
Банк проверил свою самостоятельно развёрнутую установку Presidio.
Тестовая среда: Presidio с spaCy 3.4.4 на кластере staging. Рабочая среда: Presidio с spaCy 3.5.1 на производственном кластере.
Они прогнали один и тот же набор документов через обе среды и сравнили результаты. Вывод: в 3% документов результаты обезличивания персональных данных различались. Некоторые имена обнаруживались в staging, но не в продакшне. В некоторых случаях обнаруженные текстовые фрагменты различались.
Аудиторское заключение было прямым: «Компания не может подтвердить последовательное применение технических мер по обезличиванию персональных данных из-за различий в результатах обнаружения, зависящих от конфигурации среды».
Статья 32 GDPR требует надлежащих технических мер. Правила EDPB по обезличиванию персональных данных требуют последовательности и воспроизводимости. Уровень в 3% при 100 000 документов в месяц означает 3 000 документов с непоследовательными результатами каждый месяц. Часть из них — ложные отрицания: персональные данные, которые staging обнаружил бы, остаются в рабочем выводе. Это нарушение соответствия требованиям.
Затем банк перешёл на управляемый SaaS. Аудиторское замечание было закрыто. О том, как управляемые решения справляются с этой проблемой, — на нашей странице безопасности и соответствия.
Почему управляемые сервисы устроены иначе
Управляемый сервис работает на одной версии движка. Все пользователи используют одну и ту же версию одновременно. Обновления моделей применяются из одного места. Конфигурация также управляется централизованно с полным журналом изменений. Оборудование пользователя не влияет на результаты.
Поэтому один и тот же документ, обработанный сегодня, даёт тот же результат в следующем месяце. Если версия движка изменилась, это изменение зафиксировано и версионировано.
Ключевое отличие — в журнале аудита.
Журнал аудита при самостоятельном развёртывании:
- «Использовался Presidio 2.2.35 с spaCy
en_core_web_lg 3.5.1на Ubuntu 22.04». - Это та же версия, что и в staging? Неизвестно.
- Изменилась ли модель с момента обработки этого документа? Неизвестно без отслеживания.
- Совпадает ли порог оценки с тестовым? Зависит от управления конфигурацией.
Журнал аудита управляемого сервиса:
- «Использовался API anonym.legal, версия движка 4.22.1, на 2025-03-15T14:22:31Z».
- Одна и та же версия для всех пользователей? Да.
- Изменилась ли она? Версии движка зафиксированы. Версия 4.22.1 всегда означает один и тот же движок.
- Воспроизводима ли конфигурация? Да. Идентификатор пресета регистрируется. Конфигурация для этой версии может быть получена повторно.
Журнал управляемого сервиса прозрачен. Журнал самостоятельного развёртывания требует тщательного ведения, которое большинство команд пропускает.
Как улучшить последовательность при самостоятельном развёртывании
Если самостоятельное развёртывание необходимо, дрейф можно сократить четырьмя шагами.
Во-первых, закрепите версии моделей. Зафиксируйте точные версии моделей во всех файлах развёртывания. Заблокируйте автоматические обновления. Отслеживайте версии в системе контроля версий.
Затем заморозьте образы контейнеров. Собирайте Docker-образы с зафиксированными версиями моделей. Добавляйте тег с версией модели, версией Presidio и датой. Не обновляйте базовые образы без предварительного тестирования.
Также храните конфигурацию в коде. Все настройки Presidio — детекторы, пороги оценки, активные языки — храните в файлах под контролем версий. Развёртывайте конфигурацию вместе с приложением.
Наконец, тестируйте в разных средах. После любого обновления прогоняйте фиксированный набор тестовых документов через новую конфигурацию. Сравнивайте результаты с сохранённым эталоном. Автоматизируйте эту проверку. О распространённых вопросах автоматизированного регрессионного тестирования PII — в FAQ.
Эти шаги помогают. Но они также добавляют работы. Управляемый сервис обеспечивает ту же последовательность без дополнительных усилий.
Итог
Последовательное обезличивание персональных данных не упоминается в рекламных материалах. Но оно становится критически важным, когда аудиторы запрашивают доказательства.
Без активной работы самостоятельные инструменты обнаружения персональных данных дрейфуют. Изменения версий вносят незаметные пробелы. Эти пробелы проявляются как аудиторские замечания.
Управляемые сервисы обеспечивают последовательность по умолчанию. Движок работает из одного места. Конфигурации пользователей не влияют на результаты. Для команд, ориентированных на соответствие требованиям, это прямое преимущество.