Un POC di intelligenza artificiale può costare poche centinaia di euro di API e diventare, qualche mese dopo, un servizio aziendale molto più oneroso. Tra i due momenti sono entrati dati da preparare, sistemi da integrare, controlli da costruire, output da verificare, persone da formare. E soprattutto migliaia o milioni di richieste che prima non esistevano.
È su questo passaggio, dal prototipo all’uso ricorrente, che si misura oggi il costo reale dell’AI: quanto costa produrre un risultato aziendale accettabile? Ad esempio un ticket risolto, un documento validato, una pratica elaborata, una modifica software approvata?
La questione riguarda ormai una parte consistente delle imprese italiane. Secondo l’Osservatorio Artificial Intelligence del Politecnico di Milano, nel 2025 il mercato italiano dell’AI ha raggiunto 1,8 miliardi di euro, il 50% in più rispetto al 2024. Il 46% è riconducibile a soluzioni di Generative AI o progetti ibridi. Il 71% delle grandi imprese censite dall’Osservatorio ha avviato almeno un progetto AI, contro l’8% delle PMI.
La crescita rende però più urgente una “contabilità” che molti sistemi informativi non sono ancora attrezzati a produrre. Secondo lo State of FinOps 2026 della FinOps Foundation (sesta edizione dell’indagine che analizza oltre 83 miliardi di dollari di spesa cloud annua) tra le difficoltà indicate compaiono visibilità dei costi, attribuzione alle business unit e determinazione del valore o ROI.
Costo reale dell’AI: perché token e licenze non bastano
Il TCO dell’AI è il costo necessario per progettare, mettere in esercizio, utilizzare, controllare e far evolvere un determinato servizio AI lungo un periodo definito.
Questa definizione può essere declinata secondo almeno tre categorie.
- Ci sono costi iniziali, come sviluppo, integrazione, preparazione dei dati e assessment di sicurezza;
- costi ricorrenti relativamente fissi, dalle licenze alle piattaforme di osservabilità;
- costi variabili, legati a utenti, token, chiamate API, storage, retrieval, tool utilizzati dagli agenti e capacità di calcolo.
Il problema è che sotto la parola “AI” convivono modelli economici differenti. Un copilot SaaS acquistato per utente ha una struttura di costo diversa da un’applicazione costruita sulle API di un foundation model. Un modello ospitato dall’impresa richiede invece di contabilizzare infrastruttura, GPU, personale specializzato, disponibilità della capacità e operazioni del modello.
Metterli sullo stesso piano attraverso il solo “costo dell’AI” produce confronti poco significativi: abbonamenti, consumo dei modelli, infrastruttura, integrazione e tempo umano finiscono in registri e centri di costo differenti.
La fattura del modello è solo una componente
Il listino del modello rimane naturalmente una voce importante. Solo che non è una voce semplice.
La pagina prezzi della Gemini Developer API di Google mostra quanto si sia articolata la fatturazione: input e output possono avere prezzi diversi; esistono modalità standard, batch, flex e priority; il caching ha un prezzo per token e può aggiungere un costo di storage nel tempo; il grounding tramite Google Search può essere fatturato per query dopo una franchigia. Anche la lunghezza del contesto e la modalità dei dati possono modificare il prezzo.
In una sola frase: il costo per milione di token non costituisce da solo una metrica di TCO.
Un agente, per esempio, può chiamare più volte il modello per completare una singola attività. Può interrogare una base documentale, utilizzare uno strumento esterno, valutare il risultato, ripetere un passaggio e infine chiedere l’approvazione di una persona. La fattura finale dipende dal percorso seguito, non soltanto dalla prima richiesta.
C’è poi il rapporto fra costo e qualità. Un modello meno caro può richiedere più retry, escalation o revisioni; uno più costoso può risultare economicamente preferibile se raggiunge con maggiore frequenza la soglia qualitativa richiesta. Non esiste una regola generale: occorre misurarlo sul workload.
La tendenza tecnologica, peraltro, gioca a favore degli acquirenti. L’AI Index di Stanford ha documentato negli ultimi anni una forte riduzione del prezzo dell’inferenza a parità di prestazioni. Ma la diminuzione del costo unitario non garantisce una diminuzione della spesa complessiva: nuovi casi d’uso, reasoning più lungo e sistemi agentici possono moltiplicare i consumi.
Lo stack invisibile: dati, integrazione e osservabilità
Prima che la risposta arrivi all’utente, può attraversare un’infrastruttura con gateway, autenticazione, ricerca, vector database, storage, networking, orchestrazione, sistemi RAG, guardrail, logging, evaluation e via dicendo.
Ognuno di questi elementi consuma risorse oppure richiede licenze e lavoro.
I dati costituiscono una voce ancora più difficile da isolare. Un sistema di ricerca documentale aziendale, per esempio, deve sapere quali documenti indicizzare, chi può consultarli, quando sono diventati obsoleti. Servono pulizia, metadati, gestione delle autorizzazioni, aggiornamento degli indici e controllo delle fonti.
Poi arrivano le integrazioni. Se l’AI deve leggere un CRM, modificare un ordine nell’ERP o aprire una pratica nel sistema di ticketing, l’impresa deve progettare API, identità, permessi, gestione degli errori e tracciamento. Il costo appartiene al caso d’uso anche quando compare nella fattura di un’altra piattaforma.
È precisamente il genere di frammentazione che rende il TCO dell’AI difficile da leggere nei bilanci IT.
Come calcolare il TCO dell’AI per singolo caso d’uso
Un metodo possibile parte da una formula volutamente semplice (in teoria, il problema è trovare i dati):
TCO del periodo = costi diretti del modello + infrastruttura e stack + dati e integrazioni + persone e controllo + sicurezza, governance e compliance + costi di cambiamento
La formula funziona a una condizione: ogni termine deve riferirsi allo stesso caso d’uso, allo stesso periodo e a volumi dichiarati.
I costi iniziali vanno inoltre distribuiti su un orizzonte esplicito. Ammortizzare un progetto pilota su cinque anni quando architettura e modelli potrebbero cambiare dopo dodici mesi restituisce un TCO rassicurante, ma poco utile per decidere.
Primo passo: definire confine, output e responsabile
Il calcolo deve partire dal servizio, non dalla tecnologia.
Supponiamo che un’impresa voglia usare l’AI per classificare documenti ricevuti dai clienti. L’unità economica potrebbe essere il documento correttamente classificato e validato, non la chiamata al modello.
A quel punto occorre fissare il confine: dall’ingresso del documento fino alla registrazione nel sistema aziendale? È compresa la revisione umana? E l’archiviazione? Chi risponde del risultato?
Ogni caso d’uso dovrebbe avere almeno un owner di business, un owner tecnico e un centro di costo identificabile. Senza questi tre elementi, il consumo può essere misurabile tecnicamente e restare economicamente orfano.
Secondo passo: mappare il percorso della richiesta
La richiesta va seguita dall’inizio alla fine.
Per un sistema RAG il percorso potrebbe comprendere autenticazione dell’utente, ricerca delle fonti, recupero dei documenti, costruzione del contesto, chiamata al modello, verifica automatica, eventuale seconda chiamata, presentazione della risposta, controllo umano e logging.
Per un agente il percorso può essere molto più lungo, perché il software decide quali strumenti utilizzare e quante iterazioni eseguire.
La telemetria deve quindi rilevare almeno volume, token, modello, chiamate, retry, strumenti utilizzati, latenza, errori, escalation e intervento umano. Il primo desiderata indicato dagli intervistati dello State of FinOps 2026 per i nuovi strumenti FinOps è proprio un monitoraggio granulare della spesa AI attraverso token, richieste LLM e utilizzo GPU.
I costi condivisi (ad esempio vector database, gateway, piattaforme di osservabilità) devono poi essere ripartiti secondo un criterio stabile: richieste, utenti, capacità riservata o altra misura coerente con il servizio.
Terzo passo: usare metriche unitarie e scenari
Il risultato del calcolo dovrebbe essere espresso in unità che il business possa comprendere:
- costo per output validato;
- costo per pratica o processo completato;
- costo per utente attivo;
- costo per ticket risolto;
- costo per euro di beneficio effettivamente realizzato.
A queste metriche conviene affiancare almeno tre scenari: volume ordinario, picco e crescita.
Se gli utenti raddoppiano, che cosa accade? Se il contesto medio passa da 10.000 a 30.000 token? Se il tasso di retry sale dal 5% al 15%? Se un agente passa da tre a otto chiamate per attività?
Sono domande più utili del prezzo nominale del modello perché misurano l’elasticità economica dell’architettura.
Un esempio puramente illustrativo rende visibile il metodo. Immaginiamo 100.000 documenti validati in un anno. Il servizio sostiene 15.000 euro di consumo AI, 20.000 di infrastruttura e strumenti, 30.000 di gestione dati e integrazioni, 25.000 di revisione e supporto umano, 10.000 di sicurezza e compliance. A questi si aggiungono 60.000 euro di costi iniziali, ammortizzati prudentemente su due anni: 30.000 euro nel periodo.
Il TCO annuale diventa 130.000 euro, cioè 1,30 euro per documento validato.
La fattura del modello rappresenterebbe in questo esempio soltanto 15.000 euro. Non è una percentuale da applicare altrove: è il risultato delle ipotesi dichiarate. È esattamente questo il vantaggio del costo unitario: rende verificabile il ragionamento.
Il tempo umano entra nel conto economico
Una delle voci più facilmente dimenticate è seduta davanti allo schermo con una tastiera e un mouse.
Valutare una risposta, correggerla, approvarla, gestire un’eccezione, mantenere i prompt, formare gli utenti e assisterli sono attività economiche. Si tratta di tempi di verifica e revisione che possono crescere quando la qualità dell’output è insufficiente.
Occorre però evitare l’errore opposto: considerare automaticamente ogni minuto risparmiato dall’AI come un beneficio finanziario.
Trenta minuti liberati nella giornata di un dipendente non equivalgono necessariamente a trenta minuti di costo eliminato. Diventano valore economico quando quella capacità viene riutilizzata per produrre più output, migliorare il servizio, generare ricavi oppure evitare una spesa documentabile.
Il ROI dovrebbe perciò usare benefici osservabili:
ROI = (beneficio economico realizzato − TCO) / TCO
Attenzione al termine “realizzato”: nel calcolo del ROI va considerato soltanto il beneficio economico che l’organizzazione ha effettivamente ottenuto e può documentare, non quello “stimato” nel business case. Se, per esempio, l’AI riduce il tempo necessario per gestire una pratica, il risparmio diventa un beneficio realizzato solo quando quel tempo viene realmente convertito in minori costi, maggiore capacità produttiva, più ricavi o un miglioramento misurabile del servizio.
Energia: un costo reale, ma non una scorciatoia contabile
Anche energia e capacità infrastrutturale entrano nell’economia dell’AI, soprattutto nel self-hosting e nelle decisioni di data center. Sarebbe però scorretto trasformare stime globali in un presunto costo energetico universale della singola richiesta aziendale.
Il rapporto IEA Key Questions on Energy and AI, registra una crescita del 17% dei consumi elettrici globali dei data center nel 2025 e del 50% per quelli focalizzati sull’AI. Nello stesso tempo, secondo l’Agenzia, l’energia consumata per singolo task AI è diminuita di almeno un ordine di grandezza all’anno negli ultimi anni. La difficoltà è che reasoning, video e attività agentiche possono richiedere centinaia o migliaia di volte l’energia di una semplice generazione testuale.
Efficienza crescente e domanda crescente possono convivere. Per attribuire energia e costo a uno specifico servizio aziendale servono invece misure del workload, dell’hardware e dell’ambiente effettivamente utilizzati. E ovviamente non si tratta di metriche calcolabili velocemente.
Dal TCO al valore: il ruolo di FinOps per l’AI
Il passaggio dal TCO alla gestione operativa richiede innanzitutto di rendere i costi leggibili e attribuibili. Lo State of FinOps 2026 mostra infatti che, quando FinOps si estende a nuovi ambiti come l’AI, le organizzazioni danno priorità all’allocazione della spesa, al forecasting e al budgeting, nonché alla raccolta e all’analisi dei dati. Solo su queste basi è possibile ottimizzare i consumi in modo affidabile: senza sapere quale caso d’uso genera una determinata spesa e quale valore produce, ridurre i costi rischia di compromettere il servizio anziché migliorarne l’efficienza.
Applicato all’AI significa collegare telemetria tecnica, listini, tagging, centro di costo e KPI di processo.
Un record utile potrebbe contenere, per ogni richiesta:
- caso d’uso,
- business unit,
- modello,
- quantità di input e output,
- strumenti chiamati,
- retry,
- costo tecnico,
- beneficio associato (ove possibile).
Il livello di dettaglio va naturalmente adattato a privacy, sicurezza e costi di osservabilità.
Da questa base diventa possibile anche il model routing: assegnare richieste differenti a modelli differenti in base a qualità, latenza, rischio e costo. Usare sempre il modello più potente disponibile può essere semplice dal punto di vista architetturale, ma inefficiente economicamente. Usare sempre quello più economico può spostare il costo su errori e lavoro umano.
Le domande da porre prima di estendere l’AI
Prima di passare da un pilota a migliaia di utenti, CIO e business owner dovrebbero riuscire a rispondere a poche domande verificabili:
- Qual è l’output aziendale che stiamo acquistando con questa spesa?
- Quanto costa un output validato, non semplicemente generato?
- Quale livello di qualità rende accettabile l’automazione?
- Quale business unit sostiene il costo e quale riceve il beneficio?
- Quanto tempo umano richiedono verifica, eccezioni e manutenzione?
- Che cosa accade al costo unitario se raddoppiano utenti, contesto, retry o chiamate agentiche?
- Quali costi rimarrebbero anche cambiando modello o provider?
- Quale beneficio economico è stato effettivamente realizzato e quale esiste ancora soltanto nel business case?
La checklist ha anche un valore architetturale. Se non è possibile rispondere perché mancano le informazioni, il problema è di osservabilità, non di ottimizzazione.
Le raccomandazioni per le direzioni IT
Aumentare la visibilità. Il primo compito è costruire un inventario dei modelli e dei servizi AI utilizzati, identificando utenti, applicazioni, volumi e pattern di consumo. La visibilità come punto di partenza; lo State of FinOps 2026 conferma che la granularità del monitoraggio AI è la prima capacità aggiuntiva richiesta agli strumenti FinOps.
Attribuire consumi e responsabilità. Token e GPU senza business owner sono dati tecnici. Collegati a team, prodotti e processi diventano informazioni economiche. Questa attribuzione permette anche di identificare anomalie: un aumento di spesa può essere uno spreco, ma può anche corrispondere a un aumento di attività utile.
Misurare insieme costo e qualità. Prompt, caching, batch e scelta del modello possono ridurre la spesa. L’ottimizzazione va però verificata sul risultato: un taglio del 40% del costo di inferenza perde significato se raddoppiano gli output da correggere.
Separare API, SaaS e self-hosting. Sono tre decisioni economiche differenti. Nel primo caso domina il consumo del servizio e dello stack circostante; nel secondo licenze, utilizzo e integrazione; nel terzo entrano direttamente capacità computazionale, infrastruttura e competenze operative.
Portare il TCO nella progettazione. La FinOps Foundation segnala il pre-deployment architecture costing tra le capacità più richieste. È più efficace simulare costo per unità e scenari prima del rilascio che spiegare una fattura sei mesi dopo.
Il prezzo dei modelli continuerà probabilmente a cambiare, così come cambieranno capacità, unità di fatturazione e architetture. È proprio per questo che un business case costruito sul listino di oggi invecchia rapidamente.
Il TCO più utile, quindi una misura che accompagna il servizio: quanto spendiamo, per produrre quale risultato, con quale qualità e per chi? Queste sono le 4 domande importanti da porsi.
#Adessonews seleziona nella rete articoli di particolare interesse.
Se vuoi leggere l’articolo completo clicca sul seguente link
Gianluca Ferrari
Source link
