AI governance evidence pack - це набір записів, потрібний регульованій команді до того, як AI-агента можна впевнено показати юристам, security, аудиторам або наглядовому органу. Це не папка зі скриншотами і не вивантаження всіх логів без структури. Це доказовий ланцюг, який пов’язує політику, класифікацію ризику, рішення на етапі виконання, людський нагляд і моніторинг після запуску.
Практична проблема майже завжди в часі. Команда пише responsible AI policy до запуску, додає observability після запуску, а потім намагається зібрати докази, коли клієнт, аудитор або регулятор питає, як саме агент був обмежений. У цей момент часто бракує найважливішого запису: чому конкретну дію було дозволено, відхилено або передано людині до виконання.
Проєктуйте пакет доказів навколо обов'язків, застосовних до системи. Для систем високого ризику AI Act пов'язує управління ризиками, журналювання, технічну документацію, нагляд і вимоги до якості; пакет має робити ці зв'язки придатними до перевірки.
Ключові висновки
- Evidence pack пов’язує політику, рішення системи та подальший review в один ланцюг.
- Сирі логи корисні, але вони не відповідають на питання, чи була дія дозволена політикою.
- EU AI Act робить записи, технічну документацію та людський нагляд проєктними обов’язками для систем високого ризику.
- NIST AI RMF корисний як операційна модель: ролі, контекст, вимірювання і управління ризиком.
- Найсильніша доказова база створюється під час роботи, а не відновлюється після запиту.
Що має показувати evidence pack
Evidence pack має показувати, що організація знала, що агенту дозволено робити, поставила контроль перед значущими діями і зберегла записи, які можна перевірити пізніше. Це вужчий і корисніший стандарт, ніж фраза «у нас є логи».
Є чотири питання, на які пакет має відповідати без прохання до інженера вручну шукати подію у трасах.
| Питання аудитора | Який запис потрібен | Чому самих логів мало |
|---|---|---|
| Що агенту було дозволено робити? | Затверджена політика, класи дій, класифікація ризику | Логи показують подію, але не правило |
| Чому дія пройшла? | Запис рішення з версією політики, контекстом і вердиктом | Траса може не мати контексту авторизації |
| Хто міг втрутитися? | Роль нагляду, черга перевірки, рішення, час | Ім’я в політиці не дорівнює робочому маршруту review |
| Що змінилося після approval? | Історія версій, результати тестів, моніторинг | Логи рідко пояснюють дрейф governance |
Саме тому потрібні 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 корисні, але недостатні, якщо їх не можна зв’язати з власником, класифікацією ризику і дією за політикою.
На практиці пакет має містити:
- Межі системи. До яких даних агент має доступ, які дії може запитувати, які дії заборонені, які потребують перевірки.
- Класифікацію ризику. Чому процес має низький, обмежений, високий або інший рівень ризику, із зазначенням бізнесових і правових припущень.
- Джерело політики. Затверджений набір правил: що дозволяється, що відхиляється, що передається на review.
- Записи рішень. Для кожної значущої дії: запит, контекст, версія політики, вердикт, час і reviewer, якщо він був потрібен.
- Докази нагляду. Стан черги, повноваження reviewer, рішення, причина і шлях скасування.
- Докази тестування. Тестові сценарії до запуску, відомі режими відмови, результати перевірок після змін.
- Докази моніторингу. Сигнали дрейфу, інциденти, post-release review і рішення про виведення функції з роботи, якщо вони були.
Жоден із цих елементів не потребує вигаданих чисел. Якщо метрика не вимірюється, чесний запис має показати відсутність вимірювання і план його створення.
Чому звичайні логи не закривають governance
Звичайні логи описують події. Governance evidence пояснює авторизацію.
Trace може показати, що агент звернувся до CRM о 14:03, використав конкретну модель і отримав успішну відповідь. Це корисно для debug. Але така траса не відповідає, чи була дія дозволена для цього клієнта, чи було достатньо контексту, чи можна скасувати дію, чи була потрібна згода людини і яка версія політики застосовувалася.
Відсутня ланка - запис рішення. Він має створюватися до виконання дії і зв’язуватися з операційною трасою. Якщо дію дозволено, запис пояснює чому. Якщо відхилено, запис пояснює чому. Якщо передано людині, запис рухається разом із людським рішенням.
Це різниця між 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.