Почему логи вашего AI-агента не пройдут аудит
Директор по технологиям финтех-компании попросил команду комплаенс проверить шесть месяцев активности AI-агента перед визитом регулятора. Логи существовали. Команда комплаенс читала их четыре часа и сдалась. Каждая запись выглядела примерно так: 2026-01-14T09:23:41Z INFO tool_call=send_email status=200.
Никто не мог определить, кто авторизовал это письмо, какая политика разрешала его отправку и действовал ли агент в пределах задокументированных полномочий.
Аудит провалился ещё до появления регулятора.
TL;DR
- Необработанные логи AI-агентов фиксируют выполнение, а не авторизацию — аудиторам нужно второе
- AI agent audit trail должен отвечать: кто, что, почему, на чьих полномочиях и с какими доказательствами
- Статья 12 EU AI Act требует логирования «в степени, необходимой для выявления рисков» — голые статус-коды не соответствуют этому требованию
- Три структурных разрыва приводят к тому, что большинство логов не проходят проверку: отсутствующее обоснование решений, отсутствие защиты от фальсификации, отсутствие ссылки на политику
- Исправление требует осознанного проектирования, а не увеличения объёма логов
Разрыв между логированием и доказательной базой аудита
Существует разница между тем, чтобы зафиксировать факт действия агента, и тем, чтобы доказать, что агент был авторизован на это действие. Большинство команд делают первое. Аудиторам нужно второе.
Лог веб-сервера говорит, что запрос пришёл в 14:23:41 и вернул 200. Это полезно для отладки. Аудитору это не говорит ничего о том, должен ли был запрос быть обработан, какое бизнес-правило его разрешило, кто проверял политику, которая это допустила.
Логи AI-агентов имеют ту же проблему, только в увеличенном масштабе. Агент, совершающий финансовый перевод, отправляющий электронное письмо клиенту или изменяющий запись в базе данных, выполняет последовательное действие. Запись в логе говорит, что это произошло. Вопрос аудита: должно ли это было произойти и можно ли доказать существование цепочки авторизации?
Это не один и тот же вопрос.
Что на самом деле ищут аудиторы
Аудиторы — внутренние, внешние или регуляторные — ищут конкретную структуру доказательств при проверке активности AI-агентов. Она состоит из пяти компонентов:
| Компонент | На какой вопрос отвечает | Что предоставляют необработанные логи |
|---|---|---|
| Запись о решении | Что решил агент? | ✅ Часто присутствует |
| Трассировка авторизации | Кто или что разрешило это действие? | ❌ Почти никогда не присутствует |
| Ссылка на политику | Какое правило разрешило или запретило это? | ❌ Почти никогда не присутствует |
| Доказательство неизменности | Можно ли доказать, что лог не был изменён? | ❌ Редко присутствует |
| Классификация риска | Каким был уровень риска этого действия? | ❌ Почти никогда не присутствует |
Необработанные логи обычно покрывают только первую строку. Аудиторам нужны все пять.
EU AI Act Статья 12: что требует закон
Статья 12 EU AI Act требует, чтобы системы AI высокого риска автоматически регистрировали «события, имеющие отношение к выявлению рисков для здоровья, безопасности или основных прав физических лиц» в степени, необходимой «для обеспечения прослеживаемости и мониторинга».
Конкретно статья 12 требует:
- Регистрацию периода каждого использования системы
- Ссылку на базу данных, которая использовалась
- Входные данные, использованные для верификации
- Идентичность лиц, участвующих в надзоре
Агент, отправляющий автоматическое письмо клиенту на основе данных аккаунта, должен логировать: какие данные аккаунта, какие правила запустили действие, какая политика одобрила этот класс действий, и когда применимая политика последний раз проверялась. Запись status=200 не покрывает ничего из этого.
Полный текст см. в официальном тексте EU AI Act, опубликованном Европейской комиссией.
Три структурных разрыва, из-за которых каждый аудит проваливается
Разрыв 1: Отсутствующее обоснование решений
Большинство систем логирования фиксируют результат действия агента, но не фиксируют, почему агент выбрал именно этот путь. Какие входные данные повлияли на решение? Какие правила оценил слой управления? Какие альтернативы были рассмотрены и отклонены?
Без обоснования аудитор не может отличить правильное решение от удачного совпадения. В логе они выглядят одинаково.
Разрыв 2: Отсутствие защиты от фальсификации
Текстовые файлы логов — или строки базы данных без криптографической привязки — могут быть изменены. Аудиторы знают об этом. Когда доказательства соответствия могут быть изменены без обнаружения, это не доказательства. Это заметки.
Логи уровня аудита требуют защиты от фальсификации: хеш-цепочки, подписи Ed25519 на каждой записи или append-only хранилище с внешней временной меткой.
Разрыв 3: Отсутствие ссылки на политику
Действие агента проверяемо только в том случае, если его можно проследить до политики, которая его авторизовала. «Модель решила сделать это» — не политика. «Наша конституция управления разрешает автоматическую отправку электронной почты в течение 24 часов после события клиента, согласно политике RI-007, последний раз проверенной 15.02.2026 командой комплаенс» — это ссылка на политику.
Как выглядит полноценный AI agent audit trail
Запись уровня аудита для одного действия агента содержит:
{
"event_id": "evt_9a3f2c...",
"timestamp": "2026-04-14T09:23:41.000Z",
"action": "send_email",
"agent_id": "customer-support-agent-v2",
"decision": "PERMIT",
"policy_ref": "CSP-EMAIL-001-v3",
"policy_reviewed": "2026-03-01",
"inputs": { "trigger": "purchase_confirmed", "account_id": "cust_7821" },
"risk_tier": "LOW",
"human_oversight": "not_required_at_tier",
"record_hash": "sha256:4a9f...",
"prev_hash": "sha256:8b2e...",
"signature": "ed25519:c3a1..."
}Каждое поле служит аудиту. Хеш-цепочка связывает эту запись с предыдущей — разрыв в цепочке означает фальсификацию. Подпись доказывает, что запись не была изменена после создания. Ссылка на политику связывает действие с правилом, проверенным человеком.
Как проверить ваши текущие логи
Проверьте 20 недавних действий агентов по пяти критериям:
- Тест авторизации — Можно ли определить, какая политика разрешила каждое действие? Нет → провал.
- Тест обоснования — Можно ли объяснить, почему агент выбрал именно это действие? Нет → провал.
- Тест целостности — Есть ли криптографическое доказательство того, что каждая запись не изменена? Нет → провал.
- Тест риска — Классифицировано ли каждое действие по уровню риска? Нет → провал.
- Тест надзора — Для действий, требующих надзора, зафиксирован ли надзор? Нет → провал.
Три и более провала — ваши логи не переживут компетентного аудита.
Часто задаваемые вопросы
В: Наш вендор говорит, что их платформа «соответствует AI Act». Значит ли это, что наши логи готовы к аудиту?
Соответствие платформы (если реальное) обычно покрывает инфраструктуру вендора. Оно редко покрывает поведенческие доказательства ваших конкретных рабочих процессов агентов. Ваш слой управления должен самостоятельно производить соответствующие доказательства.
В: В чём разница между audit trail и audit log?
Лог фиксирует события. Audit trail фиксирует события плюс их контекст авторизации, ссылки на политику и доказательства защиты от фальсификации. Логи полезны для отладки. Audit trail необходим для соответствия.
В: Как долго должны храниться записи аудита?
Статья 12 EU AI Act требует хранения «в течение периода, соответствующего рассматриваемой системе AI, не менее шести месяцев». Регулируемые отрасли (финтех, здравоохранение) обычно требуют 5–7 лет.
В: Применяется ли это к внутренним AI-агентам, которые не работают с данными клиентов?
Даже внутренние агенты, работающие с бизнес-данными, могут вызывать требования аудита согласно EU AI Act, SOC 2 Type II или ISO 27001, если они автоматизируют решения, затрагивающие сотрудников, бизнес-процессы или финансовые записи.
В: Можно ли добавить это ретроспективно к существующим логам?
Нет. Ретроспективное добавление контекста авторизации не поддаётся проверке — оно было добавлено постфактум. Доказательства уровня аудита должны генерироваться в момент действия.
Николай Ковтун, основатель Infracortex AI Studio. Мы помогаем инженерным командам добавить runtime-подотчётность к производственным AI-агентам — чтобы доказательства аудита генерировались автоматически в момент действия. Забронируйте звонок.
См. также: AI-агенты: наблюдаемость vs управление | EU AI Act Статья 12: требования к логированию | Почему runtime — это commodity, а управление — это ров
Cortex build: 0.1.35-260423
