Журнал действий ИИ-агента: какие записи вести и как по ним разбирать инцидент
Агент отправил письмо не тому клиенту, поменял цену в сделке или дважды создал заявку. Первый вопрос на разборе — что именно он сделал и почему. Ответ есть только там, где заранее велась запись действий: журнал агента. Разберём, чем он отличается от обычного технического лога, что в него писать, сколько хранить и как по нему разбирать инцидент.
Коротко
- Журнал действий — это запись того, что агент сделал, на каком основании и с каким результатом. Без неё разбор инцидента превращается в догадки, а ответственность размывается между агентом и человеком.
- Для высокорисковых ИИ-систем это прямая норма: статья 12 EU AI Act требует технически позволять автоматически записывать события на протяжении всего срока службы системы, а статья 19 — хранить логи не менее шести месяцев.
- IBM (Cost of a Data Breach, 2025; 600 организаций в 16 странах): среднее время обнаружения и локализации утечки — 241 день, минимум за девять лет; 97% организаций, пострадавших от инцидента, связанного с ИИ, не имели контроля доступа к ИИ, а 63% — политики управления ИИ.
- OWASP (LLM06 Excessive Agency, 2025) называет ведение и мониторинг журнала действий агента и внешних систем мерой, которая не предотвращает опасные действия, но позволяет заметить их раньше, чем ущерб станет большим.
- Минимальный рабочий состав записи — семь полей: время, исполнитель, входные данные, вызванная функция, основание для решения, результат и подтверждение человеком. Всё, что шире, добавляют по необходимости, а не «на всякий случай».
Что такое журнал действий агента
Технический лог и журнал действий — разные документы. Лог отвечает на вопрос «работает ли система»: код ответа, время, объём обработки. Журнал действий отвечает на вопрос «что система сделала»: какое действие, над каким объектом, по какому правилу и с каким результатом. Первый нужен инженеру, второй — руководителю, юристу и тому, кто отвечает за клиента.
Разница чувствуется на первом же инциденте. По обычным логам видно, что агент вызвал функцию отправки письма; по журналу — что письмо ушло не тому адресату, потому что агент подставил контакт из соседней сделки. Без журнала остаётся пересказ события с чужих слов, с журналом — воспроизводимая цепочка, которую можно поднять через недели после события.
Зачем журнал нужен на самом деле
Журнал решает четыре задачи, и все они проявляются не в спокойный день, а в проблемный.
- Разбор инцидента. По записям восстанавливают цепочку: какой сигнал пришёл, что агент с ним сделал, где решение разошлось с правилом. Это экономит часы, а иногда и репутацию.
- Доверие и контроль. Руководитель видит не обещания, а список действий и их результаты. Так полномочия агента расширяют не «на веру», а по фактам — и легче решают, какой уровень автономии допустим.
- Требования и аудит. Регуляторы и стандарты всё чаще прямо требуют вести записи о работе ИИ-систем; от этого зависит прохождение проверок и доверие крупных заказчиков.
- Улучшение правил. По журналу видно, где агент ошибается или останавливается чаще всего. Правки вносят по данным, а не по ощущениям.
Отдельно стоит сказать про связку с полномочиями. Журнал — это то, что делает автономию управляемой: не зная, что агент делал на прошлой неделе, бессмысленно расширять его права на следующую. Как это устроено, мы разбирали в статье про уровни автономии ИИ-агента.
Минимальный состав записи
Набор полей, из которых складывается пригодная для разбора запись, короче, чем кажется. Всё остальное — надстройка, которую добавляют, когда появляется конкретная задача.
| Поле | Что записывать | Зачем нужно |
|---|---|---|
| Время | Дата и время начала и окончания действия | Восстановить последовательность событий |
| Исполнитель | Какой агент и какая версия, по чьему поручению | Понять, кто отвечает за действие |
| Вход | Запрос, письмо или документ, на котором агент работал | Отличить ошибку агента от плохих данных |
| Действие | Какая функция вызвана и с какими параметрами | Воспроизвести ровно то, что произошло |
| Основание | Правило или инструкция, по которой агент решил действовать | Проверить, что решение не вышло за полномочия |
| Результат | Успех, отказ или ошибка внешней системы | Отделить сбой агента от сбоя сервиса |
| Подтверждение | Кто и когда согласовал действие, если оно требовало согласования | Разделить ответственность человека и агента |
Этот набор не случаен. Статья 12 EU AI Act предписывает высокорисковым ИИ-системам технически позволять автоматически записывать события на протяжении всего срока службы, а для отдельных категорий — как минимум фиксировать период каждого использования с датой и временем начала и конца, проверяемую базу данных, входные данные и того, кто проверял результат. Семь полей из таблицы — прикладная версия того же принципа для агента в небольшой компании.
Сколько хранить и как защитить запись
Срок хранения — не «навсегда» и не «пока хватает места». Статья 19 EU AI Act задаёт нижнюю границу: логи высокорисковой системы хранят не менее шести месяцев, если иное не установлено отраслевым или национальным правом. Для небольшой компании этого обычно достаточно, чтобы разобрать инцидент спустя месяцы после его появления.
Технические требования короткие, но обязательные. Журнал должен быть только на запись: если запись можно незаметно удалить или исправить, она ничего не доказывает — поэтому используют отдельное хранилище и хеширование записей, чтобы подмену было видно. И держать журнал действий лучше отдельно от технических логов: в смешанном файле действие агента тонет среди служебных строк.
Отсюда практический вывод: журнал стоит заводить не «когда-нибудь», а до того, как агент получит право делать что-то необратимое. Записи, которых нет в момент инцидента, восстановить потом нельзя.
Как разбирать инцидент по журналу
Инцидент разбирают не по памяти, а по записям — шаг за шагом, от сигнала к правке правила.
Первый шаг — самый недооценённый. Прежде чем что-то менять, надо вытащить из журнала именно то действие, на которое жалуются: время, входные данные, вызванную функцию, результат. Часто уже на этом шаге видно, что дело не в модели, а в исходных данных — например, в сделке стоял старый контакт клиента.
Дальше причина превращается в правку. Если агент ошибся из-за неполных данных, добавляют проверку на входе; если вышел за полномочия — сужают функцию или требуют подтверждения. Как мы раскладываем процесс на такие шаги, описано в разделе подход.
Чего журнал не заменяет
Журнал полезен, но не всесилен, и честнее сказать об этом заранее.
Что журнал не делает
- Не предотвращает действие: запись появляется после события, а не вместо него.
- Не заменяет ограничения: лишнюю функцию у агента убирают, а не логируют.
- Не читает себя сам: без регулярного просмотра он превращается в архив.
- Не отвечает на вопрос «почему» за пределами записанного: если входные данные не пишут, причина остаётся догадкой.
Что он делает
- Даёт воспроизводимую картину: что, когда и на каком основании.
- Разделяет ответственность между агентом и человеком.
- Позволяет заметить проблему до того, как она станет массовой.
- Служит доказательством при разборе с клиентом, аудитором или страховой.
Поэтому на журнал безопаснее смотреть как на одну из трёх опор. Первая — минимум полномочий: агенту дают только нужные функции и права. Вторая — подтверждение дорогих действий человеком. Третья — журнал. OWASP в описании избыточных полномочий агента прямо называет ведение и мониторинг журнала действий агента и внешних систем мерой, которая не предотвращает опасные действия, но позволяет заметить их раньше, чем ущерб станет значительным.
С чего начать
Начинать не с покупки системы, а с трёх вопросов: какие действия агента мы хотим видеть в записи, кто и как часто будет её просматривать, сколько хранить. Дальше достаточно минимума из таблицы — время, исполнитель, вход, действие, основание, результат, подтверждение.
Такую запись мы собираем вместе с ИИ-ассистентами и связками почты, CRM и мессенджеров, а её выжимка ложится в отчёт руководителя. Примеры похожих проектов — в разделе кейсов; если хотите пройти эту разметку вместе, напишите через страницу контактов.
Спроектируем журнал действий агента так, чтобы инцидент разбирался за минуты, а не за дни.
Получить диагностикуИсточники
- EU Artificial Intelligence Act — Article 12: Record-Keeping — высокорисковые ИИ-системы должны технически позволять автоматически записывать события (логи) на протяжении всего срока службы; для отдельных категорий обязательный минимум — период каждого использования (дата и время начала и окончания), проверяемая база данных, входные данные, приведшие к совпадению, и идентификация лиц, участвовавших в проверке результата
- EU Artificial Intelligence Act — Article 19: Automatically Generated Logs — провайдеры высокорисковых систем хранят автоматически сгенерированные логи не менее шести месяцев (если иное не установлено отраслевым или национальным правом); статья 26 возлагает сходные обязанности по хранению логов на пользователей системы
- IBM — 2025 Cost of a Data Breach Report: Navigating the AI rush without sidelining security (19.11.2025), по данным Ponemon Institute — исследование 600 организаций в 16 странах и регионах (утечки марта 2024 — февраля 2025): средняя глобальная стоимость утечки снизилась до $4,44 млн (на 9% с $4,88 млн), среднее время обнаружения и локализации — 241 день (минимум за девять лет); 97% организаций, переживших инцидент, связанный с ИИ, не имели должного контроля доступа к ИИ; 63% из 600 организаций не имели политики управления ИИ; использование неутверждённых ИИ-инструментов (shadow AI) добавляло к средней стоимости утечки $670 тыс.
- OWASP GenAI Security Project — LLM06:2025 Excessive Agency — избыточные полномочия агента возникают из чрезмерной функциональности, чрезмерных прав или чрезмерной автономии; среди мер снижения ущерба названо ведение и мониторинг журнала действий расширений модели и внешних систем, чтобы выявлять нежелательные действия и реагировать, а также ограничение частоты действий