Agent AI czy chatbot: 7 pytań przed podpisaniem umowy (i jak to sprawdzić zanim zapłacisz)

Zacznę od tezy, która w tej branży bywa niewygodna: większość ofert, które trafiają do mnie z dopiskiem „agent AI do obsługi klienta” albo „agent AI do faktur”, po rozłożeniu na czynniki pierwsze okazuje się zestawem reguł warunkowych połączonych z jednym wywołaniem modelu językowego gdzieś na końcu, żeby ładnie sformułować odpowiedź. To nie jest oszustwo w sensie prawnym, bo definicja „agenta” nie jest prawnie uregulowana i każdy może ją naciągnąć pod swoje potrzeby sprzedażowe. Ale to jest problem dla ciebie, jeśli płacisz stawkę za autonomiczny system decyzyjny, a dostajesz scenariusz, który sypie się przy pierwszym nietypowym przypadku.

Nie piszę tego, żeby zniechęcić do automatyzacji opartej na AI. Piszę to, bo widziałem wdrożenia po obu stronach: takie, gdzie prosty skrypt if-then wystarczył w zupełności i agent byłby przerostem formy nad treścią, oraz takie, gdzie klient zapłacił za „agenta”, dostał sztywny lejek decyzyjny i po trzech miesiącach wrócił, bo system nie radził sobie z niczym, czego nie przewidziano w scenariuszu podczas wdrożenia.

Dlaczego w ogóle trzeba o to pytać

Problem bierze się z tego, że „agent AI” brzmi lepiej w ofercie niż „automatyzacja procesu”. Sprzedaje się efektowniej, bo kojarzy się z czymś, co samo myśli, samo się uczy i samo podejmuje decyzje. Tymczasem w praktyce wdrożeniowej agentem nazywa się dziś niemal wszystko, co ma w środku jakiekolwiek wywołanie API modelu językowego, nawet jeśli cała reszta logiki to zwykłe węzły warunkowe w narzędziu typu n8n czy Make. To nie jest złe samo w sobie, bo taki system może działać świetnie i tanio. Problem pojawia się wtedy, kiedy firma płaci cenę adekwatną do pełnego agenta z pamięcią kontekstu i zdolnością do podejmowania decyzji w nieprzewidzianych sytuacjach, a otrzymuje scenariusz, który ma pięć ścieżek i przy szóstej po prostu się zawiesza albo zwraca generyczną odpowiedź.

Druga sprawa to umowa. Zapisy dotyczące dostępu do logów decyzji, kosztu zmian w scenariuszu i możliwości przeniesienia rozwiązania do własnej infrastruktury rzadko są omawiane na etapie oferty, a to one decydują, ile faktycznie zapłacisz w ciągu roku i czy w ogóle będziesz mógł odejść od dostawcy bez budowania wszystkiego od zera.

7 pytań, które warto zadać przed podpisaniem umowy

Poniższa lista nie jest poradnikiem „jak wybrać dobrą firmę wdrożeniową”. Celowo pomijam kwestie takie jak referencje czy portfolio, bo o tym przeczytasz wszędzie. Skupiam się wyłącznie na pytaniach, które demaskują naciąganie definicji agenta, bo to jest konkretny i powtarzalny problem, z którym spotykam się przy rozmowach o automatyzacji opartej na AI.

1. Czy system podejmuje decyzje warunkowe na podstawie kontekstu, czy wykonuje stały scenariusz?

To pytanie wprost. Dobry dostawca odpowie konkretnie i poda przykład: „w tym kroku model ocenia treść wiadomości klienta i na tej podstawie decyduje, czy eskalować do konsultanta, czy odpowiedzieć automatycznie”. Zły dostawca zacznie mówić ogólnikami o „inteligentnej automatyzacji” i unikać słowa „scenariusz”, chociaż właśnie to sprzedaje.

2. Co się dzieje, gdy trafi się przypadek, którego nikt nie przewidział?

To jest test praktyczny. Poproś o pokazanie, jak system zachowuje się przy zapytaniu spoza typowych ścieżek. Jeśli odpowiedź brzmi „wtedy system przekazuje sprawę do człowieka z pełnym kontekstem rozmowy”, to dobry znak. Jeśli odpowiedź brzmi „takie przypadki zdarzają się rzadko” albo pada cisza, to znaczy, że nikt tego nie testował, albo system po prostu się gubi.

3. Czy mam dostęp do logów decyzji systemu?

Chodzi o możliwość zobaczenia, dlaczego agent wybrał konkretną ścieżkę w konkretnej sytuacji, nie tylko efektu końcowego w postaci wysłanej wiadomości czy zaksięgowanej faktury. Brak takiego dostępu w umowie to częsty standardowy zapis, który trzeba wychwycić i renegocjować, bo bez logów nie da się rozliczyć systemu z błędów ani poprawić logiki tam, gdzie faktycznie szwankuje.

4. Ile kosztuje zmiana jednego kroku w scenariuszu po wdrożeniu?

Przy prawdziwym agencie dopisanie reguły albo zmiana warunku to zwykle kilka godzin pracy. Przy sztywnym skrypcie, w którym logika jest mocno poskładana i zależna od kolejności kroków, pojedyncza zmiana potrafi wymagać przebudowy większego fragmentu całości, co w cenniku godzinowym robi różnicę rzędu kilku tysięcy złotych. Zapytaj wprost o cennik zmian po wdrożeniu, nie tylko o cenę samego wdrożenia.

5. Czy mogę przenieść scenariusz do własnej infrastruktury?

To pytanie o eksportowalność i vendor lock-in. Jeśli cała logika żyje wyłącznie na koncie dostawcy, w jego własnym narzędziu, bez możliwości eksportu, to w praktyce jesteś przywiązany do niego na stałe, niezależnie od jakości współpracy. Dobra umowa przewiduje, że po zakończeniu kontraktu scenariusz, konfiguracje i dane trafiają do ciebie, a nie zostają zablokowane u dostawcy.

6. Jaki model stoi pod spodem i kto ma dostęp do danych, które przez niego przechodzą?

To pytanie techniczne, ale ma konsekwencje prawne i biznesowe. Jeśli przez system przechodzą dane klientów albo dokumenty finansowe, musisz wiedzieć, czy trafiają do zewnętrznego API, gdzie są przetwarzane i na jak długo. Dostawca, który nie potrafi tego jasno wyjaśnić, prawdopodobnie sam nie do końca wie, co dzieje się „pod maską” jego rozwiązania.

7. Jak wygląda eskalacja do człowieka i kto ją konfiguruje?

Żaden rozsądnie zaprojektowany system nie próbuje obsłużyć stu procent przypadków automatycznie. Pytanie brzmi, czy próg eskalacji jest konfigurowalny przez ciebie, czy zaszyty na sztywno przez dostawcę. W dobrych wdrożeniach automat realizuje zdecydowaną większość przypadków, a decyzję przy wyjątku, reklamacji czy nietypowym zapytaniu zostawia się człowiekowi, z pełnym kontekstem przekazanym dalej.

Standardowe zapisy umowne, które trzeba sprawdzić

Poza samymi pytaniami warto przejrzeć treść umowy pod kątem trzech obszarów, które w praktyce najczęściej są pomijane albo sformułowane na korzyść dostawcy. Pierwszy to właśnie dostęp do logów decyzji, o czym pisałem wyżej: bez niego trudno rozliczyć system z jakości działania. Drugi to koszt zmian w scenariuszu po wdrożeniu, często ukryty w osobnym cenniku godzinowym, który nie jest pokazywany na etapie podpisywania umowy głównej. Trzeci to eksportowalność i zapisy dotyczące własności konfiguracji po zakończeniu współpracy. W wielu standardowych umowach na rynku polskim ten punkt w ogóle nie jest poruszany, co w praktyce oznacza, że w razie sporu albo chęci zmiany dostawcy zaczynasz budowę systemu od nowa.

Przy automatyzacji procesów finansowych te zapisy mają dodatkowe znaczenie, bo dochodzi kwestia odpowiedzialności za błędne decyzje systemu przy księgowaniu czy weryfikacji dokumentów. Jeśli temat dotyczy obiegu dokumentów, warto przejrzeć, jak wygląda to w kontekście automatyzacji faktur, gdzie granica między prostym OCR-em a systemem rzeczywiście podejmującym decyzje (np. o akceptacji faktury niezgodnej z zamówieniem) jest szczególnie często zacierana w materiałach marketingowych.

Realne widełki cenowe i jak je czytać

Na rynku polskim proste wdrożenie automatyzacji procesowej, bez elementów decyzyjnych opartych na modelu językowym, to zwykle koszt rzędu kilku tysięcy złotych za scenariusz, w zależności od liczby integracji. Rozwiązanie, które rzeczywiście zasługuje na nazwę agenta, czyli z pamięcią kontekstu, logiką decyzyjną i obsługą wyjątków, kosztuje więcej, bo wymaga więcej pracy przy projektowaniu logiki i testowaniu przypadków brzegowych. Jeśli oferta na „agenta AI” jest w cenie prostego scenariusza automatyzacji, to niemal zawsze oznacza, że pod etykietą agenta kryje się właśnie prosty scenariusz. Rozbieżność między ceną a deklarowanym zakresem funkcji to jeden z najprostszych sygnałów ostrzegawczych, zanim jeszcze zajrzysz do umowy.

Warto też zapytać, jak wygląda faza testów przed przekazaniem systemu do pracy produkcyjnej. Rzetelne wdrożenie agenta zakłada etap, w którym scenariusze są sprawdzane na realnych, trudnych przypadkach, nie tylko na „ścieżce szczęśliwej”, w której wszystko idzie zgodnie z planem. Jeśli dostawca pomija ten etap albo traktuje go jako formalność, to zwykle dlatego, że pod spodem nie ma nic, co wymagałoby głębszego testowania.

Kiedy sztywny skrypt wcale nie jest złym wyborem

Tu wchodzę w kontrę do samego siebie, bo uczciwość wymaga tego zastrzeżenia: nie każdy proces potrzebuje agenta. Jeśli firma handlowa codziennie przepisuje te same dane z zamówień do systemu księgowego według jednego, powtarzalnego schematu, to zwykły skrypt automatyzujący to przepisywanie jest tańszy, szybszy w budowie i bardziej przewidywalny niż agent oparty na modelu językowym. Problem nie leży w samym skrypcie, tylko w nazywaniu go agentem i w sprzedawaniu po cenie adekwatnej do systemu decyzyjnego.

Podobnie w obsłudze klienta: jeśli 80% zgłoszeń to proste pytania o status zamówienia czy godziny pracy, prosty bot z kilkoma ścieżkami wystarczy w zupełności, a decyzję przy bardziej złożonym zapytaniu i tak trzeba będzie zostawić człowiekowi. W takich przypadkach bardziej opłaca się zainwestować w dobrze zaprojektowany proces eskalacji niż w kosztowną warstwę decyzyjną, która i tak w większości przypadków będzie działać identycznie jak zwykły skrypt. Więcej o tym, gdzie faktycznie opłaca się automatyzacja w kontakcie z klientem, a gdzie wystarczy prostszy mechanizm, piszemy przy okazji automatyzacji obsługi klienta.

Co zrobić z odpowiedziami dostawcy

Po przejściu przez te siedem pytań zwykle wychodzi jeden z trzech obrazów. Pierwszy: dostawca odpowiada konkretnie, pokazuje logi, podaje realny koszt zmian i nie ma problemu z zapisem o eksportowalności w umowie. To dobry sygnał, niezależnie od tego, czy system finalnie nazwiemy agentem, czy zaawansowaną automatyzacją. Drugi obraz: dostawca uczciwie przyznaje, że proponuje scenariusz oparty na regułach z punktowym użyciem AI, bo to wystarczy do danego zadania i jest tańsze. To też jest w porządku, pod warunkiem że cena i oczekiwania są dopasowane. Trzeci obraz, najgorszy: dostawca sprzedaje scenariusz jako pełnoprawnego agenta, unika konkretnych odpowiedzi i nie chce negocjować zapisów o logach ani eksportowalności. W tym trzecim przypadku zalecam po prostu odejście od stołu, niezależnie od tego, jak atrakcyjnie brzmi prezentacja.