DLP для LLM: как сохранять приватность имен сотрудников и при этом не ломать поиск

# Проблема Сотрудник пишет в корпоративный поиск: «найди последние задачи Петрова по проекту X и сравни их с обсуждением на встречах». Если перед отправкой внешней LLM просто заменить фамилию на случайный маркер (например NAME_1), связь между запросом, найденными документами и ответом модели теряется. Оставить имя в явном виде рисковано — оно может выйти за пределы доверенного контура.

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

# Почему простые маркеры не подходят Две главные проблемы naивной схемы:

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

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

# Где хранить mapping и как он работает Внутренний контур строится как gateway перед LLM. Путь запроса:

• отправка типизированного prompt внешней модели.

На обратном пути ответ модели проходит регидрацию (re-hydration) на основе session-mapping и прав вызова. В production-примере mapping живёт в сессии (например, два часа), ограничен по объёму токенов и работает в режиме insert-only: повторная подстановка не перезаписывает значение. Доступ к раскодированию требует отдельного права (pii_reveal) и фиксируется в логе аудита.

# Почему формат токена имеет значение

# Entity resolution и справочники Не все строки считаются одинаково чувствительными и одинаково полезными. AGIMA решает сопоставление не только моделью, а справочником и правилами сопоставления. В дев‑тенанте справочник включает сотрудников, юридические лица и другие записи, пополняемые и отзываемые через API/UI. Транслитерация и лемматизация выполняются в матчере. В UI подавление помечается reason=directory.

# Политика и аудит Policy engine принимает решение до деперсонализации. Регидрация возможна только при соответствии прав и наличия mapping в сессии. При расследовании инцидента mapping хранится шифрованно и доступ к раскрытию отделён от обычных прав. Такой подход минимизирует риск утечки ПД и сохраняет полезность поиска.

# Практические выводы

• Держите stateful mapping в доверенном контуре и ограничьте время и объём хранения.
• Обеспечьте entity resolution на уровне справочников, чтобы одна личность оставалась одной сущностью в сессии.
• Регидрация выполняйте только по session-mapping и правам, с аудиторией раскрытий.
• Проверяйте и входящие promпты, и исходящие ответы — безопасность на обеих сторонах процесса.