Wdrożenie agenta AI w tydzień? Harmonogram 2026 (od pierwszej rozmowy do produkcji, krok po kroku)

Najczęstsze pytanie, jakie słyszymy na pierwszej rozmowie, brzmi: "ile to potrwa?". I odpowiedź, której nikt nie chce usłyszeć, jest taka, że zbudowanie samego agenta czy automatyzacji to zwykle najkrótszy etap całego projektu. W większości wdrożeń, które robiliśmy, kod czy flow w n8n powstawał w 1-2 dni robocze. Projekt jako taki trwał jednak dwa, trzy tygodnie, a czasem dłużej. Różnica bierze się z tego, co dzieje się między spotkaniami: czekania na hasło do API, na odpowiedź działu IT, na decyzję, kto ma zatwierdzać wyjątki.

Ten artykuł to w zasadzie checklistowy harmonogram, który pokazujemy klientom, żeby mogli sami ocenić, czy termin podany przez dostawcę (nas albo kogokolwiek innego) jest realny, czy marketingowy. Rozbijamy go na dwa scenariusze, bo "wdrożenie agenta AI" dla prostego, jednosystemowego procesu i dla złożonego procesu z kilkoma integracjami to w praktyce dwa różne projekty, mimo że sprzedawane są pod tą samą nazwą.

Gdzie naprawdę znika czas przy wdrożeniu agenta AI

Zanim przejdziemy do harmonogramu, jedno zastrzeżenie: nie chodzi o to, że budowa jest łatwa, a reszta trudna. Chodzi o to, że budowa jest w pełni pod kontrolą zespołu wdrożeniowego, a reszta nie. Jeśli programista siądzie do flow w n8n, to zrobi go w dzień, może dwa. Ale ten sam flow stoi bezużyteczny, dopóki klient nie poda dostępu do skrzynki pocztowej, konta w systemie ERP albo klucza API do fakturowni czy CRM-u.

Z naszego doświadczenia największe opóźnienia biorą się z trzech rzeczy. Po pierwsze, dostępy do systemów: firma IT klienta ma inne priorytety, zgłoszenie o nowe konto serwisowe czeka w kolejce tydzień albo dwa. Po drugie, decyzje wewnętrzne, czyli kto ostatecznie akceptuje, że agent ma np. samodzielnie wysyłać odpowiedzi do klientów, a kto musi je widzieć przed wysyłką. Po trzecie, dane testowe: firma deklaruje, że "proces jest prosty", a po dwóch dniach testów okazuje się, że 15% faktur ma inny format niż reszta i trzeba dopisać obsługę wyjątków.

Harmonogram dla prostego scenariusza: tydzień do dwóch

Prosty scenariusz to taki, gdzie automatyzacja dotyczy jednego, dobrze opisanego procesu, w jednym lub dwóch systemach, z jasnymi regułami decyzyjnymi. Przykład: firma handlowa, która codziennie ręcznie przepisuje dane z faktur przychodzących z kilku stałych dostawców do systemu księgowego. Format faktur jest w miarę powtarzalny, reguły są proste, liczba wyjątków niewielka.

Dzień 1-2: audyt procesu

Pierwsza rozmowa trwa zwykle godzinę, czasem dwie. Ustalamy, co dokładnie dzieje się dziś krok po kroku, jakie systemy są w grze, kto jest właścicielem procesu po stronie klienta i jakie są wyjątki od reguły (np. faktury w walucie obcej, faktury korygujące). Jeśli proces jest prosty, spisanie go i potwierdzenie z klientem zajmuje dzień, może dwa, licząc czas na odpowiedź mailową.

Dzień 2-5: dostęp do danych i API

To etap, na którym najwięcej zależy od klienta, nie od wykonawcy. Potrzebne jest konto serwisowe do skrzynki, dostęp API do systemu księgowego albo przynajmniej eksport przykładowych danych. W najlepszym przypadku, gdy po stronie klienta jest jedna osoba decyzyjna z dostępem administracyjnym, to kwestia jednego dnia. W praktyce, gdy trzeba przejść przez dział IT albo zewnętrznego dostawcę systemu, realistycznie liczymy 2-3 dni robocze, czasem tydzień.

Dzień 4-6: budowa w n8n lub Make

Tu dzieje się właściwa praca techniczna, i to jest część, która rzeczywiście trwa krótko. Prosty scenariusz obsługi faktur czy formularzy to u nas standardowo 1-2 dni pracy jednej osoby, włącznie z podstawową obsługą błędów. Ten etap często nakłada się czasowo z poprzednim: budujemy strukturę flow na danych testowych, zanim jeszcze mamy pełny dostęp produkcyjny.

Dzień 6-9: testy na prawdziwych danych

To etap, który najczęściej jest niedoszacowany w ofertach "wdrożenie w 3 dni". Testowanie na rzeczywistych, często "brudnych" danych klienta to moment, w którym wychodzą wyjątki niewidoczne na etapie rozmowy: inny format daty, faktura bez numeru NIP, duplikat w skrzynce. Przy prostym procesie liczymy na to 2-3 dni, z poprawkami wprowadzanymi na bieżąco.

Dzień 9-10: szkolenie zespołu

Krótkie, 1-2 godzinne spotkanie, na którym pokazujemy, jak wygląda panel, gdzie sprawdzić logi, co zrobić, gdy automatyzacja się zatrzyma. Dla prostego procesu to naprawdę nie więcej niż jedno spotkanie plus krótka instrukcja pisemna.

Dzień 10-14: wdrożenie progowe z nadzorem człowieka

Nawet przy prostym procesie nie włączamy pełnej autonomii agenta od razu. Przez 3-5 dni roboczych automatyzacja działa, ale wynik trafia do zatwierdzenia przez człowieka, zanim pójdzie dalej (np. do systemu księgowego). Dopiero po tym okresie, gdy nie ma błędów krytycznych, przechodzimy na pełną automatyzację. To etap, który świadomie wydłuża projekt, ale chroni klienta przed sytuacją, w której błąd w logice trafia od razu do księgowości czy do klienta końcowego.

Łącznie: realistyczny prosty projekt to 2-3 tygodnie kalendarzowe od pierwszej rozmowy do pełnej automatyzacji, mimo że sama budowa zajęła 1-2 dni. Dobrym przykładem takiego procesu jest automatyzacja faktur, gdzie reguły są powtarzalne, ale liczba formatów dokumentów i tak wymaga realnych testów na danych klienta, nie na przykładowych plikach z internetu.

Harmonogram dla złożonego scenariusza: miesiąc do czterech

Złożony scenariusz to proces obejmujący kilka systemów (np. CRM, ERP, poczta, system obsługi zgłoszeń), z wyjątkami wymagającymi decyzji biznesowej, często z danymi wrażliwymi (dane osobowe klientów, dane finansowe), gdzie błąd automatyzacji ma realny koszt. Przykład: agent AI obsługujący pierwszy kontakt z klientem w dziale wsparcia, który ma odczytać zgłoszenie, sklasyfikować je, sprawdzić historię klienta w CRM i albo odpowiedzieć samodzielnie, albo przekazać sprawę do konsultanta.

Tydzień 1-2: audyt procesu

Przy złożonym procesie jedno spotkanie nie wystarczy. Potrzeba zwykle kilku rozmów z różnymi osobami: kierownikiem działu, osobą, która faktycznie wykonuje proces na co dzień, czasem z działem prawnym w kwestii danych osobowych. Mapowanie wyjątków (co się dzieje, gdy klient jest zły, gdy sprawa dotyczy reklamacji, gdy zgłoszenie jest dwuznaczne) to praca na 1-2 tygodnie, nie na godzinę.

Tydzień 2-5: dostęp do danych i API

To najbardziej nieprzewidywalny etap całego projektu. Jeśli trzeba uzyskać dostęp API do kilku systemów, czasem od różnych dostawców zewnętrznych, czasem z koniecznością podpisania umowy powierzenia danych, realistyczny czas to 1-4 tygodnie. Zdarzało nam się czekać dłużej na odpowiedź działu IT klienta niż trwała cała budowa automatyzacji. To nie jest wina żadnej ze stron, po prostu duże organizacje mają procedury, i te procedury nie przyspieszą, bo ktoś kupił "wdrożenie AI".

Tydzień 4-6: budowa

Przy kilku integracjach, logice warunkowej i obsłudze wyjątków budowa w n8n lub Make to już 1-2 tygodnie pracy, nie dni. Tu też często pojawia się potrzeba dodatkowej logiki: np. inny tok postępowania dla klienta VIP, inny dla nowego leada.

Tydzień 6-9: testy na prawdziwych danych

Im więcej systemów i wyjątków, tym dłużej trwa testowanie. Przy obsłudze klienta czy procesach z udziałem danych osobowych liczymy 2-3 tygodnie, często z kilkoma rundami poprawek po stronie zespołu klienta, który musi ocenić, czy odpowiedzi agenta są trafne i w odpowiednim tonie.

Tydzień 8-10: szkolenie zespołu

Przy złożonym procesie szkolenie to nie jedno spotkanie, tylko kilka sesji rozłożonych na 1-2 tygodnie: osobno dla zespołu, który pracuje z panelem na co dzień, osobno dla osoby odpowiedzialnej za eskalacje i wyjątki.

Tydzień 9-16: wdrożenie progowe z human-in-the-loop

Przy procesach dotykających klienta końcowego czy danych wrażliwych nie włączamy pełnej autonomii agenta szybciej niż po 2-4 tygodniach nadzorowanej pracy, często z progowym zwiększaniem zakresu: najpierw agent obsługuje tylko najprostsze, powtarzalne zapytania, dopiero potem szerszy zakres spraw. To świadome spowolnienie, które ma jeden cel: żeby błąd w logice albo w interpretacji intencji klienta nie kosztował firmy reputacji, zanim ktokolwiek go zauważy.

Łącznie: złożony projekt to realistycznie 2-4 miesiące od pierwszej rozmowy do pełnej, samodzielnej pracy agenta. Dobrym przykładem skali, o jakiej mówimy, jest automatyzacja obsługi klienta, gdzie liczba możliwych scenariuszy kontaktu rośnie szybciej, niż się wydaje na etapie pierwszej rozmowy.

Jak ocenić, czy "wdrożenie w tydzień" to oferta realna, czy marketing

Nie twierdzę, że tydzień to zawsze mało. Dla prostego, dobrze opisanego procesu z jednym systemem i gotowymi dostępami to w pełni realny termin, sami go podajemy. Problem zaczyna się, gdy ktoś oferuje "wdrożenie agenta AI w tydzień" dla procesu dotykającego kilku systemów, danych klientów i wymagającego zatwierdzeń prawnych. Wtedy albo dostawca nie wie jeszcze, jak skomplikowany jest proces (bo nie zrobił porządnego audytu), albo mówi o terminie samej budowy, a nie o uruchomieniu na produkcji z realnym nadzorem.

Kilka pytań, które warto zadać na etapie oferty, zanim podpiszemy umowę z deklarowanym terminem:

• Czy termin obejmuje czas na testy na naszych rzeczywistych danych, czy tylko na danych przykładowych dostawcy?
• Kto po naszej stronie musi dać dostęp do jakich systemów i czy ta osoba wie już, że będzie potrzebna w pierwszym tygodniu?
• Czy przewidziany jest okres z człowiekiem zatwierdzającym decyzje agenta, zanim przejdzie on na pełną autonomię, i ile ten okres trwa?
• Co się stanie, jeśli w trakcie testów okaże się, że proces ma więcej wyjątków, niż zakładano na starcie? Czy to wydłuża termin, czy dostawca po prostu pomija te przypadki?

Jeśli dostawca nie ma gotowej odpowiedzi na te pytania, to znak, że termin został podany bez realnego rozpoznania procesu. To samo dotyczy zresztą wdrożeń wewnętrznych w biurach rachunkowych czy działach księgowości, gdzie pozornie prosty proces (np. dekretacja dokumentów) potrafi mieć zaskakująco dużo wyjątków w praktyce, co dobrze pokazuje nasze doświadczenie z automatyzacją biura rachunkowego.

Dlaczego human-in-the-loop wydłuża projekt, a jednocześnie go ratuje

Etap wdrożenia progowego z nadzorem człowieka jest tym, który najchętniej skracamy pod presją terminu, i tym, którego skracać naprawdę nie warto. Agent AI, nawet dobrze zbudowany, robi w typowych procesach 80-90% pracy poprawnie od razu. Reszta to przypadki brzegowe, które ujawniają się dopiero na żywych danych, nie na etapie testów wewnętrznych. Jeśli w tym okresie decyzje agenta trafiają od razu do klienta albo do księgowości bez żadnej kontroli, koszt błędu jest dużo wyższy niż koszt dodatkowego tygodnia nadzoru.

W praktyce oznacza to konkretne rozwiązanie techniczne: agent generuje odpowiedź albo decyzję, ale zanim trafi ona dalej, ktoś z zespołu klienta ją widzi i zatwierdza jednym kliknięciem albo poprawia. Dopiero gdy liczba poprawek spada do poziomu bliskiego zeru przez kilka dni z rzędu, włączamy pełną automatyzację. To nie jest formalność na pokaz, tylko realny mechanizm, który w naszych wdrożeniach kilka razy uchronił klienta przed wysłaniem błędnej informacji do kontrahenta.

Co można skrócić, a czego nie warto

Skrócić realnie da się etap budowy, jeśli proces jest prosty i firma ma już gotowe API (np. popularny system księgowy z udokumentowanym dostępem). Skrócić można też audyt, jeśli klient przychodzi z gotowym, spisanym opisem procesu, co zdarza się rzadko, ale się zdarza. Czego nie warto skracać: testów na prawdziwych danych i okresu nadzoru człowieka. To dwa etapy, które bezpośrednio wpływają na to, czy agent po uruchomieniu będzie działał poprawnie, czy firma dostanie serię reklamacji w pierwszym tygodniu pełnej automatyzacji.

Jest jeszcze jeden element, który rzadko trafia do harmonogramów, a potrafi dodać tydzień albo dwa: wewnętrzna akceptacja po stronie klienta. Zdarza się, że cały projekt techniczny jest gotowy, przetestowany, a uruchomienie czeka na podpis osoby, która musi zatwierdzić zmianę procesu, i ta osoba jest akurat na urlopie albo ma inne priorytety. To nie jest wina żadnej ze stron, ale warto to uwzględnić, planując termin startu, zwłaszcza jeśli projekt ma ruszyć przed jakimś konkretnym terminem w firmie, np. przed sezonem wzmożonej sprzedaży.