Prima di diventare Field CTO in DoiT, lavoravo sul campo come professionista FinOps. Ho scritto policy di tagging. Ho rincorso risorse senza tag la settimana prima della revisione del budget. Ho costruito modelli di chargeback tecnicamente ineccepibili che scatenavano comunque una lite in ogni riunione, perché il cluster condiviso di qualcuno non si ripartiva come voleva il suo conto economico.
Ecco perché, quando questa settimana abbiamo lanciato Attribute™, ho capito subito perché il discorso parte dai token: input, output, cached, reasoning. Costo per richiesta, per cliente, per funzionalità, per agente. È l'inquadramento giusto. Semplicemente, non credo sia completo.
Contare i token è facile. La domanda difficile è: perché quei token sono stati generati? Un cliente ha adottato una nuova funzionalità AI? Un workflow interno è passato in sordina a un modello più costoso? Un singolo prompt sta bruciando dieci volte i token che gli servirebbero? Un agente ha generato centinaia di task a valle che nessuno aveva chiesto? In un report di costo, questi quattro scenari sembrano quasi identici. Per il business, non potrebbero essere più diversi.
Il tagging non è mai stato l'obiettivo
Ecco una cosa che chi lavora sul campo sa bene, ma che raramente si dice ad alta voce: nessuno ha mai voluto i tag. Quello che volevamo era l'accountability — le persone giuste che vedono le informazioni di costo giuste, in tempo per agire. Il tagging era semplicemente la migliore implementazione possibile dell'accountability per l'architettura che avevamo allora. Quando una VM serviva una sola applicazione e un account corrispondeva a un solo team, ownership, consumo e accountability coincidevano. I tag funzionavano perché l'architettura lo consentiva.
Poi l'architettura è cambiata. Kubernetes ha reso l'infrastruttura condivisa. Il serverless l'ha resa astratta. I managed services hanno trasferito la spesa dentro richieste, query e invocazioni. Vadim ha scritto sul perché la strumentazione non regge più e Josh ha spiegato con precisione dove il tagging fallisce, quindi non ripercorrerò qui gli stessi argomenti. In sintesi: ciò che viene fatturato e ciò che genera la domanda si sono allontanati, e l'AI li ha separati del tutto. Un unico account di modello o gateway può aggregare le richieste di ogni prodotto, team, agente e dipendente che avete. Quando arriva la fattura, il contesto che la spiega è già evaporato.
Stesso numero, quattro decisioni diverse
È la parte che mi sta più a cuore, perché è la differenza tra fare reporting e prendere decisioni.
Mettiamo che la vostra spesa AI il mese scorso sia cresciuta del 40%. Dopo anni sul campo, posso dirvi cosa giustifica quel numero preso da solo: nulla. La mossa successiva dipende interamente dal perché è successo.
Se la crescita è dovuta a una funzionalità customer-facing che sta trainando adozione e retention, si investe di più. Non è un problema di costo. È un segnale di crescita travestito da problema di costo.
Se è cresciuta perché un workflow interno usa un modello premium per un compito che un modello più piccolo gestisce benissimo, si ottimizza. È lavoro di ingegneria con un ritorno misurabile.
Se è cresciuta perché un agente sta propagando chiamate a valle non necessarie, si passa alla governance: rate limit, budget, controlli.
E se è cresciuta perché un unico cliente enterprise pesa in modo sproporzionato sui vostri costi di inferenza, non è più nemmeno una conversazione FinOps. Sono pricing, packaging e margine — una conversazione per il CFO e per il team di prodotto.
Quattro cause. Quattro responsabili. Quattro azioni completamente diverse. Il numero di costo non vi dice quale riunione fissare. Ve lo dice il contesto.
È questo che Attribute™ cambia davvero. Poiché misura il consumo reale a livello di kernel e lo incrocia con il billing del provider, il "perché" arriva insieme al numero: questo cliente, questa funzionalità, questo agente, questo workflow. Non perché il conteggio dei token sia il punto, ma perché è l'attribuzione a trasformare un numero in una decisione.
Cosa cambia nella pratica
Nel nostro sondaggio condotto su 500 responsabili finanziari, il 79% aveva già subito sforamenti di costo sull'AI e solo il 15% riusciva a calcolare il ROI dell'AI senza colli di bottiglia significativi. Non lo interpreto come un problema di disciplina. Quei team non stanno fallendo sul fronte FinOps. Stanno applicando il vecchio playbook a un'architettura che lo vanifica.
Ecco cosa credo che ci aspetti, e cosa dico ai clienti sul campo: il FinOps smette di essere una funzione di reporting che ricostruisce il contesto a posteriori e si integra là dove si prendono le decisioni. Gli Engineers vedono le implicazioni di costo mentre progettano, non trenta giorni dopo. I team di prodotto conoscono la unit economics di una funzionalità prima della discussione sul pricing, non dopo. La finanza collega la spesa AI al margine per cliente, invece di fissare un'unica voce indivisibile. I team di piattaforma AI vedono non solo quali modelli hanno girato, ma quali casi d'uso hanno creato valore e quali hanno prodotto sprechi.
Niente di tutto questo funziona senza attribuzione. È il livello su cui poggia tutto il resto del FinOps e, per i workloads di AI, è proprio il livello che ci è mancato finora.
Ho passato anni della mia carriera a ricostruire il contesto dopo l'arrivo della fattura. La prossima era del FinOps consiste nell'averlo prima che il denaro venga speso. È questo che, per me, significa questo lancio.
Quindici minuti per l'installazione. Nessuna strumentazione richiesta. Token economics entro fine giornata. Prenoti una demo per vedere Attribute™ nel Suo ambiente.