EU compliance для технологічних продуктів у 2026 році: AI Act, GDPR, EAA, PLD

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

EU regulations compliance для технологічних продуктів має будуватися комплексно. Продукт має одну фактичну реальність, навіть якщо регуляцій багато.

Чому у 2026 році одного GDPR-аудиту вже недостатньо.

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

У 2026 році така конструкція зовсім не ок. Один екран може одночасно бути питанням прозорості за GDPR, повідомленням про взаємодію зі штучним інтелектом за AI Act, об’єктом перевірки доступності та частиною інструкції, яка впливає на безпечність продукту.

Овва, оце так-так.

Одне оновлення може змінити поведінку моделі, відкрити вразливість, зламати навігацію клавіатурою і створити новий сценарій шкоди.

Тому на рівні ЄС для технологічних продуктів критичними стають п’ять актів:

• AI Act – правила для систем і моделей штучного інтелекту;
• GDPR – правила роботи з персональними даними;
• Cyber Resilience Act, або CRA – кібербезпека цифрових продуктів протягом усього строку їхнього життя;
• European Accessibility Act, або EAA – доступність визначених продуктів і послуг для людей з інвалідністю;
• Product Liability Directive, або PLD – відповідальність за шкоду, заподіяну дефектним продуктом, включно з програмами та системами штучного інтелекту.

Кожен акт має свій скоуп. При цьому, в рамках аудиту відповіді про фактичний стан справ дуже часто лежать в одних і тих самих системах, журналах, рішеннях команди та поведінці продукту.

П’ять EU актів: про що мова та на що дивимось?

Акт	Про що він	Що означає нормальний комплаєнс
AI Act	Ризики, ролі та правила для систем штучного інтелекту.	Зрозуміти призначення і клас ризику, керувати даними та ризиками, забезпечити людський контроль, журнали, документацію і нагляд після запуску.
GDPR	Законність і контроль обробки персональних даних.	Мати правові підстави для обробки персональних даних та забезпечити відповідні технічні та організаційні заходи, зокрема, і для реалізації прав суб’єктів даних
CRA	Кібербезпека програм і пристроїв із цифровими елементами.	Будувати безпеку в продукт, знати його компоненти, керувати вразливостями, випускати безпечні оновлення та підтримувати продукт протягом заявленого строку.
EAA	Доступність визначених продуктів і послуг.	Переконатися, що критичний шлях можна пройти клавіатурою, програмою екранного озвучення та іншими допоміжними технологіями, а інформація і підтримка є зрозумілими.
PLD	Відповідальність за шкоду від дефектного продукту.	Не просто написати попередження, а довести, що ризики оцінювалися, рішення були обґрунтовані, продукт тестувався, версії контролювалися, а відомі проблеми не ігнорувалися.

AI Act працює за ризик-орієнтованою логікою: різні ролі та сценарії використання тягнуть різний обсяг вимог.

GDPR сконцентрований на потоках персональних даних.
СRA – це про безпеку продукту від задуму до завершення підтримки.
EAA – перевіряє, чи може людина реально скористатися продуктом.
PLD – на те, чи був продукт достатньо безпечним і чи є в компанії докази на випадок шкоди.

Важливо: EAA не охоплює будь-який цифровий сервіс автоматично, а PLD не є класичним чеклістом комплаєнсу. Але для продукту, який виходить на ринок ЄС, обидва акти мають бути частиною загальної картини застосовності та ризиків.

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

П’ять окремих аудитів – це дорога екселька з дублями.

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

У результаті з’являються п’ять папок, у яких той самий продукт описаний трохи по-різному.

У GDPR-пакеті функція називається аналітикою. В AI-документації – рекомендаційною системою. У CRA-файлі її немає в переліку компонентів. В інструкції для користувача вона взагалі виглядає як автоматичне рішення. Чи стакатимуться всі ці дані? Ймовірно, але зовсім не точно.

Єдиний збір фактів дозволяє один раз дістати великий масив інформації і використовувати його для різних цілей:

Спільний блок інформації	Де він використовується
Паспорт продукту: призначення, версія, ринки, користувачі, строк підтримки	AI Act для визначення ролі й призначення; CRA для меж продукту; EAA для сфери застосування; PLD для очікуваної безпечності; GDPR для контексту обробки персональних даних.
Архітектура і перелік компонентів	CRA для поверхні атаки і залежностей; AI Act для меж системи; GDPR для систем з даними; PLD для причинно-наслідкового зв’язку та дефекту.
Карта руху даних	GDPR для цілей, передач і строків; AI Act для вхідних даних та журналів та реєстрів; CRA для критичних активів; PLD для реконструкції події.
Критичні шляхи користувача	EAA для доступності; GDPR для прозорості та згоди; AI Act для повідомлень і людського контролю; PLD для інструкцій та передбачуваного використання.
Карта підрядників і ролей	GDPR для процесорів і ко-контролерів; AI Act для ланцюга постачання ШІ; CRA для компонентів і постачальників; PLD для відповідального економічного оператора.
Журнали, реєстри, заявки підтримки та інциденти	AI Act для простежуваності; GDPR для підзвітності й витоків; CRA для вразливостей та інцидентів; PLD для доказів і повторюваних проблем.
Історія змін і релізів	AI Act для істотних змін; GDPR для нових цілей і DPIA; CRA для оновлень; EAA для регресії доступності; PLD для контролю версій.

Одна й та сама інформація не стає «даними тільки для GDPR» або «даними тільки для CRA». Вона описує реальний продукт. Регуляції просто ставлять до цієї реальності різні питання.

Комплаєнс за поведінкою продукту.

Ключовим підходом стає compliance by product behaviour – комплаєнс за поведінкою продукту. Ідея проста: перевіряється не лише те, що написано в політиці, а те, що продукт реально робить у конкретний момент.

Документація може обіцяти мінімізацію даних, але форма все одно збирає десять необов’язкових полів. Політика може описувати видалення, але кнопка «видалити профіль» залишає дані в аналітиці й резервних копіях.

Тому в комплексному аудиті є щонайменше чотири рівні правди:

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

Останній рівень часто є вирішальним. Відмова від згоди або налаштування має поширитися між системами. Оновлення має встановитися безпечно. Рішення ШІ має бути переглянуте там, де потрібен людський контроль. Форма має пройтися клавіатурою. А попередження має з’явитися до ризикової дії, а не бути захованим десь глибок в термзах.

Практичне правило
Якщо документ говорить одне, система робить друге, люди звикли до третього, а користувач бачить четверте – комплаєнс не працює. Саме поведінка продукту показує реальний стан.

Єдиний шлях аудиту: одне вікно збору даних.

Комплексний аудит не означає, що всі акти змішуються в одну велику таблицю. Він означає, що факти збираються один раз, зберігаються в єдиному доказовому файлі і далі оцінюються за окремими вимогами.

Стадія	Головне питання	Результат
0. Паспорт продукту	Що це за продукт, хто його створює, продає, використовує і змінює?	Спільна межа перевірки, версії, ролі, ринки та критичні функції.
1. Єдиний збір фактів	Як продукт реально працює: дані, моделі, код, інтерфейс, оновлення, підрядники та інциденти?	Карта архітектури, руху даних, користувацьких шляхів, компонентів, ролей і доказів.
2. Оцінка за п’ятьма актами	Де фактична поведінка не збігається з AI Act, GDPR, CRA, EAA або PLD?	Єдиний реєстр прогалин із позначенням усіх регуляцій, яких вони стосуються.
3. Комплексний план змін	Яка одна зміна може закрити кілька ризиків і хто за неї відповідає?	Пріоритетний план документальних, технічних, продуктових і поведінкових змін.

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

Завдяки цьому компанія одразу отримує комплексну картину і може системно змінювати процеси, а не латати документи по одному.

Документальна реальність EU compliance.

Кожен акт вимагає свій пакет документів. Не потрібно намагатися зробити одну «універсальну політику на всі випадки». Документи не мають сперечатися між собою.

Регуляторний блок	Типові документи та докази, звісно ж не вичерпні
AI Act	Реєстр систем ШІ, визначення ролі та ризику, управління ризиками, опис даних, технічна документація, правила людського контролю, журнали і нагляд після запуску.
GDPR	RoPA, карта правових підстав, DPIA або LIA, повідомлення про приватність, DPA, строки зберігання, процедури запитів людей та інцидентів.
CRA	Оцінка кіберризиків, перелік компонентів і залежностей, правила безпечної розробки, робота з вразливостями, докази оновлень, технічна документація і відповідність продукту.
EAA	Карта критичних шляхів, вимоги доступності, результати автоматичного і ручного тестування, опис відомих обмежень, доступні інструкції та підтримка.
PLD	Файл ризиків продукту, проєктні рішення, результати тестів, інструкції та попередження, історія версій, відомі проблеми, інциденти і рішення після запуску.

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

Якщо DPIA каже, що рішення ШІ має лише рекомендаційний характер, а інструкція оператора описує автоматичне блокування – маємо суперечність.

Що має залишитися після комплексного аудиту.

Головний результат – не п’ять PDF із різними кольорами ризику. Після аудиту компанія має отримати одну керовану модель продукту, до якої під’єднані окремі регуляторні висновки.

Мінімальний набір виглядає так:

• спільний паспорт продукту, версій, ринків, ролей і строків підтримки;
• матриця застосовності AI Act, GDPR, CRA, EAA та PLD;
• карта архітектури, компонентів, даних, користувацьких шляхів і підрядників;
• єдине сховище доказів: журнали, тести, знімки екрана, рішення, заявки та історія релізів;
• реєстр прогалин, у якому одна проблема може мати кілька регуляторних позначок;
• спільний план змін із відповідальними, строками та доказом виконання;
• ритм перегляду: нова функція, нова модель, новий підрядник, значний інцидент або суттєва зміна запускають повторну оцінку.

Чому таку історію краще не збирати по шматках.

Комплексний аудит лежить на перетині права, архітектури, кібербезпеки, дизайну, роботи з даними, доступності та управління продуктом. Тут недостатньо просто знати статті регламенту або вміти запустити технічний сканер.

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

Legal IT Group працює саме на цьому стику. Команда поєднує юридичну експертизу з розумінням технологічних продуктів, технічних доказів і поведінки команд. Ц

Висновок: один продукт – одна система комплаєнсу.

AI Act, GDPR, CRA, European Accessibility Act і Product Liability Directive не можна повністю об’єднати. У них різні сфери застосування, різні обов’язки і різні документи. Але продукт, який вони регулюють, один.

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