Аудит AI-агентов: как компании проверяют, что бот не сломал бизнес

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

Что вообще проверяют в агенте

Аудит классического сервиса — это ответ на вопрос «кто и когда изменил запись». С агентом^* вопросов больше, потому что между запросом пользователя и итоговым действием стоит цепочка рассуждений и вызовов инструментов, которую сама модель может описать неточно.

На практике команды хотят иметь возможность восстановить четыре вещи:

• Вход. Что именно пришло агенту — запрос пользователя, содержимое контекстного окна, документы из внешних источников.
• Решение. Какие инструменты агент вызвал, с какими аргументами и в каком порядке.
• Результат. Что вернули инструменты и какое финальное действие агент совершил во внешней системе.
• Границы. Не вышел ли агент за пределы выданных ему прав и лимитов.

Проблема в том, что текст рассуждений модели — это не доказательство. Модель может «объяснить» действие постфактум так, как оно не происходило. Поэтому доверяют не пояснениям агента, а логам вызовов инструментов: они фиксируются на стороне инфраструктуры, а не генерируются моделью.

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

Из чего складывается подготовка к аудиту

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

Трассировка вызовов

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

Разграничение прав

Агенту выдают не «доступ к системе», а конкретный набор действий с лимитами. Не «доступ к платежам», а «инициировать возврат до определённой суммы, всё выше — на подтверждение человеку». Это отделяет то, что агент может предложить, от того, что он может выполнить сам.

Человек в цикле на критических шагах

Часть действий помечается как необратимые: удаление данных, платёж, публичная рассылка, изменение прода. На них ставят обязательное подтверждение оператора. Это замедляет процесс, но именно необратимость чаще всего становится причиной инцидента.

Оценка на регрессиях

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

Чем это отличается от аудита обычного софта

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

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

Пригодится, если:

• Агент трогает деньги, персональные данные или прод — то есть цена ошибки измеряется в рублях или в жалобах регулятору.
• Вы в сегменте, где и без всякого AI есть требования к журналированию действий: финтех, здоровье, госзаказ. Там аудит агента — просто расширение уже существующей дисциплины.
• Агент работает от лица клиента и его действия видны третьим лицам — например, отвечает в поддержке или ведёт переписку.

Можно пока не заморачиваться, если:

• Агент — внутренний ассистент без прав на изменение чего-либо: суммаризация, черновики, поиск по базе. Тут максимум логируют входы для разбора качества.
• Все действия агента и так проходят обязательное подтверждение человеком — тогда ответственность на операторе, а не на боте.
• Вы на стадии прототипа и ещё не решили, поедет ли идея в прод. Строить полный аудит до этого — трата ресурса.

С чего начать, если агент уже в бою

1. Составьте список действий агента и пометьте необратимые. Именно на них ставьте подтверждение человеком в первую очередь.
2. Логируйте вызовы инструментов, а не только диалог с моделью. Пояснения модели держите отдельно и не считайте их доказательством.
3. Привяжите к каждому логу версию модели и версию промпта. Без этого невозможно понять, что именно изменилось после инцидента.
4. Соберите набор сценариев с известным исходом и прогоняйте его при каждой смене модели или промпта.
5. Опишите процедуру отмены совершённых действий заранее — до того, как она понадобится в три часа ночи.

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