Awaria AI w rekrutacji: jak utrzymać ciągłość procesu

Plan działania na wypadek awarii AI w rekrutacji pozwala zachować zgłoszenia, decyzje, rozmowy i komunikację prowadzoną przez ludzi w systemie ATS, nawet gdy wzbogacanie danych zależne od modeli przestaje działać. Najpierw zapisz transakcję rekrutacyjną, umieść zadania AI w kolejce wraz z wersjami danych źródłowych, ogranicz liczbę ponowień, udostępnij ścieżkę ręczną i przed wznowieniem pracy sprawdź, które zadania straciły aktualność.

To rozróżnienie ma znaczenie, bo AI nie ogranicza się już do asystenta redakcyjnego otwartego w osobnej karcie. Model może analizować CV, podsumowywać rozmowę, proponować odpowiedź, przeszukiwać dane albo wywoływać narzędzia zmieniające pipeline rekrutacji. Jeśli model znajdzie się na ścieżce, która musi zadziałać przed zapisaniem danych rekrutacyjnych, incydent dostawcy uderza również w twój proces.

Nie da się obiecać automatyzacji bez przerw. Da się za to zbudować proces rekrutacji, który pozostaje zrozumiały i użyteczny również wtedy, gdy automatyzacja się zatrzyma.

Co naprawdę pokazały 93 minuty nakładających się awarii AI?

3 września 2026 roku potwierdzone incydenty w Anthropic, xAI i OpenAI nakładały się przez 93 minuty, od 14:43 do 16:16 UTC. Nie zaczęły się jednocześnie, a publicznie dostępne dowody nie wskazują na wspólną przyczynę.

Firma Anthropic zgłosiła główny incydent o 13:26 UTC po wzroście liczby błędów w kilku modelach Claude. Raport z incydentu jako dotknięte wymienia Claude.ai, Claude API, Claude Code i Claude Cowork. Firma poinformowała, że ustaliła przyczynę, lecz publicznie opisała ją tylko jako problem z infrastrukturą. Skutki ustały o 16:16 UTC, dwie godziny i 50 minut po pierwszym komunikacie. Osobny incydent dotyczący Sonnet 5 zakończył się o 12:56 UTC. Nie był to więc początek jednej ciągłej awarii.

Zakłócenia w xAI rozpoczęły się o 13:30 UTC. Raport o stanie API w regionie US East wskazuje, że usługa wróciła do normy o 17:07 UTC. Podobne godziny awarii podano dla aplikacji webowej i mobilnej, integracji z X oraz innych obszarów API. Firma SpaceXAI poinformowała później o awarii centrum obliczeniowego w Memphis. Nie ujawniła, czy zawiodło zasilanie, sieć, sprzęt czy oprogramowanie.

Firma OpenAI odnotowała początek zakłóceń o 14:43 UTC. Strona incydentu wymienia komponenty ChatGPT i Codex, a nie OpenAI API. Rzecznik firmy przypisał problemy części użytkowników błędowi w kierowaniu ruchem. Rozwiązanie wdrożono o 15:17 UTC, jednak monitorowanie trwało aż do oznaczenia incydentu jako zakończonego o 16:55 UTC. Nazwanie tego 34-minutową awarią myliłoby czas potrzebny na ograniczenie skutków z ostatecznym usunięciem problemu.

To wystarczy, by podważyć pochopne założenie, że znany dostawca AI usuwa ryzyko operacyjne. Sama zbieżność czasowa nie dowodzi jednak, że dostawcy korzystali ze wspólnej chmury, sieci lub centrum danych ani że źródłem problemów był atak lub skok ruchu. W ówczesnych doniesieniach nie ma wypowiedzi żadnego dostawcy, która potwierdzałaby taki związek. Teorię o wspólnej przyczynie traktuj jako spekulację, dopóki nie potwierdzi jej analiza po incydencie.

Dla zespołu rekrutującego nie jest najważniejsze to, dlaczego trzy strony statusu pokazywały awarię. Liczy się to, co kandydaci i rekruterzy nadal mogli robić w tym czasie.

Które procesy rekrutacyjne muszą przetrwać awarię AI?

Działania, które tworzą wiążący zapis rekrutacji, muszą działać bez modelu. Awaria dostawcy może opóźnić wzbogacanie danych, lecz nie powinna usuwać zgłoszenia, ukrywać decyzji ani odcinać kandydata od kontaktu z osobą z zespołu.

Najpierw oddziel transakcje od wsparcia. Transakcje zmieniają trwały stan procesu rekrutacji. Wsparcie tworzy informacje pochodne lub propozycję kolejnego działania.

Liczy się to, kto ma ostatnie słowo, a nie to, jak ważna wydaje się funkcja. Rekruter może mocno polegać na wygenerowanym podsumowaniu, ale pierwotne notatki z rozmowy nadal muszą istnieć. Asystent redakcyjny może oszczędzać wiele godzin, lecz rekruter musi mieć możliwość samodzielnego napisania wiadomości. Model wyszukujący może wskazać prawdopodobne dopasowania, jednak uprawniona osoba potrzebuje także innego sposobu otwarcia danych kandydata.

NIST w podręczniku AI Risk Management Framework zaleca realne alternatywy niewymagające AI, jasno określone role ludzi, mechanizmy przejęcia kontroli oraz procedury awaryjne na wypadek problemów z zewnętrznymi dostawcami. W rekrutacji oznacza to, że tryb ograniczony nie może sprowadzać się do wskaźnika ładowania, który kręci się bez końca. Interfejs powinien wyjaśnić, co się nie udało, potwierdzić zapisane dane i wskazać kolejne bezpieczne działanie.

Awarię odczuje też kandydat. Jeśli zgłoszenie zostało przyjęte, ale analiza się opóźnia, wyślij potwierdzenie jego przyjęcia. Nie proś o ponowne przesłanie zgłoszenia tylko dlatego, że wywołanie usługi wzbogacającej dane przekroczyło limit czasu. Tak samo jak w przypadku dostępnego portalu kandydata, podstawowa ścieżka musi pozostać dostępna również wtedy, gdy opcjonalna warstwa przestaje działać.

Wyznacz tę granicę przed incydentem. Przy każdej funkcji wykorzystującej model zapytaj: jaki zapis pozostanie, jeśli to wywołanie nigdy nie zwróci odpowiedzi? Co może potem zrobić człowiek? Jeśli żadna odpowiedź nie jest oczywista, model prawdopodobnie odpowiada za zbyt dużą część transakcji.

Jak oddzielić transakcję rekrutacyjną od wzbogacania danych przez AI?

Najpierw zapisz podstawowe dane w systemie, a dopiero potem zleć ich wzbogacenie przez AI jako osobne, obserwowalne zadanie. Działanie wykonywane przez kandydata nie powinno czekać na odpowiedź modelu, chyba że funkcja jest wyraźnie opcjonalna i daje prosty sposób kontynuowania bez niej.

W praktyce ścieżka wygląda tak:

candidate or recruiter action → ATS transaction → durable AI task → bounded worker → provider → versioned result → human review

Załóżmy, że kandydat przesyła zgłoszenie. W jednej transakcji bazy danych zapisz dane kandydata, zgłoszenie, zgodę, odwołanie do załącznika i etap początkowy. Dopiero po zatwierdzeniu tej transakcji system powinien dodać do kolejki analizę albo podsumowanie CV. Gdy dostawca jest niedostępny, zgłoszenie nadal istnieje. Rekruter widzi komunikat „podsumowanie czeka w kolejce” zamiast pustego rekordu, a kandydat dostaje potwierdzenie na podstawie zapisanego zgłoszenia, nie wyniku wzbogacania.

Trwała kolejka przejmuje zadania, gdy zależność jest niedostępna, ale sama nie stanowi kompletnej strategii odporności. Wytyczne Microsoft dotyczące wyrównywania obciążenia za pomocą kolejki wskazują na konieczność monitorowania długości kolejki, ograniczania przetwarzania, zapewnienia idempotencji procesów pobierających zadania, obsługi kolejki zadań niemożliwych do wykonania oraz ustalenia kolejności. Bez tych zabezpieczeń powrót do normalnej pracy może zmienić awarię dostawcy w lawinę zaległych zadań.

Do każdego zadania dołącz niezmienną wersję danych źródłowych. Może to być wersja CV, notatek z rozmowy, kryteriów stanowiska albo szablonu wiadomości. Przed zapisaniem wyniku proces powinien porównać ją z bieżącym stanem. Jeśli kandydat zastąpił CV nowszym albo zgłoszenie przeszło dalej, stare zadanie nie jest już tylko spóźnione. Jest nieaktualne.

Nieaktualne zadanie zwykle bezpieczniej zastąpić niż uruchomić ponownie. Zachowaj je na potrzeby audytu, zapisz powód pominięcia i dodaj aktualną wersję do kolejki tylko wtedy, gdy wynik wciąż ma wartość. Dzięki temu rekruter nie przeczyta dopracowanego podsumowania danych, które nie dotyczą już kandydatury.

Interfejs wymaga tej samej precyzji. Stosuj osobne stany: oczekujące, przetwarzane, ponawiane, zakończone błędem, zastąpione, anulowane i ukończone. Komunikat „AI jest niedostępna” pomaga bardziej niż wskaźnik ładowania bez końca. Jeszcze lepsze jest „zgłoszenie zapisano; podsumowanie CV jest opóźnione”, bo wskazuje zarówno udaną transakcję, jak i niedziałające wzbogacanie.

Jak bezpiecznie ponawiać zadania przed dodaniem awaryjnego dostawcy?

Ponowienie jest bezpieczne tylko wtedy, gdy nie wywoła ponownie tego samego skutku biznesowego. Rozwiąż ten problem przed dodaniem kolejnego dostawcy modeli. Przełączenie awaryjne otwiera bowiem jeszcze jedną drogę do wykonania powielonych lub nieaktualnych działań.

Zadania AI dzielą się na dwie kategorie ryzyka. Dwukrotne wygenerowanie wewnętrznego podsumowania marnuje pieniądze i może utworzyć sprzeczne artefakty. Powtórzenie działania skierowanego do kandydata lub zmieniającego stan może wyrządzić bezpośrednią szkodę. To na przykład dwie wiadomości o odrzuceniu, dwie rezerwacje rozmowy, dwie zmiany etapu albo oferta wysłana już po wycofaniu się kandydata.

Nadaj każdej operacji klucz idempotencji odpowiadający znaczeniu biznesowemu. Może mieć taką postać:

account + application + capability + source_version + workflow_step

Zapisuj ten klucz razem z zadaniem oraz każdym wynikowym artefaktem lub skutkiem ubocznym. Przed wysłaniem wiadomości, rezerwacją, odrzuceniem albo zmianą etapu sprawdź zarówno klucz, jak i aktualny stan lokalny. Wytyczne AWS o bezpiecznym ponawianiu wywołań dzięki idempotentnym API wyjaśniają, dlaczego identyfikator przekazany przez system wywołujący jest bardziej wiarygodny niż próba odgadnięcia, czy dwa podobne żądania wyrażają ten sam zamiar.

Następnie wybierz jedną warstwę ponawiania. SDK może już automatycznie powtarzać wywołania. Proces w tle może robić to samo, a silnik procesu dodać trzecią pętlę. Jeśli każda warstwa wykonuje trzy próby, pojedynczy błąd może wywołać o wiele więcej żądań, niż sugeruje przyjęta zasada. Rozróżniaj typy błędów przejściowych, stosuj wykładniczo rosnące odstępy z losowym odchyleniem, limit prób i ostateczny termin. Błąd uwierzytelniania, nieprawidłowe dane wejściowe ani odrzucenie żądania z powodów bezpieczeństwa nie uzasadniają kolejnych prób.

Nie zaczynaj od przełączania między dostawcami. Modele o różnych nazwach mogą nadal współdzielić system tożsamości, sieć, zasoby regionalne albo inną zależność w płaszczyźnie sterowania. Analiza incydentu OpenAI z lipca 2026 roku opisuje problem z przepustowością regionalnej usługi tożsamości, podczas którego automatyczny mechanizm awaryjny przekierował za mało ruchu. Zapasowy mechanizm jest naprawdę niezależny tylko wtedy, gdy omija element, który faktycznie zawiódł.

Jeśli dodajesz opcję zapasową, określ, jakie działania wolno jej wykonywać. Drugi dostawca może się sprawdzić przy wewnętrznym podsumowaniu o niewielkim ryzyku. Nie musi jednak nadawać się do przetwarzania poufnego CV, jeśli obowiązują inne umowy, lokalizacja lub okres przechowywania danych albo zachowanie modelu. Wyniki mogą się też różnić na tyle, że przestaną pasować do założeń kolejnych procesów. Zapisuj dostawcę i model w audit trail, sprawdzaj wyniki ze ścieżki zapasowej i zachowaj możliwość pracy bez AI.

Jak przetestować pięcioetapową procedurę trybu ograniczonego?

Dobra procedura na wypadek awarii musi być na tyle krótka, by dało się jej trzymać pod presją, i na tyle jednoznaczna, by zapobiegała improwizacji. Przetestuj tych pięć etapów przy wyłączonym połączeniu z modelem, a nie na slajdach.

1. Ogłoś tryb ograniczony i chroń podstawową ścieżkę

Potwierdź objawy po stronie dostawcy, a następnie wyłącz lub omiń niekrytyczne wywołania synchroniczne. Utrzymaj przyjmowanie zgłoszeń, dostęp do danych, ręczne zmiany etapów, obsługę rozmów i możliwość samodzielnego pisania wiadomości. Umieść jasny komunikat o stanie w miejscu widocznym dla rekruterów. Zapisz godzinę rozpoczęcia incydentu i wskaż osobę koordynującą powrót do normalnej pracy.

2. Ogranicz ponowienia i zachowaj zamiar

Otwórz obwód zabezpieczający dla dotkniętej funkcji albo wstrzymaj procesy pobierające jej zadania. Nie usuwaj zadań z kolejki. Zatrzymaj ponowienia na wielu warstwach, zanim zwielokrotnią obciążenie lub wyczerpią limity zapytań. Zachowaj klucz idempotencji, wersję danych źródłowych, termin, identyfikator żądania u dostawcy i ostatni błąd wraz z typem dla każdego zadania.

Wytyczne Google SRE dotyczące awarii kaskadowych zalecają wyniki o ograniczonej jakości, terminy, odrzucanie części obciążenia i ostrożne ponawianie. Ruch generowany przez ponowienia może przedłużyć przeciążenie. Chodzi o to, by zmniejszyć nacisk na usługę bez utraty celu pierwotnego działania rekrutacyjnego.

3. Skieruj ludzi na ręczną ścieżkę

Przekaż rekruterom instrukcje właściwe dla danej funkcji. Otwórz zapisane CV, zamiast czekać na podsumowanie. Użyj wyszukiwania po słowach kluczowych lub w bazie danych zamiast embeddingów. Napisz wiadomość do kandydata bezpośrednio. Zapisz decyzję o etapie w systemie ATS, zamiast prosić agenta o jej wykonanie. Wyznacz osoby odpowiedzialne za pilne zgłoszenia i rozmowy, żeby „AI oczekuje” nie zmieniło się w „zapomniany kandydat”.

Jeśli zespół używa asystenta do obsługi narzędzi rekrutacyjnych, ponownie przeanalizuj granice uprawnień i zatwierdzania opisane we wdrażaniu agentów AI do rekrutacji za pomocą MCP. Kontrakt narzędzia może pozostać dostępny, gdy model nim sterujący nie działa.

4. Sprawdź powrót do działania przy ograniczonym budżecie

Nie uruchamiaj wszystkich zaległych zadań, gdy tylko strona statusu przestanie zgłaszać awarię. Przepuść przez obwód półotwarty niewielki zestaw aktualnych zadań o małym ryzyku. Obserwuj opóźnienie, odsetek błędów, odpowiedzi sygnalizujące rate limiting, czas oczekiwania zadań w kolejce i poprawność wyników. Stopniowo przywracaj procesy pobierające zadania i zachowaj część przepustowości dla nowych zgłoszeń kandydatów.

5. Uzgodnij stan przed ponowieniem

Wznowienie działania wymaga porównania danych w bazie, a nie tylko opróżnienia kolejki. Przy każdym zadaniu oczekującym lub zakończonym błędem sprawdź, czy wersja danych źródłowych jest aktualna, czy termin nadal ma znaczenie, czy równoważny wynik już istnieje oraz czy człowiek nie wykonał działania ręcznie. Przed kolejną próbą sprawdź w systemach zewnętrznych, co już się wydarzyło, na przykład czy e-mail został wysłany albo spotkanie zarezerwowane.

Najpierw zajmij się bieżącą komunikacją z kandydatami i aktywnymi wakatami. Oznacz nieaktualną pracę jako zastąpioną. Anuluj zadania, które straciły już sens biznesowy. Ponawiaj tylko aktualne zadania z prawidłowymi kluczami idempotencji, a następnie porównaj oczekiwane i rzeczywiste dane. W historii incydentu zachowaj liczby zadań ukończonych, pominiętych, anulowanych i rozwiązanych ręcznie.

Wykonuj takie ćwiczenie raz na kwartał i po każdej istotnej zmianie procesu. Sprawdzaj, czy nadal można przesłać zgłoszenie, czy rekruter potrafi rozpoznać nieudane wzbogacenie danych i czy przywrócenie działania nie tworzy powielonych działań wobec kandydatów. Te wyniki znaczą więcej niż deklarowany procent dostępności.

Co Kit utrzymuje w działaniu, a gdzie nadal zależy od AI?

Kit oddziela podstawowe dane rekrutacyjne i wiele ręcznych procesów od wzbogacania przez AI. Nie obiecuje jednak rekrutacji działającej całkowicie offline ani automatycznego przełączania dostawców na podstawie stanu ich usług. Uczciwa obietnica ciągłości jest węższa: dane rekrutacyjne pozostają zapisane, nawet gdy wspomaganie zależne od modeli w widoczny sposób przestaje działać.

Publiczny formularz zgłoszeniowy zapisuje dane kandydata, zgłoszenie, zgodę, przesłany formularz i etap początkowy w jednej transakcji bazy danych. Dopiero po jej zatwierdzeniu uruchamia się analiza CV. Jeśli analiza się nie powiedzie, zgłoszenie nie znika. Ręczne zmiany etapów zapisują wiążący stan pipeline niezależnie od tego, czy wykonano je w interfejsie webowym, czy przez narzędzie MCP. Model, który decyduje o wywołaniu tego narzędzia, jest osobną zależnością.

Rekruterzy mogą tworzyć zaproszenia na rozmowy, kandydaci mogą potwierdzać terminy umawiane bezpośrednio w Kit, a zespoły mogą zachowywać wiadomości napisane przez ludzi i szablony Liquid bez wywoływania modelu. Te ścieżki nadal zależą od dostępności kalendarza, tworzenia spotkań w Google Meet lub Calendly, zadań w tle oraz dostarczania poczty przez SMTP. Nazywanie ich całkowicie offline byłoby nieprawdą.

W konkretnych miejscach Kit ma także ograniczone mechanizmy zapasowe. Gdy dostawca lub warstwa transportowa nie działa, funkcja tworzenia odpowiedzi przez AI może wstawić do edytora z góry określony tekst początkowy. Część wyszukiwań semantycznych przełącza się z embeddingów Gemini na wyszukiwanie tekstowe w PostgreSQL. Narzędzia podsumowujące zgłoszenia i kandydatów serializują zapisane dane, zamiast samodzielnie generować opis. Podłączony model może je interpretować, ale zapis tych danych od niego nie zależy. Nasz materiał o MCP w rekrutacji wyjaśnia ten podział między modelem a narzędziami rekrutacyjnymi, o których użycie może poprosić.

Trzeba też jasno nazwać ograniczenia. Kit nie monitoruje stanu dostawców i nie przełącza się automatycznie między Gemini, Anthropic i OpenRouter. Przejście na słabszy model odbywa się tylko w obrębie skonfigurowanego dostawcy. Ogólne błędy czatu są pokazywane jako błędy, a nie kierowane do uniwersalnego mechanizmu ponowień. Nieudana analiza CV i pól dodatkowych może wymagać ręcznej interwencji, a embeddingi nadal zależą od Gemini, nawet jeśli czat korzysta z innego dostawcy. Kit nie ponawia każdego nieudanego wzbogacenia danych i nie usuwa zależności od kalendarzy, SMTP ani modeli.

Taki standard warto stosować wobec każdego systemu ATS od podstaw opartego na AI: gdy strona statusu modelu pokazuje awarię, dane rekrutacyjne muszą pozostać dostępne. Zgłoszenia i decyzje muszą pozostać wiążącym zapisem, zadania AI mają tworzyć dane pochodne i dawać się bezpiecznie przywrócić, a ścieżka ręczna powinna być oczywista, zanim stanie się potrzebna.