DLP для LLM: анонимизация запросов без потери качества поиска

Что обсуждается в статье

В статье «DLP для LLM: как обезличивать запросы и не ломать поиск по сотрудникам» (Habr AI, 11 сентября 2026) рассматривается проблема передачи конфиденциальных данных в корпоративный поиск, когда запросы обрабатываются внешними большими языковыми моделями (LLM). Основная задача – скрыть имена и фамилии сотрудников, не нарушив связь между запросом, найденными документами и ответом модели.

Ключевые подходы

1. Замена имен на маркеры – вместо реального ФИО подставляются случайные токены (например, EMP_001). Это простейший способ DLP, но без дополнительного механизма связь разрывается.
2. Mapping‑хранилище – отдельная база, где сохраняется соответствие «маркер ↔ реальное имя». При необходимости (например, для аудита) можно восстановить оригинал.
3. Entity resolution – система, которая распознаёт сущности в запросе и в ответе модели, сопоставляя их с маркерами. Позволяет проверять, что модель не «выдумывает» новые персональные данные.
4. Policy engine – модуль, задающий правила, какие типы сущностей можно передавать в LLM, а какие следует блокировать или заменять.
5. Двунаправленная проверка – проверка как входного prompt, так и сгенерированного ответа, чтобы гарантировать отсутствие утечки персональных данных.

Почему это важно

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

Практические рекомендации

• Хранить mapping в зашифрованном хранилище с ограниченным доступом.
• Интегрировать entity resolution в пайплайн запросов и пост‑обработку ответов.
• Настроить policy engine на основе классификации чувствительности данных.
• Проводить регулярный аудит DLP‑процедур и тестировать модели на случайные утечки.

Читать оригинальную статью