BPA vs RPA vs agent AI: 3 pytania, jedna decyzja (i jak nie pomylić narzędzia z problemem)

W większości rozmów z klientami pytanie brzmi: "zróbmy nam RPA" albo "chcemy agenta AI do wszystkiego". I to jest dokładnie odwrotna kolejność niż ta, która działa. Zanim ktokolwiek w naszej firmie zapyta, jakiego narzędzia użyć, pytamy o proces: jak często się powtarza, czy wymaga oceny, i czy dane wejściowe mają stałą strukturę. Dopiero z odpowiedzi na te trzy pytania wynika, czy sięgamy po BPA, RPA, agenta AI, czy (co zdarza się częściej niż ktokolwiek chciałby przyznać) po kombinację wszystkich trzech w jednym procesie.

Ten artykuł nie jest kolejnym słownikiem definicji przepisanym z Wikipedii. Pokazujemy w nim matrycę decyzyjną, którą realnie stosujemy przy wdrożeniach, i konkretne przykłady narzędzi z każdej kategorii, żeby po przeczytaniu dało się samodzielnie ocenić, w którą stronę patrzeć.

Dlaczego te trzy pojęcia wrzuca się do jednego worka

Bo z zewnątrz wyglądają podobnie: system robi coś, co wcześniej robił człowiek. Ale to, co dzieje się "pod maską", jest zupełnie inne. BPA orkiestruje przepływ danych między aplikacjami przez ich API. RPA symuluje ludzkie kliknięcia w interfejsie, bo API nie ma albo jest niedostępne. Agent AI, oparty o duży model językowy (LLM), nie wykonuje z góry zapisanej ścieżki, tylko interpretuje treść i podejmuje decyzję w oparciu o kontekst.

Problem w tym, że dostawcy technologii mają interes w tym, żeby te granice zacierać. Firmy sprzedające RPA nazywają swoje produkty "platformami do hiperautomatyzacji". Firmy od BPA dodają moduły AI i piszą, że to teraz "inteligentna automatyzacja". W efekcie klient słyszy trzy różne nazwy tej samej obietnicy i wybiera po cenie albo po tym, kto miał ładniejszą prezentację. To rzadko kończy się dobrze, bo narzędzie dobrane niezgodnie z naturą procesu albo się przewraca przy pierwszej zmianie w systemie źródłowym, albo generuje koszty utrzymania większe niż oszczędność czasu, którą miało dać.

Trzy definicje, trzy różne problemy do rozwiązania

BPA (Business Process Automation): łączenie systemów po API

BPA to automatyzacja przepływu pracy między aplikacjami, która korzysta z ich oficjalnych interfejsów (API, webhooki). Narzędzie typu n8n albo Make (dawniej Integromat) buduje scenariusz: dokument trafia do skrzynki mailowej, system wyciąga z niego dane, zapisuje je w ERP, wysyła powiadomienie do Slacka. Wszystko dzieje się "pod spodem", bez symulowania kliknięć w ekranie.

Zaletą BPA jest stabilność: jeśli API się nie zmienia, scenariusz działa miesiącami bez ingerencji. Ograniczeniem jest to, że wymaga, żeby system faktycznie miał API. Sporo starszych programów księgowych czy branżowych systemów magazynowych go nie ma, albo ma bardzo ograniczone. Wtedy BPA odpada i trzeba sięgnąć po RPA.

RPA (Robotic Process Automation): symulacja klikania człowieka

RPA, którego przykładem jest UiPath (albo Automation Anywhere), działa inaczej: robot "widzi" ekran tak jak użytkownik i wykonuje te same kliknięcia, przepisywanie pól, kopiuj-wklej, które wcześniej robił pracownik. To rozwiązanie ratunkowe tam, gdzie nie ma API albo integracja przez API byłaby droższa niż zrobienie robota UI.

Cena tej elastyczności jest wysoka: robot RPA jest kruchy. Zmiana układu przycisków w aplikacji, aktualizacja systemu, inny rozmiar okna, i scenariusz się wywala. W praktyce widzieliśmy wdrożenia RPA, które wymagały prawie tyle samo pracy utrzymaniowej co oszczędności, jakie dawały. Dlatego zawsze pytamy najpierw, czy dany system ma API, zanim w ogóle rozważymy RPA. Jeśli ma, wybieramy BPA. RPA zostawiamy dla przypadków bez alternatywy.

Agent AI: interpretacja i decyzja, nie tylko wykonanie

Agent AI to coś jakościowo innego. Nie ma z góry zapisanej ścieżki "jeśli pole X, to wpisz Y w pole Z". Model językowy (LLM, np. GPT) czyta treść maila, faktury, zgłoszenia od klienta, rozumie kontekst i podejmuje decyzję: to jest reklamacja pilna, wymaga eskalacji; ta faktura ma niestandardowy format, trzeba dociągnąć dane z załącznika; ten klient pyta o coś, co wymaga sprawdzenia w trzech różnych systemach, więc agent sam wykonuje te zapytania i składa odpowiedź.

Siła agenta AI to praca z danymi nieustrukturyzowanymi, tam gdzie BPA i RPA są bezradne, bo nie da się z góry napisać reguły "jeśli, to". Ograniczenie jest równie ważne: agent AI potrafi się pomylić, zwłaszcza przy niejednoznacznych danych wejściowych, i przy podejmowaniu decyzji z realnymi konsekwencjami finansowymi czy prawnymi nie zostawiamy go bez nadzoru. W naszych wdrożeniach agent robi 80% zgłoszeń w pełni samodzielnie, a te niejasne, nietypowe albo o wysokiej stawce trafiają do człowieka z gotową rekomendacją, nie z automatyczną decyzją.

Matryca decyzyjna: trzy pytania, które zadajemy przed wyborem narzędzia

Zamiast zaczynać od "jakiego narzędzia użyjemy", zaczynamy od trzech pytań o sam proces.

Pytanie 1: Czy proces jest regularny i przewidywalny? Faktura zawsze ma podobną strukturę, zamówienie zawsze wchodzi tą samą drogą, raport zawsze trzeba wygenerować w ten sam sposób o tej samej porze. Jeśli tak, i systemy mają API, patrzymy w stronę BPA.

Pytanie 2: Czy reguły są sztywne, ale system nie ma API? Wtedy, i tylko wtedy, sięgamy po RPA. Nie dlatego, że jest gorsze z definicji, tylko dlatego, że jest droższe w utrzymaniu i mniej stabilne niż integracja przez API. Traktujemy je jako plan B, nie plan A.

Pytanie 3: Czy proces wymaga interpretacji, oceny albo pracy z tekstem, który nie ma stałego formatu? Zgłoszenie od klienta napisane własnymi słowami, faktura w dowolnym układzie od dowolnego kontrahenta, mail z niejednoznaczną prośbą. Tu wchodzi agent AI, bo z góry zapisanych reguł po prostu nie da się napisać dla każdego wariantu.

W praktyce większość realnych procesów w firmie to nie jeden typ, tylko kombinacja. Klasyczny przykład: obsługa faktur kosztowych. Odbiór maila i zapis pliku to BPA. Odczytanie danych z faktury o nietypowym układzie i decyzja, do jakiej kategorii kosztowej ją przypisać, to zadanie dla agenta AI. Zaksięgowanie w systemie, który nie ma API, to już robota dla RPA. Jedno wdrożenie, trzy warstwy technologii, każda robi to, do czego jest stworzona. Więcej o tym, jak to wygląda w praktyce przy dokumentach kosztowych, opisujemy przy automatyzacji faktur.

Gdzie te granice się zacierają w praktyce

Najczęstszy błąd, jaki widzimy u klientów, to próba zrobienia agenta AI tam, gdzie wystarczyłby prosty scenariusz BPA. Ktoś chce "inteligentnego bota", który odczyta fakturę, choć faktura zawsze przychodzi w tym samym formacie od tego samego dostawcy. To niepotrzebne przepłacanie za elastyczność, która nigdy nie zostanie wykorzystana, a przy okazji wprowadzenie niepewności tam, gdzie mogłaby być stuprocentowa powtarzalność.

Drugi błąd, odwrotny: próba "zaszycia" w sztywnym scenariuszu BPA czegoś, co z natury wymaga oceny. Klient chce automatycznie kategoryzować zgłoszenia od klientów regułami typu "jeśli w treści jest słowo reklamacja, to oznacz jako reklamacja". Działa dopóki ktoś nie napisze "nie chcę reklamować, ale mam pytanie o zwrot". Reguła się sypie, bo język naturalny nie daje się domknąć w skończonym zestawie warunków "jeśli, to". To jest dokładnie miejsce, gdzie warto rozważyć agenta AI zamiast rozbudowywania coraz dłuższej listy wyjątków w scenariuszu BPA. Więcej o tym podejściu w kontekście wsparcia klientów opisujemy przy automatyzacji obsługi klienta.

Trzeci, rzadszy, ale kosztowny błąd: budowanie RPA tam, gdzie system od dawna ma API, tylko nikt go nie sprawdził. Zdarzyło się nam przejmować wdrożenia, w których robot klikał w przeglądarce w panel, choć dostawca tego systemu udostępniał gotowe API od lat. Godzina researchu na starcie oszczędza potem miesiące poprawek robota, który się wywraca przy każdej aktualizacji interfejsu.

Co mówią o tym dane rynkowe

Gartner od kilku lat umieszcza hiperautomatyzację, czyli łączenie RPA, BPA i AI w jeden ekosystem, w czołówce strategicznych trendów technologicznych, a analitycy z Deloitte i podobnych firm konsultingowych regularnie podkreślają w swoich raportach o automatyzacji, że firmy, które traktują te technologie zamiennie zamiast komplementarnie, osiągają gorszy zwrot z inwestycji. To pokrywa się z naszym doświadczeniem z wdrożeń w polskich firmach: rynek dojrzewa nie w kierunku "jednego narzędzia do wszystkiego", tylko w kierunku świadomego łączenia warstw, każdej tam, gdzie ma sens.

W biurach rachunkowych i działach księgowości ten trend widać wyraźnie: rosnąca presja czasowa przy jednoczesnym niedoborze rąk do pracy sprawia, że firmy szukają rozwiązań łączących prostą automatyzację przepływu dokumentów z warstwą, która potrafi ocenić i skategoryzować dokument bez sztywnych reguł. Piszemy o tym szerzej przy automatyzacji biura rachunkowego.

Jak to wygląda u nas, gdy zaczynamy wdrożenie

Zanim zaproponujemy klientowi konkretne narzędzie, mapujemy proces na kartce: co się dzieje krok po kroku, gdzie leżą dane, jakie systemy biorą udział, i który krok wymaga oceny człowieka, a który jest czystym przepisywaniem. Dopiero z tej mapy wynika, które fragmenty procesu oddajemy BPA, które (jeśli nie ma wyjścia) RPA, a które agentowi AI. Czasem okazuje się, że proces, który klient chciał "zautomatyzować w całości agentem AI", w 70% da się rozwiązać prostym, tańszym i bardziej stabilnym scenariuszem BPA, a agent potrzebny jest tylko w jednym, wąskim miejscu decyzyjnym.

To podejście jest mniej efektowne w sprzedaży niż hasło "wdrażamy AI", ale w praktyce oznacza niższy koszt utrzymania i mniej niespodzianek po trzech miesiącach działania systemu. Firma handlowa, która przetwarza kilkaset zamówień dziennie, zwykle potrzebuje solidnej warstwy BPA do przenoszenia danych między sklepem, magazynem i księgowością, i dopiero na tym fundamencie warto dokładać agenta AI do obsługi nietypowych zapytań klientów czy wykrywania anomalii w zamówieniach.