Agenci przeglądarkowi AI w firmie: gdzie się kończą w 2025 (i dlaczego czasem lepszy jest zwykły workflow)

Od kilku miesięcy testujemy w Ententrze narzędzia typu OpenAI Operator i Claude Computer Use w realnych zadaniach klientów. Wniosek jest prosty i pewnie nie taki, jakiego oczekuje marketing tych produktów: do procesów transakcyjnych w polskiej firmie te narzędzia jeszcze się nie nadają. Nadają się za to świetnie do researchu, monitoringu konkurencji i zadań, w których błąd kosztuje pięć minut na poprawkę, a nie utratę pieniędzy klienta.

Czym w ogóle są agenci przeglądarkowi i skąd ten szum

OpenAI Operator pojawił się jako research preview pod koniec stycznia 2025 roku, początkowo dostępny wyłącznie dla użytkowników planu ChatGPT Pro (najdroższego, kosztującego wtedy 200 dolarów miesięcznie) i tylko na terenie USA. Anthropic poszedł inną drogą: Computer Use zaprezentował już w październiku 2024 roku jako funkcję API dla modelu Claude 3.5 Sonnet. To nie jest gotowa aplikacja dla użytkownika biznesowego, tylko zestaw możliwości dla programistów, którzy chcą sami zbudować agenta robiącego zrzuty ekranu, poruszającego kursorem i klikającego elementy interfejsu.

Zasada działania jest w obu przypadkach podobna. Agent widzi ekran (albo jego zrzut), na tej podstawie decyduje, gdzie kliknąć, co wpisać, dokąd przewinąć stronę, i wykonuje tę akcję jak człowiek trzymający mysz. To odróżnia go od klasycznej automatyzacji RPA czy integracji przez API, gdzie system komunikuje się z inną aplikacją bezpośrednio, bez „patrzenia" na interfejs. Dla wielu osób to brzmi jak ostateczne rozwiązanie: skoro agent widzi to samo co człowiek, to teoretycznie może zrobić wszystko, co robi pracownik przy komputerze. W praktyce jest to najwolniejszy, najdroższy i najmniej przewidywalny sposób automatyzacji, jaki obecnie mamy do dyspozycji, i sięgamy po niego dopiero wtedy, gdy nie ma lepszej opcji.

Gdzie te narzędzia rzeczywiście sprawdzają się w pracy

Najlepsze wyniki mieliśmy tam, gdzie zadanie jest jednorazowe albo rzadkie, dotyczy publicznie dostępnych informacji i nie wymaga logowania się na konta z uprawnieniami. Konkretnie:

• Monitoring cen i oferty konkurencji na stronach, które nie udostępniają API ani kanału eksportu danych.
• Wstępny research rynku przed rozmową handlową: agent potrafi przejrzeć kilkanaście stron branżowych i wyciągnąć podsumowanie, kto co oferuje i w jakich widełkach cenowych.
• Sprawdzanie dostępności produktu w wielu sklepach naraz, gdy nie zależy nam na wyniku co do sekundy.
• Testy użyteczności własnej strony: agent klikający jak przeciętny użytkownik potrafi wyłapać, gdzie proces zakupowy się zacina.

We wszystkich tych przypadkach błąd agenta jest tani. Jeśli źle odczyta cenę konkurenta albo pominie jedną stronę, ktoś to zweryfikuje ręcznie w pięć minut. Nikt nie traci na tym pieniędzy klienta, nie wysyła błędnej faktury i nie loguje się przypadkiem na cudze konto.

Gdzie kończą się możliwości: logowania, 2FA, captcha

Tu zaczyna się rzeczywistość, która różni się od demówek pokazywanych na konferencjach. Trzy bariery pojawiają się praktycznie za każdym razem, gdy próbujemy przenieść agenta przeglądarkowego do procesu, który ma realną wartość biznesową.

Captcha i zabezpieczenia anty-botowe. Większość systemów księgowych, bankowości elektronicznej, platform B2B czy portali urzędowych ma dziś jakąś formę weryfikacji, że po drugiej stronie siedzi człowiek. Agent AI albo się na tym zatrzymuje, albo próbuje ją obejść, co samo w sobie bywa niezgodne z regulaminem danej usługi.

Uwierzytelnianie dwuskładnikowe. Kod SMS, powiadomienie push w aplikacji, klucz sprzętowy: to wszystko wymaga akcji człowieka w innym kanale niż przeglądarka. Agent może kliknąć „zaloguj", ale na kodzie z telefonu utknie, chyba że zbudujemy dla niego dodatkowy most integracyjny, co w praktyce oznacza tyle samo pracy, co zbudowanie normalnej integracji od razu.

Specyfika polskich stron. Wiele lokalnych systemów (mniejsze sklepy internetowe, panele dostawców, systemy ERP używane w małych i średnich firmach) ma interfejsy, które zmieniają się rzadko, ale nietypowo: inne układy tabel, PDF-y generowane w locie, formularze z walidacją JavaScript, która różni się od tego, na czym trenowano model. Agenci przeglądarkowi radzą sobie najlepiej na dużych, popularnych serwisach anglojęzycznych. Na mniejszej polskiej stronie księgowej czy sklepie B2B skuteczność potrafi spaść z deklarowanych w materiałach marketingowych kilkudziesięciu procent do poziomu, który nie usprawiedliwia kosztu.

Agent przeglądarkowy kontra zwykły workflow: nasze porównanie z wdrożeń

W kilku projektach mieliśmy dokładnie ten sam problem do rozwiązania dwoma sposobami: agentem klikającym po stronie i klasycznym workflow zbudowanym w n8n albo Make, korzystającym z API tam, gdzie było dostępne, albo z parsowania strony w sposób deterministyczny tam, gdzie API nie było. Wynik był powtarzalny.

Klasyczny przykład: firma handlowa, która chciała codziennie sprawdzać ceny 200 produktów u trzech konkurentów i aktualizować własny cennik. Agent przeglądarkowy teoretycznie umiał to zrobić, ale przy 200 produktach dziennie proces trwał godzinami, generował błędy odczytu na promocjach i cenach przekreślonych, i kosztował więcej niż etat stażysty. Workflow oparty o scraping strukturalny i harmonogram wykonywał to samo w kilkanaście minut, stabilnie, każdego dnia o tej samej porze, z powiadomieniem na Slacku, jeśli coś się nie zgadzało. To nie jest wyjątek, to reguła, którą widzimy w większości projektów: tam, gdzie proces jest powtarzalny i ma jasną strukturę, deterministyczna automatyzacja wygrywa z agentem AI niemal zawsze.

Podobnie wygląda to w księgowości i fakturowaniu. Jeśli ktoś w firmie codziennie loguje się do kilku portali dostawców, żeby pobrać faktury i wprowadzić je ręcznie do systemu, kuszące jest, żeby zlecić to agentowi AI, bo „przecież on też może się zalogować i kliknąć pobierz". W praktyce to proces z logowaniem, czasem z 2FA, z danymi finansowymi i z zerową tolerancją na pomyłkę w kwocie czy numerze NIP. Tu zdecydowanie polecamy podejście integracyjne, opisane szerzej przy okazji automatyzacji faktur: połączenie ze skrzynką mailową, OCR i workflow, który sam kategoryzuje i księguje dokumenty, z jasną ścieżką eskalacji do człowieka przy wyjątkach. To rozwiązanie jest przewidywalne, ma logi i nie zgaduje, gdzie kliknąć.

RODO: automatyczne przeglądanie stron z danymi klientów to nie teoria

Ten temat jest często pomijany w entuzjastycznych recenzjach nowych narzędzi, a w polskiej firmie to pierwsze pytanie, jakie powinno paść. Jeśli agent przeglądarkowy ma logować się do systemu, w którym widoczne są dane osobowe klientów (panel CRM, system zamówień, portal dostawcy z danymi kontaktowymi), to te dane w praktyce trafiają do modelu działającego u zewnętrznego dostawcy, najczęściej na serwerach poza Unią Europejską. To rodzi konkretne pytania: czy mamy podstawę prawną do takiego przetwarzania, czy dostawca oferuje umowę powierzenia przetwarzania danych (DPA) na warunkach zgodnych z RODO, jak długo dane są przechowywane po stronie usługodawcy i czy mogą zostać wykorzystane do dalszego trenowania modeli.

Nasza zasada w projektach klienckich jest prosta: agent przeglądarkowy owszem, ale wyłącznie na danych publicznych albo zanonimizowanych. Do jakiegokolwiek procesu, w którym w polu widocznym dla agenta pojawiają się dane klienta, nie podchodzimy tym narzędziem, dopóki dostawca nie da jasnych gwarancji kontraktowych. To samo dotyczy zresztą obsługi klienta: jeśli agent ma czytać zgłoszenia z ticketów albo maile, w których są dane osobowe, konfiguracja musi być świadoma i udokumentowana, a nie „bo działa". Więcej o tym, jak podchodzimy do automatyzacji w kontakcie z klientem przy zachowaniu tych zasad, opisujemy przy automatyzacji obsługi klienta.

Kiedy mimo wszystko warto rozważyć agenta przeglądarkowego

Nie jesteśmy przeciwnikami tych narzędzi, tylko przeciwnikami stosowania ich tam, gdzie się nie sprawdzają. Są sytuacje, w których to dziś najlepsza dostępna opcja. Jeśli strona, z której trzeba pobrać dane, nie ma API, zmienia strukturę zbyt często, żeby opłacało się budować dedykowany scraper, a zadanie i tak wykonuje raz na jakiś czas jedna osoba z zespołu marketingu czy sprzedaży, to agent przeglądarkowy oszczędza jej czas bez potrzeby angażowania programisty. Podobnie w researchu konkurencyjnym pod kampanie marketingowe: agent potrafi w rozsądnym czasie zebrać obraz tego, co robią inni gracze na rynku, jakich haseł używają, jak wygląda ich lejek sprzedażowy. To dobre wsparcie przy planowaniu działań opisywanych przy automatyzacji marketingu, choć i tam ostateczną decyzję zostawiamy człowiekowi, agent dostarcza materiał, nie podejmuje strategii.

Traktujemy to narzędzie jako dodatek do zestawu, nie jako zamiennik integracji. Zanim sięgniemy po agenta klikającego w przeglądarce, zawsze sprawdzamy, czy dany serwis ma API, czy da się pobrać dane przez eksport, czy istnieje gotowa integracja w n8n albo Make. Dopiero gdy żadna z tych opcji nie istnieje, a zadanie nie jest krytyczne dla działania firmy, wchodzi agent AI.