Регулювання штучного інтелекту (AI): правові ризики

Чому штучний інтелект потребує регулювання

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

Практично це породжує чотири групи питань, кожна з яких має власний режим:

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

Для українського бізнесу є додатковий шар. Станом на жовтень 2026 року в Україні немає окремого закону про штучний інтелект — але це не означає відсутності регулювання. Діють загальні норми: Цивільний кодекс, Закон «Про авторське право і суміжні права» № 2811-IX, Закон «Про захист персональних даних», законодавство про захист прав споживачів і про рекламу. А для компаній, які працюють на ринку ЄС, уже діє AI Act, і діє з реальним правозастосуванням.

Тому питання «чи регулюється AI в Україні» поставлене неправильно. Правильне питання — які норми застосовуються до вашої конкретної системи і на яких ринках ви її пропонуєте.

AI Act: чотири рівні ризику

Регламент (ЄС) 2024/1689 (AI Act) набрав чинності 1 серпня 2024 року і будується на ризик-орієнтованому підході: обсяг вимог залежить не від технології, а від того, де і як система застосовується. Комісія виділяє чотири категорії.

Окремий режим — для моделей загального призначення (GPAI): глава V Регламенту (статті 51–55) встановлює обов’язки щодо документації, політики дотримання авторського права, опису даних для навчання, а для моделей із системним ризиком — додаткові вимоги щодо оцінки та кіберзахисту.

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

Санкції за статтею 99 Регламенту серйозні: до 35 мільйонів євро або 7 відсотків світового річного обороту за порушення заборон статті 5; до 15 мільйонів євро або 3 відсотки за порушення інших обов’язків; до 7,5 мільйона євро або 1 відсоток за надання неправдивої інформації. Для малих і середніх підприємств застосовується менша з двох сум.

Digital Omnibus: що змінилося у 2026

Це найважливіше оновлення, і через нього більшість матеріалів 2024–2025 років подає строки неправильно.

Регламент (ЄС) 2026/1744 від 8 липня 2026 року («Digital Omnibus on AI») — перша зміна до AI Act. Він опублікований в Офіційному віснику 24 липня і набрав чинності 27 липня 2026 року. Консолідований текст AI Act на EUR-Lex датований саме 27 липня 2026 року, і працювати потрібно з ним.

Оновлений графік застосування виглядає так:

Що не відкладено і діє вже зараз, попри поширену думку про «перенесення AI Act»:

• загальна дата застосування 2 серпня 2026 року не змінювалася; органи ЄС і національні регулятори розпочали правозастосування саме з неї;
• стаття 50 про прозорість — розкриття чат-бота, маркування дипфейків і машинозчитуване маркування синтетичного контенту — діє;
• стаття 49 про реєстрацію не відкладена;
• заборони статті 5 діють із лютого 2025 року;
• глава V про моделі загального призначення по суті не змінена.

Інші зміни Omnibus, які варто знати: вимогу «забезпечити достатній рівень AI-грамотності» замінено на м’якшу — «вживати заходів для підтримки розвитку AI-грамотності»; для малих підприємств і компаній середньої капіталізації запроваджено пропорційні та обмежені санкції й спрощену документацію; знято «подвійний тягар» для AI в машинному обладнанні; оцінку впливу на основні права (FRIA) дозволено будувати на основі або з відсиланням до оцінки впливу на захист даних за GDPR; Офіс з AI отримав виключну компетенцію щодо систем на базі моделей загального призначення та систем, регульованих Актом про цифрові послуги.

І важливе застереження, бо тут найбільше плутанини: дані-складник пакета Digital Omnibus (COM(2025) 837), який пропонує зміни до GDPR, ePrivacy, Data Act, NIS2 і DORA, залишається пропозицією. Законом став лише AI-складник. Ніщо з анонсованих спрощень GDPR юридично не діє.

Чи поширюється AI Act на українську компанію

Так, якщо є зв’язок із ринком ЄС. Стаття 2 Регламенту побудована екстериторіально, подібно до GDPR, і охоплює щонайменше три ситуації:

• ви випускаєте на ринок ЄС або вводите в експлуатацію AI-систему чи модель загального призначення — незалежно від місця реєстрації компанії;
• ви є тим, хто впроваджує систему (deployer) і маєте осідок у ЄС;
• ви за межами ЄС, але результат роботи системи використовується в ЄС.

Друге питання, не менш важливе за перше, — яка у вас роль. Регламент розрізняє насамперед постачальника (provider), який розробляє систему та випускає її під своїм іменем, і того, хто впроваджує систему (deployer), використовуючи її у своїй діяльності. Обсяг обов’язків різний, і типова помилка українського аутсорсу — вважати себе просто виконавцем, тоді як за договором компанія фактично виступає постачальником.

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

Що робити практично:

1. скласти перелік усіх AI-систем, які компанія розробляє або використовує, включно з вбудованими в чужі продукти;
2. для кожної визначити призначення і контекст використання, а не технологію;
3. класифікувати за рівнями ризику та перевірити, чи не підпадає вона під додаток III;
4. зафіксувати роль (постачальник, впроваджувач, імпортер, дистриб’ютор) у договорах;
5. для систем із прозорістю — забезпечити розкриття і маркування вже зараз, бо стаття 50 діє;
6. для потенційно високоризикових — використати відстрочку до грудня 2027 року як робочий час, а не як підставу відкласти питання.

А що в Україні. У Верховній Раді працює робоча група з правового регулювання ШІ, і наступним кроком визначено розробку профільного євроінтеграційного закону протягом 2026 року. Проєкт створюється з урахуванням AI Act та адаптується до українських безпекових і економічних потреб під час війни.

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

Інституційно політику формуватиме Кабінет Міністрів (зокрема правила регуляторних пісочниць, вимоги до органів оцінки відповідності, порядок перевірки універсальних моделей і післяринкового моніторингу), Мінцифри відповідатиме за реалізацію політики, стандарти й AI-грамотність, а Цифровий регулятор — за підзаконні акти, ринковий нагляд за універсальними моделями та погодження планів пісочниць. Розділ про високоризикові системи ще опрацьовується, як і межі дії закону в секторі безпеки й оборони, адже AI Act військову сферу не охоплює.

AI та персональні дані

AI Act не замінює GDPR — вони застосовуються паралельно, і більшість реальних претензій до AI-продуктів досі йде саме через захист даних.

Чотири перетини, які мають значення на практиці.

Правова підстава обробки. Для навчання моделі на персональних даних потрібна підстава за статтею 6 GDPR, і «ми вже мали ці дані для іншої мети» такою підставою не є: зміна мети обробки вимагає окремого обґрунтування або згоди. Для чутливих категорій даних діє стаття 9 GDPR із власним, значно вужчим переліком підстав.

Автоматизоване ухвалення рішень. Стаття 22 GDPR дає особі право не підлягати рішенню, заснованому виключно на автоматизованій обробці, яке має щодо неї юридичні наслідки або істотно на неї впливає. Це безпосередньо стосується скорингу, автоматичного відбору кандидатів, автоматичної відмови в послузі. Практичний вихід — забезпечити реальну, а не формальну участь людини: оператор має мати повноваження й інформацію, щоб змінити рішення, а не просто натискати «підтвердити».

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

Оцінка впливу. Для операцій із високим ризиком стаття 35 GDPR вимагає DPIA. Digital Omnibus тут дав полегшення: оцінку впливу на основні права за AI Act дозволено будувати на основі або з відсиланням до відповідних розділів DPIA, тому два документи більше не потрібно писати з нуля окремо.

Окремо — про передачу даних у моделі третіх осіб. Використання публічного AI-сервісу для обробки даних клієнтів означає передачу даних оператору, і це вимагає належної підстави, угоди про обробку даних і перевірки умов сервісу щодо використання введених даних для навчання. Загальна механіка реагування на інциденти з даними розібрана в матеріалі про кібербезпеку та витік персональних даних.

Права на AI-контент: право sui generis

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

Закон «Про авторське право і суміжні права» № 2811-IX, чинний з 1 січня 2023 року, запровадив у статті 33 право особливого роду (sui generis) на неоригінальні об’єкти, згенеровані комп’ютерною програмою. Україна стала однією з перших юрисдикцій світу з окремим режимом для об’єктів, створених без безпосередньої участі людини.

Фактично існують три категорії результатів:

Ключові правила статті 33:

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

Найважливіший практичний висновок стосується працівників і підрядників. Норма про службові твори не поширюється на об’єкти sui generis автоматично. Якщо розробник використовує AI-асистента, і частина коду згенерована моделлю без творчого внеску людини в конкретні рядки, ця частина не є твором — вона є об’єктом sui generis за статтею 33, і її належність роботодавцю сама собою не виникає.

Закрити цей розрив можна лише прямо: передбачити в посадовій інструкції та трудовому договорі (а для підрядників — у договорі), що обов’язки включають використання ліцензованих роботодавцем AI-інструментів і що всі результати такого використання, зокрема об’єкти sui generis за статтею 33 Закону № 2811-IX, належать роботодавцю (замовнику). Без такого формулювання права на значну частину створеного можуть виявитися не там, де компанія очікує, — і це найбільш недооцінений ризик у передачі коду при M&A та в спорах із колишніми працівниками. Ширший контекст — у матеріалі про захист коду та IP в IT.

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

Відповідальність за рішення AI

Універсального режиму відповідальності за шкоду від AI поки немає ні в Україні, ні в завершеному вигляді в ЄС. Тому відповідальність сьогодні будується з трьох наявних джерел.

Перше: загальне цивільне право. AI-система не є суб’єктом права, тому відповідає людина або компанія. За загальними правилами відповідає той, хто завдав шкоди своєю діяльністю, а якщо система є частиною товару чи послуги — застосовуються правила про якість і про відповідальність за шкоду, завдану недоліками продукції. «Так вирішив алгоритм» не є обставиною, що звільняє від відповідальності.

Друге: галузеве регулювання. У медицині, фінансах, транспорті, трудових відносинах діють власні правила, які не зникають через використання AI. Автоматизована відмова в кредиті оцінюється за правилами фінансових послуг і за статтею 22 GDPR, а не за «загальним правом AI».

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

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

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

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

Що робити українському бізнесу зараз

План дій, який має сенс незалежно від того, коли саме ухвалять український закон.

1. Скласти реєстр AI-систем. Що розробляєте, що використовуєте, що вбудовано в придбані продукти. Більшість компаній виявляє, що AI-інструментів у них уже десятки, і частина з них обробляє персональні дані.
2. Класифікувати за ризиком за логікою AI Act, навіть якщо ви ще не на ринку ЄС. Класифікація визначить, що саме робити далі, і той самий підхід закладено в український законопроєкт.
3. Закрити прозорість уже зараз. Стаття 50 AI Act діє: користувач має знати, що спілкується з AI, а синтетичний контент має бути маркований машинозчитуваним способом. Для систем, випущених на ринок до 2 серпня 2026 року, перехідний строк спливає 2 грудня 2026 року.
4. Привести в порядок дані. Правова підстава для навчання, угоди про обробку даних із постачальниками сервісів, DPIA для високоризикових операцій, реальний людський контроль для автоматизованих рішень.
5. Виправити документи щодо прав на результат. Трудові договори, посадові інструкції та договори з підрядниками мають прямо охоплювати об’єкти sui generis за статтею 33 Закону № 2811-IX.
6. Перевірити умови AI-сервісів, які використовує команда: права на вихідні дані, використання введених даних для навчання, гарантії та межі відповідальності постачальника.
7. Розподілити відповідальність у договорах із клієнтами й постачальниками, з гарантіями, межами та indemnity.
8. Запровадити журнал і документацію — версії моделей, набори даних, логи рішень, результати тестування. Це єдиний спосіб щось довести згодом.
9. Не покладатися на відстрочку як на вирішення. Правила для систем високого ризику за додатком III застосовуються з 2 грудня 2027 року, а для вбудованих у регульовані продукти — з 2 серпня 2028 року. Це робочий час для підготовки, а не підстава відкласти питання.
10. Слідкувати за українським законопроєктом, зокрема за розділом про високоризикові системи та за межами дії закону в секторі безпеки й оборони.

Окремо для продуктових компаній, що продають у ЄС: класифікація системи і роль (постачальник чи впроваджувач) впливають не лише на комплаєнс, а й на оцінку компанії в угодах. Покупці й інвестори вже перевіряють відповідність AI Act у рамках due diligence, і невизначений статус високоризикової системи знижує ціну так само, як незакриті права на код.

ІТ-юристи практики IT-права LEGIUS класифікують AI-системи за AI Act, готують документи щодо прав на згенерований контент і розподіляють відповідальність у договорах з AI-постачальниками. Щоб оцінити, які вимоги вже застосовуються до вашого продукту, запишіться на консультацію.