Il progetto pilota AI funziona sempre, la produzione fallisce: il problema non è il modello
Perché i progetti pilota AI nelle PMI funzionano in demo e falliscono in produzione, e la checklist da usare prima di approvare il prossimo pilota.
Se il progetto pilota AI funziona in demo, non festeggiare troppo presto. Nelle PMI, la sequenza “pilota riuscito, produzione fallita” è il percorso più comune dell’adozione dell’AI. E il motivo di solito non è il modello.
Per come la vedo io, la maggior parte dei fallimenti in produzione nasce dallo stesso problema: durante il pilota, consapevolmente o no, si crea un ambiente da serra. I dati sono selezionati, le integrazioni sono una sola, e qualcuno rimedia agli errori. Quando si passa in produzione, queste tre condizioni spariscono insieme. Il sistema si rompe nell’ambiente reale e chi decide guarda indietro e conclude, per errore, che “il modello non è abbastanza buono”.
Non è un caso isolato. In una ricerca del MIT del 2025, il 95% dei progetti pilota di AI generativa non ha portato i ritorni attesi. Gartner rileva che almeno il 50% dei progetti GenAI viene abbandonato dopo la prova di concetto, per qualità dei dati insufficiente, controllo del rischio inadeguato, costi in aumento e valore di business poco chiaro. I dati IDC sono ancora più specifici: l’88% dei progetti pilota di agenti AI non arriva mai in produzione; ogni 33 progetti pilota, solo 4 sopravvivono.
I tre numeri usano campioni e definizioni diverse, ma indicano la stessa cosa: tra pilota e produzione c’è un fossato largo, e la maggior parte delle aziende non lo affronta in fase di progettazione.
Il pilota funziona perché tre condizioni vengono “esternalizzate”
Il successo del pilota si regge di solito su tre condizioni non replicabili. Se le separiamo, chi guida l’azienda capisce perché la demo e l’uso reale sono due cose diverse.
Prima condizione: dati puliti.
Nel pilota i dati sono quasi sempre selezionati. Si prende un dataset piccolo, si sistemano i formati, si riempiono i campi mancanti e si dà tutto in pasto all’AI. In demo funziona. Ma i dati di produzione sono diversi: formati incoerenti, record duplicati, informazioni datate, campi mancanti e versioni Excel contraddittorie tra un reparto e l’altro. AnAr Solutions descrive così il problema nei progetti con agenti: il pilota gira su “dati puliti e ordinati”, mentre la produzione significa “dati disordinati, utenti concorrenti, casi limite che il team non aveva mai immaginato”. I dati non si puliscono da soli: qualcuno deve occuparsene. E il costo di quel qualcuno, nella fase pilota, spesso non viene contato.
Seconda condizione: supervisione umana.
Nel pilota c’è sempre qualcuno che controlla. L’output dell’AI viene letto, gli errori corretti, i risultati fuori target filtrati. Questo crea l’illusione che “l’AI funzioni bene”, quando in realtà l’effetto è “AI + revisione umana”. Dopo la messa in produzione, quella rete di sicurezza di solito scompare. I dipendenti ricevono l’output direttamente e nessuno ha il tempo di verificarlo voce per voce. Il MIT usa il concetto di “tassa di verifica” (verification tax): quando il sistema AI dà risposte sicure ma sbagliate, il tempo che i dipendenti passano a ricontrollare supera il tempo risparmiato dall’AI. Durante il pilota, la persona che fa da filtro paga questa tassa al posto del sistema. Dopo la messa in produzione, chi la paga? Se non si risponde, il progetto fallisce.
Terza condizione: una sola integrazione.
Nel pilota l’AI dialoga di solito con un solo sistema, a volte con API simulate o snapshot di dati. In demo i dati sembrano aggiornarsi in tempo reale e tutto appare fluido. In produzione bisogna collegarsi a CRM, ERP, database e API di terze parti. Ogni sistema ha autenticazione, limiti di richieste e modi di guasto diversi. La stessa analisi sui progetti con agenti AI nota che l’orchestrazione del modello è spesso la parte più facile; la parte difficile è collegare l’agente ai sistemi reali, gestendo identità, rate limit e guasti parziali. Un sistema verificato su un solo “tubo”, portato su tutta l’azienda o su tutta la fabbrica, equivale ad aprire una strada senza mappa.
95%, 88%, 50%: tre numeri, una stessa storia
Messi insieme, i tre numeri raccontano una storia chiara.
Il 95% del MIT misura il fallimento sul ritorno: il pilota è stato fatto, ma non ha prodotto un ritorno finanziario misurabile. È il criterio più severo: non chiede solo “il sistema è andato online?”, ma “online serve a qualcosa?”.
L’88% di IDC misura il fallimento produttivo: il sistema gira benissimo in pilota, ma non arriva mai in produzione. Misura il salto dalla demo all’operatività quotidiana.
Il 50% di Gartner misura l’abbandono: finita la prova di concetto, il progetto viene tagliato. Non perché la tecnologia non fosse all’altezza, ma perché i dati non erano pronti, il controllo del rischio era insufficiente, i costi sono sfuggiti e il valore di business non era chiaro.
Tre angolazioni diverse sullo stesso fossato: più le condizioni del pilota sono “perfette”, più sono lontane dalla produzione, e più il salto diventa difficile. Un sistema cresciuto in serra, spostato all’aperto, non ha grandi probabilità di sopravvivere.
Cosa fare: progettare le condizioni di scala prima di partire
La maggior parte delle aziende tratta il pilota come “proviamo un po’”. È la mentalità più pericolosa. Lo scopo del pilota non è dimostrare che l’AI sa fare qualcosa: la demo lo dimostra già. Il vero scopo è scoprire quali condizioni si romperanno in produzione e progettare in anticipo la soluzione.
Se invertiamo questa logica, otteniamo una checklist operativa. Prima di approvare qualsiasi pilota AI, bisogna rispondere a cinque domande.
1. Che dati usa il pilota e quanto sono diversi da quelli di produzione?
Se il pilota usa dati già ripuliti, chi renderà utilizzabili i dati di produzione? Costo e tempi di questo lavoro sono inclusi nel budget? La pulizia dei dati spesso costa più del modello stesso, ma nel budget del pilota questa voce tende a sparire.
2. Dopo la messa in produzione, chi risponde dell’output dell’AI? Chi lo verifica?
Senza un responsabile chiaro, i dipendenti si arrangiano: si fidano ciecamente dell’output, oppure perdono ore a verificarlo, oppure smettono di usarlo. Tutte e tre le strade portano al fallimento. Già in fase pilota va indicato un ruolo che definisca “quale output è accettabile” e “chi interviene se è sbagliato”.
3. Se l’AI sbaglia, quanto è ampio il danno?
Nel pilota l’errore colpisce una persona. In produzione colpisce una linea produttiva, un team di assistenza clienti, una serie di preventivi inviati ai clienti. Il sistema è progettato per dire “non so” quando non è sicuro, invece di dare una risposta sbagliata ma convincente? Il rapporto del MIT segnala che i casi di successo hanno una caratteristica comune: di fronte all’incertezza il sistema rinuncia a rispondere e segnala il contesto mancante, invece di dare una risposta sbagliata con alta sicurezza. Questo comportamento va verificato in pilota, non aggiunto dopo.
4. Qual è il costo reale dopo la messa in produzione?
Nel pilota di solito non si contano supervisione umana, pulizia dati e tempo di verifica degli output. Dopo il deployment tutti questi costi emergono. Un imprenditore o un responsabile IT deve guardare il conto completo: quanto tempo ogni persona passa sull’AI, quanto ne risparmia e quanto tempo di verifica si aggiunge ogni giorno. Non basta il costo delle API del modello.
5. Come definiamo “successo” del pilota?
La demo è andata bene? Oppure qualcuno usa il sistema tutti i giorni per lavoro, per scelta? Sono due standard completamente diversi. Molti pilota “riusciti” significano solo che il giorno della demo non ci sono stati errori. Il successo vero deve essere misurabile: per una data mansione, quanto scende il tempo necessario per lo stesso carico di lavoro, o quanto scende il tasso di errore, senza interventi umani aggiuntivi.
Quando il pilota può davvero passare in produzione
Questo giudizio ha dei limiti. In alcuni scenari il passaggio dal pilota alla produzione è più lineare.
Un caso è quando il problema è abbastanza chiuso e il processo è indipendente. Per esempio: estrarre dati da moduli con formato fisso, generare descrizioni multilingua per prodotti standardizzati, smistare i ticket interni. Qui i confini dei dati sono chiari, non serve una grande quantità di dati in tempo reale da sistemi esterni, e il divario tra pilota e produzione è relativamente piccolo.
Un altro caso è quando i dati sono già vicini allo stato reale fin dal pilota. Se l’azienda ha una buona base dati — ordini, clienti, anagrafica prodotto strutturati e mantenuti quotidianamente — allora le condizioni del pilota non sono molto diverse dalla produzione. Questo conferma il punto: a decidere il successo della messa in scala non è la scelta del modello AI, ma la maturità di dati e processi dell’azienda.
Al contrario, se durante il pilota si puliscono i dati a fondo per ottenere una bella demo, si simulano tutte le integrazioni e si tiene una persona a controllare, il successo del pilota non solo non prevede il risultato in produzione: nasconde i problemi più importanti.
Quello che non ho ancora chiaro
Il primo punto è la sequenza “prima pilota, poi produzione”. A volte la strategia migliore potrebbe essere saltare il “pilota pulito” e andare direttamente in produzione con un test piccolo e controllato, ma reale. L’effetto serra del pilota è così diffuso che forse la parola “pilota” crea di per sé aspettative sbagliate. Tendo a pensare che molte aziende non abbiano bisogno di un pilota più riuscito, ma di un’entrata in produzione più piccola e più concreta. Però mi mancano ancora abbastanza casi per sostenerlo.
Il secondo punto è il limite inferiore del costo di verifica. Quanto deve essere affidabile un sistema AI perché i dipendenti non debbano più controllare ogni output? Basta mostrare le fonti? Serve un meccanismo di feedback in cui ogni correzione entra nella memoria del sistema? Sul costo marginale di questi accorgimenti per una PMI posso solo dare indicazioni di direzione, non una soglia esatta.
Di una cosa sono certo: tra il successo del pilota e il successo in produzione ci sono progettazione dei processi, governo dei dati e attribuzione delle responsabilità. Non la potenza del modello. Se questo è chiaro, chi decide può fare scelte migliori prima ancora di approvare il pilota.
Fonti
- pilota AI
- AI in produzione
- PMI
- agenti AI
- trasformazione digitale