Il FinOps ha dato ai team un vero e proprio manuale operativo per la disciplina dei costi cloud: taggare le risorse, monitorare l'unit economics, costruire modelli di chargeback che rendano engineering e finance responsabili degli stessi numeri. Funziona. Oggi la maggior parte delle organizzazioni cloud mature opera su una qualche versione di questo approccio.
L'infrastruttura AI sta mandando in crisi quel manuale, e la maggior parte dei team non ha ancora davvero preso le misure di quanto la rottura sia profonda.
Cosa significa oggi FinOps per l'AI
Il FinOps per l'AI è la naturale estensione della disciplina di cloud financial management ai workloads di machine learning e AI generativa. L'obiettivo è lo stesso del FinOps tradizionale: collegare la spesa al team, al prodotto o al cliente che la genera, perché finance ed engineering possano decidere partendo dagli stessi numeri. Ciò che è cambiato è l'infrastruttura sottostante e, se quell'infrastruttura è ancora poco familiare, la meccanica con cui un LLM elabora davvero una richiesta è un ottimo punto da cui partire.
In pratica, il FinOps per l'AI copre di solito una manciata di capacità fondamentali, ciascuna presa in prestito dal manuale FinOps tradizionale e riorientata verso un nuovo tipo di workload.
Cost allocation. Taggare le istanze GPU come si farebbe con una VM. Mappare API key, modelli e progetti su team, prodotti o clienti. Costruire per un cluster di training la stessa mappa di ownership che si costruirebbe per un namespace Kubernetes.
Showback e chargeback. Produrre report che dicano a un team quanto è costato un training run del proprio modello, o quanto ha speso in inference una determinata feature nell'ultimo mese, esattamente come lo showback funziona da anni per compute e storage.
Unit economics. Tradurre la spesa grezza in un numero su cui il business possa agire: costo per inference, costo per utente attivo, costo per feature, applicando la stessa logica che da tempo esiste per il costo per transazione o per richiesta.
Budget, alert e anomaly detection. Impostare soglie per team o per modello e ricevere una notifica quando il consumo di token o la lunghezza dei prompt sale in modo inatteso, riproducendo gli strumenti di budget e anomaly detection ormai standard nel cloud cost management.
Governance e applicazione delle policy. Definire chi può avviare cosa, con quale modello e con quale tetto di spesa: l'equivalente AI delle quote di risorse e delle policy di tagging.
Per una fetta significativa di workloads AI, questo approccio funziona ancora bene. Un cluster di training dedicato con un owner chiaro. Un endpoint di inference single-tenant al servizio di un solo prodotto. Un modello con un pattern di chiamata prevedibile e tracciabile. Lo si tagga, lo si monitora, fine.
Dove il manuale regge e dove no
I problemi cominciano con i workloads che non hanno queste caratteristiche, e sempre più spesso sono la maggioranza.
L'infrastruttura condivisa manda in crisi il modello di ownership
Un account API di modelli gestiti serve regolarmente decine di team da un'unica riga di fatturazione. Nella fattura in sé non c'è alcun confine per team: c'è solo ciò che si riesce a ricostruire a posteriori a partire da metadati che possono essere affidabili o meno. Un cluster GPU condiviso esegue inference per più prodotti in parallelo, con cicli di compute intrecciati a un livello che nessun tag riesce a vedere.
I gateway cancellano il segnale su cui il tagging si regge
Un gateway LLM aggrega richieste provenienti da agenti, pipeline automatiche e utenti umani in un unico flusso in uscita e, nel farlo, elimina l'identità del chiamante da ciò che arriva al provider. Quando la richiesta raggiunge il modello, il contesto che permetterebbe di attribuirla a un team o a una feature è spesso già andato perso. I tag applicati a monte non sopravvivono al passaggio.
I workloads agentici generano costi che nessun SDK ha mai avvolto
Un workload agentico può generare sub-agenti che innescano costi infrastrutturali reali — compute, memoria, rete, carico sul database — senza alcuna relazione con la voce di spesa AI originaria da cui sono partiti. Non esiste tag o convenzione di naming che ricolleghi tutto questo alla richiesta che ha avviato la catena, perché quella catena non era stata prevista quando è stata costruita l'instrumentation.
L'instrumentation non tiene il passo dell'infrastruttura AI
Il problema di copertura è solo metà della questione. I workloads AI si muovono a una velocità che l'instrumentation non riesce a inseguire. Un agente può generare mille sub-agenti nell'arco di una notte. Quando l'engineering ha identificato il nuovo pattern di chiamata, l'ha racchiuso in un SDK e ha rilasciato l'aggiornamento, la fattura è già arrivata. Non è un problema di disciplina di tagging risolvibile con una governance migliore o convenzioni di naming più rigide. È una realtà architetturale di come l'infrastruttura AI funziona davvero, ed è indipendente dal livello di disciplina della pratica FinOps.
Il problema della spesa orfana
Si parli con un qualsiasi practitioner FinOps sei mesi dopo l'avvio di un programma sui costi AI e si sentirà una versione della stessa storia: una voce di spesa cresciuta del 40 percento mese su mese, senza alcun owner rintracciabile. I tag puntano a un service account condiviso tra tre team. La convenzione di naming che funzionava per le VM non è mai stata applicata agli endpoint di inference. Qualcuno ha messo insieme a mano un foglio di calcolo per ricostruire l'ownership, ed è già obsoleto nel momento in cui viene chiuso.
Quella spesa non è senza owner. È non attribuita, perché il metodo usato per rintracciarla è stato pensato per un'infrastruttura che non si muove, non si condivide e non genera figli a runtime. L'infrastruttura AI fa tutte e tre le cose.
FinOps per l'AI vs. FinOps cloud tradizionale
| FinOps cloud tradizionale | FinOps per l'AI | |
|---|---|---|
| Metodo di attribuzione principale | Tag, convenzioni di naming, struttura degli account | I tag funzionano finché non entrano in gioco infrastrutture condivise o gateway |
| Stabilità dell'infrastruttura | Relativamente statica; l'ownership è di solito chiara | Altamente dinamica; l'ownership può cambiare a metà richiesta |
| Lacune di copertura | Per lo più un problema di disciplina di tagging | Architetturale: alcuni workloads non sono taggabili affatto |
| Velocità di cambiamento | Cicli di cambiamento prevedibili e governati | Può cambiare da un giorno all'altro, più in fretta di quanto si riesca ad aggiornare l'instrumentation |
| Dove va in crisi | Casi limite, risorse legacy | Cluster GPU condivisi, gateway LLM, workloads agentici e multi-agente |
Cosa arriva dopo: misurare sotto il livello del tag
Se l'architettura dei workloads AI batte l'instrumentation per progetto, allora l'instrumentation è il livello sbagliato da cui misurare. L'alternativa è misurare da un punto che non si può aggirare, filtrare o sopravanzare in velocità: il kernel.
È questa l'architettura alla base di Attribute™ by DoiT. Distribuisce un sensore eBPF all'interno del sistema operativo che osserva il consumo effettivo — ogni token, ogni richiesta al modello, ogni ciclo GPU — nel momento in cui avviene, e mappa ciascuna unità sul processo, sul container e sulla richiesta che l'ha generata. Nessun tag. Nessun SDK. Nessuna modifica al codice. Poi unisce quei dati alla fatturazione dei provider Anthropic, OpenAI, Google Gemini e AWS Bedrock, suddividendo automaticamente token in cache, di reasoning, di input e di output.
È il livello in cui la Tokenomics diventa operativa: economics a livello di token, attribuiti automaticamente, per quei workloads che il tagging non sarebbe mai stato in grado di raggiungere. Tokenomics senza tag, senza SDK, senza modifiche al codice.
Perché tutto questo conta adesso
La nostra ricerca — un sondaggio condotto da Sapio Research su 500 leader finance — ha rilevato che il 79 percento delle aziende ha già registrato sforamenti di costo legati all'AI, e solo il 15 percento riesce a calcolare il ROI dell'AI senza colli di bottiglia significativi. Il divario non è un problema di processo che i team non hanno ancora avuto modo di sistemare. È un problema di misurazione che, per essere risolto, richiede un livello diverso.
DoiT ha gestito oltre 8 miliardi di dollari di spesa cloud per 4.500 clienti in 27 Paesi, e abbiamo già visto questo schema in ogni grande categoria di costo — ottimizzazione del compute, gestione dei commitments, cost allocation su Kubernetes. I team che sistemano da subito le fondamenta della misurazione rendono migliore ogni decisione successiva. I team che aspettano passano anni a ricostruire un contesto che avrebbero potuto avere dal primo giorno.
Stiamo collaborando con la Tokenomics Foundation, insieme a JR Storment e alla FinOps Foundation, per contribuire a definire come debbano essere queste fondamenta per l'intero settore.
FAQ
Cos'è il FinOps per l'AI?
Il FinOps per l'AI è l'applicazione delle pratiche di cloud financial management — cost allocation, showback e chargeback, unit economics, budget e anomaly detection — ai workloads di machine learning e AI generativa. Estende alla nuova categoria di spesa la disciplina che ha funzionato per l'infrastruttura cloud tradizionale.
Perché il tagging non funziona per l'attribuzione dei costi AI?
Il tagging si regge su una relazione stabile e tracciabile tra una risorsa e il suo owner. Cluster GPU condivisi, gateway LLM e workloads agentici rompono questa relazione per progetto: i gateway cancellano l'identità del chiamante, l'infrastruttura condivisa non ha un confine di ownership netto e le catene agentiche generano costi a cui non è mai stato applicato alcun tag.
Qual è la differenza tra FinOps per l'AI e Tokenomics?
Il FinOps per l'AI descrive la pratica di applicare la disciplina di cost management ai workloads AI. La Tokenomics è la disciplina di misurazione sottostante: capire quanto vale ciascun token, chi l'ha consumato e se la spesa sia stata giustificata dal risultato, a prescindere dal fatto che il workload sia taggabile o meno.
Si può fare FinOps per l'AI senza instrumentation?
Sì. La misurazione a livello di kernel, con tecnologie come eBPF, osserva il consumo a livello di sistema operativo anziché dipendere da tag o SDK. Questo consente l'attribuzione anche per i workloads che l'instrumentation tradizionale non riesce a raggiungere, inclusi i cluster GPU condivisi e il traffico instradato dai gateway.
Chi è responsabile del FinOps per l'AI all'interno di un'organizzazione?
Dipende dall'azienda, ma il FinOps per l'AI si colloca tipicamente all'intersezione tra il team FinOps o cloud cost esistente, il platform o infrastructure engineering e, sempre più spesso, i team che costruiscono direttamente prodotti AI. Poiché la spesa AI si muove più in fretta e coinvolge più team rispetto alla spesa cloud tradizionale, questa pratica richiede una collaborazione tra finance ed engineering più stretta di quella richiesta dal FinOps legacy, perché nessuna delle due parti ha, da sola, piena visibilità.
In cosa la cost allocation dell'AI è diversa dalla cost allocation cloud?
La cost allocation cloud, in genere, mappa la spesa su una risorsa con un owner relativamente stabile: un'istanza, un bucket, un namespace. La cost allocation dell'AI deve invece tenere conto di consumi che attraversano i confini di ownership all'interno di una singola richiesta — una GPU condivisa che serve più prodotti, un gateway che instrada traffico da più team, un agente che genera costi in servizi che non ha mai toccato direttamente. L'obiettivo di fondo è lo stesso. La meccanica necessaria per raggiungerlo no.
Quali metriche dovrebbe monitorare un programma FinOps per l'AI?
La maggior parte dei programmi monitora una combinazione di costo per token, costo per inference, costo per feature e costo per cliente o account, insieme alla ripartizione tra token di input, output, cache e reasoning, che varia da provider a provider. Il mix giusto dipende dall'audience: l'engineering di solito vuole il dettaglio a livello di workload, mentre il finance chiede aggregazioni a livello di account o di feature, collegate ai dati di ricavi o rinnovi.
Vuole vedere il vero cost-to-serve dell'AI nella sua azienda?
Quindici minuti per l'installazione. Nessuna instrumentation richiesta. Token economics entro fine giornata.