Perché i Progetti Pilota di AI Non Arrivano in Produzione

Perché i Progetti Pilota di AI Non Arrivano in Produzione

I progetti pilota di intelligenza artificiale non arrivano in produzione perché sono costruiti per dimostrare che un modello sa svolgere un compito, non per far girare il processo reale che gli sta intorno. Automatizzano la versione scritta del lavoro, lasciano le eccezioni senza un responsabile, vanno live senza un modo per dimostrare che il mese dopo funzionano ancora, e stanno accanto al gestionale invece che sopra. Quasi mai è il modello a cedere: cedono le condizioni operative intorno.

La differenza conta, perché cambia cosa bisogna sistemare. Se il problema fosse il modello, basterebbe aspettare quello nuovo, e ne esce uno ogni trimestre. Il pilota si ferma nel momento in cui qualcuno deve prenderselo in carico: collegarlo a un sistema vero, rispondere del caso strano del martedì pomeriggio, dimostrare a chi ha firmato il budget che funziona ancora. Il pilota nasce per fare una dimostrazione. La produzione gli chiede di lavorare.

Il 95% dei Progetti AI Fallisce Davvero? Cosa Misura quel Numero

Il famoso "95%" viene dal report del MIT NANDA The GenAI Divide: State of AI in Business 2025, e di solito viene citato con meno precisione di quanta ne abbia il report. Il dato dice che, a fronte di 30–40 miliardi di dollari investiti dalle imprese nell'AI generativa, il 95% delle organizzazioni non ne ricava alcun ritorno. Il dato sul passaggio in produzione è più stretto: per gli strumenti di livello aziendale, su misura o venduti da fornitori, il 60% delle organizzazioni li ha valutati, il 20% è arrivato al pilota e solo il 5% alla produzione. Gli autori stessi precisano che i numeri sono indicativi, ricavati da interviste e non da dati ufficiali delle aziende.

La parte più utile è la diagnosi. Secondo il report, la maggior parte di questi strumenti fallisce per flussi di lavoro fragili, mancanza di apprendimento dal contesto e disallineamento con l'operatività quotidiana, e il divario non sembra dipendere dalla qualità dei modelli. Altre ricerche misurano in modo diverso e arrivano allo stesso punto. S&P Global Market Intelligence, su un campione di 1.006 professionisti IT e di business in Nord America ed Europa, ha rilevato che la quota di aziende che abbandonano la maggior parte delle iniziative AI prima della produzione è passata in un anno dal 17% al 42%. Gartner prevedeva a luglio 2024 che almeno il 30% dei progetti di AI generativa sarebbe stato abbandonato dopo la proof of concept entro la fine del 2025, per scarsa qualità dei dati, controlli dei rischi inadeguati, costi in crescita o valore di business poco chiaro.

Perché allora la maggior parte dei progetti AI si ferma? Quelle quattro cause vanno lette come sintomi. La scarsa qualità dei dati è ciò che il pilota incontra quando esce dal campione ripulito. I controlli inadeguati sono un percorso delle eccezioni che nessuno presidia. I costi in crescita sono un sistema che fa passare ogni passaggio da un modello. Il valore poco chiaro è un sistema che nessuno sa misurare. Nessuna riguarda quanto è intelligente il modello.

Per chi guida una PMI, nello stesso report c'è un dato incoraggiante: le aziende di medie dimensioni si sono mosse più in fretta. Le migliori hanno impiegato in media 90 giorni dal pilota all'implementazione completa, contro i nove mesi o più delle grandi imprese. Meno livelli di approvazione, e spesso chi decide conosce il processo di persona.

Dal Pilota alla Produzione: Cosa Cambia Davvero

Il salto è la distanza tra le condizioni in cui si prova un pilota e quelle che impone la produzione. Il pilota risponde a una sola domanda: un modello sa farlo? La produzione ne pone altre sei.

Ogni riga è una delle sei ragioni per cui i piloti non scalano, e ognuna si risolve in modo diverso.

Perché Automatizzare il Processo Documentato Non Regge in Produzione?

Perché il processo documentato non è quello che gira. Chiedi qual è il primo passaggio e ti rispondono "arriva una mail". Siediti accanto a chi apre quella casella e il primo passaggio diventa quaranta mittenti, nessuno con lo stesso formato, metà delle informazioni negli allegati PDF, e una regola per smistare i casi dubbi che esiste solo nella testa di una persona. Chi lo sa fare è l'unico che lo sa fare, e quando va in ferie il processo rallenta. Un pilota costruito sulla prima risposta funziona nella demo, perché la demo usa i casi puliti. Si rompe nella prima settimana di produzione, perché la produzione gli manda tutti gli altri.

La soluzione è mettere per iscritto il processo reale prima di costruire qualsiasi cosa: un registro delle eccezioni (Exception Ledger) che raccoglie ogni deviazione reale dal processo documentato, quanto spesso capita e chi la assorbe oggi. Non nasce da una riunione, perché in riunione il responsabile descrive la procedura, mentre chi fa il lavoro conosce le scorciatoie. Lo spieghiamo in il processo documentato non è il processo reale (in inglese).

Chi Si Occupa dei Casi che il Modello Non Sa Gestire?

Nella maggior parte dei piloti fermi, nessuno. Durante il pilota i casi strani venivano gestiti a mano, spesso da chi stava costruendo il sistema, ed è per questo che sembrava tutto pulito. Al go-live finiscono in una coda senza responsabile, l'arretrato cresce, e l'azienda conclude che il sistema "non funziona", quando il modello andava bene e il percorso delle eccezioni non era mai stato progettato.

In produzione ogni eccezione del registro deve avere uno di tre destini: gestita dal codice, passata a una persona precisa con tutto il contesto, oppure rifiutata. Un progetto di gestione ordini transfrontalieri che abbiamo realizzato mostra la terza strada: un reso dagli Stati Uniti non può essere promesso al cliente prima che il magazzino terzo l'abbia approvato, perché il flusso si rifiuta di produrre un'etichetta che non esiste. I due errori più costosi di quel processo, un Incoterm sbagliato che addebita i dazi al cliente e un modulo FDA mancante che blocca un pacco in dogana, li decide il codice e non la memoria di una persona. È un percorso delle eccezioni con un responsabile, scritto nel sistema invece che nella testa di qualcuno.

Come Sai che il Sistema Funziona Ancora Dopo il Lancio?

Senza una suite di valutazione non lo sai, e non lo sa nemmeno chi ha approvato il budget. È da qui che nasce il "valore poco chiaro". Cambiano i formati dei fornitori, cambiano i listini, il modello sottostante viene aggiornato, e un sistema corretto a marzo a settembre sbaglia senza che nessuno se ne accorga. Se l'unica prova di qualità è che nessuno si è lamentato, la prima lamentela chiude il progetto.

Una suite di valutazione è un insieme di casi reali della tua storia, ciascuno con l'esito che il tuo team ha prodotto e approvato, su cui il sistema in produzione viene misurato a intervalli regolari, con un report mensile di accuratezza. Trasforma "funziona?" da opinione a percentuale. In un motore di valutazione dei siti per data center che abbiamo costruito, otto siti di riferimento vengono valutati a ogni rilascio, così una modifica al prompt che peggiora la qualità dei report fa fallire la build invece di arrivare a chi deve decidere dove investire. L'argomento completo è in il tuo sistema AI è ancora corretto sei mesi dopo? (in inglese).

Perché un Pilota Costruito Accanto al Gestionale Si Blocca?

Perché un pilota accanto al gestionale è un secondo sistema. Il pilota tipico lavora su un export: qualcuno scarica un CSV, il modello lo elabora, una persona ricopia il risultato. Va bene per una demo ed è fatale per la scala, perché ricopiare è proprio il lavoro che il pilota doveva eliminare. La soluzione che il fornitore propone a quel punto è peggiore: sostituire il gestionale per dare al nuovo strumento una piattaforma pulita. Un processo da sei settimane diventa una migrazione di anni, e il responsabile IT dice di no, con ragione.

La strada è costruire sopra ciò che già funziona, tramite API, lettura del database o export pianificato, senza migrare nulla e senza dismettere nulla. Noi lo mettiamo per iscritto: è l'impegno ERP-additivo. È anche la risposta onesta alla "scarsa qualità dei dati" di Gartner: spesso il problema non è che il gestionale sia inadeguato, ma che il pilota non lo abbia mai letto. Il livello dati lo trattiamo nel dettaglio in perché l'AI si blocca sui gestionali legacy.

Perché un Pilota Affidato alla Strategia Si Ferma?

Perché la strategia finisce con il pilota e la produzione comincia dopo. L'indagine BCG di luglio 2026 su 152 CEO di aziende con almeno 500 milioni di dollari di fatturato ha rilevato che quasi due terzi dichiarano che la propria azienda porta avanti piloti AI, ma solo il 26% ha inserito l'AI in una trasformazione più ampia del business. Buona parte di quella distanza è una questione di persone. Il consulente ha finito quando il report è accettato, il fornitore quando lo strumento è installato, e l'IT interno non è mai stato dimensionato per un sistema in più. Il lavoro in mezzo, collegare il pilota ai dati veri, alle approvazioni vere e alle persone vere, non è di nessuno.

I piloti che scalano sono affidati a operatori: persone che lavorano accanto a chi gestisce il processo, costruiscono il sistema e restano finché quel team non lo gestisce da solo. È il criterio con cui definiamo un embedded operator.

Perché Mettere l'AI Ovunque Rende il Pilota Più Difficile da Scalare?

Perché ogni passaggio affidato a un modello lo paghi e lo aspetti a ogni esecuzione, e non puoi testarlo del tutto in anticipo. I piloti tendono a essere tutto AI perché un modello è il modo più veloce di prototipare qualsiasi cosa. Con i volumi della produzione quella scelta si traduce nei "costi in crescita" di Gartner, in tempi di risposta che si sommano lungo una catena di chiamate, e in decisioni che nessuno sa spiegare al revisore o al collegio sindacale.

La maggior parte dei passaggi di un processo aziendale sono regole: ricerche, controlli, smistamenti, calcoli. Le regole vanno nel codice normale, che costa poco, è veloce e domani dà la stessa risposta di oggi. Pochi passaggi richiedono un vero giudizio, ed è lì che un modello si guadagna il suo costo. Alcuni devono restare in mano a una persona. La mappa dei confini dell'AI (AI Boundary Map) classifica ogni passaggio in uno di questi tre modi, e il rapporto di determinismo è ciò che di solito ne emerge. Nella gestione ordini di un produttore europeo mappata da SUPALABS, tre passaggi su undici avevano davvero bisogno di un modello; gli altri otto erano lettura dei documenti, ricerche, controlli e smistamento (dati di progetto SUPALABS, 2024–2026). Da dove cominciare, e cosa non automatizzare affatto, lo spieghiamo in AI automation per un COO: cosa automatizzare per primo.

Come Portare un Pilota AI in Produzione

Rovescia le sei cause e ottieni la sequenza. L'ordine conta, perché ogni passo dipende da quello prima.

1. Scegli un solo processo che fa male in modo evidente, con un dirigente che ne risponde. Fatture passive ribattute a mano da tre persone, un ciclo dall'offerta all'incasso con cinque passaggi di mano. Se nessuno in alto risponde del risultato, il lavoro si ferma alla prima approvazione, chiunque lo costruisca.
2. Mappa il processo reale prima di quotare lo sviluppo. Lo Sprint di Mappatura Operativa sono cinque giorni accanto a chi fa il lavoro. Produce il registro delle eccezioni e la mappa dei confini dell'AI, e lo sviluppo viene quotato su ciò che hanno trovato, non su una stima a occhio.
3. Impegnati a costruire sui sistemi esistenti. Scrivi "nessuna migrazione" nel perimetro del progetto prima di scrivere una riga di codice.
4. Dai un destino a ogni eccezione. Codice, una persona con nome e cognome, oppure un rifiuto. Nessuna eccezione va in produzione senza.
5. Costruisci la suite di valutazione prima del go-live, non dopo. Fai girare il sistema in shadow mode sui casi reali, accanto alle persone che fanno il lavoro, finché la percentuale di casi superati non giustifica il passaggio all'azione.
6. Misura il passaggio di consegne, non il lancio. Il lavoro è finito quando il tuo team gestisce il sistema da solo, e un report mensile di accuratezza dice se è ancora corretto.

Impostato così, il primo processo entra tipicamente in produzione in circa sei settimane dopo lo sprint. Come funziona lo sprint, cosa consegna e cosa succede dopo è spiegato nella pagina dello Sprint di Mappatura Operativa.

Cinque Domande per Capire Perché il Tuo Pilota È Fermo

Se in azienda c'è un pilota "quasi pronto" da più di un trimestre, queste cinque domande di solito trovano il problema in una riunione:

• Sappiamo elencare le eccezioni che questo processo incontra, e quanto spesso capita ciascuna?
• Chi riceve il messaggio quando il sistema incontra un caso che non sa gestire, e lo sa?
• Qual era la percentuale di casi reali superati il mese scorso?
• Scrive direttamente nel gestionale, o qualcuno ricopia il risultato?
• Quanti passaggi chiamano un modello, e ognuno ne ha davvero bisogno?

Un "non lo so" su una qualsiasi di queste è il motivo per cui il pilota non è andato avanti, ed è una scoperta che costa meno di un altro trimestre di attesa.

Quando il Problema È un Altro

Non tutti i piloti fermi rientrano in questo schema. Se il compito è aritmetica e non giudizio, un motore di regole o un foglio di calcolo ben fatto batte qualsiasi modello, e la mossa giusta è togliere l'AI. Se hai già un team interno di sviluppo con tempo a disposizione, assumi per coprire la lacuna invece di chiamare un partner. E se nessun dirigente risponde del risultato, sistema prima quello, perché senza non sopravvive nessun progetto.

Fonti e riferimenti