Pilot AI bloccati: le cinque cause ricorrenti e come riconoscerle

C'è una scena che nei tavoli dove lavoriamo si ripete con una regolarità quasi imbarazzante: il pilot è tecnicamente riuscito, la demo ha convinto tutti, il vendor ha fatturato la sua fase uno, e poi niente. Sei mesi dopo il progetto è ancora lì, in quella terra di mezzo tra "funziona" e "lo usiamo davvero", con un budget consumato e nessuno che sappia dire con precisione perché non si va avanti.

Il fenomeno ha un nome nella letteratura di settore, pilot purgatory, e riguarda la maggioranza delle sperimentazioni AI nelle imprese europee. La cosa che ci colpisce, dopo oltre trenta assessment condotti (dati ZeroFive.AI al 2026), è che le cause quasi mai sono tecnologiche. Sono cinque, si ripetono, e si possono riconoscere prima ancora di avviare il pilot.

Un pilot nato senza una decisione

La prima causa sta a monte, nel momento in cui il pilot viene approvato. In molte organizzazioni la sperimentazione parte per entusiasmo, per pressione competitiva, perché "dobbiamo fare qualcosa con l'AI", e nessuno definisce cosa dovrebbe succedere se il pilot funziona: quale budget scatta, quale processo cambia, chi firma il passaggio in produzione.

Un pilot senza criteri di go/no-go definiti in partenza non è un esperimento, è un rinvio travestito da azione. L'esperimento vero ha un'ipotesi, una soglia di successo e una conseguenza già deliberata per entrambi gli esiti. Quando manca questo, il pilot riuscito finisce in una presentazione e la decisione resta esattamente dove stava.

Dati che non reggono il passaggio di scala

La seconda causa emerge quasi sempre tra la demo e la produzione. Il pilot gira su un dataset curato a mano, pulito per l'occasione, spesso estratto una tantum da qualcuno che conosceva bene quel sistema, e tutto funziona. Poi si prova a collegare i dati veri, quelli che vivono in tre gestionali diversi con anagrafiche disallineate e campi compilati in modo incoerente da anni, e il modello che in demo faceva il 92% di accuratezza smette di essere affidabile.

Il segnale per riconoscere questa causa in anticipo è semplice: chiedere, prima del pilot, quanto tempo servirebbe per ricostruire il dataset di test in modo automatico e ricorrente. Se la risposta è vaga, il problema non è il modello.

Uno sponsor che non c'è, o sono troppi

Terza causa, la più politica. I pilot bloccati hanno quasi sempre una ownership ambigua: il progetto è partito dall'IT ma tocca un processo del commerciale, oppure l'ha voluto un direttore che nel frattempo ha cambiato ruolo, oppure lo sponsor formale è il CEO ma il CEO lo ha delegato a qualcuno che non ha potere di spesa.

Il passaggio in produzione richiede sempre di togliere qualcosa a qualcuno, un processo, un'abitudine, a volte una responsabilità, e questo scatto avviene solo con uno sponsor esecutivo che ci mette la faccia e un team operativo che possiede il processo. Quando nei nostri assessment misuriamo la dimensione che chiamiamo AI Confidence, il commitment del board pesa quanto la robustezza tecnica, una scelta che deriva da quello che vediamo determinare, caso dopo caso, chi scala e chi resta fermo.

Metriche di successo mai scritte

La quarta causa si scopre facendo una domanda sola: come misuriamo se ha funzionato? Nei pilot bloccati la risposta arriva dopo una pausa, e di solito riguarda metriche di modello (accuratezza, precisione, latenza) e mai metriche di business (ore risparmiate, errori evitati, margine recuperato, rischio ridotto).

Le due famiglie di metriche non sono intercambiabili, perché un modello accurato applicato a un processo marginale produce un pilot perfetto e irrilevante. La metrica di business va scritta prima, con il valore atteso e la soglia sotto la quale si chiude, e va scritta da chi possiede il conto economico di quel processo, non dal team tecnico.

Il salto in produzione non era stato progettato

L'ultima causa è quella che i team tecnici conoscono meglio e che il management scopre per ultima. Portare un modello in produzione significa integrazione con i sistemi esistenti, monitoraggio continuo delle performance, gestione delle derive, un presidio di sicurezza e privacy, e da quest'anno anche un perimetro normativo esplicito, con l'EU AI Act che chiede di classificare i sistemi per rischio e documentarli.

Tutto questo ha un costo che spesso supera quello del pilot stesso, e se non era stato stimato all'inizio arriva come una brutta sorpresa che congela il progetto. Il pilot andava progettato con la produzione in mente fin dal primo giorno, con l'architettura di integrazione almeno abbozzata e i requisiti di compliance mappati, perché la validazione riguarda anche la sostenibilità del dopo.

Da dove si riparte

Le cinque cause hanno una radice comune: si è iniziato a costruire prima di aver misurato e deciso. La sequenza sana è inversa, prima si valuta la maturità dell'organizzazione (dati, competenze, governance, commitment), poi si sceglie dove sperimentare con criteri espliciti, poi si valida, e solo dopo si automatizza.

Il nostro AI Rating nasce esattamente per questo passaggio: misura su una scala 0-5 la capacità reale dell'azienda di portare l'AI in produzione, su quattro dimensioni (Readiness, Delivery, Risk, Confidence), e restituisce una roadmap a 90 giorni con i gap da chiudere prima di investire ancora. Chi ha pilot fermi da mesi di solito scopre che il blocco era scritto nei prerequisiti, e che sbloccarlo costa meno di quanto temeva.

Se avete uno o più pilot in questa condizione, il primo passo utile è capire quale delle cinque cause vi riguarda, perché la terapia è diversa per ciascuna. Trenta minuti di conversazione bastano per una prima diagnosi: potete prenotarle su calendly.com/fabiolalli/zerofive, oppure scriverci a hello@zerofive.ai. La domanda con cui vale la pena arrivare è una sola: se il pilot funzionasse domani, chi firmerebbe il passaggio in produzione?