AI governance evidence pack - это набор записей, который нужен регулируемой команде до того, как AI-агента можно спокойно показать юристам, службе безопасности, аудиторам или надзорному органу. Это не папка со скриншотами и не выгрузка всех логов подряд. Это доказательная цепочка, связывающая политику, классификацию риска, решение на этапе выполнения, человеческий надзор и мониторинг после запуска.
Проблема почти всегда во времени. Команда пишет responsible AI policy до запуска, подключает наблюдаемость после запуска, а затем пытается собрать доказательства, когда клиент или аудитор спрашивает, как именно агент был ограничен. В этот момент часто отсутствует главная запись: почему конкретное действие было разрешено, отклонено или отправлено на проверку до выполнения.
Проектируйте пакет доказательств вокруг обязанностей, применимых к системе. Для систем высокого риска AI Act связывает управление рисками, журналирование, техническую документацию, надзор и требования к качеству; пакет должен делать эти связи пригодными для проверки.
Ключевые выводы
- Evidence pack связывает политику, решение системы и дальнейшую проверку в одну цепочку.
- Сырые логи полезны, но они не отвечают на вопрос, было ли действие разрешено политикой.
- EU AI Act делает записи, техническую документацию и человеческий надзор проектными обязанностями для систем высокого риска.
- NIST AI RMF полезен как операционная модель: роли, контекст, измерение и управление риском.
- Самая сильная доказательная база создаётся во время работы, а не реконструируется после запроса.
Что должен показывать evidence pack
Evidence pack должен показывать, что организация знала, что агенту разрешено делать, поставила контроль перед значимыми действиями и сохранила записи, которые можно проверить позже. Это более узкий и более полезный стандарт, чем фраза «у нас есть логи».
Есть четыре вопроса, на которые пакет должен отвечать без просьбы к инженеру вручную искать событие в трассировках.
| Вопрос аудитора | Какая запись нужна | Почему одних логов мало |
|---|---|---|
| Что агенту было разрешено делать? | Утверждённая политика, классы действий, классификация риска | Логи показывают событие, но не правило |
| Почему действие прошло? | Запись решения с версией политики, контекстом и вердиктом | Трасса может не содержать контекст авторизации |
| Кто мог вмешаться? | Роль надзора, очередь проверки, решение, время | Имя в политике не равно рабочему маршруту проверки |
| Что изменилось после утверждения? | История версий, результаты тестов, мониторинг | Логи редко объясняют дрейф управления |
Именно поэтому нужны governance gates и audit records. В статье AI Agent Observability vs Governance отдельно разобран вопрос времени: observability объясняет прошлое, а governance оценивает следующее действие до его выполнения.
Юридическая опора: требования EU AI Act
Для систем высокого риска EU AI Act превращает доказательность в требование к продукту. В официальном тексте регламента Article 9 описывает систему управления рисками, Article 12 - автоматическое ведение записей, Article 14 - человеческий надзор, Article 15 - точность, устойчивость и кибербезопасность. Article 11 связывает техническую документацию с Annex IV.
Классифицируйте назначение по статье 6 и соответствующему пункту Приложения I или III. Сами названия медицинского, юридического или финансового секторов не делают каждый агент высокорисковым. Документируйте основание классификации и роли операторов до определения доказательных обязанностей.
Практическая привязка выглядит так.
| Область EU AI Act | Элемент evidence pack | Операционный контроль |
|---|---|---|
| Article 9 risk management | Реестр рисков, предсказуемое неправильное использование, решение о снижении риска | Проверка до запуска и после значимого изменения |
| Article 12 record-keeping | Автоматические события на протяжении жизненного цикла | Append-only audit record с контекстом политики и действия |
| Article 14 human oversight | Роль надзора, маршрут эскалации, полномочие отмены | Очередь проверки перед значимым или необратимым действием |
| Article 15 robustness | Результаты тестов, режимы отказа, обработка инцидентов | Мониторинг, регрессионные тесты, план отката |
| Annex IV documentation | Назначение системы, архитектура, данные, тестирование, надзор | Версионированная техническая документация |
Если нужна детализация по логированию, см. EU AI Act Статья 12: требования к логированию. Для практического надзора см. EU AI Act Статья 14: построение практического надзора человека.
Операционная модель: NIST AI RMF
NIST AI RMF не заменяет юридическую оценку, но хорошо переводит управление AI-риском в регулярную работу. Фреймворк строится вокруг четырёх функций: Govern, Map, Measure, Manage.
Для evidence pack особенно важна раздельность ролей. Govern отвечает на вопрос, есть ли политика, ответственность и процесс риска. Map проверяет, понятен ли контекст применения и возможное воздействие. Measure описывает, как оцениваются риски, качество, устойчивость и вред. Manage фиксирует, как организация приоритизирует и снижает риски.
Эта структура предотвращает частый сбой: команда собирает технические артефакты, но теряет управленческие решения. Model card, prompt-файл, результат eval или trace полезны, но недостаточны, если их нельзя связать с владельцем, классификацией риска и действием по политике.
На практике пакет должен содержать:
- Границы системы. К каким данным агент имеет доступ, какие действия может запрашивать, какие действия запрещены, какие требуют проверки.
- Классификацию риска. Почему процесс относится к низкому, ограниченному, высокому или иному уровню, с указанием бизнес- и правовых допущений.
- Источник политики. Утверждённый набор правил: что разрешается, что отклоняется, что отправляется на проверку.
- Записи решений. Для каждого значимого действия: запрос, контекст, версия политики, вердикт, время и проверяющий, если он был нужен.
- Доказательства надзора. Состояние очереди, полномочие проверяющего, решение, причина и путь отмены.
- Доказательства тестирования. Тестовые сценарии до запуска, известные режимы отказа, результаты проверок после изменений.
- Доказательства мониторинга. Сигналы дрейфа, инциденты, post-release review и решения о выводе функции из работы, если они были.
Ни один из этих элементов не требует выдуманных чисел. Если метрика не измеряется, честная запись должна показать отсутствие измерения и план его появления.
Почему обычные логи не закрывают governance
Обычные логи описывают события. Governance evidence объясняет авторизацию.
Trace может показать, что агент обратился к CRM в 14:03, использовал конкретную модель и получил успешный ответ. Это полезно для отладки. Но такая трасса не отвечает, было ли действие разрешено для этого клиента, было ли достаточно контекста, можно ли отменить действие, требовалось ли одобрение человека и какая версия политики применялась.
Недостающее звено - запись решения. Она должна создаваться до выполнения действия и связываться с операционной трассой. Если действие разрешено, запись объясняет почему. Если отклонено, запись объясняет почему. Если отправлено на проверку, запись следует за человеческим решением.
Это различие между observability и governance. Observability помогает понять, что произошло. Governance решает, что разрешено произойти. Регулируемой системе нужны оба слоя, но именно governance record показывает, что у действия было основание до выполнения.
Практический порядок внедрения
Самый быстрый ответственный путь - узкий.
Начните с первых трёх классов действий, которые могут повлиять на клиента, деньги, юридическое состояние, безопасность или регулируемые данные. Не начинайте со всех prompt. Начинайте с действий, которые имеют последствия.
Для каждого класса задайте разрешённый путь, запрещённый путь и путь эскалации. Требуйте запись решения до выполнения. Добавьте очередь проверки для действий с высоким воздействием, неясным контекстом или сложной отменой. Свяжите каждую операционную трассу с governance decision. После реального периода работы пересмотрите результаты и обновите политику с историей версий.
Так появляется небольшой, но защищаемый evidence pack. Он не закрывает все AI-риски. Но он меняет разговор с аудитором: команда показывает политику, решение, действие и review как одну цепочку.
Частые вопросы
В: Evidence pack - это то же самое, что техническая документация?
Нет. Техническая документация входит в пакет, особенно для Annex IV EU AI Act. Но пакет также включает операционные записи: решения по действиям, события надзора, тесты, мониторинг и изменения после запуска.
В: Можно ли собрать пакет только тогда, когда пришёл аудитор?
Документы можно собрать позже, но отсутствующие записи решений нельзя восстановить с той же надёжностью. Самая сильная запись создаётся в момент оценки действия.
В: Каждому AI-процессу нужен такой уровень governance?
Нет. Уровень должен следовать риску. Внутренние низковлияющие процессы могут иметь более лёгкие записи. Агенты, влияющие на клиентов, регулируемые решения, деньги, здоровье, юридическую работу или доступ к услугам, требуют более сильной доказательной базы.
В: Что строить первым?
Классы действий и запись решения. Без них логи и dashboards остаются оторванными от политики.
Использованные источники
- Regulation (EU) 2024/1689, Artificial Intelligence Act
- Обзор AI Act от European Commission
- NIST AI Risk Management Framework
Николай Ковтун, основатель InfraCortex AI Studio. Мы помогаем регулируемым командам превращать политики AI-агентов в контроль на этапе выполнения и доказательства, готовые к аудиту. Забронируйте discovery call.