Постачальник чи суб'єкт впровадження?

В Акті про ШІ є питання, яке визначає більшість ваших обов'язків, і це не "чи моя система високого ризику?"

Це "хто я?"

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

Чотири ролі

Усе тримається на формулюванні "під власною назвою або торговельною маркою". Не на тому, хто написав код. Не на тому, хто навчав модель. На тому, чия назва стоїть на продукті, коли він виходить на ринок.

Помилка, яку засновники роблять найчастіше

"Ми це побудували, отже ми постачальник."

Іноді правда. Часто ні, і ця різниця варта реальних грошей.

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

Те, що це знімає, суттєве. Жодної оцінки відповідності. Жодного маркування CE. Жодної технічної документації за додатком IV. Жодної реєстрації в базі даних ЄС. Це дорогі, повільні обов'язки, залежні від нотифікованого органу, і суб'єкти впровадження їх просто не мають.

Помилка, що йде у зворотний бік

Два шляхи ведуть до обов'язків постачальника без вашого рішення ним стати.

1. Істотна модифікація - стаття 25

Ви стаєте постачальником системи, яка раніше була чужою, якщо ви:

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

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

White-label - та сама пастка в дружнішому вбранні. Перепродаж під власним брендом ставить на продукт вашу назву, а регламент читає назви.

2. GPAI - стаття 53

Окреме питання з окремою відповіддю. Що ви зробили з моделлю?

• Виклики API або промптинг - ви нижче за течією. Обов'язки зі статті 53 лежать на постачальнику моделі. Не на вас.
• Легке донавчання, та сама домена, скромний набір даних - у звичайному випадку теж нижче за течією.
• Істотне перенавчання, значна зміна параметрів або нова предметна область - ви можете бути постачальником GPAI: технічна документація за додатком XI, інформація для нижчих ланок за додатком XII, політика щодо авторського права і TDM та публічне резюме навчальних даних.

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

Ви, найімовірніше, і те, і те

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

Реалістичний приклад. HR-tech компанія на двадцять осіб:

• Постачальник власної системи ранжування резюме, яку продає роботодавцям під власним брендом. Високий ризик за додатком III пункт 4. Повні обов'язки постачальника до 2 грудня 2027.
• Суб'єкт впровадження готового ШІ-нотатника, який використовує у власному наймі. Обов'язки за статтею 26, а якщо цей нотатник високого ризику, вони стосуються цієї компанії як його користувача.
• Суб'єкт впровадження чат-бота підтримки на своєму маркетинговому сайті. Обмежений ризик, інформування за статтею 50, діє вже зараз.

Три системи, три позиції, одна компанія. Саме тому "яка категорія в моєї компанії?" - не те питання, на яке регламент може відповісти. Ролі й категорії прикріплюються до систем, а не до організацій. Кожна оцінка робиться для окремої системи, і компанія з трьома системами ШІ має три оцінки.

Стаття 26 повністю - що насправді винні суб'єкти впровадження

Варто прочитати, бо це коротше, ніж люди бояться:

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

Це справжні обов'язки. Але жодного нотифікованого органу, жодного маркування CE, жодної технічної документації і жодних потрібних вісімнадцяти місяців розгону.

Як розібратися за двадцять хвилин

1. Перелічіть свої системи ШІ окремо. Не продукти - системи. Чат-бот, модель ранжування і внутрішній нотатник - це три записи.
2. Для кожної спитайте: чия назва на ній, коли вона виходить на ринок? Ваша означає постачальника. Чужа, а ви нею користуєтеся, означає суб'єкта впровадження.
3. Для кожної спитайте: чи змінили ми те, для чого вона призначена? Якщо ви перепрофілювали систему під використання високого ризику, ви, найімовірніше, тепер її постачальник.
4. Окремо спитайте: чи істотно модифікували ми модель загального призначення? Якщо так, перевірте статтю 53.
5. Запишіть кожну відповідь із одним реченням обґрунтування і поставте дату.

Останній крок люди пропускають, і саме він має цінність. Датована сторінка з написом "ця система, ця роль, це обґрунтування" - це рівно те, про що просить юридичний відділ корпоративного покупця, надсилаючи анкету. Це також те, що відрізняє "ми це оцінили" від "ми припустили".

Поширені запитання

Яка різниця між постачальником і суб'єктом впровадження за Актом про ШІ?

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

Чи можу я бути водночас постачальником і суб'єктом впровадження?

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

Чи робить використання API OpenAI або Anthropic мене постачальником GPAI?

Ні. Виклик моделі загального призначення через API або промптинг залишає вас нижче за течією, і обов'язки зі статті 53 лишаються на постачальнику моделі. Істотне перенавчання або донавчання моделі - великий набір даних, значні зміни параметрів або нова предметна область - може зробити вас постачальником GPAI за статтею 53.

Що таке істотна модифікація за Актом про ШІ?

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