Większość projektów agentów AI nie kończy się głośną porażką. Kończy się cicho – demo, które zrobiło wrażenie na zarządzie, pilotaż, który działał przez trzy miesiące, kanał na Slacku, który w końcu ucichł. Nikt oficjalnie nie zamyka projektu. Po prostu przestaje pojawiać się w przeglądach roadmapy.
Raport State of AI 2025 firmy McKinsey ujmuje to w liczbach: 62% organizacji testuje agentów AI. Tylko 23% faktycznie wdraża ich na pełną skalę. To właśnie w luce między tymi dwoma liczbami cicho znika większość budżetów na AI.
Prognozy Gartnera są jeszcze bardziej bezpośrednie: ponad 40% projektów agentowej AI zostanie porzuconych do końca 2027 roku – nie dlatego, że technologia nie działa, ale przez rosnące koszty, niejasną wartość biznesową i niewystarczającą kontrolę ryzyka.
To nie jest problem technologiczny. To problem metody. A gdy zobaczy się go kilka razy, staje się przewidywalny.
Schemat: jak naprawdę wygląda utknięty pilotaż
Po odjęciu szczegółów, większość utkniętych projektów agentów AI ma tę samą strukturę.
Zespół – często IT, czasem product manager z entuzjazmem i linią budżetową – buduje proof of concept w oparciu o gotowe API LLM. Działa na demo. Odpowiada na pytania, które zespół pomyślał, żeby zadać. Zarząd jest pod wrażeniem. Czasem powstaje nawet komunikat prasowy.
Potem przychodzi zderzenie z rzeczywistością produkcyjną. Dane, których potrzebuje agent, leżą w sześciu różnych systemach, z czego połowa nieudokumentowana. „Prosty” proces, który miał zostać zautomatyzowany, ma w rzeczywistości czternaście przypadków brzegowych, o których nikt nie wspomniał na spotkaniu startowym. Compliance pyta, kto odpowiada, gdy agent się pomyli, a nikt nie ma jasnej odpowiedzi.
Sześć miesięcy później pilotaż wciąż jest pilotażem. Nie dlatego, że ktoś zdecydował, żeby go zatrzymać – dlatego, że nikt też nie zdecydował, żeby kontynuować.
Trzy rzeczy, które odróżniają agentów trafiających do produkcji od tych odłożonych na półkę
W rozmowach discovery, które prowadzimy z firmami oceniającymi partnerów do budowy agentów AI, te same trzy luki pojawiają się raz po raz – niemal niezależnie od branży czy wielkości firmy.
1. Brak uporządkowanej fundacji danych
To zdecydowanie najczęstszy punkt awarii – i zwykle niewidoczny, dopóki pilotaż już nie trwa.
Zespół buduje działający prototyp na czystym, starannie dobranym zbiorze danych – kilka przykładowych dokumentów, uporządkowana baza testowa. Wyniki są świetne. Potem prototyp trafia na realne środowisko: foldery SharePoint z trzema różnymi konwencjami nazewnictwa, system ERP z niespójnymi formatami pól, umowy rozproszone po wątkach mailowych i dyskach współdzielonych, bez żadnych metadanych.
Agent nie jest wadliwy. Fundacja danych pod spodem nigdy nie istniała w formie, z którą agent – czy szczerze mówiąc, nowy pracownik – mógłby wiarygodnie pracować.
Prowadziliśmy wiele rozmów discovery z firmami, które miały już za sobą „pierwszy pilotaż” wykorzystujący ogólne API LLM bezpośrednio na surowych dokumentach – bez warstwy wyszukiwania (retrieval), bez strategii indeksowania, bez mapowania uprawnień dostępu. Pilotaż wyglądał obiecująco w pierwszym tygodniu. Do czwartego tygodnia zespół po cichu przestał ufać jego odpowiedziom.
2. Pasywne czatboty zamiast zintegrowanych workflow
Druga luka jest architektoniczna, nie technologiczna. Wiele pilotaży pierwszej generacji buduje się jako okno czatu doczepione do istniejących systemów – miejsce, gdzie pracownicy mogą zadawać pytania, bez realnego połączenia z procesami, w których faktycznie zapadają decyzje.
Efekt: narzędzie, które ludzie wypróbowują raz, uznają za umiarkowanie ciekawe i zapominają o nim. Odpowiada na pytania. Nie robi nic – nie uruchamia zatwierdzenia, nie aktualizuje rekordu, nie flaguje wyjątku do przeglądu.
Agenci, którzy przetrwają do produkcji, są projektowani odwrotnie: osadzeni bezpośrednio w procesie, z jasno zdefiniowanymi danymi wejściowymi, wyjściowymi i ścieżkami eskalacji. Agent, który weryfikuje fakturę i kieruje ją do zatwierdzenia, gdy coś wygląda podejrzanie, rozwiązuje inny problem niż czatbot, który potrafi odpowiedzieć na pytania o fakturach, jeśli grzecznie się go o to poprosi.
3. Governance jako temat poboczny
Trzecia luka ujawnia się później, ale często jest fatalna, gdy już się pojawi. Pilotaż, który dobrze działał w małej skali, uderza w ścianę w momencie, gdy dział prawny, compliance albo bezpieczeństwo zadają oczywiste pytania: kto zatwierdził temu agentowi dostęp do tych danych? Co się dzieje, gdy popełni błąd? Czy istnieje ścieżka audytu? Czy to zgodne z RODO albo z unijnym AI Act?
Jeśli te pytania padają po raz pierwszy po tym, jak pilotaż pokazał obiecujące wyniki, odpowiedzi zwykle nie są gotowe – a projekt staje w miejscu, podczas gdy organizacja gorączkowo dorabia governance do architektury, która nie była do tego zaprojektowana.
Agenci budowani od razu z zatwierdzeniem human-in-the-loop, pełną identyfikowalnością (traceability) i hostingiem zgodnym z wymogami UE nie napotykają tej ściany. Zostali zaprojektowani, żeby ją przejść od samego początku.
Jak wygląda model agentowego workflow
Alternatywą dla czatbota doczepionego do istniejących systemów jest to, co nazywamy modelem agentowego workflow: agent zaprojektowany od początku wokół konkretnego procesu biznesowego, a nie dopasowany później do istniejącego stosu narzędzi.
Różnica widać w trzech konkretnych miejscach:
Agent ma zdefiniowany zakres, nie otwarty mandat. Zamiast „odpowiadaj na dowolne pytanie o naszych dokumentach”, brief brzmi „weryfikuj przychodzące faktury względem zamówień i flaguj rozbieżności powyżej ustalonego progu”. Wąski zakres oznacza, że agenta można ocenić według jasnych kryteriów sukcesu już od pierwszego tygodnia.
Agent łączy się z systemami, nie tylko z oknem czatu. Czyta z ERP, zapisuje z powrotem do niego, wyzwala powiadomienie, gdy coś wymaga przeglądu przez człowieka. Proces nie zmienia się, żeby dopasować się do agenta – to agent jest budowany tak, żeby pasować do już istniejącego procesu.
Decyzje agenta są identyfikowalne od początku. Każde działanie jest logowane. Każda eskalacja zawiera uzasadnienie, które ją wywołało. Gdy compliance pyta „co się tu wydarzyło i dlaczego”, odpowiedź już istnieje – nie trzeba jej odtwarzać po fakcie.
To też dlatego dobrze zakresowany, czterotygodniowy proof of concept zwykle przebija otwarty, sześciomiesięczny pilotaż. Wąski zakres z jasnymi wymaganiami danych i zdefiniowaną metryką sukcesu albo potwierdza słuszność przypadku użycia, albo szybko go odrzuca – zamiast dryfować w pilotażowym czyśćcu przez dwa kwartały, zanim ktoś przyzna, że projekt utknął.
Chcesz zobaczyć, jak ten proces wygląda od początku do końca? Przeczytaj nasz przewodnik po wdrażaniu automatyzacji AI w firmie, łącznie z tym, jak wybrać właściwy przypadek pilotażowy i jak wygląda realistyczny harmonogram 4–8 tygodni.
Powtarzalny wzorzec z naszych rozmów discovery
Jeden wzorzec powtarza się na tyle często, że warto go nazwać: firma średniej wielkości uruchamia pierwszy pilotaż, łącząc ogólne API LLM bezpośrednio z wewnętrznymi dokumentami – bez architektury wyszukiwania, bez warstwy kontroli dostępu, bez zdefiniowanej ścieżki eskalacji. Pilotaż pokazuje, że „AI potrafi odpowiadać na pytania o naszych politykach wewnętrznych”. Nie pokazuje, że odpowiedzi są wiarygodne, możliwe do zaudytowania albo ograniczone do tego, co dany pracownik faktycznie powinien móc zobaczyć.
Sześć miesięcy później pilotaż wciąż jest pilotażem. Firma wydała budżet i zbudowała wewnętrzny sceptycyzm wobec AI jako kategorii – nie dlatego, że pomysł u podstaw był zły, tylko dlatego, że pierwsza próba została zaprojektowana jako demo, nie jako infrastruktura produkcyjna.
Kiedy odbudowujemy takie projekty, punktem startowym rzadko jest „zbuduj mądrzejszy model”. To „zbuduj fundację danych i warstwę governance, której pierwsza wersja nigdy nie miała” – a potem zakresuj na tej podstawie wąski, mierzalny pilotaż. Technologia nigdy nie była wąskim gardłem. Fundacja była.
Jak uniknąć pilotażowego czyśćca: praktyczna checklista
Zanim zakresujesz kolejny pilotaż agenta AI, warto szczerze odpowiedzieć na cztery pytania:
Czy fundacja danych jest faktycznie gotowa? Nie „czy mamy te dane gdzieś” – tylko czy są ustrukturyzowane, dostępne przez API i zmapowane na uprawnienia dostępu, które powinny regulować, kto (albo co) może je zobaczyć?
Czy pilotaż jest zakresowany na jeden, mierzalny proces – czy na otwartą zdolność? „Zautomatyzuj weryfikację faktur dla naszych 10 głównych dostawców” to pilotaż. „Spraw, żeby nasza baza wiedzy była przeszukiwalna przez AI” to projekt badawczy przebrany za pilotaż.
Czy governance jest wbudowany od początku, czy zaplanowany na później? Jeśli compliance, dział prawny i bezpieczeństwo nie przejrzały architektury przed startem pilotażu, zrobią to po – przy dużo wyższym koszcie w czasie i zaufaniu.
Czy agent integruje się z realnym procesem, czy tylko odpowiada na pytania? Jeśli metryką sukcesu jest „ludziom wydaje się to ciekawe”, to inny projekt niż „to skraca czas obsługi o X%”. Tylko jeden z nich przetrwa przegląd budżetowy.
Jeśli nie potrafisz jasno odpowiedzieć na wszystkie cztery pytania, to nie powód, żeby porzucić projekt – to właściwy punkt startowy. Dobrze zakresowany, czterotygodniowy PoC jest zaprojektowany dokładnie po to, żeby odpowiedzieć na te pytania, zanim zaangażuje się dalszy budżet.
→ Zobacz, jak ITSharkz projektuje i buduje agentów AI gotowych do produkcji – od fundacji danych po wdrożenie.
Podsumowanie
Luka między 62% testującymi a 23% wdrażającymi na skalę to nie luka technologiczna. To luka fundamentu – w danych, w architekturze i w governance.
Trzy rzeczy do zapamiętania:
- Większość pilotaży nie zawodzi dlatego, że model jest słaby. Utykają, bo fundacja danych pod spodem nigdy nie została zbudowana z myślą o produkcyjnym użyciu.
- Czatbot, który odpowiada na pytania, to inny produkt niż agent osadzony w procesie. Tylko ten drugi przetrwa kontakt z przeglądem budżetowym.
- Governance wbudowany od pierwszego dnia jest szybszy, nie wolniejszy. Dorabianie compliance do architektury, która nie była pod to zaprojektowana – to realnie zabija harmonogramy.
Jeśli zastanawiasz się, od czego zacząć, nasz przewodnik po wdrażaniu automatyzacji AI pokazuje krok po kroku, jak wybrać właściwy przypadek pilotażowy i jak wygląda realistyczny harmonogram produkcyjny.
Porozmawiaj z ITSharkz o zakresowaniu pilotażu zaprojektowanego tak, żeby trafić do produkcji – nie tylko zrobić wrażenie na demo. → Umów spotkanie z Kacprem