Aktualizacja modelu AI (zmiana wersji lub konfiguracji, która może zmienić zachowanie podpowiedzi) nie jest dla lekarza zwykłym komunikatem „system zaktualizowany”. Ta sama funkcja może po zmianie inaczej streszczać, klasyfikować albo podkreślać informacje, choć ekran wygląda identycznie. Dlatego po aktualizacji model powinien wrócić do użycia dopiero po zapisaniu wersji i zakresu zmiany, teście na syntetycznych przykładach, akceptacji właściciela klinicznego oraz ustaleniu obserwacji i warunku wycofania.
W polskiej placówce taka bramka nie ma zastępować dokumentacji producenta, oceny zgodności wyrobu medycznego ani odpowiedzialności dostawcy. Lekarz nie certyfikuje produktu. Sprawdza natomiast, czy opis zmiany pozwala bezpiecznie użyć narzędzia w konkretnym procesie i czy jego podpowiedź nadal da się rozpoznać jako wsparcie, a nie autonomiczną decyzję kliniczną.
Co naprawdę zmienia aktualizacja modelu AI?
Najpierw trzeba rozdzielić trzy rzeczy. Nowy numer modelu może oznaczać zmianę mechanizmu generowania odpowiedzi. Zmiana konfiguracji może obejmować instrukcje systemowe, progi, źródła wiedzy albo sposób prezentacji wyniku. Z kolei zwykła poprawka interfejsu nie musi zmieniać podpowiedzi klinicznej — lecz placówka nie powinna tego zgadywać.
Dostawca powinien wskazać, która wersja była używana wcześniej, która wchodzi teraz i jakie zastosowania obejmuje zmiana. Ogólne hasła typu „większa dokładność” albo „lepsze rozumowanie” nie wystarczą. Lekarz potrzebuje informacji, czy zmieniły się dane wejściowe, rodzaj wyniku, znane ograniczenia, sposób sygnalizowania niepewności lub instrukcja użycia.
WHO/Europe w czerwcu 2026 r. opisało lukę między zasadami a praktyką wdrożenia AI, a lipcowa debata o benchmarkach klinicznych w USA dopiero szuka wspólnych zasad oceny. Dla polskiej placówki nie jest to gotowa norma: komunikat o aktualizacji nadal nie dowodzi, że wersja pasuje do lokalnego procesu.
Karta decyzji o wersji: co zapisać przed pierwszym testem?
Poniższą kartę decyzji o wersji wypełnia się dla konkretnej funkcji, nie dla „AI w placówce” jako całości. Jeśli pole pozostaje puste, manager nie ma podstaw do przywrócenia tej funkcji w procesie lekarza.
| Pole | Minimalny zapis | Kto potwierdza |
|---|---|---|
| Wersja | poprzednia i nowa wersja modelu, konfiguracji oraz aplikacji | dostawca i właściciel techniczny |
| Zakres | proces, użytkownicy, dane wejściowe i rodzaj podpowiedzi objęte zmianą | manager procesu i lekarz |
| Opis zmiany | nowe działanie, ograniczenia, znane problemy i wpływ na instrukcję | dostawca; placówka sprawdza kompletność |
| Test | syntetyczne przypadki, oczekiwany sposób reakcji i kryterium odrzucenia | właściciel kliniczny |
| Obserwacja | okres ograniczonego użycia, sygnały do przeglądu i osoba analizująca | manager medyczny |
| Wycofanie | sposób powrotu do poprzedniej wersji albo przejścia na tryb ręczny | dostawca i właściciel procesu |
W małej placówce, taki rejestr nie potrzebuje osobnego systemu. Może być jednym kontrolowanym formularzem powiązanym z umową i rejestrem wersji. Ważniejsze od narzędzia jest to, by data, decyzja i osoba zatwierdzająca nie zniknęły w wątku e-mailowym.
Które testy lekarz wykonuje bez danych pacjenta?
Test lokalny nie powinien zaczynać się od prawdziwej historii choroby. Właściciel kliniczny przygotowuje kilka syntetycznych przykładów odpowiadających przeznaczeniu funkcji: przypadek typowy, niepełne wejście, sprzeczne informacje, element spoza zakresu oraz sytuację, w której model powinien odmówić lub skierować sprawę do człowieka. Dane są fikcyjne i nie pozwalają zidentyfikować pacjenta.
Dla każdego przykładu zapisuje się oczekiwany sposób zachowania: model ma zaznaczyć brak danych, zachować granicę zastosowania, nie dopisać faktu i pozostawić decyzję lekarzowi. Wynik porównuje się z poprzednią wersją, o ile jest dostępna, oraz z instrukcją dostawcy.
Zespół musi jednak umieć przetestowac zmianę przed powrotem do użycia. Jeżeli dostawca nie potrafi ujawnić identyfikatora wersji ani zakresu modyfikacji, lekarz może zobaczyć inną podpowiedź, ale nie odtworzy jej przyczyny. Wtedy bezpieczniejszym wynikiem testu jest wstrzymanie funkcji w tym procesie, a nie wymyślanie własnej certyfikacji.
Kto zatwierdza powrót modelu do pracy?
Dostawca opisuje zmianę, wersję, testy producenta i znane ograniczenia. Właściciel techniczny potwierdza wdrożoną wersję, a lekarz lub manager medyczny ocenia, czy funkcja mieści się w uzgodnionym procesie i czy jej wynik można sprawdzić przed użyciem.
Manager operacyjny zatwierdza sposób wdrożenia: komu funkcja będzie dostępna, przez jaki czas działa w ograniczonym zakresie i gdzie trafiają zgłoszenia. AI przygotowuje podpowiedź; lekarz interpretuje dane i odpowiada za decyzję kliniczną. Aktualizacja nie może przesunąć tej granicy po cichu.
Jeżeli narzędzie jest wyrobem medycznym, lokalna karta nie zastępuje obowiązków producenta, instrukcji użycia ani właściwej oceny zgodności. Wytyczne FDA o planach kontroli zmian są użytecznym wzorcem technicznym: wiążą opisaną modyfikację z walidacją, komunikacją do użytkownika, monitorowaniem oraz możliwością zatrzymania lub odwrócenia zmiany. Nie są jednak polską podstawą prawną.
Kiedy obserwować, a kiedy wycofać nową wersję?
Nowa wersja może wejść najpierw do ograniczonego zakresu: jednej funkcji lub małej grupy przeszkolonych użytkowników. Placówka rejestruje odrzucenia, istotne korekty i nieoczekiwane odpowiedzi — bez kopiowania nadmiarowych danych pacjenta.
Monitoring po dopuszczeniu rozwija osobny materiał o rejestrze zdarzeń rzadkich i near missów. Tutaj ważna jest wcześniejsza decyzja: co dokładnie spowoduje powrót do trybu ręcznego. Może to być brak identyfikowalnej wersji, odpowiedź poza przeznaczeniem, utrata źródła, powtarzalny błąd na przypadku syntetycznym lub brak możliwości odtworzenia poprzedniego działania.
Warto kontynuować obserwację, gdy dostawca opisał zmianę, testy nie wykazują rozjazdu z przeznaczeniem, lekarz widzi i zatwierdza każdą podpowiedź, a placówka potrafi wyłączyć funkcję. Zatrzymaj pilotaż, gdy wersja jest nieznana, zakres zmiany niejasny, wynik omija zatwierdzenie albo dostawca nie ma wykonalnej ścieżki wycofania.
O co zapytać dostawcę po aktualizacji?
Rozmowę można zamknąć w sześciu pytaniach. Każde powinno prowadzić do dokumentu, demonstracji albo testu, nie tylko odpowiedzi „tak”.
- Jaki jest identyfikator starej i nowej wersji modelu, konfiguracji oraz aplikacji?
- Które zastosowania, dane wejściowe i rodzaje wyniku zmieniły się względem poprzedniej wersji?
- Jakie testy producent wykonał przed wdrożeniem i które ograniczenia pozostają aktualne?
- Czy aktualizacja jest automatyczna, czy placówka może wybrać termin oraz ograniczyć grupę użytkowników?
- Jak dostawca monitoruje działanie po zmianie i w jaki sposób informuje o nowych problemach?
- Jak wyłączyć funkcję, wrócić do poprzedniej wersji lub bezpiecznie przejść na proces ręczny?
Pierwszy krok dla managera to nie test całego produktu. Weź jedną funkcję używaną przez lekarza, poproś o identyfikator wersji i opis różnic, a następnie wypełnij kartę do momentu, w którym można wskazać test, zatwierdzającego i warunek wycofania. Jeśli któregoś z tych elementów brakuje, nowa wersja nie jest jeszcze gotowa do powrotu do pracy.
Źródła
-
WHO/Europe — Bridging theory and practice: implementation insights on artificial intelligence in health care — raport z 26 czerwca 2026 r. o przełożeniu zasad wdrażania AI na praktykę ochrony zdrowia; stanowi europejskie tło dla governance, kompetencji i monitorowania. Sprawdzono: 2026-08-09.
-
WHO/Europe — WHO brings 37 countries together in Lisbon to get AI governance right — komunikat z 15 lipca 2026 r. wskazujący lukę między wdrażaniem AI a strategiami i odpowiedzialnością w ochronie zdrowia; nie opisuje polskiej placówki ani konkretnego produktu. Sprawdzono: 2026-08-09.
-
STAT Health Tech — HHS to convene experts on standards for clinical AI — materiał z 23 lipca 2026 r. o pracach nad zasadami benchmarkingu i oceny klinicznej AI; użyty jako sygnał trwającej debaty, nie jako polska norma. Sprawdzono: 2026-08-09.
-
FDA — Predetermined Change Control Plans for Machine Learning-Enabled Medical Devices: Guiding Principles — pierwotne wytyczne techniczne wiążące opis modyfikacji z walidacją, monitoringiem oraz mechanizmem zatrzymania lub odwrócenia zmiany; nie są prawem obowiązującym polską placówkę. Sprawdzono: 2026-08-09.
-
Okładka: Tima Miroshnichenko na Pexels