Відповідальні інновації AI: етика як інженерна дисципліна

У 2024 році нідерландський суд зобов’язав зупинити систему SyRI, яка алгоритмічно виявляла громадян, підозрюваних у соціальному шахрайстві. Алгоритм працював ефективно у вузькому технічному сенсі: класифікував випадки з високою точністю на тренувальних даних. Однак він був «чорною скринькою», діяв непропорційно щодо певних демографічних груп і не надавав громадянам жодного шляху оскарження. Суд визнав це порушенням прав людини.

Це не приклад злих намірів. Це приклад етичної відповідальності, сприйнятої як зовнішній шар — те, що додається «після» завершення системи. У 2026 році, з чинним AI Act і зростаючою кількістю подібних рішень, така послідовність проектування є як етично сумнівною, так і юридично ризикованою.

Відповідальні інновації AI — це інженерна дисципліна. Вони вимагають конкретних рішень на рівні архітектури, а не декларацій цінностей у підвалі сторінки.

Пояснюваність моделі AI — це здатність вказати, чому система видала конкретну рекомендацію або рішення. У практиці проектування йдеться про три різні питання, які легко сплутати.

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

Пояснюваність рішення запитує про те, що саме у вхідних даних вплинуло на результат для конкретного випадку. Тут інструменти як SHAP, LIME чи візуалізація attention дають корисні наближення, особливо для класифікаційних моделей на табличних даних. Для LLM, що генерують текст, можливе цитування фрагментів джерел (архітектура RAG надає це природно).

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

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

AI Act вимагає пояснюваності аудиту для високоризикових систем, а не повної інтерпретованості. Це важливе розрізнення для компаній, що планують впровадження.

Класичний закид щодо AI у компаніях — «чорна скринька»: система дає результат, але незрозуміло чому. У 2026 році цей закид є частково застарілим, а частково більш точним, ніж будь-коли.

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

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

Три проектні патерни, які зменшують проблему «чорної скриньки» на практиці:

• RAG з цитуванням: модель не генерує відповіді з пам’яті, а на основі конкретних фрагментів. Кожна відповідь має посилання на вихідні документи. Юридичний, податковий чи медичний асистент повинен цитувати, а не перефразовувати.
• Логи рішень агента: кожен виклик інструменту агентом (пошук, модифікація запису, відправка) логується з контекстом: що було на вході, який інструмент викликано, який результат. У разі інциденту можна відтворити послідовність.
• Human-gate при незворотних діях: рішення, які не можна скасувати (відправка електронного листа клієнту, зміна договору, запис до реєстру), вимагають підтвердження людиною. Автоматизація без human-gate при незворотних діях — це проект аварії, а не проект системи.

Упередженість у моделях AI — це тема, яка часто або применшується («це лише статистика»), або перебільшується («AI завжди упереджена»). Реальність є більш точною.

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

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

Чотири питання, які мають бути поставлені перед кожним впровадженням системи прийняття рішень:

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

Багато практиків сприймають AI Act як тягар: черговий список вимог для відмітки перед здачею системи. Це некорисна проектна перспектива.

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

Три вимоги AI Act, які одночасно є хорошими інженерними практиками незалежно від права:

Логи та документація системи. AI Act вимагає зберігання логів, автоматично генерованих високоризиковими системами. Навіть без цієї вимоги: система AI без логів — це система, яку неможливо налагодити чи перевірити після інциденту.

Прозорість для користувачів. Системи, що взаємодіють з людьми (чат-боти, асистенти, системи рекомендацій), мають бути ідентифіковані як AI. Це не лише юридична вимога — користувачі, які знають, що спілкуються з моделлю, мають інші та точніші очікування щодо помилок і обмежень.

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

Обов’язки та терміни AI Act у контексті українських компаній детально розглядає стаття AI Act і RODO 2026: обов’язки компаній.

Guardrails — це механізми, які контролюють поведінку моделі AI: що вона може сказати, на які запитання відповідати, які дії виконувати. Це технічна реалізація етичних обмежень.

Без guardrails мовні моделі схильні до так званих галюцинацій (генерації впевнених відповідей на запитання, щодо яких немає даних), виходу за межі теми, вразливості до prompt injection та повторення шаблонів з тренувальних даних, які можуть бути упередженими або застарілими.

Guardrails реалізуються на кількох рівнях:

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

Рівень retrieval (в архітектурі RAG): обмеження джерел до перевіреної бази знань, поріг впевненості retrieval — якщо система не знаходить достатньо відповідного фрагмента, вона має сказати «не знаю» замість генерації відповіді з пам’яті моделі.

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

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

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

Human-in-the-loop — це патерн, у якому людина бере участь у циклі прийняття рішень системи AI. Часто сприймається як універсальне рішення для будь-якого етичного ризику: «додамо людину». Це проектна помилка.

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

Продуктивне питання звучить не «чи додавати людину», а «де межа автоматизації». Корисна евристика:

• Автоматизація без нагляду: повторювані завдання з низьким ризиком і високою передбачуваністю (вилучення даних зі структурованих документів, класифікація за чіткими правилами, сповіщення).
• Human-in-the-loop: рішення з наслідками для конкретних осіб, де помилку можна виявити та виправити до виконання (рекомендація пропозиції клієнту, проект відповіді на скаргу для затвердження, ескалація від асистента до консультанта).
• Human-on-the-loop: система працює автономно, але людина моніторить і може втрутитися (моніторинг аномалій у даних, алерти для аналізу).
• Виключно людське рішення: незворотні дії з високим ризиком або ті, що вимагають етичної оцінки, яку система не здатна надати (рішення про звільнення працівника, відмова в медичній послузі, оцінка юридичного випадку з прецедентом).

AI Act називає цей останній рівень human-oversight і вимагає його експліцитно для високоризикових систем. У проектуванні агентних систем варто визначити ці рівні на етапі архітектури, а не постфактум.

RODO часто сприймається так само, як AI Act: список обмежень, які потрібно обійти або виконати мінімально. Для систем AI технічний підхід дає кращі результати.

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

Чотири практики, які поєднують комплаєнс RODO з якістю системи AI:

Маскування PII перед ембедінгом. Персональні дані в запитах до асистента (імена, номери телефонів, адреси) мають бути замасковані локально, перш ніж запит потрапить до моделі або векторного пошукача. Це не лише захищає приватність — усуває шум з індексу, який погіршив би якість retrieval.

Обмежений термін зберігання логів. Логи розмов необхідні для аудиту та покращення системи, але мають мати визначений термін зберігання. Постійне логування без політики видалення створює зростаючий ризик витоку.

Право на видалення даних у системах RAG. Коли користувач вимагає видалення своїх даних (ст. 17 RODO), система RAG має видалити не лише записи в реляційній базі, а й вектори у векторному індексі. Архітектура має підтримувати це з проекту, а не як пізніша модифікація.

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

Для компаній з фінансового, юридичного або медичного секторів варто розглянути self-hosting моделей, який усуває ризик витоку даних через зовнішні API. Технічні та юридичні деталі цього підходу розглядає стаття self-hosted LLM та RODO.

Опиши систему AI, яку плануєш впровадити або вже експлуатуєш. Модель вкаже потенційні етичні та юридичні ризики та конкретні заходи на рівні архітектури (playground: PII маскуються, нульове зберігання):

Ні за визначенням, але безвідповідальна інновація AI часто призводить до впроваджень, які доводиться зупиняти або переробляти після перших інцидентів. Guardrails, логування та human-gate, спроектовані з самого початку, дешевші, ніж додані постфактум до працюючої системи, яка вже встигла створити проблеми. Витрати на безвідповідальне впровадження (інциденти безпеки, порушення RODO, дискримінаційні рішення) важко оцінити заздалегідь, але вони добре задокументовані в юридичній літературі. Стаття з чого почати впровадження AI описує, як врахувати ці аспекти вже на етапі планування пілоту.

AI Act визначає високоризикові системи за двома критеріями: категорією застосування та потенційним впливом на основні права. До категорії високого ризику належать системи, що використовуються в рекрутингу та управлінні працівниками, оцінці кредитоспроможності, доступі до освіти, публічних послугах та базових сервісах, прикордонному контролі та правосудді. Системи, що використовуються в цих сферах, вимагають реєстрації в європейській базі даних, технічної документації, логування, human-oversight та оцінки відповідності перед впровадженням. Детальний огляд з прикладами українських застосувань містить стаття AI Act: високоризикові системи.

Архітектура RAG з цитуванням джерел — основний інструмент. Модель відповідає на основі конкретних фрагментів з бази знань, а не з параметричної пам’яті, і кожна відповідь містить посилання на вихідний документ. Додаткові механізми: поріг впевненості retrieval (відмова відповідати за відсутності достатнього контексту), температура моделі, підібрана під завдання (низька для завдань, що вимагають точності), верифікація структури та діапазону відповіді на рівні guardrails та регулярні регресійні тести на наборі запитань з очікуваними відповідями. Методики обмеження галюцинацій детально розглядає стаття як обмежити галюцинації AI.

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

DPIA (оцінка впливу на захист даних) — це структурований аналіз ризиків, пов’язаних з обробкою персональних даних. Для системи AI включає: опис системи та потоку даних (що обробляється, ким, як довго), оцінку необхідності та пропорційності (чи мета вимагає такого обсягу даних), ідентифікацію ризиків для прав осіб (доступ, помилкові рішення, витоки, дискримінація) та заходи для кожного ризику. DPIA вимагається, коли обробка є систематичною та великомасштабною, стосується конфіденційних даних або включає автоматизоване прийняття рішень з суттєвими наслідками для осіб. Інструмент blueprint агента проводить через ключові проектні питання, які є відправною точкою для DPIA.