Plan awaryjny dla automatyzacji AI: jak przejąć zadanie po błędzie

Automatyzacja przestaje odpowiadać w połowie sprawy. Klient wysłał zgłoszenie, model przygotował klasyfikację, ale system docelowy nie potwierdził zapisu. Czy trzeba ponowić operację? Czy sprawa już istnieje? Kto powinien dowiedzieć się o opóźnieniu? Odpowiedzi nie powinny powstawać dopiero w chwili awarii.

Plan awaryjny dla automatyzacji AI opisuje, jak rozpoznać problem, zatrzymać niewłaściwe działania i przekazać niedokończone zadanie osobie, która może je bezpiecznie przejąć. Powinien obejmować cały proces, również integracje i decyzje człowieka. Sam model jest tylko jednym z elementów tej układanki.

Jeżeli planujesz taką automatyzację, wyślij brief z przykładem sprawy, etapami jej obsługi i informacją, co dziś dzieje się, gdy któryś etap zawiedzie. Nie przesyłaj haseł ani niezanonimizowanych dokumentów klientów. Już prosty opis pozwoli wskazać miejsca, w których potrzebny będzie plan przejęcia pracy.

Najpierw ustal, co znaczy bezpiecznie przerwać

Wyobraźmy sobie firmę serwisową, która przyjmuje wiadomości o usterkach. Automatyzacja odczytuje zgłoszenie, proponuje kategorię oraz przekazuje je do kolejki odpowiedniego zespołu. Jeżeli nie rozpozna urządzenia, nie powinna zgadywać numeru ani oznaczać sprawy jako zakończonej. Może skierować zgłoszenie do pracownika wraz z informacją o brakującym polu. To przykład projektowy, a nie opis konkretnego wdrożenia.

Dla każdej czynności określcie, co uznajecie za poprawne wykonanie. Utworzenie wpisu w kolejce nie jest tym samym co przekazanie sprawy osobie odpowiedzialnej, a wysłanie żądania nie dowodzi jeszcze, że drugi system je przyjął. Ustalenie takich granic ułatwia później odróżnienie spraw zakończonych od tych, które wymagają kontroli.

Zapiszcie również, które działania można wstrzymać bez szkody dla procesu. Przygotowanie roboczej odpowiedzi można zwykle zatrzymać inaczej niż wysyłkę wiadomości do klienta czy zmianę terminu zlecenia. Skutek zależy od zadania, dlatego lista powinna powstać z udziałem osób, które codziennie obsługują sprawy. W artykule o wdrożeniu AI i pracy zespołu opisujemy, jak ustalić nowy podział obowiązków.

Przerwanie może dotyczyć pojedynczego zgłoszenia albo całej automatyzacji. Jeden nieczytelny dokument nie zawsze wymaga zatrzymania procesu dla pozostałych spraw. Seria błędnych zmian w systemie docelowym może już wymagać szybkiego wyłączenia funkcji zapisu. Dobrze, aby plan rozróżniał te sytuacje i wskazywał, kto ma dostęp do odpowiedniego przełącznika.

Rozpoznaj błąd, zanim powstanie długa kolejka

Brak technicznego wyjątku nie oznacza, że wynik jest użyteczny. Model może zwrócić odpowiedź w wymaganym formacie, lecz przypisać sprawę do niewłaściwej kategorii. Integracja może przyjąć wiadomość, lecz nie wykonać kolejnego zadania. Kontrola powinna zatem obejmować zarówno sygnały techniczne, jak i wynik procesu widoczny dla pracowników.

Przydatne pytania są konkretne: ile zgłoszeń czeka na przekazanie, jak długo najstarsze pozostaje bez właściciela, ile operacji zakończyło się błędem i czy pojawiły się nietypowe duplikaty? Wybór progów zależy od obciążenia i skutków opóźnienia. W małym zespole nawet pojedyncza pilna sprawa może wymagać reakcji, a w innym procesie ważniejsze będzie nagromadzenie zaległości.

Nie każdy sygnał powinien natychmiast budzić tę samą osobę. Ustalcie poziomy reakcji, odbiorców oraz godziny odpowiedzialności. Alert, którego nikt nie może odebrać albo który codziennie informuje o spodziewanym zdarzeniu, szybko traci znaczenie. Więcej o wyborze sygnałów i odpowiedzialności piszemy w artykule o monitorowaniu automatyzacji i obsłudze błędów.

Dokumentacja OpenTelemetry o obserwowalności opisuje metryki, dzienniki oraz ślady przejścia zadania przez elementy systemu. Można wykorzystać te rodzaje informacji do ustalenia, na którym etapie sprawa się zatrzymała. Zakres zapisywanych danych trzeba dopasować do potrzeb i ograniczyć tak, by dziennik nie powielał bez potrzeby treści dokumentów ani danych klientów.

Kolejka wyjątków potrzebuje właściciela

Sprawa wymagająca człowieka powinna trafić w miejsce, które ktoś regularnie sprawdza. Dobrze, aby kolejka pokazywała identyfikator sprawy, czas oczekiwania, etap procesu, przyczynę skierowania i osobę lub zespół odpowiedzialny. Sama etykieta „błąd AI” niewiele pomaga pracownikowi, który próbuje ustalić, czy ma poprawić dokument, wybrać kategorię czy sprawdzić wynik zapisu.

Kontekst musi wystarczyć do działania, ale nie powinien ujawniać danych osobom bez odpowiednich uprawnień. Jeśli pracownik ma tylko wskazać brakujący numer zamówienia, może nie potrzebować pełnej korespondencji z klientem. Dostęp do źródeł i historii sprawy powinien wynikać z roli pracownika. Granice dostępu do dokumentów omawiamy w tekście o uprawnieniach w firmowej wyszukiwarce dokumentów. Przy przekazywaniu informacji do zewnętrznego modelu sprawdźcie również, jakie dane są potrzebne dostawcy AI.

W kolejce przydaje się możliwość przejęcia sprawy, zapisania decyzji i wskazania następnego kroku. Kiedy dwie osoby jednocześnie widzą ten sam problem, system powinien jasno pokazać, czy ktoś już nad nim pracuje. Przy dłuższym oczekiwaniu potrzebna może być eskalacja do innej osoby. Zasady eskalacji najlepiej ustalić z zespołem, a potem sprawdzić na realistycznym obciążeniu, zamiast przyjmować uniwersalny czas dla każdej firmy.

Nie wszystkie sprawy czekają w tej samej kolejce. Zgłoszenie dotyczące bezpieczeństwa pracownika może wymagać innej drogi niż brak numeru referencyjnego na fakturze. Sposób rozróżnienia pilności należy ustalić dla konkretnego procesu i przetestować na przykładach. Jeżeli system nie potrafi bezpiecznie ocenić pilności, plan powinien wskazywać, kto sprawdzi niejednoznaczny przypadek.

Ponów dopiero po sprawdzeniu skutku

Gdy żądanie do zewnętrznego systemu przekroczy czas oczekiwania, odpowiedź może nie dotrzeć mimo wykonania operacji. Automatyczne ponowienie bez rozpoznania stanu może wtedy utworzyć drugi rekord lub wywołać kolejną wiadomość. Jeśli system docelowy na to pozwala, identyfikator operacji i mechanizm rozpoznawania ponowień pomagają powiązać kolejne próby z jednym zadaniem.

Nie każda operacja daje się bezpiecznie ponowić w ten sam sposób. Przed ponownym wysłaniem wiadomości warto sprawdzić, czy pierwsza została przyjęta. Przed zmianą danych trzeba uwzględnić, że w międzyczasie pracownik mógł ręcznie poprawić sprawę. Dokładniejsze omówienie znajdziesz w artykule o integracjach API i webhookach, gdzie pokazujemy różnicę między dostarczeniem komunikatu a wykonaniem zadania.

Liczba prób i odstęp między nimi powinny mieć granice. Ponawianie bez końca nie naprawi błędnego klucza ani brakującego uprawnienia, a przy przeciążeniu może zwiększyć liczbę żądań. Wskazówki Google dotyczące niezawodności usług zwracają uwagę, że ponowienia mogą nasilać problemy przy przeciążeniu. Po wyczerpaniu ustalonego limitu sprawa powinna trafić do odpowiedniej obsługi, a nie zniknąć z widoku.

W planie opiszcie także sytuację, w której nie da się ustalić skutku pierwszej próby. Przy zmianie danych lub wysyłce na zewnątrz lepsze może być przekazanie sprawy do sprawdzenia niż zgadywanie. Pracownik potrzebuje wtedy informacji o czasie próby, adresacie i dostępnych potwierdzeniach. Nie każda integracja udostępnia te same dane, dlatego należy sprawdzić konkretne możliwości systemu przed obiecaniem automatycznego odzyskania stanu.

Tryb ręczny musi dać się uruchomić

„W razie awarii obsłużymy sprawy ręcznie” jest dobrym początkiem rozmowy, ale jeszcze nie procedurą. Kto otwiera kolejkę? W którym systemie wpisuje decyzję? Jak pozostali dowiadują się, że sprawa jest już przejęta? Czy potrzebne są dodatkowe uprawnienia, a jeśli tak, kto może je nadać? Odpowiedzi powinny być dostępne również wtedy, gdy część aplikacji nie działa.

Tryb ręczny wymaga prostego sposobu przekazania kontekstu i oznaczenia wykonanych czynności. Jeśli pracownik odpowie klientowi poza aplikacją, system powinien później uwzględnić ten fakt, aby nie wysłać drugiej odpowiedzi po wznowieniu automatyzacji. Nie trzeba od razu tworzyć osobnego rozbudowanego narzędzia. Czasem wystarczy dobrze uzgodniona kolejka oraz zapis decyzji w systemie, z którego zespół już korzysta.

Zaplanujcie też komunikację dla osób czekających na wynik. Informacja o opóźnieniu powinna opisywać rzeczywisty stan, a nie obiecywać termin, którego nikt jeszcze nie ustalił. Jeśli odbiorca musi wykonać dodatkową czynność, powiedzcie jaką. Gdy nie musi nic robić, nie wysyłajcie go w podróż po trzech formularzach. Przy projektowaniu obsługi zapytań znaczenie ma cały przebieg sprawy, o czym piszemy w tekście o automatyzacji zapytań klientów.

Powrót do pracy i ćwiczenie scenariusza

Wznowienie procesu wymaga sprawdzenia, które zadania rzeczywiście czekają, a które zostały już obsłużone ręcznie. Osoba odpowiedzialna powinna wiedzieć, jak włączyć działanie stopniowo, obserwować wyniki i ponownie zatrzymać je w razie problemu. Zanim kolejka zostanie uruchomiona, trzeba rozstrzygnąć konflikty między aktualnym stanem sprawy a danymi zapisanymi przed awarią.

Po incydencie zapiszcie przebieg i przyczynę w zakresie, jaki udało się ustalić. Jeśli nie wiadomo, dlaczego odpowiedź nie dotarła, pozostawcie to jako niewyjaśnione pytanie. Następnie wybierzcie konkretne usprawnienie: dodatkowy sygnał, zmianę instrukcji, poprawkę integracji albo test brakującego przypadku. Raport nie musi szukać winnego. Ma pomóc uniknąć ponownego rozwiązywania tego samego problemu od zera.

Plan trzeba także przećwiczyć przed rzeczywistą awarią. W środowisku testowym zatrzymajcie odpowiedź integracji, przygotujcie niepełne zgłoszenie i sprawdźcie, czy właściwa osoba potrafi przejąć zadanie. Zwróćcie uwagę na uprawnienia, czytelność komunikatów i ślad decyzji. Więcej o przygotowaniu scenariuszy piszemy w artykule jak testować asystenta AI.

Zakres ćwiczenia można dopasować do skali firmy. Niewielki zespół może przejść jeden proces podczas krótkiego spotkania. Duża organizacja może potrzebować osobnych prób dla kilku usług i zespołów dyżurnych. W obu przypadkach ważne jest potwierdzenie, że procedura działa w praktyce i ma aktualnego właściciela. Projektując automatyzacje i workflow, warto przewidzieć ten czas obok prac nad samym działaniem modelu.

Osobny wariant ćwiczenia dotyczy błędnej odpowiedzi modelu, która przeszła kontrolę formatu. Przygotujcie przykładowe zgłoszenie z niejednoznacznym opisem i sprawdźcie, czy pracownik widzi oryginalne źródło oraz propozycję automatyzacji. Osoba przejmująca sprawę powinna móc poprawić kategorię bez przepisywania całej historii. Zapiszcie, czy korekta trafia tylko do tej sprawy, czy także do materiału używanego przy kolejnych ocenach. Taka decyzja wymaga odrębnych zasad i uprawnień.

Warto również sprawdzić ograniczenia dostępności zespołu. Jeżeli awaria zaczyna się pod koniec dnia, kto przejmie nową kolejkę rano? Czy pilne sprawy trafiają do dyżurującej osoby, czy czekają na standardową obsługę? Odpowiedzi zależą od faktycznych godzin pracy i umówionego sposobu obsługi. Instrukcja powinna wskazywać aktualny kanał kontaktu, zastępstwo i miejsce, w którym można potwierdzić przekazanie odpowiedzialności. Po zmianach organizacyjnych należy ją zaktualizować, a nie zakładać, że lista sprzed roku nadal działa.

Po powrocie do normalnej pracy porównajcie liczbę spraw przekazanych do trybu ręcznego z liczbą faktycznie zamkniętych. Różnica może wskazać zgłoszenie, które utknęło między kolejkami. Jeżeli stanów nie da się uzgodnić automatycznie, określcie osobę odpowiedzialną za kontrolę oraz sposób wyjaśnienia rozbieżności. Dopiero takie uzgodnienie pozwala bezpiecznie zakończyć obsługę incydentu.

Warto przypisać termin kolejnego przeglądu procedury oraz zapisać, kto może ją zmienić. Dzięki temu instrukcja nie zestarzeje się po zmianie narzędzia, zespołu albo sposobu przekazywania spraw.