Perché il 95% dei progetti di IA aziendale non sopravvive al pilota
C'è una differenza tra una dimostrazione che stupisce in una sala riunioni e un sistema che funziona dal lunedì al venerdì senza che qualcuno debba intervenire per salvarlo. L'industria dell'intelligenza artificiale trascorre ormai due anni a costruire la prima con una maestria che non è riuscita a trasferire alla seconda. E la ragione non risiede nei modelli, che sono sempre più potenti. Risiede nel modo in cui si è scelto di parlare di loro, e per estensione, nel modo in cui si è scelto di costruirli.
La cifra che circola tra i team tecnici più onesti del settore è difficile da ignorare: fino al 95% dei progetti di IA generativa nelle aziende non riesce a produrre un ritorno sull'investimento misurabile, secondo il MIT NANDA Initiative, citato da Iris.ai. Un tasso di fallimento compreso tra il 70 e il 95 per cento non è un segnale che il mercato "non è ancora maturo". È un segnale che qualcosa di strutturale è rotto nel modo in cui si sta costruendo.
Enrique Dans, in un articolo pubblicato il 10 giugno 2026 su Fast Company, indica dove si trova la frattura. Non nella capacità tecnica dei modelli linguistici. Non nella resistenza dei dipendenti. Ma in qualcosa di più difficile da ammettere per un'industria che vive di convincere gli investitori: l'IA aziendale è stata costruita su metafore invece che su modelli formali. E le metafore, per quanto utili siano a vendere, non si industrializzano.
Dal linguaggio poetico all'architettura che non scala
L'inventario delle metafore che ha popolato il discorso sull'IA negli ultimi due anni è esteso e rivelatore. I sistemi "ricordano", "riflettono", "pianificano" e, nel caso della tecnica del "sogno" che Anthropic ha descritto per i propri agenti, letteralmente "dormono". La documentazione dell'API degli Assistenti di Azure OpenAI descrive "thread" che memorizzano la cronologia dei messaggi e la troncano quando la finestra di contesto si esaurisce, presentando questo come "memoria". Il team di ingegneria di Anthropic parla di agenti "a lunga durata" che devono "preservare la continuità tra le sessioni".
Nessuna di queste descrizioni è tecnicamente scorretta. Il problema è che sono descrittive quando devono essere formali. Una metafora descrive. Un modello formalizza. Questa differenza ha conseguenze economiche dirette.
Quando la "memoria" non è un modello di dati ma un'analogia operativa, non esiste un'identità definita, non esiste uno stato persistente, non esistono relazioni con permessi espliciti, non esistono vincoli che il sistema garantisca indipendentemente da chi lo utilizzi o da quante volte venga interrogato. Non esistono, in termini tecnici, invarianti: le regole che un'architettura mantiene indipendentemente dalle condizioni esterne. Senza invarianti, ogni implementazione è una nuova negoziazione. Ogni distribuzione richiede che qualcuno traduca la realtà operativa dell'azienda nel linguaggio che il sistema può elaborare. E quella traduzione non può essere delegata a un modello predefinito.
Il risultato osservabile è che i principali fornitori di IA di frontiera, tra cui OpenAI e Anthropic come descrive l'articolo di Dans, stanno inviando ingegneri e team sul campo dai propri clienti aziendali per mappare i flussi di lavoro, definire i vincoli e connettere i sistemi. Quello che sembra un servizio premium è in realtà un segnale strutturale: la piattaforma non riesce a farcela da sola. Quando la traduzione personalizzata diventa la modalità dominante di erogazione, il prodotto smette di essere una piattaforma e diventa consulenza con interfaccia tecnologica.
Il costo di questo modello per i compratori è duplice. In primo luogo, la spesa diretta per l'integrazione su misura che deve essere ripetuta ogni volta che cambia un sistema, una normativa o un processo interno. In secondo luogo, il costo opportunità del non poter scalare: se ogni nuova applicazione richiede lo stesso intervento manuale, il ritorno marginale di ogni implementazione aggiuntiva non migliora nel tempo. La curva dei costi non scende. La promessa della piattaforma non si materializza.
Il pattern storico che l'industria dell'IA non ha ancora attraversato
Dans collega il momento attuale dell'IA aziendale a tre transizioni tecnologiche che sono effettivamente riuscite a industrializzarsi, e il confronto è scomodo per chi preferisce pensare che gli agenti di IA siano un fenomeno senza precedenti.
Edgar F. Codd sviluppò il modello relazionale dei dati negli anni Settanta. Prima di quel lavoro, i database erano implementazioni proprietarie, ciascuna con il proprio linguaggio, la propria logica di archiviazione e il proprio metodo di accesso. Dopo Codd, esisteva un'astrazione formale: relazioni, attributi, chiavi, dipendenze funzionali. Su quella formalizzazione nacque SQL, e su SQL nacque un mercato da miliardi di dollari in software, integrazioni e servizi. Ciò che rese possibile quel mercato non fu che i database diventassero più potenti. Fu che diventarono descrivibili con sufficiente precisione affinché due sistemi indipendenti potessero comprendersi senza negoziazione preliminare.
Il web seguì lo stesso schema. Il W3C definì risorse identificati da URI, un protocollo senza stato formalizzato nell'RFC 9110, e una grammatica condivisa di metodi HTTP, codici di stato e HTML. Nessuna azienda inventò il browser e poi chiese ai propri clienti di assumere consulenti per interpretare il significato delle proprie pagine. La grammatica era pubblica, formale e sufficientemente precisa affinché qualsiasi sviluppatore potesse costruirci sopra senza chiamare nessuno.
SAP fece lo stesso con i processi aziendali. Il suo dominio nell'ERP non derivò dall'avere interfacce migliori rispetto ai consulenti dell'epoca. Derivò dall'aver formalizzato l'azienda come oggetto tecnico: dati anagrafici, transazioni, logica contabile, inventario, approvvigionamento, relazioni operative. Quella formalizzazione rese le implementazioni sufficientemente ripetibili da consentire l'esistenza di modelli preconfigurati, partner certificati, estensioni e un mercato secondario robusto. La varianza tra un cliente e l'altro si ridusse abbastanza da permettere che la conoscenza accumulata in un'implementazione trasferisse valore alla successiva.
Ciò che accomuna questi tre casi è che il salto dalla capacità alla piattaforma non avvenne perché la tecnologia migliorò. Avvenne perché qualcuno definì con precisione cosa rappresentava la tecnologia e secondo quali regole operava. In tutti e tre i casi, ci fu un momento di formalizzazione che precedette il momento della scala.
L'IA aziendale non ha ancora attraversato quel momento. Ha la capacità. Le manca la grammatica.
Ciò che McKinsey conferma e la maggior parte dei team ignora
Le cifre del MIT sul fallimento non sono l'unica evidenza disponibile. La ricerca di McKinsey sullo stato dell'IA, citata nell'articolo di Dans, giunge a una conclusione che dovrebbe mettere a disagio i team che misurano il proprio progresso in termini di numero di piloti avviati: le aziende che ottengono benefici materiali dall'IA non sono quelle che usano più IA. Sono quelle che hanno ridisegnato i propri flussi di lavoro.
Quella distinzione non è semantica. Utilizzare l'IA su un processo esistente produce guadagni marginali nel migliore dei casi. Ridisegnare il processo attorno a una rappresentazione formale del lavoro produce qualcosa di diverso: un sistema in cui l'intelligenza artificiale non è un accessorio ma una condizione di funzionamento del processo stesso.
Michael Hammer scrisse su Harvard Business Review che le aziende commettono un errore prevedibile quando adottano nuove tecnologie: accelerano i processi esistenti invece di sostituirli. Dans riprende quell'argomento per il momento attuale. La versione contemporanea dell'errore di Hammer consiste nel prendere un flusso di approvazioni progettato per esseri umani che leggono documenti cartacei, aggiungere un modello linguistico che riassume i documenti, e chiamare tutto ciò trasformazione. Il processo ha la stessa struttura causale. Ha semplicemente un componente più rapido in un passaggio intermedio.
Il ridisegno che McKinsey individua nelle aziende con un ritorno misurabile ha una caratteristica strutturale: esiste uno strato che definisce cos'è un'entità nel business, quali stati può avere, quali transizioni sono valide, quali permessi sono richiesti per ogni azione e quali regole non possono essere violate indipendentemente dall'istruzione ricevuta dal sistema. Non si tratta di un prompt elaborato. È quella che Dans chiama la capa formale che l'industria non ha ancora costruito in modo standardizzato.
La differenza tra avere quello strato e non averlo è verificabile. Senza di esso, il sistema può dare una risposta diversa alla stessa domanda a seconda della cronologia della sessione, dell'utente che interroga o di come è stata formulata l'istruzione precedente. Con esso, esistono invarianti: il contratto con il cliente non può essere modificato senza l'autorizzazione del responsabile regionale, indipendentemente da ciò che l'agente ha "compreso" dall'email che ha letto. Quella garanzia non deriva dal modello linguistico. Deriva dall'architettura che lo contiene.
Per i settori regolamentati, questa distinzione non è una preferenza tecnica. Nei servizi finanziari, nella sanità o nel settore pubblico, l'assenza di invarianti verificabili non è un disagio operativo. È un blocco al dispiegamento su scala, perché nessun team legale firmerà la responsabilità su un sistema che non può garantire coerenza nelle proprie decisioni.
La prossima battaglia non è tra modelli, è tra astrazioni
L'analisi di Dans si conclude con una proiezione che vale la pena prendere sul serio come segnale strategico: il vantaggio competitivo nella prossima fase dell'IA aziendale non lo guadagneranno i fornitori con i modelli più potenti. Lo guadagneranno coloro che definiranno l'astrazione formale sulla quale il resto costruisce.
Ciò apre una domanda con conseguenze concrete di mercato, anche se la risposta non è ancora chiara. I candidati naturali per definire quella astrazione sono diversi e con incentivi differenti. I grandi fornitori cloud, Microsoft, Google e Amazon, hanno la distribuzione e le relazioni aziendali, ma hanno anche l'incentivo a mantenere il modello di consulenza intensiva che genera ricavi da servizi professionali. I laboratori di modelli come OpenAI e Anthropic hanno la profondità tecnica, ma hanno costruito i propri affari attorno alla capacità dei modelli, non attorno alla formalizzazione dei processi che li circondano. Le aziende di software aziendale consolidate, SAP, Salesforce, Oracle, operano già su strati formali di dati e processi, ma la loro velocità di adattamento a nuove architetture è stata storicamente lenta.
Lo spazio più interessante potrebbe appartenere a un tipo di attore che non ha ancora un nome chiaro nel mercato: uno specialista in infrastruttura di conoscenza e flusso di lavoro la cui proposta di valore non sia il modello linguistico bensì lo strato che lo rende operabile all'interno di un'azienda senza richiedere una traduzione manuale in ogni implementazione. Qualcosa di analogo a ciò che fu il middleware negli anni Novanta, ma con la capacità di ragionare sulle regole che contiene.
Il segnale che quell'attore sta vincendo non sarà un annuncio di prodotto. Sarà il momento in cui due aziende di settori diversi potranno condividere un'implementazione senza che nessuna delle due debba chiamare un consulente per spiegare cosa significa "approvato" nella propria organizzazione. Quando la grammatica sarà sufficientemente precisa affinché ciò accada, la fase artigianale dell'IA aziendale sarà terminata. Fino ad allora, il 95 per cento di fallimento non è un incidente statistico. È il prezzo di costruire su analogie invece che su definizioni.
