Perché molti progetti pilota con l'AI non diventano processi operativi

Nella maggior parte dei casi, niente. Il pilota funziona nella demo, il team che lo ha costruito lo mostra con entusiasmo giustificato, e poi il progetto entra in una fase silenziosa in cui nessuno lo ferma ufficialmente ma nessuno lo porta avanti. Sei mesi dopo, chi ha finanziato il pilota fatica a dire con precisione cosa sia successo nel frattempo.

Non è un fallimento tecnico visibile. È più subdolo: il pilota non si rompe, semplicemente non viene mai integrato in un processo che qualcuno usa ogni giorno senza doverci pensare. Resta uno strumento che una persona sa usare bene, invece di diventare un pezzo del modo in cui l'azienda lavora.

Il report esplorativo MIT NANDA The GenAI Divide, ripreso da Fortune nel 2025, segnala un impatto economico limitato nel campione studiato. Il dato non rappresenta il tasso di fallimento di tutte le aziende e non misura ogni forma di beneficio operativo.

La domanda utile per il tuo progetto è più precisa: quale risultato cambia, rispetto a quale situazione iniziale e con quali costi? Un risparmio di tempo osservato non coincide automaticamente con un miglioramento del conto economico.

Gartner formulava nel 2024 una previsione: almeno il 30% dei progetti GenAI sarebbe stato abbandonato dopo il proof of concept entro fine 2025, per dati, rischi, costi o valore poco chiaro. È una previsione storica, non un secondo tasso osservato equivalente al report NANDA. Le due fonti invitano a valutare l'integrazione, senza escludere problemi tecnici o di qualità del modello.

Il report descrive la causa come un divario di apprendimento, non di tecnologia. Uno strumento generico, usato da una singola persona con un abbonamento personale, funziona bene proprio perché è flessibile: si adatta a chi lo usa. Lo stesso strumento, calato in un processo aziendale con più persone, dati specifici e vincoli operativi, smette di adattarsi perché non impara dal contesto specifico dell'organizzazione. Resta bravo in generale e inutile nello specifico.

Un modello più capace può migliorare l'output, ma non assegna responsabilità, non rende accessibili dati mancanti e non modifica da solo il processo. Verifica separatamente qualità tecnica e adozione: a volte il limite è il modello, altre volte è il modo in cui viene inserito nel lavoro.

La differenza non è la qualità del risultato che il pilota produce la prima volta. È cosa succede alla decima volta, alla centesima, quando la persona che lo ha costruito è in ferie o ha cambiato ruolo.

Quando manca una competenza specifica, il tempo per verificare le alternative o l'esperienza di portare un workflow in produzione. Il supporto esterno va scelto per colmare quel vuoto, non perché garantisca una probabilità di successo superiore.

Prima di scegliere, chiarisci chi progetta, chi realizza, chi verifica e chi mantiene. Una buona consegna rende il team meno dipendente dal consulente: decisioni documentate, file accessibili e criteri per intervenire quando qualcosa cambia.

Un output definito, un responsabile che possa cambiare il processo e risorse per integrazione, verifica e manutenzione. Sono condizioni operative da progettare insieme alla qualità tecnica, non una formula che assicura il successo.

È la ragione per cui un elenco di strumenti non è mai la parte difficile di un progetto AI. La parte difficile è decidere chi lo possiede, come si verifica che funzioni, e cosa succede il giorno dopo il lancio, quando l'entusiasmo iniziale è passato e resta solo il lavoro di farlo funzionare tutti i giorni.

Prima ancora del fallimento evidente, ci sono segnali riconoscibili con qualche settimana di anticipo.

Non ripartire da zero e non aggiungere subito uno strumento nuovo: nella maggior parte dei casi il pilota tecnicamente funziona già, e il problema non è lì. Il primo passo è nominare un responsabile con l'autorità di decidere, non solo di seguire il progetto, anche se questo significa toglierlo temporaneamente a chi lo ha costruito originariamente. Il secondo è scrivere ora, con ritardo ma prima di procedere oltre, la metrica che si sarebbe dovuta scrivere all'inizio: cosa cambia, di quanto, misurato come, entro quando.

Il terzo passo è il più spesso saltato: fissare una data, entro poche settimane, in cui qualcuno con potere decisionale guarda quella metrica e decide esplicitamente se il progetto scala, si ferma, o continua per un altro ciclo definito. Un pilota senza quella data non muore mai formalmente, e proprio per questo continua a occupare tempo e attenzione senza mai arrivare a un verdetto. Fermare un progetto in modo esplicito, con una decisione scritta, libera più risorse di quante ne liberi lasciarlo scivolare in silenzio.