Perché il 95% dei progetti di AI fallisce (e come essere nel 5% che funziona)

In breve. Il MIT NANDA ha misurato che il 95% dei progetti di AI generativa in azienda non genera alcun impatto misurabile sul conto economico. Non è un problema di modelli: è un problema di integrazione nei processi, di monitoraggio quotidiano e di chi ne risponde. Chi costruisce con un partner specializzato riesce circa il 67% delle volte, contro un terzo per gli sviluppi puramente interni. Il 5% che funziona parte da un perimetro delimitato, un problema misurato in euro, e una persona che lo segue ogni giorno.

Un pilot che funzionava benissimo, finché non ha risposto a un cliente vero

Un istituto finanziario con qualche migliaio di dipendenti aveva appena finito di distribuire agenti AI su tutta l'organizzazione. Il progetto era stato calato dall'alto, sponsorizzato in comitato di direzione, e la demo era stata impeccabile: risposte rapide, tono corretto, casi d'uso coperti uno dopo l'altro. Nessuno in sala aveva niente da obiettare.

Poi qualcuno ha notato una risposta che non tornava. Non un errore clamoroso, il tipo di imprecisione che passa inosservata finché non tocca il cliente sbagliato al momento sbagliato. È lì che è emersa la domanda che nessuno si era fatto prima del lancio: chi controlla, ogni giorno, cosa rispondono davvero questi agenti? La risposta era nessuno. Il pilot tecnicamente funzionava. Il processo che doveva contenerlo, monitorarlo e correggerlo non esisteva.

Il pattern ha un nome, e il MIT lo ha misurato su scala

Quello che abbiamo visto in quel caso non è un incidente isolato. È esattamente il pattern che The GenAI Divide: State of AI in Business, la ricerca 2025 dell'iniziativa NANDA del MIT, ha misurato su 300 deployment pubblici, 150 interviste a manager e un sondaggio su 350 dipendenti: solo il 5% dei progetti di AI generativa in azienda porta a un'accelerazione reale di ricavi o margine. Il restante 95% resta senza impatto misurabile sul conto economico.

Il dato ha fatto rumore perché suona come un giudizio sulla tecnologia. Letto da dentro un progetto reale, dice qualcos'altro: il fallimento non è un evento raro e imprevedibile, è quasi sempre la stessa cosa che si ripete. Il MIT lo chiama learning gap, la distanza tra un modello che sa rispondere bene in laboratorio e un'organizzazione che sa cosa farne ogni giorno.

Perché non è colpa dei modelli

Il riflesso comune, davanti a un progetto AI che non porta risultati, è incolpare il modello: non capisce abbastanza, sbaglia troppo, non è ancora maturo. La ricerca smentisce questa lettura. I modelli generalisti oggi funzionano, e in laboratorio si comportano bene quasi sempre. Quello che manca non è nel modello. È tra il modello e il lavoro vero.

"Il pilot tecnicamente funzionava. Il processo che doveva contenerlo, monitorarlo e correggerlo non esisteva."

Il caso della banca lo mostra bene: la tecnologia non aveva bisogno di essere migliore. Aveva bisogno di un perimetro definito (quali domande può gestire da solo, quali no), di qualcuno che leggesse un campione di conversazioni ogni settimana, e di un criterio chiaro per capire quando intervenire. Senza questi tre elementi, anche il modello più bravo del mondo produce lo stesso risultato: funziona in demo, si rompe nel primo caso anomalo, e nessuno se ne accorge finché non è già un problema.

La differenza si vede nel perimetro, non nella dimensione

L'anno scorso abbiamo seguito un general contractor edile di circa 50 persone che voleva automatizzare un solo processo: l'invio e il tracciamento dei preventivi ai clienti. Nessun agente onnicomprensivo, nessuna ambizione di coprire ogni reparto. Un processo, criteri di accettazione definiti prima di iniziare, e una persona interna che ogni settimana verificava che il sistema facesse esattamente quello che doveva fare. Oggi quel processo gira, misura il tempo risparmiato, e nessuno in azienda si chiede se "funziona": lo vedono nei numeri.

La differenza tra questo caso e quello della banca non è la dimensione dell'azienda, né il budget, né la sofisticazione del modello usato. È che nel secondo caso il perimetro era chiaro fin dal primo giorno, e qualcuno ne rispondeva. È esattamente il confine tra il 5% e il 95% descritto dal MIT, visto da vicino: non vince chi ha l'AI più avanzata, vince chi ha impostato meglio cosa deve fare, chi la controlla, e come si misura il risultato.

Come impostare un progetto perché stia nel 5%

Il modo in cui lavoriamo in Morfeus nasce proprio per evitare l'errore che abbiamo visto ripetersi: partire dal tool invece che dal problema, restare in demo, lasciare che il sistema viva senza nessuno che ne risponda.

• Diagnosi. Prima di parlare di tecnologia, misuriamo dove l'azienda sta perdendo valore ogni giorno. Con il ROIometro quella sensazione diventa un numero, e i punti di perdita diventano Value Leak quantificati in euro.
• Sistema. Costruiamo su un perimetro delimitato, in produzione fin dal primo giorno, non in una demo isolata. Il sistema si appoggia su MARF, l'infrastruttura che resta in azienda e si estende nel tempo invece di ripartire da zero a ogni progetto.
• Valore. Ogni mese un Value Report mostra cosa il sistema ha effettivamente prodotto, in euro, non in slide.
• Autonomia. Formiamo un AI Champion per reparto: la persona che ogni giorno controlla, corregge e fa evolvere il sistema, così la capacità resta dentro l'azienda anche il giorno dopo che noi ce ne siamo andati.

Il filo che lega questi quattro passaggi è lo stesso che abbiamo visto mancare nel caso della banca e presente in quello del general contractor: un perimetro chiaro, e qualcuno che se ne prende cura ogni giorno.

In sintesi

Il 95% misurato dal MIT non è una condanna della tecnologia, è una diagnosi sul metodo. Un pilot può essere tecnicamente impeccabile e fallire comunque, se nessuno lo integra nei processi e nessuno ne risponde ogni giorno. La domanda da cui partire non è quale AI comprare, ma dove stai perdendo valore oggi, e chi la controllerà domani.