Lo scorso trimestre una CFO ha posto alla propria responsabile finanziaria una domanda semplice: quale cliente sta facendo lievitare la nostra fattura OpenAI? La responsabile finanziaria aveva una strategia di tagging, uno strumento FinOps e la fattura mensile di OpenAI. Eppure non è riuscita a rispondere. La fattura mostrava un unico numero. Il sistema di tagging non aveva nulla a cui agganciarsi. Il codice applicativo chiamava direttamente l'API e restituiva un completamento. Nessun centro di costo. Nessun ID cliente. Nessun feature flag. Solo token in ingresso, token in uscita e una voce di spesa a fine mese.
È questa la lacuna di attribuzione che la spesa AI ha aperto all'interno del FinOps Framework. L'Allocation, come capability, è nata per compute e storage, dove dietro a ogni risorsa c'è un tag, un progetto o un account. Una chiamata a token non ha nulla di tutto ciò. L'unità di spesa, la singola richiesta API, non porta con sé i metadati su cui il tagging si regge. Se i team FinOps vogliono rispondere a domande sui costi per cliente, per funzionalità o per agente, l'attribuzione deve spostarsi dal livello di billing al livello di traffico.
Perché il tagging non risolve l'attribuzione dei costi AI?
Il tagging fallisce sulla spesa AI perché una chiamata a token non ha alcuna etichetta a cui applicare un tag. L'Allocation cloud tradizionale funziona così: si applica il tag team=platform a un'istanza EC2 e, per ogni ora in cui l'istanza è in esecuzione, il costo confluisce sul team platform. Il tag risiede sulla risorsa. La risorsa genera il costo. La catena non si spezza.
Con le API AI le cose non funzionano così. Quando la sua applicazione chiama openai.chat.completions.create(), non esiste alcuna risorsa da taggare. Ci sono una richiesta, una risposta e un conteggio di token registrato sul lato OpenAI. Il suo cloud provider non lo vede. Il suo sistema di tagging non lo intercetta. A fine mese OpenAI le invia un'unica fattura per organizzazione, a volte suddivisa per modello, e questo è tutto l'universo informativo a disposizione.
La FinOps Foundation definisce l'Allocation come una capability fondamentale, ma il framework presuppone l'esistenza di un'unità taggabile. Per i provider AI in stile SaaS quell'unità non c'è. Anthropic e Bedrock hanno la stessa forma. I dashboard dei provider ripartiscono la spesa per API key o per modello, non per il cliente o la funzionalità che ha generato la richiesta. E anche suddividendo le API key per team, non si possono suddividere per cliente senza creare migliaia di chiavi e gestirle come un directory service.
Ecco perché i professionisti FinOps che prendono il playbook del tagging su EC2 e lo applicano a OpenAI si ritrovano con la stessa risposta da cui era partito il loro CFO: un totale. Nessuna allocazione.
Tre team, tre domande, un'unica fattura
La stessa fattura AI fa nascere tre domande diverse dentro un'azienda, e a nessuna si può rispondere partendo dai soli dati di billing del provider.
Finance vuole capire le unit economics. Quanto costa servire ogni singolo cliente? Se un cliente top-tier genera 40 dollari di chiamate Claude al mese e ne paga 99 di abbonamento, il quadro dei margini è ben diverso da quello di un cliente che genera 2 dollari di chiamate. Senza attribuzione per cliente, il calcolo del margine lordo resta a livello di stima.
Product vuole il ROI a livello di funzionalità. Quali funzionalità giustificano la spesa in token? Una funzione di summarization può sostenere la retention e costare 8.000 dollari al mese. Un agente sperimentale può costarne 22.000 al mese ed essere usato da 40 persone. Product non può fissare le priorità senza sapere quale funzionalità è responsabile di quale porzione della fattura.
Il CFO vuole sapere perché il numero è cambiato. Quando la fattura Anthropic raddoppia da un mese all'altro, qualcuno deve spiegarlo. È stato un nuovo cliente? Una modifica al prompt? Un agente fuori controllo che entra in loop su se stesso? La fattura non lo dice. Mostra solo il totale.
I dati di billing grezzi caricati in un dashboard FinOps non rispondono a nessuna di queste domande. Si limitano a ripresentare la fattura. È un livello di reporting, non un livello di Allocation. Il FinOps Framework considera Automation, Tools, & Services il software che abilita le Capabilities, inclusa l'Allocation per le nuove categorie di spesa. Per l'AI quell'automazione deve entrare dentro la richiesta stessa, perché è lì che vive il contesto di business.
Cosa fa concretamente l'attribuzione a livello di traffico?
L'attribuzione a livello di traffico legge ogni richiesta AI nel momento in cui avviene e associa il conteggio dei token al cliente, alla funzionalità e all'agente che l'hanno generata. Invece di provare a ricostruire l'attribuzione da una fattura aggregata, cattura il contesto nell'istante in cui la richiesta parte, prima che quel contesto svanisca.
Ecco come funziona nella pratica. La sua applicazione chiama Claude con un prompt. La richiesta attraversa un gateway o un proxy che ispeziona il payload e vi applica l'ID cliente estratto dal token di autenticazione, il nome della funzionalità dal path della richiesta e l'identificatore dell'agente dal servizio chiamante. La richiesta prosegue verso Anthropic. La risposta torna indietro. Il gateway registra i conteggi dei token sulle dimensioni taggate. A fine mese non ha un unico numero da Anthropic: ha migliaia di eventi attribuiti, raggruppabili per qualunque business unit le interessi.
Questo approccio funziona su OpenAI, Anthropic e Bedrock perché il pattern di traffico è lo stesso. Ogni provider restituisce il conteggio dei token nella risposta. Ogni richiesta porta con sé il contesto applicativo. La logica di attribuzione si colloca tra il suo codice e il provider, quindi non deve riscrivere il codice applicativo per aggiungere tag. Se vuole il costo per cliente, lo ottiene. Se vuole il costo per agente, lo ottiene.
È un modello più vicino all'observability che al tagging. Ed è anche il motivo per cui gli strumenti sono diversi. Uno strumento FinOps basato sui tag vuole ingerire un file CUR. Uno strumento di attribuzione a livello di traffico vuole stare lungo il percorso della richiesta. Architetture diverse, capability diverse. Per un approfondimento sul perché questo cambiamento conta, veda la nostra analisi precedente in Perché il FinOps tradizionale non regge con i workloads AI.
Come si colloca tutto questo nel FinOps Framework
L'attribuzione dei costi AI non è un nuovo dashboard. È una nuova Allocation Capability per una categoria di spesa che non rientra negli assunti attuali dell'Enterprise Architecture. Il FinOps Framework è stato progettato pensando a risorse taggabili. Compute, storage, network e database hanno tutti identificatori su cui gli strumenti possono raggruppare. La spesa per le API AI no. L'unità di consumo è il token, e i token vivono dentro le richieste, non sulle risorse.
Ciò significa che l'attribuzione AI appartiene al livello Automation, Tools, & Services del framework, ma con un pattern implementativo diverso da quello dell'Allocation basata sui tag. Invece di ingerire billing export e raggrupparli per tag, gli strumenti leggono il traffico in tempo reale e generano record di attribuzione che alimentano la Allocation Capability. Per un utente del reparto finance il risultato appare identico: un costo per team, per cliente, per funzionalità. Ma il meccanismo sottostante è diverso.
Questo pesa su come i professionisti FinOps pianificano la propria toolchain. Se sta costruendo una practice FinOps per l'AI sopra uno strumento basato sui tag, si scontrerà con lo stesso muro contro cui si è scontrata la responsabile finanziaria del CFO. Se sta valutando uno strumento per l'attribuzione AI, la domanda da porsi non è "riesce a ingerire la mia fattura OpenAI?". Lo fanno tutti. La domanda è "riesce ad attribuire la mia fattura OpenAI?". E questo richiede strumentazione a livello di traffico, non ingestione del billing.
Vale la pena rileggere la pagina Capabilities del FinOps Framework tenendo in mente i workloads AI. Anomaly Management, Allocation e Forecasting presuppongono tutte che l'attribuzione esista. Per la spesa AI, l'attribuzione è l'input che manca.
Frequently asked
questions
Come attribuire la spesa OpenAI o Anthropic a un cliente specifico?
Deve catturare l'ID cliente nel momento in cui la richiesta viene effettuata, perché la fattura del provider non lo include. Ciò significa strumentare il traffico tra la sua applicazione e il provider, tramite un gateway, un proxy o un wrapper SDK, così che ogni conteggio di token possa essere registrato a fronte di un identificatore cliente.
Perché il tagging non risolve l'attribuzione dei costi AI?
Il tagging richiede una risorsa a cui agganciarsi. Le chiamate a token verso OpenAI, Anthropic o Bedrock non creano una risorsa taggabile nel suo account cloud, quindi non c'è nulla a cui il tag possa legarsi. Il costo compare come un'unica voce aggregata sulla fattura del provider.
Qual è il costo per funzionalità di un prodotto AI?
È la somma dei costi in token generati dalle richieste provenienti da quella funzionalità, ripartita tra i clienti o le sessioni che l'hanno utilizzata. Lo può calcolare solo se cattura l'identificatore della funzionalità su ogni richiesta nel momento in cui avviene, dato che i dati di billing del provider non includono il contesto di funzionalità.
Come allocano i team FinOps la spesa LLM tra clienti e funzionalità?
Spostano l'attribuzione dal livello di billing al livello di traffico. Invece di provare a suddividere una fattura aggregata a posteriori, catturano il contesto per singola richiesta, cliente, funzionalità, agente, nel momento della chiamata API, e aggregano quegli eventi in report di costo.
Come si tiene traccia dell'utilizzo dei token per agente o workflow?
Serve strumentazione in grado di identificare l'agente o il workflow chiamante su ogni richiesta. Lo si può fare con header di richiesta, identificatori di servizio o un gateway che ispeziona il pattern della chiamata, per poi attribuire i conteggi di token restituiti dal provider all'agente che li ha generati.
La spesa AI ha mandato in crisi il modello del tagging perché una chiamata a token non ha nulla da taggare. Finance, Product e il CFO pongono domande a cui le fatture dei provider non possono rispondere, e nessuna quantità di billing ingestion cambierà questo dato di fatto. L'attribuzione deve spostarsi al livello di traffico, dove ogni richiesta porta ancora con sé il contesto di cliente, funzionalità e agente che dà significato al numero.