Najczęstsze błędy wdrażania agentów AI w firmie

Dlaczego wdrożenia agentów AI kończą się rozczarowaniem

Firma kupuje dostęp do modelu, prosi zespół o agenta, dostaje bota, który gubi wątek po trzech pytaniach. Znam ten scenariusz z wielu rozmów i za każdym razem problem leży nie w modelu, tylko w tym, jak system został poskładany. Modele od Anthropic czy OpenAI są dziś na tyle dobre, że rzadko to one zawodzą.

Bo agent AI to nie jedna rozmowa z modelem, tylko cały łańcuch decyzji: skąd bierze dane, jak sprawdza, czy odpowiedź jest poprawna, co robi, kiedy czegoś nie wie, i do jakich systemów firmy w ogóle może sięgnąć. Wystarczy, że jedno z tych ogniw jest słabe, na przykład baza wiedzy pełna sprzecznych dokumentów, i cały efekt wygląda jak porażka modelu, choć model nie miał tu wiele do powiedzenia. Widziałem ten sam mechanizm zarówno w prostych projektach dla obsługi klienta, jak i w rozbudowanych systemach kadrowych.

Buduję agentów AI i systemy wieloagentowe dla firm od lat, sam prowadzę pełną odpowiedzialność za wynik, a przy większych projektach dobieram zespół z Infinity Tech Group albo ClawLabs. Poniżej błędy, które widzę najczęściej przy wdrażaniu agentów AI, zanim firma zapłaci za projekt, który wyląduje w szufladzie.

Błąd pierwszy: agent bez dostępu do prawdziwych danych firmy

Najczęstszy scenariusz porażki wygląda tak: agent ma odpowiadać na pytania kadrowe albo obsługiwać zgłoszenia klientów, ale podłączony jest do jednego przestarzałego pliku PDF albo do ogólnej wiedzy modelu. Odpowiada więc ogólnikami, bo nie ma z czego czerpać konkretów, a klient szybko traci do niego zaufanie.

Agent, który ma realnie odciążyć ludzi, musi sięgać do dokumentów firmy i wykonywać zadania w jej systemach, nie tylko prowadzić rozmowę. Dlatego przy każdym wdrożeniu na starcie sprawdzam, jakie dane są dostępne, w jakim są stanie i czy w ogóle da się z nich zbudować sensowną bazę wiedzy, zanim padnie słowo architektura.

W praktyce to sprawdzenie zajmuje czasem więcej czasu niż sama budowa agenta. Zdarza się, że firma ma dokumentację rozrzuconą po kilku dyskach, część w starych wersjach, część sprzeczną ze sobą, i zanim agent cokolwiek odpowie, ktoś musi to najpierw uporządkować. Nie da się tego pominąć, bo agent podłączony do bałaganu odpowiada bałaganem, tylko w ładniejszej formie.

Błąd drugi: pominięty prototyp i testy na sztucznych danych

Firmy chcą od razu produkcji. Pomijają prototyp, testują na wyczyszczonych przykładowych zapytaniach, a potem system wysypuje się na prawdziwych pytaniach klientów, pełnych literówek, wyjątków i spraw, których nikt nie przewidział na etapie planowania.

Ja stawiam prototyp w dwa tygodnie, na prawdziwych danych klienta, zanim cokolwiek trafia do produkcji. To pokazuje realne problemy szybciej niż miesiące planowania na sucho. Asystentka kadrowa Janina, działająca dziś w produkcji, powstała właśnie dlatego, że od początku testowaliśmy ją na prawdziwym orzecznictwie i aktach prawnych, a nie na wyimaginowanych pytaniach z briefu.

Dlaczego to tak dużo zmienia? Bo dane wymyślone na potrzeby demo są zawsze grzeczniejsze niż rzeczywistość. Prawdziwy pracownik zapyta o urlop na dwa dni przed terminem, poda złą datę, zmieni zdanie w połowie rozmowy, i agent musi sobie z tym poradzić, a nie tylko z ładnie sformułowanym pytaniem z prezentacji sprzedażowej.

Błąd trzeci: jeden model, jeden dostawca, zero kontroli kosztów

Uzależnienie od jednego modelu i jednego dostawcy to błąd, który mści się przy pierwszej awarii albo podwyżce cen. Do tego dochodzi brak twardych limitów kosztów, więc rachunek za API pod koniec miesiąca potrafi zaskoczyć, a nikt w firmie nie wie dlaczego.

W projektach GenAI w produkcie stawiam na routing między ponad 35 modelami, własne klucze API klienta i limity kosztów ustawione od pierwszego dnia, nie po fakcie. ClawLabs, który hostuje agentów AI w produkcji, działa na failoverze między 35 plus modelami LLM z tego samego powodu: jeden dostawca to jeden punkt awarii dla całej firmy.

Ten błąd kosztuje podwójnie. Raz, kiedy dostawca ma awarię, a firma nie ma planu B i cały proces stoi. Dwa, kiedy nikt nie ustawił limitu i model zaczyna przetwarzać więcej niż trzeba, a faktura przychodzi już po fakcie. Limit kosztów ustawiony pierwszego dnia to nie nadgorliwość, to zwykłe zabezpieczenie budżetu, tak samo oczywiste jak limit na karcie firmowej.

Błąd czwarty: brak testów i obserwowalności po uruchomieniu

Agent wdrożony bez logów, bez evals i bez monitoringu to czarna skrzynka. Nikt nie wie, kiedy zaczyna halucynować, kiedy odpowiada źle klientowi, ani ile faktycznie kosztuje pojedyncza rozmowa czy zgłoszenie.

Przy systemach wieloagentowych orkiestracja, subagenci, evals i observability nie są dodatkiem, tylko warunkiem, żeby w ogóle wiedzieć, co system robi w danym momencie. W Janinie każda odpowiedź ma numer artykułu, z którego pochodzi, więc błąd widać od razu, a nie dopiero po miesiącu skarg.

Bez tego firma dowiaduje się o problemie od klienta, który się poskarżył, albo wcale się nie dowiaduje. A to zawsze najdroższy sposób na złapanie błędu, bo szkoda już się stała, zanim ktokolwiek to zauważył. Dobry monitoring nie musi być skomplikowany, czasem wystarczy prosty log z każdej rozmowy i regularny przegląd, żeby złapać problem, zanim urośnie.

Błąd piąty: RODO i lokalizacja danych ustalane na końcu projektu

Zgodność z RODO doklejona na koniec, gdy dane klientów już przeszły przez zewnętrzne API bez sprawdzenia, gdzie fizycznie leżą, to błąd, który potrafi zablokować cały projekt tuż przed uruchomieniem albo wywołać poważny problem prawny miesiąc po starcie.

Dane w UE, zgodność z RODO i możliwość działania on-premise powinny być ustalone na starcie rozmowy, nie na końcu wdrożenia. Janina pseudonimizuje dane kadrowe, bo to było wymaganie od pierwszego dnia, a nie łatka dodana po audycie zewnętrznej firmy.

To pytanie trzeba zadać, zanim padnie nazwa jakiegokolwiek modelu: gdzie fizycznie będą leżeć dane i kto oprócz firmy będzie miał do nich dostęp. W dziale kadr albo w obsłudze klienta to nie jest formalność, to dane osobowe pracowników i klientów, więc jeden przeoczony szczegół może kosztować więcej niż całe wdrożenie.

Jak wygląda wdrożenie, które tych błędów unika

Dobre wdrożenie zaczyna się od rozmowy, nie od umowy na sto stron. Pierwsze 60 minut poświęcam na sprawdzenie, czy dane klienta w ogóle nadają się do pracy z agentem i czy proces da się zautomatyzować bez ryzyka dla firmy.

Potem dwa tygodnie prototypu na prawdziwych danych, uruchomienie w chmurze klienta, chmurze UE albo on-premise z logami i kontrolą kosztów od pierwszego dnia, i opieka, czyli monitoring oraz aktualizacje tak długo, jak system działa w firmie. Pominięcie któregokolwiek z tych czterech etapów to najczęściej właśnie źródło błędów opisanych wyżej.

Każdy z tych pięciu błędów da się naprawić, jeśli złapie się go wcześnie. Problem zaczyna się dopiero wtedy, gdy wychodzą na jaw po podpisaniu umowy na produkcję i po wydaniu budżetu. Dlatego wolę zaczynać od małego kroku, prototypu, który kosztuje ułamek pełnego wdrożenia, a pokazuje właściwie wszystkie te pięć punktów naraz, zanim ktokolwiek zdecyduje o dalszej skali.

Mam za sobą 15 certyfikatów Anthropic, w tym z Claude API, MCP i agent skills, oraz pięć lat prowadzenia własnej firmy produkcyjnej, więc wiem, że różnica między demo a systemem w realnej pracy to setki drobnych decyzji, nie jedna duża. Usługa agentów AI, którą prowadzę z Zamościa dla firm z całej Polski i UE, zaczyna się zawsze od sprawdzenia danych klienta, nie od wyboru modelu.