Perché il 95% dei piloti di IA fallisce prima di produrre un solo risultato
C'è una scena che si ripete in quasi tutte le aziende di medie dimensioni che conosco. Il team tecnologico presenta un pilota di intelligenza artificiale. I numeri iniziali sono promettenti. Il consiglio di amministrazione approva l'investimento. E sei mesi dopo, il pilota è ancora un pilota. Nessuno lo interrompe ufficialmente. Non scala nemmeno. Semplicemente... occupa spazio nel roadmap e nelle riunioni di follow-up.
Dennis Woodside, presidente e CEO di Freshworks, ha pubblicato qualche giorno fa un'analisi su Fortune che dà un nome a questo fenomeno. E sebbene l'articolo serva anche come posizionamento commerciale per la sua azienda, la diagnosi che offre merita di essere presa sul serio per una ragione semplice: i dati esterni che cita sono scomodi per qualsiasi C-Level che da più di un anno stia promettendo risultati di IA al proprio consiglio di amministrazione.
Il MIT ha rilevato che il 95% dei piloti di IA generativa fallisce prima di arrivare in produzione. Boston Consulting Group ha pubblicato a settembre 2025 che il 60% delle aziende non genera alcun valore materiale con l'IA, e quella percentuale è peggiorata rispetto all'anno precedente, nonostante i modelli siano migliorati e l'esperienza accumulata sia aumentata. Freshworks aggiunge un dato proprio: un quarto del budget destinato all'IA nelle PMI viene consumato in integrazione, pulizia dei dati e nello sforzo di far comunicare sistemi che non sono mai stati progettati per farlo.
Ciò che questi tre numeri hanno in comune non è il modello di IA scelto. È lo stato dell'ambiente operativo in cui si tenta di implementare.
La decisione che separa chi avanza da chi si blocca
Woodside descrive il caso di Seagate Technology con una precisione che risulta utile proprio perché non ha glamour. Il team IT aveva tre mesi per migrare 30.000 dipendenti su una nuova piattaforma di gestione dei servizi, forzato dalla scadenza di un contratto. La decisione ovvia, quella che quasi qualsiasi organizzazione avrebbe preso sotto quella pressione, era spostare le configurazioni esistenti così come stavano e risolvere i problemi in seguito. È il percorso più sicuro nel breve termine. È anche quello che garantisce che qualsiasi livello di IA costruito sopra opererà su fondamenta difettose.
Il team di Seagate scelse il contrario. Ricostruì da zero: ristrutturò il catalogo dei servizi, stabilì livelli di servizio coerenti tra le regioni, riscrisse le gerarchie di categorie affinché i ticket potessero essere instradati automaticamente senza che un agente dovesse indovinare. Lo fece nello stesso arco di tre mesi. Un anno dopo, l'agente di IA distribuito su quella base deflette circa un terzo dei ticket in entrata e la risoluzione al primo contatto è del 27% al di sopra dello standard del settore.
Quella decisione, ricostruire invece di replicare, è il fulcro dell'argomento di Woodside. E ha una lettura organizzativa che va ben oltre la tecnologia.
Ciò che Seagate ha fatto ha richiesto che qualcuno, a un certo punto del processo, avesse una conversazione che nessuno voleva avere: quella che riconosce che i processi ereditati non sono semplicemente inefficienti, ma rappresentano un ostacolo attivo a qualsiasi miglioramento futuro. Quella conversazione ha un costo politico. Dire che i processi attuali non verranno trasferiti significa dire che anni di lavoro di configurazione, personalizzazione e ottimizzazione non viaggeranno nel nuovo ambiente. Significa invalidare, almeno in parte, decisioni passate. Poche organizzazioni hanno l'appetito per questo sotto pressione di tempo.
Ciò che distingue Seagate non è l'aver avuto più risorse né più tempo. È l'aver avuto la lucidità, o il coraggio direttivo, di non trascinare il passato in avanti quando il contratto è scaduto. Questa è la variabile che non appare in nessun manuale di implementazione dell'IA.
L'imposta invisibile che paga chi non guarda i propri processi
Woodside introduce il concetto di "imposta della complessità" per descrivere ciò che accade quando un'azienda cerca di implementare l'IA su un'architettura frammentata. Non è una metafora decorativa. È una meccanica finanziaria concreta.
Se il 25% del budget destinato all'IA viene perso in integrazione e pulizia dei dati prima che il modello produca un singolo output utile, un'azienda che assegna un milione di dollari all'IA sta acquistando, in pratica, 750.000 dollari di capacità. Il restante 25% viene assorbito dal debito tecnico accumulato. Per una grande azienda con budget di trasformazione di centinaia di milioni, quella frazione può essere tollerata. Per un'azienda con tra 500 e 20.000 dipendenti, con team IT ridotti e margini di manovra minori, quella perdita può fare la differenza tra un'iniziativa che prospera e una che viene cancellata silenziosamente nel successivo ciclo di budget.
L'argomento di Woodside sulle "aziende agili", il suo termine per quella fascia di organizzazioni di medie dimensioni, ha una logica che i grandi media tendono a ignorare perché il segmento non è così fotogenico come le storie di trasformazione digitale delle Fortune 500. Ma è proprio lì che si vincerà o si perderà la battaglia di produttività che l'IA promette. Le PMI rappresentano la maggior parte del tessuto imprenditoriale globale. Se l'IA non funziona lì, la promessa di produttività aggregata non si materializza, indipendentemente da ciò che fanno Google, Microsoft o Amazon con i loro modelli proprietari.
Ciò che rende l'analisi ancora più interessante è che il problema non risiede nella selezione del modello. Si trova in uno strato precedente e più difficile da risolvere: la qualità dell'ambiente operativo. Dati dispersi in sistemi che non comunicano tra loro. Flussi di lavoro definiti dalla storia dell'azienda più che dalla sua logica. Tassonomie di ticket, categorie di servizi o gerarchie di prodotti che nessuno ha mai rivisto perché avevano sempre "funzionato abbastanza bene". Quando si chiede a un agente di IA di operare su quell'infrastruttura, non fallisce perché il modello sia scadente. Fallisce perché l'ambiente gli consegna informazioni ambigue, incomplete o contraddittorie, e nessun modello può compensare questo.
Robert Lyons, direttore tecnologico di Katz Media Group, un'unità di business di 800 persone all'interno di un'azienda da 10.000 dipendenti, offre nell'analisi di Woodside quello che è forse il consiglio più pratico dell'intero articolo: prima di distribuire qualsiasi strumento di IA, il suo team ha pulito ed etichettato i dati, e ha realizzato un seminario introduttivo all'IA per tutti i dipendenti dell'azienda, condotto non dal team IT ma da una società di ricerca indipendente. La distinzione è importante. Quando è IT a presentare l'IA, lo fa con il bias implicito di chi ha un interesse nel risultato. Quando lo fa un terzo neutrale, il messaggio arriva in modo diverso e la resistenza organizzativa si abbassa.
Lyons descrive anche una matrice valore/sforzo per dare priorità ai progetti di IA: facilità di implementazione su un asse, valore per il business sull'altro. Si parte dal quadrante ad alto valore e basso sforzo. Il suo avvertimento, "non iniziare con il problema peggiore, non genererai valore", è una critica diretta a un pattern che osservo frequentemente nelle organizzazioni che trattano l'IA come un'opportunità per risolvere i problemi che nessun'altra iniziativa è riuscita a risolvere. Quella logica è comprensibile ma controproducente. I progetti di IA più visibili e ambiziosi sono anche i più fragili, perché operano sugli ambienti di dati più disorganizzati e i flussi di lavoro meno strutturati.
Cosa hanno in comune Nucor e New Balance con un'azienda siderurgica
Woodside cita due comparazioni che meritano attenzione separata. La prima è tra Nike e New Balance. Nike opera con 80.000 dipendenti; New Balance con 9.000. Woodside sostiene che New Balance stia guadagnando terreno competitivo consolidando la propria infrastruttura IT in un'unica piattaforma con una fonte di verità centralizzata, liberando i team dal lavoro di manutenzione e riconfigurando il modo in cui opera il business. La seconda comparazione riguarda Nucor e Steel Dynamics, due dei quattro maggiori produttori di acciaio degli Stati Uniti, che secondo Woodside portano avanti decenni di disciplina operativa che produce ambienti che l'IA può ottimizzare direttamente.
Il pattern che collega questi casi è lo stesso che appare in Seagate: l'IA funziona dove l'ambiente operativo era pronto ad accoglierla. Non perfetto. Pronto. Dati consolidati, flussi di lavoro definiti, sistemi capaci di scambiare informazioni senza intervento manuale, e un risultato misurabile che l'agente di IA deve migliorare.
Questo ha un'implicazione direttiva che pochi stanno nominando con chiarezza. Le aziende che hanno più difficoltà a implementare l'IA non sono quelle che hanno scelto il modello sbagliato o quelle che hanno assunto i consulenti sbagliati. Sono quelle che per anni hanno preso decisioni tecnologiche privilegiando la continuità operativa rispetto alla coerenza architettonica. Ogni volta che qualcuno ha detto "aggiungiamo questo sistema perché risolve questo problema adesso" senza chiedersi come quel sistema si sarebbe integrato con il resto, stava accumulando una passività che oggi si paga sotto forma di budget di IA consumato in integrazione.
Quella passività non è un fallimento tecnico. È il risultato cumulato di conversazioni sull'architettura che non sono mai avvenute, di valutazioni del debito tecnico che sono state rimandate perché il trimestre richiedeva velocità, di configurazioni ereditate che nessuno ha voluto rivedere perché il costo politico di metterle in discussione era troppo alto.
Ciò che i casi di successo descritti da Woodside hanno in comune è che qualcuno, in un certo momento, ha preso la decisione di pagare quella passività. Seagate lo ha fatto sotto la pressione di un contratto in scadenza. New Balance lo ha fatto come parte di una scommessa strategica sulla velocità. Nucor e Steel Dynamics lo hanno fatto per decenni senza sapere che stavano costruendo le basi per un vantaggio competitivo nell'IA.
Chi guida deve pagare il costo di guardare ciò che l'organizzazione evita di nominare
C'è un elemento dell'argomento di Woodside che l'articolo tocca tangenzialmente ma che merita di essere nominato direttamente: la maggior parte delle organizzazioni che sono bloccate nei piloti di IA lo sa. Non è ignoranza tecnica. È che la conversazione sullo stato dell'ambiente operativo ha un costo politico che nessuno vuole pagare.
Ammettere che il 25% del budget di IA viene perso in integrazione e pulizia dei dati significa ammettere che le decisioni architettoniche del passato sono state costose. Ammettere che i processi ereditati non possono essere trasferiti al nuovo ambiente significa ammettere che anni di configurazione non sopravvivono al cambiamento. Ammettere che i dati sono in cattivo stato significa ammettere che le iniziative di qualità dei dati degli ultimi anni non hanno consegnato ciò che promettevano.
Quelle ammissioni richiedono qualcosa che la dinamica di molti consigli di amministrazione disincentiva: la capacità di nominare un problema strutturale senza che la persona che lo nomina venga associata al fallimento che descrive.
Il lavoro di chi guida in questo contesto non è tecnico. È creare le condizioni affinché quelle conversazioni avvengano senza che il messaggero sia il costo. Le organizzazioni che stanno generando risultati con l'IA, i casi che Woodside descrive, non hanno ambienti perfetti. Hanno leader che hanno deciso di pagare il costo della chiarezza prima di pagare il costo dell'implementazione fallita.
Quella sequenza non è intuitiva sotto pressione. Ma è l'unica che produce risultati che non svaniscono nel successivo ciclo di revisione del budget.
