RPA, API czy AI - jak wybrać sposób automatyzacji procesu

Automatyzację można zbudować na trzy sposoby: przez API, czyli rozmowę programów bezpośrednio ze sobą, przez RPA, czyli robota klikającego w interfejs tak jak człowiek, albo przez AI, czyli model, który rozumie tekst i dokumenty. Każdy z nich jest dobry do czegoś innego, a wybór złego sposobu to najczęstsza przyczyna automatyzacji, która działa w pokazie, a psuje się w drugim miesiącu.

Ten tekst jest dla osoby, która dostała trzy oferty na „automatyzację” i nie wie, czym się różnią. Bez żargonu: jak działa każdy sposób, kiedy się sprawdza, gdzie pęka i jak je łączyć.

Trzy sposoby w jednej tabeli

API: pierwszy wybór, jeśli tylko jest

Jeśli system udostępnia API, automatyzacja przez API jest szybsza, stabilniejsza i tańsza w utrzymaniu niż jakakolwiek inna. Program dostaje dane w ustalonym formacie, więc nie obchodzi go, jak wygląda ekran, w jakim kolorze jest przycisk ani czy okno ładuje się sekundę dłużej.

Dwie rzeczy, o które warto zapytać, zanim uzna się sprawę za prostą:

• Czy dostęp do API jest w Twojej licencji. W wielu polskich programach handlowych i księgowych to osobno płatny moduł albo wyższy wariant. Przykładowo w Subiekcie GT potrzebna jest Sfera, a w linii nexo dopiero wersja nexo PRO. Rozpisuję to w tekście o integracji sklepu z ERP.
• Co API faktycznie udostępnia. Czasem da się odczytać zamówienia, ale nie da się zmienić ich statusu. Lepiej sprawdzić to na liście operacji w dokumentacji niż w trzecim tygodniu wdrożenia.

Do łączenia systemów przez API najczęściej używam n8n stawianego na serwerze klienta, a przy bardziej złożonej logice kodu w Pythonie albo TypeScripcie. Różnice między narzędziami opisuję w porównaniu n8n, Make i Zapiera.

RPA: gdy nie ma innej drogi

RPA to robot, który obsługuje program przez jego ekran: klika, wpisuje, kopiuje. Ma jedną ogromną zaletę: działa z każdym programem, także z tym sprzed dwudziestu lat, którego nikt nie odważy się ruszyć. I jedną ogromną wadę: jest tak kruchy jak interfejs, na którym pracuje.

Robot nie wie, że przycisk „Zapisz” przesunął się po aktualizacji o dwa centymetry. Nie wie, że dziś pojawiło się okno z komunikatem o licencji. Nie wie, że program odpowiada wolniej, bo serwer jest przeciążony. W każdej z tych sytuacji staje albo, co gorsze, klika w złe miejsce.

Kiedy RPA ma sens:

• system nie ma API i nie będzie go miał,
• interfejs zmienia się rzadko, bo program jest stary albo wewnętrzny,
• proces jest powtarzalny i ma niewiele wyjątków,
• ktoś będzie pilnował, czy robot nadal działa, i poprawi go po zmianie w programie.

Często lepszą alternatywą dla RPA jest eksport do pliku. Jeśli stary system potrafi codziennie zapisywać raport do CSV, automatyzacja czyta ten plik i nie musi klikać w ekran. To mniej efektowne, ale działa latami.

AI: do danych, które nie mają stałego układu

Model językowy jest dobry tam, gdzie informacja jest w tekście napisanym przez człowieka, a nie w polu formularza. Zamówienie przysłane mailem w pięciu różnych formatach, specyfikacja w PDF, zdjęcie tabliczki znamionowej, opis reklamacji.

Zasada, której się trzymam: AI wyciąga i proponuje, reguły sprawdzają, człowiek zatwierdza to, co nieodwracalne. Model odczytuje z maila pozycje zamówienia, reguły sprawdzają, czy takie indeksy istnieją w katalogu i czy ilości mają sens, a człowiek zatwierdza zamówienie jednym kliknięciem. Tam, gdzie liczba musi się zgadzać co do grosza, liczy kalkulator, a nie model. Więcej o granicach tego podejścia piszę w tekście o tym, co agenci AI naprawdę potrafią.

W praktyce najlepiej działa połączenie

Większość prawdziwych procesów używa dwóch albo trzech sposobów naraz, każdego w miejscu, do którego pasuje. Przykład obiegu zamówienia od kontrahenta, który przysyła je mailem w PDF:

1. API poczty: nowa wiadomość z załącznikiem trafia do procesu.
2. AI: model odczytuje z PDF indeksy, ilości i termin dostawy.
3. Reguły: sprawdzenie, czy indeksy istnieją, czy ceny zgadzają się z cennikiem kontrahenta, czy ilości są w rozsądnym zakresie.
4. Człowiek: zatwierdza zamówienie albo poprawia to, co reguły oznaczyły.
5. API systemu handlowego: zamówienie trafia do programu bez przepisywania.
6. RPA tylko w ostateczności: jeśli system handlowy nie ma API, robot wpisuje zamówienie przez ekran, a proces pilnuje, czy się udało.

Trzy przykłady z projektów, które zbudowałem

Każdy z trzech sposobów ma swoje miejsce także w moich wdrożeniach. Opisy całych projektów są na stronie z realizacjami, tutaj tylko to, który sposób gdzie pracuje i dlaczego.

• Portal sprzedaży maszyn używanych: API. Aplikacja dla handlowców przekazuje ogłoszenia do WordPressa przez REST API i własną wtyczkę pośredniczącą z kolejką żądań. Żadnego klikania w panel, a gdy WordPress chwilowo nie odpowiada, żądanie czeka w kolejce, zamiast zginąć.
• Autopilot treści: AI plus API. Model przygotowuje treść postów z transkrypcji filmu albo artykułu, bo to jest tekst bez stałego układu. Publikacja na czterech platformach idzie już przez ich API, a między jednym a drugim stoi bramka akceptacji przez człowieka.
• Monitor ogłoszeń z ponad dziesięciu portali: pobieranie stron. Większość portali ogłoszeniowych nie udostępnia API do wyszukiwania, więc dane pobiera się z tego, co widzi przeglądarka. To najbardziej kruchy element całego systemu, a przy okazji ten, przy którym trzeba najuważniej sprawdzić, co wolno pobierać. Dlatego ma własne powiadomienia, gdy któryś portal przestanie zwracać wyniki.

Krótki słownik, żeby rozumieć oferty

• API: udostępnione przez system wejście, przez które inne programy mogą pobierać i zapisywać dane.
• Webhook: powiadomienie, które system sam wysyła, gdy coś się wydarzy, na przykład „nowe zamówienie”. Szybsze i tańsze niż ciągłe dopytywanie.
• Odpytywanie (polling): automatyzacja co kilka minut sprawdza, czy coś się zmieniło. Prostsze, ale z opóźnieniem i większą liczbą zapytań.
• Token albo klucz API: hasło dla programu. Trzymane w zmiennych środowiskowych, nigdy w arkuszu ani w mailu.
• Limit zapytań: maksymalna liczba zapytań, jaką system przyjmie w danym czasie. Dobrze zbudowana automatyzacja go respektuje i ponawia próbę później.

Pięć pytań przed wyborem

1. Czy system ma API i czy mam je w licencji? Jeśli tak, zaczynasz od API.
2. Czy da się dostać eksport do pliku? Często to prostsza droga niż RPA.
3. Czy dane mają stały układ? Jeśli tak, AI nie jest potrzebne.
4. Co się stanie przy błędzie? Jeśli skutkiem jest zła faktura albo przelew, człowiek zostaje w pętli.
5. Kto będzie to utrzymywał? RPA i integracje z zewnętrznymi systemami wymagają kogoś, kto zareaguje, gdy druga strona coś zmieni.

Koszt utrzymania jest różny, choć rzadko się o tym mówi

Przy porównywaniu ofert łatwo patrzeć na cenę wdrożenia, a przegapić to, ile kosztuje utrzymanie przez kolejne dwa lata.

• API psuje się rzadko, zwykle przy zmianie wersji zapowiedzianej przez dostawcę z wyprzedzeniem.
• RPA psuje się przy każdej zmianie interfejsu, często bez zapowiedzi, i to jest koszt, który wraca.
• AI kosztuje przy każdym wywołaniu modelu, więc koszt rośnie razem z liczbą dokumentów, a modele i ich ceny zmieniają się co kilka miesięcy.

Jak policzyć, czy całość się zwraca, opisuję w tekście o tym, ile kosztuje automatyzacja procesu.

FAQ - RPA, API czy AI

Co to jest RPA?

RPA, czyli robotyzacja procesów, to oprogramowanie, które obsługuje inne programy przez ich ekran tak jak człowiek: klika, wpisuje i kopiuje dane. Działa z systemami bez API, ale jest wrażliwe na każdą zmianę wyglądu programu.

Czym się różni integracja przez API od RPA?

Przez API programy wymieniają dane bezpośrednio, w ustalonym formacie, więc wygląd ekranu nie ma znaczenia. RPA udaje człowieka przed ekranem, więc psuje się, gdy ekran się zmieni. Jeśli API jest dostępne, prawie zawsze jest lepszym wyborem.

Kiedy warto użyć AI w automatyzacji?

Gdy dane są w tekście bez stałego układu: w mailach, w PDF-ach od różnych kontrahentów, na zdjęciach. Wynik AI warto zawsze sprawdzić regułami, a kroki nieodwracalne zostawić do zatwierdzenia człowiekowi.

Czy AI zastąpi RPA?

Częściowo. Model potrafi rozpoznać ekran i dostosować się do drobnych zmian, co zmniejsza kruchość, ale każde wywołanie kosztuje i nie jest w pełni przewidywalne. Tam, gdzie jest API, obie te drogi przegrywają z bezpośrednią integracją.

Mój program nie ma API. Co robić?

Najpierw sprawdź, czy potrafi eksportować dane do pliku albo czy ma wyższą wersję z API. Eksport czytany przez automatyzację jest zwykle stabilniejszy niż robot klikający w ekran. RPA zostaje na koniec, gdy innej drogi nie ma.

Czy do tego potrzebny jest programista?

Proste połączenia przez API da się zbudować w narzędziach typu n8n bez pisania kodu. Przy wielu wyjątkach, RPA i procesach, od których zależą pieniądze, przydaje się ktoś, kto zadba o obsługę błędów, logi i powiadomienia.

Podsumowanie

API to pierwszy wybór zawsze, gdy system je ma i dostęp jest w licencji. RPA to wyjście awaryjne dla programów bez API, kruche przy każdej zmianie ekranu. AI to narzędzie do danych bez stałego układu, zawsze z regułami i człowiekiem przy krokach nieodwracalnych.

Najlepsze wdrożenia łączą te sposoby: AI odczytuje dokument, reguły go sprawdzają, człowiek zatwierdza, a API przenosi dane do systemu.

Porównując oferty, pytaj nie tylko o cenę wdrożenia, ale o to, co się stanie, gdy druga strona zmieni ekran albo API. Odpowiedź na to pytanie mówi o ofercie więcej niż cena.