Языковые модели (ИИ, которые генерируют текст) умеют «запоминать» то, что видели в обучающих данных или в текущем диалоге, и иногда выдают в ответе то, что не должно покидать систему: персональные данные, коммерческую тайну, фрагменты внутренних инструкций. Для компаний, которые обрабатывают документы по 152-ФЗ или работают в юриспруденции и финансах, такие утечки означают прямые риски. В этой статье — практические подходы к блокировке утечек: маскировка и анонимизация данных до обработки, жёсткий контроль формата ответов, мониторинг аномалий и как это увязать с требованиями закона и отраслевыми кейсами.
О защите от внедрения вредных инструкций (prompt injection) — в отдельной статье. Общая архитектура безопасности платформы — в разделе Безопасность.
Маскировка и анонимизация данных перед обработкой
Простой принцип: в модель не должны попадать «сырые» персональные или конфиденциальные данные, если в них нет необходимости для ответа. Перед тем как текст уходит в языковую модель, чувствительные поля заменяют на псевдонимы или метки.
Примеры. ФИО заменяют на «Гражданин Н.», номера паспортов и СНИЛС — на шаблон «***-**-** ********», суммы в договорах — на «[СУММА_1]», названия компаний — на «Организация А». После того как модель сгенерировала ответ (например, вывод по документу), обратная подстановка возвращает нужные значения только туда, где у пользователя есть право их видеть, и только в защищённом канале. Так модель «не знает» реальных ФИО и реквизитов, а значит, не может их случайно или под давлением атаки выдать в открытом виде.
Для юристов и финансов: при разборе договоров или претензий в контекст часто попадают имена сторон, суммы, даты. Маскировка на входе плюс политика «минимальных прав» (какой объём данных подставлять обратно в ответ в зависимости от роли пользователя) снижают риск утечки и помогают соответствовать 152-ФЗ при автоматизированной обработке.
Детерминированные скрипты и фиксированный контекст для ответов
Слово детерминированный здесь значит: результат ответа системы жёстко ограничен заранее заданными шаблонами и правилами, а не «свободным» текстом модели. Например, система не говорит произвольной фразой «Клиенту Иванову одобрена сумма 100 000 рублей», а подставляет данные в заготовленный шаблон: «Статус заявки: [статус]. Сумма: [значение из базы]. Срок: [дата].» Заполнение полей шаблона идёт по правилам из вашей базы и прав доступа; модель может участвовать только в выделении структурированных полей из текста (дата, сумма, тип документа), а финальную фразу формирует скрипт. Так проще контролировать, что в ответе не окажется лишнего.
Фиксированный контекст означает: в каждый запрос к модели передаётся только тот набор документов или фактов, который нужен для данной задачи и разрешён для данного пользователя. Никакого «доступа ко всей базе» — только выбранный регламентом кусок. Это уменьшает и риск утечки, и риск того, что модель «перепутает» данные из разных кейсов.
Мониторинг аномалий
Даже при маскировке и шаблонах полезно отслеживать подозрительное поведение. Мониторинг аномалий — это анализ логов запросов и ответов: не появились ли в ответах паттерны, похожие на персональные данные (например, последовательности цифр в формате паспорта), не слишком ли длинные ответы, не повторяются ли запросы, направленные на извлечение служебной информации. При срабатывании правил или ML-детектора ответ можно не отдавать пользователю, отправить на ручную проверку и зафиксировать инцидент. Так вы сочетаете превентивные меры (маскировка, шаблоны) с реактивными (обнаружение и блокировка).
| Тип угрозы | Суть | Меры |
|---|---|---|
| Внедрение в запрос (prompt injection) | Пользователь вставляет в запрос инструкцию, чтобы модель выдала чужые данные или обошла ограничения | Валидация ввода/вывода, вторая модель-«судья», изоляция контекста |
| Обход ограничений (jailbreaking) | Попытки заставить модель отвечать на запрещённые темы или выполнять запрещённые действия | Жёсткие системные инструкции, фильтр ответов, фиксированные сценарии (шаблоны) |
| Случайная утечка в ответе | Модель «вспоминает» или подставляет в ответ данные из контекста, которые не должны показываться | Маскировка на входе, детерминированные шаблоны ответа, проверка выхода на паттерны ПДн |
| Утечка через контекст | В контекст попали документы не того пользователя или лишние поля | Политика минимальных прав, фиксированный и ограниченный контекст на запрос |
Интеграция с 152-ФЗ и примеры для юристов и финансов
Закон 152-ФЗ «О персональных данных» требует, чтобы при обработке ПДн были определены цели, объём, сроки, обеспечена конфиденциальность и защита от неправомерного доступа. В системах на базе ИИ это означает:
- минимизацию данных: в модель попадают только обезличенные или маскированные данные, где это возможно;
- разграничение доступа: кто какие поля может видеть в ответе и в логах;
- фиксацию обработки: что, когда и с какой целью передавалось в ИИ и что было в ответе (для расследования и проверок).
Юридические и финансовые кейсы. При автоматической проверке договоров или претензий в контекст часто попадают ФИО, реквизиты, суммы. Маскировка на входе (например, стороны как «Сторона 1» и «Сторона 2», суммы как метки) плюс ответы в виде структурированных выводов («Нарушение срока поставки по п. 3», «Риск: высокая сумма неустойки») без разглашения персональных данных в свободном тексте — типичный подход. В финансах то же самое для отчётов и заявок: модель помогает классифицировать и извлекать факты, а персональные и конфиденциальные поля подставляются по правилам уже после генерации, с учётом прав пользователя.
Итог: предотвращение утечек в системах на ИИ строится на комбинации маскировки данных до обработки, жёсткого контроля формата ответов (шаблоны, минимальный контекст) и мониторинга аномалий. Соответствие 152-ФЗ закладывается за счёт минимизации и разграничения доступа к персональным данным на всех этапах. В Нексус-Тех мы проектируем платформу с учётом этих принципов; подробнее — в разделе Безопасность и в статье про защиту от внедрения инструкций. Обсудить внедрение под ваши процессы и 152-ФЗ можно через форму заявки.