Una ricerca del MIT del 2026 ha rilevato che circa il 95 per cento dei progetti pilota GenAI in azienda non produce alcun ritorno misurabile nel conto economico, e che circa l’88 per cento non arriva mai in produzione. La causa non è quasi mai la qualità del modello. Circa l’80 per cento del lavoro tra un pilota riuscito e un sistema funzionante è ingegneria dei dati, governance, integrazione nei processi e misurazione — esattamente le parti che un pilota tipico salta. Le organizzazioni che ce la fanno riportano circa 3,70 dollari per ogni dollaro speso, partendo da circa il 41 per cento il primo anno e arrivando a circa il 124 per cento al terzo.
Perché quasi nessun pilota arriva al conto economico
Il dato del 95 per cento è fuorviante se lo si legge come «i modelli non hanno funzionato». Nella maggior parte dei casi il modello funzionava benissimo. Ciò che è fallito è che il pilota ha dimostrato una cosa mentre l’organizzazione doveva deciderne un’altra.
Un pilota tipico verifica se il modello sa eseguire un compito. La decisione che sta dietro riguarda invece se il processo aziendale cambierà, chi smetterà di fare cosa, come lo si misura ogni mese e chi risponde quando il sistema sbaglia. Sono due domande completamente diverse, e la seconda è quella che finisce nei conti.
Da qui nasce anche la nota divisione 80/20. La parte che assomiglia al progetto — scegliere un modello, scrivere i prompt, fare una demo — è circa un quinto del lavoro. I restanti quattro quinti sono pulire ed esporre i dati, permessi e classificazione delle informazioni, collegarsi agli strumenti in cui il team già lavora, e costruire la misurazione. Un pilota che non ha toccato nessuno di questi quattro punti non ha ridotto il rischio. Lo ha solo rimandato.
Un test da fare prima di iniziare. Scrivete in una frase la decisione che verrà presa alla fine del pilota, e il numero che la deciderà. Se non riuscite a scrivere quella frase, quello che state preparando è una dimostrazione, non un pilota. Le dimostrazioni sono legittime — semplicemente, non mettetele a budget come piloti e non aspettatevene un ritorno.
Cosa misurano i piloti e cosa dovrebbero misurare
Questo scarto si ripete in quasi tutte le organizzazioni, ed è di solito il motivo per cui il pilota è riuscito e il progetto è morto.
| Cosa viene realmente misurato | Perché non basta | Cosa misurare invece |
|---|---|---|
| Accuratezza del modello su un set di test | Il set di test è stato costruito sui casi a cui avete pensato, non sul traffico reale | Tasso di successo su un campione casuale dell’ultimo mese di traffico reale, casi strani inclusi |
| Tempo risparmiato, come lo stimano gli utenti | Le stime dichiarate sono sistematicamente gonfiate e non compaiono in nessuna voce di bilancio | Tempo di ciclo end-to-end misurato, prima e dopo, sulla stessa classe di attività |
| Soddisfazione in un sondaggio | Misura l’entusiasmo per la novità, che si esaurisce dopo circa sei settimane | Tasso di ritorno alla sesta settimana tra gli utenti attivi nella prima |
| Costo dei token durante il pilota | Riflette volumi bassi e casi comodi | Costo per unità di lavoro a pieno volume, inclusi ritentativi, recupero ed escalation umana |
| «Al team piace tantissimo» | Non distingue una comodità da uno strumento di cui non si può più fare a meno | Cosa succede se lo spegnete per una settimana. È l’unico test che non si può falsare |
L’ultima riga sembra una battuta ma è la più solida dell’elenco. Uno strumento che potete spegnere per una settimana senza una sola lamentela non sopravviverà al budget annuale, e non ha senso investirci un altro trimestre.
Quattro livelli di ROI, e uno solo conta
Quando un amministratore delegato chiede qual è il ritorno, ci sono quattro risposte possibili e non sono equivalenti. Saperle distinguere è ciò che separa un pilota rifinanziato da uno che viene chiuso.
| Livello | Esempio | Compare nei conti | Quando è legittimo |
|---|---|---|---|
| Ore risparmiate | Ogni operatore risparmia 40 minuti al giorno | No. Le ore non sono sparite, si sono spostate su un altro compito | Solo se potete mostrare dove sono andate quelle ore e cosa ne è uscito |
| Capacità liberata | Lo stesso team gestisce il 30 per cento di volume in più | Indirettamente, come crescita che non ha richiesto assunzioni | Quando esiste una domanda reale per quella capacità |
| Costo diretto eliminato | Meno ore di fornitori, uno strumento esterno in meno, meno straordinari | Sì, immediatamente | Sempre. È il livello più facile da difendere |
| Ricavo aggiunto | Più lead qualificati, ciclo di vendita più breve, meno abbandono | Sì, con uno scarto di uno o due trimestri | Quando c’è un gruppo di controllo, o almeno una base storica pulita |
La maggior parte dei piloti riporta il primo livello sperando che venga letto come il terzo. Fate il contrario: costruite il pilota attorno al terzo o al quarto livello, anche se il perimetro è molto più piccolo. Un risparmio annuo dimostrato di 40.000 dollari vale più di un milione teorico.
Un pilota di sei settimane su cui si può davvero decidere
La struttura che funziona è più corta di quella che la maggior parte delle organizzazioni pianifica e richiede più lavoro a monte.
Settimana 1 — definire la decisione e la linea di base. La frase di decisione, il numero che la risolve, e una misurazione dello stato attuale esattamente su quella metrica. Senza una linea di base misurata non c’è nulla con cui confrontare alla fine, e questo è, sorprendentemente, il passo più spesso saltato.
Settimane 2 e 3 — la versione più economica che risponde alla domanda. Comprare prima di costruire. I dati di mercato mostrano che iniziare la fase di prova con un componente pronto produce un ROI 3,2 volte superiore, e che costruire prima di validare fa perdere in media circa 14 mesi. Ne abbiamo parlato in costruire o comprare capacità IA.
Settimane 4 e 5 — traffico reale, utenti reali. Non un laboratorio. Un gruppo definito che lavora con lo strumento nel proprio quotidiano, casi brutti inclusi ed escalation incluse.
Settimana 6 — decidere. Estendere, restringere o chiudere. Tutti e tre gli esiti devono essere ugualmente legittimi dal primo giorno, altrimenti il risultato è noto in anticipo.
Il budget di misurazione non è opzionale. Destinate almeno il 15 per cento del budget del pilota alla misurazione stessa: raccolta della linea di base, campionamento manuale settimanale della qualità e monitoraggio del costo per unità di lavoro. Un pilota senza budget di misurazione finisce in una discussione su impressioni, e una discussione su impressioni si risolve sempre a favore dello status quo.
Quando chiudere un pilota, e perché fa risparmiare
Chiudere presto non è un fallimento, è un meccanismo di rendimento a sé stante. Quattro segnali giustificano lo stop prima della sesta settimana.
- Il tasso di successo sul traffico reale è sensibilmente inferiore a quello del set di test interno, e lo scarto non si chiude dopo due giri di correzioni. È quasi sempre il segno che i dati non sono in uno stato che sostiene il compito.
- Il costo per unità di lavoro a pieno volume supera l’alternativa umana. Prezzo, cache e routing possono cambiarlo, ma se lo scarto è un multiplo anziché qualche decina di punti percentuali, il problema è l’architettura, non il prezzo.
- Gli utenti tornano da soli al vecchio processo, senza che glielo si chieda. È il segnale più precoce e più onesto a disposizione.
- Nessuno si prenderà la responsabilità del processo dopo il pilota. Senza un proprietario nulla arriva in produzione, per quanto buoni siano i numeri.
Un’organizzazione che chiude due piloti a trimestre dopo sei settimane invece di trascinarli per un anno libera budget per il terzo tentativo — ed è esattamente il meccanismo che separa le organizzazioni che dichiarano 3,70 dollari per dollaro da tutte le altre.
Da dove viene lo scarto tra il 41 e il 124 per cento
Questi due numeri descrivono le stesse organizzazioni in momenti diversi, e la differenza tra loro non è un modello migliore. Sono tre cose noiose.
La prima è il costo. La stessa identica capacità diventa sensibilmente più economica con cache, batching e routing tra modelli — impilare tutti e tre taglia una bolletta di inferenza del 60-80 per cento senza cambiare nulla dell’esperienza utente. Il primo anno pagate prezzo pieno perché state misurando invece di ottimizzare.
La seconda è il perimetro. Il primo caso d’uso risolve un problema. Al terzo anno la stessa infrastruttura, la stessa governance e la stessa classificazione delle informazioni servono cinque casi d’uso, e il costo fisso si divide. Ecco perché l’investimento nello strato dati sembra decisamente troppo caro il primo anno e sembra ovvio al terzo.
La terza è il processo stesso. Il primo anno lo strumento viene aggiunto a un processo esistente, quindi aggiunge costo prima di toglierne. Solo quando il processo viene riscritto attorno ad esso — passaggi che spariscono, approvazioni che si fondono, ruoli che cambiano — compare il ritorno grande. Le organizzazioni che non arrivano mai a quello stadio restano vicino al 41 per cento e concludono che l’IA non ha ripagato.
Tutte e tre poggiano sulla stessa base: un modello di costo completo della funzionalità, che abbiamo esposto in quanto costa davvero una funzionalità IA, e un prezzo collegato a quella struttura di costo, di cui abbiamo parlato in prezzare un prodotto basato su un modello. Se state definendo un pilota adesso, fissate i criteri di accettazione nella stessa riunione in cui definite la decisione.
Costruire l’impianto di misurazione e di decisione attorno a un pilota fa parte del lavoro di pianificazione finanziaria e di crescita che facciamo con i clienti.
Domande frequenti
Perché il 95 per cento dei piloti IA fallisce?
Una ricerca del MIT del 2026 ha rilevato che circa il 95 per cento dei piloti GenAI in azienda non produce alcun ritorno misurabile nel conto economico e che circa l’88 per cento non arriva mai in produzione. La causa principale non è la qualità del modello ma il fatto che il pilota ha testato una capacità tecnica invece di testare un cambiamento del processo aziendale. Circa l’80 per cento del lavoro tra pilota e produzione è ingegneria dei dati, governance, integrazione negli strumenti esistenti e misurazione — le parti che la maggior parte dei piloti salta del tutto.
Quanto dovrebbe durare un pilota IA?
Sei settimane bastano per decidere e di solito sono meglio di sei mesi. Una settimana per definire la decisione e misurare la linea di base, due settimane per la versione più economica che risponde alla domanda, due settimane su traffico reale con utenti reali, e una settimana per decidere. Un pilota più lungo non produce più certezza. Rende solo la chiusura più costosa e politicamente più difficile.
Come si misura il ROI di un progetto IA?
Separate quattro livelli: ore risparmiate, capacità liberata, costo diretto eliminato e ricavo aggiunto. Solo gli ultimi due compaiono nel conto economico. Misurate lo stato attuale esattamente sulla stessa metrica prima di iniziare, confrontate il costo per unità di lavoro a pieno volume inclusi ritentativi ed escalation umana, e destinate almeno il 15 per cento del budget del pilota alla misurazione stessa.
Quando conviene chiudere un pilota in anticipo?
Quando compare uno dei quattro segnali: il tasso di successo sul traffico reale è sensibilmente inferiore al set di test interno e non si chiude dopo due giri di correzioni, il costo per unità di lavoro è un multiplo dell’alternativa umana, gli utenti tornano da soli al vecchio processo, oppure nessuno si prenderà la responsabilità del processo dopo il pilota. Chiudere in fretta libera budget per il tentativo successivo, che è il vero meccanismo di rendimento.
Perché il ritorno sale dal 41 per cento del primo anno al 124 per cento del terzo?
Tre ragioni, nessuna delle quali riguarda il modello. Il costo di inferenza scende del 60-80 per cento una volta impilati cache, batching e routing tra modelli. Il costo fisso di infrastruttura si divide su più casi d’uso che girano sulla stessa governance e sugli stessi dati. E soprattutto, il processo aziendale viene riscritto attorno allo strumento invece che lo strumento innestato su un processo esistente — finché questo non accade, lo strumento aggiunge costo prima di toglierne.
Da leggere dopo
Ridurre il costo di inferenza del 60-80 per cento — è la leva che porta il rendimento dal 41 al 124 per cento: cache, batching e routing tra modelli.
