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.

Pochi, ed è documentato. The GenAI Divide: State of AI in Business 2025, un report del MIT NANDA basato su interviste a decine di aziende, un sondaggio su centinaia di responsabili e l'analisi di oltre trecento iniziative AI pubblicamente note, trova che circa il 95% delle iniziative di AI generativa in azienda non produce un impatto misurabile su conto economico. Solo una minoranza, circa il 5%, converte il pilota in un guadagno operativo o finanziario verificabile.

Il numero da solo dice poco. La parte utile del report è cosa distingue quel 5%, perché non è la tecnologia che usano: usano gli stessi modelli disponibili a tutti.

Una seconda fonte indipendente converge sullo stesso punto con una metodologia diversa. Gartner prevedeva che almeno il 30% dei progetti di AI generativa sarebbe stato abbandonato dopo la fase di proof of concept entro la fine del 2025, indicando come cause la scarsa qualità dei dati, controlli di rischio inadeguati, costi crescenti o un valore di business poco chiaro. Nessuna delle quattro cause è la capacità del modello, e la sovrapposizione con il report MIT rende difficile liquidare il fenomeno come un artefatto di un singolo studio.

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.

Questo spiega perché aumentare la potenza del modello non risolve il problema che la maggior parte delle aziende sta effettivamente vivendo. Il problema non è "il modello sbaglia troppo", è "nessuno ha costruito il ponte tra quello che il modello sa fare e il modo specifico in cui questa azienda lavora".

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.

Lo stesso report trova che i progetti realizzati con un partner esterno specializzato raggiungono un impatto misurabile a un tasso significativamente più alto, all'incirca il doppio, rispetto ai progetti costruiti internamente senza supporto esterno. Non perché il partner esterno abbia un modello migliore: nessuno ha un modello migliore, i modelli sono gli stessi per tutti.

Il vantaggio sta in tre cose che un team interno alla prima esperienza non ha ancora: conoscenza accumulata su cosa funziona e cosa no in contesti simili, capacità di integrare la soluzione nei processi specifici invece di consegnare uno strumento generico, e un sistema che continua a imparare dall'uso invece di restare fermo alla versione del giorno del lancio.

Questo non significa che costruire internamente sia sempre sbagliato. Significa che farlo per la prima volta, sul primo caso, senza aver mai visto dove si nasconde l'attrito, costa quasi sempre un giro di apprendimento che un partner con più iterazioni alle spalle ha già superato.

Tre cose, sempre le stesse tre: un output definito prima di iniziare a costruire, un responsabile con l'autorità di imporre il cambiamento nel processo, e un budget allocato non solo per costruire lo strumento ma per integrarlo, correggerlo e mantenerlo dopo il lancio. Nessuna delle tre riguarda il modello. Tutte e tre riguardano la struttura organizzativa attorno al modello.

È 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.