Как вести логирование ИИ-системы?

Зачем ИИ-системе журнал

Три сценария, где полный журнал незаменим. Инцидент: кто, что и через какой канал выведал из системы — без записей расследование превращается в догадки. Спор: клиент утверждает, что ассистент дал неверный ответ, — запись показывает текст ответа и источники. Качество: по журналам видно, на каких вопросах система ошибается чаще, — это карта дообучения базы знаний. Регулятор: при проверке или инциденте с персональными данными записи — ваша доказательная база о том, что делалось и когда. Четвёртый сценарий — обновления: сравнение журналов до и после смены версии модели показывает, что изменилось в поведении системы, без субъективных впечатлений.

Стартовый набор для первого месяца работы системы: запрос и ответ в маске, документы-источники, блокировки фильтров, действия агента и версия промпта. Эти шесть категорий отвечают на девять из десяти вопросов при разборе. Остальное — метрики качества, расходы, задержки — подключается вторым слоем, когда базовое журналирование уже стабильно. Попытка писать всё сразу обычно заканчивается тем, что полезного не остаётся ничего.

Что записывать

• Запрос пользователя — в обезличенном виде: идентифицирующие данные маскируются до записи в журнал. Идентификатор сессии связывает все события одного диалога — без него журнал распадается на несвязные строки.
• Ответ системы и сработавшие фильтры: что заблокировано и по какому правилу.
• Решение RAG: какие документы и фрагменты ушли в контекст — источник каждого ответа.
• Действия агента: вызванные инструменты, параметры, результаты, подтверждения человеком.
• Изменения конфигурации: правки промптов, лимитов, версий модели, пополнение базы знаний — с автором и датой.
• Аномалии: отказы, превышения квот, подозрительные паттерны атак — сырьё для алертов.

Как хранить

Журнал ценен ровно до момента, пока его можно незаметно изменить. Поэтому: защита от изменения (доступ только на чтение, отдельное хранилище), разделение прав между администратором системы и администратором журналов, регулярный экспорт в защищённое хранилище. Владелец журналов заранее назначается поимённо: без ответственного правила живут до первой загруженной недели. Сроки хранения привязаны к целям обработки: персональные данные в журналах не хранятся дольше необходимого, сами записи о работе системы — по регламенту компании и требованиям отрасли. Зачем нужна вся документация ИИ-системы в сборе — в ответе «Зачем нужна документация ИИ-системы».

Мониторинг поверх журнала

Записи без наблюдения — архив, а не защита: смотрящий дежурный важнее огромного стора. Поверх журналирования настраивается мониторинг: всплески частоты запросов, обращения к чужим документам, рост блокировок фильтрами, аномальные расходы на модель. Сигналы об аномалиях уходят в SIEM и дежурную смену — так проактивное обнаружение заменяет удивление. Пороги алертов стартуют грубыми и уточняются: первые недели ложные срабатывания неизбежны и не повод отключать контроль. Построение такого контура — направление SOC и SIEM: мониторинг ИБ и реагирование на инциденты.

Что входит в повседневное сопровождение журналируемой системы — разобрано в ответе «Что входит в сопровождение ИИ-системы».

Структура записи

Рабочая единица журнала — событие с полями: время, идентификатор сессии, роль пользователя (без персональных данных), текст запроса в маске, сработавшие фильтры, перечень документов, попавших в контекст, ответ, действия и инструменты агента, версия модели и промпта. Последнее поле критично: без него невозможно понять, на какой конфигурации система вела себя иначе.

Чего не делать

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