Jak udržet AI agenta v rozpočtu a včas ho vypnout

AI agent je program, který dostane cíl, rozdělí ho na kroky a používá další nástroje. Může hledat v datech, volat firemní aplikace, vytvářet dokumenty nebo posílat zprávy. Oproti běžnému chatu neodpoví jen jednou, ale průběžně rozhoduje o dalším kroku. Tím může spotřebu rychle znásobit.

Jedna chyba nemusí stát mnoho. Agent ji však může opakovat, dokud nesplní podmínku ukončení nebo nenarazí na technický limit. Známý případ, kdy agent běžel 4 dny a uskutečnil 4 819 volání, vyšel provozovatele téměř na 4 000 dolarů. Agent neporušil zadání, ale chyběla v něm použitelná podmínka pro zastavení.

U prvních návrhů agentů jsem také považoval upozornění na spotřebu za dostatečné opatření. Není. Upozornění pouze sdělí, že náklady rostou. Limit musí další placenou operaci skutečně zamítnout, i když nikdo zrovna nekontroluje e-mail.

Kdy je tento postup na místě

Návod používám u agentů, kteří mohou sami opakovat kroky, spouštět placené nástroje nebo pracovat bez průběžného schválení člověkem. Typickým příkladem je zpracování příchozích dokumentů, rešerše z více zdrojů nebo doplňování údajů do firemního systému. Počet kroků se u těchto úloh mění podle vstupu, takže samotný měsíční rozpočet nestačí.

Pro jednoduchý postup s přesně danými kroky bych AI agenta nenasazoval. Jestli systém vždy přečte 1 soubor, vybere 3 hodnoty a uloží je do databáze, bývá vhodnější běžná automatizace. Lépe se testuje a cenu 1 běhu lze snáze předvídat. Tento návod také neřeší rozhodnutí se závažnými následky, u kterých musí zůstat povinné schválení člověkem. Finanční limit nenahrazuje oprávnění ani kontrolu výsledku.

Rozpočet má smysl nastavit až poté, co je přesně určený měřený úkol. Při přípravě prvního AI pilotu proto předem stanovuji výchozí čas, chybovost a podmínku ukončení. Nízké provozní náklady nemají hodnotu, pokud agent vytváří nepoužitelné výstupy.

Co musí být připravené před spuštěním

Na 1 stránku sepíšu očekávaný výstup, povolené nástroje, maximální dobu běhu a hranice spotřeby. Určím také člověka, který smí provoz zastavit a znovu povolit. U každého limitu musí být napsané, co se po jeho dosažení stane.

Každý agent dostane vlastní účet nebo přístupový klíč. U sdíleného klíče nelze spolehlivě poznat, která aplikace požadavek odeslala. Jeho nouzové zrušení navíc vyřadí i ostatní systémy, které ho používají. API, tedy rozhraní, přes které si aplikace posílají požadavky, musí zaznamenat identifikátor běhu, použitý model, počet volání, spotřebu a výsledek každé operace.

Připravuji také testovací prostředí bez přístupu k provozním datům a bez skutečných vnějších následků. Odeslání zprávy se v něm pouze zapíše do protokolu. Vytvoření objednávky skončí v testovací databázi. Agent v tomto prostředí nesmí dostat skutečnou platební kartu ani jiný prostředek, kterým by mohl provést platbu.

1. Stanovím rozpočet na běh, den a měsíc

Měsíční strop neochrání před 1 vadným během. Nastavuji proto 3 samostatné hranice. Limit na běh zachytí smyčku v konkrétním úkolu. Denní limit zastaví sérii chybných úloh. Měsíční limit hlídá celkový provoz.

Pro pilot může zadání určit například nejvýše 25 Kč na běh, 300 Kč za den a 5 000 Kč za měsíc. Jde o příklad nastavení, nikoli o doporučené ceny. Částky vycházejí z hodnoty úkolu a z nákladu, který lze při chybě přijmout bez dalšího schvalování.

Funkci limitů ověřím v přehledu spotřeby. Každý běh v něm má uvedenou cenu, stav a důvod případného zastavení. Součet následně porovnám s vyúčtováním dodavatele. Každý rozdíl musí mít dohledatelné vysvětlení a nesmí zůstat schovaný v položce „ostatní“.

2. Omezím počet kroků a opakování

U operací, jejichž skutečná cena je známá až po provedení, lze chování agenta omezit předem. Na 1 běh nastavuji maximální počet požadavků na model, volání nástrojů, opakovaných pokusů a minut provozu. U menšího pilotu to může být 10 požadavků na model, 6 použití nástroje, 2 opakování stejné akce a 8 minut.

Samostatně hlídám postup, který nepřináší výsledek. Jestli agent 3krát provede stejnou akci se stejnými údaji a stav úkolu se nezmění, běh ukončím. Smyčka se tak zastaví ještě před dosažením finančního limitu.

Při ověření zadám testovací úkol, který záměrně vyžaduje 11. požadavek nebo 3. opakování. Systém musí další krok odmítnout a uložit konkrétní důvod ukončení.

3. Kontroluji rozpočet před každým placeným voláním

Kontrola až po dokončení požadavku přichází pozdě. Před každým placeným krokem proto systém odhadne jeho nejvyšší možnou cenu a rezervuje ji ze zbývajícího rozpočtu. Po obdržení údaje o skutečné spotřebě rezervaci upraví.

Tato kontrola musí probíhat v centrální bráně, tedy v části systému, přes kterou procházejí všechna volání. Agent si limit nekontroluje sám. Pokud by se dostal do smyčky, mohl by opakovat také chybné rozhodnutí, že má pokračovat.

Při testu spustím několik úloh současně. Jakmile rezervace vyčerpají dostupnou částku, další požadavek se neodešle. Rezervace a snížení dostupné částky musí proběhnout atomicky, tedy jako 1 nedělitelná operace. Centrální brána proto použije společný zámek nebo podmíněný zápis do databáze, který rezervaci povolí jen tehdy, když zbývající rozpočet pokryje její celou výši.

4. Přidám vypínač mimo samotného agenta

Nouzový vypínač musí fungovat bez spolupráce modelu. Používám centrální přepínač, který zakáže nové placené požadavky, pozastaví frontu úloh a označí rozpracované běhy k ukončení. Zrušení přístupového klíče nechávám jako poslední možnost, protože už odeslaný požadavek se tím nemusí zastavit.

Vypínač má určeného správce a jeho zástupce. Nestačí tlačítko v nástroji, ke kterému má přístup pouze 1 člověk. Podle průzkumu 20 % podniků nedokáže výdaje AI agenta zastavit v reálném čase. Možnost okamžitého zásahu proto musí být součástí návrhu a následného testu.

Funkci ověřím během provozního testu. Po aktivaci vypínače nesmí centrální brána přijmout žádné nové placené volání, a to ani z opožděné fronty. Protokol zkontroluji bezprostředně po aktivaci a znovu po 60 sekundách, nikoli pouze podle stavu zobrazeného v ovládacím rozhraní.

5. Uložím stav bezpečného zastavení

Vypnutí agenta nesmí zanechat úkol ve stavu, ze kterého nelze poznat, co už provedl. Ke každé akci ukládám čas, výsledek a jedinečný identifikátor. Při obnovení systém podle tohoto identifikátoru zkontroluje, zda už zprávu odeslal nebo záznam založil, a stejnou vnější akci znovu neprovede.

Zastavený běh dostane stav, který odliší překročený rozpočet, technickou chybu a ruční zásah. Pokračování vyžaduje nové schválení. Agent nesmí obnovit práci pouze na základě vlastního rozhodnutí. Stejný princip používám i při přípravě procesu na výpadek AI služby, protože fronta úloh po obnovení nesmí vytvořit duplicity.

Test dokončím vypnutím agenta uprostřed úkolu a následným obnovením. Výsledkem musí být dokončený úkol bez zopakované vnější akce.

6. Vyzkouším poruchy a nastavím použitelné alarmy

Před ostrým provozem záměrně vyvolám chybnou odpověď modelu, nedostupný nástroj, pomalé API, opakovanou úlohu a nedostupný údaj o ceně. Každý scénář musí skončit předem určeným stavem. Když systém nezná cenu, další placený krok nepovolím. Neznámou spotřebu nelze považovat za nulovou.

Upozornění posílám při 50 %, 80 % a 100 % rozpočtu. Obsahuje název agenta, identifikátor běhu, aktuální spotřebu, důvod a přímý odkaz k vypnutí. Při dosažení 80 % lze zastavit příjem nových úloh.

Nejčastější potíže vznikají při účtování vedlejších nástrojů. Model tvoří jen část ceny. Další položky přidává vyhledávání, převod dokumentů, ukládání dat nebo opakované pokusy integrační vrstvy. Přehled o spotřebě komplikují také sdílené klíče.

Do ostrého provozu pouštím nejprve malý objem úloh a denně porovnávám vlastní záznam s účtem dodavatele. Limity zvýším až po skutečném testu vypínače.