---
title: "Brak incydentu nie dowodzi bezpieczeństwa: jak monitorować AI w gabinecie?
"
description: "Jak monitorować rzadkie zdarzenia AI w gabinecie: rejestr użyć, near missów, decyzji lekarza i progów eskalacji dla polskiej placówki.
"
image: "https://ai4med.pl/img/ai-rejestr-zdarzen-rzadkich.jpg"
date: 2026-07-18
author: Jacek Wyderka
category: AI w pracy lekarza
tags: bezpieczeństwo AI, monitorowanie AI, zdarzenia bliskie szkody, nadzór lekarza, gabinet lekarski, pilotaż AI
url: "https://ai4med.pl/ai-w-pracy-lekarza/ai-rejestr-zdarzen-rzadkich"
inLanguage: pl
---

# Brak incydentu nie dowodzi bezpieczeństwa: jak monitorować AI w gabinecie?


## W skrócie

- **Zero zgłoszonych incydentów nie jest dowodem bezpieczeństwa** — bez liczby użyć i wspólnej definicji sygnału może oznaczać także ciszę w raportowaniu.
- **Rejestr powinien rozdzielać użycie, sygnał, zdarzenie bliskie szkody i zdarzenie wymagające reakcji**, bez wpisywania historii choroby ani danych identyfikujących pacjenta.
- **Lekarz ocenia znaczenie kliniczne i może wstrzymać użycie narzędzia**; AI nie klasyfikuje własnego błędu ani nie decyduje o dalszym postępowaniu.

Nie zatwierdzaj dalszego użycia AI w gabinecie tylko dlatego, że w rejestrze widnieje **zero incydentów**. Bez **mianownika użyć**, krótkiego kanału zgłoszenia i osoby oceniającej to zero może znaczyć bezpieczeństwo, ale równie dobrze zbyt mało obserwacji albo brak języka do opisania problemu.

Świeże badanie z Kenii dotyczyło konkretnego systemu wsparcia decyzji klinicznych, działającego w podstawowej opiece ambulatoryjnej. Nie wykazało **istotnej różnicy w 14-dniowych niepowodzeniach leczenia** ani poważnych szkód przypisanych narzędziu, lecz autorzy zaznaczyli, że obserwacja miała ograniczoną zdolność wykrycia rzadkich ciężkich zdarzeń. **Brak różnicy nie jest dowodem równoważności bezpieczeństwa** — a tym bardziej nie jest wynikiem, który można przenieść z Kenii do polskiego gabinetu.

Dla prywatnej placówki w Polsce praktyczny wniosek jest prostszy niż kopiowanie liczb z badania: **proces ma wychwytywać słabe sygnały przed skutkiem dla pacjenta**, a **lekarz ma realną możliwość zmiany albo zatrzymania działania**. Rejestr nie zastępuje obowiązków producenta ani formalnego zgłoszenia, gdy narzędzie jest wyrobem medycznym; jest wewnętrzną metodą, by szybciej zobaczyć, czego zespół jeszcze nie wie.

## Najważniejsze

- **Licznik incydentów bez licznika użyć jest niemiarodajny.** Zespół nie wie, czy brak wpisów wynika z małej ekspozycji, dobrej jakości czy niewychwyconych sygnałów.
- **Near miss ma wartość przed szkodą.** Wpis o sugestii zatrzymanej przez lekarza pozwala poprawić proces bez czekania na poważne zdarzenie.
- **Każdy wpis potrzebuje właściciela oceny.** AI może ułatwić porządkowanie logu, ale nie może samodzielnie ocenić swojego wpływu klinicznego.
- **Wstrzymanie narzędzia musi mieć prosty próg i ścieżkę.** Nie jest automatyczną decyzją medyczną, tylko zabezpieczonym zatrzymaniem procesu do czasu oceny przez uprawnioną osobę.
- **Przy oprogramowaniu będącym wyrobem medycznym** wewnętrzny rejestr uzupełnia, a nie zastępuje ścieżkę zgłoszenia do producenta i — przy poważnym incydencie — do URPL.

## Zero wpisów nie mówi jeszcze, co się wydarzyło

W praktyce często myli się **brak zgłoszenia** z **brakiem problemu**. Tymczasem narzędzie mogło być użyte kilka razy, zespół mógł poprawić sugestię bez śladu albo personel mógł nie wiedzieć, że korekta powinna trafić do wspólnego rejestru. W praktyce te wpisy są niepozorne, dlatego łatwo je pominąc przy zamykaniu dnia.

W badaniu opublikowanym 26 czerwca 2026 r. rzadkie ciężkie zdarzenia były z definicji trudne do uchwycenia w dostępnej skali obserwacji. To cenna lekcja metodologiczna, nie recepta dla polskiej placówki: **nie przenosimy ani wyniku klinicznego, ani wskaźników liczbowych**, lecz **zasadę oddzielenia obserwacji od dowodu bezpieczeństwa**. Zanim manager uzna pilotaż za spokojny, powinien zapytać: ile było użyć, ile korekt, ile eskalacji i kto przejrzał przypadki graniczne.

Do samego podziału ról warto odnieść zasady z artykułu o [human-in-the-loop w placówce medycznej](/dane-i-bezpieczenstwo/kontrola-czlowieka-ai). Ten tekst idzie krok dalej: nie opisuje wszystkich decyzji, lecz pokazuje, jak zapisać i odczytać sygnał, zanim rozmyje się w codziennym rytmie pracy.

## Co odróżnia sygnał od zdarzenia

Rejestr nie musi być rozbudowanym systemem klasy bezpieczeństwa lotniczego. Musi za to mieć **jednoznaczne nazwy** i **brak danych pacjenta w opisie roboczym**. Zamiast kopiować notatkę z wizyty, wpisuj kategorię procesu, wersję narzędzia, typ sygnału oraz to, kto podjął ocenę.

| Element wpisu | Co zapisać bez danych pacjenta | Kto dokonuje oceny | Następne działanie |
| --- | --- | --- | --- |
| Użycie | Funkcja AI, wersja, data i rola użytkownika | Właściciel procesu | Zasila mianownik obserwacji |
| Sygnał | Niespójna lub niejasna sugestia zauważona przez personel | Osoba wyznaczona przez kierownika medycznego | Ocena, czy potrzebne są dodatkowe przykłady |
| Zdarzenie bliskie szkody | Sugestia mogła wpłynąć na tok pracy, lecz lekarz zatrzymał ją przed użyciem | Lekarz lub kierownik medyczny | Analiza przyczyny i decyzja o korekcie procesu |
| Zdarzenie wymagające reakcji | Możliwy wpływ na decyzję kliniczną albo bezpieczeństwo procesu | Lekarz z odpowiednimi uprawnieniami | Eskalacja według procedury placówki i zasad dostawcy |

**Zdarzenie bliskie szkody** nie jest porażką osoby, która zgłasza. Jest materiałem do nauki o tym, gdzie interfejs, instrukcja albo zakres użycia prowadzą zespół w złą stronę. **Ocena znaczenia klinicznego pozostaje po stronie lekarza**, a opis nie powinien zawierać PESEL-u, imienia ani pełnej historii choroby.

Jeżeli oprogramowanie ma status wyrobu medycznego, URPL wskazuje, że incydent może obejmować również wadliwe działanie, błąd użytkowy czy nieprawidłową informację producenta — nie musi czekać na konkretną szkodę. **Wewnętrzny wpis nie rozstrzyga statusu prawnego**, ale pozwala przygotować fakty do właściwego działania i zachować ślad, kto je ocenił.

## Rejestr musi liczyć także użycia

Sam opis sygnałów nie wystarcza, jeśli placówka nie wie, jak często narzędzie pracowało. **Mianownik użyć nadaje sens liczbie zgłoszeń**, a **czas do oceny lekarza pokazuje, czy nadzór działa w realnym rytmie gabinetu**. Nie ustawiaj od razu targetu „zero”; najpierw zbierz własny punkt odniesienia i sprawdź, czy sposób rejestrowania jest konsekwentny.

| KPI bezpieczeństwa | Jak ją liczyć | Pytanie dla kierownika medycznego |
| --- | --- | --- |
| Kompletność obserwacji | Odsetek użyć zapisanych z funkcją i właścicielem | Czy wiemy, czego dotyczy licznik? |
| Sygnały na 100 użyć | Liczba sygnałów podzielona przez liczbę użyć | Czy wzrost wynika z problemu, czy z lepszego zgłaszania? |
| Czas do oceny | Czas od wpisu do decyzji lekarza | Czy przypadek graniczny czeka zbyt długo? |
| Zamknięte działania korygujące | Odsetek wpisów z udokumentowaną decyzją i terminem sprawdzenia | Czy rejestr prowadzi do zmiany, a nie do archiwum? |

Te metryki nie oceniają kompetencji lekarza ani nie są obietnicą poprawy wyników leczenia. **Pomagają zobaczyć jakość kontroli**, a **nie zastępują walidacji klinicznej narzędzia przez producenta i właściwe osoby w placówce**. Warto też rozdzielić zmianę wersji, zmianę instrukcji i zmianę procesu, bo każda z nich może zmienić kontekst wpisów.

## Jeden dyżur, jedna ocena człowieka

Wyobraźmy sobie poradnię specjalistyczną, w której narzędzie AI tworzy robocze podsumowania dokumentacji po wizycie. Lekarz zauważa, że jedno podsumowanie pominęło informację wymagającą sprawdzenia przed zatwierdzeniem dokumentu. **Sugestia nie została wykorzystana jako gotowa decyzja kliniczna**, a **lekarz zatrzymał ją i poprawił przed podpisaniem**.

Do rejestru trafia tylko kategoria funkcji, wersja, typ pominięcia, fakt zatrzymania oraz rola osoby oceniającej. Nie ma w nim danych pacjenta ani treści dokumentacji. Zespół, powinien zapisać obserwację zanim zacznie dyskutować o przyczynie; dzięki temu po kilku podobnych wpisach można sprawdzić, czy problem dotyczy konkretnej wersji, instrukcji użycia czy szkolenia.

To właśnie jest human-in-the-loop w praktyce: **człowiek ma czas i uprawnienie, by odrzucić sugestię**, a **placówka widzi wzorzec korekt zamiast pojedynczej anegdoty**. AI może technicznie zgrupować neutralne kategorie wpisów, ale nie może ocenić, czy korekta miała znaczenie kliniczne, ani samodzielnie zamknąć działania korygującego.

## Kiedy lekarz zatrzymuje proces

**To ma sens, gdy…** zespół z góry ustalił pięć sygnałów wymagających wpisu, ma wskazanego lekarza oceniającego i potrafi odtworzyć, ile razy użyto danej funkcji. Wtedy rejestr daje podstawę do ostrożnego rozwoju procesu, a nie do deklaracji, że narzędzie jest już bezpieczne.

**To nie ma sensu, gdy…** rejestr powstaje dopiero po problemie, wszystkie korekty są opisywane jako „błąd użytkownika”, a nikt nie ma prawa wstrzymać funkcji do czasu oceny. **Brak progu eskalacji tworzy pozorny nadzór**, zaś **automatyczna zmiana postępowania klinicznego na podstawie wpisu AI byłaby przekroczeniem roli narzędzia**.

Próg może być prosty: powtarzalny near miss, niezgodność po aktualizacji albo sygnał dotyczący decyzji klinicznej uruchamia zawieszenie użycia danej funkcji i przegląd przez lekarza oraz właściciela procesu. **Wstrzymanie chroni proces, nie wydaje diagnozy**, a jego zniesienie powinno wynikać z udokumentowanej oceny, nie z presji, by „wrócić do normalności”.

## Pierwsze pięć sygnałów na wspólne spotkanie

Na pierwszym spotkaniu lekarz i manager mogą wspólnie zdefiniować: pominięcie istotnego elementu, niespójną sugestię, korektę przez człowieka, nieoczekiwane działanie po aktualizacji oraz zdarzenie wymagające eskalacji. **Pięć prostych kategorii jest lepsze niż pusty formularz**, a **właściciel rejestru powinien być znany przed pierwszym użyciem narzędzia**.

Nie zaczynaj od gromadzenia pełnej dokumentacji w dodatkowym arkuszu. Zacznij od neutralnych kategorii, daty, wersji i decyzji o dalszym kroku; dane pacjenta zostają w zatwierdzonych systemach placówki. Przed zakupem lub rozszerzeniem użycia warto też sprawdzić, czy dostawca potrafi pokazać dowody i ścieżkę nadzoru — pomocny jest materiał o [dowodach przed zakupem narzędzia AI](/narzedzia-i-wdrozenia/eudamed-ai-dowody).

## Źródła

- [Agweyu i in., Nature Medicine — „Generative AI-enabled clinical decision support system in primary care: a pragmatic, cluster-randomized trial”](https://www.nature.com/articles/s41591-026-04503-6) — świeże badanie z 16 placówek podstawowej opieki w Kenii pokazuje ograniczenie obserwacji rzadkich ciężkich zdarzeń; wnosi metodologiczną przestrogę, a nie wynik do przeniesienia na polski gabinet. Opublikowano: 26 czerwca 2026 r.; Sprawdzono: 2026-07-15.
- [He i in., npj Digital Medicine — „Clinical outcomes and reporting quality of large language model interventions in practice: a systematic evidence map”](https://www.nature.com/articles/s41746-026-02837-6) — mapa 55 badań wskazuje niejednorodne wyniki i braki w raportowaniu jakości danych oraz błędów; materiał jest wczesną wersją, dlatego nie stanowi normy prawnej. Opublikowano: 2 czerwca 2026 r.; Sprawdzono: 2026-07-15.
- [URPL — Zgłoszenie Incydentu Medycznego (ZIM)](https://www.gov.pl/web/urpl/zgloszenie-incydentu-medycznego-zim) — polskie źródło urzędowe wyjaśnia definicję incydentu i kanał zgłoszenia dla wyrobu medycznego; pomaga odróżnić rejestr wewnętrzny od obowiązków wobec producenta i URPL. Sprawdzono: 2026-07-15.
- [URPL — zewnętrzne działania korygujące dotyczące bezpieczeństwa (FSCA)](https://www.gov.pl/web/urpl/zewnetrzne-dzialania-korygujace-dotyczace-bezpieczenstwa-fsca) — oficjalnie opisuje działania ograniczające ryzyko przy wyrobach medycznych i obowiązek zastosowania się do notatki bezpieczeństwa przez użytkownika. Sprawdzono: 2026-07-15.
- Okładka: [Tima Miroshnichenko na Pexels](https://www.pexels.com/photo/microscope-beside-a-computer-9574561/)