Оновлення регулювання ЄС щодо IT та AI: що це означає для бiзнесу

Revised Product Liability Directive: що i коли

Стара Директива 85/374/ЄЕС (40 рокiв) не писалася пiд software. Нова – Directive (EU) 2024/2853 – усуває це прогалину напряму.

Що змiнюється – через призму бiзнесу

2.1. Software та AI = «продукт»

Ключовий зсув: PLD 2024 прямо включає software до визначення «продукту» – вбудований, самостiйний чи як послуга (SaaS/хмара), незалежно вiд способу постачання. Також охопленi iнтегрованi цифровi послуги (наприклад, монiторинг здоров’я, що працює з сенсором), AI-системи та цифровi файли виробництва.

Що це означає практично: режим суворої (no-fault) вiдповiдальностi, який ранiше стосувався фiзичних продуктiв, тепер поширюється на будь-який IT або AI-продукт, що ви виводите на ринок ЄС. Не потрiбно доводити умисел або недбалiсть виробника – достатньо довести дефект i шкоду.

2.2. Хто вiдповiдає, якщо виробник за межами ЄС

Для продуктiв, вироблених поза ЄС, вiдповiдальнiсть розподiляється каскадом: спершу iмпортер, потiм уповноважений представник, а якщо їх немає – fulfilment-провайдер. Окремо – виробник компонента та, за певних умов, оператори онлайн-платформ.

Практичний наслiдок для українських IT-компанiй, що постачають продукти до ЄС: якщо у вас немає офiцiйного iмпортера або уповноваженого представника в ЄС – fulfilment-провайдер або навiть маркетплейс можуть опинитися вiдповiдачем. А потiм звернутися до вас з регресним позовом.

2.3. Що вважається дефектом – включаючи кiбербезпеку

Тест об’єктивний: «рiвень безпеки, на який особа має право розраховувати», з урахуванням презентацiї продукту, технiчних характеристик, розумно передбачуваного використання i вимог безпеки.

Два нових специфiчних джерела дефекту, критичних для IT/AI:

• Кiбервразливостi – якщо продукт має вiдому та невиправлену вразливiсть, це може становити дефект.
• Ненаданi оновлення – якщо виробник мав надати оновлення безпеки, але не надав – це теж дефект. Полiтика оновлень стає юридично значущим документом.
• Автономна та адаптивна поведiнка AI – PLD покриває шкоду вiд пост-продажних змiн через машинне навчання чи OTA-оновлення. Якщо ваша модель навчилась чогось шкiдливого пiсля релiзу – вiдповiдальнiсть нiкуди не зникає.

2.4. Презумпцiї – головний зсув для позивачiв

Суворий (no-fault) режим зберiгається, але доводити шкоду стало легше. Три автоматичнi презумпцiї:

• Дефектнiсть презюмується, якщо вiдповiдач не розкриває «необхiднi й пропорцiйнi» докази; якщо продукт не вiдповiдає обов’язковим вимогам безпеки ЄС; або якщо стався «очевидний збiй» за нормального використання.
• Причинний зв’язок презюмується, якщо шкода «типово узгоджується» з дефектом.
• У технiчно складних справах (AI, медичнi пристрої) суд презюмує дефектнiсть та/або причиннiсть, якщо позивач показав це як «ймовiрне», але доведення «надмiрно складне» через технiчну чи наукову складнiсть продукту.

Останнiй пункт особливо важливий для AI: складнiсть моделi бiльше не захищає вiд позову – вона може працювати проти вас.

2.5. Розкриття доказiв

Новий механiзм: позивач з правдоподiбним позовом може вимагати судового розкриття доказiв у вiдповiдача. Для континентальної Европи це фактично елемент discovery – iнституту, якого традицiйно там не iснувало.

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

2.6. Яка шкода компенсується

• Смерть або шкода здоров’ю фізичної особи — включно з медично підтвердженими тілесними ушкодженнями. 
• Знищення або пошкодження майна (крiм самого дефектного продукту й майна виключно професiйного використання).
• Медично пiдтверджена психологiчна шкода.
• Втрата або пошкодження даних – окрiм даних виключно професiйного використання.

Скасовано поровень 500 євро для майнової шкоди й фiнансовi стелi для тiлесних ушкоджень. Це означає: меншi позови стали економiчно виправданими, у тому числi як представницькi (колективнi).

2.7. Строки давностi

• 3 роки з моменту, коли позивач дiзнався (або мав дiзнатися) про шкоду, дефект i вiдповiдача.
• 10 рокiв з моменту розмiщення продукту на ринку – загальний строк.
• 25 рокiв – для тiлесних ушкоджень з латентною шкодою здоров’ю (замiнено попереднiй 10-рiчний строк).

AI Act: що вже треба робити (коротке нагадування)

Повний розбiр AI Act – окрема тема. Тут – тiльки те, що актуально прямо зараз i у найближчi мiсяцi, з акцентом на transparency-вимоги, якi нiхто не переносив.

Щодо санкцiй за порушення Art. 50 (transparency): до €15 млн або 3% свiтового рiчного обороту – залежно вiд того, яка сума бiльша.

Чому PLD та AI Act краще закривати разом

Мiж двома актами є пряма юридична залежнiсть, яку легко пропустити.

Невiдповiднiсть вимогам AI Act (зокрема, щодо transparency, документацiї, людського нагляду) та Cyber Resilience Act дає презумпцiю дефектностi за PLD. Iншими словами: якщо ваш AI-продукт порушує AI Act – це автоматично посилює позицiю позивача в майбутньому product-liability позовi.

Ланцюжок виглядає так:

Тому compliance пiд AI Act i CRA – не просто регуляторний обов’язок. Це практичний захист вiд product-liability позовiв за PLD.

Чек-лiст: першi кроки

Нижче – мiнiмальний набiр дiй, якi зменшують ризик i за PLD, i за AI Act. Частина з них корисна вже зараз, незалежно вiд дедлайнiв.

A. Iнвентаризацiя

• ☐  Скласти реєстр усiх software- та AI-компонентiв у продуктi – власних i стороннiх.
• ☐  Зафiксувати, хто постачальник кожного AI-компонента i якi обов’язки за ланцюгом постачання.
• ☐  Визначити, якi системи мають deployers на ринку ЄС (вони пiдпадають пiд AI Act незалежно вiд мiсця реєстрацiї компанiї).

B. Документацiя

• ☐  Привести до ладу технiчну документацiю: специфiкацiї, оцiнку ризикiв, тести безпеки.
• ☐  Завести журнал оновлень та iнцидентiв – включно з вiдомими вразливостями i датами виправлень (потрiбно i пiд розкриття доказiв за PLD, i пiд AI Act).
• ☐  Для high-risk AI систем – запустити self-declaration / реєстр AI-систем з описом функцiї, ризику i вiдповiдального.

C. Transparency (дедлайн: 2 серпня 2026)

• ☐  Перевiрити всi чат-боти та AI-асистенти, що взаємодiють з користувачами в ЄС: чи є повiдомлення про AI-взаємодiю?
• ☐  Перевiрити маркування систем розпiзнавання емоцiй та бiометричної категоризацiї.
• ☐  Для генеративного AI-контенту (зображення, аудiо, вiдео) – перевiрити, яка система запускалась до 02.08.2026 (дедлайн 02.12.2026) i яка пiсля (дедлайн 02.08.2026).

D. Договори з постачальниками

• ☐  Переглянути договори з постачальниками AI-компонентiв – чи чiтко розподiлена вiдповiдальнiсть за дефекти?
• ☐  Переконатися, що уповноважений представник або iмпортер у ЄС визначений (якщо продукт виводиться на ринок ЄС без прямої присутностi виробника).
• ☐  Перевiрити, чи договiр мiстить зобов’язання постачальника щодо патчiв безпеки – вiдсутнiсть оновлення тепер може бути дефектом за PLD.

E. Людський нагляд та мiнiмiзацiя даних

• ☐  Для кожної AI-системи визначити механiзм human oversight: хто може скасувати або зупинити рiшення AI?
• ☐  Перевiрити, чи AI-системи обробляють лише тi данi, якi справдi потрiбнi (мiнiмiзацiя – вимога i GDPR, i AI Act, i зменшує ризик за PLD).

Висновок

PLD змiщує питання з «чи використовуєте ви AI» на «чи зможете ви довести, що ваш продукт не дефектний, якщо справа дiйде до суду». AI Act додає: «i чи виконали ви transparency-вимоги до 2 серпня 2026».

Документацiя AI/software-продукту з 9 грудня 2026 стає судовим доказом – а не просто compliance-артефактом. Хто має її в порядку – захищений. Хто нi – може опинитися в ситуацiї, де суд сам презюмує дефект.

Дедлайни конкретнi, частину навiть зсунули – але transparency-зобов’язання 2 серпня нiхто не переносив. Тому першi кроки доступнi i корисні вже зараз, не чекаючи «поки все владнається».