Більшість інженерних команд розглядають оцінку ризиків AI як діяльність перед розгортанням. Ви оцінюєте ризики, документуєте їх, отримуєте схвалення і випускаєте. Готово.
Для AI-систем високого ризику стаття 9 вимагає задокументованої системи управління ризиками протягом життєвого циклу. Початкова оцінка має бути основою регулярних перевірок та оновлень у міру змін системи й ризиків.
Для AI-агентів — які еволюціонують, стикаються з новими розподілами вхідних даних і працюють у мінливих бізнес-контекстах — ця різниця має величезне значення.
Коротко про головне
- Стаття 9 вимагає задокументованої системи управління ризиками, а не одноразової оцінки ризиків
- Система повинна працювати протягом усього життєвого циклу AI-системи, включно з періодом після розгортання
- Ризики повинні оцінюватися, аналізуватися та знижуватися безперервно — не лише при запуску
- Залишковий ризик повинен бути задокументований після зниження
- AI-агенти створюють специфічні проблеми для статті 9: вони стикаються з новими вхідними даними, змінюються з часом і взаємодіють з іншими системами
Що насправді вимагає стаття 9
Стаття 9 озаглавлена «Система управління ризиками». Оперативний абзац визначає її як:
«…безперервний ітеративний процес, що виконується протягом усього життєвого циклу системи AI високого ризику, що вимагає регулярного систематичного оновлення».
Фраза «безперервний ітеративний процес» є основною вимогою. Обов’язкові елементи системи управління ризиками:
- Виявлення та аналіз відомих і передбачуваних ризиків
- Оцінка та аналіз ризиків — ймовірність і серйозність, задокументовані
- Прийняття відповідних заходів з управління ризиками — пропорційних виявленим ризикам
- Документування залишкового ризику — після зниження
- Тестування на послідовність і адекватність
Чому AI-агенти ускладнюють відповідність статті 9
Агенти стикаються з новими вхідними даними. Кожен новий паттерн вхідних даних — потенційний новий ризик, якого не було в початковій оцінці.
Поведінка агента змінюється з оновленнями моделі. Система, що відповідає статті 9, повинна оцінювати вплив оновлень моделі на ризики.
Агенти взаємодіють з іншими системами. Ризик помилки доступу до даних, збою API або несанкціонованої міжагентної дії повинен управлятися безперервно.
Побудова безперервної системи управління ризиками
Крок 1: Визначте таксономію ризиків
| Клас ризику | Опис | Приклади |
|---|---|---|
| Ризик вихідних даних | Агент виробляє шкідливі або несанкціоновані вихідні дані | Дискримінаційне рішення, неточна порада, витік даних |
| Ризик обсягу | Агент працює поза своєю авторизованою областю | Доступ до несанкціонованих даних |
| Ризик авторизації | Агент діє без необхідного схвалення людини | Автоматичне схвалення рішень, що вимагають ескалації |
| Ризик даних | Агент обробляє дані неналежним чином | Перевищення мінімізації даних |
| Ризик взаємодії | Агент створює каскадні ефекти через інші системи | Помилки суб-агентів, збої API |
Крок 2: Встановіть механізми вимірювання ризиків
- Частота порушень конституційних правил
- Частота тригерів ескалації
- Моніторинг розподілу вхідних даних
- Виявлення аномалій у вихідних даних
Крок 3: Визначте тригери оновлення
- Оновлення версії моделі
- Значна зміна обсягу або можливостей агента
- Додавання нового випадку використання
- Зміна нормативної бази
- Виникнення інциденту або близького до інциденту події
- Планова перевірка із задокументованою періодичністю відповідно до ризиків
Крок 4: Задокументуйте прийняття залишкового ризику
- Явне зазначення того, який ризик залишається після зниження
- Визначення підстав для прийняття цього залишкового ризику
- Визначення особи, уповноваженої приймати залишковий ризик від імені організації
- Запис рішення про прийняття з датою та посиланням на версію
Стаття 9 і runtime-управління
Контролі під час виконання — один зі способів реалізувати задокументовані заходи управління ризиками. Пов'яжіть кожен обраний контроль із ризиком, відповідальним власником і тестом його дієвості.
Часті запитання
П: Чи задовольняє «оцінка ризиків», проведена перед розгортанням, вимогам статті 9?
Лише компоненти виявлення та початкової оцінки. Стаття 9 вимагає безперервної системи.
П: Що означає «регулярне систематичне оновлення» на практиці?
Стаття 9 передбачає регулярний систематичний перегляд та оновлення, але не встановлює універсального квартального інтервалу. Задокументуйте періодичність відповідно до ризиків і темпу змін; окремо визначте перевірки після суттєвих оновлень, інцидентів або змін використання.
П: Чи несуть треті сторони — провайдери моделей — відповідальність за відповідність статті 9?
Обов'язки провайдера системи AI високого ризику та обов'язки її користувача відрізняються. Використання сторонньої моделі не робить вашу організацію провайдером системи автоматично. Визначте ролі за тим, хто розробляє, постачає, маркує та модифікує систему.
Микола Ковтун, засновник Infracortex AI Studio. Cortex підтримує оцінку політик під час виконання та записи, які команди можуть пов'язати зі своїм процесом управління ризиками. Забронюйте дзвінок для оцінки прогалин у відповідності статті 9
Дивіться також: EU AI Act Стаття 12: вимоги до журналювання | EU AI Act Стаття 14: побудова практичного нагляду людини | Чому runtime — це commodity, а управління — це рів (EN)