Agenci AI w firmie: co naprawdę potrafią — test 10 zadań biznesowych 

Agenci AI są dziś opisywani jako wirtualni koledzy, którzy przejmują procesy. Zanim oddasz im cokolwiek w firmie, warto odpowiedzieć sobie na jedno pytanie: czym właściwie dysponujemy. Poniżej przechodzę przez dziesięć zadań biznesowych, które producenci opisują jako zautomatyzowalne, i sprawdzam, co stoi za tymi opisami. Źródłem są dwanaście materiałów producentów, konsultingów i redakcji technicznych. Wynik jest mniej efektowny niż prezentacje, ale bardziej użyteczny przy decyzji, na którą proces i ile czasu wydać.

Ostrzegam na wstępie o jednym: w całym zestawie źródeł, które przejrzałem, nie ma ani jednego niezależnego pomiaru skuteczności agenta na konkretnym zadaniu biznesowym. Nie ma wyników z publicznych benchmarków. Nie ma liczby określającej, ile godzin agent pracuje bez nadzoru. To nie znaczy, że agenci nie działają. Znaczy, że nikt jeszcze nie opublikował rzetelnego testu, na którym można oprzeć decyzję budżetową. Cała reszta tego artykułu to rozkładanie tego, co realnie da się sprawdzić samodzielnie.

Czym agent AI różni się od chatbota, z którym rozmawiasz

NVIDIA definiuje to wprost: klasyczne aplikacje zbudowane na modelach generatywnych działają w schemacie „zapytanie i odpowiedź”. Agent to system ukierunkowany na cel, który koordynuje modele z narzędziami zewnętrznymi, żeby zaplanować i wykonać zadanie wieloetapowe.

Salesforce rozróżnia dwie klasy. Asystent, czyli copilot, działa z interwencją człowieka przy wielu zadaniach. Tylko agent autonomiczny potrafi wykonać kilka zadań pod rząd. Microsoft pisze podobnie: agent autonomiczny podejmuje decyzje i działa na podstawie celu, danych i kontekstu, bez człowieka przy każdym kroku. Agent nieautonomiczny trzyma się sztywnych reguł.

Najbardziej praktyczna różnica dotyczy tego, kiedy w ogóle sięgać po agenta. Microsoft dzieli zadania na dwa typy: stabilne i przewidywalne pasują do klasycznej automatyzacji RPA, natomiast agent obsługuje środowiska, w których reguły się psują i potrzebna jest elastyczność. Jeśli proces jest stały, dobra klasyczna automatyzacja będzie tańsza i bardziej przewidywalna niż agent. Jeśli reguły zmieniają się co miesiąc, agent zaczyna mieć sens.

TechRadar Pro ostrzega, że na rynku łatwo kupić reguły opisane słowem „AI”. Autor pisze wprost, że silnik reguł pyta sobie „która reguła powinna zadziałać dla tego wejścia”, a agent pyta „co mam zrobić, żeby zbliżyć się do celu”. To różnica w sposobie podejmowania decyzji, nie w zestawie możliwych operacji. Różnicę między automatyzacją a AI dobrze opisuje osobny tekst. Agent jest droższy w utrzymaniu, więc musi dostać zadanie, w którym twoja wiedza o procesie nie wystarcza.

Co mówią liczby, a czego w ogóle nie ma

Badanie Capgemini obejmujące 1500 kadrowych dyrektorów w 14 krajach daje obraz rynku, który jest dużo mniej rozwinięty, niż sugeruje marketing. Tylko 2% organizacji wdrożyło agentów na skalę, 12% na skalę częściową, 23% uruchomiło pilotaże, a 61% dopiero rozpoznaje temat.

Z tego samego badania: 15% procesów biznesowych ma osiągnąć pełną lub częściową autonomię w ciągu 12 miesięcy. Uwaga na sformułowanie: to procesy, nie zadania. Mniej niż jedna firma na pięć uważa, że ma dojrzałą infrastrukturę danych i technologii potrzebną do wdrożenia agentów. Zaufanie do w pełni autonomicznych agentów spadło w ciągu roku z 43% do 27%.

Te ostatnie dwie liczby dobrze się uzupełniają. Spadek zaufania nie wynika z braku chęci, tylko z doświadczeń z wdrożeń. Raport Capgemini to badanie konsultingu, a raport pobiera się po zapisaniu się. Nie jest to niezależny pomiar, ale jest to jedyne liczbowe źródło w całym zestawie, które opisuje rynek jako całość. Warto porównać je z oceną, co w małej firmie realnie się opłaca, a co zostało jeszcze napisane w ofercie.

Czego nie ma, jest równie ważne. Nie ma horyzontu autonomii, czyli odpowiedzi na pytanie, ile czasu agent pracuje sam. Nie ma wyników z benchmarków zadań. Nie ma odsetka zadań, które kończą się eskalacją do człowieka. Nie ma kosztów w złotych dla firmy z Polski. Wszystkie opisy wdrożeń, które przeczytałem, dotyczą bankowości, ubezpieczeń i doradztwa inwestycyjnego w Stanach Zjednoczonych. Jeśli ktoś sprzedaje Ci „agenta księgowego z integracją z polskim ERP-em”, zapytaj o konkretny projekt, a nie o materiał marketingowy.

Dziesięć zadań, które producenci opisują jako zautomatyzowalne

Przeszedłem przez dziesięć obszarów, które pojawiają się w materiałach źródlowych. Dla każdego podaję, co konkretnie opisuje źródło i czy podaje ono jakikolwiek pomiar. Zdanie „źródło nie podaje wyniku” powtarza się częściej, niż bym chciał. Z dziesięciu obszarów tylko jeden ma liczby, i to liczby sprzedawcy jego własnego produktu.

• Obsługa klienta zbieranie danych sprawy, analiza nastroju z e-maili i eskalacja pilnych spraw do właściwego zespołu. Wariant głosowy działa całodobowo, odpowiada na typowe pytania i pomaga w umawianiu wizyt.
• Sprzedaż pobranie informacji produktowej z CRM, odpowiedź na pytanie klienta i zaplanowanie follow-upu w jednym czacie. Dla małych firm: pomoc w pozyskiwaniu leadów i prowadzeniu spersonalizowanych kampanii.
• Raportowanie analiza danych sprzedażowych i wygenerowanie wykresu, przegląd budżetu wobec wydatków rzeczywistych, podpowiedź wykresu i streszczenia gotowego do wklejenia w prezentację.
• Finanse i spory transakcyjne agent bankowy obsługuje reklamację przez aplikację, SMS, stronę i telefon: składa zgłoszenie, sprawdza historię transakcji, uprzedza merchant, wystawia kredyt tymczasowy. To najlepiej udokumentowany proces w całym zestawie.
• Wykrywanie oszustw monitorowanie transakcji w czasie rzeczywistym, wykrywanie nietypowych wzorców, na przykład kilku dużych wypłat z nowej lokalizacji, i oznaczanie aktywności do przeglądu.
• Kodowanie i testy pisanie testów end-to-end z opisu słownego, zamiana dokumentacji i ticketów w przypadki testowe, eksport kodu do Playwright i Selenium, analiza przyczyn błędów na podstawie logów i historii, naprawianie testów, które losowo się psują.
• Logistyka sortowanie paczek, planowanie tras, zarządzanie magazynem, prognozowanie popytu pod stany magazynowe, automatyczne zwroty i monitorowanie przesyłek.
• Administracja wprowadzanie danych, planowanie, obsługa zapasów, oraz agent działający całodobowo jako asystent AIOps monitorujący systemy i wywołujący naprawy.
• Pomoc prawna składanie i montaż dokumentów, w tym wniosków wizowych, oraz analiza tekstów prawnych i precedensów.
• Rekrutacja tu jest dziura. W dwunastu źródłach nie ma ani jednego konkretnego przykładu agenta rekrutacyjnego ani kadrowego. Są wzmianki o łączeniu systemów HR, ale żadnego zadania z wynikiem.

Dziewięć z dziesięciu obszarów ma przykłady użycia. Żaden z tych przykładów nie ma liczby. Jedyny zestaw liczb, jaki udało się znaleźć, dotyczy testowania: dostawca deklaruje 91% dokładności generowania przypadków testowych, nawet do 90% szybcsze ich tworzenie i 50% większe pokrycie. To deklaracje sprzedawcy własnego produktu, bez niezależnego audytu, i dotyczą cząstki zadania, a nie całego procesu. Jeśli ktoś podaje Ci taką liczbę jako dowód, że „agenci mają 90%”, pytaj o miernik. Z drugiej strony część z tych obszarów pokrywa się z procesami, które warto automatyzować niezależnie od tego, czy obsługuje je agent czy klasyczny skrypt, o czym pisałem przy siedmiu procesach wartych automatyzacji w firmie.

Sześć bramek, które musi przejść agent przed produkcją

Jest jednak konkretna metoda oceny. TestQuality, cytując dokumentację Anthropic i Block Engineering, opisuje sześć niezależnych bram, które każdy komponent musi przejść osobno.

Brama	Wartość progowa	Co sprawdza
Domykanie zadania	90% lub więcej	Jaka część sesji kończy się celem, a nie pozornie wykonaną pracą
Poprawność wywołań narzędzi	95% lub więcej	Dobór narzędzia, zgodność argumentów ze schematem, odczyt odpowiedzi
Odzyskiwanie po błędzie	70% jako podłoga	Czy agent próbuje innej drogi zamiast zawieść po cichu
Latencja p99	99% sesji poniżej 30 sekund	Ogon rozkładu czasu odpowiedzi, który kumuluje się przy wywołaniach sekwencyjnych
Częstotliwość zabezpieczeń	1 do 5%	Częstość interwencji filtrów, nagły wzrost sygnalizuje atak lub źle ustawioną regułę
Ocena jakościowa	4,0 w skali 5	Ugruntowanie faktów, zgodność z instrukcją, ochrona danych, wierność planowi

Wartość progowa nie jest wynikiem agenta. To próg, poniżej którego wdrożenie nie wchodzi na produkcję. Różnica jest fundamentalna i większość ofert ją zaciera.

Osobno trzeba powiedzieć o tym, jak liczyć wynik. Wynik zbiorczy ukrywa awarie składowe: przykład z tego samego źródła pokazuje, że 92% ogółu może zamaskować 40% awarii w jednym wzorcu wywołania narzędzia, który dotyka każdego użytkownika danego przepływu. Dlatego progi ustawia się osobno dla każdej metryki, a nie jednym zbiorczym procentem. Jeśli ktoś raportuje Ci jeden wielki procent skuteczności, to najczęściej jest to ten właśnie zakryty przypadek.

Cztery awarie, których nie widać w logach

Najniebezpieczniejszy tryb awarii nie wygląda jak awaria. Gdy agent wywołuje zewnętrzne narzędzie i dostaje poprawną odpowiedź 200 OK z poprawnym JSON-em, ale źle odczyta znaczenie odpowiedzi, nic nie wybucha. Agent idzie dalej z błędnym założeniem i oddaje niepoprawny wynik z pewnością siebie, której nie uzasadnia. Monitorowanie szukające wyjątków, awarii i kodów błędów HTTP tego nie zobaczy. Jedyna metoda wykrycia to audyt całej sekwencji kroków.

Klasyczny przykład: agent zamawia towar, sprawdza stan magazynu i wystawia fakturę. Jeśli błędnie odczyta pole „dostępna ilość” jako „zamówiona ilość”, zamówi za dużo, a system nie zgłosi żadnego błędu. Tradycyjny błąd oprogramowania krzyczy. Agent może spokojnie zwrócić złą odpowiedź.

Drugi typ to pozornie poprawna praca. Agent resetujący hasło może wysłać maila i trafić w adres, ale dlatego, że zgadł identyfikator zamiast odczytać go z sesji. Wynik jest poprawny, a procedura jest wadliwa. IBM ujmuje to samo wprost: testowanie agenta nie powinno brać pod uwagę wyłącznie poprawności odpowiedzi, lecz także tego, czy ścieżki rozumowania i wyniki pośrednie były właściwe.

Trzeci typ jest mniej znany. Gdy kontekst modelu zbliża się do granicy, zaczyna skracać zadanie, pomijać kroki walidacji i czasem wymyśla wniosek, żeby zdążyć przed końcem okna. Nazywane jest to niepokojem kontekstu. Dotyka dokładnie długich procesów w firmie, czyli tygodniowego zamknięcia miesiąca albo sezonowej kampanii. Im dłuższy przepływ, tym większe ryzyko, że agent skończy pracę pozornie.

Czwarty: model nie oceni samego siebie wiarygodnie. Gdy poprosisz go o ocenę własnej pracy, konsekwentnie wystawia przeciętne i niepełne odpowiedzi jako dobre, bo model oceniający dzieli z modelem autorów te same ograniczenia. Wewnętrzna pętla „agent sprawdza siebie” nie działa jako bramka jakości.

Kilka słów o słowach, czyli wrażliwość na sformułowanie

Te same dane w innym brzmieniu dają inne zachowanie. „Anuluj zamówienie” i „chcę zatrzymać przesyłkę” wywołują u tego samego modelu zupełnie inne sekwencje rozumowania i inne wzorce wyboru narzędzi. Nikt nie zaprogramował tej różnicy. W firmowym procesie oznacza to, że dwie osoby wysyłające podobne polecenie mogą uruchomić zupełnie różne ścieżki, a różnica nie wynika z intencji, tylko ze słowa.

Do tego dochodzi kumulacja błędów. IBM opisuje to wprost: agenci często wykonują wieloetapowe łańcuchy rozumowania i działania, więc błąd w dowolnym miejscu łańcucha się wzmacnia. Im dłuższy proces, tym mniejsza szansa, że wszystkie kroki będą poprawne naraz. Praktyczna konsekwencja jest taka, że im więcej kroków automatyzujesz, tym częściej musisz sprawdzać wynik pośredni, a nie tylko końcowy.

Bezpieczeństwo, dane firmowe i koszt, którego nie da się zaplanować

Agenci przeglądający sieć i integrujący się z zewnętrznymi API są narażeni na ataki prompt injection i jailbreaky. To standardowy wniosek z testowania bezpieczeństwa, nie egzotyczny przypadek.

Osobny problem jest mniej oczywisty: dane wychodzą. Gdy używasz publicznego modelu językowego, twoje dane trafiają do cudzej infrastruktury. Zapewnienie „nie wykorzystujemy danych klientów do treningu” mówi niewiele, bo wejście i tak jest przyjmowane, przetwarzane i przechowywane zgodnie z wewnętrznymi politykami dostawcy, a te polityki się zmieniają. W praktyce wystarczy jeden pracownik, który przyklei arkusz z wewnętrznym cennikiem do okna promptu, i masz problem z poufnością.

Stąd wymóg, który brzmi technicznie, a jest biznesowy. NVIDIA opisuje każdego agenta działającego w piaskownicy, żeby nawet w razie zmanipulowania nie zniszczył systemu, nie wyciekł danych i nie narobił kosztów. Przy wdrożeniu pytaj, co agent ma w swoim zakresie uprawnień, a gdzie wymaga zatwierdzenia.

Koszt jest mniej przewidywalny, niż sugerują abonamenty. Rozliczenie tokenowe tworzy model, którego nie da się zaplanować z wyprzedzeniem: każde pytanie, każde wygenerowanie i każda iteracja kosztują, a iterowanie do wyniku akceptowalnego przy złożonej kampanii potrafi zużyć znaczną część budżetu. Subskrypcje firmowe dokładają własne limity użycia. IBM ujmuje to zdaniem, które warto znać na głos: agenci używający drogich narzędzi do prostych podzadań mogą być przy skali kosztowni w stopniu, który uniemożliwia ich utrzymanie. Przed wdrożeniem policz to osobno, z podejściem widełkami kosztu wdrożenia AI i osobnym rachunkiem za zwrot z automatyzacji.

Co zawsze zostaje po stronie człowieka

Firma sprzedająca narzędzia do testowania agentów sama odpowiada wprost na pytanie, czy agenci zastąpią testerów: nie. Agenci obsługują powtarzalne, czasochłonne zadania, czyli testy regresyjne, utrzymanie testów i generowanie przypadków brzegowych, żeby inżynierowie QA mogli zająć się testowaniem eksploracyjnym, strategią i oceną ryzyka. Zdanie zostawiam w oryginale, bo jest charakterystyczne: najlepsze zespoły w 2026 roku używają agentów do mnożenia własnej wydajności, a nie do redukcji załogi.

IBM pisze podobnie o ocenie: sama automatyzacja nie wystarcza do budowania rozbudowanych ekosystemów agentowych. Część osądu wymaga człowieka, na przykład decyzja, czy odpowiedź agenta jest właściwa w wrażliwym kontekście, albo czy przypadek brzegowy ujawniony w teście wynika z dobrego rozumowania, czy z przypadku. Wdrożenie powinno mieć wbudowany strukturalny przegląd przez człowieka, a nie „zero interwencji” z banera produktu.

Warto znać też sprzeczność, którą widać przy uważnym czytaniu materiałów jednej firmy. Salesforce w jednym miejscu opisuje agentów ubezpieczeniowych jako działających bez ludzkiej interwencji, a w innym tłumaczy, że tacy agenci przekazują sprawę człowiekowi do przeglądu i nadania uprawnień oraz kierują komunikację do właściwych nadzorców. Druga wersja bliższa jest rzeczywistości niż pierwsza.

Jak sprawdzić agenta u siebie, zanim mu powiesz zrobić

Skoro niezależnych benchmarków nie ma, test musisz zrobić na własnych danych. Podejście jest prostsze, niż sugeruje temat.

Krok pierwszy: 20 do 50 scenariuszy. Zestaw przedprodukcyjny zaczyna się od kuratorowanego zestawu jednoznacznych scenariuszy, wziętych z realnych sesji debugowania i znanych trybów awarii. Dziesięć z nich dzielisz na testy zdolności, które mają niski wynik przejścia i naprawiają konkretne braki, oraz testy regresji, które mają wynik bliski 100% i chronią to, co już działa.

Krok drugi: testuj zarówno ścieżki, które powinny się wykonać, jak i te, które nie powinny. Zestaw zdominowany prostymi przypadkami daje ładne liczby, które nic nie mówią o produkcji.

Krok trze: mierz wariancję, nie jedno uruchomienie. Modele językowe odpowiadają różnie na podobne podpowiedzi, więc jedna sesja nie jest wynikiem. IBM wskazuje też, że awaria na wczesnym etapie wieloetapowego przepływu może ujawnić się dopiero później.

Krok czwarty: pilnuj danych wejściowych. API, narzędzia i reguły biznesowe zmieniają się szybko, a hardkodowany zbiór danych traci aktualność i obniża jakość agenta. Dane zgromadzone na potrzeby pierwszego pilota tracą wartość po miesiącu.

Krok piąty: zacznij małym projektem. Rada Microsoft jest wprost: najpierw pilotaż, pomiar skuteczności, naprawa problemów, dopiero potem wdrożenie. Zanim wybierzesz obszar, warto zmapować procesy i znaleźć zadania do automatyzacji.

Jest jeszcze jedna zasada testowania, którą łatwo pominąć. Jeśli wynik ocenia model językowy, ten sam przypadek powinien przejść przez niego co najmniej trzy razy, a werdyktem jest większość, czyli dwa zdania „pass” na trzy. Źle skalibrowany sędzia jest tak samo groźny jak źle działający agent, bo po cichu przepuszcza regresje na produkcję.

Co zrobić w tym tygodniu

Agenci AI potrafią dziś obsłużyć wiele z dziesięciu zadań opisanych wyżej, lecz żadne z tych opisów nie zostało zweryfikowane niezależnym pomiarem na zadaniu biznesowym. Nie ma technologii, która sama się obroni przed tym problemem, bo problem jest po stronie dowodu, nie kodu.

Praktycznie: wybierz jedno zadanie, które jest powtarzalne, mierzalne w godzinach i znośne, gdy agent się pomyli. Przygotuj 20 własnych scenariuszy na podstawie tego, co faktycznie robisz. Sprawdź, czy agent zadanie domyka, i policz, ile godzin to realnie oszczędza. Jeśli po miesiącu potrafisz powtórzyć ten pomiar i wynik jest stabilny, masz wdrożenie. Jeśli nie, masz eksperyment, który kosztował miesiąc, a nie automatyzację, na której możesz polegać w procesie zamknięcia miesiąca.

Jeśli chcesz przejść od teorii do konkretnego procesu, zacznij od planu na pierwszy miesiąc i wybierz zadanie, które da się policzyć w godzinach, zanim ruszysz z czymś, czego nie zmierzysz.