Система поддержки на базе ИИ, которая, как считалось, была защищена на этапе вывода модели, допускала утечку данных клиентов через «боковую дверь» — канал, через который записи CRM попадают в промпт. Анализ причин инцидента (post-mortem) от создателя показывает, что защиты только генерируемого моделью текста недостаточно. Входящий запрос, данные, полученные из внутренних инструментов, и итоговый вывод — всё это требует независимых мер защиты, иначе компания может допустить утечку имен, адресов электронной почты и идентификаторов, даже не зафиксировав взлома на этапе вывода модели.

Почему важны три границы

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

  • Ingress (Входящий поток) — необработанный запрос, который вводит клиент.
  • Return path (Путь возврата) — информация, которую агент извлекает из нижестоящих систем, таких как CRM.
  • Emission (Вывод) — текст, который модель возвращает пользователю.

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

От демо-версии к продакшену: уроки, полученные нелегким путем

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

  • Используйте токенизацию вместо редактирования — удаление имени или адреса электронной почты до того, как они попадут в модель, мешает системе сформировать правильный ответ. Сохраняйте исходное значение в защищенном хранилище, заменяйте его случайным UUID в промпте, а после завершения работы модели возвращайте UUID обратно. Это позволяет исключить необработанные данные из контекста модели, сохраняя при этом функциональность.

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

  • Объединяйте перекрывающиеся фрагменты — записи клиентов часто содержат имя, за которым следует адрес электронной почты, имеющий общие символы (например, «John Doe john.doe@example.com»). Токенизация только имени оставляет фрагмент email в открытом виде, который может быть выведен в ответе. Рассматривайте всю область перекрытия как единый токен.

  • Тестируйте правильную границу — тест, который проходит только при проверке уровня вывода, создает ложное чувство безопасности. Тест, который проваливается, обнаружив утечку на пути возврата данных, заставляет устранить проблему. Разрабатывайте наборы тестов, которые явно проверяют каждую из трех границ.

  • Отслеживайте эталонные данные (ground truth) — если человек редактирует черновик, созданный ИИ, перед отправкой, это означает, что модель уже выдала ошибочный ответ. Сравнение черновика ИИ с окончательным сообщением, утвержденным человеком, выявляет пробелы в уверенности модели и не позволяет системе научиться повторять ошибки.

Ставки для бизнеса

ИИ-агенты службы поддержки находятся на стыке публичного взаимодействия и внутренних хранилищ данных.

Контраргумент: почему некоторые все еще предпочитают редактирование (redaction)

Итог

Обеспечение безопасности ИИ-агента службы поддержки — это не задача «одной двери». Относитесь к входящему запросу, данным из внутренних систем и исходящему тексту как к отдельным стенам: взлом любой из них ставит под угрозу весь сервис. Токенизация конфиденциальных полей, проверка идентификаторов, объединение перекрывающихся фрагментов, тестирование правильных границ и постоянное сравнение черновиков ИИ с финальными сообщениями от людей — это практические шаги, которые превращают «копилота» в надежный, агентский сервис.