AI Act ЄС: що зміниться для постачальників моделей загального призначення з 2 серпня 2026 року

2 серпня 2026 року Європейська комісія отримує повноваження повноцінно контролювати виконання обов’язків для постачальників моделей штучного інтелекту загального призначення. Самі правила для нових GPAI-моделей застосовуються ще з 2 серпня 2025 року, але тепер невідповідність може перейти з етапу консультацій у площину нагляду та санкцій. Для розробників моделей це означає потребу підтримувати документацію, політику дотримання авторського права та відомості про навчальні дані як постійні процеси, а не разову підготовку перед релізом.

GPAI — це модель, а не будь-який продукт із функцією ШІ

AI Act розрізняє модель загального призначення та систему, у яку її інтегрували. GPAI-модель здатна компетентно виконувати широкий спектр різних завдань і може бути вбудована в численні продукти. Чат для підтримки, редактор документів або пошуковий сервіс, що використовує таку модель через API, зазвичай є downstream-системою, а не автоматично її постачальником.

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

Календар залежить від дати виходу моделі

Обов’язки для постачальників GPAI почали застосовуватися 2 серпня 2025 року. Для моделей, уперше введених на ринок ЄС після цієї дати, вимоги діють від моменту запуску. Єврокомісія вказує, що з 2 серпня 2026 року її контрольні повноваження щодо цих правил застосовуються повною мірою. Моделі, які вже були на ринку до 2 серпня 2025 року, мають окремий перехідний строк до 2 серпня 2027 року.

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

Технічна документація має пояснювати можливості й межі

Постачальник повинен створювати та оновлювати технічну документацію про модель. Вона потрібна не лише AI Office: частину відомостей мають отримувати постачальники систем, які інтегрують модель. Downstream-команда повинна розуміти очікувані можливості, відомі обмеження, умови використання, типи вхідних і вихідних даних та заходи, необхідні для безпечного розгортання.

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

Потрібна публічна інформація про навчальний контент

AI Act вимагає публікувати достатньо докладне резюме контенту, використаного для навчання GPAI-моделі. Це не тотожно розкриттю кожного окремого запису чи повного датасету. Єврокомісія підготувала шаблон, що структурує категорії джерел, великі набори даних та інші типи матеріалів. Завдання резюме — дати правовласникам і суспільству змістовне уявлення про походження навчального матеріалу.

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

Авторське право потребує операційної політики

Постачальники GPAI повинні мати політику дотримання авторського права ЄС і суміжних прав. Вона має охоплювати механізми виявлення та поваги до застережень правовласників, зокрема машиночитних відмов від використання творів для інтелектуального аналізу текстів і даних. Самого речення «ми поважаємо авторські права» у правилах сервісу недостатньо.

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

Моделі із системним ризиком мають додаткові обов’язки

Для найпотужніших GPAI-моделей, здатних створювати системний ризик, передбачений посилений режим. Він включає оцінювання моделі, аналіз і пом’якшення ризиків, повідомлення про серйозні інциденти та належний рівень кібербезпеки. Закон використовує обчислювальний поріг як один зі способів презумпції системного ризику, але AI Office також може враховувати інші критерії.

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

Кодекс практики є добровільним, але корисним

General-Purpose AI Code of Practice створений як добровільний інструмент, що допомагає продемонструвати виконання вимог. Він не замінює закон і не перетворює підпис на автоматичний імунітет. Водночас узгоджені з кодексом процедури можуть дати постачальнику зрозуміліший шлях до підтвердження прозорості, авторського права, безпеки та управління системними ризиками.

Організації, яка не приєднується до кодексу, однаково потрібно пояснити власний спосіб відповідності. Розумна перевірка полягає не у виборі між «кодексом» і «нічого», а між стандартизованим доказовим маршрутом та самостійно обґрунтованою системою контролів. В обох випадках документи повинні відповідати реальному процесу, а не описувати бажаний стан.

Open source не означає автоматичного звільнення

AI Act передбачає певні винятки для моделей, випущених за вільною та відкритою ліцензією, якщо доступні визначені технічні відомості. Однак виняток не охоплює всі обов’язки й не застосовується до GPAI-моделей із системним ризиком. Саме слово «open» у назві репозиторію не доводить відповідності критеріям.

Команді потрібно перевірити, що реально оприлюднено: ваги, інформацію про архітектуру, умови використання та інші передбачені елементи. У матеріалі TechPulse про Open Source AI Definition 1.0 пояснено, чому доступу до ваг недостатньо для повної відтворюваності. А стаття про дозволи для агентів ШІ допомагає відокремити обов’язки постачальника моделі від ризиків конкретної інтеграції.

Downstream-команди також мають поставити запитання

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

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

Внутрішній аудит має залишати докази

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

Практичний план підготовки

1. Визначте роль компанії для кожної моделі та версії: постачальник, модифікатор чи інтегратор.
2. Зафіксуйте дату введення моделі на ринок ЄС і критерії істотної зміни.
3. Побудуйте реєстр навчальних джерел, ліцензій, фільтрів і застережень правовласників.
4. Зв’яжіть технічну документацію з версіями ваг, оцінюваннями та журналом релізів.
5. Перевірте, чи може модель вважатися такою, що створює системний ризик.
6. Оберіть шлях доказування відповідності: кодекс практики або власні еквівалентні процедури.
7. Підготуйте процес відповіді на запити AI Office і повідомлення про серйозні інциденти.

Головний результат підготовки

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

Це редакційне пояснення, а не індивідуальна юридична консультація. Першоджерела: рекомендації Єврокомісії для постачальників GPAI, офіційні запитання й відповіді, General-Purpose AI Code of Practice та текст AI Act.