La FinOps Foundation non ha dato vita alla Tokenomics Foundation perché la gestione dei costi dell'AI fosse un problema già risolto a cui bastava dare un nuovo nome. Come ha scritto JR Storment, la token economics è la disciplina con cui il consumo di AI viene misurato, attribuito e collegato ai risultati di business, e la maggior parte delle aziende non dispone ancora di un metodo affidabile per farlo. Nessuno costruisce una nuova disciplina attorno a un problema già risolto.
L'istinto è affrontare la questione come i team hanno sempre affrontato i costi cloud: taggare le risorse, incapsulare le chiamate in un SDK, imporre convenzioni di denominazione. Un approccio che ha funzionato per l'infrastruttura tradizionale, ma non funziona per l'infrastruttura AI. E le ragioni sono architetturali, non procedurali.
Una categoria di approcci più recente, la misurazione a livello kernel tramite eBPF, aggira del tutto il problema della strumentazione osservando il consumo direttamente a livello di sistema operativo, senza tag, SDK o modifiche al codice. È a questo che si riferisce l'espressione "tokenomics senza tag, SDK o modifiche al codice". Vediamo perché l'approccio basato sulla strumentazione non regge e in cosa si differenzia l'attribuzione a livello kernel.
Cos'è l'attribuzione dei costi AI (e perché oggi non funziona)
L'attribuzione dei costi AI è la pratica di ricondurre la spesa AI — cicli GPU, chiamate API ai modelli, consumo di token — al cliente, alla funzionalità, al team o all'agente specifico che l'ha generata. È l'equivalente per l'era AI dell'allocazione dei costi cloud, con una differenza cruciale: l'infrastruttura da misurare non resta ferma abbastanza a lungo perché i metodi tradizionali riescano a coglierla.
L'allocazione tradizionale dei costi si basa sulla strumentazione. Basta taggare una risorsa per sapere chi ne è proprietario. Basta incapsulare una chiamata API in un SDK per sapere quale team l'ha effettuata. Un approccio imperfetto anche negli ambienti cloud tradizionali — la copertura dei tag è un cantiere perpetuo — ma sufficiente, perché l'infrastruttura sottostante è relativamente statica e i confini di proprietà sono relativamente chiari.
L'infrastruttura AI infrange ognuno di questi presupposti.
Un singolo account API di modello gestito serve decine di team in parallelo. Un cluster GPU condiviso esegue workloads di più prodotti contemporaneamente, senza alcun confine di risorsa tra di essi. Un gateway LLM aggrega le richieste di agenti, pipeline e utenti umani in un unico flusso in uscita, cancellando strada facendo l'identità del chiamante. Un agentic workload può generare sub-agenti che innescano costi a valle — compute, memoria, rete — senza alcun collegamento tracciabile alla voce di spesa da cui hanno avuto origine.
Non esiste un tag che sopravviva al passaggio attraverso un proxy LLM. Non esiste un SDK con cui incapsulare una GPU condivisa. E anche là dove la strumentazione potrebbe teoricamente funzionare, i workloads AI si muovono più velocemente di quanto la strumentazione riesca a essere distribuita: un agente può generare mille sub-agenti nel giro di una notte, e la fattura arriva molto prima che qualcuno aggiorni il codice di tracciamento.
Il divario di attribuzione nella spesa AI non è un problema di processo. È una conseguenza strutturale di come funziona realmente l'infrastruttura AI.
Perché gli approcci tradizionali si scontrano con un limite
Gli strumenti pensati per risolvere questo problema rientrano generalmente in una di tre categorie.
Gli strumenti a livello di fatturazione lavorano a posteriori, riconciliando le fatture dei provider in report. Dicono quanto è stato speso, in forma aggregata, molto tempo dopo che il workload che ha generato il costo ha terminato l'esecuzione.
Gli strumenti basati su agent Kubernetes strumentano il livello di orchestrazione, tracciando l'uso delle risorse a livello di pod e container. Funzionano finché il workload resta all'interno di Kubernetes e nei confini di un singolo cluster. Perdono visibilità nel momento in cui una richiesta attraversa un'API gestita, una GPU condivisa o un gateway LLM.
Gli strumenti di inferenza da metadati provano a saltare del tutto il tagging manuale deducendo la proprietà dai metadati disponibili e proponendo automaticamente tag virtuali. Un miglioramento significativo rispetto al tagging manuale, ma con lo stesso limite: possono attribuire soltanto ciò che i metadati esistenti descrivono, e al livello in cui avviene realmente il consumo di AI quei metadati non esistono.
Tutti e tre gli approcci ricostruiscono l'attribuzione a posteriori, a partire da segnali che si collocano sopra il livello in cui il consumo effettivamente avviene. Nessuno può guardare dentro una GPU condivisa. Nessuno può seguire un token attraverso un gateway fino all'agente che lo ha innescato.
Le piattaforme in grado di farlo sono quelle che misurano al di sotto di tutti e tre i livelli, non a fianco: al kernel, dove il consumo viene osservato direttamente anziché dedotto.
Come funziona l'attribuzione a livello kernel
Un approccio a livello kernel distribuisce un sensore eBPF direttamente all'interno del sistema operativo. Il deployment richiede in genere pochi minuti: nessuna modifica al codice, nessuna modifica ai manifest Kubernetes, nessun SDK da integrare.
Una volta attivo, il sensore osserva il consumo reale nel momento in cui avviene: ogni token, ogni richiesta al modello, ogni ciclo GPU, e mappa ciascuna unità sul processo, container, pod e richiesta che ne sono responsabili. Quei dati di runtime possono poi essere incrociati con la fatturazione dei provider da fonti come Anthropic, OpenAI, Google Gemini e AWS Bedrock, separando automaticamente token in cache, token di reasoning, token di input e token di output.
Il risultato è una token economics per cliente, per funzionalità, per agente, prodotta in modo continuo, senza strumentazione, senza tagging e senza modifiche al codice. Poiché il sensore opera al kernel, vede il consumo direttamente. Non c'è nulla da dedurre e nulla dietro cui un agente, un gateway o una GPU condivisa possano nascondersi.
Cosa cambia l'attribuzione a livello kernel per ciascun team
Per i team dei VP of Engineering, l'attribuzione a livello kernel significa un chargeback difendibile. I costi GPU vengono ricondotti al workload che li ha generati, mettendo fine alle dispute di fatturazione tra team che condividono la stessa infrastruttura.
Per i professionisti FinOps significa la fine del foglio di calcolo orfano. I tag decadono. Le convenzioni di tagging diventano obsolete nello stesso istante in cui viene rilasciato un nuovo servizio. La misurazione a livello kernel non dipende dal fatto che qualcuno si ricordi di taggare alcunché.
Per i CFO e i responsabili Finance significa visibilità sul ROI legata a funzionalità specifiche e segmenti di clientela, non a stime a livello di account. Sapere che una funzionalità incide sulla probabilità di rinnovo è un tipo di insight diverso dal sapere quanto ha speso complessivamente l'account il mese scorso.
Perché la questione è urgente oggi
Lo schema si ripete in ogni precedente categoria di costo cloud: ottimizzazione del compute, gestione dei commitments, allocazione dei costi Kubernetes. Le organizzazioni che pongono per tempo le giuste fondamenta di misurazione migliorano ogni decisione successiva. Quelle che rinviano l'attribuzione fino a quando le fatture non sono già ingenti passano anni a ricostruire un contesto che avrebbero potuto avere fin dal primo giorno.
La spesa AI si muove più velocemente di qualsiasi categoria precedente, e i dati lo confermano. Un sondaggio di Sapio Research su 500 responsabili Finance ha rilevato che il 79% delle aziende ha già subito sforamenti di budget legati all'AI, e solo il 15% è in grado di calcolare il ROI dell'AI senza colli di bottiglia significativi. Il momento per costruire le giuste fondamenta è adesso, non dopo la prossima fattura a sorpresa.
L'approccio di DoiT
DoiT gestisce oltre 8 miliardi di dollari di spesa cloud per 4.500 clienti in 27 Paesi e ha visto questo schema di misurazione ripetersi in ogni grande categoria di costo cloud. Attribute™ di DoiT applica l'approccio a livello kernel descritto sopra: un sensore eBPF che si distribuisce in circa quindici minuti, senza tag, senza SDK e senza modifiche al codice, producendo una token economics per cliente, per funzionalità, per agente entro la fine della giornata stessa dell'installazione.
DoiT è inoltre marketing partner della Tokenomics Foundation e collabora con JR Storment e la FinOps Foundation per contribuire a definire standard di settore aperti per la token economics dell'AI, man mano che la categoria matura.
Prenoti una demo per vedere Attribute™ all'opera nel Suo ambiente.