DLP для LLM без потери смысла: как сессионный маппинг сохраняет связь сущностей

Андрей Непряхин, технический директор компании AGIMA, описал внутреннюю архитектуру DLP-контура, через который сотрудники компании работают с внешними языковыми моделями и ИИ-агентами. Ключевая идея: вместо «наивной» замены фамилий на случайные маркеры вроде NAME_1 система использует обратимую псевдонимизацию с привязкой к сессии. Таблица соответствий хранится внутри защищённого периметра, а модель получает только типизированный псевдоним, например [PERSON_1], и не может восстановить настоящее имя.

Почему простая замена имени на маркер ломает поиск?

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

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

Именно поэтому DLP для LLM требует разделения двух задач:

• Скрыть значение. Внешней модели не нужно видеть «Андрей Петров».
• Сохранить идентичность сущности. Внутри запроса и связанных результатов [PERSON_1] должен указывать на один и тот же объект.

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

Как устроен контур AGIMA: шлюз, маппинг, регидрация

Внутренний контур AGIMA работает как шлюз (gateway) перед языковой моделью. Запрос проходит четыре этапа: авторизация, проверка DLP, деперсонализация, отправка провайдеру. На обратном пути ответ проходит контролируемую регидрацию (восстановление реальных имён для авторизованного пользователя).

Сессионный маппинг (session-mapping), таблица соответствий между псевдонимом и реальной сущностью, это серверное состояние, а не часть промпта. В продакшене у AGIMA эта таблица:

• живёт два часа,
• ограничена 500 токенами (токен здесь означает единицу текста, которую обрабатывает модель),
• работает в режиме «только вставка»: повторный токен не перезаписывает значение,
• не смешивается с маппингом другой сессии.

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

Пошаговая инструкция

Ниже порядок действий для команды, которая строит DLP-контур для корпоративной LLM. Шаги основаны на архитектуре AGIMA.

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

2. Подключите детектор сущностей. Детектор находит в тексте запроса спан (фрагмент текста) и его тип: Петрова → PERSON.

3. Добавьте нормализатор. Он приводит найденное к лемме (базовой форме слова) с учётом морфологии: Петрова (родительный падеж) → Петров.

4. Настройте справочник сущностей. В справочнике AGIMA хранятся записи трёх типов: employee, legal_entity, other. Варианты написания (Петров, Петрова, Petrov, apetrov) привязаны к одному внутреннему entity_id. Справочник пополняется через API или интерфейс администратора.

5. Реализуйте entity resolver (сопоставитель сущностей). Он связывает все варианты написания с одним entity_id из справочника.

6. Добавьте policy engine (движок политик). Он проверяет, разрешено ли использовать сущность в конкретном источнике и действии. Поиск задач сотрудника может быть разрешён, а вывод его телефона запрещён.

7. Отправляйте в промпт только типизированный псевдоним. В текст запроса к модели уходит [PERSON_1], а не исходная строка и не внутренний entity_id.

8. Настройте регидрацию на обратном пути. Шлюз восстанавливает реальные имена только для тех токенов, которые присутствуют в маппинге текущего запроса. Если кто-то вручную напечатает [PERSON_1], шлюз не должен «угадывать» значение.

Что понадобится

• Шлюз (gateway) с поддержкой авторизации и DLP-проверок перед отправкой запросов к внешней модели
• Детектор именованных сущностей (NER) с поддержкой русского языка и морфологии
• Справочник сотрудников и юрлиц с нормализованными записями
• Хранилище для сессионного маппинга с шифрованием и TTL (временем жизни записи)
• Около 2 часов на прототип пайплайна для одного тенанта (по данным AGIMA, это масштаб дев-тенанта на несколько сотен сотрудников)

Что делать с этим прямо сейчас, по ролям

Авторам и копирайтерам на Дзене. Если вы работаете с ChatGPT, YandexGPT или GigaChat и вставляете в промпты реальные имена клиентов или коллег, эти данные уходят на серверы провайдера. Минимальная гигиена: замените имена вручную на условные метки (Клиент_1, Партнёр_А) и будьте последовательны в пределах одного диалога. Это ручной аналог того, что AGIMA автоматизировала.

Маркетологам и руководителям. Прежде чем подключать команду к внешней языковой модели, проверьте, есть ли шлюз между сотрудниками и API провайдера. Без шлюза каждый запрос с именем клиента, это потенциальная утечка. Архитектура AGIMA показывает, что проблема решаема без отказа от модели.

Предпринимателям в РФ и СНГ. Из доступных в России инструментов для обнаружения персональных данных в тексте можно посмотреть на Microsoft Presidio (опенсорс, работает локально). Непряхин упоминает его как референс по разделению операций: замена, маскирование, шифрование и обратная расшифровка. Сессионное хранение состояния и безопасность маппинга остаются задачей вашей команды.

Самый практичный вывод из архитектуры AGIMA укладывается в одно правило: маппинг между реальным именем и псевдонимом никогда не должен оказаться в тексте промпта, он живёт на сервере, шифруется, умирает через два часа и раскрывается только тому, у кого есть на это отдельное право.