Algorytm w sztabie kryzysowym?

Jak wykorzystać AI i modele językowe w zarządzaniu kryzysowym, nie tracąc kontroli nad decyzją i danymi.

Pierwsza godzina poważnego zdarzenia wygląda w większości sztabów podobnie. Telefony, wiadomości na komunikatorach, meldunki z terenu, zdjęcia, pytania mediów, posty mieszkańców. Informacji jest za dużo, a jednocześnie brakuje tej jednej, potrzebnej do decyzji. Duże modele językowe (LLM), czyli technologia stojąca za popularnymi asystentami AI, potrafią w kilka sekund przeczytać, uporządkować i streścić materiał, nad którym oficer dyżurny pracowałby godzinę. To realna zmiana w ekonomii czasu sztabu. Jednocześnie to pierwsza technologia w zarządzaniu kryzysowym, która potrafi się mylić płynnie, przekonująco i bez ostrzeżenia. Dlatego pytanie nie brzmi już „czy”, tylko „na jakich warunkach”.

Co mówią badania?

Literatura na temat LLM w zarządzaniu kryzysowym urosła w ciągu dwóch lat z kilku pilotaży do dziesiątek publikacji. Przegląd w International Journal of Disaster Risk Reduction (Xu i in., 2025) analizuje 70 badań poświęconych wyłącznie modelom językowym i porządkuje je według faz zdarzenia, od wykrywania po odbudowę. Zespół z University of Virginia (Lei i in., 2025) wskazuje na istotną nierównowagę: większość prac dotyczy fazy reagowania,

a zapobieganie i przygotowanie, gdzie ryzyko wdrożenia jest najniższe, pozostają w cieniu. Autorzy przeglądu w IEEE Internet Computing (Zhu i in., 2025) opisują wzorzec, który najlepiej oddaje praktyczną wartość tej technologii. Model rozkłada złożone zadanie na mniejsze części i przydziela je odpowiednim narzędziom analitycznym. Są też pierwsze doświadczenia operacyjne z Europy. W projekcie AI Special Project organizacji EENA, zakończonym w grudniu 2024 roku, centra powiadamiania ratunkowego z kilku państw przetestowały w dziesięciu pilotażach transkrypcję i tłumaczenie zgłoszeń w czasie rzeczywistym, redukcję szumów oraz wsparcie triażu. Warto zauważyć, jak ostrożnie dobrano zakres. AI usprawnia przepływ informacji, ale nie decyduje o dysponowaniu sił.

Gdzie LLM daje sztabowi realny zysk?

Pierwszy obszar to obraz sytuacji. Model może na bieżąco łączyć meldunki z różnych kanałów w szkic raportu sytuacyjnego, wyciągać z nich lokalizacje, liczbę poszkodowanych i zgłoszone potrzeby, a przede wszystkim wskazywać sprzeczności między źródłami. Sztab rzadko cierpi na brak danych. Częściej na to, że dwie wersje tego samego zdarzenia funkcjonują równolegle i nikt tego nie zauważył. Drugi obszar to dostęp do procedur. Plany, instrukcje, karty zadaniowe i podstawy prawne są zwykle rozproszone w dziesiątkach dokumentów. Model połączony ze zweryfikowaną bazą wiedzy organizacji (technika RAG, czyli generowanie odpowiedzi wyłącznie na podstawie wyszukanych fragmentów konkretnych dokumentów) odpowie na pytanie o ewakuację osób o ograniczonej mobilności, wskazując właściwy punkt własnej procedury, a nie ogólną wiedzę z internetu.

Trzeci obszar to dokumentacja. W artykule „Kiedy budynek przestaje być opcją” opisywaliśmy sytuację, w której po dwóch godzinach nikt nie potrafi odtworzyć, kto podjął którą decyzję i na jakiej podstawie. LLM może prowadzić dziennik działań na bieżąco, z transkrypcji odpraw i wpisów w systemie, a po zakończeniu zdarzenia przygotować szkic raportu poakcyjnego. Czwarty obszar to komunikacja: projekty komunikatów dla mieszkańców, pracowników i mediów, w kilku wersjach językowych i dla różnych kanałów, gotowe w minuty zamiast w godzinę. Zawsze jako projekt do zatwierdzenia. Piąty, najmniej oczywisty, to ćwiczenia. Generowanie wariantów scenariusza i nieoczekiwanych wprowadzeń pozwala budować ćwiczenia nieprzewidywalne, a właśnie takie, o czym pisaliśmy w artykule „Człowiek w centrum kryzysu”, budują rzeczywistą odporność zespołu.

Zagrożenie pierwsze: przekonujący błąd.

Model językowy nie „wie”. Generuje najbardziej prawdopodobny ciąg słów. Amerykański NIST w profilu ryzyk generatywnej AI (NIST AI 600-1, 2024) wymienia konfabulację, czyli treści fałszywe, ale brzmiące wiarygodnie, jako jedno z dwunastu ryzyk szczególnych dla tej technologii. W sztabie halucynacja nie wygląda jak bzdura. Wygląda jak porządnie sformatowany meldunek z błędnym numerem drogi albo nieistniejącym punktem procedury.

Groźniejszy od samego błędu jest człowiek, który go nie wyłapie. Efekt automatyzacji (automation bias) opisywano już w latach 90. w badaniach NASA nad pilotami (Mosier i in., 1996): operator wykonuje błędne polecenie automatu albo nie reaguje, bo automat milczał. Modele językowe ten efekt wzmacniają, bo ich odpowiedzi są elokwentne.

W randomizowanym badaniu z 2025 roku (Qazi i in., preprint medRxiv) 44 lekarzy po dwudziestogodzinnym szkoleniu z AI otrzymywało rekomendacje ChatGPT, w połowie przypadków z celowo wprowadzonymi błędami. Jakość rozumowania diagnostycznego spadła w tej grupie o 14 punktów procentowych, a mocniej dotknęło to lekarzy bardziej doświadczonych. Szkolenie z obsługi AI nie wystarczyło jako zabezpieczenie. Przeniesienie tego wniosku na sztab pracujący w stresie, zmęczeniu i pod presją czasu nie wymaga wielkiej wyobraźni.

Zagrożenie drugie: model jako nowa powierzchnia ataku.

OWASP umieszcza prompt injection na pierwszym miejscu listy Top 10 zagrożeń dla aplikacji LLM (2025). Istota problemu jest prosta: model nie odróżnia poleceń od danych. Jeżeli asystent sztabu czyta e-maile, posty z mediów społecznościowych czy pliki od podmiotów zewnętrznych, każdy z tych materiałów może zawierać ukrytą instrukcję. Podatność EchoLeak (CVE-2025-32711) w Microsoft 365 Copilot pokazała w 2025 roku, że do wyprowadzenia danych wystarczyła jedna spreparowana wiadomość, bez żadnego kliknięcia użytkownika. Kryzys to dla przeciwnika moment idealny. Napływ informacji jest największy, weryfikacja najsłabsza, a dezinformacja bywa elementem samego ataku. Ryzyko rośnie, gdy model może działać, np. wysyłać powiadomienia czy zmieniać statusy zadań. OWASP nazywa to nadmierną sprawczością (excessive agency).

Zagrożenie trzecie: dane i suwerenność.

Sztab przetwarza dane szczególnie wrażliwe. Tożsamość i stan zdrowia poszkodowanych, lokalizację osób, plany ochrony obiektów, słabe punkty infrastruktury. Wysłanie ich do publicznej usługi chmurowej to nie tylko kwestia RODO i oceny skutków dla ochrony danych. To także pytanie, kto i na podstawie jakiego prawa może uzyskać do nich dostęp, oraz czy narzędzie zadziała, gdy zabraknie łącza. Rozwiązanie działające tylko przy stabilnym internecie przestaje działać dokładnie w tych scenariuszach, do których sztab się przygotowuje.

Zagrożenie czwarte: regulacje.

AI Act w załączniku III kwalifikuje jako systemy wysokiego ryzyka m.in. AI służącą do oceny i klasyfikacji zgłoszeń alarmowych, dysponowania służb ratowniczych oraz jako element bezpieczeństwa infrastruktury krytycznej. Udział człowieka w decyzji nie zdejmuje tej kwalifikacji. Rozporządzenie Digital Omnibus (UE) 2026/1744 przesunęło stosowanie tych obowiązków na 2 grudnia 2027 roku, ale ich nie zniosło. Równolegle od 3 kwietnia 2026 roku obowiązuje znowelizowana ustawa o krajowym systemie cyberbezpieczeństwa wdrażająca NIS2, z obowiązkami raportowania incydentów i zabezpieczenia łańcucha dostaw. Dostawca modelu AI jest właśnie takim ogniwem.

Jak to zabezpieczyć? Siedem zasad z praktyki.

Po pierwsze. AI proponuje, człowiek decyduje, a granica jest zapisana w procedurze. Czynności warto podzielić na trzy grupy. Te, które model wykonuje samodzielnie (transkrypcja, porządkowanie, wyszukiwanie w procedurach), te, które przygotowuje do zatwierdzenia (komunikaty, raporty, rekomendacje), oraz te, do których nie ma dostępu (dysponowanie siłami, alarmowanie ludności, decyzja o ewakuacji). Żadne działanie wychodzące na zewnątrz nie odbywa się bez zatwierdzenia przez uprawnioną osobę.

Po drugie, odpowiedź bez źródła nie jest odpowiedzią. Model pracuje na zamkniętej, zweryfikowanej bazie dokumentów, przy każdej informacji wskazuje jej pochodzenie i ma prawo powiedzieć „nie wiem”. To dokładnie te mechanizmy, które NIST wskazuje jako podstawę przeciwdziałania konfabulacji: osadzenie w źródłach, wymóg cytowania, sygnalizowanie niepewności. Po trzecie? Ćwiczyć z błędnym AI. Skoro samo szkolenie nie chroni przed efektem automatyzacji, odporność trzeba budować tak jak każdą inną, w kontrolowanym stresie. W grach sztabowych warto celowo wprowadzać błędne rekomendacje systemu i sprawdzać, kto je wyłapie, a w składzie sztabu wyznaczyć osobę odpowiedzialną za weryfikację tego, co podaje model. Po czwarte dane zostają u nas. Dla danych wrażliwych właściwym kierunkiem są modele uruchamiane lokalnie lub w zaufanej infrastrukturze krajowej. Polskie otwarte modele, takie jak PLLuM rozwijany na zlecenie Ministerstwa Cyfryzacji czy Bielik, można uruchomić we własnym środowisku. Jeżeli korzystamy z chmury - minimalizacja i pseudonimizacja danych przed wysłaniem, przetwarzanie w EOG, umowny zakaz trenowania na naszych danych i ocena skutków (DPIA) przed wdrożeniem. Po piąte bezpieczeństwo jak dla systemu krytycznego. Treści z zewnątrz traktowane jako niezaufane i oddzielone od instrukcji, minimalne uprawnienia dla każdego agenta AI, pełny rejestr zapytań, odpowiedzi i działań (wymagany też przez AI Act dla systemów wysokiego ryzyka) oraz regularne testy odporności na prompt injection oparte na metodyce OWASP. Po szóste tryb zdegradowany. Proces zarządzania kryzysowego musi działać bez AI. Model jest warstwą przyspieszającą, a nie filarem. Jeżeli wyłączenie asystenta paraliżuje sztab, wdrożenie zaprojektowano źle. W mobilnych centrach dowodzenia warto przewidzieć mniejszy model działający offline, na lokalnym sprzęcie. Wreszcie po siódme. Inwentaryzacja i klasyfikacja już teraz. Każde narzędzie AI używane w procesie kryzysowym powinno trafić do rejestru, z oceną, czy nie mieści się w kategoriach załącznika III AI Act. Grudzień 2027 roku jest bliżej, niż się wydaje, szczególnie dla jednostek publicznych, które będą musiały przeprowadzić ocenę wpływu na prawa podstawowe.

Co dalej?

Modele językowe nie zastąpią lidera sztabu ani jego doświadczenia. Mogą jednak zdjąć z niego to, co dziś najbardziej go obciąża. Szum informacyjny, ręczne szukanie procedur i dokumentowanie po fakcie. Warunek jest jeden. Organizacja musi wiedzieć, gdzie kończy się rola algorytmu, a zaczyna odpowiedzialność człowieka i musi to przećwiczyć, zanim przyjdzie kryzys. CELiUS projektuje procedury zarządzania kryzysowego, rozwija aplikację mobilną dla sztabów i prowadzi ćwiczenia sztabowe w warunkach zbliżonych do rzeczywistych. Jeżeli planujesz wykorzystanie AI w swoim procesie zarządzania kryzysowego i chcesz zrobić to bezpiecznie, zapraszamy do kontaktu z naszym Zespołem.