ЕС требует от ИИ-агентов полного аудита действий. Большинство систем к этому не готовы

С 2 августа 2026 года вступают в силу жёсткие требования EU AI Act к высокорисковым ИИ-системам. Статья 12 требует создавать запись каждого решения ИИ в момент его принятия — и большинство существующих агентных стеков на это попросту не способны.

Логировать промпты и ответы ИИ — это не аудит. Аудит — это когда само применение политики генерирует запись о себе в момент исполнения, а не после факта.

Дедлайн ближе, чем кажется

С 2 августа 2026 года в полную силу вступают обязательства EU AI Act для высокорисковых ИИ-систем. Статья 12 регламента требует, чтобы каждое решение, принятое ИИ-агентом, сопровождалось формируемой «на лету» записью: что именно произошло, какие политики были применены, было ли вмешательство «жёстким» (действие заблокировано) или «мягким» (действие разрешено, но с флагом).

Звучит как требование «вести хорошие логи». Но на деле это что-то совсем другое — и, по мнению разработчика Изелла Хендриета, большинство компаний пока этого не понимают.

В чём реальная проблема

Типичный агентный стек работает так: ИИ получает промпт, генерирует ответ, система выполняет действие (tool-call). Всё это записывается в лог — промпт, ответ, maybe результат выполнения.

Это запись того, что агент сказал. Это не запись того, какая управляющая политика была применена в момент действия. И если ваш «слой говернанса» — это отдельный наблюдатель, который читает логи постфактум, то вы уже не соответствуете требованиям к высокорисковым системам. Потому что вы не можете доказать, что политика была применена в момент исполнения. Вы можете лишь показать, что заметили проблему потом.

Это принципиальная разница, и на ней строится вся архитектура, которую описывает Хендриет.

Формула: исполнение = аудит

Ключевая мысль — не «ведите лучшие логи», а сделайте применение политики и создание аудитной записи одним и тем же действием. В тот момент, когда гейт проверяет proposed action агента против политики, в этот же момент создаётся запись — не восстанавливается потом из рассыпанных по системе файлов.

Хендриет описывает архитектуру pre-admissibility gate — предварительного фильтра, через который проходит каждый tool-call агента до того, как он будет выполнен. Этот гейт делает три вещи:

• Проверяет текущий trust score агента — динамический показатель, который деградирует при нарушениях и восстанавливается при чистом поведении. Системно непослушный агент автоматически эскалируется к изоляции, вместо того чтобы получать бесконечные попытки.

• Оценивает proposed action против политики и записывает вердикт как hard gate (заблокировано) или soft gate (разрешено с флагом) — то самое, чего требует Статья 12.

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

Постквантовая криптография: перестраховка или здравый смысл?

Каждая запись в аудитной цепочке подписывается настоящей подписью ML-DSA-65 (FIPS 204) — постквантовым алгоритмом. Это не хеш, не эмуляция, а полноценная цифровая подпись.

Логика такая: вся ценность аудитного трейла в том, что его нельзя подделать или изменить задним числом. «Собери сейчас — расшифруй потом» (harvest-now-decrypt-later) — реальная угроза для всего, что должно выдержать проверку через годы. Хендриет считает, что лучше подписи имели смысл в 2035 году, чем перестраивать систему, когда криптографический ландшафт сдвинется.

Здесь стоит отметить: это разумный подход с инженерной точки зрения, но конкретные сроки «квантовой угрозы» классическим алгоритмам — тема дискуссионная. NIST рекомендует начинать переход на постквантовые алгоритмы уже сейчас, но массового квантового взлома RSA/ECC в ближайшие годы эксперты не ожидают.

Важная оговорка: это не сертифицированное решение

Хендриет честно признаёт: система не сертифицирована. Никакого SOC 2, никакого FedRAMP. Это рабочий продукт, который он агрессивно тестирует на устойчивость — включая попытки сломать собственные предположения о работоспособности. По его словам, такое самотестирование выявило серьёзные проблемы, которые иначе попали бы в релиз.

Но давайте будем честны: статья — это, по сути, приглашение к диалогу и пиар собственного продукта Sentinel Beacon V5. Автор задаёт два вопроса читателям, работающим с агентами в регулируемых контекстах — и приглашает обращаться к нему напрямую. Это стандартный приём для pre-seed или early-stage стартапов: сначала создать экспертный контент, потом собрать обратную связь и потенциальных клиентов.

Это не делает аргументацию неверной. Но важно понимать контекст.

Что это значит на практике

Если вы разрабатываете или эксплуатируете ИИ-агентов в сферах, подпадающих под EU AI Act (здравоохранение, финансы, HR, юриспруденция, госуслуги и другие высокорисковые области), то к августу 2026 вам нужно ответить на два вопроса:

1. Можете ли вы прямо сейчас — без нескольких дней инженерной работы — предоставить запись, объясняющую, почему агент предпринял конкретное действие и какая политика была применена? Или вам придётся рыться в логах?

2. Ваш говернанс работает в момент исполнения или это слой наблюдения, который анализирует что уже произошло?

Если хотя бы на один из вопросов ответ «нет» — у вас проблема, и она не решается простым добавлением ещё одного логгера.

Скептическая нотка

Архитектура, которую описывает Хендриет, звучит рационально. Идея «gate + audit в одном шаге» — это действительно правильный паттерн для compliance-критичных систем. Но есть несколько моментов, которые стоило бы прояснить:

• Производительность. Добавление gate перед каждым tool-call неизбежно добавляет задержку. Для реалтайм-агентов это может быть критично.
• Масштаб. Хеш-связанная цепочка с постквантовыми подписями — это тяжёлые записи. Как это масштабируется на тысячи агентов с миллионами действий в день?
• Trust score. Идея хороша на бумаге, но реализация динамического scoring в продакшене — нетривиальная задача. Ложные срабатывания могут заблокировать агента, который просто попал в edge case.

Автор приглашает к дискуссии — и это правильно. Но до сертификации и референсных кейсов это остаётся архитектурным предложением, а не готовым решением.

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