Czy AI może podjąć decyzję „za lekarza”? Ramy odpowiedzialności w systemach medycznych

Co w praktyce znaczy, że „AI podejmuje decyzję za lekarza”

Wsparcie decyzji a decyzja zastępcza: kluczowe rozróżnienie

W praktyce klinicznej używa się dwóch pojęć, które często są wrzucane do jednego worka: clinical decision support (wsparcie decyzji) oraz clinical decision making (podejmowanie decyzji). Granica między nimi jest płynna, ale od jej przebiegu zależy, kto faktycznie decyduje o losie pacjenta i kto ponosi odpowiedzialność za wynik leczenia.

System wspierający decyzję to taki, który generuje rekomendację, podpowiedź, ranking opcji, ale nie może samodzielnie wprowadzić zmiany w terapii ani zainicjować interwencji. Lekarz może tę rekomendację przyjąć, zmodyfikować albo zignorować. Typowe przykłady to: sugerowane dawki leków w oparciu o parametry pacjenta, podświetlanie podejrzanych zmian na obrazie radiologicznym, ostrzeżenia o interakcjach lekowych.

System zastępczo podejmujący decyzję działa krok dalej. Nie tylko podpowiada, ale też automatycznie inicjuje określone działanie – np. zleca badanie, blokuje możliwość przepisania danego leku, kieruje pacjenta do określonej ścieżki diagnostycznej. Lekarz może czasem działanie odwołać, ale musi wykonać dodatkową czynność, często połączoną z uzasadnieniem.

Różnica prawna i etyczna polega na tym, że w pierwszym modelu lekarz ma realną swobodę decyzyjną, a w drugim – jego rola przesuwa się w stronę „kontrolera” algorytmu, który raczej reaguje na jego decyzje niż samodzielnie je tworzy. Odpowiedzialność przestaje być wyłącznie kwestią indywidualnego błędu w sztuce, a staje się skutkiem splotu decyzji projektowych, organizacyjnych i klinicznych.

Kiedy AI sugeruje, a kiedy faktycznie narzuca wybór

W dokumentacji technicznej wielu systemów AI deklaruje się, że są „tylko wsparciem” (tool for assisting physicians). Faktyczne działanie oprogramowania i organizacja pracy potrafią jednak sprawić, że rekomendacja staje się de facto rozkazem. Dzieje się tak w szczególności wtedy, gdy system:

• stosuje mechanizmy „hard-stop” – nie pozwala pójść dalej, dopóki lekarz nie zaakceptuje rekomendacji lub jej formalnie nie odrzuci;
• jest powiązany z automatycznym zlecaniem badań lub leków, które wykonują pielęgniarki lub farmaceuci kliniczni bez dodatkowej weryfikacji;
• jest wpisany do obowiązkowych protokołów szpitalnych, a odstępstwo wymaga rozbudowanej procedury i jest źle widziane przez przełożonych;
• jest połączony z systemem rozliczeń z płatnikiem – np. NFZ, ubezpieczycielem – i jego rekomendacje determinują, czy procedura zostanie zapłacona.

W takich warunkach lekarz, nawet jeśli teoretycznie „ma wybór”, w praktyce jest mocno „prowadzony” przez system. Zwiększa to ryzyko tzw. automation bias (ufania maszynie bardziej niż własnemu osądowi) oraz rozmywa odpowiedzialność. Jeśli wszystko działa dobrze, nikt się tym nie przejmuje. Problem pojawia się w chwili zdarzenia niepożądanego – wtedy trzeba odpowiedzieć, czy była to decyzja lekarza, systemu, czy raczej konsekwencja ich połączenia.

Przykłady: triage na SOR i automatyczna analiza obrazów

Dobrym polem do analizy są systemy triage na Szpitalnym Oddziale Ratunkowym (SOR). Algorytm przyjmuje dane wejściowe (objawy, parametry życiowe, wywiad), przypisuje pacjentowi kategorię pilności i sugeruje kolejność przyjęć. Jeśli system tylko podpowiada kolor opaski i kolejność, a pielęgniarka lub lekarz może to łatwo zmienić, mamy wsparcie decyzji. Gdy jednak to algorytm bezpośrednio ustala kolejkę, a personel medyczny działa jedynie w oparciu o gotową listę, dochodzi do sytuacji, w której AI realnie decyduje, kto będzie leczony pierwszy.

Podobnie jest w automatycznej interpretacji badań obrazowych. System może jedynie oznaczać podejrzane obszary i nadawać priorytet opisom (radiolog nadal odpowiada za końcowy opis). Coraz częściej jednak algorytmy wstępnie klasyfikują badania jako „pilne” albo „bez zmian istotnych klinicznie”, co może prowadzić do ich odkładania w czasie. Jeśli taka klasyfikacja jest zintegrowana z systemem pracy pracowni, to w praktyce model decyduje o kolejności diagnostyki, a lekarz opisujący badania ma ograniczoną możliwość wpływu na ten porządek.

W obu przykładach kluczowe pytanie brzmi: czy lekarz ma realną możliwość zatrzymania lub odwrócenia działania algorytmu bez ponoszenia nadmiernych kosztów czasowych, organizacyjnych lub ryzyka sankcji? Jeśli nie – to, jakkolwiek system byłby nazwany w instrukcji obsługi, jego rola w podejmowaniu decyzji zbliża się do roli podmiotu decyzyjnego.

Pojęcie „związania” lekarza rekomendacją systemu

W wielu szpitalach powstają wewnętrzne procedury, które wiążą lekarzy rekomendacjami systemu AI. Zwykle nie jest to opisane wprost jako „obowiązek posłuszeństwa wobec algorytmu”, ale w praktyce skutkuje wymaganiem szczególnego uzasadnienia, gdy lekarz odstępuje od propozycji systemu.

Typowy schemat wygląda tak: system sugeruje terapię A; jeśli lekarz wybiera terapię B, musi w dokumentacji zaznaczyć „odstępstwo od rekomendacji systemu” i uzasadnić je w rozwiniętej notatce. Jednocześnie przy wyborze terapii A żadnego dodatkowego uzasadnienia nie trzeba. W efekcie powstaje asymetria: pójście „za algorytmem” jest łatwe i nie wymaga dodatkowego wysiłku, a decyzja niezależna – przeciwnie.

W praktyce buduje to subtelny mechanizm presji: lekarz wie, że każda decyzja wbrew AI będzie mogła być potem „wyciągnięta” przez przełożonych, ubezpieczyciela lub biegłego sądowego. Nawet jeśli formalnie zachowuje autonomię, koszt korzystania z niej rośnie. Z czasem prowadzi to do ukształtowania się „nowej normy”: decyzje zgodne z algorytmem stają się domyślnym standardem, od którego odstępuje się rzadko i z obawą.

Rolę wzmacniającą odgrywają tu wytyczne wewnętrzne szpitala oraz oczekiwania ubezpieczyciela. Jeśli protokoły kontrolne zakładają, że „prawidłowa ścieżka” to ścieżka rekomendowana przez AI (np. w obszarze badań diagnostycznych lub farmakoterapii), to lekarz ma nie tylko przeszkodę formalną, ale i ryzyko oceny negatywnej przy audycie. W takim środowisku mówienie, że „AI nie decyduje, a tylko rekomenduje”, zaczyna być czysto teoretyczne.

Techniczne mechanizmy przekazywania decyzji

Na poziomie technicznym systemy AI w medycynie łączą się z szpitalnymi systemami HIS, LIS, RIS i e-receptą. To, czy algorytm „tylko doradza”, czy „inicjuje”, zależy od tego, jak głęboko jest wpięty w ten ekosystem. Kilka mechanizmów jest szczególnie wrażliwych z punktu widzenia odpowiedzialności:

• Alerty typu „hard-stop” – blokują możliwość kontynuowania zlecenia, dopóki lekarz nie przyjmie wskazanej opcji lub formalnie nie uzasadni odstępstwa. Przykład: system nie pozwala przepisać antybiotyku bez zlecenia posiewu, bo „tak wynika z modelu predykcyjnego”.
• Automatyczne zlecenia badań lub leków – po spełnieniu określonych warunków (np. zestaw objawów, wynik skali ryzyka) system sam wystawia zlecenie, które trafia do laboratorium lub apteki szpitalnej. Lekarz może je potem zmienić, ale najczęściej proces już się toczy.
• Domyślne ustawienia i szablony – AI generuje domyślny zestaw badań, dawek i zaleceń, który lekarz może edytować. W realiach presji czasu domyślne ustawienia często stają się ustawieniami faktycznymi.
• Integracja z systemem kolejkowym – w SOR, pracowni diagnostycznej czy poradni algorytm ustala priorytety, a personel „tylko” obsługuje kolejkę, choć to właśnie ustawienie priorytetu bywa krytyczną decyzją medyczną.

Granica między decyzją algorytmu a decyzją człowieka przebiega tam, gdzie lekarz ma realny, a nie iluzoryczny wpływ na przebieg zdarzeń. Jeśli zmiana rekomendacji jest prosta, szybka i nie obarczona sankcją – odpowiedzialność pozostaje głównie po stronie lekarza. Jeśli natomiast system narzuca domyślne działania, a ich podważenie wymaga walki z interfejsem i organizacją pracy, odpowiedzialność za wynik staje się współdzielona.

Percepcja pacjenta a stan faktyczny

Dla pacjenta różnica między „lekarz podjął decyzję sam” a „zdecydował algorytm” jest często ogromna – również emocjonalnie. Pojawiają się wypowiedzi typu „leczy mnie komputer” lub „lekarz tylko klika w programie”. Z prawnego punktu widzenia natomiast odpowiedzialny jest nadal lekarz i podmiot leczniczy, a system AI jest narzędziem. Ten dysonans generuje kilka problemów.

Po pierwsze, pacjent może mieć zafałszowane oczekiwania. Jeśli ma wrażenie, że „dostał najnowocześniejszą, obiektywną diagnostykę AI”, może być mniej skłonny akceptować komplikacje, które – jak każde leczenie – pozostają możliwe niezależnie od użytej technologii. Po drugie, w razie sporu prawnego pacjent może wskazywać, że nie został rzetelnie poinformowany o roli algorytmu, ograniczeniach systemu czy alternatywnych sposobach postępowania bez AI.

Wreszcie pojawia się pytanie, jak lekarz powinien komunikować: „System sugeruje X, ale ja uważam, że lepsze będzie Y”. Dla pacjenta bywa to sygnał niepewności („nawet lekarz nie wie, co robić”), choć w rzeczywistości jest to przejaw odpowiedzialnej autonomii klinicznej. Jeśli komunikacja jest nieprzemyślana, sytuacja, w której lekarz odchodzi od rekomendacji AI, może być przez pacjenta odbierana jako „działanie na własną rękę”, a nie jako profesjonalna ocena całości danych.

Ramy prawne AI w medycynie: od MDR do AI Act

Kluczowe akty prawne dotyczące medycznej AI

Systemy AI używane w diagnostyce, terapii czy monitorowaniu stanu zdrowia nie funkcjonują w próżni prawnej. W Unii Europejskiej obejmują je przede wszystkim:

• MDR (Regulation (EU) 2017/745) – rozporządzenie w sprawie wyrobów medycznych,
• IVDR (Regulation (EU) 2017/746) – rozporządzenie w sprawie wyrobów medycznych do diagnostyki in vitro,
• AI Act – Europejski Akt w sprawie Sztucznej Inteligencji (wprowadzający kategorie ryzyka dla systemów SI),
• krajowe regulacje dotyczące udzielania świadczeń zdrowotnych, odpowiedzialności za błąd medyczny i praw pacjenta.

Z perspektywy AI kluczowe jest ustalenie, kiedy oprogramowanie staje się wyrobem medycznym. MDR i IVDR obejmują nie tylko sprzęt fizyczny, ale także software, jeśli spełnia określone kryteria funkcjonalne. Nie ma znaczenia, że „to tylko program” – jeśli jego przeznaczeniem jest diagnozowanie, leczenie lub łagodzenie chorób, to podlega rygorom jak każdy inny wyrób medyczny.

AI Act z kolei klasyfikuje systemy SI według poziomu ryzyka. Systemy stosowane w opiece zdrowotnej, które mogą wpływać na decyzje diagnostyczne lub terapeutyczne, są traktowane jako systemy wysokiego ryzyka. To oznacza dodatkowe wymagania w zakresie zarządzania ryzykiem, jakości danych treningowych, przejrzystości i nadzoru człowieka. W praktyce wiele rozwiązań medycznych AI będzie podlegało jednocześnie MDR/IVDR i AI Act, co stawia wysokie wymagania zarówno producentom, jak i użytkownikom (szpitalom, przychodniom).

Kiedy algorytm staje się wyrobem medycznym

Rozstrzygnięcie, czy dany system AI jest wyrobem medycznym, zależy od jego zamierzonego zastosowania, deklarowanego przez producenta. Kilka przykładów:

• Oprogramowanie, które analizuje obraz TK płuc i zaznacza potencjalne zmiany nowotworowe w celu wsparcia radiologa – to typowy wyrób medyczny (Software as a Medical Device, SaMD).
• Algorytm, który przetwarza dane z EKG i generuje przypuszczalne rozpoznania arytmii – również wyrób medyczny.
• System, który analizuje dane administracyjne i pomaga optymalizować harmonogram wizyt – to raczej narzędzie organizacyjne, nie medyczne (chyba że ma bezpośredni wpływ na decyzje o terapii).
• Aplikacja fitness z prostymi poradami zdrowotnymi bez roszczeń diagnostycznych – zwykle nie jest wyrobem medycznym, o ile nie sugeruje konkretnych interwencji klinicznych.

Granica bywa cienka. Jeśli producent deklaruje, że system służy „wyłącznie do celów informacyjnych”, ale w praktyce jest zintegrowany z dokumentacją medyczną i wpływa na diagnozę, może być traktowany przez organy nadzorcze jak wyrób medyczny. W konsekwencji brak oznakowania CE i niespełnienie wymogów MDR może stać się poważnym ryzykiem prawnym dla szpitala i producenta.

Obowiązki producenta algorytmu w świetle MDR i AI Act

Po uznaniu systemu AI za wyrób medyczny pojawia się zestaw konkretnych obowiązków po stronie producenta. Nie chodzi tylko o jednorazową certyfikację, ale o ciągły proces zarządzania wyrobem. Kluczowe elementy to:

• system zarządzania jakością – dokumentowane procedury projektowania, testowania, wdrażania i aktualizowania algorytmu,
• ocena kliniczna – dowody potwierdzające, że deklarowane działanie i korzyści kliniczne rzeczywiście występują (badania, walidacje, porównania z praktyką standardową),
• ocena ryzyka – identyfikacja sytuacji, w których algorytm może działać błędnie, analizę konsekwencji i mechanizmy ograniczające skutki błędów,
• nadzór po wprowadzeniu do obrotu (post-market surveillance) – zbieranie informacji o incydentach, błędach, nietypowych wynikach i wdrażanie korekt.

AI Act dokłada do tego m.in. wymóg zarządzania danymi: producent ma uzasadnić, skąd pochodzą dane treningowe, jak zapewniono ich reprezentatywność, ograniczono stronniczość i zadbano o odpowiednią jakość. Przy systemach klinicznych pojawia się pytanie o dane rzadkich chorób, mniejszości etnicznych, grup wiekowych, które zwykle są niedoreprezentowane. Jeśli system uczy się głównie na populacji „typowego pacjenta”, to ryzyko błędu diagnozy w mniej typowych przypadkach jest przewidywalne – i powinno być wyraźnie opisane w dokumentacji.

Istotnym wymogiem, który przekłada się na codzienną praktykę, jest także ludzki nadzór. AI Act nie pozwala na pozostawienie systemu medycznego AI w trybie „czarnej skrzynki” bez określenia, jak użytkownik (lekarz, pielęgniarka) może nad nim sprawować kontrolę: rozumieć ostrzeżenia, weryfikować wyniki, wyłączać lub ograniczać algorytm w sytuacjach nadzwyczajnych. Jeśli interfejs utrudnia zakwestionowanie rekomendacji, może to zostać zakwalifikowane jako naruszenie zasady nadzoru człowieka.

Rola podmiotu leczniczego: od wyboru systemu do jego nadzoru

Szpital czy przychodnia nie jest „tylko użytkownikiem” AI. Z perspektywy prawa staje się podmiotem odpowiedzialnym za organizację procesu leczenia. To oznacza kilka poziomów odpowiedzialności za systemy algorytmiczne:

• faza wyboru i zakupu – ocena, czy system posiada wymagane certyfikaty (np. CE jako wyrób medyczny), czy przeznaczenie deklarowane przez producenta odpowiada planowanemu użyciu w danej placówce,
• dostosowanie do lokalnego kontekstu – konfiguracja, integracja z HIS, dostosowanie protokołów i procedur tak, aby algorytm nie „wymuszał” rozwiązań sprzecznych z dobrymi praktykami,
• szkolenie personelu – zapewnienie, że lekarze i pielęgniarki rozumieją, co system robi, jakie ma ograniczenia, kiedy można, a kiedy trzeba od niego odstąpić,
• monitorowanie działania – zbieranie sygnałów o błędach, efektach ubocznych, opóźnieniach diagnostycznych związanych z AI i reagowanie na nie (w tym zgłaszanie incydentów do producenta i organów nadzoru).

Jeśli dyrekcja szpitala wdraża system AI „z pudełka”, traktując go jako zwykły moduł IT, bez analizy wpływu na procesy kliniczne, zwiększa ryzyko, że algorytm zacznie de facto kształtować standard postępowania poza kontrolą rady medycznej czy ordynatorów. W sporze prawnym taka bierność może zostać oceniona jako błąd organizacyjny podmiotu leczniczego.

Zderzenie MDR i AI Act z krajowym prawem medycznym

Rozporządzenia unijne nie zastępują krajowych regulacji dotyczących błędu medycznego, odpowiedzialności cywilnej i karnej lekarza czy zasad udzielania świadczeń. Powstaje zatem układ wielopoziomowy: algorytm jest regulowany jako wyrób medyczny i system SI, natomiast odpowiedzialność za jego użycie jest rozliczana na gruncie krajowego prawa medycznego i cywilnego.

W polskich realiach lekarz odpowiada głównie za dochowanie należytej staranności zgodnie z aktualną wiedzą medyczną. Jeżeli korzysta z certyfikowanego systemu, rekomendowanego przez szpital i powszechnie uznawanego za narzędzie wspierające decyzje, to samo w sobie nie jest naruszeniem staranności. Problem pojawia się, gdy:

• bezrefleksyjnie akceptuje rekomendacje, które są oczywiście sprzeczne z jego wiedzą i obrazem klinicznym pacjenta,
• ignoruje wyraźne ograniczenia wskazane przez producenta (np. stosuje algorytm u grupy pacjentów, dla której nie był przeznaczony),
• nie reaguje na powtarzające się sygnały z praktyki, że system ma istotne braki, a mimo to traktuje jego rekomendacje jako „złoty standard”.

Z kolei dla producenta i szpitala kluczowe jest, czy dołożyli staranności przy wprowadzaniu rozwiązania na rynek i do praktyki klinicznej. Jeśli np. system został w istotny sposób zmodyfikowany lokalnie (dostosowanie progów alarmowych, wyłączenie określonych funkcji bezpieczeństwa), to odpowiedzialność może się przesunąć w stronę podmiotu leczniczego jako „współproducenta” rozwiązania w danej konfiguracji.

Odpowiedzialność lekarza, szpitala i producenta algorytmu – kto za co odpowiada

Trójkąt odpowiedzialności: lekarz – podmiot – producent

W przypadku błędu diagnostycznego czy terapeutycznego przy współudziale AI rzadko mamy do czynienia z jednym prostym „winowajcą”. Częściej dochodzi do nakładania się kilku poziomów odpowiedzialności:

• lekarz – za sposób wykorzystania narzędzia, ocenę wyników i ostateczną decyzję kliniczną,
• podmiot leczniczy – za wybór, wdrożenie i nadzorowanie systemu w strukturze organizacyjnej,
• producent – za jakość, bezpieczeństwo i rzetelność wyrobu medycznego/algorytmu.

Rozkład odpowiedzialności zależy od tego, gdzie doszło do „pęknięcia” procesu. Kilka typowych scenariuszy pokazuje, jak ta logika działa w praktyce.

Sytuacje typowe: błąd algorytmu, błąd użycia, błąd organizacyjny

Można wyróżnić trzy główne kategorie problemów, choć w rzeczywistości często występują łącznie.

1. Błąd algorytmu (produktowy)
Jeśli algorytm działa zgodnie z instrukcją, ale jego model jest wadliwy (np. został przeszkolony na błędnych danych, źle walidowany, ma poważny bias), odpowiedzialność przesuwa się przede wszystkim na producenta jako wytwórcę wyrobu. Warunkiem jest zwykle wykazanie, że:

• lekarz korzystał z systemu zgodnie z przeznaczeniem i zaleceniami,
• podmiot leczniczy nie ingerował w sposób działania algorytmu w sposób mogący spowodować błąd,
• uszkodzenie zdrowia pacjenta wynikało z przewidywalnego błędu systemu.

Przykład: system triażu SOR systematycznie zaniża priorytet pacjentów z określonym zestawem objawów, co po czasie okazuje się skutkiem źle dobranej wagi jednej z cech wejściowych. Jeśli lekarze reagowali adekwatnie na to, co widzieli przy pacjencie, a mimo to kolejka była kształtowana przez błędny algorytm, ciężar odpowiedzialności spoczywa w dużej mierze na producencie (oraz na tych, którzy zbyt łatwo oddali mu kontrolę nad kolejkowaniem).

2. Błąd użycia (ludzki)
Tu system działa poprawnie, ale jest źle używany. Może to być błędne wprowadzenie danych, użycie AI w niewłaściwym kontekście klinicznym, zignorowanie widocznych na ekranie ostrzeżeń. W takim przypadku odpowiedzialność zwykle koncentruje się na lekarzu (lub innym użytkowniku), przy czym analizuje się, czy:

• użytkownik został odpowiednio przeszkolony,
• interfejs był zrozumiały i nie wprowadzał w błąd,
• decyzja sprzeczna z zaleceniami lub oczywista akceptacja absurdalnej rekomendacji była do uniknięcia przy zachowaniu standardowej staranności.

Przykład: lekarz, pod presją czasu, akceptuje dawkę leku sugerowaną przez system, choć jest wyraźnie nieadekwatna do masy ciała i wieku pacjenta, a system dodatkowo wyświetla ostrzeżenie o konieczności korekty – zignorowane. Trudno w takiej sytuacji przerzucać główną odpowiedzialność na producenta.

3. Błąd organizacyjny
Zdarza się, że sam algorytm jest poprawny, lekarze starają się z niego korzystać rozważnie, jednak sposób wkomponowania systemu w strukturę pracy tworzy warunki sprzyjające błędom. To może obejmować:

• narzucenie obowiązku bezwarunkowego używania AI w każdej sytuacji, niezależnie od sensu klinicznego,
• brak alternatywnego trybu pracy „bez AI” w razie awarii lub wątpliwości,
• system ocen pracowniczych czy rozliczeń z płatnikiem, który karze za odstępstwa od zaleceń algorytmu,
• zbyt mało personelu, co praktycznie uniemożliwia lekarzom rzetelną weryfikację rekomendacji.

W takim scenariuszu zarzut może dotyczyć przede wszystkim podmiotu leczniczego: zamiast użyć AI jako narzędzia pomocniczego, przekształcił je w definiujący proces, bez zapewnienia bezpiecznych warunków jego stosowania.

Dowodzenie „błędu AI” w postępowaniu sądowym

Spory z użyciem systemów AI komplikują się także na poziomie dowodowym. Ustalenie, czy to lekarz, szpital czy producent ponosi główną odpowiedzialność, wymaga odpowiedzi na kilka pytań:

• czy zachowały się logi systemu pokazujące, jaka rekomendacja została wygenerowana, o której godzinie, na podstawie jakich danych,
• czy było możliwe ręczne nadpisanie rekomendacji i w jaki sposób zrobiono to (lub zaniechano),
• czy system działał w wersji certyfikowanej, czy też po aktualizacji, która mogła wprowadzić nieprzetestowane zmiany,
• czy lekarz wypełnił swoje obowiązki dokumentacyjne, opisując, dlaczego zaufał AI lub od niej odstąpił.

Bez rzetelnej rejestracji zdarzeń w systemach IT przerzucenie winy na „czarną skrzynkę” będzie znacznie utrudnione. Z perspektywy podmiotów leczniczych i producentów oznacza to konieczność projektowania systemów AI z myślą o audytowalności: możliwość odtworzenia przebiegu zdarzeń jest tu równie ważna, jak dokładność modelu predykcyjnego.

Autonomia lekarza w erze algorytmów: standard staranności a „kliniczny rozsądek”

Standard staranności a „algorytm jako linijka odniesienia”

Standard staranności w medycynie od lat opiera się na koncepcji „rozsądnego lekarza” dysponującego aktualną wiedzą. Wprowadzenie AI zmienia krajobraz: w wielu dziedzinach to algorytm dysponuje statystycznie szerszą bazą przypadków niż pojedynczy klinicysta. Pojawia się pytanie, czy w przyszłości sądy nie zaczną oceniać lekarzy przez pryzmat: „dlaczego nie skorzystał z dostępnej AI?” albo „dlaczego odstąpił od rekomendacji systemu?”

Można przewidywać kilka tendencji:

• tam, gdzie AI staje się powszechnym narzędziem (np. w radiologii), niekorzystanie z niego w ogóle może być oceniane jako uchybienie staranności, jeśli zwiększa ryzyko pomyłki,
• tam, gdzie AI jest narzędziem niszowym lub eksperymentalnym, jego użycie bez odpowiedniego przygotowania może być postrzegane jako nadmierne ryzyko,
• odstępstwo od rekomendacji AI będzie akceptowane, o ile lekarz potrafi je racjonalnie i konkretnie uzasadnić w dokumentacji medycznej.

To ostatnie ma praktyczne znaczenie: wpis w historii choroby typu „odstąpiono od rekomendacji systemu z powodu X, Y, Z” może w przyszłości decydować o ocenie odpowiedzialności. Kliniczny rozsądek nie znika, ale musi być lepiej udokumentowany.

Dokumentowanie decyzji w zgodzie i wbrew AI

Skoro AI generuje ścieżkę domyślną, dokumentacja medyczna przestaje być tylko zapisem „co zrobiono”, a staje się też zapisem „dlaczego nie zrobiono tego, co sugerował algorytm”. W praktyce można wyróżnić trzy kategorie zapisów:

• zgodność z AI – krótkie potwierdzenie, że decyzja pokrywa się z rekomendacją systemu, ale podparte także oceną kliniczną („obraz kliniczny zgodny z sugestią systemu – włączono lek X”),
• świadome odstępstwo – opis powodów: wyjątkowość przypadku, choroby współistniejące, preferencje pacjenta, inne dane nieznane systemowi,

„Pasywne” i „aktywne” zaufanie do AI

Relacja lekarza z systemem AI nie jest zero-jedynkowa. W praktyce widać dwa skrajne wzorce zachowania:

• pasywne zaufanie – lekarz traktuje rekomendację jako domyślne rozwiązanie i szuka głównie potwierdzeń, że „nic mu nie umknęło”,
• aktywne zaufanie krytyczne – system jest jednym z głosów w dyskusji klinicznej; lekarz świadomie weryfikuje założenia modelu na tle konkretnego pacjenta.

Ten drugi model lepiej koresponduje z obowiązującym standardem staranności. Jeżeli lekarz przechodzi automatycznie od „system sugeruje” do „tak zrobimy”, bez krótkiej choćby refleksji, to trudniej obronić tezę o zachowaniu niezależności klinicznej. Minimalny poziom „aktywnego” korzystania oznacza w praktyce:

• sprawdzenie, czy profil pacjenta mieści się w populacji, na której trenowano i walidowano system (wiek, choroby współistniejące, nietypowe leczenie),
• porównanie rekomendacji z aktualnymi wytycznymi towarzystw naukowych i własnym doświadczeniem,
• odnotowanie w dokumentacji, że rekomendacja została przeanalizowana, a nie tylko mechanicznie przyjęta.

Jeżeli system w danym scenariuszu pełni funkcję „drugiej pary oczu” (np. analiza RTG lub EKG), to pasywne zaufanie jest szczególnie ryzykowne: lekarz przestaje faktycznie interpretować obraz, wykonuje jedynie kontrolne „przeklikanie” opisu. Z czasem prowadzi to do erozji umiejętności i przesunięcia faktycznej decyzyjności na algorytm – nawet jeśli formalnie to lekarz podpisuje się pod wynikiem.

Presja organizacyjna a granice autonomii klinicznej

Na decyzje lekarza coraz częściej wpływają nie tylko argumenty medyczne, lecz także konfiguracja systemów szpitalnych i oczekiwania pracodawcy. Pojawiają się sytuacje, w których:

• system rozliczeniowy premiuje zgodność z rekomendacjami AI (np. punktuje „protokółowe” leczenie sepsy generowane przez algorytm),
• menedżerowie traktują odstępstwo od AI jako „nieefektywność” wymagającą wyjaśnień,
• szpital przyjmuje wewnętrzne regulaminy nakazujące obligatoryjne stosowanie określonych ścieżek algorytmicznych.

Z medyczno-prawnego punktu widzenia linia obrony lekarza w ewentualnym sporze nie może się opierać wyłącznie na stwierdzeniu „tak wymagał system”. Jeśli zalecenie stoi w sprzeczności z aktualną wiedzą i zdrowym rozsądkiem, to obowiązkiem lekarza jest wskazanie tego konfliktu – najpierw w rozmowie wewnętrznej, a w razie potrzeby w dokumentacji. Krótkie sformułowania typu „rekomendacja systemu X uznana za nieadekwatną do stanu pacjenta – odstąpiono” sygnalizują, że autonomia kliniczna została faktycznie wykorzystana.

Jeśli presja organizacyjna jest trwała i uniemożliwia podejmowanie niezależnych decyzji, to z czasem pojawia się ryzyko, że odpowiedzialność zacznie przesuwać się z lekarza na organizację. Warunkiem jest jednak, by lekarze sygnalizowali problemy – w przeciwnym razie w postępowaniu sądowym powstaje obraz pełnej zgody personelu na taki model pracy.

Szkolenia z „czytania” AI jako element standardu zawodowego

Wraz z upowszechnianiem się rozwiązań AI rośnie znaczenie kompetencji interpretacyjnych. Coraz mniej chodzi o to, czy lekarz „umie obsłużyć system”, a coraz bardziej o to, czy rozumie jego ograniczenia. Przykładowe obszary, które mogą stać się częścią wymaganego standardu zawodowego:

• rozróżnienie wspomagania decyzji (decision support) od automatyzacji decyzji (decision making),
• podstawy oceny jakości modelu: wrażliwość, swoistość, AUC, a przede wszystkim – granice populacji, dla której te parametry mają sens,
• rozumienie wpływu biasu danych (np. mniejsza reprezentacja określonych grup etnicznych czy wiekowych) na wiarygodność zaleceń w kontekście konkretnego pacjenta.

Jeśli takie elementy staną się częścią programów specjalizacyjnych i szkoleń wewnątrzszpitalnych, to z czasem można oczekiwać, że sądy zaczną pytać: „czy lekarz, korzystając z AI, zachował się tak, jak rozsądny lekarz obeznany z tego typu narzędziami?”. Wtedy ignorowanie oczywistych ograniczeń systemu (np. użycie algorytmu niewalidowanego u dzieci u 5-latka) będzie oceniane ostrzej niż dziś.

Zgoda pacjenta i prawo do informacji przy użyciu AI

Informowanie pacjenta o udziale AI w procesie leczenia

Jeśli system AI istotnie wpływa na proces diagnostyczny lub terapeutyczny, pacjent ma prawo wiedzieć, że jego dane są analizowane przez takie narzędzie. Nie chodzi o techniczny wykład o sieciach neuronowych, lecz o przejrzyste wyjaśnienie kilku punktów:

• jaką rolę pełni AI – czy tylko pomaga w analizie obrazów, czy sugeruje dawki leków, czy też wspiera triaż na izbie przyjęć,
• kto podejmuje ostateczną decyzję – jasno wskazanie, że to lekarz ponosi odpowiedzialność za interpretację rekomendacji,
• jakie dane pacjenta trafiają do systemu i na jakich zasadach są przetwarzane.

Pacjent nie musi znać nazwy algorytmu czy producenta, ale powinien zrozumieć, że w jego przypadku zastosowano narzędzie, które bazuje na analizie dużych zbiorów danych, i że może dojść do sytuacji, w której lekarz podejmie decyzję odmienną od sugestii systemu. Taka informacja wzmacnia zaufanie i urealnia oczekiwania wobec technologii.

Czy pacjent może nie zgodzić się na użycie AI?

Pytanie o dopuszczalność „sprzeciwu wobec AI” wymaga rozróżnienia kilku poziomów wykorzystania systemów:

• AI jako integralna część infrastruktury – np. system PACS z wbudowanymi modułami analitycznymi czy algorytm wspierający filtrowanie alarmów w monitorach. W takim przypadku wyłączenie AI tylko dla jednego pacjenta jest często technicznie niemożliwe lub wiązałoby się z realnym spadkiem bezpieczeństwa. Sprzeciw pacjenta będzie tu trudny do uwzględnienia, podobnie jak sprzeciw wobec stosowania konkretnego rodzaju aparatu RTG.
• AI jako dodatkowe narzędzie decyzyjne – np. system predykcji ryzyka restenozy po zabiegu lub narzędzie dobierające chemioterapię w oparciu o profile molekularne. Tutaj łatwiej wyobrazić sobie scenariusz, w którym pacjent, po uzyskaniu informacji, decyduje się na ścieżkę „bez AI”, o ile lekarz jest w stanie zapewnić porównywalny poziom staranności klasycznymi metodami.
• AI w badaniach klinicznych i projektach pilotażowych – w takich sytuacjach zgoda pacjenta musi być co najmniej tak rozbudowana jak przy typowym badaniu klinicznym, z wyraźnym zaznaczeniem, że narzędzie jest nowe, testowane, a jego zastosowanie ma także charakter ocenny.

Jeżeli użycie AI jest kluczowe dla funkcjonowania danego oddziału (np. radiologia całkowicie oparta o systemy wspomagania opisu), a pacjent nie godzi się na jakąkolwiek analizę jego danych przez te systemy, to w praktyce opcje są dwie: wyjaśnienie zakresu i korzyści oraz – w granicach możliwości – wskazanie innego podmiotu leczniczego, który pracuje bez takich narzędzi. Ostatecznie decyzja o przyjęciu takiego pacjenta w trybie planowym lub o odmowie udzielenia świadczenia z przyczyn organizacyjno-technicznych będzie należeć do podmiotu leczniczego, a nie pojedynczego lekarza.

Zakres informacji w zgodzie na zabieg a wykorzystanie AI

Standardowa zgoda na zabieg obejmuje informację o istocie proponowanego świadczenia, spodziewanych korzyściach, ryzyku i możliwych alternatywach. Gdy ważnym elementem procesu jest AI, do tego pakietu dochodzą dodatkowe wątki. W praktyce treść rozmowy z pacjentem można uporządkować według kilku pytań:

• czy bez AI zabieg w ogóle byłby możliwy lub wykonywany w danym ośrodku (np. procedury wymagające zaawansowanej nawigacji komputerowej),
• jak AI wpływa na profil ryzyka – czy zmniejsza ryzyko określonych powikłań, ale jednocześnie wprowadza nowe kategorie ryzyka (np. awaria systemu, błędna kalibracja),
• czy istnieje realna alternatywa – np. klasyczna operacja bez wsparcia robota, inny schemat leczenia niewymagający algorytmów personalizujących dawki.

Pacjent powinien usłyszeć, w jakim stopniu decyzja terapeutyczna zależy od algorytmu – czy system jedynie proponuje kilka wariantów, spośród których lekarz wybiera, czy też wylicza konkretne parametry (np. margines resekcji, kąt cięcia). Im większy wpływ, tym bardziej szczegółowe wyjaśnienie. Nie chodzi o wyliczenie listy potencjalnych bugów technicznych, lecz o przekazanie, że część procesu jest zautomatyzowana i opiera się na pewnych założeniach statystycznych.

Transparentność wobec pacjenta a „wyjaśnialność” AI

Nowe regulacje, w tym AI Act, kładą nacisk na tzw. wyjaśnialność (explainability) systemów wysokiego ryzyka, do których medyczne AI bez wątpienia należą. W relacji z pacjentem nie oznacza to tłumaczenia zawiłości architektury modelu, lecz odpowiedź na dwa praktyczne pytania:

• dlaczego w tym konkretnym przypadku system zalecił X, a nie Y – w jakim stopniu zaważyły np. wyniki badań obrazowych, wartości laboratoryjne, dane demograficzne,
• na ile lekarz zgadza się z tym uzasadnieniem i jakie własne argumenty do niego dokłada.

Jeśli interfejs systemu umożliwia podgląd kluczowych cech decyzyjnych (np. heatmapy na obrazie TK, ranking istotności zmiennych), lekarz może na ich podstawie wytłumaczyć pacjentowi logikę rekomendacji ludzkim językiem. Gdy algorytm pozostaje zupełnie „nieprzezroczysty”, jedyną wiarygodną podstawą rozmowy stają się wytyczne i doświadczenie lekarza – wtedy AI jest raczej elementem wewnętrznego warsztatu, a nie samodzielnym źródłem informacji dla pacjenta.

Ochrona danych osobowych a trening i doskonalenie algorytmów

Przetwarzanie danych pacjentów w systemach AI ma dwa główne cele: bieżące wsparcie diagnostyczno-terapeutyczne oraz późniejsze doskonalenie modelu (np. re-trening na nowych przypadkach). Z punktu widzenia prawa pacjent ma prawo wiedzieć:

• czy jego dane są używane wyłącznie „operacyjnie”, tj. do obsługi konkretnego procesu leczenia,
• czy też trafią – po odpowiedniej anonimizacji lub pseudonimizacji – do zbiorów służących dalszemu rozwojowi algorytmu.

Jeżeli dane mają być wykorzystane wtórnie, konieczne jest oparcie się na właściwej podstawie prawnej (zgoda, interes publiczny w dziedzinie zdrowia publicznego, badania naukowe). Kluczowe jest także jasne określenie, kto jest administratorem takich danych: szpital, producent algorytmu czy współadministratorzy. W razie szkody wynikającej np. z nieuprawnionego wycieku danych z chmury, kierunek odpowiedzialności będzie zależeć właśnie od tego rozkładu ról oraz zapisów umownych.

Pacjent może zadać proste pytanie: „czy moje dane będą użyte, aby ulepszyć ten system?”. Odpowiedź „tak, ale w formie, która nie pozwoli Pana/Pani zidentyfikować, i podlega to takim samym rygorom ochrony jak cała dokumentacja medyczna” często wystarcza, by utrzymać zaufanie. Warunkiem jest jednak, by taka odpowiedź była zgodna z rzeczywistą praktyką organizacji i producenta.

Najczęściej zadawane pytania (FAQ)

Czy AI może legalnie podjąć decyzję zamiast lekarza?

AI nie ma w polskim prawie statusu „decydującego podmiotu”. Formalnie decyzję medyczną podejmuje osoba posiadająca uprawnienia zawodowe (lekarz, pielęgniarka, ratownik), nawet jeśli w praktyce działa w silnym oparciu o system AI. Algorytm może inicjować działania (np. automatyczne zlecenie badania), ale odpowiedzialność wobec pacjenta i tak przypisywana jest ludziom i organizacji.

Problem pojawia się wtedy, gdy system jest tak zintegrowany z procedurami szpitala, że lekarz ma tylko iluzoryczną możliwość sprzeciwu. Wówczas z punktu widzenia etycznego i organizacyjnego AI staje się faktycznym współdecydującym, choć nie jest tak nazwane w dokumentach prawnych.

Jaka jest różnica między „wsparciem decyzji” a „podejmowaniem decyzji” przez AI?

System wspierający decyzję (clinical decision support) podpowiada: generuje rekomendacje, ostrzeżenia, priorytety badań, ale sam niczego nie zmienia w terapii. Lekarz może łatwo zignorować lub zmodyfikować jego propozycję, bez specjalnych barier formalnych.

System podejmujący decyzję zastępczo nie tylko rekomenduje, lecz także automatycznie uruchamia działanie – np. zleca badanie, blokuje lek, ustala kolejkę pacjentów. Jeśli zmiana decyzji algorytmu wymaga dodatkowych kliknięć, uzasadnień lub ryzykuje konflikt z procedurą szpitalną, to zbliżamy się do modelu, w którym AI współdecyduje, a lekarz pełni rolę kontrolera.

Kto ponosi odpowiedzialność, gdy AI „pomyli się” w diagnostyce lub terapii?

W praktyce odpowiedzialność rozkłada się na kilka poziomów. Lekarz odpowiada za to, w jaki sposób korzysta z systemu (czy krytycznie ocenia rekomendacje, czy reaguje na oczywiste niespójności). Szpital lub podmiot leczniczy odpowiada za wybór i wdrożenie technologii, w tym za procedury, które wiążą personel z decyzjami AI. Producent systemu odpowiada za jego projekt, jakość danych, testy bezpieczeństwa i zgodność z regulacjami wyrobów medycznych.

Spory zaczynają się wtedy, gdy system jest opisany jako „tylko wsparcie”, ale w rzeczywistości narzuca wybór przez tzw. hard‑stopy, automatyczne zlecenia czy powiązanie z rozliczeniami z NFZ. W takich przypadkach trudno mówić o indywidualnym „błędzie w sztuce” lekarza, bo źródłem zdarzenia jest kombinacja decyzji projektowych i organizacyjnych.

Czy lekarz może zignorować rekomendację AI bez konsekwencji prawnych?

Może, ale to zależy od tego, jak skonstruowane są procedury w danym szpitalu. Jeśli oprogramowanie formalnie ma charakter pomocniczy, a protokoły dopuszczają swobodne odstępstwa za klinicznym uzasadnieniem, lekarz zachowuje realną autonomię. W dokumentacji powinien jednak pokazać, że jego decyzja była przemyślana i medycznie uzasadniona.

W wielu placówkach powstaje jednak asymetria: decyzja zgodna z algorytmem nie wymaga dodatkowych wyjaśnień, a decyzja odmienna – tak. To tworzy miękką presję, bo każda „niezgodność z AI” może stać się przedmiotem audytu lub pytania biegłego. Prawnie odstępstwo jest dopuszczalne, ale koszt czasowy i ryzyko kontroli rosną, przez co rekomendacja systemu staje się domyślnym standardem.

Kiedy rekomendacja AI staje się w praktyce „nakazem” dla lekarza?

Dzieje się tak, gdy sposób wdrożenia i integracji systemu ogranicza realną możliwość sprzeciwu. Typowe sytuacje to m.in.:

• alerty typu hard‑stop, które blokują dalsze działania bez akceptacji rekomendacji lub rozwiniętego uzasadnienia odstępstwa,
• automatyczne zlecanie badań i leków, które personel wykonuje bez dodatkowej weryfikacji,
• wpisanie AI do obowiązkowych protokołów, gdzie odstępstwo wiąże się z raportami, dodatkowymi podpisami lub ryzykiem „przycięcia” przy kontroli,
• powiązanie rekomendacji z rozliczeniem z płatnikiem – co system „nie widzi” lub „odradza”, bywa trudniej rozliczalne.

Jeśli lekarz, aby pójść inną drogą niż AI, musi poświęcić znacząco więcej czasu, naraża się na konflikt z przełożonymi albo ryzykuje, że procedura nie zostanie opłacona, to formalna „rekomendacja” staje się praktycznie wymogiem.

Jak działanie AI na SOR czy w radiologii wpływa na odpowiedzialność za błędy?

Na SOR algorytmy triage często ustalają priorytet przyjęcia na podstawie danych wejściowych. Jeśli pielęgniarka lub lekarz jedynie obsługuje listę wygenerowaną przez system, a zmiana priorytetu jest utrudniona, AI faktycznie decyduje, kto będzie leczony pierwszy. W razie opóźnionej pomocy pytanie brzmi: czy zawinił człowiek, czy logika kolejkowania zaszyta w algorytmie i procedurach.

W radiologii podobny problem pojawia się przy automatycznym oznaczaniu badań jako „pilne” lub „bez istotnych zmian”. Jeśli taki podział bezpośrednio wpływa na organizację pracy pracowni, to model kształtuje kolejność diagnostyki. Radiolog może odpowiadać za błędną interpretację obrazu, ale za to, że badanie pojawiło się na jego liście z opóźnieniem – współodpowiedzialne są już system i organizacja.

Jak szpitale mogą ograniczać ryzyko nadmiernego „związania” lekarzy decyzjami AI?

Podstawą jest uczciwe zaprojektowanie ról: jasne określenie, kiedy AI tylko podpowiada, a kiedy inicjuje działania oraz jakie są warunki odstępstwa. Pomagają m.in.:

• procedury, które wymagają uzasadnienia zarówno dla decyzji zgodnej, jak i niezgodnej z AI w sytuacjach wysokiego ryzyka,
• rezygnacja z nieuzasadnionych hard‑stopów i zastąpienie ich miękkimi alertami z opcją łatwego, ale świadomego odrzucenia,
• regularne audyty, czy lekarze faktycznie korzystają z możliwości modyfikacji rekomendacji, czy tylko „klikają dalej”,
• szkolenia z ryzyka automation bias, aby personel nie traktował algorytmu jak „nieomylnego” źródła prawdy.

Im większa przejrzystość tego, jak system wpływa na realny przebieg decyzji, tym łatwiej sensownie podzielić odpowiedzialność między klinicystów, organizację i producenta technologii.

Kluczowe Wnioski

• Kluczowe jest odróżnienie „wsparcia decyzji” (AI tylko rekomenduje) od „decyzji zastępczej” (AI inicjuje działanie, a lekarz jedynie je koryguje), bo od tego zależy realny podział odpowiedzialności za los pacjenta.
• Nawet system formalnie opisany jako „asystujący” może w praktyce narzucać wybór, jeśli stosuje hard‑stopy, automatycznie zleca badania/terapię lub jest wpisany w obowiązkowe protokoły i rozliczenia z płatnikiem.
• W sytuacjach takich jak triage na SOR czy automatyczna klasyfikacja badań obrazowych AI faktycznie decyduje o kolejności leczenia i diagnostyki, jeśli personel nie ma łatwej, szybkiej i bezkarnej ścieżki zmiany decyzji algorytmu.
• O tym, czy AI „podejmuje decyzję za lekarza”, przesądza nie tylko konstrukcja algorytmu, lecz także organizacja pracy – im większy koszt (czasowy, formalny, ryzyko sankcji) ma odstępstwo od rekomendacji, tym silniej lekarz jest z nią związany.
• Procedury wymagające szczegółowego uzasadnienia wyłącznie przy odejściu od rekomendacji AI tworzą asymetrię: podążanie za algorytmem staje się domyślną, „bezpieczną” ścieżką, a decyzja niezależna – wyjątkiem obarczonym dodatkowym ryzykiem.
• Taki układ sprzyja automation bias – lekarze zaczynają ufać systemowi bardziej niż własnemu osądowi, co rozmywa odpowiedzialność między błąd w sztuce a błędy projektowe i organizacyjne w działaniu systemu AI.

Źródła

• Ethics Guidelines for Trustworthy AI. European Commission High-Level Expert Group on Artificial Intelligence (2019) – Ramy etyczne dla systemów AI, w tym w ochronie zdrowia
• Proposal for a Regulation laying down harmonised rules on Artificial Intelligence (Artificial Intelligence Act). European Commission (2021) – Projekt unijnego AI Act, klasyfikacja ryzyka i wymogi dla AI w medycynie
• Regulation (EU) 2017/745 on medical devices (MDR). European Union (2017) – Status oprogramowania jako wyrobu medycznego i obowiązki producenta
• AMA Policy: Augmented Intelligence in Health Care. American Medical Association (2018) – Stanowisko AMA o roli AI jako wsparcia decyzji lekarza
• Clinical Decision Support Systems: State of the Art. Agency for Healthcare Research and Quality (2019) – Przegląd CDS, hard‑stop alerts, wpływ na decyzje kliniczne
• WHO Guidance on Ethics and Governance of Artificial Intelligence for Health. World Health Organization (2021) – Zasady etyczne i odpowiedzialność przy wdrażaniu AI w zdrowiu