Kto odpowiada za błąd sztucznej inteligencji w medycynie przyszłości

Scenka z dyżuru: algorytm się myli, lekarz podpisuje

Krótka historia pacjenta i „nieomylnej” maszyny

Młody lekarz dyżurny, noc, zmęczenie po kilkunastu godzinach pracy. System sztucznej inteligencji do analizy badań obrazowych właśnie zakończył opis serii tomografii pacjenta z urazem głowy – w raporcie brak cech krwawienia śródczaszkowego. Lekarz, polegając na reputacji algorytmu, zatwierdza opis, pacjent trafia na oddział ogólny zamiast na intensywną obserwację.

Następnego dnia stan chorego gwałtownie się pogarsza. Kolejne badanie ujawnia rozległy krwiak, który musiał być widoczny już wcześniej. Rodzina pacjenta zadaje jedno, proste pytanie: kto odpowiada za błąd sztucznej inteligencji w medycynie – lekarz, szpital, producent oprogramowania, a może „system” jako całość?

Na zespół spada fala rozterek: lekarz broni się, że system wspomagania decyzji klinicznych miał dotąd świetne wyniki; szpital wskazuje na producenta oprogramowania medycznego; dostawca powołuje się na klauzule umowy, zgodnie z którymi jego AI tylko wspiera, a nie zastępuje człowieka. Nikt nie przyznaje się do wyłącznej winy, ale pacjent odniósł realną szkodę.

Ten prosty obraz pokazuje, że wdrożenie AI nie rozwiązuje starego problemu błędu medycznego – raczej go rozwarstwia. Zamiast jednego potencjalnego sprawcy pojawia się cała sieć podmiotów, pomiędzy którymi trzeba uczciwie rozłożyć odpowiedzialność: lekarza, podmiotu leczniczego, twórcy algorytmu, integratora systemów i dostawcy chmurowego.

Jak działa AI w medycynie tu i teraz – od gadżetu do „współdecydującego”

Typowe zastosowania kliniczne i organizacyjne

Systemy sztucznej inteligencji w ochronie zdrowia nie są już wyłącznie futurystycznym gadżetem. W coraz większej liczbie szpitali i przychodni AI pojawia się w codziennych procesach: od wstępnej kwalifikacji pacjenta, przez diagnostykę, aż po planowanie zasobów. Dla zrozumienia odpowiedzialności za błąd AI trzeba najpierw odróżnić, jaką rolę pełni algorytm w danym miejscu ścieżki pacjenta.

Można wyróżnić cztery główne grupy zastosowań:

• AI diagnostyczna – analiza obrazów (RTG, TK, MR), interpretacja EKG, wykrywanie arytmii z urządzeń noszonych, klasyfikacja zmian skórnych na zdjęciach.
• AI prognostyczna – modele przewidujące ryzyko powikłań, rehospitalizacji, zaostrzeń chorób przewlekłych, sepsy na OIT.
• AI terapeutyczna – systemy proponujące dawki leków, schematy terapii, ścieżki postępowania w określonych jednostkach chorobowych.
• AI organizacyjna – algorytmy triage w SOR, zarządzanie kolejkami, planowanie bloków operacyjnych, alokacja personelu.

Każda z tych kategorii wiąże się z innym poziomem wpływu na zdrowie pacjenta. Błąd systemu prognozującego obłożenie łóżek SOR będzie miał inne skutki prawne niż pomyłka algorytmu dobierającego dawkę leku przeciwzakrzepowego. Im bardziej decyzja AI dotyka bezpośrednio życia i zdrowia, tym surowsze pytania o odpowiedzialność i konieczność precyzyjnych regulacji.

System doradczy a system autonomiczny

Najważniejsza praktyczna linia podziału przebiega między systemami, które jedynie rekomendują, a tymi, które realnie podejmują działanie bez dodatkowej zgody lekarza. To rozróżnienie ma kluczowe znaczenie przy ocenie, kto odpowiada za błąd AI w medycynie.

System doradczy (advisory) generuje podpowiedź, którą człowiek ma obowiązek ocenić. Przykłady:

• AI opisująca obraz radiologiczny, ale raport końcowy wymaga podpisu radiologa.
• Algorytm EKG wskazujący „podejrzenie zawału STEMI – pilna konsultacja kardiologiczna”, jednak decyzja o interwencji należy do lekarza.
• System rekomendujący antybiotykoterapię, pozostawiający lekarzowi wybór ostatecznego leku.

System autonomiczny (lub półautonomiczny) może natomiast:

• sam zmieniać ustawienia pompy infuzyjnej na podstawie pomiaru glikemii,
• automatycznie kategoryzować pacjentów w triage SOR i przypisywać im priorytety,
• automatycznie zatwierdzać wynik badania jako „bez zmian” bez każdorazowego wglądu lekarza w obraz.

W pierwszym wariancie producent i szpital będą starali się argumentować, że ostateczna odpowiedzialność spoczywa na lekarzu, który przyjął lub odrzucił rekomendację. W drugim – znaczna część ciężaru może przesunąć się w stronę twórcy oprogramowania medycznego oraz podmiotu, który dopuścił taki tryb pracy w swoim środowisku klinicznym.

Im więcej automatyzacji, tym trudniejsze pytania o odpowiedzialność

Wraz z rosnącym poziomem automatyzacji decyzji klinicznych rośnie również ryzyko prawne w telemedycynie i medycynie cyfrowej. Gdy algorytm jedynie sugeruje, łatwiej wskazać lekarza jako ten ostatni „bezpiecznik”. Gdy jednak system samodzielnie kategoryzuje, przepisuje, uruchamia procedury – klasyczne pojęcia winy i należytej staranności lekarza przestają wystarczać.

Pojawiają się wtedy pytania:

• czy lekarz w ogóle miał realną możliwość weryfikacji działania systemu, czy był od niego faktycznie zależny,
• czy szpital zapewnił adekwatne przeszkolenie i procedury „wyłączania” AI w razie wątpliwości,
• czy producent rzetelnie poinformował o ograniczeniach modelu, danych szkoleniowych i obszarach ryzyka.

Im więcej „czarnej skrzynki” w algorytmie, tym większe znaczenie ma solidny łańcuch odpowiedzialności technologicznej i dobrze skonstruowane umowy z dostawcami. Z punktu widzenia pacjenta nie ma znaczenia, kto zawinił – liczy się to, że system opieki zdrowotnej jako całość miał działać bezpiecznie.

Podstawy prawne: z czego wynika odpowiedzialność w ochronie zdrowia

Odpowiedzialność cywilna, karna, zawodowa i dyscyplinarna

Aby zrozumieć odpowiedzialność za błąd AI w medycynie przyszłości, trzeba sięgnąć do fundamentów. W polskim systemie – i szerzej w europejskim – odpowiedzialność w ochronie zdrowia ma kilka równoległych wymiarów:

• odpowiedzialność cywilna – za szkodę wyrządzoną pacjentowi (odszkodowanie, zadośćuczynienie),
• odpowiedzialność karna – za czyny wyczerpujące znamiona przestępstwa (np. narażenie na niebezpieczeństwo, nieumyślne spowodowanie śmierci),
• odpowiedzialność zawodowa – przed izbami lekarskimi, pielęgniarskimi, diagnostycznymi (naruszenie zasad etyki, przepisów wykonywania zawodu),
• odpowiedzialność dyscyplinarna – wobec pracodawcy (np. naruszenie regulaminu pracy, procedur wewnętrznych).

W każdym z tych reżimów kluczowe pozostają klasyczne przesłanki: wina, szkoda, związek przyczynowy. Zmiana polega na tym, że w miejsce typowych narzędzi (stetoskop, aparat USG, klasyczny system RIS/PACS) pojawia się narzędzie szczególnego rodzaju – system AI, którego działania lekarz nie jest w stanie w pełni przewidzieć ani wyjaśnić.

To jednak nie zwalnia nikogo z odpowiedzialności. Przeciwnie – ustawodawca europejski (MDR, nadchodzący AI Act) wyraźnie zmierza do tego, by sztuczna inteligencja była traktowana jako element procesu diagnostyczno-terapeutycznego, otoczony dodatkowymi wymaganiami w zakresie bezpieczeństwa, dokumentacji i nadzoru.

Rola szpitala i przychodni jako organizatora świadczeń

Podmiot leczniczy – szpital, przychodnia, prywatne centrum medyczne – odpowiada nie tylko za działania personelu, ale również za organizację świadczeń i dobór narzędzi, którymi posługują się lekarze. Wprowadzenie systemu AI do pracy klinicznej oznacza, że jest on częścią „aparatury” i procedur, za które odpowiada zarząd podmiotu.

Z perspektywy prawa cywilnego i prawa pracy oznacza to m.in., że:

• pacjent kieruje roszczenia w pierwszej kolejności do podmiotu leczniczego (szpitala), a nie bezpośrednio do pojedynczego lekarza,
• szpital odpowiada za dobór i utrzymanie sprzętu oraz oprogramowania, w tym audyt bezpieczeństwa systemów AI, aktualizacje, testy, nadzór nad ryzykiem,
• szpital ponosi odpowiedzialność za brak lub wadliwość procedur dotyczących korzystania z AI, w tym za niewystarczające przeszkolenie personelu.

Jeżeli szpital wdraża algorytm bez analizy ryzyka, bez jasnych instrukcji klinicznych, bez planu awaryjnego na wypadek awarii lub błędów, trudno zrzucać całą winę na lekarza korzystającego z narzędzia dostarczonego przez pracodawcę. Staje się to szczególnie widoczne, gdy analiza po zdarzeniu wskazuje, że błąd wynikał z wadliwego wdrożenia lub konfiguracji systemu, a nie z jednostkowego zaniedbania medyka.

Kontrakt z pacjentem i obowiązek informacji

Relacja pacjent–podmiot leczniczy ma w prawie charakter umowy o świadczenie usług medycznych. Jednym z jej kluczowych elementów jest zgoda pacjenta – nie tylko na sam zabieg czy terapię, ale też na warunki, w jakich będzie ona realizowana. Pojawia się zatem pytanie: czy pacjent powinien wyrazić zgodę na użycie algorytmu jako części procesu diagnostyczno-terapeutycznego?

Coraz częściej przyjmuje się, że pacjent ma prawo wiedzieć, że:

• jego dane zdrowotne będą przetwarzane przez systemy AI (także w chmurze),
• część decyzji może być wstępnie kształtowana przez algorytmy (np. triage, scoring ryzyka),
• ma prawo zadać pytanie, czy decyzja została zweryfikowana przez człowieka.

Brak takiej informacji może być oceniony jako naruszenie obowiązku informacyjnego i naruszenie praw pacjenta, niezależnie od tego, czy sam błąd AI wystąpił. Z kolei rzetelne poinformowanie pacjenta, odpowiedni zapis w dokumentacji oraz transparentność działania systemów AI mogą zmniejszyć ryzyko sporów i wzmocnić zaufanie do nowoczesnych metod leczenia.

Mini-wniosek: sztuczna inteligencja nie jest dodatkiem do „prawdziwej medycyny”, lecz wchodzi w sam rdzeń procesu. Odpowiedzialność prawna obejmuje więc nie tylko sam wynik algorytmu, ale i sposób, w jaki został on włączony w kontrakt terapeutyczny z pacjentem.

Gdzie w równaniu pojawia się dostawca AI – producent, integrator, chmura

Oprogramowanie jako wyrób medyczny a MDR

Dla rozkładu odpowiedzialności kluczowy jest status prawny algorytmu. Jeżeli spełnia on definicję wyrobu medycznego (zgodnie z rozporządzeniem MDR), staje się przedmiotem rygorystycznych wymagań dotyczących bezpieczeństwa, oceny zgodności, nadzoru po wprowadzeniu do obrotu. Dotyczy to w szczególności systemów wspomagania decyzji klinicznych, które mają wpływ na diagnozę lub leczenie.

W praktyce oznacza to, że:

• producent musi przeprowadzić analizę ryzyka,
• musi udokumentować proces wytwarzania, testów i walidacji,
• musi określić zamierzone zastosowanie i jasno przedstawić ograniczenia systemu,
• musi reagować na działania niepożądane i błędy zgłaszane z rynku.

Jeżeli błąd AI wynika z wady konstrukcyjnej systemu – na przykład algorytm ma systematyczną skłonność do zaniżania ryzyka u określonych grup pacjentów – odpowiedzialność producenta może przybrać formę odpowiedzialności za produkt niebezpieczny. Regulacje UE dotyczące AI w zdrowiu idą w kierunku zwiększania tego typu odpowiedzialności, szczególnie dla systemów wysokiego ryzyka.

Kto jest producentem i jakie to ma skutki

W praktyce rynkowej za „dostawcą AI” często kryje się cały ekosystem:

• start-up rozwijający algorytm uczenia maszynowego,
• koncern technologiczny dostarczający infrastrukturę,
• integrator systemów, który łączy AI z istniejącym HIS, PACS, systemami laboratoryjnymi,
• szpital lub uczelnia medyczna współtworząca model, dostarczając dane treningowe i wiedzę ekspercką,
• dostawca chmury, na której uruchomione są modele i gdzie przetwarzane są dane pacjentów.

Formalnie za producenta wyrobu medycznego zwykle uznaje się podmiot, który występuje na rynku pod własną marką i odpowiada za zgodność z MDR. Jednak w razie szkody pacjent lub podmiot leczniczy może szukać odpowiedzialności także wśród podwykonawców – szczególnie wtedy, gdy ich zaniedbania (np. w zakresie bezpieczeństwa danych, dostępności usług) przyczyniły się do błędu.

Konfiguracja, aktualizacje i „dostrajalnie” modeli – kto za to płaci i kto za to odpowiada

Na etapie sprzedaży wszystko wygląda klarownie: producent dostarcza certyfikowany system, integrator wdraża go w szpitalu, a chmura zapewnia moc obliczeniową. Problemy zaczynają się później – gdy algorytm trzeba „dostroić” do lokalnej populacji pacjentów, nowych protokołów terapeutycznych albo zmieniających się wytycznych towarzystw naukowych.

Systemy AI w medycynie coraz częściej uczą się dalej po wdrożeniu. To kuszące – model „żyje” razem z praktyką kliniczną – ale generuje też nowe punkty sporne:

• kto odpowiada za jakość dodatkowych danych treningowych (szpital, konsorcjum naukowe, producent),
• kto podejmuje decyzję o aktualizacji modelu i jak jest ona dokumentowana,
• kto ocenia, czy nowa wersja algorytmu nadal mieści się w granicach certyfikowanego „zamierzonego zastosowania”.

Jeżeli szpital samodzielnie „przekalibruje” model lub włączy tryb samouczenia bez uzgodnienia z producentem, może stać się de facto współproducentem systemu, z odpowiednimi konsekwencjami prawnymi. Z kolei producent, który bez wyraźnej zgody i walidacji klinicznej wypycha kolejne aktualizacje do chmury, nie może liczyć na to, że wszelką odpowiedzialność przejmie lekarz klikający „zaakceptuj”.

W dobrze skonstruowanych umowach pojawiają się więc mechanizmy:

• formalnego zatwierdzania aktualizacji o istotnym wpływie na praktykę kliniczną,
• obowiązku okresowej rewalidacji działania modelu na lokalnych danych,
• przejrzystego logowania zmian algorytmu (wersjonowanie) i możliwości powrotu do poprzedniej wersji, gdy nowa generuje nieakceptowalne błędy.

Mini-wniosek: odpowiedzialność za błąd rzadko wynika z pojedynczej decyzji. Częściej jest efektem łańcucha małych zaniedbań: od nieudokumentowanej aktualizacji po brak testów po-wdrożeniowych.

Dostawca chmury i bezpieczeństwo danych jako element bezpieczeństwa klinicznego

Awaria klastra chmurowego w środku nocy, brak dostępu do algorytmu triażowego na SOR-ze i kilkugodzinny chaos organizacyjny. Z punktu widzenia pacjenta to po prostu nieskuteczna pomoc medyczna, ale w dokumentach pojawiają się słowa: „przerwa w dostępności usługi chmurowej”.

Gdy AI działa w chmurze, dostawca infrastruktury przestaje być wyłącznie podmiotem przetwarzającym dane w rozumieniu RODO. Jego stabilność, poziom zabezpieczeń i procedury reagowania na incydenty stają się częścią bezpieczeństwa klinicznego. Jeśli przerwa w dostępności uniemożliwia lekarzom podjęcie decyzji diagnostycznej lub weryfikację wyników, łańcuch przyczynowy między awarią IT a szkodą pacjenta staje się realny, a nie hipotetyczny.

W praktyce oznacza to potrzebę:

• powiązania umów chmurowych (SLA) z ryzykiem klinicznym, a nie tylko parametrami technicznymi,
• jasnego określenia, jakie procedury obowiązują w razie awarii (fallback do klasycznej diagnostyki, procedury manualne),
• ustalenia odpowiedzialności odszkodowawczej dostawcy chmury wobec podmiotu leczniczego za szkody pośrednie – w tym roszczenia pacjentów.

Z punktu widzenia pacjenta relacja jest prosta: to szpital ma zapewnić ciągłość i bezpieczeństwo świadczeń. Jednak w tle powinny działać starannie przemyślane mechanizmy przenoszenia części ryzyka kontraktowego na dostawców technologicznych, inaczej „poduszka” finansowa pozostanie po jednej stronie – tej najbliższej pacjentowi.

Współtwórcy algorytmu: uczelnie, konsorcja, partnerzy badawczy

Coraz więcej algorytmów diagnostycznych powstaje we współpracy: klinika onkologii dostarcza dane i wiedzę, politechnika buduje model, start-up pakuje wszystko w produkt, a globalny koncern integruje z chmurą. Gdy po latach ujawni się systemowa wada modelu, każda z tych stron będzie przekonywać, że odpowiada tylko za „swój kawałek”.

Na gruncie prawa kontraktów i odpowiedzialności za produkt takie „rozwarstwienie” odpowiedzialności nie zawsze się utrzyma. Jeżeli uczelnia faktycznie projektowała architekturę modelu i nadzorowała walidację, a jej logo figuruje w materiałach marketingowych, trudno będzie utrzymywać, że pełniła wyłącznie rolę biernego poddostawcy. Podobnie podmiot leczniczy, który współfinansował rozwój algorytmu i wykorzystywał go najpierw w „pilocie badawczym”, a potem w rutynowej praktyce, może stać się adresatem roszczeń nie tylko jako użytkownik, ale i współtwórca narzędzia.

Umowy konsorcyjne i badawczo-rozwojowe powinny więc precyzyjnie rozstrzygać:

• kto jest „właścicielem” algorytmu i kto występuje jako producent wyrobu medycznego,
• jak dzielona jest odpowiedzialność za błędy wynikające z danych treningowych, projektu modelu i wdrożenia klinicznego,
• jakie mechanizmy odszkodowawcze (regresy, ubezpieczenia) działają między partnerami, gdy pacjent dochodzi roszczeń od szpitala.

Bez takich ustaleń odpowiedzialność za błąd AI może „spłynąć” na najbardziej namacalny podmiot – szpital – niezależnie od faktycznego wkładu w powstanie wady.

Lekarz kontra algorytm: kto decyduje i kto odpowiada w praktyce klinicznej

Standard należytej staranności w świecie z algorytmami

Dyżur na internie. Algorytm ocenia ryzyko zatorowości płucnej jako niskie, sugerując odstąpienie od angio-TK. Lekarz, zmęczony po kilkunastu godzinach pracy, decyduje się zaufać systemowi. Dwa dni później pacjent trafia na OIOM z masywnym zatorowo-zakrzepowym powikłaniem.

Ocena zachowania lekarza nadal opiera się na klasycznej kategorii „należytej staranności”. Tyle że ten standard powoli zmienia treść. Jeżeli w danym środowisku medycznym korzystanie z zaawansowanych narzędzi AI staje się powszechne, może się okazać, że lekarz, który je całkowicie ignoruje, postępuje poniżej standardu. Z drugiej strony, ślepe zaufanie do algorytmu – bez krytycznego namysłu i porównania z obrazem klinicznym – może być ocenione równie surowo.

W praktyce biegli sądowi zaczną odpowiadać na nowe pytania:

• czy w danych okolicznościach rozsądny lekarz powinien był zakwestionować rekomendację systemu,
• czy miał dostęp do informacji o ograniczeniach modelu (np. gorsza skuteczność u określonych grup wiekowych),
• czy istniały procedury pozwalające na „przełączenie się” na klasyczną ścieżkę diagnostyczną.

Mini-wniosek: AI nie znosi odpowiedzialności lekarza, ale modyfikuje to, co uznajemy za profesjonalne, staranne działanie. Coraz częściej będzie chodziło nie o to, czy lekarz skorzystał z algorytmu, lecz jak z niego skorzystał.

Obowiązek krytycznej oceny rekomendacji AI

W wielu systemach AI komunikaty są sformatowane tak, by budzić zaufanie: kolorowe wskaźniki, jednoznaczne „zalecane postępowanie”, zielone „OK” przy niskim ryzyku. W realnym świecie lekarz widzi to na ekranie obok listy innych alarmów systemowych i badań do podpisu. Ryzyko „automatowego” potwierdzania decyzji rośnie wykładniczo.

Prawo nie wprowadza formalnego obowiązku niezgadzania się z algorytmem, ale obowiązek krytycznej oceny rekomendacji można wyprowadzić z ogólnych zasad wykonywania zawodu i etyki. Lekarz ma działać niezależnie, kierując się najlepszą wiedzą medyczną i dobrem pacjenta. Algorytm jest jednym ze źródeł informacji, a nie zastępcą procesu myślowego.

W praktyce krytyczna ocena oznacza m.in. że lekarz:

• konfrontuje wynik AI z objawami, wynikiem badania przedmiotowego i wywiadem,
• zwraca uwagę na sytuacje „brzegowe”, w których pacjent nie mieści się w typowym profilu treningowym algorytmu,
• jest gotów odstąpić od rekomendacji systemu i uzasadnić to w dokumentacji.

Jeżeli w dokumentacji znajduje się jedynie lakoniczne „zgodnie z rekomendacją systemu X”, bez śladu własnej oceny, trudno będzie wykazać, że lekarz faktycznie zachował należytą staranność. Z drugiej strony, staranne opisanie przyczyn odstąpienia od rekomendacji AI może być ważnym argumentem obronnym, gdy pacjent kwestionuje przebieg leczenia.

„Overriding” algorytmu i dokumentacja decyzji klinicznych

Scenariusz zderzenia lekarza z algorytmem pojawia się coraz częściej: system triażowy klasyfikuje pacjenta jako „zielonego”, lekarz SOR-u oznacza go jako „pomarańczowy” i przyspiesza diagnostykę. Kilkanaście godzin później okazuje się, że decyzja lekarza uratowała życie. W dokumentacji powinno się znaleźć coś więcej niż tylko zmiana koloru priorytetu.

Można wyróżnić trzy typowe sytuacje:

• lekarz podąża za rekomendacją AI i osiąga dobry wynik kliniczny,
• lekarz podąża za AI i dochodzi do szkody – pojawia się pytanie o zasadność zaufania algorytmowi,
• lekarz „nadpisuje” algorytm (override), a skutek jest pozytywny lub negatywny.

W dwóch ostatnich przypadkach kluczowe staje się uzasadnienie. Jeśli dokumentacja wyjaśnia, dlaczego lekarz odstąpił od rekomendacji (np. nietypowy obraz kliniczny, dodatkowe informacje z wywiadu, obawy co do adekwatności modelu dla danego pacjenta), łatwiej wykazać, że decyzja nie była arbitralna. Jeżeli decyzja była sprzeczna z algorytmem, a uzasadnienie jest merytoryczne, ciężar dowodu w sprawie o błąd może przesunąć się w kierunku producenta lub podmiotu leczniczego (np. brak informacji o ograniczeniach systemu).

Od strony organizacyjnej przydatne są funkcje systemów, które pozwalają:

• oznaczyć, że lekarz odstąpił od rekomendacji AI,
• krótko opisać przyczynę,
• później analizować te sytuacje w ramach audytu jakości (czy overriding był słuszny, czy wynikał z nieufności do systemu, czy z jego realnych ograniczeń).

Taka dokumentacja nie tylko pomaga w ewentualnym sporze sądowym, ale też stanowi cenne źródło wiedzy dla producenta i zespołów klinicznych – wskazuje, gdzie algorytm wymaga korekty lub lepszego opisania swoich granic.

AI jako „drugi czytający” – współodpowiedzialność czy dodatkowa asekuracja?

W diagnostyce obrazowej, patologii czy kardiologii niektóre systemy AI działają jako „drugi czytający”: radiolog opisuje badanie, a algorytm równolegle wskazuje potencjalne zmiany. Na pierwszy rzut oka wygląda to jak dodatkowa asekuracja dla lekarza – jeszcze jedna para „oczu”, która może wychwycić pomyłkę. W praktyce pojawia się pytanie: co, jeśli to właśnie AI się myli, a lekarz zostaje z błędną sugestią pod świadomością, że „system by się tak nie pomylił”.

Z punktu widzenia odpowiedzialności kluczowe jest rozróżnienie dwóch ról:

• AI jako narzędzie wspomagające, którego wnioski lekarz może przyjąć lub odrzucić,
• AI jako faktyczny współdecydent, którego rekomendacje są traktowane jak standard organizacyjny (np. wymagane jest uzasadnienie, gdy lekarz się z nimi nie zgadza).

Im bliżej jesteśmy tego drugiego modelu, tym trudniej argumentować, że lekarz pozostaje jedynym odpowiedzialnym podmiotem za błąd diagnostyczny. Jeżeli szpital w regulaminie wymaga, by lekarz w określonych sytuacjach „co do zasady” podążał za AI lub konsultował każdą rozbieżność z przełożonym, element odpowiedzialności organizacyjnej i technologicznej staje się wyraźny. Błąd przestaje być wyłącznie „błędem oka radiologa”, a zaczyna być także „błędem ścieżki klinicznej opartej na algorytmie”.

Mini-wniosek: modele „drugiego czytającego” nie są tylko bezpiecznym dodatkiem. Jeżeli są mocno wplecione w proces kliniczny, wymagają jasnego opisania ról: kto ma głos decydujący i kiedy wolno (albo trzeba) powiedzieć „nie zgadzam się z AI”.

Presja systemowa: normy, targety i domniemanie winy lekarza

Na oddziale radiologii pojawia się nowy system AI. Oficjalnie ma „odciążyć” zespół i poprawić jakość. Nieoficjalnie normy opisów badań rosną o kilkadziesiąt procent, a czas na pojedyncze badanie się skraca. W takim środowisku oczekiwanie, że lekarz będzie spokojnie analizował każdy alert algorytmu, jest bardziej życzeniowe niż realistyczne.

Gdy błąd AI prowadzi do szkody, analiza przyczyn nie powinna kończyć się na pytaniu, czy lekarz „mógł dokładniej przeczytać wynik”. Trzeba spojrzeć, czy:

• system organizacji pracy nie wymuszał nadmiernego zaufania do AI (nierealne normy, brak czasu na weryfikację),
• kadra zarządzająca nie komunikowała, że „AI przejmuje prostsze przypadki”, a lekarz ma się skupić tylko na „czerwonych alarmach”,
• nie tworzyło się kulturowe domniemanie, że „jeśli AI tak mówi, to na pewno jest dobrze”.

Udział pacjenta w decyzjach wspieranych przez AI

Pacjent kardiologiczny patrzy na ekran, gdzie pielęgniarka pokazuje mu kolorowy wykres: „system ocenił, że ryzyko zawału jest niskie, dlatego nie będziemy robić koronarografii”. Słowo „system” działa jak zaklęcie – rozmowa o alternatywach praktycznie się nie odbywa. Gdy po kilku tygodniach dochodzi do incydentu, pacjent twierdzi, że nikt z nim realnie nie rozmawiał o ryzyku.

Jeżeli AI realnie wpływa na wybór ścieżki diagnostycznej lub terapeutycznej, informacja o tym powinna stać się elementem świadomej zgody pacjenta. Nie chodzi o techniczny wykład o strukturze sieci neuronowych, ale o uczciwe zakomunikowanie kilku faktów: że system jest narzędziem wspierającym lekarza, że ma określone ograniczenia (np. słabsze wyniki w rzadkich chorobach), że ostateczna decyzja należy do człowieka. Pacjent powinien mieć też przestrzeń, by zadać proste pytanie: „a co, jeśli AI się myli?”.

W dokumentacji medycznej coraz częściej będą się pojawiać zapisy w rodzaju: „pacjent poinformowany o zastosowaniu systemu wspomagania decyzji X, o jego roli i ograniczeniach; wyraża zgodę na proponowaną ścieżkę diagnostyczną”. Taki zapis nie przerzuca winy na pacjenta, ale pokazuje, że proces decyzyjny nie był automatyczny, a pacjent nie został zepchnięty do roli biernego obserwatora algorytmu.

Mini-wniosek: im silniej AI wpływa na decyzje, tym bardziej świadoma zgoda musi uwzględniać jej obecność. Pacjent nie ma decydować o technicznych parametrach modelu, ale ma prawo wiedzieć, że to nie „magia systemu”, tylko dodatkowe narzędzie w rękach lekarza.

Szare strefy odpowiedzialności: konsultacje zdalne i AI „na zapleczu”

Teleporada. Lekarz widzi w swoim panelu podsumowanie wygenerowane przez system: sugerowane rozpoznania na podstawie wcześniejszych wizyt, danych z aplikacji pacjenta i krótkiego wywiadu. Po drugiej stronie pacjent zakłada, że „ten lekarz ma dostęp do jakiejś superanalizy”, chociaż sam system działa częściowo u zewnętrznego dostawcy, a część danych przetwarzana jest w chmurze poza szpitalem.

W takich modelach świadczeń AI bywa ukryta – pacjent widzi tylko efekt końcowy, lekarz często również nie wie dokładnie, co dzieje się „pod maską”. Tymczasem to właśnie w tych cienkich warstwach integracji najłatwiej o błędy: niewłaściwe mapowanie danych, błędne przeliczenia ryzyka przy różnych populacjach, automatyczne dopisywanie kodów rozpoznań, które potem żyją własnym życiem w systemie rozliczeniowym i statystycznym.

Odpowiedzialność rozlewa się tu między kilka podmiotów:

• lekarza, który posługuje się danymi z systemu,
• podmiot leczniczy, który wybrał i skonfigurował narzędzie,
• dostawcę AI i ewentualnie integratora, który „pospinał” kilka systemów w całość,
• dostawcę chmury lub infrastruktury, jeśli błąd wynika z warunków technicznych (np. utrata części danych, niezsynchronizowane aktualizacje modeli).

Im bardziej AI staje się usługą „w tle”, tym większe znaczenie ma jasne opisanie przepływu odpowiedzialności w umowach między tymi podmiotami. Z punktu widzenia pacjenta frontem pozostaje zazwyczaj szpital lub przychodnia – to z nimi zawiera umowę o świadczenie zdrowotne i to ich najczęściej będzie pozywał. Ale rzeczywiste źródło błędu może leżeć w warstwie, której pacjent nigdy nie zobaczył.

Mini-wniosek: w modelach zdalnych i hybrydowych, gdzie AI pracuje „na zapleczu”, przejrzystość architektury systemu przestaje być wyłącznie problemem IT. To element zarządzania odpowiedzialnością za błąd medyczny.

Rola regulaminów wewnętrznych i instrukcji korzystania z AI

Ordynator wysyła mail do zespołu: „Od jutra wszystkie EKG przechodzą przez system Y. Proszę o stosowanie się do rekomendacji, odchylenia tylko w uzasadnionych przypadkach”. W załączniku jest krótka instrukcja producenta, ale nikt nie ma czasu przeczytać jej w całości. Po miesiącu pojawia się pierwszy poważny incydent związany z błędną klasyfikacją arytmii.

W takich sytuacjach na pierwszy plan wychodzi jakość regulaminów wewnętrznych. To w nich powinno być jasno określone:

• kiedy korzystanie z AI jest obowiązkowe, a kiedy fakultatywne,
• jaka jest rola AI na danym etapie ścieżki (preselekcja, „drugi czytający”, narzędzie rekomendacyjne, filtr bezpieczeństwa),
• kto zatwierdza konfigurację systemu i zmiany jego parametrów,
• jak wygląda procedura postępowania przy rozbieżności między AI a lekarzem.

Brak takich reguł albo ich czysto „folderowy” charakter sprawia, że odpowiedzialność rozmywa się między jednostkami. Lekarz będzie twierdził, że „system było trzeba stosować”, ordynator – że chodziło o „pomoc przy prostszych przypadkach”, a dział IT – że tylko wdrożył to, co zamówiono. Z punktu widzenia pacjenta to chaos, a z punktu widzenia sądu – dowód na niedostateczną organizację procesu leczenia.

Mini-wniosek: AI wprowadzone „miękko”, bez konkretnych regulaminów i jasnych instrukcji, zwiększa ryzyko sporów. Formalizacja zasad użycia nie jest biurokracją dla biurokracji – to tarcza, gdy szukamy odpowiedzi, kto faktycznie popełnił błąd.

Błędy danych wejściowych: kto odpowiada za „śmieci w systemie”

System predykcji niewydolności oddechowej podbija ryzyko u pacjenta na podstawie błędnie wprowadzonej saturacji sprzed tygodnia. Algorytm działa prawidłowo, tylko dane są złe. Pielęgniarka wpisuje wartości w pośpiechu, lekarz patrzy na wysoki wskaźnik ryzyka i decyduje o przyjęciu na oddział zamiast wypisu do domu.

Większość modeli AI jest równie dobra, jak dane, którymi je karmimy. W tradycyjnej medycynie błąd w dokumentacji dało się czasem wychwycić „na oko” – nie zgadzał się opis z obrazem pacjenta, coś „zgrzytało”. Gdy jednak system opiera się na dziesiątkach parametrów, a część z nich jest zasilana automatycznie z różnych źródeł, błąd pojedynczej wartości może zniknąć w gąszczu liczb, ale jego efekt – wysoka lub niska rekomendacja – będzie brany za dobrą monetę.

Odpowiedzialność za takie błędy jest wielowarstwowa. Na poziomie indywidualnym dotyczy osoby, która wprowadzała dane (np. błędnie odczytała wynik, pomyliła pacjentów, źle opisała próbkę). Na poziomie systemowym – tego, czy proces wprowadzania danych był sensownie zaprojektowany: czy istniały mechanizmy podwójnej weryfikacji krytycznych parametrów, walidacje zakresów wartości, ostrzeżenia przy nietypowych kombinacjach. Wreszcie na poziomie technologicznym – tego, czy producent przewidział odporność modelu na oczywiste błędy (np. saturacja 10% u chodzącego pacjenta).

Mini-wniosek: spory o „błąd AI” często okażą się sporami o błąd danych, które AI dostała. Odpowiedzialność nie zawsze będzie więc ciążyć na twórcy algorytmu – równie często na osobach i instytucjach, które zasilają go informacjami.

Akt o SI, MDR i krajowe regulacje – co to zmienia w odpowiedzialności

Szpital kupuje system klasyfikujący zmiany skórne. Producent chwali się zgodnością z przepisami unijnymi, oznaczeniem CE, „wysoką skutecznością potwierdzoną badaniami”. Dla wielu decydentów administracyjnych to wystarczający argument: skoro produkt „jest zgodny z prawem”, to ryzyko odpowiedzialności wydaje się mniejsze. Tymczasem oznaczenie CE i zgodność z Aktem o SI wyznaczają tylko punkt wyjścia, a nie koniec dyskusji o odpowiedzialności.

Z perspektywy prawa UE systemy AI wykorzystywane w ochronie zdrowia często kwalifikują się jako „wysokiego ryzyka”. Oznacza to m.in. obowiązki producenta dotyczące:

• oceny zgodności i zarządzania ryzykiem,
• jakości danych treningowych (reprezentatywność, usuwanie uprzedzeń),
• transparentności działania na poziomie adekwatnym dla użytkownika zawodowego,
• monitorowania działania systemu po wdrożeniu.

Równolegle, jeżeli AI jest wyrobem medycznym w rozumieniu MDR, dochodzą wymagania dotyczące bezpieczeństwa, wydajności klinicznej i nadzoru po wprowadzeniu na rynek. Z punktu widzenia odpowiedzialności deliktowej i kontraktowej kluczowe jest to, czy producent i podmiot leczniczy faktycznie wypełnili te obowiązki, czy ograniczyli się do formalnego „odhaczenia” pól w dokumentacji.

Jeżeli system działa zgodnie z deklarowaną specyfikacją, a błąd wynika z nieprawidłowego użycia, ciężar odpowiedzialności przesuwa się w stronę lekarza lub szpitala. Jeżeli jednak dochodzi do szkody, a analiza wykazuje np. brak rzetelnych badań walidacyjnych w populacji podobnej do pacjentów danego szpitala, brak aktualizacji modelu mimo istotnych zmian w standardach leczenia, czy zatajenie znanych ograniczeń – rośnie ryzyko odpowiedzialności producenta. W skrajnych przypadkach można mówić również o wadzie produktu w rozumieniu prawa o odpowiedzialności za produkt niebezpieczny.

Mini-wniosek: nowe regulacje unijne nie zdejmuą odpowiedzialności z lekarzy i szpitali, ale dodają kolejną warstwę – odpowiedzialność producenta za jakość i bezpieczeństwo systemu jako produktu. W sporach sądowych coraz częściej będziemy widzieć obok siebie pozwy przeciwko podmiotowi leczniczemu i dostawcy AI.

Dowody w sporach o błąd AI: logi, wersje modeli i „czarna skrzynka”

Po nieudanym leczeniu onkologicznym pacjent pozywa szpital, twierdząc, że przy wyborze schematu terapii „zawiódł algorytm”. Gdy adwokaci proszą o dokumentację z systemu AI, okazuje się, że historię rekomendacji nadpisuje każda kolejna aktualizacja modelu, a logi przechowywane są tylko przez kilkanaście dni. Odtworzenie, co system „myślał” rok wcześniej, jest praktycznie niemożliwe.

Spory związane z AI będą wymagały nowego podejścia do dowodów. Oprócz klasycznej dokumentacji medycznej znaczenia nabiorą:

• logi systemowe pokazujące, jaka była rekomendacja algorytmu w danym momencie,
• informacja o wersji modelu, zestawie parametrów i ewentualnych aktualizacjach,
• dokumentacja konfiguracji lokalnej (np. progi czułości ustalone przez szpital),
• raporty z audytów wewnętrznych i zewnętrznych działania systemu.

Jeżeli te dane nie są gromadzone lub znikają po krótkim czasie, ocena odpowiedzialności zamienia się w zgadywanie. Sąd będzie bazować na ogólnych opisach działania systemu, a nie na tym, jak faktycznie zadziałał w konkretnej sprawie. Taka nieprzejrzystość zwykle działa na niekorzyść podmiotu, który był zobowiązany do właściwej organizacji procesu leczenia – czyli szpitala lub przychodni.

Mini-wniosek: w świecie z AI „dokumentacja medyczna” rozciąga się także na świat informatyczny. Brak logów, historii wersji modeli czy opisów konfiguracji może okazać się poważnym zaniedbaniem w zakresie należytej organizacji leczenia.

Kiedy AI staje się nowym standardem – ryzyko podwójnej odpowiedzialności

Oddział intensywnej terapii. Od dwóch lat działa system prognozujący ryzyko sepsy na podstawie strumieni danych z monitorów i wyników badań. Lekarze przyzwyczaili się, że „jak coś jest źle, to system krzyczy”. Pewnej nocy alert się nie pojawia, lekarz zajęty innym pacjentem nie zauważa subtelnych zmian. Kilka godzin później dochodzi do wstrząsu septycznego.

Jeżeli w danej dziedzinie AI jest już powszechnym narzędziem, trudno będzie bronić lekarza, który całkowicie z niego nie korzysta, gdy wszyscy koledzy z branży stosują takie rozwiązania. Z drugiej strony, gdy AI staje się de facto elementem standardu opieki, rośnie odpowiedzialność tych, którzy ten standard współtworzą: producentów, towarzystw naukowych rekomendujących konkretne systemy, dyrektorów szpitali wdrażających je bez pilotażu i monitoringu.

Może się pojawić swoista „podwójna odpowiedzialność”: za niekorzystanie z AI tam, gdzie jest już uznanym narzędziem (np. w skriningu), oraz za nadmierne poleganie na AI bez krytycznego nadzoru. Linia podziału będzie często przebiegać w ocenie biegłego: czy w danym momencie rozwoju wiedzy medycznej i technologicznej rozsądny lekarz powinien był mieć dostęp do takiego systemu, a jeśli miał – czy wykorzystał go właściwie.

Mini-wniosek: w miarę jak AI wchodzi do standardów postępowania, odpowiedzialność zaczyna się rozkładać na wszystkich współtwórców tych standardów. Błąd nie będzie już tylko „indywidualną pomyłką lekarza”, lecz efektem całego ekosystemu decyzji technologicznych i organizacyjnych.

Najczęściej zadawane pytania (FAQ)

Kto ponosi odpowiedzialność za błąd sztucznej inteligencji w leczeniu pacjenta?

Najczęściej odpowiedzialność nie spada na jedną osobę czy firmę, tylko rozkłada się na kilka podmiotów. W grę wchodzi lekarz, szpital lub przychodnia jako organizator świadczeń oraz producent i dostawcy systemu AI (np. integrator, dostawca chmury).

Z prawnego punktu widzenia pacjent zazwyczaj kieruje roszczenia przede wszystkim do podmiotu leczniczego, bo to on odpowiada za całość organizacji leczenia i za narzędzia, z których korzysta personel. Lekarz odpowiada za sposób użycia systemu (czy krytycznie ocenił podpowiedź), a producent – za wady samego oprogramowania i rzetelne informowanie o jego ograniczeniach.

Czy lekarz zawsze odpowiada za błąd AI w diagnostyce i terapii?

Wyobraźmy sobie lekarza, który o 3:00 w nocy podpisuje opis tomografii przygotowany przez AI. Jeśli system jest tylko doradczy, a lekarz formalnie akceptuje wynik, prawo nadal wymaga od niego samodzielnej oceny – więc ponosi istotną część odpowiedzialności za błąd.

Inaczej wygląda sytuacja, gdy system działa autonomicznie, np. sam zatwierdza wyniki badań „bez zmian” albo zmienia dawkę leku bez każdorazowej zgody lekarza. Wtedy większa część odpowiedzialności może przesunąć się na podmiot leczniczy, który dopuścił taki tryb pracy, oraz na producenta systemu, bo ich decyzje organizacyjne i techniczne wprost wpływają na bezpieczeństwo pacjenta.

Jaką odpowiedzialność ponosi szpital lub przychodnia za wdrożenie AI?

Dyrektor szpitala, który decyduje się na system AI do opisu badań czy triage na SOR, bierze na siebie odpowiedzialność za jego wybór, konfigurację i sposób użycia. Jeśli zabraknie procedur weryfikacji wyników, szkoleń dla personelu czy jasnych zasad „wyłączania” algorytmu, zarzut będzie dotyczył złej organizacji leczenia.

W praktyce oznacza to, że szpital może odpowiadać cywilnie za szkodę pacjenta (odszkodowanie, zadośćuczynienie), a wewnętrznie – rozliczać personel lub dostawców z naruszenia umów i procedur. Dobrze skonstruowane kontrakty z producentem AI i dokumentacja wdrożenia stają się więc nie tyle formalnością, co realną „tarczą” prawną.

Czy producent oprogramowania medycznego z AI może „schować się” za klauzulą, że to tylko narzędzie pomocnicze?

Wielu producentów wpisuje w umowach i instrukcjach, że system AI „jedynie wspiera, a nie zastępuje” lekarza. Takie zastrzeżenie ma znaczenie, ale nie usuwa odpowiedzialności za wady wyrobu medycznego, błędy algorytmu czy niedostateczne informacje o ryzykach.

Jeśli system był źle zaprojektowany, testowany na nieadekwatnej populacji albo producent zataił istotne ograniczenia modelu, nadal może ponosić odpowiedzialność cywilną (a w skrajnych przypadkach także karną). Im bardziej autonomiczne działanie algorytmu, tym trudniej będzie producentowi przekonywać, że cała odpowiedzialność spoczywa na użytkowniku.

Czy pacjent może pozwać „sztuczną inteligencję”, a nie lekarza lub szpital?

Gdy rodzina pacjenta widzi, że to „maszyna się pomyliła”, naturalnym odruchem jest pytanie, czy da się pozwać samą AI. Z prawnego punktu widzenia nie jest to możliwe – pozwanym zawsze będzie człowiek lub podmiot (szpital, firma), który odpowiada za użycie i utrzymanie systemu.

W praktyce pacjent kieruje roszczenie do podmiotu leczniczego, a ten może potem dochodzić regresu od producenta systemu czy ubezpieczyciela. Dla poszkodowanego ważne jest więc udokumentowanie zdarzenia (raporty z systemu, wpisy w dokumentacji), a nie to, jak dokładnie „myślał” algorytm.

Czy poziom automatyzacji AI ma znaczenie dla odpowiedzialności za błąd?

Różnica między systemem, który tylko podpowiada rozpoznanie, a takim, który sam zmienia dawkę leku, jest kluczowa. Im wyższy poziom automatyzacji i im bliżej „twardych” decyzji klinicznych działa system, tym większe pytania o odpowiedzialność producenta i organizatora systemu opieki.

Przy doradczych AI nacisk kładzie się na należytą staranność lekarza – czy wziął pod uwagę objawy, wyniki badań, czy nie zaufał bezkrytycznie algorytmowi. Przy rozwiązaniach autonomicznych ciężar dowodu przesuwa się na to, czy szpital i dostawca zapewnili bezpieczny projekt, testy, nadzór i możliwość interwencji człowieka, gdy system się myli.

Jakie rodzaje odpowiedzialności prawnej wchodzą w grę przy błędzie AI w medycynie?

Po poważnym zdarzeniu z udziałem AI zazwyczaj „odpalają się” równolegle różne tory odpowiedzialności. Po pierwsze – cywilna, czyli roszczenia pacjenta lub rodziny o odszkodowanie i zadośćuczynienie. Po drugie – karna, gdy istnieje podejrzenie narażenia na niebezpieczeństwo albo nieumyślnego spowodowania śmierci.

Do tego dochodzi odpowiedzialność zawodowa przed izbą lekarską czy pielęgniarską (naruszenie zasad etyki, standardów wykonywania zawodu) oraz dyscyplinarna wobec pracodawcy za niewłaściwe korzystanie z narzędzia. Sam fakt użycia AI nie zwalnia z tych reżimów – przeciwnie, jest traktowany jako element procesu medycznego, który także musi spełniać wymogi bezpieczeństwa i należytej staranności.

Opracowano na podstawie

• Regulation (EU) 2017/745 on medical devices (MDR). European Union (2017) – Podstawy prawne klasyfikacji i odpowiedzialności za wyroby medyczne, w tym oprogramowanie
• Proposal for a Regulation laying down harmonised rules on Artificial Intelligence (AI Act). European Commission (2021) – Projekt unijnego AI Act, klasyfikacja systemów wysokiego ryzyka w ochronie zdrowia
• Ethics and governance of artificial intelligence for health. World Health Organization (2021) – Wytyczne WHO dot. etyki, odpowiedzialności i zarządzania AI w medycynie
• Guidance on Qualification and Classification of Software in Regulation (EU) 2017/745 and 2017/746 (MDCG 2019-11). Medical Device Coordination Group (2019) – Wytyczne klasyfikacji oprogramowania medycznego jako wyrobu medycznego
• Artificial Intelligence in Health Care: The Hope, the Hype, the Promise, the Peril. National Academies Press (2019) – Przegląd zastosowań AI w ochronie zdrowia, ryzyka kliniczne i organizacyjne
• Kodeks Etyki Lekarskiej. Naczelna Izba Lekarska (2019) – Zasady odpowiedzialności zawodowej lekarzy, relacja lekarz–technologia
• Ustawa z dnia 6 listopada 2008 r. o prawach pacjenta i Rzeczniku Praw Pacjenta. Sejm Rzeczypospolitej Polskiej (2008) – Podstawy odpowiedzialności cywilnej wobec pacjenta w polskim systemie prawnym