Чтобы передать обращения клиентов в LLM для классификации, сначала выделите нужный текст, найдите чувствительные фрагменты и замените их по правилам задачи. Presidio помогает обнаруживать и преобразовывать такие фрагменты, но не гарантирует обнаружения всех персональных данных. Одной замены имени на [PERSON] недостаточно, чтобы считать сообщение анонимным. Это ограничение прямо указано в документации проекта.
FAQ адресован руководителям поддержки и разработчикам интеграций. Он разбирает подготовку текста жалоб: что скрыть, как сохранить различимость клиентов и почему детектор пропускает данные. Это технический разбор, а не юридическое заключение о допустимости передачи конкретному провайдеру. Документация сверена 4 ноября 2026 года. Presidio здесь не запускался; приведённые преобразования — предлагаемые учебные примеры, а не результаты теста библиотеки.
Содержание
- Что именно делает Presidio перед отправкой текста в ИИ?
- Какие данные удалить ещё до запуска детектора?
- Чем заменить найденные имена, телефоны и адреса?
- Как сохранить связь между сообщениями одного клиента?
- Достаточно ли указать русский язык?
- Почему Presidio пропускает внутренние номера и необычные контакты?
- Почему после очистки исчезает полезный смысл жалобы?
- Как понять, что качество очистки подходит задаче?
- Можно ли той же обработкой очистить PDF и скриншоты?
- Куда поставить Presidio и что делать при ошибке обработки?
- Можно ли после замен считать передачу данных разрешённой?
Что именно делает Presidio перед отправкой текста в ИИ?
Presidio разделяет обнаружение и преобразование. Analyzer находит участки текста, Anonymizer применяет к ним выбранные операции. Найти фамилию и решить, чем её заменить, — разные задачи. Поэтому настройка детектора сама по себе ещё не определяет содержимое запроса к LLM. Архитектура описана в разделе о работе с текстом.
Для классификатора причин обращений обычно нужен смысл: «оплату списали повторно», «товар доставили повреждённым», «не удаётся войти». Имя, контакт и идентификатор заказа часто можно исключить. Для подготовки персонального ответа требования будут другими: обратное связывание ответа с карточкой клиента лучше выполнять внутри своей системы после генерации.
Сначала сформулируйте результат: например, получить категорию жалобы и краткое описание проблемы. Затем определите разрешённые входные поля. Такой порядок помогает не отправлять целиком карточку CRM только потому, что её удобно выгрузить.
Какие данные удалить ещё до запуска детектора?
Исключите поля, заведомо ненужные для анализа. Не стоит искать телефон в тексте, если интеграция сама добавляет отдельное поле phone. Предлагаемая схема для классификации жалоб:
| Поле исходной записи | Предлагаемое действие | Что остаётся полезным |
|---|---|---|
| Контактный телефон и почта | Не включать в запрос | Причина обращения |
| ФИО и подпись сотрудника | Удалить либо заменить локальным псевдонимом | Роль участника |
| Текст жалобы | Обработать детектором и правилами | Описание проблемы |
| Номер заказа | Оставить во внутренней системе | Связь с заказом после ответа |
| Вложение | Не отправлять вместе с текстом автоматически | Отдельное решение по обработке файла |
Это пример проектного решения, а не встроенная политика Presidio. Состав полей зависит от задачи и требований компании. Для данных в таблицах у проекта есть Presidio Structured: обработка ячеек и колонок отличается от передачи всей строки как произвольного текста.
Чем заменить найденные имена, телефоны и адреса?
Выбирайте операцию по тому, что должно сохраниться после обработки. В Anonymizer предусмотрены, в частности, replace, redact, mask и encrypt: замена, удаление, частичное скрытие и шифрование. Параметры и поведение следует сверять с документацией операторов.
Для определения темы жалобы предлагается заменять контактные данные понятными метками: [EMAIL], [PHONE]. Удаление подходит, когда сам факт наличия фрагмента не нужен. Частичная маска оставляет часть исходного значения: её нельзя автоматически считать достаточной для отправки во внешний сервис.
Учебный пример: «Я Клиент А. По заказу ЗАКАЗ-А оплату списали повторно, ответьте на ПОЧТА-А» можно преобразовать в «Я [CLIENT_1]. По заказу [ORDER_1] оплату списали повторно, ответьте на [EMAIL]». Сохраняется причина жалобы, но точные значения не участвуют в классификации. Какое преобразование действительно выполнит ваша конфигурация, нужно проверять отдельно.
Как сохранить связь между сообщениями одного клиента?
Используйте согласованные псевдонимы в пределах нужной области. Если один участник получил метку [CLIENT_1], его последующие сообщения в том же диалоге должны сохранять эту метку. Другому участнику нужна другая. Замена всех имён на [PERSON] может смешать роли и испортить анализ разговора.
Предлагаемая область действия — отдельный диалог, если аналитике не требуется связывать клиента между обращениями. Таблицу соответствий храните внутри доверенной системы и не добавляйте её в промпт. Не расширяйте срок и область хранения только ради удобства разработчика.
Это проектная рекомендация. В официальном FAQ Presidio есть ссылка на пример псевдонимизации, который можно адаптировать. Наличие обратимого соответствия не доказывает необратимое обезличивание: возможность восстановить связь нужно учитывать отдельно.
Достаточно ли указать русский язык?
Нет. Для русского текста должны согласоваться NLP-модель, конфигурация языка и распознаватели нужных сущностей. Языковой код сам по себе не добавляет модели знание русских фамилий, склонений и адресов. Проект описывает адаптацию в руководстве по многоязычной обработке.
Практический вопрос разработчику: какая модель распознаёт имена, какие правила ищут контакты и какие сущности вообще включены для русского языка? Ответ «библиотека поддерживает несколько языков» не заменяет перечня конкретных компонентов.
Для проверки подготовьте разные формы: имя в подписи, фамилию в косвенном падеже, адрес внутри цитаты, смешанный русский и английский текст. Это предлагаемый набор примеров. Результаты и точность на русском в данной статье не измерялись.
Почему Presidio пропускает внутренние номера и необычные контакты?
Универсальный детектор не обязан знать формат вашей CRM. Номер договора, код клиента или внутренний логин могут выглядеть как обычные слова. Для таких значений нужен отдельный распознаватель либо удаление соответствующего поля до анализа.
В Presidio можно добавлять распознаватели на основе регулярных выражений, списков значений и собственной логики. Устройство расширений описано в руководстве по распознавателям. Не следует считать любую последовательность цифр персональным идентификатором: тот же шаблон может совпасть с артикулом товара.
Предлагаемый пример: если внутренний идентификатор всегда имеет префикс CLIENT-, правило должно учитывать этот формат и окружающий контекст. Затем нужны отрицательные примеры — похожие артикулы, которые удалять нельзя. Такой сценарий здесь не запускался и не предлагается как готовое универсальное правило.
Почему после очистки исчезает полезный смысл жалобы?
Детектор может принять обычный текст за чувствительную сущность. Это ложное срабатывание. Например, широкий числовой шаблон способен затронуть характеристику товара; конкретный результат зависит от конфигурации. В официальном FAQ обсуждаются настройка порога, выбор распознавателей и компромисс между пропусками и ложными срабатываниями. Источник: ошибки детекции.
Разбирайте причину на отдельных примерах: какой распознаватель сработал, какой участок он выделил и почему его нельзя удалять. Поднимать общий порог только ради более красивого текста опасно: вместе с лишними заменами могут исчезнуть и нужные находки.
Разрешение сохранять отдельные слова должно быть узким и обоснованным. Например, название товарной линейки можно сохранить для классификации дефектов, но это не основание разрешить все похожие имена. После изменения правила проверьте и полезный текст, и чувствительные фрагменты, которые раньше обнаруживались.
Как понять, что качество очистки подходит задаче?
Оцените отдельно пропуски и лишние удаления. Полнота, или recall, показывает долю обнаруженных чувствительных сущностей среди всех размеченных. Точность, или precision, — долю правильных находок среди всех находок детектора. Эти определения и формулы приведены в руководстве по оценке Presidio.
Предлагаемый порядок: вручную разметить разрешённую выборку, отделить примеры для настройки от контрольных, сравнить выделенные фрагменты с разметкой. Считайте ошибки отдельно по типам сущностей: общий показатель может скрыть пропуски адресов при хорошем поиске электронной почты. Проверяйте полные границы значения, а не только факт нахождения его части.
Параллельно сравните классификацию жалоб до и после преобразования в разрешённой тестовой среде. Категория «повторное списание» должна оставаться различимой. Порог готовности задаёт владелец процесса вместе с ответственными за данные; универсального процента, который разрешает любую передачу, здесь нет.
Можно ли той же обработкой очистить PDF и скриншоты?
Текстовый детектор не очищает изображение автоматически. Для изображений у Presidio есть отдельный Image Redactor, использующий OCR и обнаружение чувствительных сущностей. Поэтому качество распознавания текста влияет на последующие замены. Документация Image Redactor.
Если обращение содержит скриншот, обработка только текстового поля оставляет вложение отдельным каналом передачи данных. Предлагаемое правило для первого сценария — исключить вложения из отправки, пока для них не определён собственный маршрут обработки.
Для PDF также различайте извлечённый текст и сам файл. Очистка текстовой копии не означает удаления данных из исходного документа. О подготовке текста рассказывает сравнение инструментов парсинга PDF; оно решает задачу извлечения, а не подтверждает обезличивание.
Куда поставить Presidio и что делать при ошибке обработки?
Предлагаемое место — внутри доверенной инфраструктуры до формирования внешнего запроса. На выходе формируйте новый объект только из разрешённых полей. Если детектор завершился с ошибкой или вернул непонятный результат, переводите запись на ручной разбор; автоматическая отправка исходного текста должна быть отдельным запрещённым обходом.
Проверьте не только промпт, но и логи, трассировки и сообщения об ошибках: в предлагаемой архитектуре исходное обращение не должно попадать туда без принятой политики хранения и доступа. Техническое наличие локального сервиса само по себе эту политику не реализует.
Официальный FAQ предупреждает: API Presidio не включает встроенную аутентификацию; защиту доступа следует организовать отдельным инфраструктурным слоем. Не выставляйте сервис напрямую в недоверенную сеть. Источник: развёртывание Presidio.
Можно ли после замен считать передачу данных разрешённой?
Такой вывод из результата детектора не следует. Сам проект предупреждает, что автоматическое обнаружение может пропускать чувствительную информацию. Кроме прямых идентификаторов, специалистам компании следует оценить сохраняющийся контекст: уникальное событие, должность, место или сочетание деталей могут оставаться значимыми для установления личности. Это риск, который нужно оценивать для конкретного набора, а не свойство любой метки [PERSON].
Юридическую допустимость передачи, договорные условия и требования к конкретной системе оценивают отдельно. Статья не подтверждает соответствие требованиям законодательства и не выдаёт очистку Presidio за такое подтверждение. Если нельзя обосновать допустимость внешней передачи, рассмотрите выполнение задачи внутри утверждённой инфраструктуры.
Как AI студия Владимира Ломтева помогает подготовить обращения для ИИ?
AI студия Владимира Ломтева занимается подготовкой данных, интеграцией ИИ с бизнес-системами и тестированием. В задаче анализа обращений это позволяет связать работу с тремя конкретными результатами: определить состав входных полей, спроектировать преобразование до вызова модели и проверить сохранение смысла на контрольных примерах.
Первый шаг — выбрать один процесс классификации жалоб, описать его текущий результат, источники данных, ограничения и критерий готовности. Такое описание помогает обсуждать интеграцию предметно. Оно не означает гарантии обезличивания, отсутствия ошибок или юридической допустимости передачи.
Итог: какой текст передавать классификатору?
Передавайте только необходимые для задачи поля после согласованного преобразования и проверки. Различайте обнаружение чувствительного фрагмента, его замену и сохранение связи между сообщениями. Для начала удобно выбрать классификацию причины жалобы: у неё понятный выход и обычно нет необходимости возвращать модели контактные данные клиента. Успех такого сценария определяется одновременно качеством скрытия и сохранением смысла обращения.
