Почему обычного журнала приложения недостаточно

Локальный AI‑агент редко ограничивается одним запросом к модели. Он ищет документы в RAG, вызывает CRM или ERP, формирует файл, просит согласование и повторяет операцию после ошибки. Когда результат оказывается неверным, руководителю нужен ответ не только на вопрос «что сказала модель», но и на вопросы «какие данные она видела», «какое действие было разрешено» и «кто подтвердил результат».

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

OpenTelemetry прямо предупреждает, что инструкции, входные и выходные сообщения могут быть большими и чувствительными. В актуальных соглашениях GenAI их захват не рекомендуется включать по умолчанию. OWASP отдельно советует не записывать напрямую токены доступа, пароли, ключи, строки подключения и чувствительные персональные данные.

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

Разделите трассировку и аудит

У двух журналов разные задачи.

  • Оперативная трассировка помогает инженеру найти медленный запрос, повторный вызов или ошибку интеграции. Она содержит `trace_id`, длительности, коды ошибок, имена операций, счётчики токенов и технические метрики.
  • Журнал аудита отвечает, кто инициировал действие, какая политика применялась, какие объекты были затронуты, требовалось ли согласование и чем закончилась операция.

Один и тот же `trace_id` может связывать эти слои, но права доступа и сроки хранения должны различаться. Значимые бизнес-события доступны только группе, отвечающей за безопасность и контроль процесса.

Не стоит делать SIEM, APM или панель разработчика единственным хранилищем доказательств. Операционные данные оптимизированы для поиска неисправностей и могут семплироваться. Аудит требует предсказуемой полноты для выбранных событий и контролируемого удаления.

Минимальная схема события

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

  • точное время в UTC, `trace_id`, идентификатор запуска и родительского шага;
  • тип инициатора: сотрудник, сервис, расписание или другой агент;
  • роль или служебный идентификатор инициатора без лишних персональных данных;
  • версия агента, модели, системной инструкции, политики доступа и схемы инструмента;
  • операция: поиск, генерация, вызов инструмента, запрос согласования, исполнение или откат;
  • идентификаторы затронутых объектов и их классы данных;
  • идентификаторы найденных документов, номера версий и оценки релевантности, но не сами фрагменты;
  • имя инструмента, разрешённый ресурс и нормализованный тип действия;
  • решение политики: разрешено, запрещено или требуется согласование;
  • идентификатор согласования и роль подтвердившего сотрудника;
  • идемпотентный ключ для внешнего изменения;
  • код результата, тип ошибки, длительность и объём обработки;
  • хеш нормализованного входного или выходного артефакта, если нужно доказать его неизменность.

Названия операций и статусов должны иметь низкую кардинальность. Вместо имени клиента храните внутренний идентификатор и обращайтесь к мастер‑системе только при санкционированном расследовании.

Что не должно попадать в обычную телеметрию

По умолчанию исключите:

  • полные промпты и ответы модели;
  • текст найденных RAG‑фрагментов;
  • содержимое писем, договоров, счетов и вложений;
  • пароли, токены, ключи API, cookie и строки подключения;
  • произвольные заголовки HTTP и тела запросов;
  • точные персональные данные, если для расследования достаточно псевдонима или идентификатора;
  • внутренние рассуждения модели и скрытые служебные инструкции.

Маскирование после отправки в коллектор слишком поздно: секрет уже покинул приложение. Редактор чувствительных полей должен работать в процессе агента или на ближайшем доверенном шлюзе до экспорта телеметрии.

Регулярные выражения полезны для известных форматов, но не являются достаточной защитой. Нужны разрешённые списки полей, типизированные схемы и проверка аргументов каждого инструмента. Безопаснее записать пять заранее определённых атрибутов, чем пытаться очищать произвольный JSON после события.

Архитектура безопасного следа

Рабочая схема состоит из шести элементов.

1. Шлюз агента назначает идентификатор запуска и распространяет контекст трассировки между моделью, RAG и инструментами. Стандарт W3C Trace Context задаёт переносимый формат, позволяющий связать операции разных сервисов.
2. Каждый значимый шаг создаёт структурированный span или событие: запрос к модели, поиск, вызов инструмента, согласование и исполнение.
3. Политика телеметрии разрешает только утверждённые атрибуты. Содержимое сообщений выключено, секреты и персональные поля отбрасываются до коллектора.
4. Коллектор разделяет потоки: техническая трассировка идёт в систему наблюдаемости, обязательные бизнес-события — в защищённый журнал аудита.
5. Журнал хранится в неизменяемом или контролируемом хранилище с отдельными ролями, журналом доступа, сроком хранения и проверяемым удалением.
6. Для редких расследований создаётся отдельное хранилище доказательств. Полный артефакт попадает туда только по явной политике, шифруется, имеет короткий срок жизни и связывается с трассой ссылкой, а не копией.

OpenTelemetry даёт полезный словарь для GenAI‑операций, но соответствующие соглашения ещё развиваются. Поэтому отображение внутренних полей на `gen_ai.*` лучше держать в одном адаптере и фиксировать его версию. Тогда изменение стандарта не потребует переписывать бизнес‑логику агента.

Пример: агент готовит платёжное поручение

Допустим, агент получает счёт из почты, сверяет поставщика с договором, создаёт черновик платежа и передаёт его финансовому контролёру.

В безопасном журнале останутся:

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

Если платёж ушёл не тому получателю, этой цепочки достаточно, чтобы понять, где возникла ошибка: в распознавании, сопоставлении, политике, согласовании или исполнителе. Полная переписка нужна не всегда. Если она всё же требуется, след ведёт к защищённому оригиналу в почтовой или документной системе с её собственным контролем доступа.

Как обеспечить доказуемость

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

Синхронизируйте часы сервисов и храните время события вместе со временем его приёма. Это особенно важно для асинхронных очередей.

Отдельно проверяйте полноту. Если аудиторское событие не удалось записать, финансовое или юридически значимое действие должно остановиться либо перейти в заранее определённый безопасный режим. «Продолжить без журнала» — осознанное бизнес‑решение, а не настройка библиотеки по умолчанию.

Объём и экономика

Точная стоимость зависит не от числа запросов к модели, а от количества событий, размера полей, индексов, срока хранения и числа копий.

Модельный пример: 30 000 запусков в месяц, по 12 событий на запуск и около 0,6 КБ структурированных данных на событие дают примерно 216 МБ необработанного журнала. Индексы, репликация и служебные поля увеличат объём. Если же сохранять по 20 КБ полного содержимого на каждом шаге, только исходные записи вырастут примерно до 7,2 ГБ — ещё до индексов и резервных копий.

Это не прогноз тарифа, а иллюстрация эффекта. Посчитайте собственную формулу:

`запуски × события × средний размер × срок хранения × коэффициент копий`.

Экономить следует не семплированием обязательного аудита, а отказом от ненужного содержимого, разными сроками хранения и переносом редких полных артефактов в отдельный более дешёвый контур.

Пилот за десять рабочих дней

Для первого этапа выберите один процесс с внешним действием — например, создание заявки, изменение карточки клиента или подготовку платежа.

  • Опишите пять вопросов, на которые должно отвечать расследование.
  • Утвердите 10–15 типов событий и разрешённые поля.
  • Свяжите модель, RAG, шлюз инструментов и исполнитель одним `trace_id`.
  • Включите запрет записи содержимого и тесты на токены, персональные данные и документы.
  • Проведите несколько контролируемых ошибок: отказ политики, повтор, тайм‑аут и откат.
  • Попросите независимого сотрудника восстановить цепочку действий только по журналу.

Полезный критерий готовности: за 15 минут можно объяснить, кто и почему разрешил действие, какие версии участвовали и какой объект изменился, не открывая полную переписку агента.

Что взять руководителю

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

Локальный контур снижает риск передачи информации внешнему поставщику, но не отменяет утечки внутри собственной телеметрии. Безопасный AI‑агент оставляет достаточно следов для ответственности — и недостаточно, чтобы журнал стал новым источником компрометации.