Gdy voicebot (automatyczny asystent głosowy odbierający telefon), moduł podsumowujący dokumentację albo inne narzędzie AI nagle przestaje odpowiadać, placówka traci nie tylko aplikację — może stracić uzgodniony sposób obsługi pacjentów. Manager powinien wcześniej przypisać krytycznemu procesowi tryb ręczny, dopuszczalny czas przerwy, kanał komunikacji i osobę zatwierdzającą powrót, a potem sprawdzić ten układ podczas krótkiej próby bez AI. Ten poradnik pokazuje, jak podjąć te decyzje dla jednego procesu, zamiast pisać ogólną procedurę na każdą możliwą awarię.
Plan ciągłości działania to spisany sposób utrzymania najważniejszej pracy, gdy używana usługa jest niedostępna lub działa niewiarygodnie. Uruchamia się go nie tylko przy całkowitym braku odpowiedzi, lecz także wtedy, gdy wyniki przychodzą z takim opóźnieniem, że personel nie może na nich polegać, albo gdy dostawca uruchomił wersję, której placówka jeszcze nie dopuściła.
W takim planie AI nie decyduje, czy samo jest gotowe do pracy. Narzędzie może po powrocie przygotować wynik testowy, ale człowiek sprawdza go, rozlicza sprawy obsłużone ręcznie i dopiero wtedy przywraca normalny proces. To szczególnie ważne w polskiej placówce, gdzie niedostępność administracyjnej pomocy AI nie może obniżyć wymagań wobec dokumentacji, ochrony danych ani decyzji klinicznych.
Który proces placówki nie może czekać na powrót AI?
Najpierw nazwij proces placówki, nie nazwę produktu. Asystent głosowy może wspierać rejestrację, model może porządkować wiadomości, a skryba AI — czyli narzędzie tworzące szkic notatki po wizycie — wspierać dokumentację. Ciągłości wymaga jednak przyjmowanie zgłoszeń, przekazywanie pilnych spraw, dokumentowanie wykonanych czynności albo uzgodnienie informacji po wizycie — zależnie od tego, gdzie placówka używa narzędzia.
Dla jednego procesu manager określa dopuszczalny czas przerwy. Nie istnieje uniwersalna liczba dla wszystkich przychodni. Kilka minut bez podpowiedzi do wewnętrznego raportu może nie zmienić pracy, podczas gdy przerwa w obsłudze telefonu w godzinach szczytu szybko tworzy kolejkę, której zespół nie odrobi tego samego dnia. Limit ma więc wynikać ze skutku dla pacjenta, obciążenia personelu i możliwości bezpiecznej pracy ręcznej.
Dopiero potem ustal sygnał przejścia na tryb ręczny. Może nim być brak odpowiedzi przez ustalony czas, seria błędów, rozbieżność między wersją zgłoszoną przez dostawcę a wersją dopuszczoną lokalnie albo brak możliwości potwierdzenia, gdzie trafiają dane. Jeżeli pracownik musi zgadywać, czy awaria już trwa, decyzja została podjęta za późno.
Proces jest naprawdę krytyczny wtedy, gdy jego zatrzymanie wpływa na udzielanie świadczeń, bezpieczeństwo informacji lub zdolność placówki do kontaktu z pacjentem. Nie każdy moduł AI zasługuje na rozbudowany plan, ale każdy używany w krytycznym procesie musi mieć realną drogę obejścia.
Co personel robi w pierwszych minutach awarii?
Wyobraźmy sobie przychodnię, w której taki asystent głosowy odbiera część połączeń przed otwarciem rejestracji. O 7:45 przestaje zwracać potwierdzenia. Nie wiadomo jeszcze, czy problem dotyczy łącza, dostawcy czy nowej wersji usługi. Rejestratorka widzi tylko rosnącą liczbę niezamkniętych spraw.
Pierwszą decyzją nie jest diagnozowanie infrastruktury przez recepcję. Wyznaczony manager ogłasza tryb ręczny, zapisuje godzinę i zakres problemu oraz wstrzymuje automatyczne potwierdzenia, których poprawności nie można sprawdzić. Rejestracja przechodzi na przygotowany kanał: odbiera połączenia, zapisuje status sprawy w miejscu wcześniej wybranym przez placówkę — na przykład w dopuszczonym systemie gabinetowym albo na przygotowanym papierowym formularzu — i przekazuje pytania medyczne osobie z odpowiednimi uprawnieniami. AI nie ustala priorytetu klinicznego ani nie odpowiada w imieniu lekarza.
Równolegle placówka wskazuje jeden kanał komunikacji o stanie awarii. Personel dostaje krótki komunikat: co nie działa, jaki tryb obowiązuje i kiedy będzie następna aktualizacja. Pacjent słyszy neutralną informację o przejściowej niedostępności i alternatywnym kontakcie; placówka nie spekuluje publicznie o przyczynie ani nie prosi o przesyłanie danych zdrowotnych przypadkowym kanałem.
Amerykański rządowy portal gotowości kryzysowej dla ochrony zdrowia publikuje listę działań dla szpitala podczas przestoju. Podkreśla dostępne instrukcje, alternatywną komunikację oraz bezpieczne porządkowanie dokumentów. Nie jest to polska procedura ani instrukcja dla małej przychodni, lecz trafnie pokazuje zasadę: materiały potrzebne podczas awarii muszą być dostępne wtedy, gdy główny system właśnie nie działa.
Po kilkunastu minutach wiadomo, które sprawy weszły ręcznie i kto je prowadzi. Zespół nie próbuje utrzymać całego zakresu automatyzacji za wszelką cenę. Ogranicza nowe zobowiązania do tego, co może bezpiecznie wykonać i później rozliczyć, dzięki czemu powrót systemu nie tworzy drugiej awarii w postaci duplikatów i sprzecznych potwierdzeń.
Dlaczego kopia danych nie zastępuje trybu ręcznego?
Kopia danych pomaga odtworzyć informacje, ale nie mówi ludziom, jak pracować w czasie przerwy. Nie określa, kto ogłasza zmianę trybu, gdzie personel zapisuje nowe sprawy, jak pacjent otrzymuje informację ani kto porówna ręczne wpisy z kolejką po powrocie. Dlatego kopia zapasowa jest jednym zabezpieczeniem technicznym, a plan ciągłości — decyzją organizacyjną.
Poniższą kartę wykorzystaj dla jednego procesu. Manager wypełnia każdy wiersz razem z osobą wykonującą pracę i dostawcą, a później sprawdza decyzje podczas krótkiej próby bez narzędzia AI. Dowodem gotowości ma być wykonana czynność, nie samo pole oznaczone jako gotowe.
| Pole planu | Decyzja placówki | Dowód gotowości |
|---|---|---|
| Proces krytyczny | Jaka praca ma być utrzymana mimo braku AI | Zespół potrafi opisać, co rozpoczyna pracę, jaki ma być wynik i kto za nią odpowiada |
| Sygnał przejścia na tryb ręczny | Po jakim czasie lub jakim sygnale przestajemy ufać usłudze | Pracownik rozpoznaje sygnał bez pytania dostawcy o zgodę |
| Dopuszczalna przerwa | Jak długo proces może czekać, zanim ograniczymy zakres pracy | Manager umie wskazać decyzję po przekroczeniu limitu |
| Kanał i zapis ręczny | Gdzie trafiają nowe sprawy oraz kto je chroni i porządkuje | Personel wykonuje próbę bez użycia publicznego narzędzia |
| Komunikacja | Kto informuje zespół, pacjentów i dostawcę | Gotowy komunikat podaje stan, kanał zastępczy i czas aktualizacji |
| Powrót do systemu | Jakie testy, wersja i osoba są wymagane przed startem | Osoba odpowiedzialna zatwierdza wynik testu i porównanie spraw zapisanych ręcznie ze sprawami w systemie |
Warto też zapytać dostawcę, czy przerwana czynność po powrocie zaczyna się od nowa, czy wraca do bezpiecznego punktu. Perspektywa opublikowana w TechRadar Pro wskazuje, że odporność systemu AI zależy między innymi od możliwości wznowienia pracy bez powtarzania wcześniej wykonanych kroków. To opinia techniczna dostawcy infrastruktury, nie standard medyczny, ale dla managera daje dobre pytanie zakupowe: czy ponowne uruchomienie może wysłać drugi komunikat, utworzyć drugi wpis albo ponownie wykonać zakończoną czynność?
Kto zatwierdza powrót narzędzia AI do pracy?
Zielony status u dostawcy nie jest jeszcze zgodą placówki na powrót. Najpierw administrator lub dostawca potwierdza zakres zdarzenia, aktualną wersję i stan połączeń. Następnie osoba odpowiedzialna za proces uruchamia test na danych syntetycznych, czyli przygotowanych do próby i niezawierających danych realnego pacjenta. Sprawdza wynik, opóźnienie, to, czy wykonanie zostało zapisane w systemie, oraz czy usługa nie powtarza zakończonej czynności.
Jeżeli awaria wiązała się ze zmianą wersji, placówka stosuje osobną kartę decyzji i test aktualizacji modelu. Test na danych syntetycznych powinien odtworzyć najważniejszy wariant procesu i jeden wyjątek, ale nie służy do potwierdzania skuteczności klinicznej na skróty. Jeśli narzędzie wspiera decyzję lekarza, dopuszczenie wyniku pozostaje po stronie uprawnionej osoby medycznej.
Po teście trzeba porównać listę spraw zapisanych ręcznie ze sprawami widocznymi po powrocie w systemie. Każda sprawa otrzymuje jeden status: zakończona ręcznie, czeka na wprowadzenie do systemu albo wymaga ponownego kontaktu. Dzięki temu żadna sprawa nie zostaje pominięta ani wykonana drugi raz. Dopiero wtedy osoba odpowiedzialna przywraca narzędzie najpierw tylko dla jednego procesu lub małej grupy pracowników, z możliwością natychmiastowego powrotu do pracy ręcznej. Lista działań tego samego amerykańskiego programu podobnie zaleca wskazanie osoby testującej, opisanie zakresu działających funkcji i uruchamianie odzyskanych usług najpierw w mniejszej części organizacji.
Zwykła niedostępność dostawcy i cyberincydent nie są tym samym. Jeśli pojawiają się oznaki oprogramowania blokującego dane dla okupu, nieautoryzowanego dostępu, wycieku albo nieuprawnionej zmiany danych, placówka uruchamia procedurę reagowania na incydent bezpieczeństwa i nie niszczy śladów przez wielokrotne wyłączanie i uruchamianie urządzeń. W praktyce przerywa używanie podejrzanej usługi, zgłasza zdarzenie wcześniej wyznaczonej osobie odpowiedzialnej za bezpieczeństwo i zachowuje dostępne dowody. Polski kontekst oraz plan pierwszego zgłoszenia opisuje materiał o zespole reagowania Centrum e-Zdrowia (CSIRT CeZ) i pierwszych 24 godzinach incydentu. Obowiązki zależą od statusu podmiotu i rodzaju zdarzenia; sam brak odpowiedzi usługi nie przesądza jeszcze o kwalifikacji prawnej.
Jak przetestować jeden proces bez narzędzia AI?
Pierwsza próba powinna dotyczyć jednego procesu i jednego zespołu, nie całej placówki. Wybierz spokojny termin, przygotuj kilka fikcyjnych spraw bez realnych danych pacjentów i uzgodnij moment wyłączenia. Manager obserwuje, czy personel rozpoznaje ustalony sygnał awarii, przechodzi na właściwy kanał, zapisuje czynności oraz wie, komu przekazać wyjątek.
W połowie próby dodaj jedną zmianę: dłuższy czas przerwy albo komunikat dostawcy o przywróceniu usługi w nieznanej wersji. Nie chodzi o zaskakiwanie ludzi. Chodzi o sprawdzenie, czy decyzja nadal wynika z planu, czy z presji, by jak najszybciej włączyć narzędzie. Przy procedurze bezpieczeństwa plan trzeba też przetestować, bo samo przeczytanie dokumentu nie ujawnia brakującego dostępu, telefonu ani kontaktu do dostawcy.
Zespół może wtedy zauważyć tarcia których nie widać podczas rozmowy przy stole: ręczny formularz nie ma właściciela, numer dostawcy jest w niedostępnym systemie, a komunikat dla pacjenta obiecuje termin, którego nikt nie kontroluje. Te obserwacje są wynikiem próby, nie porażką pracowników.
Sukces nie oznacza, że ręczny proces jest równie szybki jak automatyczny. Sukces oznacza kontrolowane ograniczenie usługi: personel wie, co utrzymuje, czego chwilowo nie obiecuje, gdzie zapisuje nowe sprawy i kto podejmuje decyzję o powrocie. Po próbie manager poprawia kartę, a nie dopisuje dziesięciu stron ogólnej procedury.
Jednoznaczny pierwszy krok jest prosty: dzisiaj wybierz jeden proces zależny od AI i umów 30 minutową próbę pracy bez narzędzia. Do zaproszenia dołącz tylko nazwę procesu, sygnał przejścia na tryb ręczny i osobę, która oceni powrót.
Kiedy nie wracać do narzędzia po awarii?
Warto przywrócić narzędzie najpierw w małym zakresie, gdy placówka ma dostęp do własnych danych potrzebnych do kontynuacji pracy, zna oznaczenie używanej wersji narzędzia AI, potrafi wyłączyć automatyczne komunikaty i ma osobę, która może ogłosić tryb ręczny. Nie zaczynaj ponownego uruchamiania narzędzia, gdy któregokolwiek z tych warunków brakuje. W takim układzie ponowne włączenie usługi zwiększa zależność, ale nie zwiększa odporności.
Zatrzymaj proces także wtedy, gdy tryb ręczny wymaga przenoszenia danych pacjenta do niezatwierdzonego kanału lub pozostawia decyzję kliniczną bez uprawnionego człowieka. Manager nie obniża wymagań bezpieczeństwa tylko dlatego, że dostawca ma awarię. Może ograniczyć liczbę obsługiwanych spraw, przełożyć czynność administracyjną albo skierować pacjenta do kanału kontaktu wcześniej wskazanego przez placówkę, lecz nie zastępuje oceny lekarza improwizowaną podpowiedzią AI.
Ostatnim sygnałem do zatrzymania jest brak wiarygodnego kryterium powrotu. Jeżeli jedynym argumentem jest to, że aplikacja znów się otwiera, placówka nie wie, czy działa właściwa wersja, czy wynik zapisuje się we właściwym miejscu i czy ręczna kolejka nie zostanie wykonana drugi raz. Ciągłość kończy się kontrolowanym powrotem, nie samym włączeniem systemu.
Źródła
- Centrum e-Zdrowia — Nowy bastion cyberbezpieczeństwa w ochronie zdrowia. Poznaj portal CSIRT CeZ — polskie oficjalne źródło o osobie kontaktowej, koordynacji i ścieżce zgłaszania incydentów; publikacja: 23.06.2026. Nie zastępuje lokalnego planu utrzymania świadczeń. Sprawdzono: 2026-08-18.
- Centrum e-Zdrowia — Działania prewencyjne po incydencie dotyczącym firmy MyDr — aktualny polski przykład monitorowania wpływu incydentu dostawcy, współpracy instytucjonalnej i skoordynowanej zmiany certyfikatów; publikacja: 14.08.2026. Materiał nie jest uniwersalną procedurą ciągłości. Sprawdzono: 2026-08-18.
- Amerykański rządowy portal gotowości kryzysowej — lista działań szpitala podczas przestoju — oficjalna amerykańska checklista przejścia na zmieniony tryb pracy, alternatywnej komunikacji i dokumentowania podczas przestoju. Karta zasobu: 18.08.2026; PDF ma Last-Modified 08.02.2021. To wzorzec operacyjny, nie polska podstawa prawna. Sprawdzono: 2026-08-18.
- Amerykański rządowy portal gotowości kryzysowej — lista przywracania systemów po incydencie — oficjalna checklista przywracania: priorytety usług, osoba testująca, status funkcji i ograniczony start; karta zasobu: 26.07.2026. Kontekst amerykańskich szpitali wymaga lokalnego dostosowania. Sprawdzono: 2026-08-18.
- HealthTech — Clinical Care Resilience Goes Beyond Having the Right Security Tools — perspektywa branżowa o ćwiczeniu pracy ręcznej, alternatywnej komunikacji i celach odtworzenia; publikacja: 14.07.2026. Autorką jest globalna CISO Check Point, więc materiał nie jest niezależnym badaniem ani regulacją. Sprawdzono: 2026-08-18.
- TechRadar Pro — Trustworthy AI Starts With Surviving Production Failures — opinia techniczna o wznawianiu przerwanych procesów AI, ograniczeniu dostępu i dowodach zachowania systemu podczas awarii; publikacja: 12.08.2026. Autor jest CTO dostawcy infrastruktury; tekst nie jest standardem medycznym. Sprawdzono: 2026-08-18.
- Okładka: Diana ✨ na Pexels