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

Закон ЄС про ШІ (EU AI Act), офіційно відомий як Регламент (ЄС) 2024/1689, впроваджує нову реальність для компаній, які створюють або використовують штучний інтелект на європейському ринку. Продакт-оунери більше не можуть ставитися до комплаєнсу як до формальності, яку перевіряють прямо перед релізом. А інженерні команди не можуть спочатку будувати ШІ-системи, а потім просити юристів «привести їх у відповідність до закону».

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

Для компаній, які інвестують у кастомну розробку ШІ, це створює безпосередній технічний виклик: відповідність вимогам (комплаєнс) має закладатися на етапі архітектури, а не «налеплюватися» на готове ПЗ після релізу.

Цей гайд пояснює, що саме охоплює Регламент (ЄС) 2024/1689, як він впливає на ключові галузі та як Lionwood Software забезпечує технічний комплаєнс завдяки методології розробки Compliance-by-Design (Відповідність вимогам через проєктування).

Що таке Регламент (ЄС) 2024/1689 і що він регулює?

Регламент (ЄС) 2024/1689 — це офіційна правова база Закону ЄС про ШІ. Це горизонтальний регламент, що базується на оцінці ризиків. Це означає, що він застосовується не до однієї конкретної галузі чи типу ПЗ, а поширюється загалом на всі ШІ-системи, які виводяться на європейський ринок або використовуються в ЄС, — включно із системами, розробленими компаніями з-за меж Євросоюзу.

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

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

Базова класифікація рівнів ризику

• Неприйнятний ризик (Unacceptable Risk): Такі практики використання ШІ є повністю забороненими. Ця категорія включає системи, які шкідливо маніпулюють поведінкою людей, здійснюють соціальний скоринг, експлуатують вразливі групи населення або використовують певні форми збору та ідентифікації біометричних даних у заборонених контекстах. Для бізнес-лідерів меседж очевидний: такі системи не можна створювати, розгортати чи комерціалізувати на ринку ЄС.
• Високий ризик (High-Risk): Ці системи дозволені, але суворо регулюються. До ШІ високого ризику належать системи, що використовуються в критичній інфраструктурі, охороні здоров'я, працевлаштуванні, освіті, правоохоронних органах, міграційних процесах, доступі до основних послуг або у функціях безпеки продуктів. Такі системи вимагають потужної технічної документації, належного управління даними (data governance), логування, прозорості, людського нагляду, ризик-менеджменту, кібербезпеки та постмаркетингового моніторингу.
• Обмежений ризик (Limited Risk): Ці системи загалом дозволені, але мають відповідати зобов'язанням щодо прозорості. Прикладами є чат-боти для підтримки клієнтів, ШІ-генератори тексту чи медіафайлів (дипфейки), певні інтерфейси розпізнавання емоцій, а також системи, де користувачі мають бути чітко поінформовані про те, що вони взаємодіють із ШІ або переглядають згенерований ним контент.
• Мінімальний ризик або його відсутність (Minimal or No Risk): Такі системи мають мінімальні зобов'язання. Сюди відносяться стандартні інструменти для підвищення продуктивності бізнесу, спам-фільтри, прості рекомендаційні системи або функції внутрішньої підтримки, які суттєво не впливають на права, безпеку, працевлаштування, медицину чи доступ до базових послуг.

Головний практичний аспект: Класифікація залежить від цільового призначення системи. Одна й та сама базова ШІ-модель може мати мінімальний ризик в одному контексті та високий — в іншому. Прогнозна модель для загального планування складських запасів — це зовсім не те саме, що ШІ-система для прийняття критично важливих для безпеки рішень у транспортній інфраструктурі чи клінічних процесах.

Таймлайн впровадження вимог

Закон ЄС про ШІ набув чинності 1 серпня 2024 року. Заборона на ШІ-практики з неприйнятним ризиком почала діяти з 2 лютого 2025 року. Загальна інфраструктура застосування закону продовжує фіксуватися навколо серпня 2026 року.

Проте оновлення EU Digital Omnibus змінило горизонт планування комплаєнсу для систем високого ризику. Згідно з нещодавніми коригуваннями, для автономних (standalone) ШІ-систем високого ризику (згідно з Додатком III) дедлайн впровадження перенесено на 2 грудня 2027 року, тоді як для систем високого ризику, інтегрованих у продукти (згідно з Додатком I), запуск очікується в серпні 2028 року.

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

Вплив на індустрії: Що Закон означає для ключових вертикалей

Регламент (ЄС) 2024/1689 не є абстрактним для галузей, які залежать від даних, автоматизації та прийняття операційних рішень. Його вплив стає цілком відчутним у реальних бізнес-доменах, де працює Lionwood Software.

Логістика та ланцюги постачання

ШІ все частіше використовується в логістиці для оптимізації транзитних маршрутів, прогнозування часу доставки, управління складами, автоматизації диспетчеризації та покращення прозорості ланцюгів постачання.

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

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

З технічної точки зору, логістичні ШІ-системи повинні розроблятися з чітким відстеженням походження даних, логуванням подій, зрозумілістю рекомендацій щодо маршрутів (explainability), опціями ручного перевизначення (manual override) та моніторингом аномальних результатів.

Охорона здоров'я та медичне ПЗ

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

Питання не в тому, чи корисний ШІ в медицині — він однозначно корисний. Питання в тому, чи є система точною, доступною для пояснення, контрольованою, безпечною та належним чином керованою кваліфікованими медичними працівниками.

Медична ШІ-система не повинна ставати «чорною скринькою», яка таємно впливає на клінічні рішення без можливості відстежити логіку. Вона має проєктуватися з контрольованими наборами даних (datasets), задокументованою поведінкою моделі, можливістю перевірки людиною (human-in-the-loop), аудиторськими логами та рольовим доступом для лікарів, адміністраторів і команд із комплаєнсу.

Для кастомного медичного ПЗ підхід Compliance-by-Design є обов'язковим. Це єдиний реалістичний спосіб запобігти кардинальній переробці архітектури на пізніх стадіях, розмиванню відповідальності та слабкій готовності до аудитів.

Виробництво

ШІ у виробництві підтримує предиктивне обслуговування (predictive maintenance), виявлення аномалій, промисловий контроль якості, планування виробництва та ідентифікацію дефектів.

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

Тому архітектура ШІ для виробництва повинна включати надійний моніторинг, тестування режимів відмови (failure-mode testing), логування подій, безпечний контроль доступу та чіткі механізми ескалації. Коли вихідні дані ШІ можуть вплинути на безпеку на робочому місці або якість продукції, людський нагляд не може бути номінальним — він має бути закладений безпосередньо в робочий процес.

Цифрові активи та блокчейн

Системи блокчейну та цифрових активів не стають автоматично ШІ-системами високого ризику. Однак вони часто мають технічні вимоги, які тісно перетинаються з очікуваннями Закону про ШІ: простежуваність (traceability), цілісність даних, безпечні потоки ідентифікації, логіка валідації та захищені від несанкціонованого доступу записи.

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

Досвід Lionwood у розробці блокчейн-систем є цінним у цьому контексті, оскільки регульована архітектура ШІ так само критично залежить від можливості аудиту. Коли система повинна довести, що сталося, коли це сталося, хто вчинив дію і чи були змінені записи — інженерна дисципліна стає головним активом комплаєнсу.

Як Lionwood забезпечує технічний комплаєнс зі свого боку

Lionwood Software не замінює собою юридичну відповідальність Постачальника (Provider) або Розгортача (Deployer) системи. Остаточний статус комплаєнсу ШІ-продукту залежить від його цільового призначення, категорії ризику, ролі на ринку, документації, контексту використання та регуляторної оцінки.

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

У цьому і полягає практичний зміст підходу Compliance-by-Design у кастомній розробці ШІ.

1. Фаза Discovery як шлюз для оцінки ризиків комплаєнсу

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

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

Під час Discovery команда оцінює:

• Цільове використання: Яке рішення або робочий процес система ШІ підтримуватиме, автоматизуватиме чи на яке впливатиме?
• Рівень ризику: Чи є система мінімальною, обмеженою, високоризиковою чи забороненою?
• Межі системи: Які частини продукту використовують ШІ, а які залишаються на базі чітких правил (rule-based), ручними або контролюються ззовні?
• Потоки даних: Які дані надходять у систему, звідки вони беруться, як обробляються і де зберігаються?
• Точки людського контролю: Де в робочий процес необхідно закласти перевірку, затвердження, перевизначення або ескалацію людиною?
• Сторонні залежності: Чи покладається система на зовнішні моделі ШІ, API, хмарні інструменти або процесори даних?

Цей процес мінімізує ризик дороговартісних змін на пізніх стадіях розробки. Замість виявлення гепів (прогалин) у комплаєнсі після завершення проєкту, команда продукту з самого початку формує архітектуру відповідно до правильного регуляторного профілю.

2. Високоточне управління даними відповідно до Статті 10

Стаття 10 приділяє особливу увагу управлінню даними (data governance) для ШІ-систем високого ризику. Інженерною мовою це означає, що системи ШІ мають будуватися на контрольованих, релевантних, репрезентативних та відповідних цільовому призначенню даних.

Lionwood підтримує це через структуровані практики дата-менеджменту:

• Відстеження життєвого циклу даних (Data Lineage Tracking): Архітектура має чітко визначати, звідки походять набори даних для навчання, валідації та тестування, як вони збиралися і як рухаються через систему.
• Походження датасетів (Dataset Provenance): Кожен набір даних повинен мати чітке джерело, контекст власності, історію обробки та цільове призначення.
• Оцінка релевантності: Дані мають перевірятися на відповідність реальному операційному середовищу, де використовуватиметься система ШІ.
• Тестування для пом'якшення упередженості (Bias Mitigation): Автоматизовані потоки валідації допомагають виявляти пропущені значення, історичну упередженість, аномалії, незбалансовані дані або застарілі записи.
• Моніторинг якості даних: Система не повинна розглядати якість даних як одноразове налаштування. Продакшн-дані необхідно моніторити постійно, щоб вчасно виявляти відхилення (data drift), деградацію моделей або неочікувані патерни вхідних даних.

3. Простежуваність, безпечне логування та паралель з кейсом Lingon відповідно до Статей 11 та 12

Статті 11 та 12 фокусуються на технічній документації та автоматичному веденні записів для систем ШІ високого ризику. З точки зору програмної інженерії, система повинна вміти «пояснити» свою операційну історію.

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

Lionwood реалізує це через готові до аудиту інженерні патерни:

• Автоматизований аудит системи: ШІ-системи генерують структуровані логи, які фіксують релевантні вхідні/вихідні дані, версії моделей, дії користувачів та зміни конфігурації.
• Безпечне збереження логів: Для систем ШІ високого ризику компанії, що розгортають ПЗ, зобов'язані зберігати автоматично згенеровані логи під своїм контролем щонайменше 6 місяців відповідно до Статті 26. Архітектура підтримує цю вимогу через чіткі політики ретенції та безпечне сховище.
• Відстеження конфігурації моделей: Система фіксує, яка саме модель, версія промпту, версія датасету чи конфігурація правил були активними на момент прийняття рішення.
• Захист записів від несанкціонованого доступу: Логи захищені від несанкціонованих модифікацій, видалення або прихованих маніпуляцій.

Архітектурний прецедент: Проєкт Lingon Certificates

Проєкт Lingon Certificates є чудовим доказом нашої інженерної зрілості. У цьому проєкті Lionwood розробила мобільний додаток для генерації унікальних цифрових сертифікатів та реєстрації прав власності на активи e-commerce в блокчейні. Система підтримувала перевірку автентичності через QR-сканування, реєстрацію власності, безпечну автентифікацію та відстеження життєвого циклу сертифікатів.

Цей проєкт не був продуктом під комплаєнс Закону про ШІ, але його цінність — суто архітектурна. Генерація сертифікатів на базі блокчейну вимагає максимально безпечних записів, простежуваних подій та захисту від підробок. Це ті самі інженерні принципи, які необхідні для готових до аудиту ШІ-систем, де логи, події життєвого циклу та системні рішення мають залишатися на 100% надійними. Паралель з Lingon показує, що Lionwood має практичний досвід створення систем, де простежуваність — це не фіча, додана згодом, а частина ядра архітектури.

4. Людський нагляд та гранулярні рольові моделі відповідно до Статті 14

Стаття 14 вимагає, щоб системи ШІ високого ризику підтримували ефективний людський нагляд. У кастомному ПЗ це має трансформуватися в реальний інтерфейс та дизайн робочих процесів.

Слабка імплементація просто додала б загальний підпис «потрібна перевірка». Сильна імплементація надає кваліфікованим фахівцям інструменти для контролю, перевірки, перевизначення, призупинення або повної зупинки операцій ШІ за потреби.

Lionwood реалізує це через детальний дизайн ролей та воркфлоу:

• Контроль за принципом Human-in-the-Loop: Чутливі результати роботи ШІ можуть спрямовуватися до реальних рев'юверів (людей) перед тим, як вони вплинуть на реальні рішення.
• Дашборди затвердження: Оператори можуть переглядати рекомендації, вивчати супутню інформацію та затверджувати або відхиляти згенеровані ШІ варіанти.
• Функції ручного перевизначення: Авторизовані користувачі можуть втрутитися, якщо система видає небезпечну, неточну або неповну рекомендацію.
• Рольовий контроль доступу (RBAC): Різним ролям призначаються різні дозволи на перегляд, затвердження, редагування, аудит або вимкнення функцій ШІ.
• Процеси ескалації: Сумнівні або критично важливі кейси автоматично перенаправляються на старших рев'юверів, комплаєнс-офіцерів, лікарів, супервайзерів або адміністраторів.
• Логіка «екстреної кнопки» (Kill-Switch Logic): У високоризикових середовищах система має містити чіткий механізм для швидкої зупинки або вимкнення операцій ШІ.

5. Архітектурна кібербезпека відповідно до Статті 15

Стаття 15 вимагає, щоб системи ШІ високого ризику відповідали належним рівням точності, стійкості та кібербезпеки. Для ШІ-продуктів це виходить далеко за рамки стандартної безпеки додатків (AppSec).

ШІ-системи стикаються зі специфічними векторами атак, і безпечна архітектура має враховувати їх від самого початку:

• Захист від промпт-ін'єкцій (Prompt Injection Protection): Генеративні ШІ-воркфлоу мають бути захищені від шкідливих інструкцій, які намагаються обійти системні правила або розкрити конфіденційну інформацію.
• Захист від состязательних атак (Adversarial Manipulation Defense): Моделі ШІ мають тестуватися на стійкість до вхідних даних, створених спеціально для того, щоб ввести систему в оману або зманіпулювати нею.
• Контроль отруєння даних (Data Poisoning Controls): Пайплайни навчальних та операційних даних мають бути захищені від пошкоджених або навмисно сфальсифікованих даних.
• Запобігання несанкціонованому дрейфу моделі: Система контролює, коли саме моделі оновлюються, перенавчаються, доналаштовуються (fine-tuned) або змінюють конфігурацію.

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

Навігація в ланцюгу створення вартості: Постачальники (Providers) vs. Розгортачі (Deployers)

Ключова частина Регламенту (ЄС) 2024/1689 — це розуміння того, хто саме несе відповідальність. У кастомній розробці ПЗ цей момент часто інтерпретують помилково.

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

Lionwood Software зазвичай функціонує як партнер із виконання (execution partner). Наша роль полягає в наданні технічної інфраструктури, архітектури ПЗ, підтримки документації, засобів контролю даних, заходів безпеки та процесів розробки, які допомагають клієнту виконати зобов'язання, покладені на його юридичну роль.

Точний розподіл ролей фіксується контрактно та технічно ще під час фази Discovery.

Комплаєнс стає конкурентною перевагою

Регламент (ЄС) 2024/1689 часто обговорюють виключно як юридичний тягар. Проте для компаній, які створюють серйозні ШІ-продукти, такий погляд є занадто вузьким.

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

ШІ-система, розроблена за принципом Compliance-by-Design, легше проходить оцінку, викликає більше довіри, простіше масштабується та безперешкодно інтегрується в регульовані бізнес-середовища.

Для сфери кастомної розробки програмного забезпечення практичний висновок очевидний: не намагайтеся ретроактивно «наліпити» комплаєнс на готове ПЗ. Будуйте правильний технічний фундамент з першого дня.