Autorska ilustracja koncepcyjna, nie wynik pomiaru. Na podstawie Sebin i Karaman Sebin, Frontiers in Artificial Intelligence, 2026, DOI: 10.3389/frai.2026.1956533. Propozycja ram oceny nie jest dowodem ich skuteczności.
Sztuczna inteligencja może udzielić odpowiedzi, która brzmi przekonująco i pasuje do pytania. Czy to wystarcza, aby uznać jej zastosowanie w ochronie zdrowia za bezpieczne? Nie. Między odpowiedzią programu a sytuacją pacjenta znajdują się jeszcze ludzie, zasady pracy, decyzje i działania. Właśnie tę drogę proponują analizować autorzy nowego artykułu o bezpieczeństwie AI. To wartościowy punkt wyjścia do rozmowy organizacyjnej, ale nie dowód, że opisane zabezpieczenia już sprawdzono w praktyce klinicznej.
Co właściwie opublikowano?
Burhan Sebin i Irem Karaman Sebin przedstawili tekst From model failure to system harm: operationalizing a sociotechnical pathway for healthcare AI safety w czasopiśmie Frontiers in Artificial Intelligence. Artykuł ukazał się 14 września 2026 roku jako Perspective, czyli praca przedstawiająca perspektywę autorów i proponowany sposób uporządkowania problemu. Nie jest randomizowanym badaniem klinicznym, walidacją konkretnego narzędzia ani wytycznymi towarzystwa naukowego. Pełny tekst jest dostępny u wydawcy.
Autorzy korzystają z celowo dobranych publikacji, aby połączyć zagadnienia techniczne i organizacyjne. Nie przeprowadzili systematycznego wyszukiwania ani formalnej oceny ryzyka błędu systematycznego przywołanych prac. Nie przedstawiają nowych danych pacjentów. Ich propozycja nie została prospektywnie zwalidowana jako sposób zapobiegania szkodom. Te ograniczenia nie przekreślają wartości rozmowy, którą inicjuje tekst, lecz wyznaczają granicę tego, co wolno na jego podstawie obiecywać.
Dlaczego odpowiedź modelu i bezpieczeństwo to różne pytania?
Ocena odpowiedzi dotyczy tego, co wygenerował system. Ocena bezpieczeństwa musi objąć również to, jak odpowiedź została wykorzystana. Błąd modelu nie musi skończyć się szkodą: może zostać zauważony, zakwestionowany lub zatrzymany przed podjęciem działania. Z kolei sam korzystny wynik testowania modelu nie opisuje wszystkich warunków jego użycia w konkretnej placówce. Nie mówi automatycznie, kto przejmuje odpowiedzialność za następny krok.
Nie wynika z tego, że pomiar jakości modelu jest zbędny. Wynika natomiast, że nie powinien zamykać oceny. Pytania o odpowiedź, decyzję i konsekwencje są powiązane, ale nie są zamienne. Artykuł zachęca do prześledzenia tych połączeń zamiast traktowania bezpieczeństwa jako jednej właściwości programu. To koncepcja oceny całego układu pracy, a nie nowy wskaźnik pozwalający nadać systemowi etykietę „bezpieczny”.
Pięć etapów proponowanych przez autorów
W pracy przedstawiono ciąg: podatność, zachowanie AI, człowiek i organizacja pracy, decyzja lub działanie systemu, a następnie możliwa szkoda. To mapa pojęciowa autorów. Nie oznacza, że każdy incydent przechodzi przez te etapy w identyczny sposób ani że znamy prawdopodobieństwo przejścia między nimi. Poniższe objaśnienia służą zrozumieniu tej propozycji, nie zastępują jej walidacji.
1. Podatność: gdzie może zacząć się problem?
Pierwszy etap dotyczy warunków, które mogą sprzyjać niepożądanemu zachowaniu. Rozmowa nie powinna zaczynać się dopiero po zauważeniu błędnej odpowiedzi. Warto najpierw określić, do czego system ma służyć i w jakich okolicznościach będzie wykorzystywany. To pozwala wskazać obszary wymagające kontroli, ale samo ich nazwanie nie dowodzi, że zagrożenie zostało usunięte. Lista potencjalnych słabości nie jest jeszcze pomiarem rzeczywistego ryzyka pacjenta.
2. Zachowanie AI: co rzeczywiście zrobił system?
Kolejny etap koncentruje się na zachowaniu narzędzia. Trzeba oddzielić obserwację jego odpowiedzi od interpretacji skutków. Stwierdzenie „program popełnił błąd” opisuje inny fragment zdarzenia niż stwierdzenie „pacjent doznał szkody”. Połączenie tych informacji wymaga sprawdzenia dalszych kroków. Autorzy nie proponują uniwersalnego odsetka błędów, poniżej którego każde zastosowanie byłoby bezpieczne, niezależnie od zadania i otoczenia.
3. Człowiek i organizacja pracy: co dzieje się z odpowiedzią?
Odpowiedź trafia do określonej osoby i do konkretnego procesu. Znaczenie ma to, kto ją odczytuje, jak rozumie swoją rolę i czy może zgłosić wątpliwość. W tej części analizy pytamy o rzeczywisty przebieg pracy, nie tylko o deklarację, że człowiek pozostaje zaangażowany. Sam zapis o nadzorze nie wyjaśnia jeszcze, co osoba nadzorująca widzi, sprawdza i robi po zauważeniu problemu.
4. Decyzja lub działanie: jaki krok został wykonany?
Następnie trzeba ustalić, czy i w jaki sposób odpowiedź AI wpłynęła na działanie. Nie należy zakładać tego wpływu wyłącznie dlatego, że narzędzie było dostępne. Istotne jest rozróżnienie pomiędzy informacją wyświetloną przez model a decyzją podjętą w procesie opieki. Bez tego łatwo przypisać modelowi zarówno korzyść, jak i szkodę, których związek z jego użyciem nie został właściwie oceniony.
5. Możliwa szkoda: co wiadomo o konsekwencjach?
Ostatni etap dotyczy następstw, a nie wyłącznie poprawności odpowiedzi. Artykuł nie dostarcza jednej częstości szkód, którą można przenieść do dowolnej kliniki. Przykłady zaczerpnięte z różnych prac także nie tworzą wspólnego mianownika. Nie można zatem zamienić liczby opisanych incydentów w indywidualne ryzyko pacjenta ani uznać odsetka wadliwych odpowiedzi za odsetek osób, którym zaszkodzono.
Jak wykorzystać tę koncepcję bez udawania, że jest standardem?
Najbardziej ostrożne zastosowanie to potraktowanie tekstu jako zaproszenia do rozmowy między osobami odpowiedzialnymi za narzędzie i za organizację opieki. Zamiast zaczynać od ogólnego zapewnienia o bezpieczeństwie, można wspólnie opisać, co następuje po odpowiedzi modelu. Takie uporządkowanie pytań nie stanowi jednak certyfikacji, zgody regulatora ani dowodu skuteczności proponowanych zabezpieczeń.
Poniższa lista jest redakcyjną pomocą do dyskusji. Nie została zwalidowana, nie jest punktowanym testem i nie daje wyniku „wdrożenie bezpieczne”. Jej celem jest ujawnienie pytań, na które zespół powinien poszukać odpowiedzi w swoim rzeczywistym procesie:
- Do jakiego dokładnie zadania używamy AI i czego nie powierzamy temu narzędziu?
- Kto otrzymuje odpowiedź i kto ocenia decyzję podejmowaną po jej otrzymaniu?
- Jaki sygnał powoduje zgłoszenie wątpliwości i do kogo ono trafia?
- Co następuje po takim zgłoszeniu i kto odpowiada za dalszą reakcję?
- Jak odróżniamy problem odpowiedzi modelu od problemu organizacji pracy?
- Jakie dane byłyby potrzebne, aby ocenić konsekwencje dla pacjentów?
Nie chodzi o odhaczenie wszystkich punktów i zamknięcie sprawy. Odpowiedź „mamy procedurę” jest początkiem sprawdzania, a nie opisem tego, jak procedura działa. Podobnie samo wskazanie osoby odpowiedzialnej nie pokazuje, czy ma ona dostęp do potrzebnych informacji. Są to pytania organizacyjne inspirowane publikacją, a nie wyniki nowego eksperymentu ani zalecenia dotyczące leczenia konkretnej osoby.
Czego ten artykuł nie rozstrzyga?
Nie wiadomo na jego podstawie, o ile proponowane ramy zmniejszają liczbę szkód, czy ich zastosowanie zmienia decyzje kliniczne ani jakie są koszty takiego wdrożenia. Nie przedstawiono jednego własnego modelu i zbioru testowego, dla którego można byłoby ocenić reprezentatywność danych, kalibrację lub wyniki poszczególnych grup pacjentów. Te pytania pozostają właściwe dla konkretnych narzędzi i ich zastosowań, ale tutaj nie otrzymujemy gotowych odpowiedzi.
Ważne jest także rozróżnienie dowodów przytoczonych i dowodów własnych. Autorzy omawiają inne publikacje, jednak wyniki badania określonego narzędzia nie są automatycznie dowodem skuteczności całej proponowanej architektury nadzoru. Każde szczegółowe twierdzenie liczbowe zaczerpnięte z takiej pracy wymagałoby osobnej kontroli źródła. W tym omówieniu celowo nie wykorzystujemy odsetków błędów ani szkód z przywołanych przykładów.
Co może z tego wynieść pacjent?
Pomocne jest rozdzielenie trzech rodzajów wypowiedzi o wdrożeniu. Pierwsza opisuje zamiar: „chcemy zwiększyć bezpieczeństwo”. Druga opisuje rozwiązanie organizacyjne: „wprowadziliśmy określony sposób nadzoru”. Trzecia dotyczy wyniku: „sprawdziliśmy, jakie były konsekwencje”. To redakcyjne objaśnienie, nie dodatkowy model badawczy. Pokazuje jednak, dlaczego nie należy traktować deklarowanego celu ani samego uruchomienia procedury jako dowodu osiągnięcia korzyści dla pacjentów.
Ta ostrożność pomaga także czytać doniesienia o nowych rozwiązaniach. Sformułowanie „autorzy proponują” nie znaczy tego samego co „autorzy wykazali”. Informacja o omówieniu wielu przykładów nie oznacza, że przeprowadzono systematyczny przegląd całego dostępnego piśmiennictwa. Z kolei brak walidacji tej propozycji nie jest dowodem, że propozycja nie może być przydatna. Oznacza po prostu, że jej przydatność organizacyjną trzeba odróżnić od potwierdzonej skuteczności w zapobieganiu szkodom. Taki sposób lektury pozwala uniknąć zarówno nadmiernych obietnic, jak i pochopnego odrzucenia wartościowej dyskusji.
Przede wszystkim świadomość, że pytanie o AI w placówce nie musi ograniczać się do jej nazwy albo deklarowanej dokładności. Można również zapytać, jaką rolę pełni narzędzie, kto weryfikuje decyzję oraz jak zgłaszane są wątpliwości. To nie jest zachęta do samodzielnego oceniania algorytmu lub zmiany leczenia. Jest to sposób prowadzenia bardziej konkretnej rozmowy o odpowiedzialności za proces opieki.
Nie należy też wyciągać odwrotnego, równie nieuprawnionego wniosku, że artykuł dowodzi nieskuteczności wszystkich zastosowań AI. Nie taki był jego projekt. Autorzy proponują język do analizy bezpieczeństwa, a nie rozstrzygają wartości każdego produktu. Potencjalna przydatność narzędzia i jakość zabezpieczeń muszą być oceniane w odniesieniu do określonego zastosowania, zamiast na podstawie ogólnego entuzjazmu lub ogólnego lęku przed technologią.
Przejrzystość i najważniejszy wniosek
W publikacji zadeklarowano brak finansowego wsparcia pracy i publikacji. Burhan Sebin ujawnił zatrudnienie w eMerge Americas; drugi autor zadeklarował brak relacji konfliktowych. Autorzy ujawnili również wykorzystanie generatywnej AI do wsparcia pomysłów, redakcji językowej i opracowania ryciny. Przytoczenie tych deklaracji służy przejrzystości: nie stanowi niezależnego audytu interesów ani powodu do automatycznego przyjęcia lub odrzucenia argumentów.
Najważniejsza myśl pozostaje prosta: dobry wynik modelu nie kończy pytań o bezpieczeństwo. Trzeba jeszcze zbadać drogę od odpowiedzi do decyzji i konsekwencji. Omawiana Perspective pomaga tę drogę nazwać, ale nie dowodzi skuteczności własnej propozycji. Dlatego warto wykorzystać ją do postawienia precyzyjnych pytań, nie do ogłoszenia, że problem bezpieczeństwa AI został już rozwiązany.
Źródło: Sebin B, Karaman Sebin I. From model failure to system harm: operationalizing a sociotechnical pathway for healthcare AI safety. Frontiers in Artificial Intelligence. 2026;9:1956533. DOI: 10.3389/frai.2026.1956533. Typ publikacji: Perspective.