AI Act w medycynie: ramy prawne dla systemów wysokiego ryzyka

W 2023 roku europejski regulator zatwierdził system AI do wspomagania triage w SOR-ze. Rok później ten sam typ systemu trafił na listę przypadków, w których AI błędnie depriorytetyzowała pacjentów z atypicznymi obrazami klinicznymi. Obie sytuacje są możliwe jednocześnie: AI w medycynie działa i zawodzi — często na tych samych danych, z tych samych powodów. AI Act nie zakazuje tych zastosowań. Określa warunki, pod którymi mogą działać odpowiedzialnie.

AI Act dzieli systemy według potencjalnej szkody, nie według branży. Ale lista systemów wysokiego ryzyka w Załączniku III celuje prosto w ochronę zdrowia:

• pkt 5a: systemy AI przeznaczone do wspomagania decyzji klinicznych (diagnostyka, planowanie leczenia, analiza obrazów medycznych),
• pkt 5b: systemy zarządzające dostępem do opieki zdrowotnej lub alokacją zasobów (priorytetyzacja, triage),
• pkt 5c: systemy monitorowania stanu zdrowia pacjenta w czasie rzeczywistym.

Dla każdego z tych zastosowań obowiązuje pełny pakiet obowiązków wysokiego ryzyka. Chatbot na recepcji szpitala, który tylko informuje o godzinach pracy — ograniczone ryzyko. Ten sam chatbot, który zbiera objawy i sugeruje oddział — wskakuje w pkt 5b i pociąga za sobą dokumentację techniczną, walidację, nadzór ludzki i rejestr incydentów.

AI Act precyzuje obowiązki w Rozdziale III. Dla systemów medycznych sprowadzają się do czterech filarów:

Każdy z tych filarów to nie punkt na checkliście — to wymaganie procesowe. Brak logu oznacza brak możliwości wykazania zgodności w razie kontroli lub zdarzenia niepożądanego.

Najczęstsze pytanie szpitali i klinik brzmi: „jak wyjaśnić lekarzowi, dlaczego AI podjęła taką decyzję?". To pytanie ma teraz wymiar prawny.

Art. 13 AI Act wymaga, żeby systemy wysokiego ryzyka były zaprojektowane tak, aby ich działanie było wystarczająco przejrzyste, by użytkownicy mogli interpretować wyniki i korzystać z nich właściwie. W praktyce oznacza to, że:

• lekarz musi dostać nie tylko wynik, ale uzasadnienie (które cechy obrazu, które parametry kliniczne wpłynęły na decyzję),
• uzasadnienie musi być zrozumiałe dla człowieka bez znajomości architektury modelu,
• system musi informować o limitach pewności — kiedy jego rekomendacja jest mniej wiarygodna.

W naszej pracy z systemami wyjaśnialnymi (XAI) wyróżniamy trzy poziomy: wyjaśnienie lokalne (dlaczego ta decyzja dla tego pacjenta), wyjaśnienie globalne (jak model działa w ogóle) i ślad audytowy (co zrobiło w czasie). AI Act wymaga co najmniej pierwszego i trzeciego. Metodyki takie jak SHAP, LIME czy attention maps to narzędzia implementacyjne — żadna z nich nie jest wymagana z nazwy, ale każda może służyć wykazaniu zgodności.

AI Act i RODO to dwa osobne reżimy, które w medycynie nakładają się niemal całkowicie. Dane pacjenta to dane o stanie zdrowia — kategoria szczególna w rozumieniu art. 9 RODO, wymagająca wyraźnej podstawy prawnej (zgoda lub interes publiczny) i znacznie wyższego poziomu ochrony.

Przy każdym systemie AI operującym na danych medycznych trzeba zadać pytanie o ocenę skutków (DPIA). RODO wymaga jej, gdy przetwarzanie może powodować wysokie ryzyko dla praw osób — a AI decydująca o diagnostyce lub leczeniu spełnia ten próg prawie zawsze.

Kluczowe zasady projektowania warstwy danych w systemach medycznych AI:

• Minimalizacja: model powinien operować na możliwie małym zbiorze danych — nie na pełnej historii choroby, jeśli wystarczy fragment,
• Pseudonimizacja przed treningiem: identyfikatory pacjentów nie mogą znaleźć się w zbiorze treningowym ani w promptach,
• PII maskowanie przed jakimkolwiek wyjściem do zewnętrznych API — dane wrażliwe mogą nie opuszczać infrastruktury szpitala,
• Prawo do usunięcia: jeśli model był trenowany na danych pacjenta, który cofnął zgodę, techniczny sposób wycofania tych danych musi istnieć (machine unlearning lub retrain bez danego podzbioru).

Szpital wdrażający outsourcowany system AI pozostaje administratorem danych — nie przenosi tej odpowiedzialności na dostawcę.

Art. 14 AI Act mówi o nadzorze ludzkim jako o elemencie, który musi być zaprojektowany w systemie — nie dodany jako opcja. W kontekście klinicznym to oznacza konkretną architekturę przepływu pracy:

Lekarz (lub inny uprawniony klinicysta) powinien mieć możliwość:

1. przejrzenia uzasadnienia przed podjęciem decyzji na podstawie rekomendacji AI,
2. odrzucenia rekomendacji bez utraty dostępu do systemu ani bez konieczności podawania powodu,
3. zatrzymania systemu w razie wątpliwości co do jego działania.

W architekturze agentowej (systemy, które wykonują sekwencje akcji, np. planują leczenie, zamawiają badania, aktualizują dokumentację) human-gate — czyli wymagane potwierdzenie człowieka przed każdą nieodwracalną akcją — jest implementacją Art. 14 wprost. System może zaproponować, ale nie może samodzielnie wykonać akcji nieodwracalnej. Mechanizm ten szczegółowo opisujemy w artykule o bezpieczeństwie agentów AI.

To nie ogranicza automatyzacji. Ogranicza ją tam, gdzie błąd może zaszkodzić pacjentowi.

Systemy AI wysokiego ryzyka w medycynie najczęściej są jednocześnie wyrobami medycznymi w rozumieniu rozporządzenia MDR (2017/745) lub In Vitro Diagnostics Regulation (IVDR). Obie regulacje muszą być spełnione łącznie — AI Act nie zastępuje MDR.

Notofikowana jednostka certyfikująca wyrób medyczny musi teraz brać pod uwagę AI Act jako część oceny technicznej. W praktyce:

• dokumentacja techniczna AI (wymagana przez AI Act) trafia do akt certyfikacyjnych MDR,
• plan monitorowania post-market (Art. 72 AI Act) musi być zsynchronizowany z Post-Market Surveillance Plan wymaganym przez MDR,
• rejestr zdarzeń niepożądanych musi być spójny między obydwoma reżimami.

Producenci, którzy już mają certyfikację MDR klasy IIa lub wyższej dla systemu z komponentem AI, powinni traktować AI Act jako rozszerzenie istniejących obowiązków, nie jako nowy, niezależny projekt. Ogólny przegląd obowiązków firm wdrażających AI — poza sektorem medycznym — opisuje artykuł AI Act i RODO w 2026.

Jedna z mniej oczywistych konsekwencji AI Act w medycynie: wymóg, żeby dane treningowe były reprezentatywne i wolne od dyskryminacyjnych uprzedzeń (Art. 10). W praktyce klinicznej to problem, który przemysł znał od lat, ale teraz staje się prawnym obowiązkiem.

Klasyczny przykład: algorytmy predykcji ryzyka sercowo-naczyniowego trenowane głównie na kohortach zachodnich mężczyzn w średnim wieku. Stosowane u kobiet, osób starszych lub z innych grup etnicznych mogą systematycznie niedoszacowywać ryzyko. To błąd statystyczny, ale jeśli prowadzi do opóźnienia leczenia — to zdarzenie niepożądane, za które administrator systemu AI ponosi odpowiedzialność.

Identyfikacja i dokumentacja potencjalnych uprzedzeń to część dokumentacji technicznej. Jeśli zbiór treningowy ma ograniczenia demograficzne, muszą być one jawnie opisane razem z zaleceniami dotyczącymi populacji, dla których system jest walidowany. Narzędzie oceny gotowości do AI pomaga zidentyfikować luki zanim projekt wejdzie w fazę dokumentacji regulacyjnej.

Opisz przypadek użycia systemu AI w kontekście medycznym lub opieki zdrowotnej, a model pomoże wstępnie ocenić kategorię ryzyka wg AI Act, wskazać odpowiednie artykuły i zidentyfikować kluczowe obowiązki. To punkt wyjścia do rozmowy z prawnikiem i podmiotem odpowiedzialnym, nie jej substytut (playground: dane maskowane, zero retencji):

Nie. Chatbot ograniczony do informacji organizacyjnych (godziny, adresy, procedury administracyjne) to system ograniczonego ryzyka. Musi spełnić wymóg transparentności — użytkownik musi wiedzieć, że rozmawia z AI. Granica przesuwa się, gdy chatbot zaczyna zbierać objawy, sugerować rozpoznania lub kierować na oddziały: wtedy wkracza w zakres Załącznika III i staje się systemem wysokiego ryzyka ze wszystkimi wynikającymi z tego obowiązkami.

Obaj. AI Act rozróżnia dostawcę (ten, kto system opracował i wprowadził na rynek) i podmiot wdrażający (szpital, który go używa). Dostawca odpowiada za zgodność techniczną i dokumentację. Podmiot wdrażający odpowiada za właściwe użytkowanie zgodne z instrukcją, nadzór i monitorowanie w warunkach rzeczywistych. Szpital, który kupuje gotowy system, nie zrzuca na dostawcę obowiązków administratora danych wynikających z RODO.

Nie w sensie kliknięcia „OK" przy każdej sugestii — to byłoby niepraktyczne. Wymaga, żeby klinicysta mógł interweniować, odrzucić wynik lub zatrzymać system. W praktyce projektuje się to jako: wynik AI widoczny obok danych klinicznych, możliwość odrzucenia z notatką, blokada wykonania akcji nieodwracalnych (np. automatycznego zlecenia badania) bez jawnego potwierdzenia. Zakres nadzoru proporcjonalny do stawki decyzji.

Może, ale dokumentacja techniczna musi zawierać opis populacji treningowej i jej ograniczeń demograficznych. Jeśli model był walidowany wyłącznie na polskich pacjentach i jest wdrażany w Niemczech, konieczna jest ocena, czy kohorty są wystarczająco podobne. AI Act wymaga, żeby systemy działały poprawnie w przewidywalnych warunkach użytkowania — różnice populacyjne mogą być takim warunkiem ryzyka.

Minimum to: identyfikator sesji (bez PII), wersja modelu, typ rekomendacji, czy klinicysta ją przyjął czy odrzucił, czas odpowiedzi, wskaźnik pewności modelu oraz znacznik czasowy. Przy zdarzeniu niepożądanym rejestr musi umożliwić odtworzenie kontekstu decyzji — bez tego wykazanie, że system działał poprawnie lub że błąd był po stronie użycia, nie modelu, jest niemożliwe. Czas retencji rejestru zgodny z wymogami prawnymi dla dokumentacji medycznej w danym kraju.