Fundamental Rights Impact Assessment (FRIA) за EU AI Act: коли потрібна оцінка впливу на основоположні права та як вона співвідноситься з DPIA за GDPR

1. FRIA за EU AI Act: коли потрібно оцінювати вплив AI?

Fundamental Rights Impact Assessment (FRIA) допомагає компанії подивитися на AI-систему не тільки з боку її технічних характеристик, а й з погляду людини, на яку впливають рішення цієї системи. Чи може вона призвести до дискримінації? Чи не створює надмірного втручання у приватність? Чи має людина можливість зрозуміти рішення системи та оскаржити його? Саме такі питання лежать в основі оцінки впливу на основоположні права.

Водночас FRIA потрібна не кожному бізнесу, який використовує штучний інтелект (ШІ). Стаття 27 EU AI Act встановлює конкретні випадки, коли deployer high-risk AI system повинен провести таку оцінку. 

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

Зокрема, провести FRIA потрібно, якщо 

• організація буде впроваджувати системи ШІ високого ризику, зазначені в статті 6(2), за винятком систем ШІ високого ризику, призначених для використання в галузі, перелічених у пункті 2 Додатка III та є органом публічного права, або є приватним суб’єктом господарювання, що надає державні послуги; або
• організація буде впроваджувати системи ШІ високого ризику і вона зазначена у пунктах 5 (b) та (c) Додатка III.

До прикладу:

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

Важливе уточнення: передбачалося, що стаття 27 EU AI Act почне застосовуватися з 2 серпня 2026 року. Однак після змін, внесених у 2026 році, для high-risk систем за статтею 6(2) EU AI Act та Annex III застосування відповідних положень, включно з обов’язком за статтею 27, перенесено на 2 грудня 2027 року. 

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

2. DPIA і FRIA: чи потрібні обидві?

Зазвичай виникає цілком логічне запитання: якщо компанія вже проводить DPIA за GDPR, навіщо їй ще одна оцінка? Відповідь полягає у різному фокусі цих двох інструментів.

DPIA насамперед допомагає оцінити ризики для людей, пов’язані з обробкою їхніх персональних даних. FRIA дивиться ширше – на те, як використання ШІ може вплинути на основоположні права людини.

AI Act прямо передбачає, що DPIA та FRIA можуть бути взаємопов’язані, але це не означає, що одна автоматично замінює іншу. Причина в тому, що предмет оцінок різний. DPIA за GDPR оцінює ризики для прав і свобод осіб, пов’язані саме з обробкою персональних даних. FRIA має ширший предмет – вона оцінює вплив використання AI-системи на фундаментальні права загалом. Тому, якщо DPIA вже охоплює певні питання, їх не обов’язково повторно аналізувати у FRIA, але FRIA повинна доповнити DPIA питаннями, які виходять за межі захисту персональних даних. 

Щодо того, чи мають це бути два окремі документи, стаття 27(4) AI Act свідчить про можливість інтегрованого підходу, за яким FRIA може доповнювати вже проведену DPIA.

3. Як закрити вимоги GDPR та AI Act в одному compliance framework

Для компаній, які розробляють або використовують системи ШІ, відповідність GDPR та AI Act не варто будувати як два окремі процеси. Значно ефективніше створити єдину систему управління, у якій оцінювання ризиків, документування, контроль даних та реагування на інциденти одразу враховують вимоги обох актів. 

Перший етап: реєстр систем ШІ та операцій обробки персональних даних

Для кожного продукту або функціоналу варто зафіксувати:

• які дані використовуються;
• з якою метою;
• хто є контролером або процесором;
• хто є provider та deployer системи ШІ;
• де і ким вона використовується; а також
• до якої категорії за AI Act система ШІ належить. 

Це допоможе ще до запуску продукту визначити, чи виникає потреба у DPIA, FRIA або обох оцінках.

Другий етап: управління даними та контроль

GDPR вимагає, щоб персональні дані оброблялися законно, прозоро та для визначених цілей, а їхній обсяг був необхідним для відповідної мети. Для high-risk AI AI Act у статті 26(4) додатково покладає на deployer обов’язок, у межах його контролю над вхідними даними, забезпечувати їхню релевантність і достатню репрезентативність щодо призначення системи. Тому в єдиному фреймворку варто підготувати процедури перевірки джерел даних, перевірити правові підстави їх використання, якість, репрезентативність, строки зберігання та доступ до даних.

Також GDPR вимагає враховувати ризики автоматизованого прийняття рішень та профілювання, а AI Act для high-risk AI прямо вимагає від deployer забезпечити людський нагляд особами, які мають необхідні компетентність, підготовку та повноваження. Тому потрібно визначити хто саме контролює систему, що ця особа може змінити або скасувати, коли вона зобов’язана втрутитися та як фіксується таке втручання.

Третій етап: проведення DPIA та/або FRIA

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

Для проведення DPIA компанія може використовувати шаблон, розроблений Європейською радою із захисту даних (EDPB). Водночас станом на серпень 2026 року цей шаблон ще не є остаточним. EDPB прямо зазначає, що після завершення публічної консультації шаблон буде доопрацьований з урахуванням отриманих пропозицій.

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

Під час підготовки FRIA, компанія перевіряє застосовність статті 27 AI Act. Якщо ця стаття застосовується, deployer проводить оцінювання впливу на фундаментальні права. FRIA має містити щонайменше: 

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

Після проведення FRIA deployer має повідомити орган ринкового нагляду (market surveillance authority; визначає кожна держава ЄС за статтею 70 AI Act) про її результати шляхом подання передбаченого шаблону, якщо не застосовується відповідне звільнення.

Четвертий етап: вимоги щодо прозорості

Користувач повинен розуміти, які персональні дані компанія використовує та для яких цілей відповідно до GDPR, а в передбачених AI Act випадках особу також потрібно повідомляти про те, що вона є об’єктом використання high-risk AI. Для компаній це означає, що політика приватності, повідомлення користувачу, інтерфейс продукту та документація щодо ШІ мають бути узгодженими між собою.

П’ятий етап: перегляд та оновлення

Compliance framework має працювати не лише до запуску продукту. Для GDPR DPIA є інструментом, який необхідно переглядати, коли змінюється характер обробки персональних даних або виникають нові ризики. FRIA також має оновлюватися, якщо змінюються обставини, що мають значення для оцінки впливу.

Висновки

Отже, якщо ваша компанія використовує або планує використовувати high-risk AI, саме час перевірити, чи потрібна вам FRIA, які ризики необхідно оцінити та як вона має співвідноситися з уже проведеною DPIA. 

Якщо DPIA ще немає – необхідно окремо оцінити, чи виникає обов’язок її проведення за GDPR. Адже ефективний AI compliance – це комплексний підхід, який одночасно враховує вимоги EU AI Act та GDPR і допомагає бути готовим до регуляторних вимог.