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

Зачем корпоративным нейросетям обратимая деперсонализация

При интеграции языковых моделей и AI-агентов во внутренние рабочие процессы компании мы регулярно сталкиваемся с фундаментальным противоречием между информационной безопасностью и эффективностью поиска. Главная сложность систем DLP (Data Loss Prevention) при обработке промптов для нейросетей — не просто стереть или маскировать ФИО и телефоны перед отправкой запроса во внешнюю модель, а сохранить исходный смысл и логику общения.

Представьте стандартный рабочий сценарий: инженер пишет AI-ассистенту «найди свежие тикеты Петрова в Jira по проекту X и сопоставь их с протоколом вчерашней встречи». Если традиционный маскировщик заменит «Петрова» на случайный плейсхолдер NAME_1, а в следующем сообщении на NAME_7, внешняя модель потеряет контекст и перестанет понимать, что речь идет об одном и том же сотруднике. В то же время передавать реальные персональные данные во внешнее облако напрямую запрещено правилами безопасности и законодательством.

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

Почему простой замене на плейсхолдеры вроде NAME_1 не хватает эффективности

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

• Локальность нумерации: Маркеры присваиваются по мере их появления в конкретном тексте. Из-за этого в соседних сообщениях диалога один и тот же сотрудник получает разные номера, либо двое разных коллег обозначаются одинаковой меткой. В результате LLM путает контекст и делает неверные выводы.
• Утеря типа сущности и связей: Для нейросети бессмысленный набор символов NAME_1 одинаков для всех типов данных. Фамилия разработчика, номер телефона, название компании-клиента или корпоративный логин превращаются в абстрактную строку. Модель продолжает генерировать текст, но теряет способность сопоставлять объекты с результатами поиска в корпоративных базах данных и Wiki.

Чтобы обойти эти ограничения, я рекомендую разделять две независимые задачи:

1. Изоляция значения: Внешняя языковая модель не должна видеть реальное имя или чувствительные данные.
2. Сохранение идентичности: В рамках сессии и связанных результатов поиска нейросеть должна однозначно понимать, что токен [PERSON_1] указывает на один и тот же объект во всех найденных документах.

Концептуально это напоминает внешние ключи (foreign keys) в реляционных базах данных. Внешний ключ связывает таблицы между собой, но сам по себе не раскрывает содержимое записи. Главное отличие в том, что в AI-архитектуре этот ключ категорически запрещено передавать пользователю или нейросети в виде, допускающем прямую расшифровку.

Базовая архитектура: изолированная таблица соответствий на LLM-шлюзе

Для реализации безопасного взаимодействия мы используем специальный API-шлюз (Gateway), установленный перед внешним провайдером LLM. Каждый входящий запрос перед отправкой в нейросеть последовательно проходит авторизацию, DLP-детектор, модуль деперсонализации и только после этого направляется провайдеру. На обратном пути ответ модели проходит контролируемый этап регидрации (восстановления исходных данных).

Центральным элементом этой схемы является объект сессионного маппинга (req_map). Это не текст в системном промпте, а изолированное серверное состояние текущей сессии, которое находится строго внутри защищенного контура.

В продакшен-среде время жизни сессионного маппинга ограничено (например, 2 часа), сам он зафиксирован по объему (до 500 токенов) и работает исключительно в режиме добавления (insert-only). Это предотвращает перезапись или искажение уже зарегистрированных связей. Маппинги разных сессий строго изолированы друг от друга. Если требуется провести аудит безопасности, данные маппинга хранятся в зашифрованном виде, а доступ к их раскрытию выдается строго по привилегии pii_reveal с фиксацией в журналах действий.

Для самих псевдонимов лучше задействовать предсказуемый и явный формат, например [PERSON_1]. Это помогает нейросети не терять токен при рассуждениях (reasoning) или генерации JSON-структур. При этом безопасность системы опирается не на секретность формата токена, а на недоступность таблицы соответствий. Если пользователь попытается вручную вписать в чат строку [PERSON_1], шлюз не будет угадывать значение: регидрируются только те токены, которые были официально зарегистрированы в req_map текущего авторизованного запроса.

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

Entity resolution: как привязать сотрудников к единой сущности

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

Для точного распознавания объектов используется модуль сопоставления сущностей (Entity Resolver) и корпоративный справочник. Справочник собирает данные о сотрудниках, юридических лицах и внутренних сервисах из баз Jira, HR-систем и Wiki. Все записи распределены по типам (employee, legal_entity и др.), а сопоставление выполняется с учетом лемм и транслитерации.

Пайплайн обработки входящего запроса:

1. Детектор (NER/regex): Находит спан текста и определяет первичный тип (например, «Петрова» → PERSON).
2. Нормализатор: Извлекает лемму и морфологические признаки (лемма «Петров», родительный падеж).
3. Entity Resolver: Связывает все вариации написания («Петров», «Петрова», «Petrov», «apetrov») с единым внутренним идентификатором entity_id.
4. Policy Engine: Проверяет правила доступа для данного источника, пользователя и типа сущности.
5. Генерация промпта: В итоговый текст для LLM подставляется типизированный токен [PERSON_1]. Сам внутренний entity_id во внешнюю модель никогда не передается.

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

Границы применения справочника сущностей

Важно подчеркнуть: корпоративный справочник сотрудников — это инструмент идентификации объектов, а не «белый список» для обхода DLP. Он ответит на вопрос, о ком идет речь, но не дает права на автоматический вывод чувствительных данных.

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

Четыре вердикта Policy Engine вместо жесткого запрета

Практика показывает, что концепция «все заблокировать» делает использование AI-инструментов бесполезным. В нашей архитектуре движок правил (Policy Engine) принимает один из четырех вердиктов:

Такой гибкий подход предотвращает блокировку легитимных рабочих запросов: система позволяет искать задачи по сотрудникам, но надежно защищает данные от утечки наружу. В интерфейсе шлюза каждое подавление подсвечивается с указанием причины (например, reason=directory).

Регидрация ответов: обработка обратного потока данных

Проверить только входящий промпт недостаточно. Ответ нейросети также может содержать персональные данные в самых разных форматах: обычный текст, JSON-структуры, аргументы вызова функций (tool calls) или потоковая трансляция (streaming).

На обратном пути шлюз выполняет строго контролируемую регидрацию:

• Для стандартного текста восстанавливаются только те токены, которые присутствуют в req_map текущего запроса.
• Для формата JSON проверяется корректность структуры и разрешенные поля.
• Для вызовов инструментов (tool calls) выполняется валидация аргументов до их фактического исполнения на сервере.
• Для потоковых ответов (streaming) применяются режим буферизации (выдача ответа после полной проверки) или скользящее окно с немедленным разрывом соединения при обнаружении нарушений.

Правовой статус: псевдонимизация против анонимизации по 152-ФЗ

С юридической точки зрения описанную схему нельзя называть полной анонимизацией. В рамках 152-ФЗ «О персональных данных» обезличиванием признаются действия, в результате которых становится невозможно без использования дополнительной информации определить принадлежность персональных данных конкретному субъекту.

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

Методика тестирования и контроля качества поиска

Чтобы убедиться, что деперсонализация не ломает работу поисковых AI-агентов, мы используем расширенный тестовый набор:

• Проверка распознавания одного сотрудника в 6 падежных формах и различных вариантах транслитерации.
• Корректная обработка однофамильцев в одном контексте.
• Проход сквозного сценария: имя в запросе → поиск в документе → итоговый ответ LLM.
• Повторные упоминания сущности в длинных диалогах.
• Тестирование устойчивости к попыткам ручной подделки токенов [PERSON_X].
• Проверка вызовов функций (tool calls) и JSON-структур с entity-токенами.
• Мониторинг потокового вывода на наличие утечек в реальном времени.

Качество системы оценивается раздельно по ключевым метрикам: полнота обнаружения PII (Recall), уровень ложных срабатываний (Precision), точность связывания сущностей (Entity Match) и отсутствие утечек чужих сессионных маппингов. Дополнительно каждые 10 минут запускается автоматический канареечный тест (mask → upstream → rehydrate) для непрерывной проверки работоспособности контура.

Практический чек-лист по настройке защиты LLM

1. Четко очертите границы изолированного контура и исключите прямой доступ нейросети к таблице соответствий.
2. Разделите архитектурно модули детекции PII, сопоставления сущностей (Entity Resolution), Policy Engine и регидрации.
3. Храните исходные значения и внутренние entity_id раздельно; используйте сессионный req_map с ограниченным TTL по умолчанию.
4. Настройте нормализацию падежей и транслитерации, но не используйте справочник как автоматический пропуск для DLP.
5. Присваивайте каждому найденному сигналу источник обнаружения (NER, Regular Expressions, ML-модель, эвристика).
6. Обязательно фильтруйте и регидрируйте обратный поток: ответ модели, структуры JSON, аргументы tool-call и стриминг.
7. Логируйте все операции раскрытия данных и храните ключи шифрования отдельно от основной базы.
8. Регулярно проводите тестирование ред-тимингом и проверяйте сценарии сопоставления на реальных корпоративных запросах.

Выводы

Грамотная защита персональных данных при работе с LLM не должна превращаться в слепое уничтожение контекста. Использование слоя управления идентичностью (Identity Layer) с обратимой псевдонимизацией позволяет сохранить глубокий смысл запросов и высокую точность поиска, обеспечивая при этом надежную безопасность корпоративного периметра.

Источник: habr.com