Что это значит
Здесь интересен не сам DLP-слой, а архитектурный принцип: приватность нельзя решать грубой заменой данных. Если ты строишь контент-завод и подключаешь внешнюю модель к базе знаний, CRM или архиву публикаций, системе нужно помнить, что условный «Автор 17» в найденном документе - это конкретный человек, проект или клиент. Иначе поиск формально отработает, но ответ потеряет смысл, а ручная перепроверка съест всю экономию от автоматизации.
Рабочая схема состоит из нескольких контуров. Отдельно хранится mapping между реальными сущностями и маркерами, запрос проходит через entity resolution, а policy engine решает, что можно отправить модели и что разрешено вернуть пользователю. Проверять нужно и prompt, и ответ: модель может воспроизвести скрытое имя, фрагмент переписки или другой чувствительный атрибут.
Что делать уже сейчас: составь карту данных во всём своём пайплайне - от формы брифа до публикации. Отметь, где появляются имена, контакты и клиентские материалы, вынеси соответствия в отдельное хранилище с правами доступа и добавь тесты на утечки в ответы. Обезличивание должно не прерывать поток, а безопасно пропускать через него только тот контекст, который действительно нужен для результата.
