Регламент Європейського Союзу про штучний інтелект досягає загальної дати застосування 2 серпня 2026 року. Для розробника це не означає, що треба додати однаковий бейдж «створено AI» на кожен екран. Потрібно описати кожну AI-систему, визначити provider і deployer, показати повідомлення Article 50 у користувацькому потоці, зберегти сигнали простежуваності й дати уповноваженій людині реальний спосіб втрутитися. У цій статті інженерну роботу зіставлено з консолідованим текстом Регламенту (EU) 2024/1689 на EUR-Lex і настановами Комісії щодо Article 50, перевіреними 28 серпня 2026 року.
Це технічний посібник, а не юридична консультація. AI Act містить правила, що залежать від ролі, призначення, способу використання та галузі. Команда все одно має перевірити факти, застосовне національне право, обов’язки із захисту даних і компетентний орган. Нижче наведені інженерні шаблони, а не юридична класифікація вашого продукту.
Дати, що змінюють план розробки
Обов’язки щодо прозорості Article 50 застосовуються з 2 серпня 2026 року. Для provider генеративної AI-системи, розміщеної на ринку до цієї дати, є обмежений перехідний період щодо обов’язку Article 50(2) маркувати контент і забезпечувати його виявлення, до 2 грудня 2026 року. Комісія зазначає, що контент, створений і вже доступний до 2 серпня, не потрібно маркувати заднім числом. Цей перехід не скасовує інші обов’язки Article 50, які з 2 серпня діють для охопленої системи. Вважайте ці дати двома різними воротами релізу.
Інші дати легко переплутати. Заборони, визначення та положення про AI-грамотність діють із 2 лютого 2025 року. Правила управління й обов’язки для моделей загального призначення діють із 2 серпня 2025 року. За зміненим Article 113 вимоги до високоризикових систем у Chapter III, Sections 1–3 застосовуються до систем Annex III за Article 6(2) із 2 грудня 2027 року, а до пов’язаних із продуктами систем за Article 6(1) і Annex I із 2 серпня 2028 року. Provider і deployer високоризикових систем для державних органів мають зробити необхідні кроки до 2 серпня 2030 року. Це не причина відкладати контроль, але Article 12 не є загальним обов’язком вести логи для кожного чатбота в серпні 2026 року.
Перевіряйте календар у поточному огляді AI Act від Комісії. Перед релізом знову перечитуйте консолідований текст EUR-Lex, бо наступні акти або національні заходи можуть змінити роботу для конкретної системи.
Почніть із ролі та юрисдикції
Article 2 охоплює provider, який розміщує AI-систему або модель загального призначення на ринку Союзу чи вводить її в експлуатацію в Союзі, незалежно від місця заснування в Союзі або третій країні. Він охоплює deployer, заснованого або розташованого в Союзі, а також provider чи deployer із третьої країни, якщо результат системи використовується в Союзі. До сфери також входять імпортери, дистриб’ютори, виробники продуктів і уповноважені представники. Article 2 виключає сфери поза правом Союзу та системи, що використовуються виключно у військових, оборонних цілях або для національної безпеки.
За Article 3 provider — це організація, яка розробляє або замовляє розробку AI-системи та розміщує її на ринку чи вводить в експлуатацію під власним іменем або торговою маркою. Deployer використовує систему під своєю владою, крім особистого непрофесійного використання. Хмарний постачальник може бути provider моделі, а ваша компанія — deployer агента, який її викликає. Якщо компанія ставить власне ім’я, суттєво змінює високоризикову систему або змінює призначення так, що невисокоризикова система стає високоризиковою, Article 25 може зробити компанію provider цієї системи. Зафіксуйте це рішення в ланцюжку створення.
Створіть рядок реєстру для кожної користувацької системи та кожної повторно використовуваної моделі або служби. Запишіть provider, deployer, призначення, ринки, модальності, безпосередню взаємодію з людиною, оцінку ризику, версії, інтеграції та того, хто затвердив запис. Коротка схема потоку даних корисніша за ярлик продукту:
людина -> інтерфейс -> повідомлення AI -> адаптер моделі -> політика виводу
-> мітка походження -> ярлик або перевірка -> публікація
-> сховище подій -> моніторинг і реагування
Article 50 має чотири різні інженерні поверхні
FAQ Комісії про Article 50 пояснює сферу та приклади. Реалізуйте ці обов’язки окремо.
| Поверхня AI Act | Відповідальна роль | Мінімальний наслідок для продукту |
|---|---|---|
| Безпосередня взаємодія | Provider | Повідомити людину, що вона взаємодіє з AI, якщо це не очевидно з контексту. |
| Синтетичний звук, зображення, відео або текст | Provider | Додати машинозчитувану мітку, що дає змогу виявити штучне створення або зміну. |
| Вплив розпізнавання емоцій або біометричної категоризації | Deployer | Повідомити людей, на яких впливає операція, і обробляти дані за застосовними правилами Союзу. |
| Deepfake або згенерований текст про суспільно важливе питання | Deployer | Надати чітке розрізнюване розкриття під час першого впливу з урахуванням винятків Article 50(4). |
Розкриття в чатботі та агенті
Настанови Комісії описують чотири сукупні умови обов’язку Article 50(1): система є AI-системою, створена для справжнього двостороннього обміну, AI спілкується безпосередньо, а не через людського посередника, а інша сторона є фізичною особою. Фонова служба, що спілкується лише з іншою службою, відрізняється від агента підтримки, який передає клієнту потоковий текст. Виняток «очевидно» слід тлумачити вузько, бо він забирає інформацію в людини.
Показуйте повідомлення до першого токена моделі. Воно має бути видимим у транскрипті, доступним для допоміжних технологій і зберігатися під час виклику інструмента чи передачі діалогу людині. Фраза «Ви взаємодієте з AI-асистентом» ясніша за назву бренду або схожий на людину аватар. Зберігайте версію повідомлення та результат відображення в аудиторській події. У голосовому інтерфейсі повідомляйте про AI до початку обміну. Подальша перевірка людиною не скасовує початковий обов’язок.
Синтетичний контент і походження
Article 50(2) покладає обов’язок маркування на provider, зокрема на provider системи загального призначення, що створює синтетичний звук, зображення, відео або текст. Мітка має бути машинозчитуваною і давати змогу виявити штучне створення або зміну. Технічне рішення повинно бути ефективним, сумісним, стійким і надійним настільки, наскільки це технічно можливо, з урахуванням типу контенту, вартості й сучасного рівня техніки. Видимий бейдж сам по собі не є машинозчитуваною міткою, а така мітка не замінює видиме розкриття deployer для deepfake.
Винятки охоплюють допоміжну функцію стандартного редагування, результат без суттєвої зміни вхідних даних deployer або їхньої семантики та системи, дозволені законом для виявлення, запобігання, розслідування чи переслідування злочинів. Настанови обговорюють вужчі приклади машинної взаємодії та замкненого виробничого процесу. Не перетворюйте їх на загальний виняток для внутрішніх інструментів. Збережіть рішення про сферу та його власника.
Deepfake і текст про суспільний інтерес
Deployer має розкрити AI-згенероване або змінене зображення, аудіо чи відео, що є deepfake. Комісія описує його через схожість з реальною або правдоподібно реальною людиною, предметом, місцем, сутністю чи подією та хибне враження автентичності або правдивості. Розкриття має сприйматися без спеціального інструмента чи додаткової дії. Розмістіть «створено або змінено AI» біля медіа, у його доступному імені або в звуковому повідомленні під час першого впливу. Для явно художнього, сатиричного чи вигаданого твору можна повідомити лише про наявність створеного контенту, не заважаючи його показу.
Окреме правило для тексту діє, коли згенерований або змінений текст публікують, щоб інформувати громадськість про питання суспільного інтересу. Приклади охоплюють політику, державне управління, правосуддя, основні права, громадську безпеку, здоров’я, довкілля, безпеку споживачів і економічні, фінансові, наукові чи культурні події. Виняток Article 50(4) потребує людської перевірки або редакційного контролю та фізичної чи юридичної особи, відповідальної за публікацію. Перевірка орфографії не є такою перевіркою. Якщо команда не може довести змістовну перевірку й відповідальність, залиште чітку мітку.
Логуйте потрібне, а не все
Article 12 застосовується до високоризикових AI-систем, коли стають чинними їхні вимоги Chapter III. Система має технічно підтримувати автоматичний запис подій протягом життєвого циклу. Логи повинні забезпечувати простежуваність, відповідну призначенню, зокрема виявлення ситуацій, що можуть створити ризик або суттєву зміну, постмаркетинговий моніторинг за Article 72 і моніторинг роботи за Article 26(5). Для високоризикової дистанційної біометричної ідентифікації з Annex III, point 1(a), Article 12 додає мінімальні поля: період використання, еталонну базу, вхідні дані, що дали збіг, і людей, які перевірили результат.
Article 19 вимагає від provider зберігати автоматично створені логи під його контролем протягом строку, відповідного призначенню, але щонайменше шість місяців, якщо право Союзу або національне право, особливо законодавство про дані, не встановлює інше. Article 26(6) встановлює такий самий мінімум для логів під контролем deployer. Це не дозвіл зберігати сирі розмови безстроково. Визначте клас зберігання, обмежте доступ, шифруйте сховище подій і відокремте телеметрію від змісту. Хешуйте або редагуйте входи й виходи, якщо сирі дані не потрібні. Поля, що можуть ідентифікувати людину, має затвердити відповідальний за дані.
Оболонка події може мати такий вигляд:
{
"trace_id": "tr_7f3c",
"system_version": "agent-2026.08.28",
"model_id": "model-release",
"actor_role": "deployer",
"content_class": "text",
"mark_applied": true,
"label_shown": true,
"human_review": "not_required",
"override": false,
"created_at": "2026-08-28T12:00:00Z"
}
Це приклад ідентифікаторів, а не схема ЄС. Зв’яжіть повідомлення, версію моделі, обробку виводу, рішення людини та публікацію, не записуючи секрети чи повні транскрипти в кожен лог. Для високоризикового використання дозвольте provider і deployer отримувати, тлумачити та корелювати події. Посібник зі спостережуваності AI-агента описує траси, метрики й редагування даних.
Людський нагляд має працювати
Article 14 стосується високоризикових AI-систем. Provider має проєктувати їх, зокрема з відповідними інструментами взаємодії людини й машини, так, щоб фізичні особи могли ефективно наглядати за системою під час використання. Заходи мають відповідати ризику, автономності та контексту. Article 14 вимагає, щоб людина могла зрозуміти обмеження, виявляти аномалії та неочікувану роботу, помічати automation bias, правильно тлумачити вивід, ігнорувати або скасовувати його та зупиняти систему кнопкою чи подібною процедурою, що приводить її в безпечний стан.
Article 26 вимагає від deployer призначити нагляд людям із потрібними компетенціями, навчанням, повноваженнями й підтримкою. «Хтось подивився» не є контролем, якщо людина не бачить доказів, не може відхилити рекомендацію або зупинити дію. Розмістіть межу схвалення до незворотного побічного ефекту. Покажіть вивід моделі, важливі входи, обмеження системи, політичні перевірки та точну наступну дію. Розділіть відхилення, редагування, ескалацію та зупинку. Записуйте, хто втрутився і чому, не перетворюючи перевіряльника на формальну печатку.
Для високоризикових систем Annex III, point 1(a), Article 14(5) вимагає окремої перевірки й підтвердження щонайменше двома компетентними, навченими та уповноваженими фізичними особами до того, як deployer діятиме на основі ідентифікації, з винятком непропорційності, передбаченим правом Союзу або національним правом для правоохоронної діяльності, міграції, прикордонного контролю та притулку. Це спеціальне правило, а не загальна вимога двох перевіряльників для кожного AI-виводу.
Потік даних, який можна розгорнути
Залиште контроль у детермінованих службах навколо моделі. Шлюз взаємодії відповідає за початкове повідомлення та локаль. Адаптер моделі записує версію й нормалізує метадані provider. Сервіс виводу визначає модальність і призначення, застосовує або перевіряє машинозчитувану мітку та вирішує, чи потрібні видимий ярлик або змістовна людська перевірка. Політичний шлюз блокує публікацію без потрібного сигналу. Сервіс погодження зберігає перевіряльника, рішення, строк дії та шлях зупинки. Сховище подій отримує мінімальний пов’язаний запис. Моніторинг шукає відсутні повідомлення, помилки міток, неперевірений текст про суспільний інтерес, неочікувані виклики інструментів і невдалі зупинки.
Не ховайте ці перевірки в prompt. Лише інтерфейс гарантує повідомлення до початку потокової відповіді, а лише конвеєр виводу збереже мітку після експорту. Для дозволів агента й недовірених результатів інструментів дивіться посібник із prompt injection та безпеки MCP. Для окремих меж оркестрації, політики та побічних ефектів дивіться посібник із production-архітектури AI-агента.
Моніторинг і ритм оновлень
Вважайте Article 50 інваріантом релізу. Кожен build, що змінює модель, системний prompt, інтерфейс, рендеринг, експорт або локалізацію, має перевіряти повідомлення під час першої взаємодії, збереження машинозчитуваної мітки після завантаження й перетворення, видиме розкриття deepfake та неможливість опублікувати текст про суспільний інтерес без перевірки або мітки. Тестуйте клавіатуру, screen reader, мобільний, голос і API-клієнти, бо Article 50(5) вимагає чіткої та розрізнюваної інформації з урахуванням доступності.
У роботі підіймайте тривогу через відсутнє повідомлення, помилку походження, мітку, вилучену перетворенням, публікацію без human_review, перевіряльника без повноважень або зупинку, що не приводить систему в безпечний стан. Щотижня переглядайте вибірку трас. Щомісяця перевіряйте зберігання, доступ, навчання та зміни моделі або provider. Щокварталу проводьте документований огляд ризику й потоку даних. Негайно переглядайте систему після серйозного інциденту, релізу provider, нової модальності, зміни призначення, суттєвої модифікації або нової настанови Комісії.
Це інженерна практика, а не встановлений законом інтервал. Для високоризикових систем узгодьте управління ризиками й постмаркетинговий процес зі Articles 9 і 72. Article 112 передбачає оцінку можливих змін списку Article 50 до 2 серпня 2028 року і кожні чотири роки після цього. Ведіть реєстр джерел із консолідованим текстом EUR-Lex, настановами Комісії, статусом code of practice і відповідальним національним органом.
Чекліст перед релізом
- Запишіть provider, deployer, призначення, зв’язок із Союзом, модальності, користувачів і напрямки виводу.
- Визначте застосовний пункт Article 50 і збережіть докази винятків.
- Покажіть повідомлення про взаємодію до першого токена й перевірте доступність.
- Застосуйте машинозчитувану мітку на межі provider і перевірте її після експорту.
- Додайте розкриття під час першого впливу для deepfake і тексту про суспільний інтерес.
- Визначте змістовну перевірку, редакційну відповідальність, повноваження, скасування та безпечну зупинку.
- Для високоризикової сфери реалізуйте запис подій, власника, доступ, зберігання та ескалацію.
- Пов’яжіть кожен реліз із записами моделі, політики, мітки, перевіряльника та моніторингу.
- Перевіряйте офіційні джерела Комісії та EUR-Lex перед важливим релізом і після регуляторних змін.
Офіційні джерела цього посібника: консолідований Regulation (EU) 2024/1689, настанови Комісії щодо Article 50, FAQ Article 50, календар AI Act і короткі факти про прозорість. Визначальними є текст закону та настанови Комісії. Ця стаття не замінює юридичну, privacy чи галузеву консультацію.