Ryzyko klinicznej AI obejmuje cały cykl życia

Przegląd porządkuje zagrożenia na wielu etapach wdrażania i stosowania AI w ochronie zdrowia:

• Projektowanie i dane treningowe: zmanipulowane lub „zatrute” dane mogą zmienić zachowanie systemu jeszcze zanim trafi on do placówki medycznej.
• Wdrożenie i interfejsy: atak typu prompt injection może wprowadzić do procesu pracy złośliwe instrukcje. Autorzy wskazują między innymi na możliwość, że model przeoczy widoczny guz, jeśli atak wpłynie na sposób interpretacji obrazu lub informacji klinicznej. Podatna infrastruktura informatyczna szpitala może także zakłócić udzielanie świadczeń albo doprowadzić do ujawnienia danych pacjentów.
• Zachowanie modelu: duże modele językowe potrafią generować przekonujące, lecz nieprawdziwe informacje medyczne — tak zwane halucynacje. Mogą również zbyt łatwo przyjmować założenia użytkownika i wzmacniać błędną przesłankę zamiast ją zakwestionować.
• Relacja człowiek–AI: przekonujące odpowiedzi mogą sprzyjać automatyzacji poznawczej, czyli zbyt łatwemu podporządkowaniu się sugestii systemu, oraz błędowi potwierdzenia, gdy lekarz wykorzystuje AI do poparcia wcześniej przyjętej diagnozy lub opinii.
• Wykorzystanie instytucjonalne: personel może sięgać po publiczne albo niezatwierdzone narzędzia bez formalnej zgody placówki. Takie „ukryte użycie” (shadow use) może omijać zabezpieczenia prywatności, lokalne testy, zasady odpowiedzialności i procedury zgłaszania incydentów.

To spojrzenie na cały cykl życia ma praktyczne znaczenie. System może dobrze wypaść w kontrolowanym teście, a mimo to okazać się niebezpieczny w codziennej pracy. Ostateczny wynik zależy także od bezpieczeństwa infrastruktury, zachowań ludzi, kontekstu klinicznego i kontroli organizacyjnych.

Jak powinno wyglądać odpowiedzialne wdrożenie?

Zdaniem autorów zabezpieczenia muszą działać także po uruchomieniu narzędzia. Potrzebne są między innymi bezpieczny proces tworzenia oprogramowania, kontrola jakości i pochodzenia danych treningowych, testy w konkretnej placówce i w rzeczywistym kontekście klinicznym, jasno określone obowiązki człowieka oraz stałe monitorowanie wyników i incydentów.

Szpital lub przychodnia powinny więc ustalić nie tylko, czy narzędzie generuje wiarygodnie brzmiący tekst. Konieczne jest również określenie:

• kto może korzystać z systemu i do jakich zadań;
• do jakich danych ma on dostęp i gdzie te dane są przetwarzane;
• w jaki sposób lekarze i inni pracownicy mają weryfikować jego wyniki;
• kto odpowiada za błędną dokumentację lub rekomendację powstałą z pomocą AI;
• jak placówka zbada incydent, wstrzyma działanie narzędzia albo całkowicie je wycofa, gdy pojawi się zagrożenie.

Dwa poziomy nadzoru nad AI

Aby wzmocnić odpowiedzialność, autorzy proponują dwa uzupełniające się poziomy nadzoru.

Zespoły ds. zarządzania AI w placówkach

Szpitale i inne organizacje ochrony zdrowia powinny korzystać z wyspecjalizowanych zespołów, które zatwierdzałyby narzędzia AI, oceniały je lokalnie, określały zakres odpowiedzialności i nadzorowały ich działanie. Dzięki temu decyzje uwzględniałyby konkretnych pacjentów, procedury, infrastrukturę i obowiązki zawodowe danej placówki.

Centralne centra operacji bezpieczeństwa AI

Przegląd rekomenduje także scentralizowane centra operacji bezpieczeństwa AI — AI Security Operations Centers (SOCs). Ich zadaniem byłoby wykrywanie incydentów w wielu organizacjach, wymiana informacji o zagrożeniach i koordynowanie reakcji. Atak lub awaria w jednym systemie klinicznym może bowiem ujawnić szerszą lukę, która dotyczy także innych placówek.

Połączenie obu poziomów ma zapewnić lokalną odpowiedzialność kliniczną oraz szerszą wymianę wiedzy o cyberzagrożeniach.

Dlaczego obecne regulacje mogą nie wystarczać?

Tradycyjne przepisy dotyczące wyrobów medycznych tworzono w dużej mierze z myślą o produktach, które można ocenić jako względnie stabilne. Oprogramowanie wykorzystujące AI może działać inaczej: jego zachowanie i profil ryzyka mogą się zmieniać wraz z aktualizacjami modelu, zmianami w rozkładzie danych, ewolucją procesów klinicznych i pojawianiem się nowych technik ataku.

Powstaje w ten sposób luka regulacyjna. Ocena lub zgoda wydana w jednym momencie nie gwarantuje automatycznie, że system pozostanie bezpieczny w każdym późniejszym środowisku. Szersze prace badaczy z TU Dresden dotyczące regulacji medycznej AI również wskazują, że nauka o regulacjach musi nadążać za szybko rozwijającymi się technologiami.

Dla placówek oznacza to, że wdrożenie powinno być początkiem nadzoru, a nie jego końcem. Kontrole powinny stale obejmować skuteczność, bezpieczeństwo, cyberbezpieczeństwo, prywatność i równe traktowanie pacjentów. Potrzebne są także procedury zgłaszania incydentów oraz zawieszania działania systemu, gdy wymaga tego sytuacja.

Zgoda pacjenta to element bezpieczeństwa technicznego

Problemy opisane w przeglądzie widać również przy stosowaniu asystentów AI do sporządzania dokumentacji medycznej. Australijskie wytyczne kliniczne mówią, że pacjenci powinni być poinformowani o celu i zakresie użycia systemu, jego korzyściach i ryzykach oraz sposobach monitorowania bezpieczeństwa i działania. Jednocześnie odpowiedzialność za opiekę i dokumentację przygotowaną z pomocą AI nadal spoczywa na lekarzu.

Wytyczne australijskiego środowiska lekarzy rodzinnych podkreślają ponadto, że lekarz powinien rozumieć działanie asystenta, przetestować go, uzyskać zgodę przed każdym użyciem, chronić przechowywane dane i upewnić się, że dokumentacja prawidłowo odzwierciedla przebieg konsultacji.

Najnowsze doniesienia wskazują na duże różnice w sposobie uzyskiwania zgody w australijskich placówkach. W niektórych przypadkach za wystarczającą uznawano jedynie informację na tablicy w poczekalni. Australijski regulator medyczny przypomniał również, że lekarze muszą sprawdzać poprawność wszystkich treści wygenerowanych przez asystenta AI.

Nie ma dowodów pozwalających stwierdzić, jak powszechne są niewystarczająca zgoda lub brak odpowiedniego zrozumienia technologii w całej Australii. Przykłady te wzmacniają jednak szerszy argument autorów przeglądu: przejrzystość, ludzki nadzór i odpowiedzialność organizacyjna są praktycznymi zabezpieczeniami, a nie formalnościami dopisywanymi po wdrożeniu.

Co z tego wynika dla placówek medycznych?

Wnioski z przeglądu nie są odrzuceniem klinicznej AI, lecz propozycją standardu wdrażania. Duże modele językowe mogą wspierać wartościowe procesy, ale należy traktować je jako zmieniające się systemy społeczno-techniczne, a nie zwykłe programy komputerowe.

Przed wdrożeniem i po nim osoby zarządzające ochroną zdrowia powinny być gotowe oceniać model, zabezpieczać infrastrukturę, szkolić użytkowników, informować pacjentów o udziale AI, monitorować działanie narzędzia w praktyce i jasno wskazywać, kto może zareagować, gdy system zawiedzie. Bez takich kontroli wykorzystanie AI w medycynie nadal będzie wyprzedzać nadzór potrzebny do tego, by można było uznać je za godne zaufania.

Ryzyko klinicznej AI obejmuje cały cykl życia

Przegląd porządkuje zagrożenia na wielu etapach wdrażania i stosowania AI w ochronie zdrowia:

• Projektowanie i dane treningowe: zmanipulowane lub „zatrute” dane mogą zmienić zachowanie systemu jeszcze zanim trafi on do placówki medycznej.
• Wdrożenie i interfejsy: atak typu prompt injection może wprowadzić do procesu pracy złośliwe instrukcje. Autorzy wskazują między innymi na możliwość, że model przeoczy widoczny guz, jeśli atak wpłynie na sposób interpretacji obrazu lub informacji klinicznej. Podatna infrastruktura informatyczna szpitala może także zakłócić udzielanie świadczeń albo doprowadzić do ujawnienia danych pacjentów.
• Zachowanie modelu: duże modele językowe potrafią generować przekonujące, lecz nieprawdziwe informacje medyczne — tak zwane halucynacje. Mogą również zbyt łatwo przyjmować założenia użytkownika i wzmacniać błędną przesłankę zamiast ją zakwestionować.
• Relacja człowiek–AI: przekonujące odpowiedzi mogą sprzyjać automatyzacji poznawczej, czyli zbyt łatwemu podporządkowaniu się sugestii systemu, oraz błędowi potwierdzenia, gdy lekarz wykorzystuje AI do poparcia wcześniej przyjętej diagnozy lub opinii.
• Wykorzystanie instytucjonalne: personel może sięgać po publiczne albo niezatwierdzone narzędzia bez formalnej zgody placówki. Takie „ukryte użycie” (shadow use) może omijać zabezpieczenia prywatności, lokalne testy, zasady odpowiedzialności i procedury zgłaszania incydentów.

To spojrzenie na cały cykl życia ma praktyczne znaczenie. System może dobrze wypaść w kontrolowanym teście, a mimo to okazać się niebezpieczny w codziennej pracy. Ostateczny wynik zależy także od bezpieczeństwa infrastruktury, zachowań ludzi, kontekstu klinicznego i kontroli organizacyjnych.

Jak powinno wyglądać odpowiedzialne wdrożenie?

Zdaniem autorów zabezpieczenia muszą działać także po uruchomieniu narzędzia. Potrzebne są między innymi bezpieczny proces tworzenia oprogramowania, kontrola jakości i pochodzenia danych treningowych, testy w konkretnej placówce i w rzeczywistym kontekście klinicznym, jasno określone obowiązki człowieka oraz stałe monitorowanie wyników i incydentów.

Szpital lub przychodnia powinny więc ustalić nie tylko, czy narzędzie generuje wiarygodnie brzmiący tekst. Konieczne jest również określenie:

• kto może korzystać z systemu i do jakich zadań;
• do jakich danych ma on dostęp i gdzie te dane są przetwarzane;
• w jaki sposób lekarze i inni pracownicy mają weryfikować jego wyniki;
• kto odpowiada za błędną dokumentację lub rekomendację powstałą z pomocą AI;
• jak placówka zbada incydent, wstrzyma działanie narzędzia albo całkowicie je wycofa, gdy pojawi się zagrożenie.

Dwa poziomy nadzoru nad AI

Aby wzmocnić odpowiedzialność, autorzy proponują dwa uzupełniające się poziomy nadzoru.

Zespoły ds. zarządzania AI w placówkach

Szpitale i inne organizacje ochrony zdrowia powinny korzystać z wyspecjalizowanych zespołów, które zatwierdzałyby narzędzia AI, oceniały je lokalnie, określały zakres odpowiedzialności i nadzorowały ich działanie. Dzięki temu decyzje uwzględniałyby konkretnych pacjentów, procedury, infrastrukturę i obowiązki zawodowe danej placówki.

Centralne centra operacji bezpieczeństwa AI

Przegląd rekomenduje także scentralizowane centra operacji bezpieczeństwa AI — AI Security Operations Centers (SOCs). Ich zadaniem byłoby wykrywanie incydentów w wielu organizacjach, wymiana informacji o zagrożeniach i koordynowanie reakcji. Atak lub awaria w jednym systemie klinicznym może bowiem ujawnić szerszą lukę, która dotyczy także innych placówek.

Połączenie obu poziomów ma zapewnić lokalną odpowiedzialność kliniczną oraz szerszą wymianę wiedzy o cyberzagrożeniach.

Dlaczego obecne regulacje mogą nie wystarczać?

Tradycyjne przepisy dotyczące wyrobów medycznych tworzono w dużej mierze z myślą o produktach, które można ocenić jako względnie stabilne. Oprogramowanie wykorzystujące AI może działać inaczej: jego zachowanie i profil ryzyka mogą się zmieniać wraz z aktualizacjami modelu, zmianami w rozkładzie danych, ewolucją procesów klinicznych i pojawianiem się nowych technik ataku.

Powstaje w ten sposób luka regulacyjna. Ocena lub zgoda wydana w jednym momencie nie gwarantuje automatycznie, że system pozostanie bezpieczny w każdym późniejszym środowisku. Szersze prace badaczy z TU Dresden dotyczące regulacji medycznej AI również wskazują, że nauka o regulacjach musi nadążać za szybko rozwijającymi się technologiami.

Dla placówek oznacza to, że wdrożenie powinno być początkiem nadzoru, a nie jego końcem. Kontrole powinny stale obejmować skuteczność, bezpieczeństwo, cyberbezpieczeństwo, prywatność i równe traktowanie pacjentów. Potrzebne są także procedury zgłaszania incydentów oraz zawieszania działania systemu, gdy wymaga tego sytuacja.

Zgoda pacjenta to element bezpieczeństwa technicznego

Problemy opisane w przeglądzie widać również przy stosowaniu asystentów AI do sporządzania dokumentacji medycznej. Australijskie wytyczne kliniczne mówią, że pacjenci powinni być poinformowani o celu i zakresie użycia systemu, jego korzyściach i ryzykach oraz sposobach monitorowania bezpieczeństwa i działania. Jednocześnie odpowiedzialność za opiekę i dokumentację przygotowaną z pomocą AI nadal spoczywa na lekarzu.

Wytyczne australijskiego środowiska lekarzy rodzinnych podkreślają ponadto, że lekarz powinien rozumieć działanie asystenta, przetestować go, uzyskać zgodę przed każdym użyciem, chronić przechowywane dane i upewnić się, że dokumentacja prawidłowo odzwierciedla przebieg konsultacji.

Najnowsze doniesienia wskazują na duże różnice w sposobie uzyskiwania zgody w australijskich placówkach. W niektórych przypadkach za wystarczającą uznawano jedynie informację na tablicy w poczekalni. Australijski regulator medyczny przypomniał również, że lekarze muszą sprawdzać poprawność wszystkich treści wygenerowanych przez asystenta AI.

Nie ma dowodów pozwalających stwierdzić, jak powszechne są niewystarczająca zgoda lub brak odpowiedniego zrozumienia technologii w całej Australii. Przykłady te wzmacniają jednak szerszy argument autorów przeglądu: przejrzystość, ludzki nadzór i odpowiedzialność organizacyjna są praktycznymi zabezpieczeniami, a nie formalnościami dopisywanymi po wdrożeniu.

Co z tego wynika dla placówek medycznych?

Wnioski z przeglądu nie są odrzuceniem klinicznej AI, lecz propozycją standardu wdrażania. Duże modele językowe mogą wspierać wartościowe procesy, ale należy traktować je jako zmieniające się systemy społeczno-techniczne, a nie zwykłe programy komputerowe.

Przed wdrożeniem i po nim osoby zarządzające ochroną zdrowia powinny być gotowe oceniać model, zabezpieczać infrastrukturę, szkolić użytkowników, informować pacjentów o udziale AI, monitorować działanie narzędzia w praktyce i jasno wskazywać, kto może zareagować, gdy system zawiedzie. Bez takich kontroli wykorzystanie AI w medycynie nadal będzie wyprzedzać nadzór potrzebny do tego, by można było uznać je za godne zaufania.