RPA umiera czy ewoluuje? Automatyzacja procesów w czasach agentów AI

Dlaczego temat „śmierci RPA” wraca właśnie teraz

Skąd wzięła się fala nagłówków o końcu RPA

Temat „RPA umiera” nie bierze się znikąd. Przez ostatnią dekadę robotyzacja procesów (RPA – Robotic Process Automation) była jednym z głównych narzędzi do szybkiej automatyzacji back-office’u. Roboty klikalne rozwiązywały bardzo konkretny problem: jak zautomatyzować pracę człowieka przy ekranie, bez konieczności zmian w systemach IT i budowania integracji API.

Wystarczyło „nagrać” sekwencję kliknięć i działań, dodać reguły biznesowe i robot zaczynał wykonywać powtarzalną pracę: kopiowanie danych między systemami, generowanie raportów, wypełnianie formularzy. To było tańsze i szybsze niż rozbudowa ERP czy CRM, więc działy operacyjne i finansowe chętnie po to sięgały.

Fala nagłówków o śmierci RPA pojawiła się, gdy na rynek weszły generatywne modele językowe (LLM) i agenci AI. Nagle okazało się, że:

• maszyna potrafi sama zrozumieć treść maila, pisma czy dokumentu PDF,
• nie trzeba definiować setek reguł, bo model „domyśla się” intencji użytkownika,
• pracownik może „gadać” z systemem w języku naturalnym, zamiast klikać w formularze.

Na tym tle tradycyjne roboty RPA – przywiązane do ekranu, kruche wobec zmian UI i ślepe na kontekst – zaczęły wyglądać jak technologia poprzedniej epoki. Stąd narracja, że RPA umiera. Tyle że to tylko część obrazu.

Wpływ generatywnej AI na myślenie o automatyzacji procesów

Generatywna AI i duże modele językowe radykalnie zmieniły, jak patrzy się na automatyzację procesów biurowych. Do tej pory dominowała logika: „mamy sekwencję kroków, trzeba ją zautomatyzować”. Dziś coraz częściej pytanie brzmi: „jakiego wyniku oczekuje użytkownik i co musi się stać po drodze, żeby go dostarczyć”.

LLM potrafią:

• klasyfikować wiadomości i dokumenty na podstawie treści,
• wyciągać z nich dane (np. numery faktur, kwoty, daty, nazwy kontrahentów),
• proponować kolejne kroki (np. wygenerować odpowiedź, utworzyć zgłoszenie w systemie, przygotować draft umowy).

To powoduje, że automatyzacja przesuwa się z poziomu „kliknij tu i skopiuj tam” do poziomu „zrozum, co trzeba zrobić i załatw to możliwie najprościej”. RPA nie znika, ale traci monopol na bycie pierwszym wyborem. Coraz częściej pełni rolę „ostatniej mili” integracji tam, gdzie nie ma API albo zmiana systemu jest nierealna w krótkim czasie.

Dwa obozy: łatać stare RPA czy przepisać wszystko na AI

W wielu firmach zarysowały się dwa podejścia.

Pierwszy obóz – nazwijmy go konserwatywnym – mówi: utrzymać i łatać. Argumenty:

• roboty działają, generują realne oszczędności i trudno uzasadnić ich „wyrzucenie”,
• organizacja zainwestowała w licencje, kompetencje i Center of Excellence automatyzacji,
• regulacje i audyt wymuszają stabilność – każda nowa technologia to dodatkowa praca po stronie compliance.

Drugi obóz – ofensywny – jest bliżej narracji „porzucić i przepisać na AI”. W ich ocenie:

• dalszy rozwój RPA to pompka do podtrzymywania „technologii przejściowej”,
• koszty utrzymania robotów rosną wraz z liczbą wyjątków i zmian w systemach,
• agenci AI i integracje API umożliwiają pójście od razu w automatyzację procesów end-to-end.

Realna strategia zwykle leży pomiędzy. CIO i COO, którzy patrzą na temat trzeźwo, próbują wyznaczyć:

• jaką część robotów można „otoczyć” AI, zamiast przepisywać od razu (np. AI obsługuje maile, robot wykonuje operacje w systemie),
• które procesy powinny mieć priorytet w migracji do automatyzacji opartej o API i agentów AI,
• jak wygląda strategia wyjścia z legacy RPA na 3–5 lat, a nie w perspektywie jednego kwartału.

W praktyce kluczowa decyzja dotyczy nie tyle samego RPA, ile tego, gdzie firma chce być na krzywej automatyzacji za kilka lat i jakie technologie będą wtedy fundamentem, a jakie tylko łatkami.

Jakie decyzje musi dziś podjąć CIO / dyrektor operacyjny

Na poziomie zarządczym temat „czy RPA umiera” przekłada się na kilka bardzo konkretnych decyzji:

• Strategia technologiczna – czy platforma RPA pozostaje głównym narzędziem automatyzacji, czy przechodzi do roli jednego z komponentów obok platform integracyjnych, narzędzi low-code i agentów AI.
• Budżet i priorytety – czy nowy budżet rozwojowy idzie w rozbudowę floty robotów, czy w projekty API-first, modernizację systemów i wdrożenia generatywnej AI.
• Kompetencje zespołu – czy continue-uje się kształcenie „twórców botów”, czy przesuwa akcent na analityków procesów, architektów integracji i specjalistów od orkiestracji agentów AI.
• Governance – jak połączyć governance AI i RPA: modele odpowiedzialności, procesy change management, kontrolę jakości, bezpieczeństwo danych.
• Ryzyko technologicznego długu – który fragment parku robotów już dziś należy traktować jako „RPA-as-legacy” i zacząć planować jego wygaszanie.

Od jakości tych decyzji zależy, czy organizacja wpadnie w pułapkę inwestowania w technologię, która za dwa–trzy lata będzie głównie utrapieniem, czy zbuduje elastyczny krajobraz automatyzacji łączący RPA, API, workflow i agentów AI.

RPA – czym faktycznie jest, a czym nigdy nie było

RPA jako robot klikalny, a nie „inteligentny pracownik”

RPA to w swojej klasycznej formie robot softwarowy, który naśladuje działania człowieka w interfejsie graficznym. Logika jest deterministyczna: jeśli na ekranie pojawi się taki element, kliknij tu; jeśli w komórce arkusza jest taka wartość, skopiuj ją tam. Całość opiera się na jasno zdefiniowanych krokach i regułach.

Kluczowe cechy klasycznego RPA:

• Wysoka deterministyczność – robot nie „domyśla się”, co miałeś na myśli; wykonuje ściśle zdefiniowane instrukcje.
• Brak rozumienia kontekstu – widzi pola i wartości, nie rozumie znaczenia tekstu w taki sposób, jak robi to człowiek czy współczesny model językowy.
• Orientacja na UI – pracuje na ekranach aplikacji, nie na ich logice biznesowej.

Wbrew marketingowym hasłom, RPA nigdy nie było „cyfrowym pracownikiem, który myśli i się uczy”. To narzędzie do odtwarzania powtarzalnych czynności. „Inteligencja” pojawiała się najczęściej w materiałach sprzedażowych, a nie w realnych wdrożeniach.

Typowe zastosowania klasycznego RPA

Tam, gdzie proces jest powtarzalny, oparty na ustrukturyzowanych danych i rozbity na jasne kroki, roboty RPA sprawdzały się (i wciąż sprawdzają) bardzo dobrze. Typowe przykłady:

• Kopiowanie danych między systemami – np. przenoszenie danych z systemu zamówień do systemu finansowo-księgowego, jeśli nie ma prostego API.
• Praca z aplikacjami bez API – stare systemy, aplikacje terminalowe, rozwiązania vendorów, którzy nie udostępniają integracji.
• Generowanie raportów – uruchamianie serii zapytań, eksport danych do Excela, łączenie arkuszy, formatowanie.
• Obsługa prostych formularzy – wprowadzanie danych z plików CSV, Excel lub prostych szablonów.

W takich obszarach RPA bywa wręcz trudne do pobicia: jest szybsze do wdrożenia niż budowa integracji API w dużym, zbiurokratyzowanym środowisku IT i nie wymaga zmian w systemie źródłowym.

Główne ograniczenia – kruchość i koszt utrzymania

Problem pojawia się wtedy, gdy:

• interfejsy systemów często się zmieniają (nowe wersje, redesign UI, zmiany layoutu),
• proces ma dużo wyjątków i odchyleń od „happy path”,
• dane wejściowe są nieustrukturyzowane (wolny tekst, skany dokumentów, maile),
• robot musi „interpretować” treść, a nie tylko mechanicznie kopiować wartości.

W takich sytuacjach klasyczne RPA staje się kruche. Każda zmiana ekranu może „złamać” bota. Pojawia się rosnący koszt maintenance’u: trzeba ciągle wracać do istniejących robotów i poprawiać ich działanie. W dużych flotach liczonych w setkach robotów, to poważny element budżetu.

Do tego dochodzi problem braku adaptacji do wyjątków. Robot nie „zastanawia się”, co zrobić w nietypowej sytuacji. Można oczywiście rozbudować go o kolejne warunki, ale to równa się:

• wzrostowi złożoności skryptów,
• większej podatności na błędy,
• konieczności utrzymywania ludzi, którzy rozumieją te skrypty.

Efekt: roboty, które miały odciążyć ludzi, zaczynają wymagać osobnego „działu wsparcia” i stają się nową warstwą długu technologicznego.

Mit „sztucznej inteligencji” w RPA

Przez lata wielu dostawców RPA chętnie używało określeń „inteligentne roboty”, „cyfrowi pracownicy”, „AI-powered RPA”. W praktyce w zdecydowanej większości wdrożeń:

• główna logika była w pełni regułowa i deterministyczna,
• „AI” ograniczała się do rozwiązań typu OCR lub prostych klasyfikatorów,
• brakowało zdolności rozumienia języka i kontekstu w sensie zbliżonym do tego, co dziś potrafią LLM.

To ważne rozróżnienie. RPA to technologia automatyzacji interfejsu, nie inteligentnego wnioskowania. Współczesne platformy automatyzacji często łączą RPA z modułami AI (np. rozpoznawanie dokumentów, analiza treści), ale jest to architektura hybrydowa, nie „magiczna transformacja” klasycznego bota w inteligentnego agenta.

RPA a szeroko rozumiana automatyzacja procesów

W wielu organizacjach powstało niebezpieczne utożsamienie: automatyzacja procesów = RPA. To zafałszowuje obraz. RPA jest tylko jednym z narzędzi w szerszym ekosystemie:

• BPM (Business Process Management) – narzędzia do modelowania, wykonywania i monitorowania procesów end-to-end (workflow, reguły biznesowe, role).
• Integracje API / iPaaS – łączenie systemów po warstwie danych i usług, bez „udawania” użytkownika na ekranie.
• Low-code / no-code – szybkie budowanie prostych aplikacji i mikroprocesów, które mogą zastąpić część robotów.
• Agenci AI – komponenty oparte o modele językowe, które potrafią zrozumieć intencje, zaplanować kroki i użyć odpowiednich narzędzi.

RPA było i jest jednym z budulców automatyzacji, ale nie zastępuje architektury procesowej, dobrego zaprojektowania przepływów end-to-end ani polityki danych. Traktowanie RPA jako „srebrnej kuli” prowadziło do nadmiernego rozrostu floty botów i właśnie do powstania „RPA-as-legacy”.

Agenci AI – czym są i czym różnią się od robotów RPA

Definicja agenta AI i jego kluczowe cechy

Agent AI to komponent oparty o modele językowe (LLM), który potrafi samodzielnie zinterpretować zadanie, zaplanować sekwencję działań i skorzystać z dostępnych narzędzi (np. API, baz danych, usług zewnętrznych), aby osiągnąć oczekiwany rezultat.

W odróżnieniu od robotów RPA, agent AI:

• pracuje przede wszystkim na języku naturalnym – przyjmuje polecenia i przetwarza dane tekstowe,
• radzi sobie z nieustrukturyzowanymi danymi – maile, dokumenty, czaty, notatki,
• ma zdolność do podejmowania drobnych decyzji – np. wybierając odpowiednią procedurę na podstawie treści zgłoszenia,
• może uczyć się z przykładów, promptów, feedbacku użytkownika, a nie tylko z twardo zakodowanych reguł.

Od promptu do działania – jak agenci AI wykonują pracę

Dobrze zbudowany agent AI ma trzy kluczowe „mięśnie”: rozumienie, planowanie i wykonanie. Całość przypomina pracę młodszego specjalisty, który zna procedury, ma dostęp do narzędzi i potrafi dopytać, gdy ma wątpliwości.

W uproszczeniu jego działanie przebiega tak:

• Interpretacja zlecenia – agent analizuje treść zadania (np. mail klienta, opis incydentu, prośbę menedżera) i wyciąga z niej istotne elementy: intencję, parametry, ograniczenia.
• Planowanie – na podstawie wbudowanych instrukcji (promptów), dokumentacji procesów i dostępnych narzędzi układa plan krok po kroku. Ten plan może być jawny (logi, które widzi człowiek) lub wewnętrzny.
• Dobór narzędzi – agent decyduje, czy dany krok wykona poprzez wywołanie API, użycie RPA, uruchomienie workflow w systemie BPM czy wygenerowanie odpowiedzi tekstowej.
• Weryfikacja i korekta – sprawdza, czy osiągnięty wynik spełnia założenia (np. czy status zamówienia rzeczywiście się zmienił); jeśli nie, próbuje innej ścieżki lub eskaluje do człowieka.

Kluczowa różnica względem RPA leży w zdolności do elastycznego doboru ścieżki. Robot RPA odtwarza zaprogramowaną ścieżkę, agent AI może ją modyfikować w zależności od tego, co „zobaczy” w danych lub jaką odpowiedź zwróci system.

Rodzaje agentów AI z perspektywy biznesu

Z punktu widzenia organizacji, nie ma znaczenia, czy agent jest oparty o jeden model, kilka modeli czy hybrydę rozwiązań. Istotne jest, do jakiej pracy jest „zatrudniony”. W praktyce spotykane są głównie trzy typy:

• Agenci asystujący (copiloty) – wspierają człowieka w pracy, ale niczego nie finalizują sami. Podpowiadają odpowiedzi klientom, przygotowują szkice maili, sugerują kolejne kroki w procesie.
• Agenci wykonawczy – samodzielnie realizują zadania w określonych granicach odpowiedzialności: zakładają zgłoszenia, sprawdzają statusy, wyszukują informacje, aktualizują dane w systemach.
• Agenci orkiestrujący – pełnią rolę „koordynatora”, który rozdziela zadania między inne systemy: roboty RPA, mikroserwisy, workflow BPM, a w razie potrzeby także ludzi (np. prosząc o akceptację).

Te role często się przenikają. Ten sam agent może czasem tylko podsuwac rekomendację konsultantowi, a w innych scenariuszach działać w pełni autonomicznie, jeśli ryzyko jest niewielkie i proces dobrze opisany.

Agenci AI a ryzyko: halucynacje, kontrola, odpowiedzialność

W odróżnieniu od robotów RPA, agent AI może popełniać błędy „kreatywne”: błędnie zinterpretować kontekst, wygenerować nieprawdziwą odpowiedź, źle dobrać narzędzie. W obszarach wrażliwych (finanse, regulacje, dane osobowe) oznacza to konieczność innych mechanizmów bezpieczeństwa niż przy klasycznym RPA.

Zwykle stosuje się kombinację kilku zabezpieczeń:

• Granularne uprawnienia – agent ma dostęp tylko do tych operacji, które są mu faktycznie potrzebne (np. może odczytać saldo, ale nie może zlecić przelewu).
• Kontrola zakresu samodzielności – w procesach o wyższym ryzyku agent może jedynie przygotować propozycję działania, a decyzję podejmuje człowiek.
• Walidacja ex-ante i ex-post – reguły biznesowe, które weryfikują, czy wynik działania mieści się w dopuszczalnych granicach (np. próg kwotowy, typ klienta, zakres dat).
• Ścieżka audytu – pełne logowanie promptów, odpowiedzi modelu i wywołań narzędzi, tak aby dało się odtworzyć, dlaczego agent podjął konkretną decyzję.

Tam, gdzie w RPA „bezpieczeństwo” wynikało w dużej mierze z deterministyczności skryptu, w agentach AI trzeba budować je poprzez połączenie reguł, nadzoru i architektury uprawnień.

RPA i agenci AI w jednym procesie – praktyczne scenariusze

W wielu firmach sensowne nie jest zastępowanie robotów agentami, tylko dobudowanie warstwy AI, która odciąża ludzi od interpretacji i decyzji, a RPA pozostawia tam, gdzie jest stabilne.

Przykładowy wzorzec wygląda tak:

• Agent AI czyta przychodzącą korespondencję (mail, formularz, skan umowy), wyciąga kluczowe dane i klasyfikuje sprawę.
• Na tej podstawie wybiera odpowiednią ścieżkę procesu i przekazuje zadanie do bota RPA (np. „zarejestruj reklamację typu X”).
• Robot RPA wykonuje techniczną pracę w systemie, po czym odsyła status do agenta.
• Agent przygotowuje personalizowaną odpowiedź do klienta, uwzględniając status, historię i obowiązujące procedury.

W takim układzie RPA pełni rolę silnika wykonawczego w starszych systemach, a agent AI – warstwy „rozumiejącej” i komunikacyjnej. Z punktu widzenia klienta znika wrażenie sztywnej automatyzacji, a wewnątrz organizacji spada presja na przebudowę całej floty robotów na raz.

Czy RPA faktycznie „umiera”? Trzeźwe spojrzenie na rynek i praktykę

Cykl życia technologii: od hype’u do infrastruktury

RPA przeszło już pełny cykl hype’u: od entuzjastycznych prezentacji o „cyfrowych pracownikach”, przez masowe projekty pilotażowe, aż po dojrzałe dyskusje o TCO, długu technologicznym i roli w architekturze przedsiębiorstwa. Na tym etapie technologia zwykle nie „umiera”, tylko staje się fragmentem infrastruktury.

W praktyce oznacza to, że:

• w nowych projektach automatyzacyjnych RPA rzadko jest pierwszym wyborem – częściej pojawia się pytanie: „czy da się to zrobić API lub workflow?”;
• roboty istniejące w krytycznych procesach są utrzymywane i optymalizowane, ale rzadziej dynamicznie rozbudowywane;
• część prostych automatyzacji migruje do narzędzi low-code/no-code lub do funkcji natywnych w systemach biznesowych.

Z perspektywy zarządów wygląda to jak „spadek znaczenia RPA”. Z perspektywy architektury IT to raczej przesunięcie technologii z warstwy innowacji do warstwy utrzymaniowej.

Gdzie zapotrzebowanie na RPA realnie maleje

Są obszary, w których presja na redukcję RPA jest szczególnie silna:

• Systemy z dojrzałym API – tam, gdzie dostawca udostępnia stabilne, dobrze udokumentowane interfejsy, budowanie nowych robotów klikających w UI zwyczajnie nie ma sensu.
• SaaS klasy enterprise – platformy CRM, ERP czy HCM rozwijają własne mechanizmy workflow i automatyzacji. Roboty, które kiedyś kleiły brakujące funkcje, stopniowo stają się zbędne.
• Proste zadania biurkowe – część z nich przejmują funkcje wbudowane w narzędzia biurowe (makra w chmurze, automatyzacje „if this then that”), a w najbliższych latach dodatkowo copiloty w pakietach office.

W tych segmentach RPA konkuruje już nie tylko z integracją systemową, ale z natywnymi funkcjami produktów i usługą „AI-as-feature”, którą dostawcy systemów dodają do swoich platform.

Gdzie RPA ma jeszcze długie życie

Jednocześnie istnieją środowiska, w których RPA będzie funkcjonować jeszcze przez lata:

• Rozległe parki aplikacji legacy – banki, ubezpieczyciele, administracja publiczna, energetyka. Systemy pisane dekady temu, często bez perspektywy szybkiej wymiany, z minimalnymi możliwościami integracji.
• Procesy cross-vendorowe – gdy trzeba połączyć kilka zamkniętych systemów od różnych dostawców, a żaden nie ma sensownego API ani wsparcia dla integracji.
• Scenariusze przejściowe – migracje systemów, przejęcia, wdrożenia, w których RPA pełni rolę „tymczasowej protezy” na 2–3 lata, dopóki nie powstanie docelowa architektura.

W takich kontekstach roboty nie są konkurencją dla agentów AI, tylko jednym z narzędzi w zestawie. Agent może „myśleć” i decydować, ale wciąż ktoś musi kliknąć w stary ekran terminala.

Jak wyglądają decyzje „stop / rozwijaj” w dojrzałych organizacjach

W organizacjach, które przeszły etap entuzjastycznego skalowania RPA, widać obecnie kilka powtarzalnych decyzji:

• Zamrożenie nowych inicjatyw UI-first – nowe automatyzacje mogą używać RPA tylko wtedy, gdy brak realnej alternatywy (API, integracja plikowa, workflow systemowe).
• Segmentacja istniejącej floty robotów – podział na roboty krytyczne (utrzymujemy), średnio istotne (planujemy migrację) i zbędne (wyłączamy przy okazji zmian procesów).
• Łączenie zespołów RPA z zespołami integracji – zamiast osobnego „działu botów”, powstaje szersza funkcja automatyzacji, która patrzy na proces i architekturę koniec–do–końca.

To przesunięcie z myślenia „ile mamy robotów” na myślenie „jak wygląda nasz krajobraz automatyzacji” – i gdzie RPA jest realnie najlepszym (lub jedynym) narzędziem.

Od prostych makr do hiperautomatyzacji – jak wygląda ewolucja automatyzacji procesów

Historia w skrócie: od Excela do agentów

Większość organizacji przechodzi podobną ścieżkę rozwoju automatyzacji:

• Makra i skrypty – pojedynczy pracownicy automatyzują własną pracę (VBA, skrypty w przeglądarce, proste integracje).
• RPA jako „biurowy egzoszkielet” – formalizacja tych automatyzacji na poziomie organizacji, centralne zarządzanie robotami, standaryzacja sposobu klikania w systemy.
• BPM i integracje – przejście z automatyzacji pojedynczych zadań do projektowania i wykonywania całych procesów end-to-end.
• Hiperautomatyzacja – zintegrowanie narzędzi: RPA, BPM, API, low-code i AI, do tego monitorowanie pracy procesów oraz ciągła optymalizacja.
• Agenci AI i orkiestracja – dodanie warstwy „rozumiejącej”, która potrafi dynamicznie łączyć te narzędzia w różnych konfiguracjach.

Na każdym etapie pojawia się pokusa, by „nowa fala” całkowicie wymazała poprzednią. W praktyce warstwy technologiczne nakładają się: makra wciąż żyją obok RPA, RPA obok BPM, a teraz dołącza do tego wszystko warstwa agentów.

Hiperautomatyzacja jako zdolność, nie produkt do kupienia

Hiperautomatyzacja jest często sprzedawana jako etykieta platformy („kup nas, będziesz mieć hiperautomatyzację”). Tymczasem w praktyce jest to zdolność organizacyjna: umiejętność łączenia narzędzi automatyzacyjnych tak, by przyspieszać procesy i redukować pracę ręczną, a nie mnożyć silosy technologiczne.

Taka zdolność opiera się na kilku fundamentach:

• Architektura danych i integracji – automatyzacja jest tak dobra, jak jakość i dostępność danych, do których ma dostęp. Bez tego nawet najbardziej zaawansowany agent AI będzie „zgadywał”.
• Jedno miejsce odpowiedzialności za proces – ktoś musi patrzeć na proces jako całość (od klienta do rozliczenia), a nie tylko na pojedynczy krok „w którym działa robot”.
• Repozytorium automatyzacji – wiedza o tym, co już jest zautomatyzowane, jakimi narzędziami i z jakim efektem (kto odpowiada, kto utrzymuje, jaki jest koszt).
• Wspólne standardy – sposób logowania, monitorowania, eskalacji błędów, nadawania uprawnień, niezależnie od tego, czy zadanie wykonuje robot RPA, workflow czy agent AI.

Bez tego hiperautomatyzacja kończy się „hipersprawnym chaosem”: wiele osobnych inicjatyw, brak spójności i rosnące koszty utrzymania.

Rola agentów AI w dojrzewaniu automatyzacji

Agenci AI nie tyle „zastępują” dotychczasowe narzędzia, co zmieniają sposób ich użycia. Zamiast projektować setki wąsko wyspecjalizowanych robotów, organizacje zaczynają budować:

• warstwę usług i API – pojedyncze, dobrze zdefiniowane operacje biznesowe („utwórz zgłoszenie reklamacyjne”, „pobierz listę faktur klienta”),
• zestawy narzędzi dla agentów – katalog operacji, z których agent może korzystać w różnych kombinacjach, w zależności od kontekstu sprawy,

Od „flowchartu” do decydowania w locie

Klasyczna automatyzacja procesów opiera się na z góry zdefiniowanych ścieżkach. Projektujemy diagram BPMN, piszemy reguły, konfigurujemy roboty, a potem walczymy z wyjątkami. Każde odstępstwo od ścieżki głównej kończy się eskalacją do człowieka albo kolejną iteracją projektu.

Agenci AI wprowadzają inną logikę: decyzje są podejmowane w czasie rzeczywistym, na podstawie kontekstu danej sprawy, danych historycznych i dostępnych narzędzi. Zamiast setek rozgałęzień „if–else”, powstaje zestaw:

• zasad twardych (compliance, limity, obowiązkowe kroki),
• narzędzi technicznych (API, roboty, zapytania do hurtowni danych),
• ram decyzyjnych dla agenta (jakie cele optymalizuje, czego mu nie wolno).

W praktyce oznacza to inny balans między projektowaniem procesu a projektowaniem przestrzeni decyzyjnej. Proces przestaje być przepływem „od A do Z”, a staje się zbiorem dozwolonych kroków, które agent może łączyć.

Dobry przykład to obsługa reklamacji: wcześniej projektowano osobne ścieżki dla 10–20 najczęstszych typów zgłoszeń. Dziś coraz częściej buduje się jedną warstwę agentową, która:

• rozumie kontekst opisu klienta,
• potrafi samodzielnie sięgnąć po dane z różnych systemów,
• zna zasady, które określają możliwe decyzje (uznać, odrzucić, poprosić o doprecyzowanie).

Robot RPA może być nadal użyty – ale jako wykonawca konkretnej operacji (np. zaksięguj korektę w starym systemie), a nie jako nośnik całej logiki procesu.

Nowe role w zespołach automatyzacji

Ewolucja od prostych robotów do agentów zmienia także skład zespołów. Sam zespół developerów RPA przestaje wystarczać. Obok klasycznych ról technicznych pojawiają się m.in.:

• projektant usług biznesowych – definiuje, jak ustandaryzować operacje biznesowe w postaci API lub akcji agenta („co dokładnie znaczy utwórz klienta w różnych systemach?”),
• architekt wiedzy i promptów – odpowiada za to, jak agent ma rozumieć pojęcia biznesowe, jak zadawać pytania o brakujące dane, jak tłumaczyć swoje decyzje,
• kuratorka procesów – patrzy na dane z monitoringu, wychwytuje nowe wzorce spraw, inicjuje zmiany w konfiguracji agenta lub w samych procesach.

Programiści RPA w takim środowisku często przesuwają się w stronę twórców narzędzi dla agentów: potrafią szybko „otulić” trudny system skryptem lub robotem, ale zamiast budować całe procesy, dostarczają dobrze zdefiniowane, idempotentne akcje.

Jeśli organizacja zatrzymuje się na poziomie „mamy zespół botów”, trudno jej wykorzystać pełny potencjał agentów. Kompetencje muszą obejmować proces, dane, UX pracownika i klienta, a nie tylko samo „klikanie” w systemy.

Automatyzacja jako produkt wewnętrzny

W dojrzałych firmach automatyzacje (w tym roboty i agenci) przestają być pojedynczymi projektami, a zaczynają być traktowane jak produkty wewnętrzne. To subtelna, ale kluczowa zmiana:

• mają właściciela po stronie biznesu,
• mają roadmapę rozwoju zamiast jednorazowego wdrożenia,
• są rozliczane z efektów (czas obsługi, liczba spraw na pracownika), a nie z liczby wdrożonych robotów.

Agenci AI przyspieszają tę transformację, bo są bliżej użytkownika końcowego. Rozmawiają z konsultantem lub klientem, podejmują decyzje w jego imieniu, więc łatwiej mierzyć ich wpływ na doświadczenie, NPS, liczbę błędów. W takim modelu pytanie „co wdrażamy: RPA czy agenta?” schodzi na drugi plan. Ważniejsze jest: „jakiego produktu potrzebują użytkownicy i jak go utrzymamy przez kolejne lata?”.

Praktyczne kryteria: kiedy RPA, kiedy agenci AI, a kiedy po prostu API

Trzy podstawowe pytania, zanim wybierzesz narzędzie

Wybór między RPA, agentem a bezpośrednią integracją zwykle da się sprowadzić do kilku kluczowych pytań:

1. Jak stabilne i dostępne są interfejsy systemów?
2. Jak bardzo zmienny i nieustrukturyzowany jest kontekst pracy?
3. Kto będzie realnym użytkownikiem rozwiązania i jak szybko ma powstać?

Odpowiedzi na nie prowadzą do bardziej konkretnych kryteriów. Zamiast debat ogólnych („RPA to przeszłość”, „AI wszystko załatwi”), da się podjąć decyzję na poziomie konkretnego procesu lub jego fragmentu.

Kiedy RPA ma przewagę

RPA wciąż jest racjonalnym wyborem w kilku powtarzalnych sytuacjach:

• Brak sensownego API – system legacy, dostawca nie planuje rozwoju, a organizacja nie ma wpływu na jego roadmapę. Potrzebna jest automatyzacja „po ekranie”, bo to jedyny dostępny interfejs.
• Stabilne, mało zmienne czynności – formularze się prawie nie zmieniają, dane są ustrukturyzowane, wyjątki są rzadkie, a proces jest dobrze opisany.
• Wysoki wolumen prostych zadań – bardzo dużo powtarzalnych operacji na ograniczonym zestawie ekranów, gdzie każda sekunda oszczędności przekłada się na realny zysk.
• Ścisły reżim audytowy – trzeba dokładnie odtworzyć kroki, jakie wykonywałby człowiek, z pełnym logiem akcji w interfejsie użytkownika (np. określone regulacje sektora finansowego lub publicznego).

W takich warunkach dokładanie warstwy agentowej bywa nadmiarem – zwiększa złożoność bez proporcjonalnej korzyści. Lepiej zbudować solidnego robota, dobrze go monitorować i po kilku latach zaplanować migrację do API, gdy system zostanie wymieniony.

Kiedy lepiej postawić na API i integrację

Jeśli tylko jest możliwość zbliżyć się do danych i funkcji systemu „od środka”, integracja API prawie zawsze będzie:

• stabilniejsza,
• łatwiejsza w testowaniu,
• tańsza w utrzymaniu w perspektywie kilku lat.

Sensowna przewaga pojawia się zwłaszcza wtedy, gdy:

• Systemy są pod naszą kontrolą – własne aplikacje, mikroserwisy, nowoczesne SaaS z dobrym wsparciem dla developerów.
• Istnieją już kluczowe API biznesowe – np. „złóż zamówienie”, „zaktualizuj dane klienta”, „sprawdź status płatności”. Dalsza automatyzacja to głównie kwestia orkiestracji.
• Potrzebna jest wysoka wydajność – tysiące operacji na minutę, bliski real-time, wymagania pod kątem SLA, które trudno spełnić botami.
• Planowana jest długoterminowa transformacja – w horyzoncie 3–5 lat i tak będziemy wymieniać systemy, budować hurtownię danych, porządkować architekturę.

W takim scenariuszu RPA może pojawić się jako rozwiązanie przejściowe, ale nie powinno być fundamentem. Lepiej poświęcić czas na ekspozycję kluczowych funkcji w postaci API, z których później skorzystają i workflow, i agenci AI.

Kiedy agenci AI wnoszą najwięcej wartości

Agenci definiują nową klasę zastosowań: tam, gdzie poziom zmienności i niepewności jest wysoki, a wcześniej jedyną opcją był człowiek „na froncie”. Typowe sytuacje:

• Dane nie są w pełni ustrukturyzowane – maile, opisy w zgłoszeniach, dokumenty tekstowe, częściowo wypełnione formularze. Trzeba zrozumieć intencję, wyciągnąć sens, doprecyzować brakujące informacje.
• Przebieg sprawy nie jest z góry znany – różne typy klientów, różne scenariusze, „dziwne przypadki”, które dziś i tak obsługuje doświadczony pracownik.
• Potrzebna jest interakcja w języku naturalnym – rozmowa z klientem lub z pracownikiem, wyjaśnienie decyzji, zaproponowanie kolejnych kroków.
• Proces zawiera wiele drobnych decyzji – każda z nich z osobna jest łatwa, ale ich kombinacje są zbyt liczne, by modelować je klasycznymi regułami.

W tych obszarach agent nie tylko „podmienia” człowieka w powtarzalnych czynnościach, ale także porządkuje chaos. Odczytuje kontekst, uzupełnia dane, wybiera odpowiednie narzędzia (API, robot, zapytanie SQL), a na końcu tłumaczy rezultat.

Odpowiednia architektura pozwala wtedy zachować prostotę na poziomie technicznym: agenci korzystają z tych samych usług i robotów, których używają inni klienci wewnętrzni (np. portale samoobsługowe), tylko w bardziej elastycznych kombinacjach.

Matryca decyzyjna: stabilność vs niepewność

Pomaga prosta matryca dwóch wymiarów:

• Stabilność interfejsów (UI/API): od „ciągle się zmienia” do „stabilne od lat”.
• Niepewność kontekstu: od „zawsze tak samo” do „zależy od klienta, kanału, historii”.

Jeśli:

• interfejs jest stabilny, a kontekst powtarzalny – RPA/UI lub czyste API będą efektywne,
• interfejs jest stabilny, ale kontekst zmienny – API + agent to najczęstsza kombinacja (agent decyduje, API wykonuje),
• interfejs jest niestabilny, a kontekst prosty – najpierw walka o API; jeśli to nierealne, to RPA z dobrze zorganizowanym utrzymaniem,
• interfejs jest niestabilny, a kontekst zmienny – projekt transformacyjny, a nie lokalna automatyzacja; bez zmian w systemach i procesach każdy wybór będzie kosztowny.

Taka matryca nie zastąpi analizy szczegółowej, ale szybko ujawnia, czy dyskusja dotyczy rzeczywiście wyboru narzędzia, czy raczej próby zamaskowania głębszych problemów architektonicznych.

Typowe antywzorce i pułapki

W praktyce wiele problemów z „umierającym RPA” lub „rozczarowaniem agentami AI” wynika nie tyle z technologii, co z kilku powtarzalnych antywzorców:

• RPA jako proteza na wszystko – roboty budowane tam, gdzie rozsądniej byłoby negocjować zmiany u dostawcy systemu lub inwestować w integracje API.
• Agenci bez narzędzi – wdrożenie warstwy LLM bez dostępu do danych i bez bezpiecznych akcji, które agent może wykonać. Efekt: „inteligentny” chat, który trochę lepiej odpowiada na pytania, ale nie skraca procesu.
• Brak odpowiedzialności za całość procesu – automatyzacja klei tylko pojedynczy krok, bez wpływu na resztę. Agregacja takich „wysepek” po kilku latach tworzy trudny do zarządzania krajobraz.
• Mylenie PoC z produkcją – zachwyt po pierwszych demonstracjach agenta, a potem szok, gdy trzeba zadbać o monitoring, wersjonowanie promptów, zarządzanie uprawnieniami.

Unikanie tych pułapek wymaga bardziej świadomego podejścia do wyboru narzędzi. RPA, API i agenci AI nie konkurują ze sobą wprost – raczej uzupełniają się, jeśli od początku projektuje się proces z myślą o ich współdziałaniu.

Przykład rozbicia jednego procesu na różne technologie

Dobrym testem dojrzałości jest umiejętność „rozwarstwienia” jednego procesu na fragmenty, które obsłużą różne narzędzia. Przykładowo, proces obsługi nowego kontraktu w B2B może wyglądać tak:

• Agent AI prowadzi konwersację z handlowcem, pomaga uzupełnić brakujące dane, analizuje maile z klientem, sugeruje warianty umowy.
• Workflow BPM uruchamia sekwencję kroków akceptacyjnych (compliance, ryzyko, finanse) i pilnuje SLA.
• API CRM/ERP tworzą rekordy ofert, klientów i kontraktów w systemach źródłowych.
• Robot RPA uzupełnia dane w dwóch starych aplikacjach, dla których nie ma innego interfejsu, generuje i wysyła określone zestawienia.

Dla użytkownika końcowego kluczowe jest, żeby całość działała spójnie. Jaką część pracy wykonał robot, a jaką agent – to kwestia architektury i kosztów utrzymania, nie cel sam w sobie.

Jak przygotować organizację na wspólną przyszłość RPA i agentów

Zamiast spekulować, czy „RPA umrze”, rozsądniej jest przygotować się na scenariusz, w którym różne generacje automatyzacji współistnieją. Kilka praktycznych kroków:

Najczęściej zadawane pytania (FAQ)

Czy RPA naprawdę „umiera” przez generatywną AI i agentów AI?

RPA nie tyle „umiera”, co traci rolę głównego narzędzia automatyzacji biurowej. Generatywna AI i agenci AI przejmują coraz większą część zadań wymagających rozumienia treści, interpretacji kontekstu i pracy na nieustrukturyzowanych danych, gdzie klasyczne roboty klikalne sobie nie radziły.

RPA przesuwa się raczej do roli technologii uzupełniającej – „ostatniej mili” tam, gdzie nie ma API, systemy są stare albo zmiany w nich są zbyt kosztowne. W wielu organizacjach nadal będzie działać, ale nie jako pierwszy wybór przy nowych inicjatywach automatyzacyjnych.

Jaka jest różnica między klasycznym RPA a agentami AI?

Klasyczne RPA to deterministyczne roboty softwarowe odtwarzające kroki użytkownika w interfejsie: kliknięcia, kopiowanie danych, wypełnianie formularzy. Działają na jasno zdefiniowanych regułach i są mocno zależne od layoutu ekranu. Nie „rozumieją” kontekstu biznesowego ani treści dokumentów.

Agenci AI opierają się na dużych modelach językowych. Potrafią interpretować treść maili i dokumentów, wyciągać z nich dane, klasyfikować zgłoszenia i proponować kolejne kroki procesu. Często komunikują się z użytkownikiem w języku naturalnym i korzystają z API systemów zamiast z ich interfejsu graficznego.

Kiedy nadal opłaca się inwestować w RPA, a kiedy lepiej postawić na AI i API?

RPA ma sens tam, gdzie proces jest stabilny, powtarzalny, oparty na ustrukturyzowanych danych, a kluczowe systemy nie mają wygodnych API (lub ich modernizacja jest odłożona w czasie). Przykład: przenoszenie danych między starym systemem księgowym a aplikacją dostawcy, który nie udostępnia integracji.

Jeśli jednak proces często się zmienia, ma wiele wyjątków, a dane wejściowe to głównie maile, pliki PDF czy skany, lepiej od razu projektować rozwiązanie oparte o API, workflow i agentów AI. Wtedy RPA szybko zamieniłoby się w kosztowną w utrzymaniu „łatę”.

Jak może wyglądać współpraca RPA z generatywną AI w jednym procesie?

Typowy scenariusz to podział ról: AI zajmuje się „rozumieniem”, a RPA „klikaniem”. Przykład: model językowy czyta przychodzące maile, klasyfikuje je, wyciąga dane (numery faktur, kwoty, daty), a następnie przygotowuje ustrukturyzowane zlecenie dla robota. Robot loguje się do systemów i wykonuje konkretne operacje.

W takim układzie nie trzeba od razu przepisywać wszystkich botów. Część z nich można „otoczyć” AI – dołożyć inteligentne rozpoznawanie treści na wejściu i bardziej elastyczne podejmowanie decyzji, zostawiając RPA jako technologię egzekucji kroków w systemach.

Jaką strategię powinien przyjąć CIO wobec istniejącej floty robotów RPA?

W praktyce potrzebne są trzy równoległe działania: inwentaryzacja parku robotów (które procesy są krytyczne, które są „łatami”), wskazanie automatyzacji do wygaszania w perspektywie 3–5 lat oraz zdefiniowanie, gdzie RPA ma zostać jako komponent „ostatniej mili”. Bez takiego mapowania łatwo wpaść w spiralę rosnących kosztów utrzymania.

Następny krok to przesunięcie nowych budżetów rozwojowych z rozbudowy floty botów w stronę architektury API-first, narzędzi integracyjnych, platform low-code i agentów AI. RPA nie znika, ale przestaje być centrum strategii – staje się jednym z narzędzi, a nie fundamentem całego krajobrazu automatyzacji.

Jakie kompetencje w zespołach automatyzacji będą kluczowe w erze agentów AI?

Rola klasycznego „twórcy botów” będzie stopniowo maleć na rzecz kompetencji bardziej architektonicznych i procesowych. Coraz większe znaczenie mają: analiza i projektowanie procesów end-to-end, projektowanie integracji API, orkiestracja agentów AI oraz łączenie tych elementów z istniejącymi robotami.

Równolegle rośnie zapotrzebowanie na kompetencje governance: zarządzanie ryzykiem AI, kontrola jakości modeli, bezpieczeństwo danych. Bez tych umiejętności organizacja łatwo tworzy nową warstwę technologicznego długu – tym razem nie w RPA, ale w źle zarządzanych zastosowaniach sztucznej inteligencji.

Jak rozpoznać, że nasze obecne RPA stało się „legacy”, od którego trzeba planować odejście?

Sygnalizatorów jest kilka: rosnący koszt utrzymania botów przy każdej zmianie UI, duża liczba wyjątków i „ręcznych obejść”, trudność w audytowaniu tego, co robot faktycznie robi, oraz blokowanie inicjatyw integracyjnych, bo „przecież już mamy RPA”. Jeśli przy każdej zmianie systemu trzeba aktualizować dziesiątki skryptów, to znak, że rozwiązanie weszło w fazę legacy.

W takiej sytuacji warto oznaczyć te automatyzacje jako „RPA-as-legacy”, zdefiniować plan migracji na integracje API i agentów AI oraz nie rozwijać ich dalej, poza krytycznymi poprawkami. Równolegle można wykorzystywać nowe wdrożenia AI jako okazję do stopniowego wygaszania najbardziej kłopotliwych botów.

Najważniejsze wnioski

• RPA nie „umiera”, ale traci rolę głównego narzędzia automatyzacji; coraz częściej staje się komponentem „ostatniej mili” tam, gdzie brakuje API lub modernizacja systemów jest zbyt kosztowna.
• Generatywna AI i LLM przesuwają ciężar z automatyzacji kroków („kliknij tu, skopiuj tam”) na automatyzację wyniku – system ma zrozumieć intencję i sam dobrać sekwencję działań, np. odczytać maila, wyciągnąć dane i zaproponować kolejne kroki.
• W organizacjach ścierają się dwa podejścia: konserwatywne (utrzymać i łatać istniejące roboty) oraz ofensywne (stopniowo przepisywać procesy na AI i integracje API); realna strategia zwykle łączy oba kierunki i rozkłada zmiany na 3–5 lat.
• Kluczowym zadaniem CIO/COO jest określenie, jaka część obecnego parku RPA staje się „RPA-as-legacy” i wymaga planu wygaszania, a gdzie roboty można otoczyć AI (np. AI rozumie dokumenty, RPA wykonuje operacje w starym systemie).
• Decyzje budżetowe przesuwają się od prostego „dokupmy boty” w stronę inwestycji w API-first, modernizację systemów core oraz wdrożenia agentów AI, które umożliwiają automatyzację procesów end-to-end.
• Zmienia się profil kompetencji: samo „klikanie botów” przestaje wystarczać, rośnie zapotrzebowanie na analityków procesów, architektów integracji i osoby potrafiące orkiestrwać współpracę RPA, workflow, API i agentów AI.