La demo è andata in scena un martedì, nella sala riunioni buona, quella con lo schermo che funziona. Il modello ha letto un contratto di fornitura di quaranta pagine e lo ha riassunto in nove secondi. Ha risposto a domande sulle clausole di manleva. Ha redatto un'email di follow-up nel tono di voce dell'azienda. Ha trovato una data di rinnovo sepolta in un allegato, quella che l'ufficio legale una volta si era persa davvero, una svista che era costata all'azienda un rinnovo automatico imbarazzante e un trimestre di domande scomode in consiglio. Qualcuno nella stanza ha detto "wow" a voce alta. Il CFO, arrivato scettico, ha chiesto quando si poteva estendere a tutto il procurement.
Erano quattordici mesi fa. Il pilota è ora ufficialmente "sospeso in attesa di ulteriori valutazioni", che in aziendese vuol dire morto.
Se la storia suona familiare è perché è la storia mediana. L'iniziativa NANDA del MIT, nel suo molto discusso report "State of AI in Business 2025", ha rilevato che circa il 95% dei pilot GenAI enterprise non produce alcun impatto misurabile sul conto economico. S&P Global Market Intelligence ha intervistato oltre mille aziende e ha trovato che il 42% aveva abbandonato la maggior parte delle proprie iniziative AI nel 2025, contro il 17% dell'anno prima, con l'organizzazione media che rottama quasi metà dei propri proof-of-concept prima della produzione. Gartner aveva previsto che il 30% dei progetti GenAI sarebbe stato abbandonato dopo il proof-of-concept entro fine 2025. Si può discutere ogni singolo numero; non si può discutere la direzione in cui puntano tutti.
Le spiegazioni standard sono immaturità organizzativa, dati sporchi, fallimento del change management, mancanza di sponsorship esecutiva. Tutte reali, tutte secondarie. Voglio sostenere una cosa più scomoda: la maggior parte dei pilot non fallisce lungo la strada verso la produzione: non era mai sulla strada verso la produzione, perché un pilota e un sistema di produzione sono due oggetti diversi, ottimizzati per due cose diverse. Un pilota è ottimizzato per essere creduto. Un sistema di produzione è ottimizzato per sopravvivere. Le competenze, il budget, l'architettura e la responsabilità richieste dal secondo sono quasi del tutto assenti nel primo. Il che significa che un pilota riuscito porta molta meno informazione sulla fattibilità in produzione di quanta chi lo finanzia assuma: vicina a zero, in molti casi. Il 95% non è un gap di maturità in attesa di essere chiuso da modelli migliori o da un change management migliore. È un errore di misura: abbiamo testato l'oggetto sbagliato.
La demo campiona il percorso felice. La produzione campiona tutto.
Si parte dal meccanismo, perché tutto il resto ne discende.
Una demo, e quasi tutti i pilot sono demo estese, gira su input scelti, più o meno consapevolmente, per essere rappresentativi del caso tipico. Il contratto pulito. L'email del cliente ben formata. La domanda che il team aveva in testa mentre costruiva la cosa. Un sistema di produzione gira sull'intera distribuzione degli input: il PDF scansionato che in realtà è la foto di un fax, l'email scritta metà in portoghese, il cliente che fa tre domande in una frase, l'utente avversario, il caso limite che nessuno aveva immaginato perché, per definizione, la coda non la immagini: la incontri.
Questo conta più per i sistemi AI di quanto sia mai contato per il software tradizionale, per una ragione precisa: gli errori nei workflow AI a più passi si compongono in modo moltiplicativo. Se un modello è corretto il 95% delle volte su un singolo passo, un numero davvero buono, un workflow che incatena cinque passi del genere riesce circa il 77% delle volte. Dieci passi: 60%. Venti: 36%. Il software tradizionale non si comporta così, perché il codice deterministico è corretto o sbagliato per caso, e i casi li puoi enumerare e correggere. Un sistema probabilistico è approssimativamente corretto per passo, e l'approssimazione decade con la profondità.
Quindi il pilota e il sistema di produzione non stanno in due punti della stessa curva, con la produzione semplicemente "più avanti". Sono valutati su distribuzioni diverse. Il pilota è valutato sull'input mediano, dove i modelli moderni sono francamente spettacolari. La produzione è valutata sulla coda, perché in un'azienda la coda è dove vivono le cause legali, i rimborsi, gli incidenti di compliance e gli screenshot sui social. Un sistema brillante sul mediano e inaffidabile sulla coda non è al 90% della strada verso il deploy. In un contesto regolato o rivolto al cliente può essere al 20%, perché il lavoro che resta, rilevare, contenere e recuperare i fallimenti di coda, è la maggior parte dell'ingegneria.
E quindi la prima implicazione per chi decide: quando un team riferisce "il pilota funziona", l'unica risposta rigorosa è una domanda: su quale distribuzione? Se la risposta è "sui casi che abbiamo provato", hai imparato che il modello è notevole. Lo sapevi già. Hai speso sei mesi e qualche centinaio di migliaia di euro per confermare un comunicato stampa.
Nel software probabilistico, la valutazione è il prodotto
C'è un secondo meccanismo, meno discusso e più fondamentale.
Con il software deterministico la verifica è difficile ma limitata: scrivi i test, i test passano o falliscono, e una suite verde è un fatto durevole sul sistema. Con un sistema basato su LLM, "funziona?" non è una domanda sì/no. È un'affermazione statistica, produce output accettabile l'X% delle volte sulla distribuzione Y, dove "accettabile" è definito dal giudizio Z, e ogni termine di quell'affermazione è qualcosa che devi costruire. Ti serve un set di valutazione etichettato che assomigli davvero al traffico di produzione. Ti serve una definizione di "accettabile" abbastanza precisa da poterci dare un punteggio, il che costringe il business ad articolare cose che non ha mai messo per iscritto. Devi rieseguire tutto ogni volta che cambia il prompt, cambia la versione del modello o deriva il mix di input, e il fornitore il modello lo cambierà che ti piaccia o no.
Questa impalcatura, il set di eval, lo scoring, la pipeline di regressione, il monitoraggio in produzione che intercetta la deriva, non è un'impalcatura attorno al prodotto. Per un sistema AI enterprise è il prodotto, nello stesso senso in cui la portata di un ponte è il ponte. Il modello è sempre più una commodity che noleggi; tre concorrenti chiamano la stessa API. L'impalcatura è la parte che possiedi, quella che codifica i tuoi dati, il tuo giudizio, i tuoi modi di fallire.
Ora guarda cosa contiene un pilota tipico: un prompt, una chiamata API, un'interfaccia elegante e un copione per la demo. Nessun set di eval, nessuno scoring, nessun monitoraggio. Non perché il team sia pigro, ma perché la funzione reale del pilota, il lavoro per cui è stato assunto, è assicurarsi il prossimo round di finanziamento interno, e le impalcature non si fanno belle in demo. Nessuno applaude una matrice di confusione.
È anche per questo che l'inquadratura di Gartner è quella giusta: i progetti vengono abbandonati non perché la tecnologia ha fallito, ma perché l'organizzazione non è riuscita a costruire la macchina per migliorare in sicurezza in produzione. Un pilota senza eval harness non può nemmeno dirti che sta fallendo. Può solo dirti che una volta ha impressionato un CFO.
Nessuno viene svegliato alle 3 di notte per un pilota
Il terzo meccanismo è organizzativo, ed è quello su cui un CEO può agire più in fretta.
Pensa a tutto ciò che un sistema di produzione ha e un pilota no. Un proprietario il cui nome è attaccato quando si rompe alle 3 di notte. Un turno di reperibilità. Un error budget. Un percorso di escalation quando il modello produce qualcosa che non dovrebbe. Log di audit, perché il regolatore chiederà. Controlli di accesso, perché il riassuntore di contratti non deve riassumere la cartella M&A per uno stagista. Un piano di rollback. Una SLA del fornitore che qualcuno ha davvero letto. Una riga di budget che sopravvive all'anno fiscale. Un workflow di revisione umana per il 4% di casi che il sistema segnala come incerti, e una definizione di chi sono quegli umani, qual è la loro capacità oraria, e cosa succede quando sono in ferie.
Un pilota ha uno sponsor. La produzione ha bisogno di un proprietario. Sono specie diverse. L'incentivo dello sponsor è che il pilota sembri riuscito; l'incentivo del proprietario è che il sistema sia affidabile, perché è lui a ricevere la chiamata. Nella maggior parte delle aziende, nel momento in cui un pilota "riesce", affronta un passaggio di consegne da un team di innovazione senza alcuna responsabilità operativa a un'organizzazione IT o di linea che non l'ha mai chiesto, non si fida, non può vedere i risultati di eval (non ce ne sono) e a cui si chiede di presidiare il rischio di coda con un budget invariato. L'organizzazione ricevente fa la cosa razionale: si blocca. Lo chiamiamo "fallimento di scaling". È in realtà un sistema immunitario che funziona correttamente, e rigetta un organo arrivato senza gruppo sanguigno.
Cosa significa per il capitale, le assunzioni e cosa smettere di fare
Tira la catena delle conseguenze, perché ogni meccanismo atterra su una decisione.
Allocazione del capitale. Se l'impalcatura e l'integrazione sono l'80% del lavoro, il budget dovrebbe assomigliare a questo, e quasi nessun budget di pilota lo fa. La struttura di costo onesta di un sistema AI enterprise è grosso modo l'inverso di come viene tipicamente finanziato: una fetta sottile per il modello e i prompt, il grosso per valutazione, monitoraggio, integrazione nel workflow e loop di revisione umana. Una regola pratica: se il budget di una proposta è quasi tutto modello e UI, stai finanziando una demo, comunque la chiami la slide.
Build contro buy. I dati del MIT contengono un numero poco esaminato: le soluzioni acquistate da fornitori specializzati arrivavano al deploy circa il 67% delle volte, mentre i build interni riuscivano a circa un terzo di quel tasso. Il meccanismo è esattamente quello di sopra: un fornitore che serve cinquanta clienti ha ammortizzato l'impalcatura, la gestione dei casi di coda e i pattern di integrazione su tutti loro. Quando costruisci internamente, paghi a prezzo pieno l'80% invisibile. Il build interno ha senso dove il workflow stesso è il tuo fossato; ovunque altro, stai costruendo a mano delle tubature.
Assunzioni. La competenza scarsa non è il prompt engineering, che è la parte che diventa più facile a ogni generazione di modelli. È l'evaluation engineering e l'ML operations: persone che sanno costruire un set di test che assomiglia alla realtà, definire "buono" in codice di scoring, e far girare la macchina statistica che trasforma "sembra a posto" in "è corretto il 96,2% delle volte ed ecco l'alert quando scende". Quasi tutte le aziende hanno zero persone del genere, e assumono per il ruolo sbagliato.
Incentivi. Smettete di contare i pilot. Il numero di pilot AI lanciati è una metrica da teatro dell'innovazione, con lo stesso rapporto col valore che le righe di codice hanno con la qualità del software. Contate i sistemi in produzione con un proprietario, una suite di eval e novanta giorni di traffico monitorato. Guardate come si restringe il portafoglio, e quanto diventa più onesta la conversazione.
Le obiezioni oneste
Due controargomenti seri meritano la loro versione più forte.
Primo: un'alta mortalità dei pilot è sana. I pilot sono opzioni a basso costo; sei tenuto a uccidere la maggior parte. Vero, e se il 95% morisse perché il caso d'uso si è rivelato a basso valore, sarebbe un portafoglio che funziona bene. Ma non è questo il pattern di fallimento osservato. Il pattern sono pilot che riescono secondo i propri criteri e non vanno comunque mai in produzione. Un'opzione che non puoi esercitare nemmeno quando scade in-the-money non è un'opzione. È teatro con una riga di budget.
Secondo: i modelli migliori chiuderanno il gap. In parte giusto. Man mano che i modelli di frontiera diventano più affidabili per passo, la matematica del compounding migliora, e la linea tra "serve un'impalcatura pesante" e "abbastanza buono out of the box" si sposta: si è visibilmente spostata per compiti come riassunto e assistenza al codice dal 2023. Ma nota quali meccanismi un modello migliore aggiusta e quali no. Alza l'accuratezza per passo. Non crea il tuo set di eval, non si integra col tuo ERP, non definisce il tuo percorso di escalation, non assegna un proprietario che riceve la chiamata. Il gap di capacità si sta chiudendo; i gap di verifica e responsabilità non sono problemi di modello, e aspettare GPT-7 per risolvere il tuo organigramma non è una strategia.
Spedisci una fetta, non un pilota
La soluzione non è pilot migliori. È rifiutare del tutto la dicotomia pilota/produzione.
Prendi un solo workflow stretto, abbastanza stretto da essere quasi imbarazzante, e costruiscilo come produzione dal primo giorno: traffico vero, suite di eval vera, proprietario vero, reperibilità vera, log di audit vero. Un solo tipo di contratto, non tutti i contratti. Una sola coda di supporto, non l'intera casella. Andrai più piano per il primo trimestre e sarai l'unico team nell'edificio che sa, con i numeri, se la cosa funziona. Poi allarghi la fetta.
E prima di finanziare qualunque cosa, fai l'unica domanda che separa il 5% dal resto. Non "la demo ci ha impressionato?": la demo impressiona sempre, è ciò per cui esistono le demo. Chiedi: chi viene svegliato quando questa cosa sbaglia alle 3 di notte, e quale dashboard sta guardando?
Se non c'è un nome e non c'è una dashboard, non hai una strategia AI. Hai un martedì nella sala riunioni buona.
Fonti: MIT NANDA, "The GenAI Divide: State of AI in Business 2025" (via Fortune) · S&P Global Market Intelligence, indagine GenAI 2025 · CIO Dive sui dati di abbandono S&P Global