Agenci AI potrzebują bezpiecznika wydatków, a nie kolejnego maila z ostrzeżeniem

Simon Willison przekonuje, że usługi rozliczane według zużycia powinny faktycznie zatrzymywać się po wyczerpaniu budżetu. Gdy agenci mogą nocą wywoływać API i uruchamiać infrastrukturę, hard cap staje się granicą bezpieczeństwa, a nie dodatkiem do faktury.

Po przekroczeniu budżetu ma pojawić się błąd, nie e-mail

Willison odróżnia miękki limit, który tylko wysyła ostrzeżenie, od twardego limitu odrzucającego kolejne żądania. Proponuje prostą zasadę: po wydaniu kwoty X w miesiącu usługa ma się zatrzymać i zwracać błędy. Jego zdaniem większość osób i firm woli przerwę w działaniu niż niespodziewany rachunek przekraczający 10 000 USD.

Duzi dostawcy już idą w tym kierunku. AWS 16 września zapowiedział miesięczny spend limit, po którego osiągnięciu projekt zostaje wstrzymany do końca miesiąca. Funkcja trafia jednak tylko do ograniczonej grupy klientów. Google Cloud w lipcu uruchomił Spend Caps dla wybranych usług w jednym projekcie. Po egzekwowaniu limitu nowe żądania są blokowane, lecz opóźnienia w raportowaniu mogą jeszcze zwiększyć rachunek.

Budżet staje się częścią uprawnień agenta

Coding agent z dostępem do płatnych API potrafi wdrożyć użyteczną aplikację, a przy okazji uruchomić niekontrolowane zużycie. Limit finansowy powinien więc stać obok uprawnień, reguł sieciowych i logów audytowych. Wyznacza kwotę szkody, którą automatyzacja może wyrządzić bez kolejnej zgody człowieka.

Dla programistów oznacza to zmianę zarówno przy wyborze dostawcy, jak i przy projektowaniu systemu. Każdy projekt, środowisko lub agent potrzebuje własnego pułapu, a aplikacja powinna bezpiecznie ograniczyć działanie po jego osiągnięciu. Jeden limit dla całego konta firmowego jest zbyt tępy, bo eksperyment może zatrzymać razem ze sobą ważną produkcję.

Twardy limit również działa z opóźnieniem

Nazwa hard cap sugeruje szczelną ścianę. Dane billingowe docierają jednak później, a rozpoczęte żądania zwykle kończą się normalnie. Google wprost ostrzega, że egzekwowanie limitu nie jest natychmiastowe, a nadwyżkę płaci klient. Miesięczny pułap nadal wymaga limitów żądań, bieżącego pomiaru i awaryjnego wyłącznika.

Przerwa w działaniu może też kosztować więcej niż nadwyżka. Firmy potrzebują kilku trybów: pełnego zatrzymania eksperymentu, ograniczonej pracy narzędzia wewnętrznego i eskalacji dla usługi krytycznej. Bez takiego wyboru zespoły wyłączą zabezpieczenie po pierwszym kłopotliwym incydencie.

Domyślne ustawienia i realna nadwyżka pokażą skuteczność

Pierwszym ważnym sygnałem będzie to, czy AWS i Google automatycznie włączą twarde limity dla nowych projektów, czy ukryją je w ustawieniach. Drugi będzie czysto operacyjny: o ile rachunek przekroczy ustawioną kwotę, zanim dostawca zatrzyma nowe użycie.

Dostawcy powinni też udostępnić limity przez API, aby agent dostawał budżet razem z pozostałymi uprawnieniami. Bez pułapów zarządzanych maszynowo tempo wdrożeń nadal będzie wyprzedzać kontrolę nad rachunkiem.

Werdykt Lilith

Agent bez limitu wydatków przypomina stażystę z firmową kartą na nocnej zmianie bez nadzoru. Mail z ostrzeżeniem przychodzi, gdy rachunek już leży na biurku.