Загальна оцінка точності може приховувати збій для окремого формату документа або процесу. Визначте метрику, тестову сукупність і наслідки неправильного результату до оцінки його прийнятності.
Для перевірки доходів досліджуйте формати та умови, з якими система має працювати. Аналізуйте концентрацію помилок, не припускаючи однакової якості в усіх передбачених випадках.
Для системи високого ризику стаття 15 вимагає належної точності, стійкості й кібербезпеки протягом життєвого циклу. Пов'яжіть докази якості з моніторингом, обробкою помилок і перевіреною резервною поведінкою для важливих у цьому використанні збоїв.
Коротко про головне
- Стаття 15 вимагає від систем AI високого ризику досягнення відповідних рівнів точності, стійкості та кібербезпеки
- Точність — це не єдиний тест: вона повинна підтримуватись протягом усього терміну служби системи та вимірюватись за релевантними підгрупами
- Стійкість охоплює захищеність від помилок, несправностей та невідповідностей — включаючи змагальні вхідні дані
- Кібербезпека вимагає захисту від атак, які можуть змінити поведінку системи
- Обробка помилок і резервна поведінка повинні бути визначені, задокументовані та протестовані
Що охоплює стаття 15
Точність
Стаття 15 вимагає від систем AI високого ризику досягнення «відповідних рівнів точності». «Відповідних» означає, що стандарт точності залежить від контексту. Вимога до точності поширюється на підгрупи — система з 99% загальною точністю, що систематично гірше працює для конкретних демографічних або географічних груп, не задовольняє статті 15, якщо це зниження продуктивності створює дискримінаційні ефекти.
Стійкість
- Стійкість до вхідних даних — Як агент обробляє неправильно сформовані вхідні дані або дані поза його навчальним розподілом?
- Операційна стійкість — Як поводиться агент при збоях upstream-залежностей?
- Поведінка в деградованому режимі — Що відбувається, коли компонент системи недоступний?
- Змагальна стійкість — Чи може система бути маніпульована через ін’єкцію промптів, отруєння даних?
Кібербезпека
Основні проблеми кібербезпеки для AI-агентів:
- Ін’єкція промптів
- Вилучення моделі
- Отруєння навчальних даних
- Маніпуляція при виведенні
Практична реалізація
Реалізація точності
Визначте метрики точності для кожного випадку використання. Встановіть порогові значення та моніторинг. Задокументуйте докази точності в технічній документації Додатку IV.
Реалізація стійкості
| Вимір стійкості | Тип тесту | Мінімально необхідне |
|---|---|---|
| Граничні випадки вхідних даних | Граничне тестування | Визначена поведінка для всіх вхідних даних |
| Збій залежності | Хаос-тестування | Задокументована поведінка в деградованому режимі |
| Змагальні вхідні дані | Red team / ін’єкція промптів | Протестований, задокументований залишковий ризик |
| Зсув розподілу | Shadow deployment | Сповіщення моніторингу при виявленні зсуву |
Реалізація кібербезпеки
Зниження ризику ін’єкції промптів. Поведінковий моніторинг. Управління доступом і ізоляція — принцип найменших привілеїв.
Зобов’язання щодо тестування
Будуйте план тестування навколо призначення системи та ризиків, визначених за статтею 9. Практичні перевірки можуть включати:
- Тестування перед розгортанням
- Змагальне тестування (red teaming, ін’єкція промптів)
- Аналіз продуктивності за підгрупами
- Аналіз режимів збою та документація
- Безперервний моніторинг після розгортання
Вимоги до обробки помилок
Кожен тип помилки повинен мати визначений обробник. Обробка помилок повинна бути протестована. Помилки повинні бути зафіксовані. Резервна поведінка повинна бути безпечною — при невизначеності ескалація або відмова.
Часті запитання
П: Чи вимагає стаття 15 конкретного порогу точності?
Ні. «Відповідної» точності — стандарту, що залежить від контексту.
П: Чи вимагають оновлення моделі від нашого провайдера повторного тестування за статтею 15?
Так. Оновлення моделі можуть змінювати характеристики точності та стійкості.
Микола Ковтун, засновник Infracortex AI Studio. Шар управління Cortex генерує докази, необхідні для демонстрації відповідності статті 15. Забронюйте 30-хвилинний дзвінок для оцінки прогалин за статтею 15.
Дивіться також: EU AI Act Стаття 9: безперервне управління ризиками | EU AI Act Стаття 12: вимоги до журналювання | Спостережуваність AI-агентів vs управління