Il budget è un guard rail: gli agenti AI devono avere un limite di spesa

CLOUD / AGENTI / CONTROLLO COSTI

Un agente AI può creare una funzione serverless, collegarla a un modello, aggiungere storage, schedulare un job e lasciarlo lavorare mentre nessuno guarda. È esattamente il motivo per cui l’automazione è utile. È anche il motivo per cui una mail che dice “hai superato il budget” comincia ad assomigliare a un sistema di sicurezza che manda l’allarme dopo che la porta è già stata aperta.

Simon Willison ha proposto una regola molto semplice: i servizi a consumo dovrebbero offrire per default un limite di spesa rigido, capace di interrompere il servizio quando viene raggiunta una soglia. La parte interessante non è la fatturazione. È che, con software sempre più autonomo, il denaro diventa una risorsa di runtime e il budget smette di essere soltanto un dato per amministrazione e FinOps.

Se un agente può consumare denaro senza chiedere permesso a ogni operazione, il budget non è più soltanto un report: è parte del suo perimetro di esecuzione.

Un alert osserva. Un cap controlla.

La distinzione sembra banale, ma cambia l’architettura. Un alert risponde alla domanda “quanto stiamo spendendo?”. Un hard cap prova a rispondere a una domanda diversa: “quanto può ancora spendere questo workload prima che il sistema gli tolga la possibilità di continuare?”.

È la stessa differenza che esiste fra logging ed enforcement. Il log può dirci che un processo ha provato a fare qualcosa. Una policy può impedirglielo. Nel caso degli agenti, questo principio si collega direttamente a un tema che ho già affrontato parlando di sicurezza degli agenti ed enforcement fuori dal prompt: un limite è credibile quando viene applicato da un livello che il componente autonomo non può reinterpretare a proprio vantaggio.

Con il costo succede la stessa cosa. Scrivere nel prompt “non spendere più di 50 euro” è un’intenzione. Mandare una notifica all’80% è osservabilità. Bloccare tecnicamente nuove operazioni fatturabili oltre una soglia è controllo. Sono tre cose diverse, e confonderle diventa costoso proprio quando togliamo l’operatore umano dal loop.

Gli agenti cambiano il profilo del rischio economico

Il cloud ha sempre avuto il problema dei costi inattesi. Una configurazione sbagliata, traffico anomalo, una query troppo aggressiva o una risorsa dimenticata possono produrre una fattura sgradevole senza bisogno di alcuna AI. Gli agenti però abbassano la frizione con cui il software può creare altro software e altre risorse.

Quando l’AI smette di limitarsi a conversare e comincia ad agire, il problema non è più soltanto la qualità della risposta. Conta l’action space: quali API può chiamare, quali risorse può creare, per quanto tempo può lavorare, quante volte può ritentare e quali effetti può accumulare. A questa lista manca spesso una voce: quanto denaro può trasformare in effetti prima di fermarsi.

Un agente che fallisce velocemente è fastidioso. Un agente che fallisce lentamente ma continua a generare chiamate a pagamento può essere molto più educato e molto più costoso. Retry, parallelismo, code, job pianificati e risorse elastiche moltiplicano il problema: sono tutti meccanismi ragionevoli finché il sistema possiede un limite superiore osservabile e applicabile.

Il budget dovrebbe stare accanto a timeout, rate limit e lease

Quando progetto un processo autonomo, mi interessa sapere dove finisce. Un timeout impedisce che un’operazione duri per sempre. Un rate limit limita la velocità con cui può consumare una risorsa. Una quota limita la quantità. Un lease impedisce a un worker di considerare eterno il proprio diritto a lavorare. Un meccanismo di fencing evita che una vecchia esecuzione continui a mutare lo stato dopo essere stata sostituita.

Il budget monetario appartiene alla stessa famiglia, ma misura una dimensione che CPU, token e richieste non catturano bene. Diecimila chiamate possono costare pochi centesimi su un servizio e centinaia di euro su un altro. Un’ora di esecuzione può essere trascurabile oppure includere GPU, storage, egress e API esterne. Il denaro diventa quindi una metrica trasversale capace di sommare risorse eterogenee.

• Budget per task o progetto. Il workload non eredita implicitamente tutta la capacità di spesa dell’account.
• Rate limit e quote locali. Contengono picchi e loop prima che il costo aggregato arrivi al cap.
• Timeout e deadline. Evitano processi economicamente vivi ma operativamente inutili.
• Kill switch esterno. Il componente che decide di continuare non dovrebbe essere l’unico che può decidere di fermarsi.
• Read-back dei costi. L’agente può usare il budget residuo come segnale per scegliere strategie meno costose, ma non deve controllare l’enforcement finale.

Non è una teoria particolarmente esotica. È il vecchio principio del blast radius applicato alla fatturazione: se qualcosa va storto, quanto può diventare grande il danno prima che un confine indipendente lo arresti?

AWS e Google stanno iniziando a rendere il limite più concreto

Il segnale interessante è che i provider stanno introducendo controlli più vicini a questo modello. Il 16 settembre 2026 AWS ha annunciato una nuova esperienza per builder in cui un progetto può avere un limite mensile di spesa e viene messo in pausa quando lo raggiunge. La documentazione AWS descrive il limite come un tetto sui costi pre-tax del progetto e prevede anche controlli anticipati opzionali, per esempio impedire la creazione di nuove risorse prima di arrivare alla soglia.

È però importante non trasformare questa funzione in una proprietà universale di AWS. La nuova esperienza è in rollout e ha regole proprie, inclusi valori minimi del limite calcolati anche sull’uso corrente. È un passo nella direzione giusta, non la prova che qualunque account AWS oggi disponga di un interruttore assoluto applicabile a ogni scenario.

Anche Google Cloud documenta gli Spend Caps, attualmente in Preview, per singoli servizi eleggibili all’interno di un progetto. Quando il cap viene applicato, le nuove richieste verso il servizio specificato vengono bloccate finché un operatore non lo rimuove. Fra i servizi indicati oggi compaiono Gemini API, Agent Platform, Cloud Run e Cloud Run functions.

Qui c’è un dettaglio che vale più del nome della feature: Google avverte esplicitamente che l’enforcement non è istantaneo e che eventuali costi maturati durante la latenza restano dovuti. Inoltre alcune risorse persistenti possono continuare a generare costi. Quindi hard cap non significa necessariamente “il conto non supererà mai matematicamente X di un centesimo”.

Un hard cap non sostituisce una buona architettura

Sarebbe comodo risolvere tutto con una soglia mensile e dichiarare chiuso il problema. Non funziona così. Un cap troppo alto limita poco. Un cap troppo basso può fermare un servizio nel momento peggiore. Un singolo limite a livello account può proteggere la fattura e contemporaneamente avere un blast radius enorme, perché un workload rumoroso può consumare il budget degli altri.

Per questo il punto non è scegliere fra disponibilità e controllo dei costi. È progettare la gerarchia dei limiti. Un servizio critico può avere un budget diverso da un esperimento. Un agente che prova una nuova pipeline non dovrebbe possedere la stessa capacità economica di un sistema di produzione. E una soglia monetaria dovrebbe convivere con quote tecniche più vicine alla causa: token, richieste, istanze, job concorrenti, storage, egress.

È lo stesso motivo per cui, parlando di migrazioni cloud e assunti infrastrutturali, il problema raramente è il singolo componente. Sono gli assunti impliciti a rompere il sistema. “Il provider mi avviserà prima che costi troppo” è uno di quegli assunti. Finché c’è un umano che controlla la dashboard può sembrare accettabile. Con un agente che opera alle tre di notte diventa una dipendenza architetturale.

Anche la scelta del provider diventa una scelta di sicurezza

Willison suggerisce un’altra conseguenza interessante: gli stessi agenti potrebbero preferire servizi che offrono limiti di spesa realmente enforceable e avvertire quando stanno per usare un servizio uncapped. Ha senso, ma farei un passo ulteriore. La presenza del cap dovrebbe entrare nella descrizione delle capability che un agente può utilizzare.

Non basta sapere che un provider espone una API. Serve sapere con quale identità verrà chiamata, quali quote applica, quale budget residuo possiede il progetto, che cosa succede al superamento e quanto è forte la garanzia di arresto. In altre parole, il costo diventa parte del contratto operativo del tool.

Questo cambia anche il procurement tecnico. Due API con prezzo simile non sono equivalenti se una permette di isolare un progetto con un tetto enforceable e l’altra offre soltanto notifiche. Per un prototipo manuale può essere un dettaglio. Per un sistema che decide e ritenta autonomamente è una proprietà di sicurezza.

L’autonomia ha bisogno di confini noiosi

Gli agenti rendono spettacolari molte cose che, in produzione, dovrebbero restare noiose: permessi, timeout, idempotenza, audit, quote, lease, circuit breaker. Il budget appartiene a quella lista. Non serve renderlo intelligente. Serve renderlo difficile da ignorare.

La domanda utile non è quindi “quanto costa usare un agente?”. È più precisa: qual è la massima spesa che questo agente può causare prima che un meccanismo esterno lo fermi? Se la risposta è “dipende da quando qualcuno legge la mail”, non abbiamo definito un limite. Abbiamo definito un osservatore.

Più deleghiamo al software la capacità di agire, più dobbiamo smettere di considerare il denaro una conseguenza amministrativa delle sue azioni. CPU, rete, storage e token hanno sempre avuto quote. Ora che un agente può orchestrare tutte queste risorse insieme, anche il budget deve diventare una quota di sistema.