Liderzy opinii

Dlaczego projekty agentowej AI są anulowane i co dobrze robi ośmiotygodniowy pilotaż

mm
Dodaj Unite.AI do preferowanych źródeł w Google
Kluczowe punktyMost agentic AI risk sits in the business processes the agent inherits rather than in…
Zobacz więcej
  • Most agentic AI risk sits in the business processes the agent inherits rather than in the model itself.
  • Value hinges on cost per completed task once human oversight is counted not on raw agent speed.
  • An eight-week pilot should end in a scale fix or stop decision grounded in baseline evidence.

Klient prosi o zwrot pieniędzy, a agent znajduje zamówienie w systemie CRM, sprawdza zasady zwrotów i przygotowuje odpowiedź w mniej niż minutę. Potem jednak staje w miejscu, bo zatwierdzenie zwrotu odbywa się w systemie finansowym, z którym nie został połączony, a adres klienta jest inny w dwóch bazach danych. Takie luki rzadko wychodzą na jaw podczas demonstracji, a jednak decydują o tym, ile kosztuje działanie agenta i czy można mu zaufać. Oznacza to, że większe ryzyko związane z agentową AI w firmie tkwi w środowisku biznesowym, do którego agent zostaje wdrożony, a nie w samym modelu.

Gartner przewiduje, że do końca 2027 roku zostanie anulowanych ponad 40% projektów z zakresu agentowej AI, wskazując na rosnące koszty, niejasną wartość biznesową i niewystarczające mechanizmy kontroli ryzyka. Przy bliższym spojrzeniu widać, że prognoza ta dotyczy sposobu zatwierdzania tych projektów na podstawie udanej demonstracji, bez większego rozeznania w tym, ile obecnie kosztuje dana praca ani kto odpowiada za jej wynik.

Każdemu zespołowi kierowniczemu zadałbym pytanie, czy firma jest w stanie na co dzień wspierać agenta wykonującego tę pracę, ponosząc koszty i ryzyko, które może zaakceptować. Aby na nie odpowiedzieć, trzeba dokładnie przyjrzeć się temu, co nazywam pracą po automatyzacji, czyli wszystkim czynnościom, które ludzie nadal muszą wykonać, gdy agent zakończy swoją część zadania. Ośmiotygodniowy pilotaż to praktyczny sposób, by to zmierzyć przed podjęciem decyzji o pełnym wdrożeniu.

Problemy odziedziczone przez agenta po firmie

Agent rzadko działa samodzielnie, ponieważ nawet pozornie proste zadanie obejmuje dane klientów, kilka aplikacji biznesowych i zwykle etap zatwierdzania, a każde połączenie ogranicza to, co agent może zobaczyć i zrobić. Jeśli dane są niespójne albo nie wiadomo dokładnie, kto ma zatwierdzić wynik, agent przejmuje to zamieszanie razem z zadaniem.

Rutynowe przypadki rzadko stanowią problem — są nim wyjątki, bo to właśnie wtedy kumulują się koszty operacyjne, a demonstracje z założenia je pomijają. Badanie Deloitte z 2026 roku wykazało, że tylko 5% organizacji uważa swoje procesy biznesowe za bardzo dobrze przygotowane do obsługi agentów AI. Ta liczba mówi więcej niż jakikolwiek wynik testu porównawczego modelu, ponieważ sugeruje, że AI osiąga gotowość na długo przed większością procesów.

Analiza biznesowa musi uwzględniać pracę po automatyzacji

Pomiar szybkości, z jaką agent generuje wynik, to najprostszy sposób, by zawyżyć jego wartość, bo najważniejsze jest to, ile pracy wymaga ukończenie zadania. Załóżmy, że pracownik potrzebuje 20 minut na realizację prośby, a agent skraca czas przygotowania pierwszej wersji do dwóch minut. Wygląda to na oszczędność 18 minut — aż do chwili, gdy ktoś poświęca 15 minut na sprawdzenie wyniku i poprawienie błędów. Oszczędność trzech minut przynosi niewielką korzyść, gdy po drugiej stronie rachunku uwzględni się koszt działania agenta.

Analiza McKinsey dotycząca agenta obsługi klienta w bankowości pokazuje ten sam schemat na dużą skalę: tokeny stanowiły 20–25% zmiennych kosztów operacyjnych, a nadzór człowieka — 70–75%, więc większość wydatków przypadała na elementy spoza modelu. Jeśli przed napisaniem kodu nie ustali się punktu odniesienia, pilotaż może wykazać znaczne postępy techniczne, a mimo to nie zweryfikować zasadności inwestycji. Osoba odpowiedzialna za biznes powinna znać co najmniej jasne odpowiedzi na każde z poniższych pytań:

  • Wolumen: jak często realizowany jest proces i ile osób bierze w nim udział.
  • Czas realizacji: ile trwa wykonanie całego zadania, łącznie ze sprawdzaniem i poprawkami.
  • Dokładność: jak często pojawiają się błędy lub konieczne jest ponowne wykonanie zadania.
  • Koszt zadania: ile obecnie kosztuje pomyślne wykonanie jednego zadania.
  • Wpływ na biznes: co rzeczywista poprawa zmieniłaby dla klientów, pracowników lub firmy.

Agent musi uzasadnić swoje miejsce w przepływie pracy

Wdrożenie zwykle zalicza się do zarządzania zmianą, ale z mojego doświadczenia wynika, że o jego powodzeniu rozstrzyga się znacznie wcześniej — decyduje o nim miejsce agenta w przepływie pracy. Globalna firma świadcząca usługi profesjonalne stworzyła agentów do obsługi klienta i zadań związanych ze zgodnością z przepisami. Agent obsługi klienta potrafił pobierać informacje z kilku systemów wewnętrznych, ale aby z niego skorzystać, pracownicy musieli otworzyć osobną aplikację, więc na ogół z niego nie korzystali. Gdy ten sam przepływ pracy przeniesiono do używanej już platformy obsługi klienta, agent pojawił się w zgłoszeniu, nad którym pracownicy już pracowali. Podobnie postąpiono z agentem do weryfikacji zgodności: wbudowano go w Salesforce, tak aby uruchamiał się przy każdym utworzeniu sprawy.

Same agenty się nie zmieniły — zmieniło się ich miejsce w przepływie pracy. Pracownicy i tak mieli powód, by otworzyć zgłoszenie lub utworzyć sprawę, więc udostępnienie im agenta w tym momencie nie wymagało od nich żadnego dodatkowego wysiłku. Umiejscowienie agenta jest zatem zarówno decyzją architektoniczną, jak i kwestią jego wdrożenia: agent potrzebuje kontekstu dostępnego tam, gdzie odbywa się praca, a jego wynik musi trafiać do kolejnego etapu bez ręcznego kopiowania.

Autonomia zmienia zasady bezpieczeństwa

Agent, który może jedynie odczytywać informacje, wiąże się z jednym rodzajem ryzyka, a agent mogący zmieniać dane lub wysyłać e-maile do klientów — z zupełnie innym. Mechanizmy kontroli muszą więc odpowiadać temu, do czego agent faktycznie jest uprawniony. Nadmierne uprawnienia i wycieki danych wrażliwych to dobrze znane zagrożenia, ale szczególną uwagę należy poświęcić wstrzykiwaniu poleceń: instrukcjom ukrytym w dokumencie lub e-mailu, na które agent natrafia podczas wykonywania zupełnie legalnego zadania.

Wskazówki Gartnera z maja 2026 r. dotyczące zarządzania agentami wyróżniają cztery poziomy autonomii, co ułatwia określenie, jak restrykcyjne powinny być zabezpieczenia:

  1. Obserwacja: agent pobiera informacje i wykrywa wzorce, mając dostęp wyłącznie do odczytu.
  2. Doradzanie: agent rekomenduje działanie, a decyzję podejmuje pracownik.
  3. Działanie za zgodą: agent przygotowuje działanie lub je rozpoczyna, ale przed jego wykonaniem musi je zatwierdzić człowiek.
  4. Działanie autonomiczne: agent samodzielnie wykonuje zatwierdzone działania w określonych granicach, a wyjątki są monitorowane i eskalowane.

Na każdym poziomie agent potrzebuje własnej tożsamości, uprawnień ograniczonych do powierzonych mu zadań oraz rejestru wszystkich podejmowanych działań. Organizacje muszą też określić zasady przetwarzania i przechowywania danych, jasno wskazać, jakie informacje trafiają do zewnętrznych dostawców modeli, oraz wyznaczyć osobę uprawnioną do wstrzymania działania agenta i odebrania mu dostępu, gdy tylko coś wzbudzi niepokój.

Każde z tych zabezpieczeń wiąże się z bieżącymi kosztami, ponieważ szersze uprawnienia, dodatkowy monitoring i częste zatwierdzanie działań z czasem zwiększają wydatki. Właściwy poziom autonomii jest więc decyzją ekonomiczną, a nie tylko kwestią bezpieczeństwa. Zależy od tego, czy agent przynosi wartościowe rezultaty przy poziomie ryzyka akceptowalnym dla firmy.

Wybierz proces, który uzasadnia wdrożenie agenta

Wiele zespołów zaczyna od technologii, a dopiero potem szuka dla niej problemu do rozwiązania. Lepszym punktem wyjścia jest proces, którego koszty lub opóźnienia są już dobrze znane osobom wykonującym tę pracę.

Współpracująca z nami globalna firma z branży sieci ekspertów dobrze ilustruje tę sytuację: jej zespół dopasowywał prośby o udział w ankietach do ekspertów, korzystając z trzech niepołączonych ze sobą systemów. Przy każdym dopasowaniu ręcznie sprawdzał profile, wcześniejszy udział i zgodność z wymogami. Zbudowaliśmy agenta, który łączył wyszukiwanie semantyczne z historią udziału ekspertów i zasadami zgodności. Po wdrożeniu liczba zgłoszeń dotyczących niedopasowań spadła o 80%, trafność dopasowań wzrosła o 40%, a zespół odzyskał 22% swoich zasobów.

Projekt się powiódł, ponieważ problem był jasno określony: informacje były rozproszone, ich łączenie odbywało się ręcznie, a jakość dopasowań można było zmierzyć przed wdrożeniem i po nim. Precyzyjne określenie problemu pomaga też ustalić, czy dany proces w ogóle wymaga agenta. Procesy oparte na sztywnych regułach zazwyczaj taniej obsłużyć za pomocą tradycyjnej automatyzacji, a do zadań polegających głównie na wyszukiwaniu i streszczaniu informacji często wystarczy asystent AI. Dodatkowy koszt i ryzyko związane z agentami są uzasadnione, gdy zadanie wymaga odczytywania kontekstu, wyboru spośród dozwolonych działań i łączenia kilku kroków w celu osiągnięcia określonego rezultatu.

Ośmiotygodniowy pilotaż z jasno określonymi punktami decyzyjnymi

Cały pilotaż zależy od jednej kwestii biznesowej: czy ten agent usprawni proces na tyle, by uzasadnić jego wdrożenie na dużą skalę? Osiem tygodni wystarczy, by sprawdzić zasadność biznesową i technologię, a także to, czy organizacja potrafi zarządzać tym, co stworzy.

Tygodnie 1–2: określ, co wymaga poprawy

Zacznij od udokumentowania obecnego przebiegu procesu: jego skali, czasu realizacji, odsetka błędów, konieczności ponownego wykonywania pracy i kosztów. Zapisz, jakie systemy są wykorzystywane, kto odpowiada za poszczególne etapy i które wyjątki wymagają interwencji człowieka. Następnie uzgodnij z właścicielem biznesowym procesu i zespołem technicznym jeden rezultat, który agent ma poprawić. Punkt decyzyjny: kontynuuj, gdy problem, stan wyjściowy, osoba odpowiedzialna i miary sukcesu są jasno określone.

Tydzień 3: określ granice działania agenta

Na tym etapie określa się ograniczenia agenta: jego tożsamość, uprawnienia, dostęp do danych, zatwierdzone narzędzia i stopień autonomii. Przetestuj go pod kątem ataków polegających na wstrzykiwaniu poleceń, nieuprawnionego dostępu, ujawnienia wrażliwych danych i niewłaściwego użycia narzędzi. Wprowadź rejestrowanie zdarzeń i procedury reagowania na incydenty, a także możliwość zawieszenia działania agenta lub odebrania mu dostępu. Punkt decyzyjny: kontynuuj, gdy zabezpieczenia i procedury interwencji zostały faktycznie przetestowane, a wszyscy wiedzą, co agent może robić.

Tygodnie 4–6: przetestuj sytuacje, które mogą obnażyć słabości wersji demonstracyjnej

Teraz powierz agentowi realistyczne zadania, w tym pracę z niekompletnymi rekordami, sprzecznymi informacjami, nietypowymi prośbami i sporadycznymi awariami systemu. Śledź, ile zadań wykonuje, jak dokładny jest i ile pracy korygującej muszą wykonać ludzie. Następnie oblicz rzeczywisty koszt pomyślnego wykonania zadania, uwzględniając korzystanie z modeli, integracje, monitoring i weryfikację. Punkt decyzyjny: przejdź do testów na żywo, gdy agent osiągnie uzgodnione progi, a zespół pozna zarówno koszty jego działania, jak i sposoby, w jakie zawodzi.

Tygodnie 7–8: udostępnij agenta rzeczywistym użytkownikom

Udostępnij agenta niewielkiej grupie pracowników i powierz mu kontrolowaną część rzeczywistej pracy, pozostawiając dotychczasowy proces do obsługi zadań, z którymi agent sobie nie radzi. Obserwuj, czy ludzie faktycznie z niego korzystają, czy ułatwia im pracę i czy ufają uzyskiwanym wynikom.

Na koniec zestaw wyniki ze stanem wyjściowym z pierwszego tygodnia i oceń produktywność, dokładność, poziom wykorzystania, częstotliwość interwencji ludzi, całkowity koszt operacyjny i wszelkie nierozwiązane zagrożenia dla bezpieczeństwa. Następnie zdecyduj, czy wdrożyć agenta na większą skalę, usunąć konkretne braki i przeprowadzić ponowne testy, czy zakończyć projekt. Pilotaż, który wykazuje, że agent jest zbyt drogi lub zawodny do danego zadania, również spełnił swoją rolę: zapobiegł znacznie większej inwestycji opartej na domysłach.

Zmierz wyniki, a następnie zdecyduj, jak dużą autonomię przyznać

Sama liczba zadań obsłużonych przez agenta niewiele mówi, ponieważ system może przetworzyć tysiące zgłoszeń, a mimo to pozostawić pracownikom weryfikację, poprawianie lub kończenie większości z nich. Koszt pomyślnie zrealizowanego zadania, analizowany łącznie z dokładnością i odsetkiem wyjątków, znacznie lepiej pokazuje, czy cały proces się usprawnił.

Te same wskaźniki uzasadniają przyznanie agentowi większej swobody działania. Agentowi, który niezawodnie obsługuje rutynowe zgłoszenia w uzgodnionych granicach, można powierzyć samodzielne podejmowanie takich działań. Jeśli natomiast wciąż trafia na niejednoznaczne przypadki, człowiek nadal zatwierdza te decyzje, a zakres uprawnień jest weryfikowany w miarę gromadzenia dowodów.

Rozwijaj rozwiązanie na większą skalę, gdy firma jest w stanie wspierać agenta

Agent, który dobrze sprawdza się w jednym zespole, prędzej czy później będzie musiał współpracować z innymi działami, aplikacjami i ścieżkami zatwierdzania. Skalowanie wymaga jasnego określenia odpowiedzialności, spójnych mechanizmów kontroli dostępu i sposobu obsługi wyjątków, a także budżetu na aktualizowanie agenta w miarę zmian zachodzących w otaczających go procesach.

U podstaw wszystkich tych decyzji leży pytanie, jak dużą odpowiedzialność organizacja jest gotowa przekazać agentowi. Odpowiedź musi opierać się na dowodach z rzeczywistej pracy, a nie na udanej demonstracji. Po ośmiu tygodniach kierownictwo powinno wiedzieć, z czym agent sobie radzi, w jakich sytuacjach nadal muszą interweniować ludzie i ile będzie kosztować jego działanie. Przewagę w dziedzinie agentowej sztucznej inteligencji zyskają przedsiębiorstwa, które od pierwszego tygodnia planują pracę po automatyzacji i finansują agentów za zadania, które faktycznie wykonują.

Bhupendra Chopra jest dyrektorem ds. przychodów i współzałożycielem Kanerika, firmy oferującej rozwiązania z zakresu danych i sztucznej inteligencji. Współpracuje z przedsiębiorstwami przy modernizacji platform danych, wdrażaniu sztucznej inteligencji oraz przechodzeniu z projektami AI od etapu pilotażowego do produkcyjnego. Jego doświadczenie obejmuje Microsoft Fabric, Databricks, migracje Power BI, zarządzanie danymi i agentową sztuczną inteligencję.

Zanim założył Kanerika, Bhupendra pełnił różne funkcje w Informatica, Oracle i TCS. Ukończył Stanford Leadership Learning Program oraz program dla kadry kierowniczej w IIM Indore. Mieszka w Austin w stanie Teksas.