In questo articolo vediamo perché la spesa AI, oggi, è quasi impossibile da confrontare tra vendor diversi e cosa si sta muovendo per risolverlo, sulla scia di quanto già successo con il cloud.
Chiedete a tre fornitori diversi cosa sia un token, e otterrete tre risposte diverse. Eppure è l’unità con cui, oggi, si misura buona parte della spesa AI aziendale e su cui, sempre più spesso, si basano decisioni di budget da centinaia di migliaia di euro.
Il problema non è tecnico in senso stretto. È che manca uno standard: un modo condiviso di definire e misurare il consumo, che permetta di leggere una fattura di un vendor con lo stesso metro di un’altra. Senza uno standard, ogni fattura racconta una storia diversa e il confronto, semplicemente, non è possibile.
Non è la prima volta che il settore IT si trova in questa situazione. È già successo con il cloud, ed è già stata trovata una soluzione: vedremo più avanti come.
Un token è, in prima approssimazione, un frammento di testo: in inglese, corrisponde grosso modo a quattro caratteri, o a una porzione di parola. “Understanding” potrebbe essere spezzato in due o tre token; “the” è quasi sempre un token intero. In lingue con caratteri non latini – cinese, giapponese, coreano – il rapporto cambia radicalmente, e la stessa frase può costare due o tre volte i token rispetto all’equivalente inglese.
Fin qui, sembrerebbe un concetto tecnico ma coerente. Il problema è che ogni vendor tokenizza a modo suo. Il modello di un fornitore può contare 100 token dove un altro ne conta 140, per lo stesso identico testo. Non esiste una tabella di conversione universale, perché ogni tokenizzatore è costruito internamente dal vendor, con logiche proprietarie che raramente vengono documentate in dettaglio.
Risultato: due fatture con lo stesso numero di “token consumati” possono rappresentare quantità di lavoro completamente diverse.
Non tutta la spesa AI passa dai token. Molte funzionalità AI incorporate dentro software SaaS più ampi – Adobe Firefly dentro Creative Cloud, Salesforce Einstein dentro il CRM – usano il concetto di credito: un pacchetto di unità che l’azienda acquista in anticipo e consuma nel tempo.
A queste si aggiunge una terza metrica, forse la più familiare a chi si occupa di licensing: il seat, ovvero la licenza a utente nominativo. È il modello con cui vengono venduti strumenti come Microsoft Copilot, ChatGPT Enterprise o Claude Team – un canone fisso per persona assegnata, spesso abbinato a crediti aggiuntivi per l’uso che eccede la soglia inclusa. Potremmo parlare anche di situazioni ibride come Claude Enterprise ma per il momento rimaniamo ancora sulle metriche base, ci torneremo.
Le differenze tra queste tre metriche non sono solo terminologiche, sono contrattuali. I crediti scadono, tipicamente a fine periodo (mensile o annuale) – se non li usi, li perdi. I token, invece, di solito rappresentano un ammontare acquistato che si consuma liberamente, spesso fino alla scadenza del contratto stesso, anche a distanza di anni. I seat seguono ancora un’altra logica: il costo è fisso per persona, indipendentemente da quanto quella persona utilizzi effettivamente lo strumento – un modello familiare a chi gestisce licenze software tradizionali, ma che nella pratica AI convive quasi sempre con un secondo strato di consumo a credito o a token.
Questo significa che due aziende con lo stesso volume di spesa AI possono trovarsi in situazioni di rischio molto diverse: chi lavora a crediti deve gestire attentamente il ritmo di consumo per non sprecare budget già pagato; chi lavora a token ha più flessibilità, ma meno urgenza e quindi, spesso, meno controllo; chi lavora a seat rischia, all’opposto, di non sapere se sta pagando per utenze sottoutilizzate, un problema ben noto nel mondo del software license management ma che nell’AI si somma a tutto il resto.
Ora che abbiamo chiarito le basi riprendiamo, come anticipato, il tema delle situazioni ibride attraverso un esempio concreto che rende bene l’idea di quanto queste tre logiche possano convivere nello stesso contratto. Un bundle come Microsoft 365 E7 include già, in un’unica licenza a seat, l’accesso a Copilot – le cui funzionalità AI, a loro volta, consumano crediti o token man mano che vengono utilizzate. Sulla fattura compare una sola riga di costo, ma dietro convivono almeno due logiche di misurazione diverse: quella fissa del seat, e quella variabile del consumo effettivo. Capire quanto della spesa complessiva dipenda dall’uno o dall’altro fattore – e quindi dove si può intervenire per ottimizzare – richiede di scomporre quel bundle, non di guardarlo come un blocco unico.
Negli ultimi anni il costo per singolo token è crollato – gli analisti stimano un calo di quasi il 99% rispetto ai modelli di prima generazione. Sarebbe lecito aspettarsi che la spesa complessiva sia scesa di conseguenza. È successo l’esatto opposto.
Il motivo è semplice: i modelli più recenti consumano molti più token per svolgere lo stesso compito. Un prompt che un tempo richiedeva poche centinaia di token, oggi – tra contesto conversazionale più esteso, ragionamento più articolato, catene di verifica interne – può arrivarne a consumare decine di migliaia. Al calare del costo unitario, sale la quantità richiesta dalle tecnologie moderne come se le due cose fossero legate senza sapere chi è causa e chi conseguenza. Un po’ quello che è successo negli anni per i processori o lo storage: oggi il costo di un megabyte di storage è molto inferiore a quello degli anni 90, tuttavia anche il solo sistema operativo oggi occuperebbe un migliaio di hard disk dell’epoca.
A questo si aggiunge un secondo moltiplicatore, spesso sottovalutato: gli agenti. A differenza di un utente che fa una domanda e aspetta una risposta, un agente lavora in autonomia, ripete, verifica, richiama il modello più volte per completare un singolo task. Un’attività affidata a un agente può arrivare a consumare 5-10 volte i token di un prompt interattivo equivalente e gli agenti, a differenza delle persone, non smettono mai di lavorare.
Mettete insieme questi tre elementi – tokenizzazione non standardizzata, metriche diverse (token vs crediti vs licenze a seat) e un consumo che cresce nonostante il calo dei prezzi unitari e il risultato è che oggi non esiste un modo affidabile di confrontare la spesa AI tra fornitori diversi.
Non è solo un problema teorico. Significa che un’azienda che valuta se spostare un carico di lavoro da un modello a un altro, o che sta negoziando un rinnovo contrattuale, spesso lo fa senza un termine di paragone reale confrontando cifre che, sulla carta, sembrano comparabili, ma che nella sostanza misurano cose diverse. Chi lavora da tempo nel mondo FinOps riconoscerà questo schema. È lo stesso identico problema che si presentò con l’esplosione della spesa cloud: fatture di provider diversi – AWS, Azure, Google Cloud – con voci di costo, unità di misura e strutture di prezzo completamente diverse tra loro.
La risposta, allora, non fu un tool. Fu una metodologia - il FinOps, nato per allineare finance, tecnologia e business intorno a un modo comune di leggere e gestire la spesa cloud – che a un certo punto ha prodotto anche uno standard tecnico: FOCUS (FinOps Open Cost and Usage Specification), nato dentro la FinOps Foundation, con l’obiettivo di normalizzare i dati di consumo cloud in un formato comune, leggibile allo stesso modo indipendentemente dal fornitore.
Oggi si sta ripetendo lo stesso percorso per l’AI. Nel giugno 2026 è nata la Tokenomics Foundation, promossa dalla Linux Foundation – la stessa organizzazione che ospita la FinOps Foundation – con l’obiettivo dichiarato di costruire uno standard condiviso per l’economia dell’AI. Tra i membri fondatori figurano Microsoft, Google Cloud, Salesforce, ServiceNow e, ovviamente, Flexera.
È presto per dire quanto rapidamente questo standard arriverà a maturazione – la normalizzazione dei consumi cloud, con FOCUS, ha richiesto anni per diventare pratica diffusa. Ma la direzione è la stessa: prima il linguaggio comune, poi gli strumenti che lo useranno.
Flexera, tra le aziende che hanno promosso la nascita della Tokenomics Foundation, ha già fatto proprio questo concetto: nel suo nuovo modulo AI Cost Management di Flexera One ha introdotto il principio della normalizzazione dei consumi, applicando alla spesa AI la stessa logica di comparazione già disponibile sul resto della spesa IT e cloud (ciò che in FinOps chiamiamo unit economics). Non solo, grazie all’introduzione del consumatore AI come elemento alla base dell’analisi (sia esso utente, agente, workflow, service principal o altro), ha potuto inserire anche la stessa logica di attribuzione al fine di sapere non solo quanto si spende, ma chi consuma.
L’obiettivo dichiarato è offrire una visione a 360 gradi della spesa IT, che includa licenze tradizionali, cloud e ora anche AI, in un’unica lettura coerente.
In WEGG, come consulenti FinOps e partner tecnologici di Flexera, condividiamo questo approccio e lo applichiamo ogni giorno: vogliamo far sì che le aziende possano avviare un percorso di attribuzione a partire da dati normalizzati, riportando le diverse unità di misura – token, crediti, seat – a un linguaggio comune. Un lavoro che si traduce in vantaggi molto concreti: scegliere con cognizione di causa tra modelli diversi, negoziare i rinnovi contrattuali su basi comparabili, tenere sotto controllo i costi prima che sfuggano di mano, e sapere finalmente chi spende cosa, e perché.
Del tema parleremo più nel dettaglio nel webinar “Governare i costi AI”, in programma il 27 ottobre. Vai qui per iscriverti!
Approfondimenti
I NOSTRI UFFICI
I NOSTRI UFFICI
PADOVA
Via Arnaldo Fusinato 42, 35137
MILANO
Viale Enrico Forlanini 23, 20134
ROMA
Viale Giorgio Ribotta 11, 00144
Copyright © 2025 WEGG S.r.l. • P.I 03447430285 • C.F. 02371140233 • REA 311023
Azienda Certificata ISO 9001:2015 – ITA / ISO 9001:2015 – EN
