Содержание
  1. Карта выбора под ограничения
  2. Ручной эталон и фактический выход
  3. Положительный и отрицательный случаи
  4. Продуктовый путь, API и доступ
  5. Границы обещаний
  6. Согласование scope и приёмки
  7. Частые вопросы
Подборки и сравнения

Обезличивание текста: Presidio, Google DLP, AWS

7 ноября 2026 · 10 минут чтения

Обезличивание текста: Presidio, Google DLP, AWS — три разных пути к одной задаче. Presidio живёт на вашем железе и даёт настраиваемые распознаватели с операторами замены. Google Sensitive Data Protection выполняет синхронный поиск и преобразование через content.deidentify. AWS Comprehend ищет сущности в реальном времени и редактирует документы отдельным асинхронным заданием. Ниже — карта выбора, учебный вход и проверка результата.

Карта выбора под ограничения

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

Документация Presidio на presidio.dataprivacystack.org описывает проект как набор модулей для идентификации и анонимизации приватных сущностей в тексте и изображениях: номера карт, имена, локации, номера соцстрахования, биткоин-кошельки, телефоны США, финансовые данные. Проект перешёл в community-owned Data Privacy Stack. Модули: analyzer для поиска, anonymizer для замены, image redactor для картинок, structured для табличных данных. Развёртывание идёт от Python и PySpark до Docker и Kubernetes. Документация прямо предупреждает: автоматическая детекция не гарантирует нахождение всей чувствительной информации, поэтому нужны дополнительные системы и защиты.

Google Sensitive Data Protection в документации на cloud.google.com описывает обезличивание как удаление идентифицирующей информации: API находит PII и применяет преобразование — маскирование, удаление или иное сокрытие. Методы включают замену символов на звёздочку или решётку, замену каждого вхождения на токен, шифрование с случайным или заданным ключом. Вызов content.deidentify состоит из трёх частей: данные для проверки (ContentItem), конфигурация поиска (InspectConfig) и конфигурация преобразования (DeidentifyConfig).

AWS Comprehend в документации на docs.aws.amazon.com описывает поиск PII-сущностей в английском и испанском тексте. Реальный анализ одного документа идёт через консоль или API, вход ограничен 100 килобайтами UTF-8. Асинхронное пакетное задание возвращает копию входного текста с редактированием каждой сущности.

Ограничение Presidio Google SDP AWS Comprehend
Где живут данные ваша инфраструктура облако Google облако AWS
Языки в документации несколько языков infoTypes по регионам английский, испанский
Поиск и замена analyzer + anonymizer один вызов content.deidentify поиск и редактирование раздельно
Редактирование документа операторы замены синхронный ответ асинхронное задание
Настройка сущностей свои распознаватели свои infoType-детекторы фиксированный список типов

Карта не объявляет юридически достаточную анонимность и не обещает стопроцентную детекцию. Она сужает выбор до одного кандидата, которого вы проверите на своём тексте.

Ручной эталон и фактический выход

Разделите два артефакта. Ручной эталон — то, что вы объявляете правильным ответом до запуска. Фактический выход модели — то, что вернул продукт. Совпадение проверяется отдельно для каждого.

Учебный вход для этой статьи:

ТЕКСТ
Email me at alex@example.test. Order A-17 costs 40 EUR.

Для проверки зафиксирована вся строка. Подстрока alex@example.test занимает позиции от 12 до 29. Проверьте срез до запуска: text[12:29] == "alex@example.test". Ошибка на единицу оставляет букву t в конце, и эталон перестаёт совпадать.

Ручной эталон после замены email:

ТЕКСТ
Email me at [EMAIL]. Order A-17 costs 40 EUR.

Точка после email, номер заказа A-17 и сумма 40 EUR сохраняются. Это контракт приёмки, который вы фиксируете заранее.

Эталон с [EMAIL] относится к Presidio с настроенным оператором replace и к Google с replaceConfig. Описанное асинхронное редактирование AWS Comprehend возвращает маску, поэтому для него заранее фиксируют отдельный эталон: Email me at *****************. Order A-17 costs 40 EUR. при замене каждого символа email звёздочкой. Для каждого кандидата проверяют детекцию, границы и результат выбранной операции по его эталону; несовпадение маски AWS с токеном [EMAIL] само по себе не является дефектом. Положительная проба с [EMAIL] ниже проверяет только пути с оператором replace. Google в документации показывает замену через replaceConfig с newValue: строка My name is Alicia Abernathy, and my email address is aabernathy@example.com. превращается в My name is Alicia Abernathy, and my email address is [email-address].. Ответ содержит transformedBytes и transformationSummaries со счётчиком и кодом SUCCESS.

redactConfig удаляет значение полностью: та же строка возвращается как My name is Alicia Abernathy, and my email address is .. characterMaskConfig заменяет заданное число символов фиксированным знаком. В примере документации с # и игнорированием . и @ получается ##########@#######.###.. Три преобразования дают три разных результата, и эталон подходит только к одному из них.

Синхронный анализ AWS Comprehend возвращает список сущностей. Для входа Hello Paulo Santos. The latest statement for your credit card account 1111-0000-1111-0000 was mailed to 123 Any Street, Seattle, WA 98109. ответ содержит NAME со спаном 6–18, CREDIT_DEBIT_NUMBER со спаном 69–88 и ADDRESS со спаном 103–138. Оценки уверенности в примере: 0.9999669790267944, 0.8905550241470337, 0.9999889731407166. Редактирование выполняется отдельным асинхронным заданием и даёт Hello ***** ******. The latest statement for your credit card account ******************* was mailed to *** *** ******* ******** ** *****..

Фактический выход модели остаётся неизмеренным, пока вы не запустили продукт на своём входе. Ручной эталон задаёт ожидаемое содержание результата.

Положительный и отрицательный случаи

Проверка строится на точных данных. Возьмите вход из предыдущего раздела и прогоните четыре сценария.

Положительный случай: детектор находит alex@example.test, спан равен 12–29, оператор замены даёт [EMAIL]. Результат совпадает с эталоном посимвольно.

Отрицательный случай с границей: спан заканчивается на 28. Срез text[12:28] равен alex@example.tes, буква t остаётся в тексте. Результат не принят.

Отрицательный случай с лишней маскировкой: продукт маскирует A-17 или 40 EUR, когда разрешён только email. Результат не принят, даже если email найден верно.

Отрицательный случай без сущности: вход Order A-17 costs 40 EUR. не содержит email. Эталон совпадает с входом без изменений. Любая вставка в текст означает ложное срабатывание.

Отдельно проверьте вымышленный адрес с доменом .test. Если детектор не выделил его, отсутствие находки не считается успешным обезличиванием. Сначала подтвердите, что продукт поддерживает такой вход, затем проверьте детерминированный путь оператора на известной сущности.

Сценарий Вход Ожидание Вердикт при отклонении
Положительный email на 12–29 [EMAIL], остальное сохранено принято
Граница спана end = 28 буква t остаётся не принято
Лишняя маскировка email и заказ заказ без изменений не принято
Без сущности только заказ и сумма текст без изменений не принято при вставке

Такая матрица отделяет ошибку детекции от ошибки преобразования. Продукт может найти сущность и применить не тот оператор — это разные дефекты с разными исправлениями.

Продуктовый путь, API и доступ

Каждый продукт требует своих условий доступа. Google в документации указывает: для клиентских библиотек нужен проект Google Cloud и Application Default Credentials, для REST-вызовов клиентская библиотека не требуется. Вызов идёт методом content.deidentify, тело — JSON с item, deidentifyConfig и inspectConfig. Если в InspectConfig не указать infoTypes, поиск идёт по набору ALL_BASIC, часть которого может быть не нужна и добавляет задержку.

AWS Comprehend работает через консоль или API. Реальный анализ одного документа ограничен 100 килобайтами UTF-8. Редактирование запускается асинхронным пакетным заданием. Список сущностей фиксирован: универсальные типы вроде EMAIL, PHONE, CREDIT_DEBIT_NUMBER, IP_ADDRESS, NAME и страновые вроде UK_NATIONAL_INSURANCE_NUMBER, IN_AADHAAR, SSN.

Presidio устанавливается как Python-пакеты presidio-analyzer и presidio-anonymizer. Документация NVIDIA NeMo Guardrails показывает подключение: pip install presidio-analyzer presidio-anonymizer spacy, затем загрузка модели en_core_web_lg для spaCy. Там же описан порог score_threshold со значением по умолчанию 0.2 для отсечения ложных срабатываний и свои распознаватели через deny_list.

Промпт для планирования проверки перед запуском:

ТЕКСТ12 строк
Ты помогаешь спланировать проверку обезличивания текста.
Вход: [ваш текст]
Разрешённые сущности: [список, например EMAIL_ADDRESS]
Запрещённые изменения: [что должно остаться, например номера заказов и суммы]
Для каждого кандидата — Presidio, Google Sensitive Data Protection, AWS Comprehend — верни:
1. Поддерживает ли он нужный язык и тип сущности по своей документации.
2. Точный спан сущности во входе в виде start:end и проверку среза.
3. Ожидаемый текст после преобразования.
4. Тип операции: замена, удаление, маскирование, токенизация.
5. Условия доступа: проект, ключи, аутентификация, лимит входа.
6. Три отрицательных случая: сдвиг границы, лишняя маскировка, вход без сущности.
Не утверждай, что продукт справится. Отметь, что фактический выход проверяется запуском.

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

Границы обещаний

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

Google в документации описывает лимит находок: при более чем 3000 находок возвращается сообщение Too many findings to de-identify. Retry with a smaller request., а список находок представляет произвольное подмножество. Для полного набора запрос разбивают на меньшие пакеты.

AWS Comprehend ограничивает реальный анализ 100 килобайтами UTF-8 и разделяет поиск и редактирование на разные операции.

Скорость зависит от числа infoTypes в запросе, объёма текста и выбранного преобразования. Google в документации предупреждает: поиск ненужных infoTypes добавляет задержку. Приватность определяется местом обработки: Presidio работает на вашей инфраструктуре, Google и AWS обрабатывают данные в своих облаках. Юридическую достаточность анонимности не подтверждает ни один из документов.

Русский язык на английском примере не проверяется. Документация AWS называет английский и испанский. Документация Presidio говорит о нескольких языках без перечисления. Для русского текста нужна отдельная проверка поддержки входа.

Согласование scope и приёмки

Зафиксируйте письменно пять пунктов до запуска.

Scope: какие сущности разрешено менять, какие остаются нетронутыми, на каком языке вход. Пример: только EMAIL_ADDRESS в английском тексте, номера заказов и суммы сохраняются.

Пример: полный вход, спан с точными границами, ожидаемый текст после преобразования. Учебный вход выше годится как образец формата.

Схема данных: тип входа — строка или таблица. Google различает InfoTypeTransformations для свободного текста и RecordTransformations для табличных данных. Для RecordTransformations в content.deidentify поле item должно быть типа Table.

Критерии приёмки: посимвольное совпадение с эталоном, сохранение разрешённых фрагментов, отсутствие вставок на входе без сущностей.

Ограничения: лимит находок, лимит размера входа, условия доступа, место обработки данных.

Пункт Что фиксируем Пример
Scope сущности, язык, запрет на изменения только email, английский
Пример вход, спан, эталон alex@example.test, 12–29, [EMAIL]
Схема строка или таблица строка свободного текста
Приёмка совпадение и сохранение посимвольно, заказ цел
Ограничения лимиты и доступ 3000 находок, проект Google

После согласования выберите кандидата по карте из первого раздела и прогоните матрицу из третьего. Расхождение с эталоном разбирайте по типу: детекция, границы, оператор.

Частые вопросы

Чем Presidio отличается от Google DLP и AWS Comprehend по месту обработки?

Presidio разворачивается на вашей инфраструктуре: от Python и PySpark до Docker и Kubernetes, как описывает документация проекта. Google Sensitive Data Protection и AWS Comprehend обрабатывают данные в своих облаках. Выбор места определяет требования к передаче данных и условия доступа.

Можно ли обезличить русский текст этими инструментами?

Документация AWS Comprehend называет английский и испанский языки. Документация Presidio говорит о нескольких языках без перечисления. Для русского текста нужна отдельная проверка поддержки входа на вашем наборе сущностей.

Как устроен результат анализа AWS Comprehend?

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

Что делать, если преобразование затронуло лишние данные?

Сузьте список infoTypes или сущностей до разрешённых. В Google укажите конкретные infoTypes в InspectConfig вместо набора по умолчанию. В Presidio настройте распознаватели и операторы под нужные типы.

Как проверить, что границы сущности определены верно?

Сверьте срез текста по началу и концу спана с ожидаемой подстрокой до запуска преобразования. Для учебного входа text[12:29] равен alex@example.test. Сдвиг на единицу оставляет лишний символ и ломает эталон.

Читайте также

3 материала