Dlaczego odpowiedzialność za błąd algorytmu to nie akademicka ciekawostka
Cyfrowe zdrowie weszło do prawdziwych procesów leczenia
Aplikacje zdrowotne przestały być tylko gadżetem do liczenia kroków. Coraz częściej uczestniczą w realnych procesach diagnostycznych, terapeutycznych i profilaktycznych. Algorytmy sztucznej inteligencji podpowiadają lekarzom rozpoznania, szacują ryzyko powikłań, a chatboty objawowe układają wstępne ścieżki postępowania dla pacjentów. W telemedycynie i digital health granica między „informacją ogólną” a „rekomendacją medyczną” jest bardzo cienka.
To oznacza, że błąd algorytmu przestaje być czysto technicznym problemem programisty, a zaczyna być realnym zdarzeniem medycznym. Gdy aplikacja sugeruje, że objawy nie wymagają pilnej konsultacji, a w rzeczywistości zwiastują stan nagły, skutki mogą być tak samo poważne, jak przy klasycznym błędzie lekarza. Ktoś podejmuje decyzję na podstawie informacji lub rekomendacji systemu – i to uruchamia całą machinę prawną.
Do tego dochodzi efekt skali: jeśli klasyczny błąd popełnia jeden lekarz na dyżurze, to błąd algorytmu może dotknąć setki, a nawet tysiące użytkowników w krótkim czasie. Jeden wadliwy update aplikacji może zmienić profil ryzyka dla całej populacji korzystającej z danego rozwiązania. Tak rodzi się nie tylko problem odpowiedzialności za konkretne szkody, ale także pytanie o zaufanie do całego ekosystemu e‑zdrowia.
Dwa krótkie przykłady z praktyki cyfrowego zdrowia
Pierwsza sytuacja: chatbot objawowy dostępny w aplikacji zdrowotnej. Pacjent opisuje ból w klatce piersiowej, duszność i osłabienie. Ze względu na konstrukcję pytań i zbyt „optymistyczny” model ryzyka, chatbot uznaje, że to najpewniej niestrawność i zaleca obserwację w domu. Pacjent nie wzywa pomocy, dochodzi do zawału z powikłaniami. Na stole pojawia się pytanie: czy zawinił producent aplikacji, operator systemu, lekarz nadzorujący treści, a może pacjent, który „zaufał aplikacji zamiast zdrowemu rozsądkowi”?
Druga sytuacja: aplikacja do zdalnego monitorowania glikemii integrowana z glukometrem. Algorytm analizuje ciągi pomiarów i sugeruje modyfikacje dawki insuliny, ale źle radzi sobie z rzadkimi wzorcami danych. W efekcie kilku użytkowników otrzymuje rekomendacje, które sprzyjają hipoglikemii. U jednego z pacjentów dochodzi do poważnego incydentu. Pojawia się problem: czy odpowiedzialność spoczywa na producentach sprzętu, twórcach oprogramowania, lekarzu prowadzącym, który „autoryzował” korzystanie z aplikacji, czy na samym pacjencie wprowadzającym dane?
Takie przypadki – a w praktyce bywają o wiele bardziej złożone – pokazują, że nie wystarczy schemat: lekarz popełnił błąd, pacjent poniósł szkodę. W łańcuchu pojawiają się nowe ogniwa: data scientist, dostawca chmury, integrator systemów, product owner, a także regulacje unijne dotyczące wyrobów medycznych i sztucznej inteligencji.
Skutki błędów algorytmów dla zdrowia i systemu ochrony zdrowia
Najbardziej widoczny skutek to oczywiście szkoda na zdrowiu konkretnego pacjenta: opóźniona diagnoza, źle dobrane leczenie, brak skierowania do szpitala w porę. Czasem skutkiem będzie „tylko” wydłużone cierpienie czy dłuższa niezdolność do pracy, ale w najcięższych przypadkach mówimy o trwałym uszczerbku na zdrowiu lub zgonie. Z prawnego punktu widzenia każde z tych zdarzeń może generować roszczenia odszkodowawcze.
Druga warstwa to utrata zaufania. Jeśli nagłośnione zostaną przypadki błędnych rekomendacji aplikacji zdrowotnych, pacjenci zaczną unikać także rozwiązań, które działają prawidłowo. Lekarze będą obawiać się korzystania z narzędzi AI, bo „nie wiadomo, kto za to odpowie”. Organizacje ochrony zdrowia zaczną blokować wdrożenia innowacji z obawy przed lawiną pozwów. Paradoksalnie więc brak jasności co do odpowiedzialności może hamować rozwój nawet bardzo wartościowych technologii.
Wreszcie, błędy algorytmów w ochronie zdrowia generują spory sądowe, w których tradycyjne kategorie – błąd w sztuce, staranność lekarza, wina podmiotu leczniczego – mieszają się z zagadnieniami prawa nowych technologii: wadliwością oprogramowania, odpowiedzialnością za produkt niebezpieczny, ochroną danych czy odpowiedzialnością za wadliwy system wysokiego ryzyka w rozumieniu AI Act. Im więcej stron sporu, tym trudniej o jednoznaczne rozstrzygnięcie, a to kolejny czynnik niepewności.
Dlaczego schemat „lekarz – pacjent” już nie wystarcza
Klasyczny model odpowiedzialności w medycynie zakłada, że to lekarz diagnozuje, leczy i odpowiada za swoje decyzje, a podmiot leczniczy odpowiada za organizację i sprzęt. W cyfrowym zdrowiu decyzje często powstają na styku kilku warstw: danych zbieranych przez urządzenia, algorytmu przetwarzającego te dane, interfejsu prezentującego wnioski, oraz człowieka – pacjenta lub lekarza – który na tej podstawie działa.
Nie da się zadowolić prostym stwierdzeniem, że „algorytm to tylko narzędzie, a lekarz i tak odpowiada za wszystko”. Po pierwsze, nie wszystkie aplikacje zdrowotne są używane przez lekarzy – wiele działa w relacji bezpośrednio z pacjentem. Po drugie, przy systemach złożonych z dziesiątek modułów trudno oczekiwać, że lekarz będzie w stanie zweryfikować każdy element logiki działania. Po trzecie, prawo unijne – MDR i AI Act – wprowadza odrębną odpowiedzialność po stronie producenta systemu, który projektuje, wytwarza i utrzymuje narzędzie wysokiego ryzyka.
Dlatego punkt wyjścia do rozmowy o odpowiedzialności za błąd algorytmu musi obejmować cały łańcuch wartości: od etapu projektowania i trenowania modelu, przez wdrożenie w środowisku klinicznym, aż po codzienne używanie przez lekarzy i pacjentów. Każde z tych ogniw może generować inną podstawę prawną odpowiedzialności i inne obowiązki dowodowe.
Co to znaczy „błąd algorytmu” i „błędna rekomendacja” w cyfrowym zdrowiu
Bug techniczny, błąd projektowy, błąd uczenia, błąd danych wejściowych
Pod pojęciem „błąd algorytmu” kryje się kilka bardzo różnych zjawisk. Z prawnego punktu widzenia ich rozróżnienie jest kluczowe, bo wskazuje, czy mamy do czynienia z wadą produktu, wadą procesu, czy może niewłaściwym użyciem narzędzia przez użytkownika.
Bug techniczny (błąd programistyczny) to klasyczna usterka w kodzie: literówka, zły operator, pomyłka w warunku logicznym. Algorytm „wie, co powinien robić”, ale kod sprawia, że robi coś innego. Jeżeli bug techniczny prowadzi do błędnej interpretacji danych pacjenta, łatwo wykazać wadę wykonania produktu. Wówczas odpowiedzialność producenta oprogramowania (lub innego podmiotu z łańcucha wytwórczego) jest mocno zbliżona do odpowiedzialności za wadliwy sprzęt medyczny.
Błąd projektowy wynika z założeń przyjętych przy projektowaniu algorytmu. Może chodzić o zbyt uproszczony model ryzyka, nieuwzględnienie istotnych zmiennych klinicznych albo przyjęcie błędnej logiki decyzyjnej. Algorytm działa „zgodnie z projektem”, ale sam projekt jest wadliwy. Tu odpowiedzialność przesuwa się w stronę podmiotu, który określił wymagania funkcjonalne i zaakceptował architekturę systemu.
Błąd uczenia modelu (dla AI/ML) wynika z jakości i reprezentatywności danych treningowych, doboru hiperparametrów, nadmiernego dopasowania do konkretnej populacji (overfitting) lub braku walidacji na odpowiedniej grupie. Model może działać świetnie dla populacji, na której był trenowany, ale bardzo źle dla innych grup (np. ze względu na wiek, płeć, pochodzenie etniczne). To prowadzi do pytania o nadzór nad procesem uczenia oraz o to, kto odpowiada za dobór danych treningowych.
Błąd danych wejściowych (data quality) to z kolei sytuacja, w której dane wprowadzane do systemu są błędne, niekompletne lub sprzeczne. Przykład: pacjent źle wpisuje dawki leków, pomiar z urządzenia jest zakłócony, a lekarz nie aktualizuje istotnej informacji w systemie. Algorytm liczy poprawnie – tylko bazuje na fałszywych przesłankach. Tu w grę wchodzi współodpowiedzialność pacjenta lub personelu oraz pytanie, czy producent dołożył starań, by takie błędy wychwytywać (walidacja danych, alerty, mechanizmy sanity check).
Rekomendacja medyczna a czysta informacja edukacyjna
Nie każda treść wygenerowana przez aplikację zdrowotną jest od razu „rekomendacją medyczną” w sensie prawnym. Granica przebiega mniej więcej tam, gdzie system zaczyna sugerować konkretne decyzje dotyczące zdrowia, a nie tylko dostarcza ogólnych informacji.
Aplikacja, która wyświetla artykuły o zdrowym stylu życia, nie prowadzi wywiadu, nie analizuje indywidualnego przypadku i nie sugeruje zmian leczenia, mieści się raczej w obszarze edukacji lub wellbeing. Co innego system, który po wprowadzeniu objawów lub wyników badań wskazuje prawdopodobne rozpoznanie, sugeruje dawkowanie leków lub konkretny tryb postępowania („skontaktuj się z lekarzem w ciągu 24 godzin”, „przyjmij dodatkową dawkę” itp.). Wtedy zbliżamy się do obszaru świadczenia usług medycznych lub co najmniej udzielania porad zdrowotnych.
Dla oceny odpowiedzialności istotne bywa nawet brzmienie komunikatów. „Może to oznaczać X, porozmawiaj z lekarzem” brzmi inaczej niż „Masz X, zastosuj Y”. Im bardziej kategoryczna i konkretna rekomendacja, tym trudniej twierdzić, że to tylko „informacja edukacyjna”, za którą nikt nie powinien odpowiadać jak za poradę medyczną.
Z tego powodu prawidłowe oznaczenie charakteru aplikacji (czy to wyrób medyczny, czy narzędzie wellbeing) oraz precyzyjne sformułowanie komunikatów do użytkownika stają się jednym z kluczowych obszarów minimalizowania ryzyka prawnego dla producentów i podmiotów medycznych.
Specyfika systemów AI/ML: probabilistyczność, „black box” i bias
Klasyczne oprogramowanie działa według z góry określonych reguł: jeśli A i B, to C. W przypadku uczenia maszynowego często nie da się łatwo wyjaśnić, dlaczego model doszedł do danego wniosku. System generuje prawdopodobieństwo lub ranking rozpoznań, ale ścieżka dojścia do wyniku jest trudna do prześledzenia nawet dla twórców. To rodzi wyzwanie dowodowe: pacjent lub lekarz chcą wiedzieć, dlaczego system się pomylił, a audytorzy i sądy potrzebują zrozumieć logikę działania, aby ocenić, czy producent dochował należytej staranności.
Algorytmy AI mają też charakter probabilistyczny – nigdy nie dają 100% pewności. Można im przypisać skuteczność, czułość, swoistość, ale zawsze pozostaje margines błędu. Pojawia się więc pytanie: w którym momencie błąd jest „normalnym ryzykiem metody”, akceptowalnym klinicznie i regulacyjnie, a kiedy staje się zaniedbaniem po stronie producenta (np. zbyt rzadkie retrenowanie modelu, brak monitoringu skuteczności po wdrożeniu)?
Na to nakłada się problem biasu, czyli stronniczości. Jeśli dane treningowe były zdominowane przez określoną populację, system może systematycznie zaniżać ryzyko u innych grup. Przykład: algorytm gorzej rozpoznaje zmiany skórne u osób o ciemniejszej karnacji, bo prawie nie widział takich zdjęć w procesie uczenia. Wówczas nie mamy do czynienia z „pojedynczym błędem”, ale z całą kategorią uprzedniości strukturalnej, za którą ktoś jest odpowiedzialny na poziomie projektu i walidacji modelu.
Dlaczego identyfikacja rodzaju błędu ma kluczowe znaczenie dla odpowiedzialności
W praktyce prawnej ustalenie, jakiego rodzaju błąd wystąpił, jest fundamentem przypisania odpowiedzialności. Jeśli doszło do bug-a technicznego powstałego przy modyfikacji kodu, odpowiedzialność spoczywa najczęściej na producencie lub podwykonawcy, który wykonywał update. Jeśli błąd wynika z założeń klinicznych i wymogów funkcjonalnych, do gry wchodzi także zleceniodawca systemu, np. szpital czy sieć przychodni, które współtworzyły specyfikację.
Jeżeli źródłem problemu są błędne dane wprowadzone przez pacjenta (nieprawdziwa masa ciała, pominięte choroby, pomylone jednostki), pojawia się możliwość przypisania współodpowiedzialności użytkownikowi – zwłaszcza, gdy aplikacja zawierała jasne ostrzeżenia i instrukcje. Podobnie, gdy błąd wynika z nieprawidłowego używania systemu przez personel medyczny (ignorowanie alertów, brak aktualizacji danych, wprowadzanie skrótów).
Rozróżnienie typu błędu jest też kluczowe dla ubezpieczycieli odpowiedzialności cywilnej. Inaczej kalkuluje się ryzyko dla producenta wyrobów medycznych, a inaczej dla lekarza lub podmiotu leczniczego. Dlatego dobrze zaprojektowana aplikacja zdrowotna powinna umożliwiać możliwie precyzyjne odtworzenie, co się wydarzyło w konkretnym przypadku: jakie dane weszły do systemu, jaka była logika decyzji, jakie ostrzeżenia pokazano użytkownikowi i jak zareagował.
Podstawowe ramy prawne w Polsce i UE dla cyfrowego zdrowia
Wiele gałęzi prawa na jednym boisku
Odpowiedzialność za błąd algorytmu w aplikacji zdrowotnej nie mieści się w jednym akcie prawnym. Na „boisku” spotykają się co najmniej:
- prawo medyczne (ustawa o działalności leczniczej, ustawy zawodowe lekarzy, pielęgniarek itd.),
- bug w kodzie (czysto programistyczna usterka),
- błąd projektowy – np. zbyt uproszczony model ryzyka, pominięcie ważnych parametrów klinicznych,
- błąd uczenia modelu AI – złe, niereprezentatywne dane treningowe, brak walidacji na odpowiedniej populacji,
- błąd danych wejściowych – np. mylne dane podane przez pacjenta lub wadliwy odczyt z urządzenia.
Prawo wyrobów medycznych i kwalifikacja oprogramowania
Cyfrowe narzędzia zdrowotne bardzo często są – z punktu widzenia prawa – wyrobami medycznymi. Kluczowe znaczenie ma tu rozporządzenie (UE) 2017/745 (MDR), które wprost obejmuje oprogramowanie, jeśli ma ono służyć m.in. diagnozowaniu, profilaktyce, monitorowaniu, leczeniu lub łagodzeniu chorób. Nie wystarczy więc nakleić na aplikację etykiety „wellbeing”, jeśli w praktyce generuje ona rekomendacje kliniczne.
Dla producenta moment kwalifikacji jest jak wybranie toru na autostradzie: po jednej stronie leży relatywnie lekki reżim narzędzi lifestyle’owych, po drugiej – pełne wymogi dla wyrobów medycznych: ocena kliniczna, zarządzanie ryzykiem, system jakości, dokumentacja techniczna, nadzór po wprowadzeniu do obrotu. Pomyłka w kwalifikacji może potem drogo kosztować, bo w razie incydentu sąd i organy nadzoru będą patrzyły na faktyczne funkcje aplikacji, a nie na marketingowe etykietki.
Jeżeli oprogramowanie zostanie uznane za wyrób medyczny, na producenta spadają precyzyjne obowiązki dotyczące bezpieczeństwa i działania wyrobu. W razie błędnej rekomendacji można więc badać, czy spełnił wymogi MDR, w tym czy przeprowadził właściwą ocenę kliniczną, testy użyteczności, walidację danych oraz czy monitorował zdarzenia po wprowadzeniu wyrobu na rynek. Zaniedbania w tych obszarach to potencjalna podstawa odpowiedzialności.
Ochrona konsumenta i nieuczciwe praktyki rynkowe
Pacjent korzystający z aplikacji zdrowotnej jest bardzo często jednocześnie konsumentem. To otwiera drzwi dla zastosowania przepisów o ochronie konsumentów, w tym tych dotyczących nieuczciwych praktyk rynkowych i niezgodności towaru z umową (po implementacji tzw. dyrektywy towarowej i cyfrowej).
Jeżeli aplikacja była reklamowana jako „diagnozująca choroby serca dzięki sztucznej inteligencji”, a w rzeczywistości generuje jedynie orientacyjne podpowiedzi bez solidnego podparcia klinicznego, można mówić o wprowadzeniu w błąd co do jej funkcji. W razie szkody pacjent nie musi ograniczać się do klasycznego roszczenia deliktowego – może sięgnąć po instrumenty z prawa konsumenckiego, np. zarzucając nieuczciwą praktykę rynkową lub brak zgodności usługi cyfrowej z umową.
Ochrona konsumenta ma też znaczenie dla kwestii klauzul wyłączających lub ograniczających odpowiedzialność. „Kliknięte” regulaminy nie mogą po prostu zrzucić całej odpowiedzialności na użytkownika, jeśli aplikacja zachęca do traktowania jej jak narzędzia medycznego. Sądy w takich sytuacjach chętnie badają, jakie było realne wrażenie przeciętnego użytkownika, a nie tylko to, co napisano małym druczkiem.
Odpowiedzialność deliktowa i kontraktowa
W tle zawsze pozostaje ogólna odpowiedzialność na zasadzie winy (art. 415 i n. Kodeksu cywilnego) oraz odpowiedzialność kontraktowa. Jeżeli między stronami istnieje umowa – np. pomiędzy szpitalem a dostawcą systemu AI – punktem odniesienia jest przede wszystkim treść tej umowy i należyta staranność w jej wykonaniu. Gdy relacja opiera się na „samej” aplikacji konsumenckiej, ścieżka deliktowa i konsumencka uzupełniają się wzajemnie.
Dla praktyki sporu bardzo istotny jest podział ról opisany w umowach B2B. Kto odpowiada za integrację z systemem szpitalnym? Kto ma prowadzić walidację kliniczną przed pełnym wdrożeniem? Kto jest zobowiązany do aktualizacji i monitorowania skuteczności? To nie są jedynie kwestie organizacyjne – w procesie sądowym mogą decydować, czy za błąd algorytmu odpowiada zewnętrzny dostawca, szpital, czy też obie strony solidarnie.
Dane osobowe, tajemnica medyczna i cyberbezpieczeństwo
Algorytmy zdrowotne żywią się danymi, a więc wchodzą na teren RODO, przepisów o dokumentacji medycznej i tajemnicy zawodowej. Błędna rekomendacja może być efektem naruszenia poufności lub integralności danych – np. wskutek ataku hakerskiego lub awarii, która zmienia dane wejściowe. W takiej sytuacji odpowiedzialność rozkłada się inaczej niż przy „czystym” błędzie modelu.
Administrator danych (zwykle podmiot leczniczy) ponosi odpowiedzialność za dobór i nadzór nad podmiotami przetwarzającymi, w tym dostawcami chmurowych rozwiązań AI. Dostawca zaś odpowiada za wdrożenie adekwatnych środków technicznych i organizacyjnych. Jeśli incydent bezpieczeństwa prowadzi do zafałszowania danych klinicznych, późniejsza błędna rekomendacja nie jest wyłącznie „błędem algorytmu”, lecz także skutkiem naruszenia obowiązków z zakresu ochrony danych i cyberbezpieczeństwa.
Kto może odpowiadać za błąd: producenci, lekarze, placówki, pacjenci
Producent oprogramowania i podmiot wprowadzający wyrób do obrotu
Producent jest pierwszym naturalnym adresatem roszczeń, gdy zawodzi technologia. W przypadku wyrobów medycznych odpowiada za projekt, wytworzenie, działanie i zgodność wyrobu z deklarowanym przeznaczeniem. Jeśli aplikacja nie spełnia podstawowych wymagań bezpieczeństwa, nie przeszła odpowiednich testów, a mimo to trafiła na rynek, mamy klasyczny przykład zaniedbania po stronie producenta.
Odpowiedzialność producenta może być rozpatrywana zarówno na gruncie MDR i krajowych przepisów o wyrobach medycznych, jak i ogólnych zasad odpowiedzialności cywilnej. Gdy błąd wynika z defektu produktu, wchodzi w grę również odpowiedzialność za produkt niebezpieczny. W praktyce oznacza to, że pacjent nie musi udowadniać konkretnego zaniedbania w procesie wytwórczym, lecz jedynie wykazać, że wyrób nie zapewniał bezpieczeństwa, jakiego można było oczekiwać.
Trzeba też pamiętać o roli „quasi-producenta” – podmiotu, który sprzedaje system pod własną marką, choć technicznie wytworzył go ktoś inny. Dla pacjenta to właśnie on bywa „twarzą” rozwiązania i to do niego naturalnie kierowane są roszczenia, nawet jeśli w tle funkcjonuje skomplikowany łańcuch podwykonawców.
Dostawca usług wdrożeniowych i integrator systemów
Często samo oprogramowanie działa poprawnie, ale zostaje błędnie wdrożone w konkretnej infrastrukturze. Źle skonfigurowane interfejsy, błędny mapping pól pomiędzy systemem HIS a modułem AI, brak uwzględnienia lokalnych procedur – to wszystko może powodować, że z punktu widzenia użytkownika „algorytm się myli”. A problem leży w integracji, nie w modelu.
Integrator i dostawca usług wdrożeniowych odpowiada wtedy za należyte wykonanie umowy i zachowanie należytej staranności zawodowej. Jeżeli zignorował wytyczne producenta co do środowiska pracy, nie przeprowadził testów odbiorczych lub nie przeszkolił personelu, ponosi współodpowiedzialność za skutki błędnych rekomendacji.
Lekarz korzystający z narzędzia algorytmicznego
Lekarz nie odpowiada za cały wszechświat technologii, ale odpowiada za sposób, w jaki włącza ją w proces diagnostyczno-terapeutyczny. Jeżeli system jest certyfikowany, wdrożony zgodnie z zaleceniami i używany właściwie, rola lekarza polega przede wszystkim na krytycznej ocenie jego podpowiedzi. Sytuacja zmienia się, gdy lekarz bezrefleksyjnie akceptuje rekomendację, która kłóci się z obrazem klinicznym lub podstawową wiedzą medyczną.
W postępowaniach o błąd medyczny pojawi się pytanie: czy kompetentny lekarz na tym samym stanowisku, dysponując tymi samymi danymi, mógł dostrzec, że sugestia algorytmu jest nieprawdopodobna, sprzeczna z wytycznymi lub po prostu „nie trzyma się kupy”. Jeśli tak, powoływanie się wyłącznie na rekomendację systemu może zostać uznane za naruszenie reguł sztuki.
Są jednak także sytuacje odwrotne. Jeżeli lekarz, wbrew uzasadnionym ostrzeżeniom algorytmu, lekceważy sygnały o ryzyku (np. wysokie prawdopodobieństwo zawału na podstawie EKG) i nie podejmuje dalszej diagnostyki, odpowiedzialność może spocząć właśnie na nim – narzędzie zadziałało prawidłowo, zawiódł człowiek.
Placówka medyczna jako organizator procesu
Podmiot leczniczy nie jest jedynie „sceną”, na której pojawiają się lekarze i technologie. To on decyduje, jakie systemy wdraża, jakie zasady ich używania obowiązują personel, jak prowadzone są szkolenia oraz jak wygląda nadzór nad incydentami. Jeżeli szpital wprowadza zaawansowane narzędzie AI, ale nie tworzy żadnych procedur, nie szkoli lekarzy i nie monitoruje skutków, część odpowiedzialności za błędy algorytmu może zostać przypisana właśnie jemu.
Odpowiedzialność placówki bywa także „wtórna”: odpowiada za swoich pracowników (lekarzy, pielęgniarki) oraz za dobór podwykonawców technologicznych. Jeżeli wybrała rozwiązanie oczywiście nieodpowiednie, mimo dostępnych ostrzeżeń regulatora czy negatywnych opinii, trudno będzie obronić się przed zarzutem braku należytej staranności przy organizowaniu procesu udzielania świadczeń.
Pacjent jako współtwórca danych i użytkownik aplikacji
Cyfrowe zdrowie ma to do siebie, że pacjent nie jest biernym odbiorcą. Wpisuje objawy, zaznacza schorzenia, mierzy ciśnienie, potwierdza przyjmowanie leków. W tym sensie staje się współtwórcą materiału, na którym pracuje algorytm. Jeżeli konsekwentnie podaje nieprawdziwe dane (choć był uprzedzony o konsekwencjach), ignoruje wyraźne ostrzeżenia czy używa aplikacji w sposób oczywiście sprzeczny z instrukcją, może ponieść część odpowiedzialności za skutki błędnej rekomendacji.
Granica ta nie jest jednak dowolna. Pacjent ma prawo nie rozumieć zawiłości medycyny i technologii. Nie można przerzucić na niego całej winy za nieprecyzyjne opisanie objawów, jeżeli interfejs jest nieintuicyjny, komunikaty niejasne, a proces wprowadzania danych sprzyja pomyłkom. W praktyce sądowej coraz większą rolę odgrywa więc ocena użyteczności aplikacji – czy była zaprojektowana w sposób przyjazny, czy raczej zachęcała do błędów?
Błąd algorytmu a odpowiedzialność lekarza – gdzie kończy się „pomocniczość” narzędzia
Model „narzędzia pomocniczego” a model „współdecydenta”
W klasycznym ujęciu systemy wspomagania decyzji klinicznych (CDSS) są jedynie narzędziem w ręku lekarza, podobnie jak stetoskop czy kalkulator dawki. Odpowiedzialność skupia się wtedy na człowieku: to on ma ocenić, czy rekomendacja algorytmu ma sens. W dobie coraz bardziej autonomicznych modeli AI takie proste rozróżnienie zaczyna jednak pękać.
Jeżeli system jest wbudowany w workflow w taki sposób, że lekarz widzi jedynie końcową rekomendację („zatwierdź/odrzuć”), a domyślną opcją jest akceptacja, rola algorytmu staje się realnie współdecyzyjna. Silny efekt autorytetu technologii (zwłaszcza, gdy jest ona przedstawiana jako „superdokładna AI”) może osłabiać czujność lekarza. W procesach o błąd medyczny coraz częściej pojawia się dlatego pytanie: czy lekarz realnie miał przestrzeń, aby zakwestionować podpowiedź systemu?
Standard należytej staranności w erze algorytmów
Standard postępowania lekarza nie jest stały – zmienia się wraz z rozwojem wiedzy i technologii. Gdy pewien typ systemów AI staje się powszechnie dostępny i rekomendowany w wytycznych, może się pojawić oczekiwanie, że lekarz będzie z niego korzystał. Odwrotnie, jeśli narzędzie jest eksperymentalne, bez jasnych dowodów skuteczności, lekarz powinien zachować większy dystans i informować pacjenta o charakterze rozwiązania.
To rodzi ciekawy dylemat: w jakim momencie „niekorzystanie z AI” staje się odstępstwem od aktualnego standardu? I odwrotnie – kiedy zbyt gorliwe ufanie algorytmom, bez adekwatnej kontroli, będzie traktowane jako nienależyta staranność? Odpowiedzi będą kształtowane przez biegłych, wytyczne towarzystw naukowych i pierwsze orzeczenia sądów.
Dokumentowanie korzystania z rekomendacji algorytmu
W sporach dotyczących błędów medycznych kluczowe jest to, co zostało udokumentowane w dokumentacji medycznej. Jeśli lekarz oparł się na rekomendacji aplikacji, dobrze, aby ślad tego znalazł się w karcie pacjenta: jaka była sugestia systemu, jakie były dane wejściowe, dlaczego lekarz ją przyjął lub odrzucił.
To z jednej strony chroni lekarza (pokazuje tok rozumowania), a z drugiej ujawnia rzeczywistą rolę technologii. Jeżeli w dokumentacji systematycznie pojawia się formuła „zastosowano się do rekomendacji algorytmu X”, trudno później twierdzić, że narzędzie było jedynie luźną inspiracją. Dla oceny odpowiedzialności lekarza i producenta takie zapisy są często ważniejsze niż marketingowe opisy aplikacji.
Zgoda pacjenta i informowanie o roli algorytmów
Pacjent ma prawo wiedzieć, że w jego przypadku korzysta się z narzędzi algorytmicznych, zwłaszcza jeśli mogą one w istotny sposób wpłynąć na decyzje terapeutyczne. Nie chodzi o opisywanie parametrów modelu, lecz o jasną informację, że część procesu decyzyjnego jest wspierana przez system AI o określonych ograniczeniach.
Jeżeli lekarz nie informuje o tym, a pacjent ponosi szkodę wynikającą z błędnej rekomendacji algorytmu, w tle pojawia się wątek wadliwej zgody. Wówczas odpowiedzialność może nie ograniczać się do samego błędu medycznego, lecz obejmować również naruszenie prawa pacjenta do informacji i współdecydowania o leczeniu.
Producent i dostawca aplikacji zdrowotnej – jak budować ochronę prawną w fazie projektowania
„Bezpieczny-by-design” – od specyfikacji po pierwszą linijkę kodu
W świecie cyfrowego zdrowia nie da się „dokręcić” bezpieczeństwa na końcu projektu. Jeżeli w specyfikacji biznesowej algorytm jest opisany jako „narzędzie orientacyjne do samoedukacji pacjenta”, a w prezentacjach sprzedażowych jako „niemal diagnostyka”, rodzi się rozdźwięk, który później będzie boleśnie wyciągany w sądzie. Konsekwencja między koncepcją, dokumentacją, materiałami marketingowymi i rzeczywistym działaniem jest jednym z pierwszych testów należytej staranności producenta.
Projektowanie „bezpieczne z natury” oznacza kilka prostych, ale wymagających dyscypliny założeń: jasne zdefiniowanie grupy docelowej (pacjent, lekarz, personel pomocniczy), określenie kontekstu użycia (dom, SOR, poradnia POZ), a także granic kompetencji systemu. Algorytm, który sugeruje dalszy kontakt z lekarzem, gra w innej lidze niż narzędzie ustawiające dawki chemioterapii. Jeżeli te granice są od początku nazwane, łatwiej później wykazać, że produkt nie obiecywał więcej, niż dawał.
Ocena ryzyka klinicznego i „przewidywalne niewłaściwe użycie”
Twórcy systemów medycznych przyzwyczaili się do analiz ryzyka w duchu norm ISO. Algorytmy AI dokładają do tego nowe warstwy: ryzyko błędnych danych treningowych, uprzedzeń, dryfu modelu, ale także zwykłych, ludzkich skrótów. Czy lekarz w nocy, przy zmęczeniu, nie zacznie traktować systemu jak „drugiego pilota”, któremu zbyt łatwo ufa? Czy pacjent nie użyje aplikacji triage’owej jak narzędzia „samodiagnozy z pominięciem lekarza”?
Tak zwane „przewidywalne niewłaściwe użycie” nie jest wymysłem prawników – regulator europejski wprost wymaga, aby producent zastanowił się, jak jego produkt może być używany wbrew instrukcji, ale w sposób dający się racjonalnie przewidzieć. Jeżeli aplikacja medyczna jest wizualnie niemal identyczna z popularnym komunikatorem i łatwo pomylić przycisk „zapisz notatkę” z „wyślij do lekarza”, to problem nie leży tylko po stronie użytkownika. Brak refleksji nad takimi scenariuszami w dokumentacji ryzyka będzie wyglądał słabo przy analizie odpowiedzialności.
Transparentność działania algorytmu a zaufanie i odpowiedzialność
Nie każdy model da się wyjaśnić w prosty sposób, ale każdy system można zaprojektować tak, by był bardziej lub mniej „czarną skrzynką” dla lekarza. W sporze prawnym szybkie pada pytanie: czy użytkownik mógł zorientować się, dlaczego algorytm doszedł do danej rekomendacji, choćby w zarysie? Prosta, wizualna prezentacja głównych czynników wpływających na wynik (np. wiek, konkretne parametry laboratoryjne) jest nie tylko wsparciem klinicznym, ale i elementem bezpieczeństwa prawnego.
Jeżeli lekarz otrzymuje lakoniczny komunikat „prawdopodobieństwo X: 97%” bez informacji, co stało za takim wynikiem, trudniej wymagać od niego krytycznej oceny. Producent, który całkowicie zaciera ślady procesu decyzyjnego modelu, może usłyszeć zarzut, że stworzył narzędzie zachęcające do bezrefleksyjnej akceptacji rezultatu. W systemach projektowanych z myślą o odpowiedzialności coraz częściej pojawiają się więc moduły „why this?” – krótkie, zrozumiałe objaśnienia, nawet jeśli dalekie od akademickiej „explainable AI”.
Interfejs użytkownika jako element bezpieczeństwa prawnego
Interfejs to nie tylko estetyka – to także narzędzie zarządzania ryzykiem. Przykład z praktyki: aplikacja do dawkowania insuliny, w której lekarz miał do dyspozycji dwa bardzo podobne pola – „masa ciała” (kg) i „objętość roztworu” (ml). Jedno błędne kliknięcie skutkowało dawką kilkukrotnie wyższą niż zalecana. Formalnie algorytm liczył dobrze, ale projekt interfejsu wręcz zapraszał do pomyłek, co w analizie odpowiedzialności ciążyło na producencie.
Dobre praktyki interfejsu w zdrowiu cyfrowym obejmują nie tylko ergonomię, ale także sposób prezentowania ryzyka i niepewności. Zamiast zielonego „OK” i czerwonego „NIEBEZPIECZEŃSTWO” lepiej pokazać zakresy, poziomy zaufania modelu, warunki, w których wynik jest mniej wiarygodny. Dostosowanie języka do odbiorcy – innego dla lekarza, innego dla pacjenta – jest równie istotne. Prosty, zrozumiały komunikat „to narzędzie nie zastępuje wizyty lekarskiej” działa inaczej, gdy jest zakopany w regulaminie, a inaczej, gdy pojawia się w krytycznym momencie ścieżki użytkownika.
Ostrzeżenia, ograniczenia i komunikaty – nie tylko w regulaminie
Producenci lubią zasłaniać się ogólnymi zastrzeżeniami: „aplikacja ma charakter wyłącznie informacyjny, nie stanowi porady medycznej”. Tego typu klauzule pomagają, ale nie są tarczą absolutną. Sąd będzie patrzył nie tylko na to, co wpisano w regulaminie, lecz przede wszystkim na to, jak przeciętny użytkownik odbierał funkcję aplikacji. Jeśli reklama, onboarding i interfejs sugerują „diagnostykę z telefonu”, a jedno zdanie w regulaminie twierdzi, że to „tylko edukacja”, wiarygodność takiego zastrzeżenia jest wątpliwa.
Dlatego sensowne ostrzeżenia i ograniczenia powinny być „wbudowane” w kluczowe etapy korzystania z aplikacji: przed podjęciem decyzji, przed wysłaniem recepty, przed wygenerowaniem diagnozy wstępnej. Krótkie, kontekstowe komunikaty („ta ocena nie zastępuje badania fizykalnego”, „w przypadku nagłych objawów zadzwoń pod numer alarmowy”) wzmacniają argument, że producent rozsądnie informował o granicach narzędzia. Brak takich sygnałów może zostać odczytany jako zachęta do nadmiernej wiary w algorytm.
Mechanizmy nadzoru nad działaniem modelu po wdrożeniu
Algorytm medyczny nie jest jak jednorazowy sprzęt jednorazowy – to raczej organizm, który żyje w konkretnym środowisku danych. Producent, który po wdrożeniu „odcina pępowinę” i nie monitoruje działania modelu, świadomie przyjmuje na siebie dodatkowe ryzyko. Coraz częściej wymaga się, aby w dokumentacji istniał plan nadzoru po wprowadzeniu na rynek: jak zbierane są informacje o błędach, kto analizuje alarmujące wzorce, w jakim trybie wprowadza się poprawki.
W praktyce oznacza to konieczność stworzenia kanałów zgłaszania incydentów (przez lekarzy, pacjentów, integratorów), procedur analizy istotnych zdarzeń oraz jasnej polityki aktualizacji. Jeżeli przez miesiące napływają zgłoszenia, że system stale zaniża ryzyko u określonej grupy pacjentów, a producent nie reaguje, trudno bronić się twierdzeniem, że dochował należytej staranności. Z drugiej strony dobrze udokumentowane działania naprawcze pokazują, że ryzykiem zarządzano aktywnie, co ma znaczenie przy ograniczaniu odpowiedzialności.
Zarządzanie zmianą wersji algorytmu i re-treningiem modelu
Modele uczące się „w locie” kuszą producentów obietnicą stałego doskonalenia. Z perspektywy prawa rodzi to jednak kilka kłopotliwych pytań. Której wersji algorytmu dotyczy certyfikacja? Jakie dane posłużyły do dodatkowego treningu? Czy użytkownicy zostali poinformowani, że istotnie zmieniły się zasady działania systemu?
Bez kontrolowanego procesu wersjonowania – z changelogiem, opisem wpływu na ryzyko kliniczne i, przy poważniejszych zmianach, powtórną walidacją – producent sprowadza na siebie zarzut „eksperymentowania na żywym organizmie”. W przypadku poważnego incydentu biegli będą pytać, która wersja modelu zadziałała wadliwie, a brak jasnej ścieżki wersji może być interpretowany na niekorzyść wytwórcy. Dlatego mechanizmy utrwalania wersji, możliwość odtworzenia wcześniejszego stanu systemu i kontrola nad samo-uczeniem się modelu są tak samo elementem bezpieczeństwa, jak testy jednostkowe.
Walidacja kliniczna i dokumentowanie wiarygodności wyników
Algorytm może imponować „accuracy” na zbiorze testowym, ale pytanie brzmi: czy ta skuteczność przekłada się na realny, kliniczny kontekst, w którym będzie stosowany? Jeżeli system był trenowany na danych z dużego ośrodka akademickiego, a trafia do małego szpitala powiatowego z inną populacją pacjentów, walidacja ex ante może nie oddać pełnego obrazu ryzyka. Producent, który lubi chwalić się wyśrubowanymi statystykami, powinien równie chętnie pokazywać ograniczenia i warunki, w jakich takie wyniki uzyskano.
Udokumentowana walidacja kliniczna – z udziałem niezależnych ośrodków, opisem populacji i precyzyjnym zakreśleniem obszaru zastosowania – jest potem kluczowym punktem odniesienia w dyskusjach o odpowiedzialności. Jeżeli w dokumentacji jasno zapisano, że model nie był badany u dzieci, a mimo to zostaje użyty na oddziale pediatrycznym, odpowiedzialność przesuwa się w kierunku użytkownika i placówki. Gdy natomiast zakres walidacji jest opisany mgliście, producenci muszą liczyć się z tym, że domniemania procesowe nie będą dla nich korzystne.
Umowy z placówkami medycznymi i lekarzami – rozkład ról i ryzyk
Kontrakty zawierane z podmiotami leczniczymi to nie tylko cennik i poziom wsparcia technicznego. To również narzędzie kształtowania odpowiedzialności. Producenci często próbują „zrzucić” jak najwięcej ryzyka na użytkownika, formułując klauzule: „użytkownik ponosi pełną odpowiedzialność za wykorzystanie rekomendacji”. Takie zapisy mają jednak ograniczoną skuteczność – nie przekreślą odpowiedzialności za wady produktu czy rażące zaniedbania po stronie producenta.
Rozsądniej jest precyzyjnie opisać, co po stronie placówki jest obowiązkiem, a co po stronie dostawcy: kto odpowiada za konfigurację, kto za aktualizacje, kto za szkolenia personelu, a kto za monitorowanie działania systemu i zgłaszanie incydentów. Klarowny podział ról i procedur nie tylko zmniejsza ryzyko samego wystąpienia błędów, ale też ułatwia późniejsze „rozplątanie” odpowiedzialności między stronami, gdy dojdzie do sporu.
Szkolenia użytkowników jako część strategii odpowiedzialności
Nawet najlepszy algorytm można „zepsuć” kiepskim wdrożeniem. Jeśli lekarz dowiaduje się o istnieniu nowego systemu z maila „od jutra korzystamy z modułu AI, login i hasło jak zwykle”, trudno oczekiwać, że będzie rozumiał jego ograniczenia. Producenci, którzy budują programy szkoleń – wstępnych i okresowych – mogą później wykazać, że dołożyli starań, by użytkownik korzystał z narzędzia zgodnie z przeznaczeniem.
Szkolenie nie musi oznaczać wielodniowych konferencji. Czasem bardziej efektywne są krótkie, dobrze zaprojektowane scenariusze: symulacje przypadków, przykłady typowych błędów interpretacyjnych, omówienie tego, czego system „nie widzi”. Kluczowe jest, aby informacje o ograniczeniach i ryzykach nie były jedynie „dodatkiem” na końcu prezentacji, lecz stanowiły jej oś. Dokumentacja przeprowadzonych szkoleń (listy obecności, materiały) może potem stać się ważnym elementem obrony producenta.
Bezpieczeństwo danych a odpowiedzialność za błędne rekomendacje
Na pierwszy rzut oka naruszenia ochrony danych wydają się odrębną kategorią od błędów algorytmu. W praktyce jedno często wpływa na drugie. Jeżeli z przyczyn bezpieczeństwa ograniczono zakres zbieranych danych do tego stopnia, że model działa na „okrojonych” informacjach, trzeba uczciwie nazwać wynikające z tego ograniczenia kliniczne. Z kolei incydenty bezpieczeństwa (np. manipulacja danymi wejściowymi przez osobę nieuprawnioną) mogą rzutować na poprawność rekomendacji.
Producent, który projektuje architekturę bezpieczeństwa, powinien uwzględnić nie tylko poufność i integralność danych w sensie „informatycznym”, ale też ich znaczenie kliniczne. Mechanizmy wykrywania anomalii w danych (np. nagłe, nielogiczne zmiany parametrów) czy ograniczenie możliwości ręcznego nadpisywania kluczowych wartości przez użytkownika są elementem obrony zarówno przed atakami, jak i przed nieświadomym wprowadzeniem błędów, które potem „skażają” rekomendacje.
Etyka projektowania a perspektywa prawnika
Może brzmieć to abstrakcyjnie, ale wartości etyczne zapisane w politykach firmy często przekładają się na bardzo praktyczne decyzje designowe: jak prezentujemy niepewność modelu, czy pozwalamy użytkownikowi łatwo pominąć ostrzeżenia, czy dajemy możliwość „drugiej opinii” w systemie. Z perspektywy prawnika te wybory będą później czytane jako sygnały: czy producent postawił na maksymalizację kliknięć, czy raczej na bezpieczeństwo użytkownika.
Prosty przykład: moduł samodiagnostyczny może po zakończeniu ankiety wyświetlić listę możliwych schorzeń wraz z informacją „prawdopodobieństwo wysokie”. Ale może też uporczywie przypominać, że to jedynie lista hipotez i zalecać konsultację z lekarzem, szczególnie przy objawach alarmowych. W tym drugim wariancie łatwiej będzie bronić się przed zarzutem, że producent zachęcał do samodzielnego leczenia na podstawie algorytmu.
Dokumentacja techniczna i „ślady audytowe” jako linia obrony
Gdy dochodzi do sporu, bardzo szybko okazuje się, że najcenniejszym zasobem producenta są nie tyle hasła marketingowe, ile skrupulatnie prowadzona dokumentacja. Opisy procesu tworzenia modelu, raporty z testów, protokoły posiedzeń zespołów ds. bezpieczeństwa, analizy ryzyka – to wszystko układa się w opowieść o tym, czy wytwórca działał jak rzetelny profesjonalista, czy jak entuzjastyczny start‑up, który liczył, że „jakoś to będzie”.
Najczęściej zadawane pytania (FAQ)
Kto odpowiada za błąd algorytmu w aplikacji zdrowotnej – lekarz, producent czy pacjent?
Odpowiedzialność zwykle rozkłada się na kilka podmiotów. Producent (twórca oprogramowania, dostawca systemu) odpowiada za to, żeby aplikacja była zaprojektowana, wytworzona i aktualizowana zgodnie z wymogami prawa (np. MDR, a w przypadku systemów AI także AI Act) oraz zasadami bezpieczeństwa. Jeśli w kodzie jest klasyczny bug lub wadliwy projekt modelu, ciężar spoczywa przede wszystkim na producencie.
Jeśli aplikacja jest narzędziem pracy lekarza, on nadal musi zachować własną staranność zawodową – nie może „bezrefleksyjnie klikać OK”. Z kolei pacjent odpowiada za sposób korzystania z aplikacji: wprowadzanie prawdziwych danych, nieignorowanie ostrzeżeń, czytanie instrukcji. W sporze sądowym zwykle bada się cały łańcuch zdarzeń, a nie tylko „kto ostatni kliknął przycisk”.
Czy lekarz zawsze odpowiada za błędną rekomendację aplikacji medycznej?
Nie zawsze i nie w ten sam sposób. Jeżeli aplikacja jest wyrobem medycznym używanym jako wsparcie decyzji klinicznej, lekarz ma obowiązek krytycznie ocenić jej podpowiedzi i skonfrontować je ze swoją wiedzą oraz stanem pacjenta. Wtedy jego odpowiedzialność miesza się z odpowiedzialnością producenta – bada się, czy mógł zauważyć oczywisty błąd systemu.
W wielu rozwiązaniach digital health algorytm działa jednak bezpośrednio w relacji z pacjentem (chatbot objawowy, aplikacja do samokontroli). Lekarz w ogóle nie widzi interfejsu, nie zna szczegółów logiki algorytmu. W takiej sytuacji trudno obarczać go odpowiedzialnością za każdy błąd narzędzia, o którego konstrukcji nie miał pojęcia i na które nie miał realnego wpływu.
Co to jest „błąd algorytmu” w cyfrowym zdrowiu i czym różni się od „błędnej rekomendacji”?
„Błąd algorytmu” to ogólne hasło, pod którym kryją się różne zjawiska techniczne i projektowe. Może to być:
„Błędna rekomendacja” to już efekt na wierzchu – konkretna wskazówka, komunikat albo decyzja systemu (np. „to tylko niestrawność, zostań w domu”), która okazuje się niezgodna z aktualną wiedzą medyczną i prowadzi do szkody. W procesie prawnym trzeba zwykle odpowiedzieć na pytanie: czy źródłem tej błędnej rekomendacji był wadliwy projekt, wadliwe dane, błąd użytkownika, czy kombinacja tych elementów.
Czy producent aplikacji zdrowotnej może się „wybronić” klauzulą, że aplikacja nie zastępuje lekarza?
Ogólne zastrzeżenie typu „aplikacja ma charakter informacyjny i nie zastępuje porady lekarza” pomaga tylko wtedy, gdy rzeczywiście narzędzie pełni funkcję informacyjną. Jeśli interfejs, język komunikatów i funkcjonalności sugerują użytkownikowi konkretne decyzje medyczne (np. „nie ma potrzeby pilnego kontaktu z lekarzem”), sąd raczej nie da się przekonać, że to „tylko ciekawostka”.
Innymi słowy: jeżeli system faktycznie wpływa na diagnostykę, leczenie lub triage pacjentów, to klauzula „nie zastępuje lekarza” nie usuwa odpowiedzialności producenta. Może za to zmniejszyć ryzyko, gdy aplikacja jest wyraźnie edukacyjna, a użytkownik mimo jasnych ostrzeżeń użyje jej w miejsce pilnej konsultacji.
Jak pacjent może dochodzić roszczeń po szkodzie spowodowanej przez aplikację zdrowotną?
Pacjent w praktyce ma kilka ścieżek. Może wystąpić z roszczeniem odszkodowawczym przeciwko podmiotowi leczniczemu lub lekarzowi (jeżeli system był elementem procesu leczenia w placówce), a równolegle – przeciwko producentowi aplikacji jako za produkt wadliwy lub produkt niebezpieczny. W sprawy coraz częściej włączani są także ubezpieczyciele odpowiedzialności cywilnej.
Kluczowe jest zgromadzenie dowodów: logów z aplikacji, historii aktualizacji, regulaminu i instrukcji, dokumentacji medycznej, a czasem opinii biegłych z zakresu informatyki medycznej i AI. Bez tego trudno wykazać związek przyczynowy między działaniem algorytmu a konkretną szkodą zdrowotną.
Czy błąd algorytmu w systemie AI w ochronie zdrowia to zawsze „błąd w sztuce lekarskiej”?
Niekoniecznie. „Błąd w sztuce” dotyczy przede wszystkim postępowania lekarza w świetle aktualnej wiedzy medycznej. Algorytm może się pomylić z powodu wadliwego kodu, niedopracowanego modelu lub złych danych treningowych, mimo że lekarz pracował zgodnie z procedurami i nie miał realnego wpływu na wewnętrzne mechanizmy systemu.
Taki przypadek częściej podpada pod odpowiedzialność za produkt niebezpieczny lub naruszenie wymogów dotyczących wyrobów medycznych i systemów wysokiego ryzyka (MDR, AI Act), niż pod klasyczny „błąd w sztuce” lekarza. Granice są jednak płynne – zdarzają się sytuacje, w których i algorytm, i człowiek zachowują się nieprawidłowo, a sąd dzieli odpowiedzialność pomiędzy kilka stron.
Opracowano na podstawie
- Regulation (EU) 2017/745 on medical devices (MDR). European Union (2017) – Ramowe zasady dla wyrobów medycznych, w tym oprogramowania
- Regulation (EU) 2024/1689 laying down harmonised rules on artificial intelligence (AI Act). European Union (2024) – Klasyfikacja systemów wysokiego ryzyka i obowiązki dostawców AI
- Guidance on Qualification and Classification of Software in Regulation (EU) 2017/745. European Commission Medical Device Coordination Group (2019) – Wytyczne dot. kwalifikacji aplikacji jako wyrobu medycznego
- Ethics and governance of artificial intelligence for health. World Health Organization (2021) – Zasady etyczne i odpowiedzialność przy stosowaniu AI w zdrowiu
- Liability for Artificial Intelligence and other emerging digital technologies. European Commission Expert Group on Liability and New Technologies (2019) – Analiza odpowiedzialności cywilnej za systemy AI
- Proposal for a Directive on adapting non-contractual civil liability rules to artificial intelligence. European Commission (2022) – Projekt regulacji odpowiedzialności za szkody wyrządzone przez AI
