- Come calcolare il ROI dell’AI?
- Quali costi di governance includere?
- Come misurare un outcome verificato?
Il nuovo problema non è comprare AI, ma dimostrarne il valore
Il dibattito sull’AI nel supporto sta cambiando. Dopo la fase dei prototipi, la domanda del management non è più soltanto «funziona?», ma «vale ciò che costa, anche quando includiamo controllo e rischio?». Il segnale più recente arriva dal FinOps Framework 2026: la FinOps Foundation ha introdotto l’Executive Strategy Alignment per collegare investimenti tecnologici, priorità aziendali e decisioni di portafoglio. Lo stesso aggiornamento richiama esplicitamente la collaborazione con ITSM, ITAM, IT Financial Management, sicurezza ed enterprise architecture.
Il State of FinOps 2026 riferisce inoltre che il 98% dei partecipanti gestisce ormai spesa AI, contro il 31% di due anni prima, e indica l’AI cost management come principale competenza da sviluppare. Il dato descrive il campione della community FinOps, non l’intero mercato; resta però un’indicazione chiara: il costo dell’AI sta uscendo dal laboratorio ed entra nella gestione ordinaria.
Per il Service Desk questo passaggio è decisivo. Un chatbot può ridurre contatti semplici, un copilota può accorciare la diagnosi, un agente può eseguire una remediation. Ma una riduzione del volume non equivale automaticamente a valore: il lavoro può riapparire come escalation, ricorrenza, controllo manuale o insoddisfazione.
Dal registro di conformità a una mappa economica
L’articolo precedente proponeva di inventariare l’AI per caso d’uso, non per prodotto. Il passo successivo è attribuire a ogni riga dell’inventario una logica economica. Senza questo collegamento, la governance sa dove si trova l’AI ma non aiuta a decidere dove aumentare autonomia, dove correggere e dove interrompere l’investimento.
L’OCSE rileva che l’incertezza sul ritorno dell’investimento è un ostacolo ricorrente all’adozione dell’AI nelle imprese; segnala anche la maturità dei dati e la difficoltà manageriale nel collegare l’AI a problemi reali di lavoro. È esattamente il punto in cui il Service Management può fare la differenza: possiede domanda, categorie, tempi, ricorrenze, journey, costi dei fornitori ed evidenze sugli esiti.
Un caso d’uso dovrebbe quindi avere almeno quattro viste collegate: risultato atteso, costo end-to-end, controlli necessari e danno potenziale. La governance diventa così una disciplina di allocazione: controlli più intensi dove l’impatto è alto, sperimentazione più rapida dove l’errore è reversibile, dismissione dove il beneficio non supera il costo complessivo.
Una formula utile, purché non diventi una scorciatoia
Propongo un modello manageriale semplice: Valore netto AI = beneficio operativo verificato meno costo tecnologico meno costo del controllo meno costo atteso dell’errore. Non è una formula prevista dall’AI Act, dal NIST o dal FinOps Framework; è una struttura originale per rendere esplicite voci che spesso finiscono in budget separati.
Il beneficio operativo verificato comprende ore realmente restituite alle persone, riduzione delle ricorrenze, maggiore disponibilità, migliore qualità e capacità aggiuntiva assorbita senza degradare il servizio. Il costo tecnologico include licenze, token, infrastruttura, integrazioni, dati e supporto. Il costo del controllo comprende test, osservabilità, revisione umana, formazione, audit e rollback. Il costo atteso dell’errore combina probabilità e impatto di incidenti, risposte errate, privilegi impropri, perdita di produttività o danni all’esperienza.
Il NIST Generative AI Profile è volontario e non fornisce un ROI standard, ma invita a integrare l’affidabilità nel design, nell’uso e nella valutazione lungo il ciclo di vita. La lezione economica è indiretta ma importante: il controllo non è un costo esterno da aggiungere dopo il go-live; è parte del prodotto operativo.
Sette metriche per evitare il ROI cosmetico
Le ore teoricamente risparmiate sono una misura fragile: presuppongono che ogni contatto evitato equivalga a tempo produttivo e che il problema non ritorni. Per una service review più credibile userei sette metriche collegate.
Primo: tasso di outcome verificato, cioè automazioni concluse con prova che il servizio è tornato disponibile. Secondo: ore nette restituite, al netto di escalation, controlli e rilavorazioni. Terzo: riduzione delle ricorrenze sullo stesso problema. Quarto: costo per remediation riuscita, non per semplice esecuzione. Quinto: tasso di rollback o intervento umano non pianificato. Sesto: costo del controllo per caso d’uso. Settimo: esperienza dopo l’automazione, misurata nel punto del journey interessato.
Queste misure impediscono due distorsioni. La prima è celebrare la deflection mentre il backlog si sposta sui gruppi di secondo livello. La seconda è premiare la velocità quando l’automazione produce più contatti ripetuti. Il ROI diventa allora un confronto tra baseline e risultato netto, segmentato per servizio, canale e livello di autonomia.
Quando un’automazione può diventare un prodotto replicabile
Il commento che ha ispirato questo approfondimento pone una domanda interessante: quando un servizio AI diventa davvero scalabile e vendibile? La mia interpretazione è che servano confini chiari, outcome ripetibili e unit economics osservabili. Una demo personalizzata non è ancora un prodotto; lo diventa quando configurazione, controlli, supporto e responsabilità possono essere replicati senza far crescere i costi più rapidamente del valore.
Nel supporto ciò richiede un catalogo di automazioni con prerequisiti, dati ammessi, limiti di autonomia, evidenze di successo, procedura di fallback e costo unitario. Richiede anche supplier governance: il margine apparente può scomparire se token, licenze, assistenza specialistica o verifiche aumentano con il volume.
Il FinOps Framework 2026 descrive gli scope come contesti decisionali collegati a prodotti, centri di costo o ambienti, non come semplici viste infrastrutturali. Applicato all’ITSM, significa leggere insieme consumo, rischio e outcome del singolo servizio. Solo allora si può confrontare «automatizzare di più» con alternative come migliorare knowledge, eliminare la causa radice o semplificare il processo.
Una service review che decide, non che racconta
Il passo pratico è aggiungere alla service review una pagina per ciascun caso d’uso AI: baseline, outcome verificati, costo totale, controllo richiesto, errori, andamento dell’esperienza e decisione successiva. Le decisioni possibili devono essere esplicite: scalare, mantenere, correggere, ridurre autonomia o dismettere.
La conformità resta necessaria. Dal 2 agosto 2026 l’AI Act è generalmente applicabile, con eccezioni e scadenze differenziate, e le autorità europee hanno avviato le attività di attuazione e supervisione. Ma trasformare la compliance in ROI non significa monetizzare il rispetto della legge: significa usare inventario, evidenze e responsabilità anche per allocare meglio capitale e capacità.
La conclusione manageriale è semplice: se un’automazione non è inventariata, non è governabile; se non è misurata sull’outcome, non è confrontabile; se beneficio, controllo e rischio non entrano nello stesso conto, il ROI rimane una promessa. Il Service Desk può diventare il luogo in cui quella promessa viene verificata.
Fonti e approfondimenti
- FinOps Foundation — State of FinOps 2026 Report — 2026 ↗
- Vasilio Markanastasakis, FinOps Foundation — FinOps Framework 2026: Executive Strategy, Technology Categories, and Converging Disciplines — 19 marzo 2026 — contenuto CC BY 4.0 ↗
- FinOps Foundation — FinOps for AI, Technology Category — consultato il 13 agosto 2026 — contenuto CC BY 4.0 ↗
- OECD — The Adoption of Artificial Intelligence in Firms — 2 maggio 2025 ↗
- NIST — Artificial Intelligence Risk Management Framework: Generative Artificial Intelligence Profile, NIST AI 600-1 — 26 luglio 2024 ↗
- Commissione europea — AI Act: regulatory framework e calendario — aggiornato 3 agosto 2026 ↗
Analisi e interpretazioni sono personali e non rappresentano le posizioni delle organizzazioni citate o del mio datore di lavoro.