L’adozione di modelli linguistici e agenti AI nelle imprese sta rendendo la spesa per inferenza una voce operativa sempre meno semplice da controllare. Le fatture non dipendono soltanto dal numero di richieste inviate a un provider, ma da una combinazione di token in input e output, modello effettivamente utilizzato, chiamate agli strumenti, richieste concorrenti, retry automatici, cache, limiti di contesto e instradamento attraverso piattaforme cloud o gateway intermedi.
Un controllo sui costi sostenuti da un gruppo di aziende ha evidenziato contestazioni per circa 1,7 milioni di dollari su 34 milioni di spesa AI analizzata tra marzo e giugno. Le verifiche hanno riguardato soprattutto utilizzi di Claude Code, ma hanno coinvolto anche architetture in cui i modelli venivano consumati tramite Amazon Web Services, Google Cloud e Microsoft Azure. In seguito alle contestazioni, una parte rilevante degli importi è stata riconosciuta attraverso rimborsi o crediti.
Le anomalie segnalate riguardano anzitutto la corrispondenza tra il modello dichiarato nei log applicativi e quello associato alla tariffazione. In un ambiente multi-modello, il prezzo per milione di token può cambiare in modo rilevante tra versioni precedenti, modelli ad alta capacità e configurazioni pensate per attività di ragionamento o coding. Quando l’azienda non dispone di un registro indipendente delle chiamate, diventa difficile verificare se il modello fatturato coincide con quello realmente selezionato dal router, dall’SDK o dalla piattaforma di deployment.
Un secondo nodo riguarda le richieste non concluse. Un agente può ricevere un errore, superare un timeout, interrompersi durante una chiamata a un tool o restituire un output non utilizzabile dall’applicazione. Dal punto di vista tecnico, però, una parte del lavoro inferenziale può essere già stata eseguita: il prompt è stato elaborato, sono stati generati token intermedi oppure sono state avviate chiamate successive. La trasparenza della fatturazione dipende quindi dalla distinzione precisa tra richiesta accettata, richiesta elaborata, risposta generata, risposta consegnata e task completato.
Particolarmente critico è il fenomeno del retry storm. Nei workflow agentici il sistema può ripetere automaticamente una stessa operazione quando un tool non risponde, un endpoint restituisce un errore transitorio, un parser non riesce a validare l’output o un limite di rate viene superato. Se il retry non ha soglie, backoff progressivo, idempotenza e tracciamento centralizzato, la stessa attività può generare decine di chiamate quasi identiche, spesso senza che l’utente finale ne abbia visibilità. Il costo non deriva da una singola risposta del modello, ma dalla catena di esecuzioni ripetute attivata dal workflow.
Per le aziende che usano AI generativa su scala, il controllo economico richiede quindi una telemetria separata dalla sola fattura del provider. Ogni chiamata dovrebbe essere collegata a un identificativo di utente, applicazione, agente, modello, versione del prompt, numero di token, stato finale, strumenti utilizzati e numero di tentativi effettuati. Questo consente di riconciliare l’uso reale con gli importi fatturati, ma anche di individuare configurazioni inefficienti, prompt troppo lunghi, contesti ripetuti inutilmente e agenti che consumano risorse senza portare a termine il task.
Il tema non riguarda soltanto possibili errori di addebito. Man mano che gli agenti diventano autonomi nell’eseguire procedure composte, il costo AI si sposta dalla semplice richiesta testuale a una metrica di esecuzione: quanti passaggi sono stati necessari, quali strumenti sono stati chiamati, quanti token sono stati usati per ragionare, quante correzioni sono state tentate e quale risultato è stato effettivamente consegnato. Senza questa visibilità, la governance dell’AI rischia di fermarsi al budget, senza riuscire a misurare con precisione l’efficienza reale dei sistemi.