Поетапне застосування AI Act ЄС дійшло до частин, важливих для команд безпеки. Із серпня 2026 року зобовʼязання щодо високоризикового AI — включно з положеннями про кібербезпеку — застосовуються на повну. Ця стаття для керівника безпеки, чия компанія стоїть по будь-який бік «лінії AI»: виробляє AI-продукт або використовує AI-системи, що торкаються захищених даних, регульованих процесів чи критичної інфраструктури.
Стаття 15 — точність, стійкість і кібербезпека
Стаття 15 — та частина AI Act, що втягує команди безпеки в зону дії. Для високоризикових AI-систем провайдери мають «проєктувати та розробляти» систему так, щоб досягти «належного рівня точності, стійкості та кібербезпеки», із заходами, що включають:
- Стійкість до спроб змінити використання, вихідні дані чи продуктивність системи через несанкціоновану маніпуляцію вхідними даними — тобто до атак adversarial input.
- Стійкість до інверсії моделі, витягування моделі та membership inference, коли вхідні або навчальні дані чутливі.
- Логування подій, повʼязаних із безпекою, із простежуваністю вхідних і вихідних даних.
- Визначений рівень точності, задекларований у технічній документації, та процес моніторингу дрейфу.
Моделювання загроз adversarial ML — для команди безпеки
AI-специфічні загрози, релевантні статті 15, — добре задокументовані:
- Атаки adversarial input: спеціально сконструйовані вхідні дані, що спричиняють хибну класифікацію чи небезпечні відповіді. Мітигації: валідація вхідних даних, ансамблеві рішення, тестування на обмежених вхідних діапазонах під час оцінювання.
- Атаки з отруєнням даних: маніпульовані навчальні дані, що псують модель. Мітигації: контроль походження навчальних даних, перевірка постачальників і перевірки цілісності навчального пайплайна.
- Витягування моделі: запити, що реконструюють модель. Мітигації: обмеження частоти запитів, збурення вихідних даних, водяні знаки для чутливих моделей.
- Інверсія моделі / membership inference: запити, що реконструюють навчальні дані. Мітигації: диференційна приватність у навчанні, шум у вихідних даних, контроль доступу.
- Prompt injection (для систем на LLM): зловмисні вхідні дані, що перекривають системні промпти. Мітигації: санітизація вхідних даних, валідація вихідних, обмежені виклики інструментів.
Високоризикові системи — практичний перелік
Додаток III перелічує високоризикові категорії. Найважливіші для безпеки та покупців із регульованих галузей:
- Біометрична ідентифікація та категоризація.
- Критична інфраструктура (електроенергія, газ, вода, транспорт, управління рухом).
- Освіта та професійне навчання (вступ, оцінювання).
- Зайнятість (рекрутинг, оцінка результативності).
- Доступ до основних приватних і публічних послуг (кредитний скоринг, ціноутворення страхування життя і здоровʼя, право на виплати).
- Правоохоронна діяльність (предиктивна поліцейська робота, оцінка надійності доказів).
- Міграція, притулок, управління прикордонним контролем.
- Здійснення правосуддя та демократичні процеси.
Що має показувати технічна документація
Технічна документація за додатком IV обширна. Елементи, повʼязані з кібербезпекою:
- Опис елементів AI-системи та процесу розробки — включно з методологією навчання, джерелами даних і процедурою валідації.
- Опис заходів кібербезпеки з простежуваністю до ідентифікованих загроз.
- План постринкового моніторингу з метриками та тригерами перегляду.
- Документація управління ризиками, що повʼязує ідентифіковані ризики з мітигаціями та залишковими ризиками.
- Для систем, навчених на персональних даних, — правова підстава та технічні заходи приватності (звʼязок зі статтею 32 GDPR і взаємодією GDPR та AI Act).
Як це лягає в наявну програму безпеки
Для організацій, що вже мають програми за NIS2 чи ISO 27001, AI Act додає два операційні шари:
- AI-специфічне моделювання загроз, інтегроване у ваш наявний ритм моделювання загроз. Це інкрементальна робота, а не окрема функція.
- AI-специфічне тестування — оцінювання adversarial input, тестування prompt injection для LLM-систем — додане до наявного обсягу пентестів.
Для організацій, які ще не запустили програму інформаційної безпеки, AI Act стає для неї примусовим приводом. Технічну документацію неможливо правдоподібно зібрати без ISMS в основі.
Де тут Sandline
Ми проводимо тестування adversarial ML і prompt injection у межах пентест-проєктів, інтегруємо AI-специфічний ризик у наявні програми управління вразливостями та готуємо кібербезпекову частину технічної документації за AI Act. Ми не беремося за роботу з упередженістю AI та оцінкою фундаментальних прав — для цього потрібні фахівці з іншим мандатом.