RPA odtwarza zapisaną sekwencję kliknięć w interfejsie i wysypuje się przy każdej zmianie formatki. Agent AI w przepływie agentowym czyta treść — maila, dokument, zgłoszenie — i decyduje w wyznaczonych granicach, przekazując wyjątki człowiekowi. To dwa różne mechanizmy działania, które w praktyce często pracują razem, a nie zamiast siebie.
RPA w skrócie: co robi i gdzie się kończy jego skuteczność
RPA (Robotic Process Automation) to oprogramowanie, które nagrywa i odtwarza sekwencję działań użytkownika na interfejsie — kliknięcia, wpisywanie danych, kopiowanie wartości między systemami. Gartner definiuje RPA jako narzędzia wykonujące „if, then, else" na ustrukturyzowanych danych wejściowych, bez rozumienia treści, którą przetwarzają. Robot RPA jest szybki i przewidywalny, dopóki środowisko, w którym działa, się nie zmieni — nowy układ formularza, inny format eksportu, dodatkowe pole w systemie. Wtedy scenariusz przestaje pasować i proces się zatrzymuje, zwykle bez informacji, co dokładnie poszło nie tak dla osoby, która nie pisała skryptu.
To dlatego wdrożenia RPA sprawdzają się najlepiej w środowiskach, które same się rzadko zmieniają — księgowość, kadry, systemy legacy o ustabilizowanym interfejsie. Tam, gdzie źródło danych jest ustrukturyzowane, a proces nie wymaga interpretacji treści, RPA bywa tańsze i szybsze do wdrożenia niż jakikolwiek agent — nie warto zastępować go „na siłę" tylko dlatego, że AI jest obecnie popularniejszym tematem.
Przepływ agentowy w skrócie
Przepływ agentowy nie odtwarza kliknięć — agent czyta treść zgłoszenia, maila czy dokumentu i interpretuje ją, tak jak zrobiłby to człowiek na pierwszej linii. Dzięki temu radzi sobie ze zmiennością formy: inny szyk zdania, nietypowe sformułowanie, brakujące pole nie muszą oznaczać błędu. W zamian przepływ musi mieć jasno opisane granice decyzji agenta — bo w przeciwieństwie do RPA, agent nie zatrzymuje się sam, kiedy napotka coś nietypowego; trzeba mu to wprost zdefiniować, zanim zacznie działać na realnych zgłoszeniach.
Tabela porównawcza
| Cecha | RPA | Workflow agentowy |
|---|---|---|
| Sposób działania | odtwarza nagraną sekwencję kliknięć/działań | interpretuje treść i decyduje w granicach |
| Wejście | ustrukturyzowane dane, stały format | tekst naturalny, zmienna forma |
| Odporność na zmiany interfejsu | niska — zmiana formatki psuje scenariusz | wysoka — zmiana formy treści nie musi przeszkadzać |
| Obsługa wyjątków | zatrzymanie z błędem, kolejka do przeglądu | rozpoznanie granicy i przekazanie z kontekstem |
| Koszt utrzymania | rośnie z liczbą zmian w systemach źródłowych | rośnie z liczbą nowych typów przypadków |
| Typowe zastosowania | przenoszenie danych między systemami, raportowanie | triage zgłoszeń, kwalifikacja leadów, czytanie dokumentów |
Kiedy łączyć RPA i agenta w jednym przepływie
W praktyce oba podejścia rzadko się wykluczają. Częsty wzorzec: agent czyta treść i podejmuje decyzję, a RPA wykonuje mechaniczną część zadania — wprowadza dane do systemu księgowego, aktualizuje status w CRM-ie, generuje dokument w ustalonym formacie. Krótko: RPA wykonuje, agent decyduje. Rozdzielenie tych ról jest jednym z powodów, dla których przepływ agentowy warto zaprojektować jako osobną warstwę, zanim ktokolwiek zacznie łączyć konkretne narzędzia.
Typowe pułapki przy migracji z RPA do agenta
- Kopiowanie starego scenariusza wprost. Skrypt RPA opisuje kroki, nie granice decyzji — próba „przepisania" go dla agenta zwykle pomija właśnie to, co najważniejsze.
- Brak zdefiniowanego progu eskalacji. Bez jasnej reguły agent zaczyna zgadywać zamiast przekazywać sprawę dalej — dokładnie to, czego przepływ agentowy ma unikać.
- Traktowanie migracji jako projektu czysto technicznego. Najwięcej czasu pochłania ustalenie progów biznesowych, nie wybór frameworka.
- Wyłączenie starych robotów RPA za wcześnie. Jeśli agent przejmuje tylko interpretację treści, a mechaniczne wprowadzanie danych nadal robi robot, wyłączenie go przed uruchomieniem nowej integracji zostawia proces bez żadnego wykonawcy.
Przykład: agent i RPA w przetwarzaniu faktur
Faktura przychodzi jako załącznik PDF o zmiennym układzie — inny dostawca, inny szablon. Agent czyta dokument, wyodrębnia kwotę, numer zamówienia i termin płatności, po czym zestawia je z zamówieniem w systemie. Jeśli kwoty zgadzają się co do grosza, robot RPA wykonuje mechaniczną część: wprowadza dane do systemu księgowego dokładnie w formacie, jakiego oczekuje ten system. Przy rozbieżności agent nie próbuje jej „wyrównać" — sprawa trafia do księgowej z podświetloną różnicą. RPA w tym układzie nigdy nie widzi treści faktury, tylko już rozstrzygnięte dane; agent nigdy nie dotyka samego systemu księgowego. Rozdzielenie odpowiedzialności ułatwia też testowanie — błąd łatwiej przypisać do konkretnej warstwy.
Jak zacząć
Zanim zdecydujesz, czy dany proces potrzebuje RPA, agenta, czy obu naraz, warto sprawdzić dwie rzeczy: czy dane wejściowe są ustrukturyzowane (RPA) czy wymagają interpretacji treści (agent), oraz jak często zmienia się środowisko, w którym proces działa. Jeśli odpowiedź na oba pytania brzmi „ustrukturyzowane i stabilne", zbudowanie przepływu agentowego może być nadmiarowe — zwykły RPA wystarczy taniej i szybciej.
Czy agent może całkowicie zastąpić istniejące roboty RPA? Rzadko warto to robić od razu. Tam, gdzie RPA działa stabilnie na ustrukturyzowanych danych, wymiana go na agenta nic nie daje — koszt utrzymania modelu bywa wyższy niż koszt utrzymania prostego skryptu. Sens ma dobudowanie agenta tam, gdzie dziś przed RPA stoi człowiek czytający i interpretujący treść.
Więcej o samym pojęciu przepływu agentowego przeczytasz w artykule Czym jest przepływ agentowy (agentic workflow)?, a o projektowaniu konkretnego przepływu krok po kroku — w Jak zaprojektować przepływ agenta AI dla obsługi zgłoszeń.