Чому журнали вашого 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
