AI Act у медицині: правові рамки для систем високого риску

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

AI Act поділяє системи за потенційною шкодою, а не за галуззю. Але список систем високого ризику в Додатку III прямо націлений на охорону здоров'я:

• п. 5a: системи ШІ, призначені для підтримки клінічних рішень (діагностика, планування лікування, аналіз медичних зображень),
• п. 5b: системи, що керують доступом до медичної допомоги або розподілом ресурсів (пріоритизація, тріаж),
• п. 5c: системи моніторингу стану здоров'я пацієнта в режимі реального часу.

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

AI Act уточнює обов'язки в Розділі III. Для медичних систем вони зводяться до чотирьох стовпів:

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

Найчастіше питання лікарень і клінік звучить так: "як пояснити лікарю, чому ШІ прийняв таке рішення?". Це питання тепер має правовий вимір.

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

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

У нашій роботі з пояснюваними системами (XAI) виділяємо три рівні: локальне пояснення (чому таке рішення для цього пацієнта), глобальне пояснення (як модель працює загалом) та аудиторський слід (що вона робила в часі). AI Act вимагає щонайменше першого та третього. Методики на кшталт SHAP, LIME чи attention maps — це інструменти реалізації. Жодна з них не є обов'язковою за назвою, але кожна може слугувати для доведення відповідності.

AI Act і RODO — це два окремі режими, які в медицині перетинаються майже повністю. Дані пацієнта — це дані про стан здоров'я — особлива категорія згідно зі ст. 9 RODO, що вимагає чіткої правової основи (згода або суспільний інтерес) та значно вищого рівня захисту.

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

Ключові принципи проєктування шару даних у медичних системах ШІ:

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

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

Ст. 14 AI Act говорить про людський нагляд як про елемент, який має бути вбудований у систему — не доданий як опція. У клінічному контексті це означає конкретну архітектуру робочого процесу:

Лікар (або інший уповноважений клініцист) має мати можливість:

1. переглянути обґрунтування перед прийняттям рішення на основі рекомендації ШІ,
2. відхилити рекомендацію без втрати доступу до системи та без необхідності пояснювати причину,
3. зупинити систему у разі сумнівів щодо її роботи.

В агентній архітектурі (системи, що виконують послідовності дій, наприклад, планують лікування, замовляють обстеження, оновлюють документацію) human-gate — тобто обов'язкове підтвердження людиною перед кожною незворотною дією — є прямою реалізацією ст. 14. Система може пропонувати, але не може самостійно виконувати незворотні дії. Цей механізм детально описаний у статті про безпеку агентів ШІ.

Це не обмежує автоматизацію. Обмежує її там, де помилка може зашкодити пацієнту.

Системи ШІ високого ризику в медицині найчастіше є одночасно медичними виробами згідно з регламентом MDR (2017/745) або In Vitro Diagnostics Regulation (IVDR). Обидва регулювання мають виконуватися одночасно — AI Act не замінює MDR.

Нотифікований орган, що сертифікує медичний виріб, тепер має враховувати AI Act як частину технічної оцінки. На практиці:

• технічна документація ШІ (вимога AI Act) потрапляє до актів сертифікації MDR,
• план моніторингу post-market (ст. 72 AI Act) має бути синхронізований з Post-Market Surveillance Plan, вимогою MDR,
• реєстр небажаних подій має бути узгодженим між обома режимами.

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

Одна з менш очевидних наслідків AI Act у медицині: вимога, щоб навчальні дані були репрезентативними та вільними від дискримінаційних упереджень (ст. 10). У клінічній практиці це проблема, яку індустрія знала роками, але тепер вона стає правовим обов'язком.

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

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

Опиши випадок використання системи ШІ в медичному або охоронному контексті, а модель допоможе попередньо оцінити категорію ризику згідно з AI Act, вказати відповідні статті та визначити ключові обов'язки. Це відправна точка для розмови з юристом та відповідальною особою, а не її заміна (playground: дані маскуються, нульове збереження):

Ні. Чат-бот, обмежений організаційною інформацією (години, адреси, адміністративні процедури), є системою обмеженого ризику. Він має відповідати вимозі прозорості — користувач має знати, що спілкується з ШІ. Межа зміщується, коли чат-бот починає збирати симптоми, пропонувати діагнози або направляти до відділень: тоді він потрапляє під дію Додатку III і стає системою високого ризику з усіма наслідками.

Обидва. AI Act розрізняє постачальника (той, хто розробив і вивів систему на ринок) та суб'єкта впровадження (лікарня, що її використовує). Постачальник відповідає за технічну відповідність і документацію. Суб'єкт впровадження відповідає за належне використання згідно з інструкцією, нагляд та моніторинг у реальних умовах. Лікарня, яка купує готову систему, не знімає з себе обов'язків адміністратора даних згідно з RODO.

Ні, не в сенсі кліку "ОК" при кожній пропозиції — це було б непрактично. Вимога полягає в тому, щоб клініцист міг втрутитися, відхилити результат або зупинити систему. На практиці це реалізується так: результат ШІ видно поряд з клінічними даними, є можливість відхилити з приміткою, блокується виконання незворотних дій (наприклад, автоматичне призначення обстеження) без явного підтвердження. Обсяг нагляду пропорційний вазі рішення.

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

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