L’adozione dell’AI generativa in ambito aziendale è sempre più spesso raccontata come una questione di capacità dei modelli. Tuttavia, l’esperienza pratica sul campo rivela che il fattore decisivo è il costo, e in particolare la sua prevedibilità.
Con l’adozione di un’AI “a consumo”, che si basa su token, API e infrastruttura cloud, molte imprese si stanno rendendo conto che il costo pubblicizzato del modello è solo un aspetto della questione.
Indice degli argomenti
Selezionare fornitori focalizzati sulla governance
Il costo effettivo si manifesta quando l’AI viene integrata nei processi, ne aumenta la portata e diventa un elemento costante. In questo scenario, la selezione del partner AI non coincide con la scelta del modello più noto, ma con la capacità di governare architettura, responsabilità e misurazione nel tempo. Più che la promessa iniziale, conta la tenuta del sistema quando passa dalla demo alla produzione.
La scelta del fornitore è già una scelta di governance. Un partner affidabile deve saper collegare tecnologia, processi e persone, definendo visibilità sugli output, controlli sugli errori e regole di aggiornamento dei modelli. È la logica richiamata anche dai framework internazionali di gestione del rischio AI, come il NIST AI Risk Management Framework, che propone un approccio strutturato alla gestione dei rischi lungo tutto il ciclo di vita dei sistemi di AI, e da ISO/IEC 42001, standard dedicato ai sistemi di gestione dell’AI. Per i decision maker, il punto critico è semplice: senza governance, il progetto resta esposto a costi opachi, regressioni e perdita di controllo.
| Un segnale operativo utile arriva dalle indagini più recenti: nella survey 2026 di Grant Thornton su 950 leader senior, il 78% degli executive dichiara di non avere forte fiducia nella capacità di superare un audit indipendente di governance AI entro 90 giorni, mentre il 46% indica fallimenti di governance e compliance tra le principali cause di sottoperformance dell’AI. Il dato rafforza una conclusione pratica: il fornitore non va valutato solo sul modello proposto, ma sulla sua capacità di produrre evidenze auditabili, responsabilità chiare e controlli continui. [Grant Thornton] |
Evitare i partner con approcci puramente entusiastici
Da questa premessa discende un primo criterio di selezione. I partner che impostano la relazione solo sull’hype tendono a valorizzare velocità, brillantezza delle demo e capacità generali del modello, ma non chiariscono come l’AI verrà inserita nei workflow aziendali e con quali limiti operativi. È un’impostazione che rischia di spingere l’azienda verso usi indistinti, senza distinguere tra sperimentazione, uso operativo e uso critico.
| Un indicatore di rischio è la proposta che non distingue tra “pilot”, “produzione controllata” e “processo critico”. Nel primo caso bastano limiti di budget e sandbox; nel secondo servono monitoraggio, ownership e metriche; nel terzo diventano indispensabili tracciabilità, piani di risposta agli incidenti, supervisione umana e continuità operativa. |
La maturità non dipende soltanto dalla tecnologia. In Europa, secondo i dati dell’Osservatorio Artificial Intelligence del Politencico di Milano, oltre il 55% delle grandi imprese usa l’AI, contro il 17% delle PMI: un divario che segnala soprattutto differenze organizzative e di competenze. Anche quando l’AI porta risultati concreti, come aumenti delle conversioni tra il 20% e il 30% e riduzioni dei costi operativi fino al 30% nei processi di marketing, il valore emerge dove esistono supervisione umana, dati coerenti e regole di handoff chiare. In altri termini, una buona consulenza AI non promette accelerazione indiscriminata, ma costruisce percorsi misurabili e compatibili con la maturità aziendale.
- Chiedere al partner di mappare i casi d’uso per rischio, valore economico e impatto sulle persone.
- Separare le attività esplorative dai workflow che producono effetti su clienti, fornitori, dipendenti o compliance.
- Verificare se esiste un registro dei prompt, dei dataset, delle versioni modello e delle modifiche ai workflow.
- Pretendere una matrice di responsabilità che includa business owner, IT, legale, sicurezza, procurement e funzione finance.
- Stabilire fin dall’inizio quando l’AI deve fermarsi e passare a revisione umana.
Anche la prudenza sugli upgrade rientra in questo criterio. Nei sistemi reali, i nuovi modelli possono introdurre allucinazioni, regressioni e instabilità nei workflow. Se il partner non prevede versioning, fallback, controlli sull’output e una separazione rigorosa fra ambienti di test e produzione, l’azienda rischia di pagare due volte: prima per adottare, poi per correggere. In assenza di questo presidio, la consulenza diventa una fonte di complessità invece che uno strumento di riduzione del rischio.
Il tema diventa ancora più rilevante con i sistemi agentici. La ricerca 2026 di Grant Thornton rileva che quasi tre organizzazioni su quattro stanno dando ad agenti AI accesso a dati e processi, ma solo una su cinque dichiara di avere un piano di risposta testato per i fallimenti dell’AI. Questo dato suggerisce che, prima di autorizzare automazioni con accesso a sistemi aziendali, il fornitore dovrebbe dimostrare come limita i privilegi, monitora deviazioni, registra decisioni e ripristina uno stato sicuro in caso di errore. [Grant Thornton]
Richiedere dimostrazioni di calcolo del TCO preventivo
Lo stesso approccio deve riflettersi nel modo in cui viene presentato il costo. Limitarsi al prezzo per milione di token è fuorviante, perché il TCO dipende dall’interazione tra modello, workflow e volumi reali.
All’interno dei processi aziendali, l’LLM può essere invocato più volte nel medesimo flusso di lavoro per interpretare ingressi, recuperare informazioni, coordinare strumenti esterni e convalidare l’esito finale. Ogni passaggio genera nuovi token e quindi nuova spesa.
La FinOps Foundation segnala che i costi AI richiedono nuove metriche di controllo, come:
- costo per token
- costo per inferenz
- costo per chiamata API
- efficienza di utilizzo GPU
- anomaly detection rate
- tempo al valore
La stessa fonte raccomanda di tracciare regolarmente costi e utilizzo, impostare quote, taggare o attribuire le risorse e collegare la misurazione finanziaria agli outcome di business. In pratica, il TCO non è un foglio Excel statico: è una disciplina di controllo continuo. [FinOps Foundation]
| Voce di costo | Domanda da porre al fornitore | Rischio se manca la risposta |
| Token input e output | Quanti token medi e di picco genera ogni fase del workflow? | Budget sottostimato e costi non attribuibili ai singoli processi. |
| Chiamate iterative | Quante chiamate LLM servono per completare una pratica end-to-end? | Moltiplicazione dei costi rispetto al listino del singolo modello. |
| RAG e ricerca vettoriale | Quanto costa indicizzare, aggiornare e interrogare basi documentali? | Costi di storage, embedding e retrieval esclusi dalla stima iniziale. |
| Ambienti di test | Quali limiti di consumo e quali dataset separati sono previsti? | Spesa sperimentale che si confonde con quella di produzione. |
| Monitoraggio e audit | Chi paga logging, dashboard, alert, revisione output e incident response? | Controlli ridotti proprio quando il sistema scala. |
| Fallback e multi-modello | Qual è il costo di mantenere alternative tecniche attive? | Dipendenza da un solo provider e maggiore esposizione a rincari o outage. |
Componenti da includere in una stima preventiva del TCO AI prima della firma del contratto.
I dati disponibili mostrano bene il disallineamento fra listini e costo totale. Nei 18 mesi osservati, il prezzo di input di OpenAI è passato da circa 10 dollari per 1 milione di token con GPT-4 e GPT-4 Turbo nel Q2 2024 a circa 2,50 dollari con GPT-4o nel Q4 2024, fino a circa 1,25 dollari con GPT-5 nel Q3 2025 e GPT-5.1 all’inizio del Q4 2025. Ma a fine Q4 2025, con GPT-5.2, il costo di input è risalito a 1,75 dollari e quello di output a 14 dollari per 1 milione di token, rispetto ai 10 dollari delle versioni precedenti. L’inversione è collegata alla maggiore capacità di calcolo, soprattutto sull’output. Nel confronto riportato tra GPT-5.2 e Gemini 3 Pro, l’input è indicato rispettivamente a 1,75 e 2,00 dollari per 1 milione di token, l’output a 14 e 12 dollari, mentre per Gemini 3 Pro l’output sale a 18 dollari oltre i 200k token di contesto. Sono differenze che incidono direttamente quando i processi scalano.
| Nel 2026 la visibilità dei costi AI sta diventando una metrica di governance. Secondo analisi recenti di settore, la difficoltà non è solo spendere meno, ma attribuire token, chiamate API e GPU hour a team, prodotti, feature o clienti. Senza questa attribuzione, il CFO vede un aumento della fattura, ma non sa quale processo lo abbia generato né se il valore prodotto sia proporzionato. [Finout] |
Il TCO, quindi, va stimato ex ante includendo almeno implementazione, integrazione, orchestrazione, monitoraggio, manutenzione, aggiornamenti e supporto, oltre ai costi nascosti legati a contesti persistenti, reasoning token e chiamate iterative. Come mostrato nell’analisi sui costi reali dell’AI in azienda, lo stesso contesto può essere conteggiato più volte a ogni chiamata API, anche se non cambia, e nei processi articolati questo meccanismo può far crescere rapidamente la spesa.
Per evitare stime teoriche poco utili, una valutazione credibile richiede ipotesi esplicite sui volumi, separazione fra test e produzione, uso di caching e riuso dei risultati intermedi, oltre alla scelta di riservare i modelli più costosi solo ai task ad alto valore.
Strutturare contratti basati su KPI misurabili
Una volta chiariti governance e TCO, la questione si sposta sul contratto. In un progetto AI il contratto non serve solo a formalizzare un acquisto: è uno strumento di governo del rischio, perché traduce aspettative generiche in metriche verificabili, responsabilità e criteri di intervento. I materiali di ricerca sottolineano che una dashboard efficace deve integrare metriche di business, metriche tecnologiche e indicatori di impatto sulle persone.
Questo è particolarmente rilevante quando l’adozione richiede change management, AI literacy e il coinvolgimento dei middle manager per ridurre attriti e resistenze.
La dimensione persone non è secondaria. Nella survey 2026 di Grant Thornton, il training risulta tra le aree di investimento AI più sottofinanziate, mentre frontline employee e middle manager sono indicati come gruppi che necessitano di maggiore supporto operativo. Il contratto dovrebbe quindi misurare anche adozione, qualità dell’handoff uomo-macchina, tempo di revisione e carico di controllo, non solo throughput tecnologico. [Grant Thornton]
In termini pratici, i KPI non dovrebbero essere definiti dopo l’avvio, ma prima della firma. Se il fornitore non sa spiegare come misurerà accuratezza, affidabilità, tempi di risposta, tasso di fallback, numero di escalation manuali o stabilità del workflow, l’azienda resta esposta a valutazioni arbitrarie. La misurazione serve proprio a evitare che un progetto apparentemente efficiente nasconda costi operativi crescenti o un aumento del carico umano di controllo.
| Area KPI | Metrica concreta | Perché conta nel contratto |
| Qualità | Accuratezza, hallucination rate, tasso di output respinti | Evita che l’efficienza apparente scarichi errori sui team umani. |
| Operatività | Tempo medio di risposta, disponibilità, tasso di fallback | Misura la continuità del servizio nei workflow reali. |
| Economia | Costo per inferenza, costo per pratica, costo per cliente o feature | Collega la spesa AI al valore prodotto e alla marginalità. |
| Governance | Percentuale di decisioni tracciabili, audit log completi, incidenti chiusi | Permette di dimostrare controllo, responsabilità e conformità. |
| Adozione | Utenti formati, utilizzo effettivo, escalation corrette | Verifica che la tecnologia sia integrata nel lavoro quotidiano. |
| Resilienza | Tempo di ripristino, test di fallback, piani di risposta provati | Riduce il rischio di blocchi, regressioni e dipendenza operativa. |
Esempi di KPI contrattuali per trasformare un progetto AI in un sistema misurabile e governabile.
Legare i compensi alla riduzione degli errori di processo
Su questa base diventa ragionevole discutere anche di modelli di remunerazione più allineati agli outcome. Non si tratta di trasformare ogni iniziativa in un pay for performance rigido, ma di collegare almeno una parte del compenso a soglie verificabili di qualità del processo.
Se l’obiettivo dichiarato è ridurre errori, tempi morti o rielaborazioni manuali, il contratto dovrebbe prevedere milestone e criteri di verifica coerenti con questi risultati.
| Una clausola efficace non remunera “l’uso dell’AI”, ma il miglioramento osservabile del processo: meno errori, meno rielaborazioni, tempi di risposta più stabili, costi unitari sotto controllo e maggiore capacità di spiegare le decisioni automatizzate. |
Si richiama un principio utile: l’AI va classificata in base al tipo di impatto atteso, distinguendo fra soluzioni orientate all’efficienza quotidiana, ottimizzazioni più ampie e iniziative che cambiano il modello operativo. Di conseguenza, anche i KPI vanno adattati. Per un workflow continuo, per esempio, il valore può essere osservato nella riduzione degli errori di processo, nel minor numero di escalation manuali, nella stabilità del servizio e nella prevedibilità dei consumi cloud. Il vantaggio di questa impostazione è che sposta la relazione con il fornitore dal piano dichiarativo a quello dell’accountability misurabile.
Per rendere questi obiettivi verificabili, il contratto può distinguere tra metriche di risultato, metriche di controllo e metriche di apprendimento. Le prime guardano al business, le seconde alla sicurezza operativa, le terze alla capacità del sistema di migliorare senza introdurre regressioni.
Esigere clausole di portabilità per evitare il vendor lock-in
L’ultimo passaggio riguarda la continuità. Anche un progetto ben governato può diventare fragile se lega dati, configurazioni e logica di workflow a un solo vendor. Per questo la portabilità non è un dettaglio contrattuale: è una tutela economica e strategica che consente di cambiare modello, fornitore o architettura senza perdere l’investimento fatto.
Dal punto di vista operativo, le clausole dovrebbero coprire dati, configurazioni dei flussi, prompt o regole operative, documentazione tecnica e standard di esportazione. In assenza di questi elementi, un cambio di piattaforma può trasformarsi in una reimplementazione completa, con tempi, costi e rischi superiori a quelli previsti all’inizio. Il tema è particolarmente sensibile nei contesti dove l’AI viene orchestrata su più strumenti o in logiche agentiche, perché la dipendenza non riguarda solo il modello ma l’intero stack.
La portabilità si collega anche alla resilienza tecnica. Versioning, fallback e approcci multi-modello riducono il rischio di regressioni quando un provider aggiorna i propri sistemi o modifica i listini.
| Una clausola anti lock-in dovrebbe prevedere anche tempi massimi di consegna degli export, assistenza alla migrazione, continuità dei log per finalità di audit e divieto di trattenere configurazioni essenziali come proprietà esclusiva del fornitore quando sono state sviluppate per il workflow del cliente. |
Partecipa alla community