Чем отличается от соседней заметки Agent Observability — про то, как понять, где просело качество и что чинить. Эта заметка — про то, как доказать, что произошло: кто был субъектом, какое правило открыло действие, кто подтвердил исключение.
Что хранить на один рискованный запуск
- входной идентификатор запроса;
- субъект и арендатор (Agent Identity);
- решение политики — включая отказ;
- метаданные сборки подсказки;
- аргументы вызова инструмента в безопасно отредактированном виде;
- записи подтверждений (Approval Path);
- итоговое событие на выходе.
Формулировка «в безопасно отредактированном виде» существенна: аргументы нужны для разбора, но именно в них живут персональные данные и секреты, поэтому маскирование делается до записи, а не при выгрузке (DLP for LLM).
Событий мало — нужны связки
У пригодного для расследования следа есть не только события, но и отношения между ними. Три связки, которые и делают журнал журналом:
- какой субъект начал запуск;
- какое решение политики открыло или закрыло действие;
- какой подтверждающий одобрил исключение.
Без этих связей журнал остаётся лентой строк, по которой восстановить цепочку можно только вручную и с догадками. Практический признак того, что связки есть: по идентификатору запуска собирается вся история одним запросом, без сопоставления времени между разными системами (W3C Trace Context).
Отказ — такое же событие, как выполнение
Типичный пробел: журналируется то, что произошло, и не журналируется то, что было запрещено. Тогда на вопрос «почему агент этого не сделал» ответа нет, и различить «политика запретила», «инструмент упал» и «модель не додумалась» невозможно.
Из этого же следует, что решение политики пишется в момент решения, а не выводится задним числом из наличия или отсутствия побочного эффекта (Agent Control Plane).
Неизменяемость там, где она нужна
Для систем, чьи решения могут оспариваться, журнал соответствия ведётся в неизменяемом хранилище: запись добавляется, но не правится и не удаляется. Это отличает его от обычных логов приложения, у которых есть срок хранения и ротация.
Разделение практичное: обычные логи оптимизируются под отладку и стоимость, журнал соответствия — под доказуемость, и смешивать их в одном хранилище с общей политикой ротации значит потерять второе ради первого (AI Fairness — где такой журнал требуется по существу задачи).
Удалить из prompt — не значит удалить из системы
В state-centric цикле предыдущие рассуждения и наблюдения намеренно не возвращаются модели на каждом шаге (State Centric Execution). Для стоимости это правильная граница; для расследования уничтожение той же информации было бы ошибкой. Полная траектория хранится отдельно от рабочего prompt: версия state до шага, предложенный patch, результат валидации, версия после коммита, действие и наблюдение.
Так prompt оптимизируется под следующий выбор, а trace — под replay и доказательство. Особенно важно записывать отклонённые patch: без них видно только состояние, к которому пришли, но не попытку удалить подтверждение или переписать уже проверенный факт.
Чего у нас не было: схема записи и след извлечения
Сверка с OWASP AISVS C12.1 подтвердила состав записи на рискованный запуск и добавила две категории.
Запись должна следовать структурированной переносимой схеме, а не быть свободным набором полей: как минимум идентификатор модели и расход токенов на входе и выходе. Разница не косметическая — след, собранный по схеме, сравним между запусками и между сервисами, а собранный как придётся годится только для чтения глазами. Заодно это единственный способ ответить на вопрос «та же ли модель отвечала», когда провайдер молча подменил версию (Model Selection).
События извлечения логируются отдельно: запрос, найденные документы, источник знания. У нас этой категории не было вовсе, а без неё в RAG-системе нельзя восстановить, почему модель ответила именно так: аргументы вызова инструмента есть, а что подали в контекст из индекса — нет. Это же закрывает разбор случаев отравления индекса (RAG Poisoning) и подделанной атрибуции (Overreliance, RAG Observability).
Рядом стоит требование к учёту расхода: токены считаются не суммарно, а по пользователю, сессии, функциональной точке и команде — иначе атрибуция стоимости упирается в один общий счётчик (Unit Economics AI).
Связано с
- Agent Observability — трассировка ради качества, а не ради доказательств
- Agent Control Plane — источник решений, которые сюда пишутся
- Approval Path — запись подтверждения как часть следа
- Agent Identity — субъект, к которому привязан запуск
- Tool Gateway — где фиксируются решение и факт исполнения
- W3C Trace Context — сквозной идентификатор, связывающий события
- DLP for LLM — маскирование до записи
- Incident Management AI — процесс, для которого этот след и собирается
- Blameless Postmortem — разбор, опирающийся на восстановленную цепочку
- State Centric Execution — почему траектория может отсутствовать в prompt, но обязана оставаться в trace