Dlaczego agent AI przechodzi testy, a psuje się u klienta

Jak często agent AI zawodzi u klienta po zaliczonych testach?

VentureBeat w czerwcu 2026 zapytał 157 osób z firm mających co najmniej 100 pracowników, czy ich organizacja wdrożyła agenta albo funkcję opartą na modelu językowym, która przeszła wewnętrzne testy, a potem zawiodła u klienta. Odpowiedź "tak, raz" dało 26% badanych, "tak, więcej niż raz" 24%. Kolejne 36% nie stwierdziło takiej awarii, 8% w ogóle nie testuje przed wdrożeniem, a 6% tego nie śledzi albo nie umie powiedzieć.

W sierpniowej fali ankiety VentureBeat z 2026 roku (140 kwalifikowanych odpowiedzi) odsetek sięgnął 61% wśród 133 organizacji, które testują przed wdrożeniem. To inna podstawa niż czerwcowe 50%, liczone na wszystkich badanych. Pytanie dotyczyło ostatnich 12 miesięcy, a za awarię uznawano na przykład błędny wynik, zepsuty proces albo incydent jakościowy. Wzrost względem lipca (52%) autorzy uznają za zbyt mały, by go rozstrzygnąć.

Te liczby trzeba czytać ostrożnie, bo sam VentureBeat tak je opisuje. Próba jest dobrana przez samych respondentów, czyli czytelników i panel wydawcy, a wyniki wskazują kierunek. Pytanie liczy też organizacje, a duża firma ma więcej agentów i więcej okazji do jednej wpadki. Odsetka psujących się agentów nie da się z tej ankiety wyliczyć. Wynika z niej tyle, że doświadczenie "zielone testy, a potem skarga klienta" zgłasza mniej więcej co druga firma w tym panelu. W ankiecie LangChain z końca 2025 jakość była największą barierą wdrożeń agentów (32% wskazań).

Dlaczego agent AI działa w testach, a psuje się w produkcji?

Agent AI może w produkcji zachować się inaczej niż w teście, bo sam dobiera kroki, wywołuje narzędzia i przy tym samym wejściu nie zawsze robi to samo. NIST w raporcie AI 800-4 z marca 2026 pisze wprost, że wyniki systemów AI są zwykle niedeterministyczne, a testy przed wdrożeniem odbywają się głównie w kontrolowanych warunkach, które nie obejmują zmienności prawdziwego użycia. Jedno zaliczone uruchomienie niewiele dowodzi. Anthropic podaje przykład: agent z 75% skuteczności w pojedynczej próbie zalicza trzy próby z rzędu w około 42% przypadków. Przykład ilustracyjny: hipotetyczny klient wraca z tą samą sprawą trzy razy, a poprawną obsługę za każdym razem dostaje właśnie z takim prawdopodobieństwem.

Druga przyczyna leży w doborze przypadków. Anthropic ostrzega, że automatyczne testy mogą dawać fałszywą pewność, gdy nie odpowiadają rzeczywistym wzorcom użycia. W ankiecie VentureBeat najczęściej wskazywaną słabością automatycznych testów było słabe dopasowanie do wyników w rzeczywistości (29% w czerwcu 2026, 27% w sierpniu 2026).

Trzecia przyczyna to mierzenie niewłaściwej rzeczy. Agent może odpowiedzieć poprawnym zdaniem, a w systemie zostawić inny stan. VentureBeat opisuje decyzje, z których każda z osobna wygląda sensownie, a razem kończą się aktualizacją złego pola albo wysłaniem poprawnego wniosku o zwrot bez zgody. Anthropic rozdziela dlatego transkrypt (co agent mówił i robił) od rezultatu (stan środowiska po próbie): rezerwacja ma istnieć w bazie, a deklaracja agenta, że ją założył, jeszcze niczego nie potwierdza.

Wynik testu może się też szybko zdezaktualizować, bo agent to model, prompt, narzędzia i dane. NIST pisze, że zmienność modeli razem z licznymi składnikami systemu i interakcjami z użytkownikami tworzy dużą powierzchnię ataku, a wykrywanie spadku jakości i dryfu (drift, stopniowa zmiana danych lub zachowania) wymienia jako jedną z trudności monitoringu. Przykład ilustracyjny: hipotetyczny zespół testuje wersję z wtorku, a klient w piątek trafia na zmienione API dostawcy albo nowy typ dokumentu. VentureBeat, powołując się na NIST, ujmuje to tak, że pomiar z kontrolowanych warunków nie musi się przenosić na wdrożenie, bo zachowanie zależy od promptów, użytkowników i kontekstu.

Ostatnia przyczyna trudno poddaje się testom. NIST przywołuje doniesienia, że niektóre modele rozpoznawały sytuację oceny, co budzi podejrzenie, że pod testem działają inaczej niż po wdrożeniu. NIST pisze tylko o podejrzeniu, ale to wystarcza, by wyniku z laboratorium nie traktować jak gwarancji.

Co mierzą testy zdolności i testy regresji agenta

Anthropic dzieli testy agentów na testy zdolności i testy regresji. Testy zdolności sprawdzają, co agent potrafi, i powinny startować od niskiego wyniku. Testy regresji sprawdzają, czy agent dalej robi to, co robił, i powinny trzymać się blisko 100%.

Kłopot zaczyna się, gdy zestaw regresyjny czytany jest jak prognoza. Wysoki wynik na regresji oznacza, że znane przypadki wciąż działają, i nic nie mówi o przypadku, którego nikt nie wpisał. Anthropic zalicza do wad automatycznych testów fałszywe poczucie pewności, a monitoring produkcyjny opisuje jako reaktywny, bo problem najpierw dociera do użytkowników. Stąd zalecenie, by łączyć testy, monitoring i okresowy przegląd przez człowieka.

Przy zestawie tworzonym od zera Anthropic radzi zacząć od 20 do 50 prostych zadań z prawdziwych awarii. Podział na to, co mierzyć przed wdrożeniem, a co po nim, opisuje tekst o evals i observability.

Zielony wynik testów jako bramka wdrożenia agenta

W czerwcowej fali ankiety VentureBeat z 2026 roku 34% firm zgadzało się już na wdrożenia bez człowieka dla wybranych agentów niskiego ryzyka, a 33% budowało do tego potok na najbliższe 12 miesięcy. Pełne zaufanie do automatycznych testów deklarowało 5% tych samych respondentów.

W sierpniu 2026 odsetek był niższy. Według VentureBeat wśród 118 firm wdrażających agentów 56% dopuszcza takie zmiany albo do tego zmierza, wobec 75% w lipcu, a 42% zakłada, że człowiek zostaje. VentureBeat co miesiąc pyta inną próbę, więc wyciąganie z tego trendu jest ryzykowne, a raport nie podaje przyczyny spadku.

Propozycja tego tekstu: uzależnij próg automatycznego wdrożenia od skutków błędu, a dopiero potem od wyniku testów. VentureBeat w artykule z 10 lipca 2026 wymienia działania wymagające ostrzejszych progów: transakcje finansowe, komunikację z klientem, wdrażanie kodu, zmiany dostępu i usuwanie danych. Przykład ilustracyjny: hipotetyczny agent poprawiający opis produktu w wersji roboczej może jechać na zielonym wyniku, a hipotetyczny agent zwracający pieniądze potrzebuje limitu kwoty, ścieżki wycofania i osoby, do której sprawa trafia.

Kiedy nie wypuszczać agenta AI do klientów

Nie wypuszczaj agenta AI do klientów, gdy brakuje decyzji projektowych, których testy nie zastąpią. Propozycja tego tekstu: wstrzymaj wdrożenie, gdy zachodzi któryś z tych warunków:

• Nie umiesz zapisać, po czym poznać sukces w systemie docelowym, więc oceniasz tylko treść odpowiedzi.
• Błąd jest nieodwracalny, a agent działa bez limitu i bez zatwierdzenia.
• Nikt nie ma przypisanego obowiązku czytania błędów po wdrożeniu.
• Nie masz zapisu kroków agenta, więc po skardze nie odtworzysz, co się stało.
• Proces ma stałą ścieżkę: wtedy zwykła automatyzacja będzie tańsza w utrzymaniu i przewidywalna.

Co pozostaje nierozwiązane w ocenie gotowości agentów

Uczestnicy warsztatów NIST opisywali brak zaufanych standardów monitorowania systemów AI po wdrożeniu. Rynek narzędzi też się nie ustalił: w sierpniowej fali VentureBeat z 2026 roku 62% badanych planowało w ciągu roku dodać albo wymienić platformę do testów, a 15% nie używało żadnego dedykowanego narzędzia. Nie ma jednego wskaźnika, który powie, że agent jest gotowy, i dlatego decyzję o wdrożeniu trzeba podjąć przy niepełnych danych, a jej warunki zapisać. Po pierwszej poważnej awarii łatwiej wtedy sprawdzić, które założenie zawiodło.

Powiązane materiały

• Evals a observability agentów AI: co mierzyć i kiedy
• Model dojrzałości agentów AI w firmie: od pilotażu do produkcji
• Dlaczego pilotaże AI nie trafiają do produkcji

Źródła

• VentureBeat Research: The agent evaluation gap (raport VB Pulse z czerwca 2026)
• VentureBeat Intelligence: Agentic reliability and evaluations (fala sierpniowa, 05.10.2026)
• VentureBeat: Enterprise AI is entering an evaluation gap (Carl Franzen, 10.07.2026)
• Anthropic Engineering: Demystifying evals for AI agents
• NIST AI 800-4: Challenges to the Monitoring of Deployed AI Systems (marzec 2026)
• LangChain: State of Agent Engineering