Provate a immaginare la scena. Sala riunioni del comitato esecutivo di una corporate di medie dimensioni, settore regolato. Il Chief Innovation Officer presenta lo stato dei progetti AI dell’anno: sedici iniziative attive, distribuite tra sette funzioni diverse, investimenti complessivi nell’ordine dei 7 milioni di euro. Tutti i sedici progetti hanno superato la fase di pilot interno con successo, almeno secondo le metriche che il team aveva definito all’inizio. Poi il CEO interrompe il flusso della presentazione e fa una domanda diretta: “quanti di questi pilot stanno producendo valore misurabile in produzione?”. Silenzio breve. Poi una risposta onesta: “due, forse tre”.
Indice degli argomenti
Il purgatorio dei pilot AI nelle aziende
Non è uno scenario inventato. È la sintesi di una scena a cui ho assistito di persona qualche mese fa, ma soprattutto è una rappresentazione abbastanza fedele di quello che le grandi survey di settore stanno raccontando da almeno due anni. La survey BCG su mille C-level executive del 2024 rilevava che solo il 26 per cento delle aziende riesce a generare valore tangibile dall’AI, il restante 74 per cento fatica a uscire dalla fase pilota. Un report del MIT NANDA citato da Fortune nell’agosto 2025 ha stimato che il novantacinque per cento dei pilot di AI generativa nelle aziende non produca alcun impatto P&L misurabile. Numeri così alti da sembrare incredibili, e che invece rappresentano la fotografia abbastanza accurata di un settore in cui l’adozione corre molto più veloce della maturazione.
Il fenomeno ha guadagnato un nome nel lessico della consulenza, “pilot purgatory”, letteralmente il purgatorio del pilot. Indica esattamente quella zona intermedia in cui un’iniziativa AI funziona abbastanza da non poter essere chiusa, ma non funziona abbastanza da poter essere scalata, e resta sospesa per mesi o anni in una via di mezzo che consuma budget senza produrre ritorno strutturale. Questa puntata prova a guardare il fenomeno da vicino, per capire cosa succede davvero nel passaggio mancato dal pilot al sistema, e cosa distingue le aziende che riescono a uscirne da quelle che ci restano dentro.
I pattern che bloccano i pilot di AI generativa nelle aziende
I tratti che si ripetono in più aziende, attraverso settori molto diversi, sono abbastanza coerenti da poter essere descritti come pattern.
Troppe iniziative e poche priorità
Il primo è la moltiplicazione delle iniziative senza priorità. Quando l’AI arriva in azienda come tema strategico, ogni funzione vuole avere il proprio pilot, e ogni manager intermedio si sente in dovere di proporne uno. Il risultato è una lista di dieci, 15, 20 progetti che competono per le stesse risorse limitate (data team, infrastruttura cloud, budget di sviluppo, tempo dei consulenti esterni), e in cui ognuno avanza più lentamente di quanto avanzerebbe da solo.
Ownership, metriche e contesto operativo
Il secondo pattern è l’ownership ambigua. Il pilot è promosso dal team di innovazione, sviluppato da una software house esterna o da un fornitore SaaS, supervisionato dal CIO, ma utilizzato da un team operativo che non l’ha richiesto e che non si sente responsabile dei risultati. Quando il pilot funziona, tutti rivendicano paternità. Quando il pilot non funziona, nessuno la rivendica. E in mezzo ci sono settimane di riunioni inconcludenti in cui si discute di metriche senza che nessuno abbia il mandato di prendere decisioni operative.
Il terzo pattern è la metrica auto-referenziale. Il pilot viene valutato sulla base di metriche che il team del pilot ha definito, e che spesso non sono allineate alle metriche con cui l’azienda misura il valore reale. Il sistema “ha gestito 800 richieste con un’accuratezza dell’86 per cento”, ma nessuno sa dire che cosa quelle 800 richieste hanno prodotto in tempo risparmiato, in revenue aggiuntivo, in costi evitati, in soddisfazione cliente migliorata. La metrica esiste, il valore non è collegato.
Il quarto pattern è la mancata cura del contesto. Il pilot lavora su un dataset preparato ad hoc per la dimostrazione, pulito e selezionato, e funziona benissimo. Quando si tenta di farlo girare su dati reali, con tutti i loro silos, le incoerenze, le versioni multiple, le eccezioni non documentate, le performance crollano. Il salto dalla qualità del dataset di pilot alla messy reality dei dati di produzione è una delle cause più ricorrenti del fallimento di scaling, ed è anche quella che le presentazioni interne tendono a minimizzare, perché ammetterla significa ammettere che il pilot è stato disegnato con un’illusione di partenza.
Il quinto pattern è la roadmap senza orizzonte. Il pilot si conclude con un report e una proposta di “fase due”, che però rimane vaga. Cosa esattamente la fase due dovrebbe produrre, in quanto tempo, con quale investimento, con quale ownership, con quali criteri di accettazione. Se queste domande non hanno risposte concrete e condivise tra il management e il team operativo, la fase due non parte mai davvero, e il pilot resta nel limbo del “dovremo decidere”.
Quando due o più di questi pattern coesistono nello stesso progetto, la probabilità che il pilot esca dal purgatorio è bassa. Quando coesistono tutti e cinque, la probabilità è praticamente nulla.
Dove si rompe il passaggio dal pilot AI al sistema
Dietro i pattern che ho descritto si nascondono tre punti di rottura strutturali, ed è utile nominarli perché agire su uno qualsiasi dei tre, anche da solo, può cambiare la traiettoria di un progetto.
Dati, responsabilità e feedback strutturato
Il primo punto di rottura è la qualità dei dati. Non parlo di qualità tecnica intesa come pulizia formale, parlo di qualità operativa intesa come adeguatezza al compito. I dati che un’azienda ha possono essere abbondanti e accessibili, formalmente puliti, e tuttavia inadeguati per il pilot specifico, perché non rappresentano abbastanza i casi limite, perché contengono bias storici che il sistema apprenderebbe e amplificherebbe, perché sono distribuiti su sistemi che non comunicano tra loro, perché vivono in formati che richiedono lavoro di trasformazione prima di essere utilizzabili. Le aziende che escono dal pilot purgatory sono quasi sempre quelle che hanno investito tempo e risorse, prima del pilot, nella preparazione e nella governance dei dati. Quelle che non l’hanno fatto si trovano a doverlo fare in corsa, con costi più alti e qualità peggiore.
Il secondo punto di rottura è l’ownership chiara. Un progetto AI ha bisogno di un proprietario unico, identificato per nome, che risponde dei risultati e ha il mandato di prendere decisioni operative senza dover convocare un comitato per ogni piccolo aggiustamento. Quando l’ownership è distribuita, il progetto rallenta perché ogni decisione richiede un consenso che è strutturalmente difficile da ottenere in un’organizzazione complessa. Quando l’ownership è chiara, il progetto avanza al ritmo che il proprietario sceglie, e i blocchi che emergono possono essere risolti con interventi mirati invece che con riunioni interminabili.
Il terzo punto di rottura è il feedback strutturato. Un sistema AI live produce output. Quegli output vengono usati e corretti, scartati o completati a seconda dei casi. Se le correzioni e gli scarti restano nella testa degli utenti senza essere catturati, il sistema non impara. Se vengono catturati ma non sono restituiti al sistema in forma utilizzabile, il sistema impara male. Se vengono catturati, restituiti e usati per migliorare il prodotto continuamente, il sistema migliora con un rate che la concorrenza non può eguagliare. Le aziende che escono dal pilot purgatory sono quelle che progettano il feedback come parte del prodotto, non come fase successiva al deployment.
Dal pilot AI alla produzione: competenze e organizzazione
Tra il pilot che funziona e il sistema che è entrato in produzione c’è un salto qualitativo che merita di essere nominato esplicitamente, perché è la transizione che molte aziende non riconoscono come tale e quindi non gestiscono. Il pilot dimostra che qualcosa è tecnicamente possibile, in condizioni controllate, con un perimetro definito. Il sistema fa sì che quella possibilità diventi parte stabile del lavoro, integrandosi con i processi esistenti, sopravvivendo alle eccezioni, mantenendo la qualità nel tempo, scalando agli utenti che non erano nel pilot iniziale.
Le competenze richieste per gestire la transizione sono diverse da quelle che hanno fatto funzionare il pilot. Per il pilot servivano data scientist, ML engineer, prompt designer, magari qualche consulente esterno specializzato. Per il sistema servono product manager con esperienza enterprise, competenze di change management e di operations, capacità di formazione degli utenti, supporto continuo, governance dell’evoluzione del prodotto. Aziende che hanno investito molto sui primi profili e poco sui secondi si trovano spesso bloccate proprio nel salto, perché hanno costruito un buon pilot ma non hanno il tessuto organizzativo per portarlo a regime.
Questo squilibrio si presenta in diverse occasioni, e quasi sempre porta allo stesso esito. Il team del pilot, frustrato perché il proprio lavoro non scala, propone una “fase due” che è in realtà un altro pilot più ambizioso, sperando che il problema dello scaling si risolva da sé alla prossima iterazione. Non si risolve. La fase due ripropone gli stessi limiti della fase uno, perché i limiti non erano nella fase uno, erano nel modo in cui l’azienda gestisce il passaggio da fase a fase. Senza un cambio di approccio, il purgatorio si autoalimenta.
Il ruolo del top management nello scaling dell’AI
Le survey corporate sull’AI raccontano un dato che torna con regolarità inquietante. McKinsey, BCG, Deloitte: tutti, con modalità diverse, identificano l’engagement del top management come uno dei discriminanti più forti tra le aziende che riescono a scalare l’AI e quelle che restano nei pilot. Non l’engagement come endorsement pubblico, che ormai tutti i CEO hanno, ma l’engagement come attenzione operativa: il CEO che si siede in riunioni di review trimestrali sull’AI, che chiede metriche specifiche, che spinge per priorità chiare, che protegge le iniziative dalla pressione di altre richieste interne.
Quando il management si limita all’endorsement pubblico, l’AI diventa un altro filone di iniziative tra tanti, e finisce nel sottobosco delle priorità operative. Quando il management si impegna nell’attenzione operativa, l’AI riceve la priorità necessaria per emergere, anche al prezzo di rallentare altre iniziative. Le aziende che scalano sono quelle dove il CEO sa rispondere, in qualunque momento, alla domanda “quali due o tre workflow stiamo ridisegnando con l’AI quest’anno”, senza dover consultare il dossier preparato dal CIO. Le aziende che non scalano sono quelle dove il CEO conosce il numero di pilot attivi, ma non i workflow che stanno diventando diversi.
Per gli innovation manager corporate, questo è un punto delicato. Non sempre si può scegliere il livello di engagement del top management, ma si può influenzarlo costruendo report che parlino la lingua del business invece della lingua della tecnologia. Non “abbiamo deployato un modello fine-tuned su trecento pratiche”, ma “abbiamo ridotto del trentadue per cento il tempo medio di lavorazione delle pratiche di credito di importo inferiore a centomila euro, con un impatto annualizzato stimato di quattrocentomila euro su un costo operativo di un milione e duecentomila”. La differenza non ha solo natura cosmetica, ha anche natura sostanziale, perché un management che vede l’AI in termini di impatto business è un management che proteggerà le iniziative dalle ondate di tagli ricorrenti.
Cosa fanno le aziende che escono dal pilot purgatory
Le aziende che riescono a uscire dal purgatorio condividono alcuni comportamenti operativi abbastanza riconoscibili. Non sono garanzia di successo, ma sono condizioni necessarie che spesso mancano dove il purgatorio diventa cronico.
Meno progetti, più prodotto e governance
Riducono il numero di iniziative attive. Invece di sedici progetti paralleli, scelgono tre o quattro priorità chiare e concentrano risorse su quelle. La survey McKinsey State of AI 2025 ha trovato che gli high performer perseguono circa la metà delle iniziative degli altri, ma ne scalano molto di più. È una scelta di disciplina che richiede di dire no a richieste interne legittime, e che richiede al management di proteggere le scelte di concentrazione anche quando arrivano pressioni per espandere.
Investono in figure di prodotto enterprise prima ancora che in talenti tecnici scarsi. Un buon product manager con esperienza di scaling enterprise vale più di tre data scientist senior, in questa fase di mercato, perché la frizione che blocca i progetti è quasi sempre organizzativa, non tecnica. Aziende che riescono a scalare sono quelle che hanno questi profili in casa o che hanno saputo attrarli, anche pagandoli sopra la media interna.
Costruiscono un’infrastruttura di feedback fin dal pilot. Non aspettano il deployment per progettare come gli utenti correggeranno il sistema, come quei feedback verranno aggregati, come torneranno nel prodotto. Ogni pilot in queste aziende esce con un piano esplicito di feedback strutturato, e il piano viene rivisto trimestralmente man mano che il sistema evolve.
Negoziano un mandato chiaro con il top management prima di partire. Non solo budget e risorse, ma anche definizione esplicita di cosa significa successo, di chi decide cosa, di come si affronterà il primo conflitto interno quando emergerà. Le iniziative AI che falliscono più clamorosamente sono spesso quelle che partono con entusiasmo bipartisan e si schiantano al primo conflitto reale tra funzioni diverse, perché nessuno aveva pre-negoziato il meccanismo di risoluzione.
Trattano la governance come componente di prodotto, non come adempimento successivo. Definiscono fin dall’inizio quali errori sono tollerabili e quali no, chi vede i log delle interazioni del sistema, chi può approvare modifiche al comportamento, come si gestiscono i casi limite che richiedono escalation umana. Quando lanciano il sistema, queste aziende hanno già attraversato le conversazioni difficili con compliance, legal e IT security, e questo permette al sistema di entrare in workflow sensibili senza generare allarmi che ne bloccano l’adozione. Le aziende che invece trattano governance come fase post-deployment si trovano spesso a dover ridisegnare il prodotto a sei mesi dal lancio, perché qualche aspetto della compliance è emerso troppo tardi.
La lezione per startup AI e progetti corporate
Quanto abbiamo scritto nei precedenti articoli, letto dal punto di vista di un innovation manager corporate, racconta la stessa partita vista dall’altro lato del tavolo. Le stesse leggi del wedge, del workflow, del contesto, della fiducia operativa, valgono per i pilot interni che lancia una grande azienda.
Un pilot interno che parte largo è destinato a fallire come una startup che parte larga. Un pilot che non costruisce contesto operativo specifico è destinato a funzionare in dimostrazione e fermarsi nel deployment. Un pilot la cui posizione dipende interamente dal modello sottostante è esposto alla stessa fragilità di una startup wrapper.
Lo specchio funziona anche al contrario, e qui c’è un’opportunità che molti fornitori sottovalutano: una startup AI che capisce dove la corporate è bloccata nel pilot purgatory, e propone un percorso per uscirne invece di una tecnologia che richiede alla corporate di fare i compiti a casa prima dell’adozione, parte da una posizione di vendita molto diversa. Le startup AI che vendono meglio in enterprise oggi sono quelle che si presentano con un metodo di lavoro più che con un prodotto: il prodotto è dentro, ma quello che il cliente compra è la traiettoria che porta dal primo workflow ridisegnato all’ottavo, dieci-dodici mesi dopo.
Resta una domanda da tenersi addosso prima di approvare il prossimo progetto AI corporate: questo progetto è disegnato per uscire dal purgatorio, o è disegnato per restarci dentro elegantemente? La differenza, in molti casi, sta nei dettagli operativi che sembrano noiosi (chi possiede il caso d’uso, come si misura il successo, cosa accade dopo il pilot, chi paga la fase di scaling), e che invece sono i veri discriminanti. Investire dieci settimane in più nella fase di setup, e fare bene quei dettagli, vale spesso più di sei mesi di sviluppo aggiuntivo.
La prossima puntata propone uno strumento operativo concreto per applicare tutto questo a una valutazione: una scorecard in 12 punti che permette di capire, in quindici minuti, se una startup AI o un progetto AI corporate sta davvero costruendo un loop o sta solo accumulando volumi senza accumulare vantaggio. La trattazione completa del framework, con la roadmap dal pilot alla posizione e gli strumenti operativi, è nel libro Da Zero a Loop.
Partecipa alla community