Зачем нужен шлюз перед моделью

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

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

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

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

Четыре независимых контура

Рабочая схема состоит из четырёх сервисов, между которыми есть явные границы.

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

**2. Обнаружение и замена.** Детектор объединяет регулярные выражения, контрольные суммы, справочники, контекстные правила и NER-модель. Затем отдельный модуль применяет операторы: удаление, маскирование, замену, хеширование или шифрование.

**3. Работа LLM.** Модель видит текст с маркерами вида `[PERSON_01]`, `[PHONE_01]`, `[CONTRACT_02]`. Ей доступны только инструменты, необходимые для бизнес-задачи. Таблица соответствий в контекст модели не попадает.

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

Разделение важно: модель не должна одновременно видеть исходный текст, карту замен и ключ расшифрования. Иначе шлюз существует только на диаграмме.

Что даёт Presidio и чего не даёт

Microsoft Presidio — открытый набор компонентов для поиска и деидентификации PII в тексте, изображениях и структурированных данных. В текстовом сценарии Analyzer определяет интервалы сущностей, а Anonymizer применяет выбранные операторы.

Официальная документация перечисляет несколько механизмов распознавания: регулярные выражения, deny-листы, контрольные суммы, правила, NER и контекст вокруг совпадения. Это полезная основа для шлюза, потому что номера карт, телефоны, имена и внутренние коды требуют разных методов.

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

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

Выберите оператор по назначению

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

**Удаление** подходит, когда сущность не нужна модели. Оно максимально сокращает данные, но может разрушить грамматику и контекст.

**Маскирование** оставляет часть формата, например последние цифры. Это удобно сотруднику, но иногда сохраняет достаточно признаков для связывания записей.

**Маркерная замена** сохраняет структуру: один и тот же клиент становится `[CLIENT_01]` во всём документе. Для суммаризации и классификации этого часто достаточно.

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

**Шифрование** позволяет обратное восстановление, но создаёт ключ и карту, которые становятся чувствительными активами. Доступ к ним должен быть уже, чем доступ к результату модели.

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

Где хранить карту маркеров

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

Минимальные правила:

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

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

Не следует помещать исходные фрагменты в имя маркера. `[IVANOV_01]` не обезличивает фамилию. Маркер должен отражать только тип и локальный порядковый номер.

RAG требует обработки до индексации

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

Для RAG нужен отдельный маршрут:

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

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

Как измерить качество детектора

Средняя точность на чужом наборе мало говорит о вашем процессе. Соберите 200–500 обезличенных примеров из реального потока и вручную разметьте типы сущностей. Включите опечатки, сокращения, склонения, смешение кириллицы и латиницы, номера без разделителей, подписи, таблицы и OCR-ошибки.

Считайте отдельно:

  • recall — долю чувствительных фрагментов, которые шлюз нашёл;
  • precision — долю найденных фрагментов, которые действительно чувствительны;
  • долю документов хотя бы с одним опасным пропуском;
  • потерю полезности: может ли модель решить задачу после замены;
  • время обработки и размер ручной очереди.

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

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

Что делать с пропусками

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

Полезны два порога. Выше высокого порога сущность заменяется автоматически. Между высоким и низким — документ получает флаг проверки. Ниже низкого совпадение не считается сущностью, но аномалии формата всё равно могут остановить маршрут.

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

Экономика небольшого контура

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

Считайте стоимость на обработанный и принятый документ:

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

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

Пилот за три шага

**Шаг 1 — карта данных.** Выберите процесс, перечислите источники, типы сущностей, получателей и допустимое назначение результата. Вместе с ответственными за безопасность и данные определите, что можно удалять, что псевдонимизировать и что нельзя передавать модели вообще.

**Шаг 2 — теневой режим.** Шлюз анализирует копии документов, но ничего не отправляет в рабочую LLM. Команда измеряет пропуски, ложные срабатывания и потерю смысла. Настройки фиксируются как версия политики.

**Шаг 3 — ограниченный маршрут.** Включите один обратимый сценарий, например подготовку черновика ответа. Внешняя отправка остаётся за человеком. Журналируйте версии детектора и политики, но не исходные значения и ключи.

Успех пилота — не «PII найдена на демонстрации», а стабильная доля документов без опасных пропусков, приемлемое время проверки и понятная процедура отказа.

Управленческий вывод

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

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