AI w medycynie i diagnostyce: wymagania prawne, ryzyka i odpowiedzialność za błąd

Dlaczego AI w medycynie to nie tylko technologia, ale też prawo i ryzyko

Rosnąca rola sztucznej inteligencji w diagnostyce i terapii

Sztuczna inteligencja w medycynie przestała być eksperymentem z uczelnianego laboratorium. Systemy AI wspierają segregację pacjentów na SOR-ze, analizują zdjęcia RTG i tomografie, prognozują ryzyko zaostrzeń chorób przewlekłych, a nawet sugerują dobór leków w onkologii spersonalizowanej. Dla pacjenta często są „niewidoczne” – widzi lekarza, wynik badania, zalecenia. W tle jednak działają algorytmy, które mają realny wpływ na rozpoznanie, kolejność przyjęcia, terapię i monitorowanie wyników.

Na przykład narzędzie do analizy EKG oparte na sieciach neuronowych może w kilka sekund wykrywać zaburzenia rytmu, których człowiek szybko nie wychwyci. System triage’owy na izbie przyjęć na podstawie kilku parametrów i krótkiego wywiadu przypisuje priorytet koloru czerwonego, żółtego lub zielonego. Algorytm do analizy obrazów dermatologicznych sugeruje „prawdopodobne zmiany złośliwe” i rekomenduje pilną konsultację. Wszystkie te decyzje przekładają się na realne działania medyczne.

Im bardziej medycyna opiera się na AI, tym bardziej staje się to zagadnieniem prawnym, a nie tylko technologicznym. Każda decyzja kliniczna oznacza potencjalne ryzyko szkody, a za każdą szkodą mogą iść roszczenia pacjentów, odpowiedzialność cywilna, a w skrajnych przypadkach – również karna i zawodowa. Ochrona zdrowia to jedna z najsilniej regulowanych branż, a sztuczna inteligencja dodatkowo podnosi poprzeczkę wymogów.

Główne źródła ryzyka w systemach AI dla medycyny

Ryzyko związane z AI w medycynie nie pochodzi tylko z samego „błędu algorytmu”. Źródeł jest kilka, często nakładają się na siebie i kumulują efekt:

• Błędny model lub dane treningowe – algorytm trenowany na niepełnych, stronniczych lub źle opisanych danych może systemowo pomijać pewne grupy pacjentów (np. rzadkie choroby, inne fenotypy, starsze osoby).
• Błędna interpretacja wyniku przez człowieka – lekarz może przecenić wiarygodność wyniku, nie zrozumieć ograniczeń narzędzia lub potraktować sugestię AI jako „wyrok”, a nie wsparcie decyzji.
• Awarie techniczne i integracyjne – problemy z łącznością, błędy w integracji AI z systemem HIS/PACS, niewłaściwe mapowanie danych mogą podawać algorytmowi nie te informacje, które powinien analizować.
• Cyberbezpieczeństwo systemów medycznych – atak na infrastrukturę IT może zablokować dostęp do AI w krytycznym momencie albo – w gorszym scenariuszu – zmanipulować dane wejściowe lub wyjściowe.
• Brak lub niewłaściwe procedury – nawet świetnie zaprojektowany system AI używany bez jasnych zasad, szkoleń i nadzoru człowieka może stać się źródłem chaosu i niekontrolowanych decyzji.

Ryzyka techniczne i kliniczne szybko przeradzają się w ryzyka prawne: roszczenia pacjentów, postępowania przed rzecznikiem odpowiedzialności zawodowej, kontrole organów nadzoru (UODO, URPL, NFZ), audyty wewnętrzne. Dlatego projektowanie AI bez równoległego projektowania zabezpieczeń prawnych to prosta droga do poważnych problemów.

Asymetria zaufania i napięcie między „wsparciem” a „decyzją”

Pacjent obdarza zaufaniem lekarza, nie system AI. Dla niego źródłem decyzji jest człowiek w białym fartuchu. Lekarz natomiast coraz częściej w praktyce opiera się na rekomendacjach systemu: wynikach scoringu ryzyka, sugestiach diagnostycznych, flagach ostrzegawczych. Jeśli lekarz traktuje komunikaty z AI jako bezdyskusyjne, to w praktyce dochodzi do sytuacji, w której decyzję de facto podejmuje algorytm, choć prawnie odpowiada człowiek.

Prawo (zarówno krajowe, jak i unijne – w tym MDR oraz AI Act) zakłada jednak, że systemy AI w medycynie mają co do zasady charakter wsparcia decyzji (clinical decision support systems), a nie autonomicznych decydentów. Lekarz ma zachować nadzór człowieka (human oversight), zrozumieć ograniczenia narzędzia, umieć mu się sprzeciwić. Gdy algorytm sugeruje rozpoznanie, a lekarz widzi kliniczny obraz nie pasujący do tego wyniku, ma obowiązek to dostrzec i zareagować.

Ta asymetria zaufania – pacjent ufa lekarzowi, a lekarz w praktyce często ufa systemowi – tworzy napięcie, które musi być „domknięte” przez jasne regulacje, procedury i dokumentację. Inaczej każda porażka AI może wywołać prawny „spór o winowajcę” między szpitalem, lekarzem i producentem oprogramowania.

Im lepiej zespoły medyczne i zarządy podmiotów leczniczych rozumieją ten układ zależności, tym łatwiej tworzą bezpieczne, przejrzyste modele korzystania z AI, które realnie pomagają, a nie dokładają nerwów i papierologii.

Podstawy prawne stosowania AI w medycynie – od ogółu do szczegółu

Najważniejsze akty prawne regulujące AI w ochronie zdrowia

Wykorzystanie sztucznej inteligencji w medycynie i diagnostyce dotyka kilku warstw regulacyjnych jednocześnie. Nie wystarczy „RODO i MDR”. W praktyce trzeba uwzględnić co najmniej:

• Prawo krajowe, w szczególności:
  • ustawę o działalności leczniczej – określa ramy organizacji świadczeń, odpowiedzialności podmiotu leczniczego, standard organizacyjny;
  • ustawę o prawach pacjenta i Rzeczniku Praw Pacjenta – prawa do informacji, wyrażania zgody, tajemnicy, dokumentacji medycznej;
  • ustawę o zawodach lekarza i lekarza dentysty oraz inne przepisy zawodowe – obowiązek dochowania należytej staranności, aktualnej wiedzy medycznej;
  • kodeks cywilny i karny – ogólne zasady odpowiedzialności.
• Prawo Unii Europejskiej:
  • MDR (Rozporządzenie 2017/745) – regulacje dotyczące wyrobów medycznych, w tym software jako wyrobów medycznych;
  • RODO – ochrona danych osobowych, w tym danych medycznych jako szczególnej kategorii;
  • nadchodzący AI Act – rozporządzenie o sztucznej inteligencji, które klasyfikuje systemy AI w ochronie zdrowia jako „high-risk” i nakłada szczególne obowiązki;
  • przepisy dotyczące cyberbezpieczeństwa (np. NIS2, regulacje sektorowe).

Dodatkowo dochodzą wytyczne organów nadzorczych (np. EDPB w obszarze RODO, Komisji Europejskiej w zakresie AI Act) oraz krajowe rekomendacje towarzystw naukowych i izb lekarskich. Ignorowanie którejkolwiek z tych „warstw” może doprowadzić do sytuacji, w której system technicznie działa, ale jest używany w sposób niezgodny z prawem.

Status prawny AI jako wyrobu medycznego w świetle MDR

Kluczowa kwestia: czy dana aplikacja AI jest wyrobem medycznym w rozumieniu MDR. Jeśli tak, podlega pełnemu reżimowi prawnemu wyrobów medycznych: klasyfikacja, ocena zgodności, znak CE, nadzór po wprowadzeniu do obrotu. Decyduje o tym nie technologia, ale deklarowany cel kliniczny i przewidywane zastosowanie.

Software (w tym AI) będzie zazwyczaj wyrobem medycznym, jeśli jego głównym przeznaczeniem jest m.in.:

• diagnozowanie chorób lub stanów zdrowotnych,
• monitorowanie procesów fizjologicznych,
• planowanie lub wspieranie terapii,
• prognozowanie przebiegu choroby i ryzyka powikłań.

Przykłady:

• System AI do analizy zdjęć RTG klatki piersiowej pod kątem zapalenia płuc – co do zasady wyrób medyczny.
• Chatbot obsługujący rejestrację pacjentów i przypominający o wizycie – najczęściej narzędzie organizacyjne, nie wyrób medyczny.
• Aplikacja licząca BMI i sugerująca ogólne zalecenia zdrowego stylu życia – prawdopodobnie nie wyrób medyczny, o ile nie deklaruje konkretnego zastosowania diagnostycznego lub terapeutycznego.

Dla producenta oznacza to konieczność przejścia pełnego procesu MDR. Dla podmiotu leczniczego – obowiązek sprawdzenia, czy system ma właściwe oznakowanie, dokumentację, instrukcje użycia i czy sposób jego wykorzystania w szpitalu jest spójny z deklarowanym przeznaczeniem.

Narzędzie ogólnego przeznaczenia a wyrób medyczny – cienka granica

Częstym błędem jest traktowanie zaawansowanych, „inteligentnych” narzędzi jako neutralnych technologii IT, podczas gdy ich rzeczywiste użycie ma charakter medyczny. Przykładowo: platforma analityczna, która z założenia była systemem ogólnego przeznaczenia, po integracji z EHR i modułem scoringu ryzyka nagle zaczyna „podpowiadać” rozpoznania lub priorytet przyjęcia. Z punktu widzenia MDR to może już być wyrób medyczny – niezależnie od marketingowych deklaracji dostawcy.

Podmiot leczniczy jako użytkownik profesjonalny wyrobów medycznych ma obowiązek sprawdzić nie tylko formalne oznakowanie CE, ale i realne funkcje systemu po wdrożeniu. Jeśli szpital „doklei” do rozwiązania funkcje o charakterze diagnostycznym lub terapeutycznym, które nie były objęte oceną zgodności, może przejąć na siebie rolę wytwórcy/zmodyfikowanego producenta w rozumieniu MDR.

Dlatego tak ważna jest współpraca działów IT, działu prawnego, kierowników medycznych i inspektora ds. wyrobów medycznych. Wspólnie trzeba ustalić, które narzędzia AI mają status wyrobu medycznego, które są jedynie wsparciem organizacyjnym, a które wymagają dodatkowej analizy i ewentualnego ograniczenia funkcji.

Obowiązki podmiotu leczniczego jako użytkownika systemów AI

Szpital czy przychodnia nie są tylko „klientem” dostawcy AI. W świetle prawa pełnią rolę profesjonalnego użytkownika wyrobów medycznych, co wiąże się z konkretnymi obowiązkami. Należą do nich m.in.:

• zapewnienie, że używane wyroby – w tym software – posiadają ważne oznakowanie CE i są przeznaczone do danego zastosowania klinicznego,
• zapoznanie personelu z instrukcjami użytkowania, ograniczeniami i ostrzeżeniami producenta,
• wprowadzenie wewnętrznych procedur korzystania z systemu AI (kiedy używać, kto zatwierdza decyzje, jak dokumentować wyniki),
• zgłaszanie poważnych incydentów z udziałem wyrobów medycznych do właściwych organów (w Polsce – do URPL),
• monitorowanie działania systemu po wdrożeniu – np. przez analizy jakości, audyty przypadków, zgłaszanie problemów do producenta.

Formalna zgodność z MDR po stronie producenta nie zwalnia podmiotu leczniczego z odpowiedzialności za sposób używania systemu. Jeżeli AI jest stosowane w sposób sprzeczny z instrukcją, bez właściwego nadzoru człowieka lub z pominięciem procedur – to podmiot medyczny bierze na siebie dużą część ryzyka.

Dlaczego zgodność z MDR to dopiero początek

Certyfikat CE oraz dokumentacja MDR są ważnym fundamentem, ale nie gwarantują bezpiecznego, zgodnego z prawem użycia AI w konkretnej placówce. Rzeczywiste środowisko to specyficzni pacjenci, własny system informatyczny, praktyki lekarzy, presja czasu, braki kadrowe. System, który „na papierze” działa świetnie, może w praktyce generować chaos, jeśli zabraknie trzech elementów:

• lokalnych polityk i procedur – np. kto ma dostęp, kiedy stosujemy AI, czy wynik jest obowiązkowo dokumentowany w historii choroby, co robimy przy rozbieżnościach między AI a lekarzem,
• szkoleń i budowania kompetencji – personel musi wiedzieć, jak działa system, jakie ma ograniczenia, jak ocenić jego „sensowność” w danym przypadku,
• ciągłego nadzoru i przeglądów – okresowe audyty przypadków, ocena jakości, analiza incydentów, aktualizacja procedur i oprogramowania.

Podmiot leczniczy, który myśli o AI jako „kolejnym programie IT”, naraża się na spiralę ryzyka. Ten, który traktuje AI jako element procesu klinicznego i uczy zespół mądrze z niego korzystać, zyskuje przewagę: wyższy poziom bezpieczeństwa pacjenta i lepszą pozycję w razie ewentualnego sporu.

AI jako wyrób medyczny – klasyfikacja, certyfikacja i nadzór

Kiedy algorytm staje się wyrobem medycznym

Granica między ogólnym oprogramowaniem a wyrobem medycznym bywa subtelna. Kluczowe są: przewidywane zastosowanie (intended purpose) określone przez wytwórcę oraz funkcje, które realnie wykonuje system po wdrożeniu. Nie wystarczy nazwać produktu „platformą analityczną” czy „narzędziem wspierającym”. Liczy się to, czy ma on służyć do diagnozowania, nadzorowania, leczenia, łagodzenia lub zapobiegania chorobom.

Jeśli AI:

• analizuje dane medyczne (obrazy, wyniki badań, objawy) i generuje wnioski kliniczne (np. sugerowane rozpoznania, klasyfikację wg skali ryzyka),
• wpływa na dobór terapii, dawek leków, zakres badań dodatkowych,

Klasy ryzyka oprogramowania medycznego według MDR

Dla algorytmów AI MDR oznacza nie tylko „tak/nie” co do statusu wyrobu, lecz także przypisanie do odpowiedniej klasy ryzyka (I, IIa, IIb, III). Im wyższa klasa, tym bardziej rygorystyczna ocena kliniczna, testy i nadzór po wprowadzeniu do obrotu.

W praktyce większość systemów AI o realnym wpływie na diagnozę czy leczenie trafi do klasy wyższej niż „zwykły” software administracyjny. Przydatny jest tu załącznik VIII MDR oraz wytyczne MDCG dotyczące software (m.in. MDCG 2019-11). Dla AI mają znaczenie szczególnie zasady związane z:

• wpływem decyzji systemu na los pacjenta – czy wynik AI może doprowadzić do poważnego pogorszenia stanu zdrowia, utraty życia, opóźnienia rozpoznania choroby,
• rolą systemu w procesie klinicznym – czy AI jedynie „fl aguje” przypadki do dalszej analizy, czy też sugeruje konkretną diagnozę lub dawkę leku,
• grupą docelową – pacjenci pediatryczni, onkologiczni, OIT, SOR oznaczają zwykle wyższe ryzyko.

Przykładowo:

• AI do wstępnego sortowania zdjęć RTG pod kątem obecności „jakichkolwiek nieprawidłowości” może zostać zaklasyfikowana niżej (np. IIa), jeśli lekarz zawsze samodzielnie opisuje badanie,
• system wspomagający dobór dawki leku o wąskim indeksie terapeutycznym, bazujący na danych z EHR – wchodzi już w obszar wyższej klasy (IIb lub nawet III), bo błąd może mieć ciężkie konsekwencje.

Znajomość klasy ryzyka nie jest tylko problemem producenta. Od niej zależy, jak bardzo podmiot leczniczy musi „usztywnić” procedury, włączyć dodatkowy nadzór specjalistów czy kontrolę zarządczą. Tam, gdzie ryzyko jest największe, przyda się więcej kontroli niż przy narzędziach o charakterze pomocniczym.

Proces certyfikacji: od prototypu do znaku CE

Dla twórców AI wejście w świat MDR oznacza przejście pełnego cyklu życia wyrobu medycznego. Nie wystarczy „dopracować modelu”. Potrzebne są m.in.:

• system zarządzania jakością (najczęściej wg ISO 13485) – opisujący, jak zespół wytwarza, testuje, aktualizuje i wycofuje oprogramowanie,
• analiza ryzyka klinicznego i technicznego – identyfikacja możliwych błędów algorytmu, błędów integracji z innymi systemami, ryzyka błędnej interpretacji przez użytkownika,
• dane kliniczne – dowody, że AI rzeczywiście robi to, co deklaruje, z akceptowalnym poziomem bezpieczeństwa i skuteczności,
• dokumentacja techniczna – architektura systemu, sposób trenowania modeli, kontrola wersji, procedury monitorowania działania w czasie.

W przypadku klas wyższych niż I w grę wchodzi jednostka notyfikowana (notified body), która weryfikuje dokumentację i procesy. To często najbardziej wymagający etap – ale też moment, który porządkuje rozwój produktu i zmusza do wprowadzenia dyscypliny jakościowej.

Dla szpitala czy przychodni proces certyfikacji jest „niewidoczny”, ale efekt już tak: dokumentacja producenta, deklaracja zgodności, oznakowanie CE, instrukcje, etykiety. Warto je przejrzeć nie tylko pod kątem formalnym, lecz także praktycznym – czy deklarowane przeznaczenie zgadza się z tym, co chcemy robić z narzędziem w codziennej pracy.

Nadzór po wprowadzeniu do obrotu i „żyjące” algorytmy

AI nie jest statycznym urządzeniem. Modele uczą się, są aktualizowane, przenoszone na nowe środowiska IT. MDR i nadchodzący AI Act mocno podkreślają wymóg ciągłego nadzoru po wprowadzeniu do obrotu (post-market surveillance).

Producent powinien zbierać informacje z rynku: zgłoszenia incydentów, reklamacje, wyniki audytów, dane z rejestrów, a także informacje od użytkowników o sytuacjach, w których AI „zachowała się dziwnie”. Na tej podstawie aktualizuje analizę ryzyka i w razie potrzeby – oprogramowanie.

W przypadku algorytmów, które mogą się dynamicznie uczyć (np. na danych lokalnych), wymaga to szczególnej ostrożności. Każda „duża” zmiana mogąca wpłynąć na charakterystykę bezpieczeństwa lub skuteczności wyrobu może wymagać ponownej oceny zgodności. Stąd trend w stronę tzw. locked models, czyli modeli „zamrożonych” po certyfikacji, w których późniejsze aktualizacje są kontrolowane, opisane i śledzone.

Podmiot leczniczy powinien z kolei mieć własne mechanizmy monitorowania: przeglądy przypadków, okresowe porównania wyników AI z decyzjami lekarzy, rejestr incydentów, analizę trendów błędów. Im bardziej świadome raportowanie, tym lepsza pozycja przy ewentualnym sporze – można wykazać, że nadzór był realny, a nie tylko „na papierze”.

Aktualizacje, wersjonowanie i odpowiedzialność za „patchowanie” AI

Software medyczny żyje aktualizacjami. Dla AI to szczególnie wrażliwy punkt – nieostrożna zmiana może radykalnie zmienić charakterystykę działania systemu. Dlatego potrzebne są jasne zasady:

• kto zatwierdza aktualizacje po stronie szpitala (nie tylko IT, ale także przedstawiciele personelu medycznego i bezpieczeństwa informacji),
• jak testowana jest nowa wersja – np. na środowisku testowym, z użyciem zanonimizowanych danych,
• jak dokumentowane są zmiany – release notes od producenta, własne notatki z testów, ewentualne modyfikacje procedur klinicznych.

Jeżeli podmiot leczniczy „samodzielnie” modyfikuje model, łączy go z innym oprogramowaniem w sposób zmieniający przeznaczenie kliniczne albo wyłącza mechanizmy kontroli producenta, może zostać uznany za wytwórcę lub współwytwórcę wyrobu. Wtedy zmienia się rozkład odpowiedzialności – także finansowej.

Rozsądne podejście: każdą poważniejszą aktualizację traktować jak mini-projekt wdrożeniowy. Kilka dodatkowych godzin testów i uzgodnień potrafi oszczędzić tygodnie kłopotów po nieudanym „patchu”.

Rola lekarza i personelu: kto faktycznie podejmuje decyzję i za nią odpowiada

AI jako narzędzie wspomagające, a nie „zastępujące” lekarza

W polskim porządku prawnym decyzje diagnostyczne i terapeutyczne nadal podejmuje człowiek – lekarz, pielęgniarka, ratownik medyczny – działający zgodnie z uprawnieniami zawodowymi. AI może tę decyzję wspierać, ale nie przejmuje odpowiedzialności.

W praktyce oznacza to, że wynik wygenerowany przez system AI jest jednym z elementów materiału dowodowego w procesie klinicznym, obok wywiadu, badań fizykalnych, badań obrazowych, konsultacji. Lekarz ma nie tylko prawo, ale wręcz obowiązek skonfrontować rekomendację AI z całością obrazu klinicznego.

Nie ma obecnie przepisów, które pozwalałyby „zrzucić” odpowiedzialność na system IT czy producenta w sytuacji, w której lekarz bezrefleksyjnie powtarza rekomendację AI. Wręcz przeciwnie – w razie sporu sądowego brak krytycznej oceny może zostać oceniony jako naruszenie należytej staranności.

„Należyta staranność” w erze algorytmów

Pojęcie należytej staranności nie zniknęło wraz z pojawieniem się AI. Zmienia się tylko to, jak jest interpretowane. Coraz częściej będzie się brało pod uwagę, czy:

• personel miał dostęp do narzędzi AI adekwatnych do standardu opieki w danym czasie,
• rozumiał zasady działania systemu i jego ograniczenia,
• wiedział, kiedy odstąpić od rekomendacji AI,
• istniały jasne procedury postępowania w razie rozbieżności między AI a oceną kliniczną.

Możliwa jest sytuacja odwrotna: w pewnych obszarach (np. radiologia) używanie certyfikowanego narzędzia AI stanie się standardem. Wtedy zaniechanie skorzystania z takiego narzędzia w oczywistych sytuacjach może być interpretowane jako brak należytej staranności. To perspektywa kilku najbliższych lat – ale warto się na nią przygotować już teraz.

Dokumentowanie roli AI w procesie diagnostycznym

W kontekście odpowiedzialności kluczowe jest to, co zostanie odnotowane w dokumentacji medycznej. Dobrą praktyką jest, aby:

• wskazać, że użyto konkretnego systemu AI (nazwa, wersja),
• zanotować wynik istotny klinicznie (np. „AI: wysokie prawdopodobieństwo zatorowości płucnej”),
• krótko odnotować, jak lekarz odniósł się do tego wyniku („wynik AI zbieżny z oceną własną; decyzja o…”, albo „wynik AI nieadekwatny do obrazu klinicznego; przyjęto rozpoznanie…”).

Takie wpisy nie tylko ułatwiają kontynuację leczenia, ale też budują „tarczę dowodową” w razie roszczeń. Pokazują, że AI była narzędziem wspierającym, a nie „autopilotem” leczenia.

Szkolenia, uprawnienia i „prawo do odmowy” korzystania z AI

Nie każdy pracownik medyczny musi od razu czuć się pewnie z AI. Stąd istotne są:

• szkolenia wstępne – nie tylko „gdzie kliknąć”, ale też: jak interpretować wyniki, kiedy uważać na bias, co zrobić, gdy system nie działa,
• szkolenia okresowe – przy dużych aktualizacjach, zmianie algorytmu lub rozszerzeniu zakresu stosowania,
• jasne zasady uprawnień – kto może korzystać z AI w jakim zakresie (np. lekarz specjalista vs. rezydent vs. pielęgniarka).

Przy wdrożeniu warto wprost zdefiniować, że lekarz ma prawo odmówić wykorzystania wyniku AI w konkretnym przypadku, jeśli uzna go za nieadekwatny. Kluczem jest jednak uzasadnienie tej decyzji w dokumentacji medycznej. To nie jest bunt wobec technologii, lecz element profesjonalnej autonomii klinicznej.

Rola innych członków zespołu: pielęgniarki, technicy, analitycy

AI wkracza nie tylko w obszar lekarzy. Z systemów korzystają pielęgniarki (np. scoring ryzyka odleżyn), diagności laboratoryjni (automatyczna interpretacja wyników), technicy elektroradiologii (podpowiedzi co do protokołów badań), a nawet pracownicy administracji (triajz zgłoszeń pacjentów).

Warto jasno rozpisać zakres odpowiedzialności:

• kto jest operatorem technicznym systemu – dba o poprawność wprowadzanych danych, obsługę interfejsu,
• kto jest decydentem klinicznym – interpretuje wyniki w kontekście stanu zdrowia,
• kto odpowiada za nadzór administracyjny – aktualizacje, prawa dostępu, zgłaszanie incydentów.

Rozpisanie ról ogranicza ryzyko „rozmycia” odpowiedzialności. Zespół wie, kto za co odpowiada, a w razie problemu łatwiej jest przeanalizować, co poszło nie tak i co poprawić.

Presja systemu vs. autonomia kliniczna

AI potrafi być narzędziem presji: „system tak zalecił”, „benchmark pokazuje, że SOR może przyjąć więcej pacjentów na godzinę”, „algorytm triage ustalił niski priorytet”. W takich warunkach szczególnie łatwo o sytuacje, w których lekarz lub pielęgniarka czują się zmuszeni iść za AI wbrew intuicji klinicznej.

Dlatego przy wdrożeniu AI warto zadbać o kulturę organizacyjną, w której kwestionowanie rekomendacji systemu jest akceptowane, a czasem wręcz oczekiwane. Chodzi o świadome używanie narzędzia, nie ślepe podążanie za „wynikiem komputera”. W dłuższej perspektywie podnosi to zarówno bezpieczeństwo pacjentów, jak i komfort pracy personelu.

Odpowiedzialność cywilna, karna i zawodowa za błąd AI – jak to się rozkłada

Odpowiedzialność cywilna: roszczenia pacjentów i ubezpieczyciele

Z punktu widzenia pacjenta liczy się przede wszystkim to, czy w razie szkody zdrowotnej może domagać się odszkodowania i od kogo. W tle toczy się gra między trzema głównymi podmiotami: lekarzem, podmiotem leczniczym i producentem systemu AI.

Najczęściej pacjent kieruje roszczenia do podmiotu leczniczego (szpitala, przychodni) jako organizatora udzielania świadczeń zdrowotnych. Ten z kolei jest zwykle objęty ubezpieczeniem OC. Ubezpieczyciel analizuje, czy doszło do błędu medycznego (naruszenie należytej staranności), błędu organizacyjnego, czy awarii/usterki wyrobu medycznego.

W razie wykazania, że szkoda wynika z wadliwego działania wyrobu medycznego, podmiot leczniczy – po zaspokojeniu roszczeń pacjenta – może dochodzić roszczeń regresowych od producenta. To jednak wymaga solidnego materiału dowodowego: dokumentacji, logów systemowych, potwierdzenia, że AI była używana zgodnie z instrukcją.

Najważniejsze wnioski

• AI w medycynie realnie wpływa na decyzje kliniczne – od triage’u na SOR-ze, przez analizę EKG czy RTG, po dobór terapii onkologicznej – więc nie jest dodatkiem technologicznym, lecz elementem procesu leczenia z pełnym ciężarem ryzyka.
• Źródłem zagrożeń nie jest wyłącznie „błąd algorytmu”; równie groźne są złej jakości dane treningowe, błędna interpretacja wyniku przez lekarza, awarie integracji z systemami szpitalnymi, ataki cybernetyczne oraz brak przemyślanych procedur użycia.
• Techniczne i kliniczne potknięcia AI bardzo szybko przekładają się na konsekwencje prawne: roszczenia pacjentów, odpowiedzialność zawodową lekarzy, kontrole UODO/URPL/NFZ oraz wewnętrzne audyty, które mogą sparaliżować organizację.
• Pacjent ufa lekarzowi, a lekarz coraz częściej ufa systemowi – jeśli komunikaty AI są traktowane jak niepodważalny wyrok, faktycznym decydentem staje się algorytm, choć pełną odpowiedzialność ponosi człowiek w białym fartuchu.
• Prawo krajowe i unijne (w tym MDR, RODO i nadchodzący AI Act) zakłada, że AI w ochronie zdrowia ma charakter wsparcia decyzji, a nie autonomicznego decydenta – lekarz musi zachować nadzór człowieka, rozumieć ograniczenia narzędzia i umieć mu się sprzeciwić.
• Bez jasnych regulaminów, instrukcji, szkoleń i dokumentowania sposobu korzystania z AI każda pomyłka przeradza się w spór o winę między szpitalem, lekarzem i producentem oprogramowania, zamiast w spokojną analizę i poprawę procesu.