Per molti mesi la priorità delle imprese è stata semplice: convincere le persone a usare l’AI. E abbiamo parlato e stiamo parlando ancora di AI adoption. È stata una fase necessaria, quasi inevitabile. E forse ancora non conclusa, anzi ne sono certo, lo vedo ogni giorno nelle aziende quando faccio consulenza. Prima si è lavorato sull’evangelizzazione, poi sull’accesso agli strumenti, poi sulla formazione di base, infine sulla ricerca dei primi casi d’uso. Adesso, in alcuni casi però, nelle organizzazioni più mature si sta aprendo una fase diversa. Il tema non è più solo l’adozione e tipologia di progettualità, ma il governo economico dell’uso.
E sì, proprio governo economico, perché come dicono alcuni grandi report mondiali, i progetti falliscono perché i progetti di AI non sono sostenibili: o costano troppo e nessuno lo aveva correttamente stimato, o costano il giusto ma non creano condizioni di nuovi ricavi.
È qui, in questa valutazione, che entrano in scena i token. Finché restano confinati nel linguaggio degli sviluppatori o nell’utilizzo nascosto degli account dei tools consumer, sembrano un dettaglio tecnico. Quando però il loro consumo inizia a generare voci di spesa visibili, o differenze significative tra team, persone e processi, diventano una metrica di business. E quindi una questione manageriale.
Indice degli argomenti:
Dal pilot alla contabilità dell’AI
Il passaggio sta iniziando come ho scritto più volte Il Wall Street Journal ha raccontato che alcune aziende stanno monitorando il consumo di token per capire dove si crea valore e dove invece si accumula spreco.
In Zapier, piattaforma Saas nota per le automazioni, un utilizzo di token molto superiore alla media non viene letto automaticamente come inefficienza: può indicare un uso confuso degli strumenti, ma può anche segnalare una persona che sta producendo risultati fuori scala.
In altri casi, come quello riportato da Vercel, altra piattaforma saas, un’attività AI con un costo elevato è stata comunque giustificata dal fatto di aver sostituito settimane di lavoro umano.
Il tema della valutazione però resta un punto necessario da trattare: un costo alto, da solo, non dice nulla. Conta, come in altri ambiti ovviamente, il rapporto tra consumo e risultato. È lo stesso passaggio che il cloud ha imposto anni fa, quando la conversazione si è spostata dalla semplice disponibilità delle risorse alla loro allocazione efficiente.
Per l’AI sta accadendo qualcosa di simile, ma con una differenza importante: la risorsa non alimenta solo infrastruttura, alimenta lavoro cognitivo.
I token non sono un dettaglio tecnico
Le piattaforme AI rendono ormai molto chiaro che l’utilizzo viene tariffato per token, con logiche diverse tra input, output, cache e, in alcuni casi, finestre di contesto più ampie o strumenti aggiuntivi. Questo significa che dietro un prompt non c’è un costo astratto, ma una microtransazione che cresce o si riduce in base al modello scelto, alla lunghezza del contesto, alla risposta generata e alla presenza di tool chiamati durante il flusso.
La conseguenza organizzativa è rilevante. Quando ogni interazione ha una struttura di costo diversa, non basta sapere quante persone “usano l’AI”. Serve capire come la usano, per quali attività, con quale frequenza e con quale ritorno. In questo senso la FinOps Foundation osserva che, per gran parte dei workload di AI, i token sono la singola unità di costo più semplice da tracciare e attribuire ai diversi casi d’uso.
Non a caso il tema si sta spostando rapidamente dentro il perimetro del FinOps. Nel report State of FinOps 2026, la gestione dei costi dell’AI emerge come la competenza prioritaria da sviluppare, e il 98% dei rispondenti dichiara di gestire ormai la spesa AI. È un segnale molto netto: il mercato sta trattando l’AI sempre meno come eccezione sperimentale e sempre più come una categoria ordinaria di spesa da governare.
Il paradosso della produttività
E questo è un vero nodo da dover sciogliere. Se un dipendente consuma cinque volte i token dei colleghi, cosa sta succedendo all’interno di quello spazio lavorativo? Sta lavorando male, perché non sa costruire richieste efficaci? Oppure sta eseguendo task più complessi, automatizzando parti del proprio lavoro o ottenendo risultati che gli altri non riescono ancora a produrre?
Stessa cosa vale per processi automatizzati che a un certo punto, su una scala più grande iniziano ad avere un consumo maggiore: sono meglio utilizzati? Sta degradando qualcosa? O semplicemente su una scala grande quell’utilizzo, legato a prompt fatti male, non era stato verificato correttamente?
La tentazione di fermarsi al costo sarebbe un errore. I token, da soli, non misurano produttività. Misurano intensità d’uso di una capacità computazionale. Per diventare una metrica manageriale devono essere letti insieme ad almeno altre tre variabili: il tipo di lavoro svolto, la qualità dell’output e l’impatto generato sul processo.
Un team legale, uno di customer care e uno di sviluppo software possono avere strutture di consumo profondamente diverse, senza che questo indichi automaticamente maggiore o minore efficienza.
Per questo la token governance non può essere una versione aggiornata del controllo dei consumi IT. Deve diventare una disciplina capace di collegare spesa, contesto e risultato esattamente come dico costantemente quando in Zerofive.ai progettiamo e misuriamo processi, definiamo usa case o supportiamo l’analisi di chi vuole capire se realmente l’AI sta generando valore.
Altrimenti si rischiano due errori opposti: lasciare correre costi invisibili finché non esplodono, oppure comprimere l’utilizzo proprio dove l’AI sta generando il maggior vantaggio competitivo. E questo porta comunque un problema all’azienda: la non misurazione, genera inconsapevolezza.
Che cosa dovrebbe misurare davvero un’azienda
La prima metrica è il costo per attività, non il costo per prompt. L’unità minima utile per il management non è la singola interazione, ma il processo che quell’interazione abilita: sintesi documentale, analisi commerciale, supporto clienti, generazione di codice, assistenza interna, redazione di contenuti, ricerca.
La seconda metrica è il costo per output valido. Se dieci prompt producono una risposta utilizzabile e altri venti no, il tema non è soltanto quante chiamate sono state fatte, ma quanto “costo di apprendimento” o “costo di iterazione” il sistema sta assorbendo prima di arrivare a un risultato accettabile.
La terza metrica è il costo per decisione o per tempo risparmiato. In molti contesti il beneficio dell’AI non si traduce solo in meno ore operative, ma in minore latenza decisionale, riduzione degli errori, maggiore copertura informativa o incremento della qualità del servizio. Sono elementi meno immediati da misurare, ma molto più vicini al valore reale.
La quarta metrica è la varianza tra persone e team. Non per costruire classifiche punitive, ma per capire dove esistono pattern replicabili. Un utilizzo molto efficiente potrebbe dipendere da un set di prompt ben progettato, da una migliore integrazione nel workflow o da una competenza tacita che l’organizzazione non ha ancora codificato. In questo senso, la governance non serve solo a tagliare costi: serve a scoprire pratiche ad alto rendimento.
Verso un AI FinOps operativo
Chiamarla token governance , come faccio da tempo, ha senso proprio per questo. Non si tratta di una dashboard di controllo, ma di un layer operativo che mette insieme finanza, tecnologia, operations e responsabilità di business. Alcuni principi sono già abbastanza chiari.
Il primo è l’osservabilità. Dove possibile, le interazioni AI dovrebbero transitare attraverso interfacce comuni, SDK interni o piattaforme che applichino tagging, contesto e attribuzione del consumo ai diversi casi d’uso. La FinOps Foundation sottolinea che, in ambienti decentralizzati, senza standard condivisi diventa molto più difficile attribuire costi e leggere i pattern reali di utilizzo.
Il secondo è la policy. Non basta offrire accesso agli strumenti. Occorre definire quali modelli usare per quali task, quando ha senso passare a modelli più costosi, quali soglie di spesa richiedono revisione e quali attività devono essere automatizzate in modo strutturale anziché lasciate al prompting individuale.
Il terzo è la responsabilità distribuita. La token governance non può essere solo materia del CIO o del procurement. Serve una responsabilità condivisa tra chi governa i budget, chi costruisce l’architettura e chi conosce il valore operativo dei processi. In molte aziende questa convergenza potrebbe spingere la nascita di figure ibride, a metà tra AI product owner, responsabili di processo e funzioni FinOps.
Governare senza frenare
L’errore più probabile, nei prossimi mesi, sarà leggere la token governance come una disciplina di contenimento. Sarebbe riduttivo. Il suo scopo non è minimizzare il numero di token, ma massimizzare il rapporto tra token impiegati e valore generato.
Una richiesta lunga, un contesto ampio o un output costoso non sono di per sé un problema. Possono diventarlo se non esiste un criterio per collegarli ai risultati. Allo stesso modo, un consumo apparentemente basso può nascondere un’adozione superficiale, incapace di produrre impatto reale. La vera maturità non sta quindi nel spendere poco, ma nel sapere perché si spende, dove si spende e che cosa si ottiene in cambio.
Le aziende che stanno entrando in questa fase hanno davanti una scelta precisa. Possono trattare i token come un dettaglio tecnico da lasciare ai team di sviluppo, e allora la spesa AI crescerà in modo opaco. Oppure possono riconoscere che i token sono la nuova unità minima di una economia cognitiva aziendale, e costruire intorno a questa unità metriche, policy e modelli di accountability.
Su questo cambio di approccio, di misurazione e di attenzione, l’AI smette di essere solo uno strumento di produttività individuale e inizia a diventare una infrastruttura di impresa, capace di generare valore.
E quando questo accade, governare i token non significherà più fare contabilità spicciola, ma imparare a leggere, con precisione crescente, quanto costa davvero trasformare capacità computazionale in vantaggio competitivo.
