EU AI Act Статья 9: непрерывное управление рисками для AI-агентов

Большинство инженерных команд рассматривают оценку рисков AI как деятельность перед развёртыванием. Вы оцениваете риски, документируете их, получаете одобрение и выпускаете. Готово.

Для AI-систем высокого риска статья 9 требует документированной системы управления рисками в течение жизненного цикла. Первоначальная оценка должна служить основой регулярных проверок и обновлений по мере изменения системы и рисков.

Для AI-агентов — которые эволюционируют, сталкиваются с новыми распределениями входных данных и работают в меняющихся бизнес-контекстах — это различие имеет огромное значение.

Коротко о главном

Статья 9 требует задокументированной системы управления рисками, а не единовременной оценки рисков

Система должна работать на протяжении всего жизненного цикла AI-системы, включая период после развёртывания

Риски должны оцениваться, анализироваться и снижаться непрерывно — не только при запуске

Остаточный риск должен быть задокументирован после снижения, и эта документация должна быть доступна

AI-агенты создают специфические проблемы для статьи 9: они сталкиваются с новыми входными данными, меняются со временем и взаимодействуют с другими системами

Что на самом деле требует статья 9

Статья 9 озаглавлена «Система управления рисками». Оперативный абзац определяет её как:

«…непрерывный итеративный процесс, выполняемый на протяжении всего жизненного цикла системы AI высокого риска, требующий регулярного систематического обновления».

Фраза «непрерывный итеративный процесс» является основным требованием. Она исключает подход «оцени один раз, выпусти и забудь». Статичный документ оценки рисков, который не обновляется по мере работы системы, не удовлетворяет статье 9.

Обязательные элементы системы управления рисками в соответствии со статьёй 9:

Выявление и анализ известных и предсказуемых рисков — Вы должны систематически выявлять, что может пойти не так. Это включает риски для основных прав, здоровья, безопасности и дискриминационные результаты.
Оценка и анализ рисков — Не только выявление: вы должны оценивать вероятность и серьёзность. Матрица рисков должна быть задокументирована.
Принятие соответствующих мер по управлению рисками — Меры управления рисками должны быть соразмерны выявленным рискам. Документирование риска без соразмерного снижения не удовлетворяет статье 9.
Документирование остаточного риска — После снижения оставшийся риск должен быть задокументирован и признан приемлемым. Планка «приемлемого» остаточного риска должна быть определена.
Тестирование на последовательность и адекватность — Меры управления рисками должны быть протестированы для проверки их реальной работы. Тестирование не является необязательным; оно является частью системы статьи 9.

Почему AI-агенты усложняют соответствие статье 9

Статичное программное приложение — механизм принятия решений на основе правил, классификатор с фиксированной логикой — работает с предсказуемыми профилями риска. Оценка рисков, проведённая при развёртывании, остаётся точной, пока приложение не меняется.

AI-агенты отличаются тремя способами, делающими статичную оценку рисков недостаточной.

Агенты сталкиваются с новыми входными данными. Агент для проверки контрактов, обученный на стандартных коммерческих контрактах, в итоге столкнётся с нестандартными входными данными — нетипичными структурами сделок, необычными условиями юрисдикции, документами, оформленными вне его обучающего распределения. Каждый новый паттерн входных данных — потенциальный новый риск, которого не было в первоначальной оценке.

Поведение агента меняется с обновлениями модели. Когда базовая модель обновляется — будь то вами или провайдером модели — поведение агента может меняться способами, не охваченными первоначальной оценкой рисков. Система, соответствующая статье 9, должна оценивать влияние обновлений модели на риски.

Агенты взаимодействуют с другими системами. Агент, вызывающий внешние API, обращающийся к базам данных клиентов или оркестрирующий суб-агентов, создаёт системные риски, которых не существует в изолированных приложениях. Риск ошибки доступа к данным, сбоя API или несанкционированного межагентного действия должен управляться непрерывно.

Построение непрерывной системы управления рисками

Шаг 1: Определите таксономию рисков

Прежде чем непрерывно управлять рисками, вам нужен структурированный способ их категоризации. Статья 9 не предписывает таксономию, но практическая таксономия для AI-агентов включает:

Класс риска	Описание	Примеры
Риск выходных данных	Агент производит вредоносные или несанкционированные выходные данные	Дискриминационное решение, неточный совет, утечка данных
Риск области применения	Агент работает вне своей авторизованной области	Доступ к несанкционированным данным, несанкционированные действия
Риск авторизации	Агент действует без необходимого одобрения человека	Автоматическое одобрение решений, требующих эскалации
Риск данных	Агент обрабатывает данные ненадлежащим образом	Превышение минимизации данных, ненадлежащее хранение
Риск взаимодействия	Агент создаёт каскадные эффекты через другие системы	Ошибки суб-агентов, сбои API, гонки условий

Шаг 2: Установите механизмы измерения рисков

Непрерывное управление рисками требует непрерывного измерения. Механизмы измерения для AI-агентов включают:

Частота нарушений конституциональных правил — Как часто запускаются проверки управления? Какова доля DENY vs PERMIT? Рост частоты DENY сигнализирует о дрейфе между поведением агента и политикой.
Частота триггеров эскалации — Как часто система эскалирует на проверку человеком? Устойчивые высокие темпы эскалации указывают либо на некорректно настроенные пороги, либо на реальную концентрацию рисков.
Мониторинг распределения входных данных — Остаются ли входящие запросы в пределах распределения, для которого была разработана система? Значительный сдвиг распределения — сигнал риска.
Обнаружение аномалий в выходных данных — Систематически ли отклоняются выходные данные от ожидаемых паттернов? Статистическое обнаружение аномалий на распределениях выходных данных выявляет дрейф, который пропускают проверки на основе правил.

Шаг 3: Определите триггеры обновления

Требование статьи 9 о «регулярном систематическом обновлении» нужно операционализировать. Определите явные триггеры, которые принуждают к проверке системы управления рисками:

Обновление версии модели (провайдером или внутреннее)
Значительное изменение области применения или возможностей агента
Добавление нового случая использования к мандату агента
Изменение нормативной базы (новое регулирование, обновлённое руководство)
Возникновение инцидента или близкого к инциденту события
Плановая проверка с документированной периодичностью с учётом рисков

Задокументируйте эти триггеры в спецификации вашей системы управления рисками. Когда триггер срабатывает, проверка должна состояться, а её результаты должны быть задокументированы.

Шаг 4: Задокументируйте принятие остаточного риска

После принятия мер по снижению статья 9 требует, чтобы остаточный риск был задокументирован и принят. Это означает:

Явное указание того, какой риск остаётся после снижения
Определение основания для принятия этого остаточного риска (ориентиры, аналогичные системы, юридическое руководство)
Определение лица, уполномоченного принимать остаточный риск от имени организации
Запись решения о принятии с датой и ссылкой на версию

На этом шаге большинство организаций имеют пробелы. Снижение задокументировано; принятие остаточного риска неформально или отсутствует.

О соответствующих требованиях к доказательствам аудита для ваших решений по управлению рисками см. EU AI Act Статья 12: требования к логированию — детальный разбор.

Статья 9 и runtime-управление

Контроли во время выполнения — один из способов реализовать документированные меры управления рисками. Свяжите каждый выбранный контроль с риском, ответственным владельцем и проверкой его действенности.

Риск, выявленный в оценке по статье 9, должен иметь соответствующее снижение. Для рисков AI-агентов наиболее распространённые меры снижения:

Конституциональное правило, предотвращающее рискованное действие
Шлюз эскалации, требующий проверки человеком для высокорисковых действий
Оповещение мониторинга, сигнализирующее о рисковом паттерне при его возникновении

Проверяйте выбранные меры снижения риска в рабочем процессе, где они действуют. Технические контроли, процедуры людей и мониторинг могут дополнять друг друга; запись в политике сама по себе не доказывает действенность меры.

Часто задаваемые вопросы

В: Удовлетворяет ли «оценка рисков», проведённая перед развёртыванием, требованиям статьи 9?

Только компоненты выявления и первоначальной оценки. Статья 9 требует непрерывной системы — оценка должна обновляться на протяжении всего жизненного цикла системы. Оценка перед развёртыванием — отправная точка соответствия статье 9, а не конечная.

В: Что означает «регулярное систематическое обновление» на практике?

Статья 9 предусматривает регулярный систематический пересмотр и обновление, но не устанавливает универсального квартального интервала. Документируйте периодичность с учётом рисков и темпа изменений; отдельно определите проверки после существенных обновлений, инцидентов или изменений использования.

В: Несут ли сторонние провайдеры моделей ответственность за соответствие статье 9?

Обязанности провайдера AI-системы высокого риска и обязанности её пользователя различаются. Использование сторонней модели не делает вашу организацию провайдером системы автоматически. Определите роли по тому, кто разрабатывает, поставляет, маркирует и модифицирует систему.

В: Как статья 9 взаимодействует со статьёй 17 (система управления качеством)?

Статья 17 требует системы управления качеством для провайдеров систем AI высокого риска. Система управления рисками, требуемая статьёй 9, является обязательным компонентом системы управления качеством по статье 17. На практике: статья 9 определяет, что вы должны делать для управления рисками; статья 17 определяет, как эта практика управления рисками должна быть встроена в вашу организационную систему качества.

В: Мы работаем в США, а не в ЕС. Применяется ли к нам статья 9?

Статья 2 может охватывать организации за пределами ЕС, включая провайдеров и пользователей систем, результаты которых используются в ЕС. Проверьте конкретное территориальное основание, классификацию системы и роль оператора; гражданство ЕС или наличие персональных данных из ЕС само по себе не определяет применимость статьи 9.

Николай Ковтун, основатель Infracortex AI Studio. Cortex поддерживает оценку политик во время выполнения и записи, которые команды могут связать со своим процессом управления рисками. Забронируйте звонок для оценки пробелов в соответствии статье 9

См. также: EU AI Act Статья 12: требования к логированию — детальный разбор | EU AI Act Статья 14: построение практического надзора человека | Почему runtime — это commodity, а управление — это ров (EN)