AI odmawia wykonania zadania

Model AI może być dostępny, działać poprawnie i jednocześnie nie wykonać zadania, którego firma od niego oczekuje. W przypadku agentów wykonujących wieloetapową pracę odmowa nie jest już tylko komunikatem w oknie czatu. Może oznaczać przerwany proces, konieczność przejęcia pracy przez inny model i dodatkowy koszt po stronie organizacji.

Przez ostatnie lata przy wyborze modeli AI nauczyliśmy się patrzeć na coraz więcej parametrów: jakość odpowiedzi, cenę miliona tokenów, wielkość kontekstu, szybkość, obsługę narzędzi czy możliwości programistyczne. To wszystko jest ważne. Problem w tym, że wraz z rozwojem agentów AI pojawia się jeszcze jedno kryterium, które w klasycznych porównaniach często ginie:

Czy model, który rozpoczął zadanie, będzie w stanie doprowadzić je do końca — także wtedy, gdy po drodze pojawi się błąd?

To pytanie przestaje być teoretyczne. GPT-6 Astra, model OpenAI przeznaczony m.in. do kodowania i złożonej pracy agentowej, otrzymał dodatkowe mechanizmy bezpieczeństwa wynikające z jego bardzo wysokich możliwości w cyberbezpieczeństwie. OpenAI samo informuje, że te mechanizmy mogą czasem spowolnić, wstrzymać albo zatrzymać również legalną pracę. W przypadku API zadanie może zostać po prostu zakończone.

Z perspektywy dostawcy jest to zabezpieczenie. Z perspektywy firmy, która oparła na agencie fragment procesu, może to być przerwanie świadczenia funkcji dokładnie wtedy, gdy jest ona potrzebna.

Dostępna usługa to nie zawsze dostępna funkcja

W klasycznym systemie informatycznym awaria jest stosunkowo łatwa do sklasyfikowania. Serwer nie odpowiada, API zwraca błąd, baza danych jest niedostępna albo aplikacja przekroczyła limit zasobów. W przypadku agentów AI dochodzi nowy stan:

usługa działa → model rozumie zadanie → posiada odpowiednie możliwości → polityka zatrzymuje wykonanie

Technicznie system nie jest niedostępny. Model nie musi też mieć problemu kompetencyjnego. A jednak funkcja biznesowa pozostaje niewykonana.

To ważne rozróżnienie, bo z punktu widzenia właściciela procesu końcowy rezultat jest taki sam jak przy awarii: trzeba znaleźć inną drogę realizacji zadania.

Najgorszy moment na odmowę? Po rozpoczęciu pracy

Podczas mojego własnego testu Astry wystąpiła sytuacja szczególnie problematyczna z perspektywy procesu wytwarzania oprogramowania. Model uczestniczył w przygotowaniu kodu, natomiast po wykryciu problemu odmówił dalszej pracy nad jego poprawą.

Nie chodzi więc o scenariusz:

zadanie → odmowa → wybieramy inne narzędzie

To byłoby stosunkowo łatwe do obsłużenia. Znacznie trudniejszy jest przebieg:

analiza → zmiana kodu → defekt → próba naprawy → odmowa

W tym momencie firma ma już artefakt powstały przy udziale modelu, ale naprawę musi przejąć inny wykonawca. Może nim być człowiek albo inny model AI. Oba warianty oznaczają konieczność ponownego zbudowania kontekstu.

Jeżeli nowy model jest słabszy od modelu, który stworzył zmianę, pojawia się dodatkowe pytanie: czy poradzi sobie z naprawą rozwiązania stworzonego przez bardziej zaawansowanego poprzednika?

W klasycznej organizacji przypominałoby to sytuację, w której najbardziej doświadczony deweloper tworzy skomplikowany fragment systemu, a po wystąpieniu błędu oznajmia, że dalsza praca jest poza zakresem jego obowiązków. Projekt nadal trzeba naprawić. Tyle że teraz musi to zrobić ktoś, kto nie uczestniczył w podejmowaniu wcześniejszych decyzji.

Koszt odmowy nie kończy się na tokenach

Przy porównywaniu modeli AI łatwo skoncentrować się na cenniku API. Tymczasem koszt pojedynczego zadania może być tylko niewielką częścią kosztu całego procesu.

Skutek odmowy	Potencjalny koszt dla firmy
Przerwanie zadania	Czas operatora potrzebny do ustalenia, co faktycznie zostało wykonane
Zmiana modelu	Ponowne przekazanie kontekstu i odtworzenie założeń
Przejęcie kodu przez innego wykonawcę	Analiza zmian, przegląd diffu i ponowne testy
Stan pośredni systemu	Rollback albo ręczne doprowadzenie środowiska do spójnego stanu
Opóźnienie procesu	Wpływ na termin realizacji, SLA albo pracę innych zespołów

Nie twierdzę przy tym, że każdy provider nalicza opłatę za odmowę w identyczny sposób. Modele rozliczeń są różne. Znacznie ważniejsza jest szersza miara:

Nie tylko „cena za token”, ale koszt skutecznie zakończonego zadania.

Model nominalnie droższy, ale przewidywalny i łatwy do zastąpienia, może być w procesie tańszy od modelu, który wymaga dodatkowej obsługi wyjątków i przejmowania rozpoczętych zadań.

Bezpieczeństwo dostawcy i bezpieczeństwo użytkownika to nie to samo

W tym miejscu dochodzimy do szerszego problemu. Bezpieczeństwo AI nie jest pojęciem bezwzględnym.

Dostawca modelu chce ograniczyć ryzyko wykorzystania jego technologii do działań szkodliwych.
Firma korzystająca z modelu chce zapewnić ciągłość procesu i kontrolę nad swoim systemem.
Operator chce wiedzieć, czy wydane polecenie zostanie wykonane i co nastąpi w przypadku błędu.
Właściciel danych chce ograniczyć zakres informacji przekazywanych zewnętrznym podmiotom.

Te cele często się pokrywają, ale nie zawsze. Mechanizm ograniczający ryzyko dostawcy może jednocześnie stworzyć nowe ryzyko operacyjne po stronie użytkownika.

Szerzej analizuję ten problem w artykule „Bezpieczne korzystanie z AI” na Technologie-AI.pl, gdzie pokazuję różne perspektywy bezpieczeństwa oraz znaczenie architektury, w której model pozostaje jednym z komponentów, a nie właścicielem całej ścieżki wykonawczej.

Uzależnienie od dostawcy obejmuje również sposób pracy

Vendor lock-in w przypadku AI zwykle kojarzymy z API, formatem danych, cenami albo migracją promptów. Agent AI dodaje jeszcze jeden wymiar: zależność od zachowania modelu i jego polityki wykonania.

Firma może posiadać cały kod integracyjny, a mimo to być silnie zależna od jednego providera, jeżeli tylko jego model zna pełny kontekst procesu, historię decyzji i stan rozpoczętej pracy.

Dlatego w artykule „Wybór modelu AI w firmie” zwracałem uwagę, że dostęp do technologii przestał być największym problemem. Istotniejsze staje się to, czy rozwiązanie można mierzyć, utrzymać i w razie potrzeby zastąpić.

Przypadek odmowy agenta pokazuje, że możliwość zastąpienia trzeba sprawdzić nie tylko przed wdrożeniem, ale także w połowie rozpoczętego zadania.

Agent powinien być wymiennym wykonawcą, nie właścicielem procesu

Bezpieczniejsza architektura nie musi polegać na znalezieniu jednego „idealnie bezpiecznego” modelu. Można odwrócić problem i założyć, że każdy model jest zawodnym, zewnętrznym wykonawcą.

proces firmy
   ↓
orkiestrator
   ↓
worker AI A / worker AI B / człowiek
   ↓
walidacja
   ↓
commit albo rollback

W takim modelu odmowa Astry, Qwena, DeepSeeka czy dowolnego kolejnego systemu nie powinna oznaczać końca procesu. Powinna oznaczać zmianę wykonawcy.

To podobna zasada do tej, którą od lat stosujemy w dobrze zaprojektowanej automatyzacji. Samo narzędzie nie jest procesem. Pisałem o tym szerzej w materiale „Automatyzacja procesów w firmie – dlaczego samo narzędzie nie wystarczy?”.

Przy agentach AI dochodzi tylko nowy rodzaj wyjątku. Obok timeoutu, błędu API czy niepoprawnego wyniku trzeba uwzględnić również:

POLICY_REFUSAL / POLICY_ABORT

I potraktować go dokładnie jak każdy inny failure mode.

Co sprawdzić przed powierzeniem agentowi procesu?

Przed wdrożeniem agenta AI do rzeczywistego procesu biznesowego warto przeprowadzić kilka prostych testów odbiorczych.

Czy drugi model potrafi przejąć rozpoczęte zadanie?
Czy stan procesu jest zapisany poza sesją modelu?
Czy można jednoznacznie ustalić, które operacje zostały już wykonane?
Czy zmiany są odwracalne albo istnieje rollback?
Czy odmowa modelu jest rejestrowana jako zdarzenie techniczne?
Czy operator posiada niezależną ścieżkę administracyjną?
Czy krytyczne informacje nie istnieją wyłącznie w kontekście jednego dostawcy?

Jeżeli na kilka z tych pytań odpowiedź brzmi „nie”, problemem nie jest już wyłącznie wybór modelu. Problemem jest architektura procesu.

Nie pytaj tylko, czy AI potrafi. Sprawdź, czy proces przetrwa jego odmowę

GPT-6 Astra jest interesującym przykładem bardzo zaawansowanego modelu, którego producent jednocześnie wprowadził rozbudowane zabezpieczenia. OpenAI otwarcie przyznaje, że dodatkowe kontrole mogą czasem zatrzymywać również legalną pracę. To uczciwa informacja — ale dla przedsiębiorstwa powinna być również wymaganiem projektowym.

Nie wystarczy więc sprawdzić:

„Czy ten model potrafi wykonać nasze zadanie?”

Trzeba zadać drugie pytanie:

„Co stanie się z naszym procesem, jeżeli model jutro odmówi wykonania kolejnego kroku?”

Jeżeli odpowiedzią jest: „proces zatrzyma się”, organizacja nie wdrożyła jeszcze bezpiecznego agenta AI. Wdrożyła pojedynczy punkt awarii wyposażony w bardzo inteligentny model.