Аудит действий AI-агентов: где теряется прослеживаемость
Агентная цепочка редко выглядит как один запрос и один ответ. Даже простая задача — это последовательность переходов: модель рассуждает, вызывает инструмент, получает результат, корректирует план и идёт дальше. Прослеживаемость агентных цепочек держится ровно до тех пор, пока каждый такой переход зафиксирован вместе со своим входом, выходом и решением, которое на нём было принято.
Разрыв появляется не внутри модели, а на стыках. Незаписанные вызовы инструментов — самая частая дыра: агент обращается к внутренней системе, её ответ влияет на итоговое действие, а в журнале остаётся только текст финального сообщения. Строка есть, а восстановить по ней причину решения уже нельзя.
Дальше в дело вступают повторные попытки, параллельные ветви и частичные сбои. Вызов ушёл дважды, один раз упал по таймауту, второй вернул данные — и без сквозного идентификатора шага эти записи не связать между собой. В журнале появляется набор разрозненных событий, порядок и связь которых приходится угадывать.
Цена проявляется в момент разбора инцидента с агентом. Вместо того чтобы открыть след и увидеть, какой аргумент ушёл в инструмент и что вернулось, команда реконструирует картину по косвенным признакам: фрагментам ответов, метрикам, опросу очевидцев. На это уходят дни, а выводы остаются вероятностными — их сложно предъявить заказчику и службе безопасности. Без полного следа инцидент нельзя воспроизвести, значит, нельзя и убедиться, что исправление закрывает проблему.
Аудит действий AI-агентов строится не на количестве логов, а на сквозной связи шагов. Разбираем, как это закрывается технически.
Что меняется после внедрения: разбор инцидентов и отказы
Время локализации причины
Раньше разбор начинался со сверки разрозненных логов: шаги агента лежали в одном месте, вызовы инструментов — в другом, права — в третьем. Причина всплывала часами, а часть эпизодов так и оставалась с неподтверждённой версией. После внедрения журнал строится вокруг идентификатора трассировки: шаг, вызов, аргументы и ответ привязаны к одной сессии, поэтому цепочка восстанавливается за минуты, а не за смену.
Доля инцидентов с неподтверждённой причиной падает до единичных случаев — по каждому есть входные данные, решение агента и результат его проверки. Принцип тот же, что в наблюдаемости сервисов OpenTelemetry, только разметка расширена действиями агента: видно не «что-то упало», а на каком шаге и по чьему разрешению.
Какие классы отказов уходят
- Повторные действия агента — идемпотентные ключи и дедупликация вызовов: два одинаковых списания или письма не проходят.
- Выход за пределы прав — разрешения проверяются на каждом вызове, а не один раз при старте сессии; попытка выйти за рамки фиксируется и блокируется.
- Утечка данных в ответе — проверка на выходе редактирует чувствительные поля до отправки пользователю.
Воспроизведение сессии закрывает и разбор, и регресс: сохраняются входы, версии политик и решения агента, поэтому эпизод можно проиграть заново и убедиться, что исправление убрало отказ, а не замаскировало его.
Способы сбора событий: сравнение вариантов
Полнота журнала зависит от того, в какой точке перехватывается событие. Чем ближе к агенту, тем больше деталей попадает в запись — планы, промежуточные рассуждения, аргументы вызовов; чем дальше от него, тем ниже накладные расходы на запись и тем меньше шансов потерять событие при сбое самого агента. На практике варианты не конкурируют, а дополняют друг друга.
| Вариант | Когда подходит | Ограничения |
|---|---|---|
| Сбор событий внутри агента | Нужны рассуждения, планы и промежуточные шаги, а не только факт вызова | Держится на дисциплине кода: пропустили вызов — событие исчезло из журнала |
| Перехват вызовов инструментов на промежуточном слое | Агент обращается к внешним сервисам, базам и файлам | В записи видны только вызовы инструментов, внутренняя логика остаётся за кадром |
| Сбор на стороне оркестратора | В процессе несколько агентов и подзадач, важна маршрутизация | Детализация ниже, нагрузка ложится на узел оркестрации |
| Поток от поставщика модели | Модель внешняя, доступа к её коду нет | Состав полей и задержку задаёт поставщик, часть деталей не отдаётся |
Выбор диктует вопрос: какие события обязаны пережить сбой и последующий разбор. Для инцидента обычно берут два уровня — перехват вызовов инструментов плюс журнал оркестратора, а внутренний сбор добавляют там, где нужна логика принятия решения.
Порядок внедрения: от схемы событий до передачи
Порядок работ фиксируем до первой строки кода: сначала описываем, что считаем действием агента, и только потом поднимаем сбор. Иначе журнал выходит либо избыточным, либо не отвечает на главный вопрос — кто и на каком основании сделал вызов.
- Разбор текущих цепочек: проходим по вызовам модели, инструментам и внешним сервисам, отмечаем, где теряется идентификатор сессии и где решение принимается без записи.
- Схема событий: согласуем закрытый перечень — запрос к модели, вызов инструмента, отказ политики, изменение состояния. Каждому событию назначаем обязательные атрибуты и связь по идентификатору цепочки.
- Словарь полей журнала: типы, обязательность, формат времени и правила маскирования персональных данных — до того, как записи начнут накапливаться.
- Настройка сбора событий: подключаем источники, буферизацию на случай недоступности хранилища и защиту от потери записей при сбое агента.
- Разграничение доступа: роли на чтение, выгрузку и администрирование; обращение к самому журналу — тоже событие.
- Проверка на тестовом контуре: успешный вызов, отказ, обрыв связи, повторная доставка — сверяем полноту записей и восстановление цепочки по идентификатору.
- Приёмка системы аудита и передача: разбираем выборку реальных цепочек, отдаём документацию и обучаем дежурную смену разбору инцидентов.
Схема событий и словарь полей остаются у вас как рабочий документ: по ним меняются агенты и настраиваются правила реагирования, без обращения к нам за каждой доработкой.
Комплект на выходе: схемы, политики, регламенты
После запуска у заказчика остаётся рабочий комплект, по которому журнал живёт без нас: его можно расширять, чистить и передавать новым инженерам. Каждый артефакт привязан к конкретной операции — добавлению события, разбору инцидента, выдаче доступа.
- Схема потоков событий — путь от вызова агентом инструмента до записи в хранилище: точки перехвата, буфер, повторные отправки, поведение при недоступности приёмника. По ней видно, какие действия агента в журнал не попадают.
- Словарь полей — значение каждого поля, обязательность, допустимые форматы. Без него разбор инцидента превращается в догадки о том, что именно записал агент.
- Политики доступа к журналу — кто и при каких условиях читает записи, срок хранения, запрет правки. Журнал дописываемый: изменить прошлую запись нельзя технически, а не «по инструкции».
- Роли и права на чтение — отдельные наборы для дежурной смены, разбора инцидентов, аудита и службы безопасности: каждый видит свой срез, полный доступ не выдаётся по умолчанию.
- Правила маскирования данных — что вырезается до записи: персональные данные, ключи доступа, содержимое обращений. Маскирование стоит на входе, поэтому в хранилище чувствительные значения не попадают.
- Регламент разбора инцидентов — классификация событий, срок реакции, кто принимает решение остановить агента, как фиксируются выводы. К нему приложены инструкции для дежурной смены: что смотреть и что собрать до подключения разбирающегося.
Документацию передаём в ваш репозиторий и сопровождаем первые изменения, пока команда не начнёт править её сама.
Кейс: разбор инцидента до и после внедрения журнала
Триггером стал инцидент с агентом поддержки: подключённый к внутренней системе через инструменты, он вне сценария изменил статусы и суммы по части заказов. Узнали об этом от клиентов — изменения уже ушли в биллинг.
Расследование шло без журнала: в логах приложения были вызовы методов, но не было ни идентификатора агента, ни версии инструкций, ни привязки вызова к сессии. Три недели ручного сопоставления дали атрибуцию меньше чем для половины действий, границы инцидента остались размытыми, а откат пришлось делать по всей базе — вместе с легитимными изменениями.
Что изменили
Ввели неизменяемый журнал: записи только добавляются, правка и удаление недоступны. На каждый вызов инструмента пишутся агент и версия его инструкций, входные и выходные данные, обоснование решения, идентификаторы сессии и родительской задачи. Записи приведены к формату трассировки OpenTelemetry и хранят хеш предыдущей — пропуск или подмена обнаруживаются, а писать может только среда выполнения агента.
Метрики до и после
- Расследование эпизода: три недели ручного поиска → выборка по агенту, сессии и интервалу времени за часы.
- Атрибуция действий: подтверждалась менее чем для половины вызовов → 100%, с версией инструкций и инициатором на каждом шаге.
- Откат: полное восстановление базы → точечный откат только затронутых записей.
«Похожий случай разобрали за день и нашли корневую причину — пересечение прав у двух инструментов, а не ошибку модели», — руководитель направления.
Что делать, если система уже работает в продакшене?
Останавливать агентов не нужно: сбор событий встраивается как надстройка над точками, где агент вызывает инструменты и внешние сервисы. Код агентов при этом не переписывается — перехватчик фиксирует входные и выходные данные вызова и передаёт событие отдельным потоком, чтобы время ответа не росло.
Поэтапность здесь не компромисс, а способ снизить риск. Сначала под наблюдение попадают самые рискованные сценарии — те, что меняют данные, пишут во внешние системы или удаляют записи. Такие действия необратимы, и именно по ним чаще всего спрашивают «кто и на каком основании это сделал». Остальные подключаются следующими волнами, когда первые события уже проверены на полноту.
Каждая волна — это конфигурация, а не новая сборка сервиса. Перехватчик включается флагом на группу сценариев, правила маскируют персональные данные на входе, события уходят в очередь и затем в хранилище. Если хранилище недоступно, они копятся в локальном буфере и отправляются после восстановления связи: краткий сбой не должен стоить истории действий.
Приоритизация строится на двух осях — вероятность ошибки в сценарии и цена её последствий. Необратимые действия и внешние интеграции идут первыми, диалоговые и справочные — последними. Эффект виден с первой волны: журнал аудита покрывает именно те пути, где раньше разбор инцидента был невозможен.
Откат тоже предусмотрен: снятие флага возвращает систему к исходному поведению, а уже собранные события остаются доступными. Если ваши агенты уже в эксплуатации — расскажите, какие сценарии вызывают больше всего вопросов, и мы вернёмся с планом поэтапного внедрения под ваш контур.
Сомнения по журналу аудита: разбираем по пунктам
Возражения по журналу аудита обычно одни и те же, и они справедливые: запись легко сделать неполной, легко переписать, легко превратить в свалку персональных данных. Ниже — как мы закрываем четыре самых частых сомнения на уровне схемы хранения и правил записи.
Агент вызовет модель напрямую, минуя общий шлюз — запись потеряется?
Собираем события из двух слоёв: перехват на транспортном уровне и обработчики внутри процесса агента, где фиксируются вызовы инструментов и обращения к внешним сервисам. Если событие прошло только одним путём, в записи остаётся отметка о неполноте цепочки, а локальный буфер досылает пропущенное при первой возможности. Разрыв виден в отчёте, а не маскируется.
В записях окажутся персональные данные — что с этим делать?
По умолчанию журнал хранит идентификатор субъекта и метаданные вызова, а не тело запроса и ответа. Там, где полный текст действительно нужен для разбора, включаем маскирование полей и псевдонимизацию — сопоставление с личностью живёт отдельно и доступно узкому кругу ролей.
Сколько хранить записи, чтобы журнал не стал балластом?
Срок назначается по классу события, а не единой цифрой: операционные записи живут недолго, доступы и значимые решения — длительно. Дальше работает правило жизненного цикла: истёкшее выгружается в холодное хранилище, ещё позже удаляется вместе с ключами.
Записи можно переписать задним числом — как это исключить?
Каждая запись получает отпечаток предыдущей и подпись узла, который её создал, поэтому правка в середине ломает всю последующую цепочку. Корневой отпечаток периодически фиксируем на внешней стороне, а само хранилище держим в режиме только добавления — удалить или подменить прошлое нельзя, не оставив следа.
Обсудим вашу задачу и вернёмся с планом
Чтобы перейти от разговора к плану, достаточно описания контура: какие агенты действуют, кто инициирует вызовы, через какие сервисы проходят запросы, где стоит хранилище и кто отвечает за инфраструктуру. Этого хватает, чтобы разложить задачу на этапы и вернуться с оценкой сроков и границами работ — без долгого предпроектного цикла.
- Обсуждение задачи: разбираем сценарии агентов, кто принимает решения, что считается чувствительным действием и что именно должно попадать в аудит действий AI-агентов.
- Схема сбора: определяем точки перехвата — шлюз перед моделями, вызовы инструментов, обращения к базам, — и формат события: кто, что, когда, с каким контекстом и результатом.
- План этапов внедрения: пилотирование на одном агенте, затем тиражирование, настройка хранения и сроков давности, подключение поиска и выгрузок.
- Состав работ по аудиту: перечень интеграций, правила нормализации событий, разграничение доступа к журналам, защита от подмены записей.
- Критерии приёмки: доля действий агентов, покрытых записью, полнота контекста по каждому шагу, время поиска инцидента, восстановление цепочки решений от запроса до результата.
- Что прислать: список сервисов и агентов, пример типового запроса и ответа, требования регуляторов или внутренних служб, ограничения по срокам хранения.
- Дальнейшие шаги: согласуем границы, фиксируем план этапов и критерии приёмки, после чего начинаем с пилота.
Опишите задачу в таком виде — вернёмся с оценкой, планом этапов и составом работ.
