Агент разослал письма не тем клиентам: разбор ошибки

Типичный сценарий, который повторяется в компаниях, внедряющих автономных агентов для работы с клиентами: агенту дали доступ к CRM и почтовому API, поставили задачу «разослать персональные предложения по сегменту», а он отправил письма с чужими именами, скидками и историей заказов не тем людям. Утечка персональных данных, десятки жалоб и разбор полётов на несколько дней. Разберём, почему так происходит и что в архитектуре агента почти всегда становится причиной.

Что произошло в кейсе

Условная компания настроила агента на базе LLM с функцией tool calling: модель могла сама вызывать функции get_segment(name), render_email(client_id) и send_email(to, body). Задача формулировалась в свободной форме: «отправь письмо с промокодом всем клиентам из сегмента лояльных за последний квартал».

Дальше цепочка рассыпалась в трёх местах сразу:

1. Агент получил список клиентов сегмента, но при итерации перепутал соответствие между client_id и адресом получателя — тело письма собиралось для одного клиента, а to подставлялся от соседнего.
2. Определение сегмента «лояльные за квартал» модель интерпретировала шире, чем задумывал маркетолог, и захватила часть базы, которая давно отписалась.
3. Не было финального шага подтверждения человеком: агент отправлял письма пачкой без остановки.

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

Агент не «ошибся» в человеческом смысле. Он выполнил ровно то, что позволяла архитектура: сгенерировал последовательность вызовов, которую никто не проверял на согласованность данных перед отправкой.

Почему агенты ломаются именно так

Автономный агент* — это не программа с жёстко заданным порядком действий. Модель сама решает, какие инструменты и в каком порядке вызвать, опираясь на текст задачи и промежуточные результаты. Это даёт гибкость, но убирает гарантии, к которым все привыкли в обычном коде.

Смешение данных в контексте

Когда в контекстное окно агента одновременно попадают данные нескольких клиентов, модель может перепутать, какое значение к кому относится. Для LLM «Иван, заказов на 40 000» и «Пётр, заказов на 12 000» — это токены в одном потоке, а не строго связанные записи. Чем длиннее список в одном запросе, тем выше риск склейки.

Нестрогая интерпретация задачи

Формулировка «лояльные за квартал» для человека и для модели значит разное. Без явного фильтра в коде агент опирается на собственную догадку о границах сегмента. Это не баг модели, а отсутствие детерминированного слоя между намерением и действием.

Отсутствие точки останова

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

Как устроена защита в правильной архитектуре

Ключевая идея: агент решает что сделать, но детерминированный код решает, можно ли это выполнить и как именно собрать данные. Разделение ответственности выглядит так:

Практические меры, которые закрывают именно этот класс ошибок:

• Связывать адрес и тело письма атомарно. Пусть функция принимает только client_id, а адрес и содержимое подтягивает сам код из одной записи. Агент не должен передавать to и body раздельно.
• Не отдавать сегментацию модели. Фильтр аудитории — это SQL-запрос или проверенная функция, а не свободная интерпретация промпта.
• Ставить обязательный шаг подтверждения перед любой массовой рассылкой: агент готовит превью на 5–10 писем, человек проверяет соответствие имён и адресов.
• Ограничивать размер батча и вводить лимит на количество писем за один запуск.
• Логировать пару «получатель — источник тела» для каждого отправления, чтобы утечку можно было локализовать за минуты, а не за дни.

Кому это пригодится, а кому нет

Автономная рассылка через агента оправдана не всегда. Ориентиры по сценариям:

• Пригодится: внутренние уведомления команде, где нет персональных данных клиентов; черновики писем на проверку менеджеру; агрегированные отчёты, которые собираются из безличных данных.
• Пригодится с оговорками: персональные рассылки, но только через связку «агент планирует — код исполняет — человек подтверждает первую партию».
• Не стоит отдавать агенту: прямую отправку персональных писем клиентам без слоя валидации и подтверждения. Здесь цена одной ошибки — это уведомление в Роскомнадзор о нарушении при обработке персональных данных и репутационный удар, который дороже любой экономии на автоматизации.

*Агент — программа на основе языковой модели, которая сама выбирает и вызывает внешние инструменты (функции, API), чтобы достичь поставленной цели, а не следует заранее прописанному сценарию. Гибкость такого подхода оборачивается отсутствием жёстких гарантий порядка и согласованности действий.