EU AI Act для ШІ-функції: що перевірити перед релізом

Сцена перед релізом

Функція майже готова. У демо все працює: користувач вводить короткий опис товару, ШІ-система генерує текст для сторінки, а редактор може одразу його підправити. Команда вже думає про реліз, аж раптом на щоденній зустрічі звучить просте питання: чи треба позначати цей результат як створений ШІ, і хто відповідатиме, якщо система помилиться.

Саме тут EU AI Act перестає бути абстрактним законом з новин. Для команди продукту це стає звичайною передрелізною перевіркою: що ми запускаємо, кому це доступно, який рівень ризику має функція, що бачить користувач, які докази ми збережемо, якщо через місяць треба буде пояснити рішення.

Ця стаття не замінює юриста. Але вона допомагає розробнику або власнику функції підготувати нормальний технічний пакет перед тим, як іти до юриста, без паніки й без фрази «ми просто підключили модель».

Спочатку опишіть, що саме робить ШІ

Найгірший початок для перевірки відповідності вимогам — сказати «у нас там трохи ШІ». Так команда одразу губить межі відповідальності. Краще описати функцію як маленький сценарій.

Наприклад: користувач пише коротке завдання, система відправляє його до моделі, отримує текст, показує результат у редакторі, а користувач може прийняти, змінити або відхилити відповідь. Якщо функція генерує зображення, варто так само записати, хто вводить запит, де зображення зберігається, чи публікується воно назовні, чи можна його завантажити.

Цей опис потрібен не для бюрократії. Він визначає, чи є у вас ШІ-система, де виникає синтетичний вміст, чи взаємодіє користувач із ШІ напряму, і які журнали подій треба зберігати. Без цього команда сперечатиметься про закон, не маючи карти самої функції.

Практична ознака хорошого опису: новий інженер може прочитати його й за п’ять хвилин пояснити, який результат створює модель, де людина може втрутитися, і що піде в реліз.

Далі визначте рівень ризику

EU AI Act працює через підхід на основі ризику. Це означає, що різні ШІ-системи не мають однакових вимог. Система, яка допомагає написати опис товару, і система, яка впливає на доступ до роботи, освіти, кредиту або критичної послуги, не живуть в одному режимі.

На високому рівні є чотири зони. Деякі практики заборонені. Частина систем потрапляє в високий ризик і потребує серйознішого контролю. Частина має обмежений ризик, де головне питання — прозорість для користувача. Багато повсякденних функцій можуть залишатися в мінімальному ризику, але це не означає, що можна нічого не документувати.

Для нашої функції з генерацією тексту команда не повинна сама героїчно робити фінальний юридичний висновок. Їй достатньо підготувати коротку нотатку: що робить функція, чому вона схожа або не схожа на високий ризик, які користувачі зачеплені, чи може результат вплинути на права людини або важливе рішення.

Антипатерн тут простий: назвати все мінімальним ризиком, бо «це лише текст». Текст може бути нешкідливою чернеткою, а може потрапити в лист про відмову кандидату, медичну пораду або фінансове рішення. Ризик залежить не від красивості моделі, а від контексту використання.

Перевірте вимоги прозорості

Для багатьох продуктових команд найпомітніша частина EU AI Act — вимоги прозорості. Користувач не має випадково думати, що розмовляє з людиною, якщо насправді взаємодіє з ШІ. Так само для частини синтетичного вмісту потрібне маркування або технічний спосіб розпізнати походження результату.

У нашому прикладі це перетворюється на кілька інженерних питань. Чи видно в інтерфейсі, що текст запропонований ШІ? Чи залишається за людиною фінальне рішення перед публікацією? Чи зберігаємо ми факт генерації в журналі подій? Чи може експортований результат втратити позначку? Чи знає служба підтримки, як відповідати на скаргу про неправильний результат?

Не треба робити інтерфейс страшним або перевантажувати його юридичними попередженнями. Але позначення має бути чесним і стабільним. Якщо користувач бачить кнопку «Згенерувати опис», а після цього отримує редагований текст із позначкою походження, це краще, ніж ховати ШІ за нейтральним словом «покращити» й не лишати жодного сліду.

Окремо варто перевірити експорт. Багато команд маркують результат у веб-інтерфейсі, але забувають про PDF, публічну сторінку, відповідь програмного інтерфейсу або інтеграцію з іншим сервісом. Саме там прозорість часто ламається.

Зберіть мінімальні артефакти релізу

Передрелізна перевірка не повинна перетворюватися на двадцять документів, які ніхто не читає. Для першого нормального рівня достатньо кількох артефактів.

Перший — короткий опис функції й потоку даних. Другий — нотатка про рівень ризику з відкритими питаннями. Третій — перелік моделей, програмних інтерфейсів та постачальників, які використовує функція. Четвертий — тестові докази: приклади нормальних відповідей, відмов, помилок, спроб обійти обмеження. П’ятий — журнал подій: мінімум час, користувач або технічний ідентифікатор, тип дії, версія моделі чи налаштувань, статус результату.

Ще потрібен шлях реагування на інцидент. Не роман на десять сторінок, а проста відповідь: хто приймає повідомлення, хто може вимкнути функцію, де лежать журнали подій, як швидко продуктова команда має зібрати факти, кого треба підключити з безпеки, права або підтримки.

Добрий тест: якщо завтра користувач скаже, що ШІ-згенерований результат нашкодив йому або ввів в оману, команда зможе відновити події без археології в чатах.

Зробіть передрелізну перевірку частиною процесу

Найкраще місце для EU AI Act-перевірки — не окремий героїчний документ перед кінцевим терміном, а звичайний контрольний етап релізу. Наприклад, поруч із пунктами про безпеку, приватність, доступність і спостережуваність.

Для маленької ШІ-функції контрольний етап може бути коротким. Чи описано сценарій? Чи записано попередній рівень ризику? Чи перевірено вимоги прозорості? Чи є журнали подій? Чи тестували небажані відповіді? Чи є власник інциденту? Чи може команда вимкнути функцію без повного відкату релізу?

Якщо на два або три питання відповідь «не знаємо», це не завжди означає стоп релізу. Але це означає, що ризик не керований. Тоді краще звузити запуск, обмежити аудиторію, додати ручне підтвердження або відкласти частину функціональності.

Типові помилки

Перша помилка — згадати EU AI Act після того, як усе вже працює в робочому середовищі. Тоді кожне виправлення виглядає як аварійний ремонт, а команда починає сперечатися з реальністю.

Друга — думати тільки про модель. Регуляторний ризик часто живе не в самій моделі, а в продукті: хто бачить результат, яке рішення він підтримує, чи є людський контроль, чи можна перевірити історію.

Третя — не маркувати синтетичний вміст там, де він виходить за межі редактора. Якщо вміст піде в публічний канал, інтеграцію або файл, позначення не має зникати по дорозі.

Четверта — не мати журналів подій. Без них команда може мати найкращі наміри, але не матиме фактів.

Практичний висновок

Для команди розробки EU AI Act краще сприймати як частину операційної готовності, а не як страшну юридичну хмару над релізом. Почніть із карти функції, визначте попередній рівень ризику, перевірте прозорість, збережіть мінімальні артефакти й додайте короткий контрольний етап перед запуском.

Це не зробить продукт автоматично відповідним усім вимогам. Але це зробить розмову з юристами, безпекою та бізнесом предметною. І найважливіше — команда знатиме, що саме вона запускає, як це пояснити користувачу і що робити, якщо система помилиться.

Джерела

• Docker Blog: What Does EU AI Act Compliance Require? — https://www.docker.com/blog/eu-ai-act-compliance/
• Regulation (EU) 2024/1689 on artificial intelligence — https://eur-lex.europa.eu/eli/reg/2024/1689/oj
• European Commission: Regulatory framework on AI — https://digital-strategy.ec.europa.eu/en/policies/regulatory-framework-ai
• European Commission: AI Office — https://digital-strategy.ec.europa.eu/en/policies/ai-office