Журналирование ИИ-агентов — это запись каждого действия агента: от входящего запроса до финального результата. Без такого журнала невозможно понять, почему агент принял решение, кто подтвердил операцию и где произошла ошибка. Журнал становится основой для аудита действий ИИ, разбора инцидентов и доказательства соблюдения регламентов.
Логи ИИ-агента нужны не только ИТ-отделу. Руководитель видит, сколько задач агент выполнил сам, а сколько передал человеку. Служба ИБ проверяет, что секреты не попали в журнал. Бухгалтерия получает подтверждённую историю операций для акта приёмки.
Зачем нужно журналирование ИИ-агентов
Агент без журнала — чёрный ящик. Руководитель не знает, сколько операций агент выполнил корректно, а сколько потребовало вмешательства сотрудника. При сбое ИТ-отдел тратит часы на восстановление хода событий вместо минут на чтение логов.
Журнал решает три задачи. Первая — ответственность: каждая операция привязана к пользователю, времени и контексту. Вторая — отладка: по логам видно, на каком шаге агент ошибся и какие данные использовал. Третья — контроль расходов: журнал фиксирует количество запросов к моделям и объём потреблённых токенов.
Что именно записывает журнал агента
История операций агента включает семь обязательных полей. Каждое поле фиксируется автоматически, без ручного ввода.
Входящий запрос. Кто обратился к агенту, в каком канале (Telegram, CRM, почта) и с какой задачей. Записывается текст запроса и идентификатор пользователя.
Источники данных. Какие документы, базы знаний и внешние системы агент использовал для формирования ответа. Для RAG-сценариев — конкретные фрагменты из базы знаний.
Принятое решение. Какой маршрут выбрал агент: самостоятельный ответ, вызов интеграции или передача человеку. Если агент обращался к внешним системам — какие именно API вызваны и что вернули.
Подтверждение человека. Для необратимых операций — отправка заявки, изменение статуса сделки, списание — агент ждёт подтверждения. В журнале фиксируется: кто подтвердил, когда и какое решение принял.
Результат. Что получил пользователь: текст ответа, сформированный документ, обновлённая запись в CRM.
Ошибки. Сбои интеграций, таймауты моделей, отклонённые запросы. Каждая ошибка привязана к шагу, на котором произошла.
Расход ресурсов. Количество токенов, стоимость запроса к модели, время выполнения. Эти данные нужны для контроля бюджета и оптимизации расходов на API.
Как защитить журнал от утечки секретов
Главная задача журналирования — записать всё полезное и не записать ничего секретного. Пароли, ключи API, токены доступа и персональные данные не должны попадать в логи.
Защита строится на трёх принципах. Первый — секреты отдельно от кода: ключи и пароли хранятся в защищённом хранилище на сервере, а не в конфигурационных файлах или репозитории. Второй — маскирование: если агент передаёт данные через внешний API, в журнал пишется класс операции и результат, но не содержимое полей с персональными данными. Третий — минимальные права: у агента отдельная учётная запись с доступом только к тем данным, которые нужны для задачи.
Политика данных фиксируется письменно до запуска. В ней указано, какие классы данных могут попасть в журнал, а какие — нет. Эмбеддинги для базы знаний считает локальная модель на сервере, тексты документов наружу не уходят. О схемах размещения и требованиях ИБ — в разделе Инфраструктура для ИИ.
Пример: журналирование в отделе продаж
Рассмотрим гипотетический сценарий. Компания подключает ИИ-агента к CRM и почте отдела продаж. Агент читает входящие письма, находит связанную сделку в CRM, формирует ответ на основе базы знаний и отправляет черновик менеджеру на подтверждение.
Вот как выглядит одна запись в журнале:
| Поле | Значение | |---|---| | Время | 2026-08-30 14:12 | | Источник | Email, отдел продаж | | Запрос | Письмо от клиента о сроках поставки | | Данные | Сделка №4821 в CRM, карточка товара, раздел FAQ из базы знаний | | Решение | Сформировать ответ на основе FAQ, отправить черновик | | Подтверждение | Менеджер Иванова подтвердила отправку в 14:18 | | Результат | Черновик отправлен клиенту | | Токены | 1 840 | | Ошибки | — |
Если бы интеграция с CRM вернула ошибку, в поле «Ошибки» появилась бы запись: «CRM API timeout, попытка 1 из 3, повтор через 5 сек». Агент попробовал бы ещё раз, и только после третьей неудачи передал бы задачу сотруднику.
Такой журнал позволяет руководителю отдела видеть, сколько писем агент обработал за день, сколько потребовало подтверждения, а сколько ушло автоматически. ИТ-отдел по логам находит причину сбоя за минуты.
Этапы настройки журналирования
Настройка журналирования — часть работ по внедрению ИИ в компанию. Вот типичная последовательность.
Шаг 1. Определить, что записывать. Составляем список операций агента и разделяем на три категории: безопасные (агент выполняет сам), требующие подтверждения (ждут сотрудника) и запрещённые (агент не имеет права выполнять). Список фиксируется в политике проекта.
Шаг 2. Настроить инфраструктуру. Журналы хранятся в контуре компании — на вашем сервере или арендованной площадке в России. Выбор площадки и классы данных согласуются с ИТ и ИБ. Требования к серверу зависят от объёма документов, числа агентов и выбранных моделей.
Шаг 3. Настроить права и логирование. Отдельные учётные записи для агентов, минимальные права доступа, маскирование секретов. Состав работ и актуальные ставки — в открытом прайсе.
Шаг 4. Прогон проверочных сценариев. Типовые, ошибочные и рискованные сценарии. Проверяем, что журнал записывает всё нужное и не записывает ничего лишнего.
Шаг 5. Обучение. Руководитель учится читать журнал: где искать причину ошибки, как оценить нагрузку на агента, когда менять настройки. Сотрудники — понимать, когда агент ждёт их подтверждения.
Как проверить результат и с чего начать
Проверка журналирования — не формальность. Вот что нужно убедиться перед запуском в отдел.
Полнота. Каждая операция агента имеет запись в журнале. Если операция произошла, но записи нет — журнал настроен неправильно.
Безопасность. В журнале нет паролей, ключей, токенов и персональных данных, которые не разрешены политикой. Проверяем маскирование на тестовых данных.
Читаемость. Руководитель отдела может по журналу понять, что сделал агент, без помощи ИТ-специалиста. Если записи непонятны — формулировки нужно доработать.
Подтверждение. Для каждой необратимой операции в журнале есть отметка: кто подтвердил и когда. Если операция прошла без подтверждения, а должна была его ждать — это ошибка конфигурации.
Восстановление. Журнал доступен после перезагрузки сервера. Резервные копии проверены обратным восстановлением — «файл существует» проверкой не считается.
Настроенное журналирование ИИ-агентов даёт руководителю прозрачность, а ИТ-отделу — инструмент для быстрой отладки. Начните с описания одной задачи: кто выполняет процесс, какие системы задействованы и какой результат нужен. Мы оценим состав работ и диапазон часов. Если задача не подходит для ИИ — скажем об этом на этапе оценки. Описать задачу можно на странице внедрения ИИ или написать в Telegram.
Частые вопросы
Что именно должно попадать в журнал ИИ-агента?
В журнал записываются входящий запрос, источники данных, принятое решение, вызовы внешних систем, подтверждение или отказ человека, результат и ошибки. Пароли, ключи и токены в логи не попадают.
Можно ли вести журнал, если агент работает с персональными данными?
Да, но требования 152-ФЗ нужно учитывать при выборе площадки и каналов. Классы данных, которые попадают в журнал, фиксируются политикой проекта и согласуются со службой ИБ до запуска.
Кто имеет доступ к журналам действий агента?
Журнал открыт администратору и руководителю. Доступы выдаются с минимальными правами: отдельные учётные записи для агентов, отзыв доступа одним действием.
Как быстро настроить журналирование для существующего агента?
Срок зависит от числа интеграций и объёма данных. Настройка прав, логирования и сценариев подтверждения человеком идёт по прайсу. Начните с описания задачи — мы оценим диапазон часов.
Официальные материалы по теме
Для терминов, возможностей интерфейсов и требований безопасности используем первичные материалы разработчиков и профильных организаций.