Aplikacja agentowa bez limitu wydatków może wygenerować ogromny rachunek po jednym błędzie: guardraile pomijane przez startupy

Agent AI nie musi „zwariować”, żeby narobić kosztów. Wystarczy znacznie bardziej banalny błąd: źle obsłużony retry, pętla między dwoma narzędziami, brak ograniczenia liczby kroków albo 50 workerów uruchomionych równolegle na tym samym zadaniu. Jeśli aplikacja ma dostęp do płatnego modelu, wyszukiwarki, przeglądarki, infrastruktury chmurowej czy zewnętrznych API i nie ma twardego limitu kosztu, jedna wadliwa ścieżka wykonania potrafi mnożyć opłaty do momentu ręcznego wyłączenia systemu.

To różni aplikację agentową od zwykłego chatbota. Użytkownik czatu wykonuje kolejną operację, dopiero gdy napisze kolejną wiadomość. Agent sam planuje następne kroki, uruchamia narzędzia, interpretuje wynik i podejmuje kolejną decyzję. Jeśli logika zakończenia zadania jest wadliwa, ten sam mechanizm, który miał oszczędzać pracę człowieka, zaczyna automatycznie produkować kolejne płatne operacje.

Najgroźniejsze jest przy tym mylenie alertu kosztowego z zabezpieczeniem. Alert informujący o przekroczeniu 1000 euro nie chroni przed rachunkiem na 3000 euro, jeżeli po jego wysłaniu workload nadal działa.

Najdroższy błąd zwykle nie jest w modelu, tylko w pętli agenta

W produkcyjnych systemach agentowych koszt pojedynczego zapytania rzadko jest najważniejszą liczbą. Trzeba patrzeć na koszt całej ścieżki wykonania.

Jedno zadanie może obejmować:

• wywołanie modelu planującego,

• kilka zapytań do wyszukiwarki,

• pobranie dokumentów,

• analizę każdego dokumentu przez model,

• zapis danych do bazy,

• wygenerowanie kolejnego planu,

• ponowne użycie modelu po błędzie narzędzia,

• walidację wyniku,

• dodatkową próbę, jeśli walidacja nie przejdzie.

W praktyce jedno kliknięcie użytkownika może więc oznaczać kilkanaście albo kilkadziesiąt płatnych operacji.

Problem zaczyna się wtedy, gdy deweloper ograniczył na przykład długość odpowiedzi modelu, ale nie ograniczył liczby iteracji całego workflow.

Typowy scenariusz wygląda niewinnie:

1. agent wysyła żądanie do zewnętrznego API;

2. API zwraca błąd albo odpowiedź, której agent nie rozumie;

3. aplikacja interpretuje wynik jako nieukończone zadanie;

4. agent przygotowuje kolejną próbę;

5. mechanizm retry uruchamia tę samą procedurę;

6. proces powtarza się przez setki iteracji.

Jeszcze gorzej, jeśli system działa równolegle.

Załóżmy modelowy, celowo uproszczony przypadek. Jeden pełny krok agenta — model plus zewnętrzne narzędzia — kosztuje średnio 0,04 euro. Workload uruchamia 50 równoległych zadań, każde dochodzi do 30 kroków:

50 × 30 × 0,04 euro = 60 euro.

Jeżeli błąd powoduje pięciokrotne ponowienie całej operacji, koszt rośnie do 300 euro. Przy 500 równoległych zadaniach byłoby to już 3000 euro.

Nie jest to cennik konkretnego dostawcy, lecz prosty model pokazujący mechanizm wzrostu kosztów. W prawdziwej aplikacji należy policzyć własną średnią na podstawie tokenów, cen narzędzi, transferu, baz danych, wyszukiwania i infrastruktury.

I właśnie tutaj startupy często popełniają pierwszy błąd projektowy: monitorują koszt modelu, zamiast kosztu wykonania zadania.

Do limitu powinny wejść wszystkie płatne elementy:

LLM + embeddingi + web search + OCR + crawling + storage + transfer + kolejki + funkcje serverless + bazy + komercyjne API.

Jeżeli agent może sam uruchomić dodatkową maszynę, zlecić renderowanie, kupić dostęp do danych albo utworzyć setki instancji procesu, ograniczenie samych tokenów niewiele daje.

Drugi problem to rosnący kontekst. W wielu implementacjach agent podczas kolejnych iteracji przesyła modelowi coraz dłuższą historię. Dziesiąty krok nie musi więc kosztować tyle co pierwszy. System może ponownie wysyłać wcześniejsze wyniki narzędzi, dokumenty, logi i własne odpowiedzi, a koszt pojedynczej iteracji zaczyna rosnąć razem z długością sesji.

Z tego powodu maksymalna liczba kroków jest zabezpieczeniem kosztowym, a nie tylko programistycznym.

W prostym agencie sensownym punktem wyjścia jest zwykle limit rzędu 10–30 kroków na zadanie. Jeżeli proces biznesowy rzeczywiście wymaga 100 kroków, powinno to być świadome odstępstwo, a nie wartość wynikająca z while true.

Budżet, alert i twardy limit to trzy różne zabezpieczenia

Najbardziej kosztownym nieporozumieniem jest założenie, że ustawiony w panelu dostawcy „budget” automatycznie zatrzyma aplikację.

Nie zawsze tak działa.

W Google Cloud klasyczne budżety typu alerts-only nie blokują użycia po osiągnięciu ustalonej kwoty. Służą do obserwowania wydatków i wysyłania alarmów. To oznacza, że budżet 1000 euro może zostać przekroczony, jeżeli usługi nadal wykonują operacje.

W 2026 roku Google udostępnił również spend cap budgets w wersji Preview dla wybranych usług, między innymi Gemini API, Gemini Enterprise Agent Platform, Cloud Run i Cloud Run functions. Mechanizm wysyła ostrzeżenia przy 50%, 80% i 100% budżetu, a po przekroczeniu 100% blokuje nowe użycie objętej limitem usługi.

To znacznie lepszy mechanizm, ale nie należy traktować go jak idealnego bezpiecznika elektrycznego. Google wprost wskazuje, że egzekwowanie limitu nie jest natychmiastowe, a operacje będące już w toku mogą zostać dokończone i naliczyć dodatkowy koszt. Limit obejmuje też konkretny projekt i konkretną kwalifikującą się usługę, a nie automatycznie cały rachunek firmy.

OpenAI również rozdziela mechanizmy monitorowania wydatków od hard spend limit. Limit na poziomie organizacji albo projektu może być ustawiony jako wymuszany, tak aby kolejne żądania API po osiągnięciu progu kończyły się błędem. Sam alert czy miękki próg wydatków tego efektu nie daje.

AWS ma z kolei AWS Budgets i Budget Actions. Po przekroczeniu progu można między innymi zastosować politykę IAM lub SCP albo uruchomić działania wobec określonych zasobów. Samo utworzenie budżetu nie zastępuje jednak prawidłowej architektury uprawnień.

Dlatego przed uruchomieniem agenta trzeba odpowiedzieć na jedno bardzo konkretne pytanie:

co fizycznie stanie się po przekroczeniu 100% mojego limitu?

Jeżeli odpowiedź brzmi „dostanę e-mail”, system nie ma twardego limitu.

W praktyce stosuję trzy poziomy ochrony.

Poziom 1: limit pojedynczego zadania.
Agent dostaje maksymalny koszt, liczbę kroków, czas wykonania i liczbę wywołań narzędzi.

Przykładowa polityka dla wewnętrznego agenta:

• maks. koszt zadania: 2 euro,

• maks. 20 kroków,

• maks. 60 wywołań narzędzi,

• maks. 10 minut pracy,

• maks. 3 ponowienia pojedynczej operacji.

To nie są uniwersalne liczby. Agent wykonujący analizę dokumentu może potrzebować innych parametrów niż agent wykonujący setki operacji na danych. Ważne jest, żeby wartości istniały i wynikały z pomiarów.

Poziom 2: limit aplikacji lub projektu.
Po przekroczeniu np. 80% dziennego budżetu można ograniczyć równoległość, przełączyć część ruchu na tańszy model albo zablokować zadania o niskim priorytecie.

Przy 100% ruch powinien zostać zatrzymany technicznie.

Poziom 3: limit po stronie dostawcy.
Jeżeli platforma obsługuje rzeczywisty hard cap, należy go włączyć. Chroni również przed błędem w samym mechanizmie budżetowym aplikacji.

Najgorsza konstrukcja to sytuacja, w której aplikacja i dostawca mają wyłącznie alerty. Wtedy jeden wadliwy deployment potrafi pracować przez noc, a pierwszy człowiek zauważa problem dopiero rano.

Guardrail kosztowy powinien blokować działanie, a nie tylko pisać na Slacku

Najbardziej niezawodny guardrail działa przed wykonaniem kosztownej operacji.

Agent powinien mieć lokalny licznik kosztu zadania. Przed każdym wywołaniem modelu lub płatnego narzędzia system oblicza albo szacuje koszt kolejnego kroku i porównuje go z pozostałym budżetem.

Jeżeli zadanie wykorzystało 1,92 euro z limitu 2 euro, aplikacja nie powinna uruchamiać operacji szacowanej na 0,25 euro tylko dlatego, że „jeszcze nie przekroczyła dwóch euro”.

Powinna ją odrzucić.

Do wdrożenia produkcyjnego minimum obejmuje:

• max_cost_per_task — maksymalny koszt pojedynczego zadania,

• max_steps — maksymalna liczba iteracji,

• max_tool_calls — maksymalna liczba uruchomień narzędzi,

• max_runtime — maksymalny czas życia procesu,

• max_retries — ograniczenie ponowień,

• max_concurrency — limit równoległych agentów,

• circuit breaker — automatyczne zatrzymanie po serii błędów,

• allowlista narzędzi i operacji,

• approval gate dla operacji kosztownych albo nieodwracalnych.

Retry wymaga szczególnej uwagi. Popularny zapis „spróbuj ponownie trzy razy” może oznaczać coś zupełnie innego na różnych poziomach systemu.

Jeżeli klient HTTP wykonuje trzy próby, funkcja nadrzędna trzy razy ponawia wywołanie klienta, a agent trzy razy ponawia cały krok, jedna operacja biznesowa może w skrajnym przypadku wygenerować:

3 × 3 × 3 = 27 prób.

Dodanie jeszcze jednego mechanizmu retry na poziomie kolejki daje potencjalnie 81 wykonań.

To klasyczny problem, którego nie widać podczas testu „happy path”.

Kolejny guardrail to idempotency. Jeżeli agent ponawia operację „utwórz zamówienie”, „wyślij kampanię”, „zarezerwuj zasób” czy „uruchom instancję”, druga próba nie może automatycznie tworzyć drugiego obiektu.

Dotyczy to również pieniędzy. Narzędzia umożliwiające zakup, rezerwację zasobów, zwiększenie infrastruktury czy uruchomienie płatnej kampanii powinny mieć osobny limit transakcyjny, niezależny od kosztu tokenów.

Agent z budżetem modeli 20 euro nie powinien przez to automatycznie dostać prawa do uruchomienia infrastruktury za 5000 euro.

Dobrze zaprojektowane uprawnienia są więc wąskie:

agent do raportowania nie potrzebuje prawa do tworzenia serwerów;
agent do analizy faktur nie potrzebuje prawa do wykonania przelewu;
agent do przygotowania kampanii nie powinien samodzielnie zwiększać budżetu reklamowego.

Zasada least privilege ma w systemach agentowych znaczenie finansowe równie duże jak bezpieczeństwo danych.

W środowisku europejskim dochodzi jeszcze kwestia audytowalności. AI Act zaczął być szerzej egzekwowany 2 sierpnia 2026 roku, a od tego dnia obowiązują między innymi określone wymogi przejrzystości z art. 50. Nie oznacza to, że każdy firmowy agent automatycznie jest systemem wysokiego ryzyka. Oznacza natomiast, że traktowanie logów, kontroli dostępu, odpowiedzialności za działanie i nadzoru człowieka jako „funkcji na później” jest coraz trudniejsze do obrony organizacyjnie.

Z perspektywy kosztowej log powinien pozwalać po incydencie odtworzyć przynajmniej:

• identyfikator zadania,

• użytkownika lub usługę, która je uruchomiła,

• użyty model,

• każde wywołane narzędzie,

• liczbę tokenów lub jednostek rozliczeniowych,

• szacowany i rzeczywisty koszt,

• liczbę retry,

• powód zakończenia,

• wersję promptu i workflow,

• deployment aplikacji, na którym wykonano zadanie.

Bez tych informacji po rachunku na kilka tysięcy euro zespół często wie jedynie, że „API zużyło za dużo”. Nie wie natomiast, które zachowanie aplikacji trzeba poprawić.

Najbardziej irytującą cechą systemów billingowych jest opóźnienie. Nie wszystkie koszty pojawiają się w dashboardzie natychmiast. Google przy swoich spend capach również zastrzega, że zatrzymanie nie następuje natychmiast i może wystąpić przekroczenie limitu. Z tego powodu zewnętrzny billing nie powinien być jedynym licznikiem kosztu działającym podczas wykonywania agenta.

Aplikacja powinna prowadzić własny licznik w czasie rzeczywistym, nawet jeżeli jest to tylko konserwatywna estymacja.

Jeżeli dokładny koszt danego wywołania jest znany dopiero później, lepiej przyjąć bezpieczny koszt maksymalny niż zakładać zero.

Dobre rozwiązanie wygląda więc jak kilka niezależnych hamulców, a nie jeden wielki przycisk STOP:

limit zadania → limit równoległości → circuit breaker → limit projektu → hard cap dostawcy.

Wtedy awaria jednego poziomu nie oznacza automatycznie nieograniczonego rachunku.

Dodatkowe informacje na: https://itux.pl

FAQ

Czy sam limit tokenów wystarczy do ochrony przed wysokim rachunkiem?
Nie. Limit tokenów ogranicza jeden składnik kosztu. Agent może równolegle płacić za wyszukiwanie, crawling, bazy danych, storage, funkcje serverless, transfer i zewnętrzne API. Potrzebny jest limit kosztu całego zadania.

Czy alert przy 80% i 100% budżetu jest wystarczającym zabezpieczeniem?
Nie, jeżeli po wysłaniu alertu system nadal działa. Alert jest mechanizmem obserwacji. Twardy guardrail musi technicznie odrzucić następne zadania albo kosztowne operacje.

Jaki limit ustawić na początku dla nowego agenta?
Najpierw zmierz 100–500 kontrolowanych zadań testowych i wyznacz typowy koszt oraz 95. lub 99. percentyl. Limit produkcyjny można ustawić nieco powyżej kosztu poprawnie wykonanych najdroższych zadań, zamiast wybierać arbitralnie wysoką kwotę. Do czasu zebrania danych uruchamiaj agenta z małym budżetem i niewielką równoległością.

Czy hard cap gwarantuje, że rachunek nigdy nie przekroczy ustawionej wartości?
Nie zawsze. Dostawca może rozliczać część użycia z opóźnieniem, a żądania już znajdujące się w toku mogą zostać dokończone. Dlatego twardy limit platformy powinien znajdować się poniżej absolutnej kwoty, której firma nie chce przekroczyć.

Co powinno wymagać zatwierdzenia człowieka?
Przede wszystkim operacje o wysokim koszcie lub trudne do odwrócenia: zakup, płatność, zwiększenie budżetu reklamowego, uruchomienie dużej infrastruktury, masowa wysyłka wiadomości, usuwanie danych i zmiana uprawnień. Nie ma sensu blokować człowiekiem każdego odczytu z bazy czy prostego zapytania do modelu.

Co sprawdzić przed wypuszczeniem agenta na produkcję?
Uruchom test celowo uszkodzonego workflow: zwracaj błędy z API, timeouty, błędne odpowiedzi narzędzi i powtarzające się wyniki. Sprawdź, czy agent rzeczywiście zatrzymuje się po osiągnięciu max_steps, max_retries, max_runtime i max_cost_per_task, zamiast tylko zapisywać ostrzeżenie w logu.

Od czego zacząć, jeśli aplikacja agentowa już działa bez tych zabezpieczeń?
Nie zaczynaj od przebudowy promptów. Najpierw usuń możliwość nieograniczonego wykonania: ustaw twardy koszt pojedynczego zadania, maksymalną liczbę kroków i limit równoległości, a następnie sprawdź, czy po przekroczeniu budżetu dostawca naprawdę odrzuca kolejne żądania. To jest błąd, który należy usunąć przed każdą dalszą optymalizacją agenta.