Presidio перед отправкой текста в ИИ: маскируем данные и проверяем пропуски

MAATRIX · 17 октября 2026 · 8 мин чтения

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

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

Сначала убираем то, что уже известно

Если данные приходят в JSON с полями message, email, phone и customer_id, начните с явного отбора полей. Для определения категории обращения иногда достаточно только message. Зачем передавать известный телефон в распознаватель, чтобы потом надеяться, что он найдёт его среди других символов?

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

Определите, что делать с каждой сущностью. Иногда достаточно заменить её общей меткой. Иногда нужно сохранить различие между двумя людьми, подставив PERSON_1 и PERSON_2. А иногда документ целиком следует оставить внутри организации и не отправлять внешнему сервису. Выбор начинается с назначения обработки, а не с настройки порога уверенности.

Две отдельные операции Presidio

Analyzer ищет сущности и возвращает их тип, границы и оценку. Anonymizer применяет выбранное преобразование к найденным диапазонам. Между этими этапами удобно проверять результат и принимать решение о дальнейшей отправке. Устройство компонентов описано на официальном сайте Presidio.

Названия модулей не означают, что любой результат автоматически стал обезличенным в юридическом или практическом смысле. Человека иногда можно узнать по сочетанию должности, города, даты события и редкой ситуации, даже если имя скрыто. Авторы проекта прямо указывают, что автоматический поиск не гарантирует обнаружение всех чувствительных сведений.

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

Учебный опыт с внутренним номером клиента

Допустим, в вашей системе номер клиента имеет формат CLIENT- и шесть цифр. Это вымышленный формат для примера. Его удобно распознавать правилом без языковой модели. Создайте виртуальное окружение и установите пакеты:

python3 -m venv .venv
. .venv/bin/activate
python -m pip install presidio-analyzer presidio-anonymizer

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

from presidio_analyzer import Pattern, PatternRecognizer
from presidio_anonymizer import AnonymizerEngine
from presidio_anonymizer.entities import OperatorConfig

text = "Клиент CLIENT-123456 сообщает: после обновления не открывается отчёт."

recognizer = PatternRecognizer(
    supported_entity="CUSTOMER_ID",
    supported_language="ru",
    patterns=[Pattern(
        name="internal_customer_id",
        regex=r"\bCLIENT-\d{6}\b",
        score=0.9,
    )],
)

findings = recognizer.analyze(text=text, entities=["CUSTOMER_ID"])
masked = AnonymizerEngine().anonymize(
    text=text,
    analyzer_results=findings,
    operators={
        "CUSTOMER_ID": OperatorConfig(
            "replace", {"new_value": "<CUSTOMER_ID>"}
        )
    },
)
print(masked.text)

После запуска python mask_demo.py номер должен замениться меткой, а описание ошибки остаться. Это узкая проверка конкретного формата. Она не ищет имена, телефоны, адреса и другие данные. Расширять её до рабочего фильтра нужно осознанно, добавляя распознаватели и тесты под свой набор сущностей.

Механизм пользовательских правил разобран в руководстве регулярных распознавателей, а варианты замены — в примере anonymizer. Значение score в учебном правиле задано автором правила; это не измеренная вероятность безошибочного распознавания.

Русский язык требует собственной настройки

Конфигурация по умолчанию ориентирована на английский. Для другого языка нужно выбрать подходящий NLP-компонент, загрузить совместимую модель и настроить распознаватели. Просто передать language="ru" существующему английскому анализатору недостаточно. Это объясняет документация многоязычной обработки.

Имена могут склоняться, смешиваться с названиями компаний и встречаться без фамилии. Телефон может содержать пробелы, скобки, код страны или слова вместо части цифр. Внутренний номер документа может выглядеть как обычная сумма. Для каждого типа нужны характерные примеры вашего потока, а иногда и собственные правила с проверкой контекста.

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

Контекстные слова тоже должны соответствовать языку. «Телефон», «контакт», «договор» и «клиент» помогают интерпретировать соседние значения, но не являются абсолютным доказательством. Составляйте правила так, чтобы они объяснимо решали вашу задачу, и сохраняйте версию конфигурации вместе с результатами испытаний.

Собираем набор, на котором фильтр может ошибиться

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

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

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

Используйте отдельную контрольную выборку, которую не брали для настройки. Иначе легко улучшить правила ровно под знакомые примеры и получить неприятный сюрприз в реальной почте. Подходы к измерению описаны в руководстве оценки Presidio. Числа отчёта всегда связывайте с составом набора, а не представляйте как универсальную точность продукта.

Сохраняем смысл без лишней обратимости

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

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

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

Поведение при ошибке важнее красивого примера

Если анализатор недоступен, обработка не должна незаметно отправлять исходный текст в модель. Заранее определите безопасный режим: остановить задачу, отложить её или направить на ручную обработку. В интерфейсе покажите причину задержки, а оператору отправьте техническое уведомление без полного содержимого документа.

Установите ограничения на длину текста и время обработки. Большие вложения разбирайте отдельно, сохраняя связь фрагментов с исходником. PDF и изображение могут содержать текст в нескольких слоях; маскировка извлечённой строки не удаляет данные из оригинального вложения.

Проверьте логирование на всех этапах: приложение, прокси, система трассировки и очередь ошибок. Для диагностики обычно достаточно номера задания, версии правил, типов найденных сущностей и времени обработки. Временные файлы удаляйте по политике хранения, а доступ к исходникам выдавайте только тем, кому он действительно требуется.

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

VPS для предварительной обработки текста

Для небольшого сервиса с правилами и умеренной NLP-моделью можно начать испытание на MAATRIX Uab Start: 2 vCPU и 4 GB RAM. Более тяжёлые модели, длинные документы и параллельная обработка требуют отдельного замера; Heka Standard с 8 GB может стать следующим стендом. Выберите поддерживаемую Ubuntu или Debian и фиксируйте версии библиотек.

Presidio устанавливается самостоятельно. На VPS MAATRIX его можно разместить перед вашим ботом, n8n или приложением с внешним API. Стоимость модели, которая затем получает текст, рассчитывается отдельно. Сам факт использования фильтра не подтверждает выполнение всех требований к обработке данных — он решает конкретную техническую часть процесса.

Рабочая проверка звучит просто: в модель попадает только необходимый текст, найденные сведения заменены, известные ограничения зафиксированы, а при сбое исходник не уходит наружу. Такой результат полезнее обещания «удаляем всё личное», которое никакая одна демонстрация доказать не может.