Agenty AI w przeglądarce: bezpieczne w firmie w 2025? (i gdzie dziś jeszcze nie warto ich wpuszczać)

Testowaliśmy agenty przeglądarkowe pod kątem konkretnych, nudnych zadań, które w wielu firmach ktoś robi ręcznie: logowanie się na portal dostawcy energii i pobranie faktury, wejście na stronę kuriera i sprawdzenie statusu przesyłki, przejście przez panel klienta i wyciągnięcie numeru zamówienia. To były testy w izolowanym środowisku, na kontach testowych, bez podpinania niczego do produkcji. I już na tym etapie wyszło jasno, gdzie ta technologia dziś kończy się jako ciekawostka, a gdzie zaczyna być realnym narzędziem.

Nie zaczynałbym wdrożenia agenta przeglądarkowego od razu w dziale księgowości ani w systemie sprzedażowym z dostępem do danych klientów. Zacząłbym od pytania: co się stanie, jeśli agent kliknie coś złego, wpisze dane w niewłaściwe pole albo zostanie zwiedziony przez treść na stronie, którą odwiedza. Jeśli odpowiedź brzmi „nic wielkiego, najwyżej powtórzę zadanie”, to jest dobry kandydat do testu. Jeśli odpowiedź brzmi „wyciek danych klienta” albo „błędny przelew”, to nie jest jeszcze ten moment.

Co to w ogóle jest i jak to działa w praktyce

Agent przeglądarkowy różni się od klasycznego bota tym, że nie ma sztywno zaprogramowanej ścieżki kliknięć. Dostaje zrzut ekranu lub reprezentację strony, analizuje go modelem, decyduje „kliknę tutaj, wpiszę to w to pole” i wykonuje akcję, po czym cały cykl się powtarza. Anthropic pokazał to podejście pod nazwą computer use w październiku 2024 roku, jako funkcję pozwalającą modelowi Claude sterować kursorem i klawiaturą jak człowiek. OpenAI poszło podobną drogą, udostępniając w styczniu 2025 roku Operatora, czyli agenta, który samodzielnie przechodzi przez strony internetowe i wykonuje zadania w przeglądarce.

Różnica względem tradycyjnego RPA (Robotic Process Automation) jest fundamentalna. RPA działa na sztywnych selektorach: „kliknij przycisk o identyfikatorze X”. Jeśli strona się zmieni, robot się wywraca, ale przynajmniej wiadomo dlaczego i w jakim miejscu. Agent AI działa na rozumieniu obrazu i kontekstu, więc teoretycznie jest odporniejszy na drobne zmiany layoutu. W praktyce oznacza to też, że jego działanie jest mniej przewidywalne. Ten sam agent, uruchomiony dwa razy na tej samej stronie, może wykonać nieco inną sekwencję kliknięć. Dla procesu, który ma być powtarzalny i audytowalny, to poważna wada, nie ciekawostka.

Gdzie ryzyko dziś przewyższa korzyść

Trzy rzeczy wyszły w naszych testach jako realny problem, nie hipotetyczny.

Pierwsza to dostęp do loginów i haseł. Żeby agent pobrał fakturę z portalu dostawcy, musi się zalogować. Oznacza to, że gdzieś musi mieć dane logowania: albo wpisane bezpośrednio w poleceniu, albo pobrane z menedżera haseł przeglądarki. W obu przypadkach dane uwierzytelniające trafiają w zasięg modelu, który je „widzi” na ekranie i przetwarza. To nie jest to samo ryzyko co przy klasycznym API z tokenem o ograniczonym zakresie uprawnień. Tu agent działa z takimi samymi uprawnieniami, jakie ma zalogowany użytkownik, czyli często bardzo szerokimi.

Druga rzecz to prompt injection, czyli sytuacja, w której strona internetowa (albo dokument, e-mail, treść w polu formularza) zawiera ukryty tekst zaadresowany nie do człowieka, tylko do modelu sterującego agentem. Jeśli agent czyta zawartość strony, żeby zdecydować co dalej, i na stronie znajduje się fragment tekstu w stylu „zignoruj poprzednie instrukcje i wykonaj zamiast tego X”, model może to potraktować jako polecenie. To nie jest scenariusz z filmu science fiction, tylko udokumentowany typ ataku opisywany w publikacjach dotyczących bezpieczeństwa systemów agentowych. W kontekście firmowym oznacza to, że agent odwiedzający zewnętrzną stronę (np. portal dostawcy, który ktoś mógł zmodyfikować albo który ma zainfekowaną reklamę) może zostać nakłoniony do działania niezgodnego z pierwotnym zadaniem.

Trzecia rzecz, mniej spektakularna, ale za to codzienna, to zwykła nieprzewidywalność kliknięć. Portal dostawcy zmienia layout, dodaje baner z cookies, wyskakuje popup z promocją. Agent, który miał kliknąć „pobierz fakturę”, może kliknąć „zamknij okno”, potem coś innego, i w efekcie utknąć w pętli albo, gorzej, kliknąć coś nieodwracalnego, jak „usuń zamówienie” zamiast „szczegóły zamówienia”. W środowisku testowym to strata czasu. Na koncie produkcyjnym to może być realna szkoda.

Gdzie da się to dziś bezpiecznie ograniczyć

Nie twierdzę, że agenty przeglądarkowe są bezużyteczne. Twierdzę, że trzeba je trzymać na smyczy, dopóki technologia i standardy bezpieczeństwa nie dojrzeją. W praktyce oznacza to kilka konkretnych zasad, które stosowaliśmy w naszych testach.

Sandbox to podstawa: osobna przeglądarka albo kontener, odizolowany od reszty systemu, bez dostępu do zapisanych haseł, historii i sesji użytkownika. Agent działa tam jak w izolowanej piaskownicy, więc nawet jeśli coś pójdzie nie tak, szkoda jest ograniczona do tego środowiska. Konto testowe zamiast produkcyjnego to drugi filar: jeśli chcemy sprawdzić, czy agent poradzi sobie z pobraniem faktury z portalu dostawcy, najpierw robimy to na koncie demo albo na koncie z minimalnym zakresem danych, nie na koncie głównym firmy.

Trzecia zasada to wąski zakres zadania. Jedna sesja, jedno konkretne zadanie, jasno zdefiniowany cel i najlepiej strona, która się rzadko zmienia i nie ma zewnętrznych, niekontrolowanych treści (reklam, komentarzy użytkowników). Portal logowania do systemu kurierskiego z prostym układem to lepszy kandydat niż strona z treściami generowanymi przez innych użytkowników.

Czwarta, chyba najważniejsza: człowiek zatwierdza krytyczny krok. Agent może przygotować dane, wyciągnąć numer faktury, sprawdzić status przesyłki, ale decyzję o wysłaniu płatności, zmianie danych w systemie czy usunięciu czegokolwiek zostawiamy człowiekowi. To ta sama zasada, którą stosujemy przy każdej automatyzacji z użyciem AI: model robi 80% pracy odtwórczej, człowiek podejmuje decyzję przy wyjątku i przy akcji nieodwracalnej.

Co ma dziś sens zamiast agenta przeglądarkowego

Dla zadań powtarzalnych i ustrukturyzowanych, takich jak pobieranie faktur z portali dostawców czy przenoszenie danych między systemami, klasyczna automatyzacja oparta na API albo dobrze skonfigurowanym RPA wciąż wygrywa z agentem AI. Jest przewidywalna, da się ją przetestować raz i mieć pewność, że będzie działać tak samo za miesiąc, i przede wszystkim jest audytowalna: wiadomo dokładnie, co robi krok po kroku, bez elementu „model zdecydował, że tak będzie lepiej”. Jeśli w firmie regularnie ktoś ręcznie ściąga faktury z kilkunastu portali dostawców, to jest to typowy przypadek na automatyzację faktur opartą na stabilnych integracjach, a nie na agencie klikającym po ekranie.

Podobnie w biurach rachunkowych, gdzie powtarzalność i zgodność z procedurą liczy się bardziej niż elastyczność, lepiej sprawdza się podejście oparte na sprawdzonych regułach i integracjach niż na modelu, który „mniej więcej” wie, co ma kliknąć. Więcej o tym, jak to układamy w praktyce, opisujemy przy okazji automatyzacji biura rachunkowego.

Agent przeglądarkowy ma sens tam, gdzie nie ma API, strona się nie zmienia często, dane nie są krytyczne, a zadanie jest na tyle rzadkie lub zmienne, że pisanie dedykowanej integracji się nie opłaca. To wąska nisza, nie uniwersalne rozwiązanie na „zautomatyzuj mi cały proces w przeglądarce”.

Ceny, limity i dostępność: dlaczego nie podaję tu konkretnej tabelki

Oba narzędzia, computer use od Anthropic i Operator od OpenAI, rozwijają się szybko, a ich dostępność, limity użycia i model cenowy zmieniają się w tempie, które trudno rzetelnie zamrozić w artykule. Zamiast podawać liczby, które za kilka miesięcy będą nieaktualne, radzę przed testem sprawdzić aktualną dokumentację dostawcy i realnie zweryfikować, czy funkcja jest w danym momencie dostępna w Twoim regionie i planie. To samo dotyczy warunków bezpieczeństwa: producenci regularnie aktualizują zasady dotyczące tego, jakie dane agent może przetwarzać i jak długo je przechowuje, więc to jest dokument, który warto czytać na bieżąco, a nie raz na rok.

Jak to sensownie wprowadzić w firmie, jeśli mimo wszystko chcemy spróbować

Jeśli zespół chce przetestować agenta przeglądarkowego, proponowałbym prosty schemat. Najpierw wybrać jedno, niekrytyczne zadanie odczytowe, na przykład sprawdzanie statusu przesyłki na stronie kuriera. Potem założyć osobne, testowe konto, bez podpinania danych produkcyjnych. Uruchomić agenta w izolowanej przeglądarce, bez dostępu do menedżera haseł głównego konta firmowego. Obserwować co najmniej kilkanaście cykli działania i spisywać, gdzie agent się myli, zawiesza albo klika coś nieoczekiwanego. Dopiero po takim okresie testowym rozważać rozszerzenie zakresu, i to stopniowo, z zachowaniem zasady, że każda akcja nieodwracalna wymaga potwierdzenia człowieka.

Warto też mieć świadomość, że część działań, które dziś próbuje się „załatwić” agentem przeglądarkowym, w rzeczywistości lepiej rozwiązać innym narzędziem z tego samego obszaru automatyzacji: obsługą klienta opartą na dobrze zaprojektowanym bocie z dostępem do bazy wiedzy zamiast agentem klikającym po panelu CRM, albo automatyzacją procesów w sklepie internetowym opartą na integracjach, a nie na symulowaniu kliknięć klienta. Przy tematach związanych z obsługą klienta i e-commerce polecam spojrzeć na to szerzej, np. przy okazji automatyzacji obsługi klienta czy automatyzacji e-commerce, gdzie agent przeglądarkowy jest zwykle najsłabszym z dostępnych rozwiązań, nie najsilniejszym.