Abbiamo speso 35 miliardi di dollari in AI e non abbiamo ottenuto quasi nulla in cambio

La telefonata è arrivata un martedì sera. Un'azienda sanitaria di medie dimensioni — che seguivamo come consulenti — aveva appena cancellato il suo progetto AI di punta. Nove mesi di lavoro. Una spesa a sei cifre. Il CTO sembrava esausto, non arrabbiato. "Nella demo funzionava alla perfezione", mi ha detto. "Ogni singola volta. Poi l'abbiamo collegato ai dati reali dei pazienti e ha iniziato ad allucinare codici assicurativi."

Non sapevo cosa dire, perché avevo sentito una qualche versione di questa storia una dozzina di volte solo in quel trimestre. AI che abbaglia in una sala riunioni e si disintegra in produzione. Progetti pilota che generano entusiasmo al primo mese e revisioni di budget al sesto. Il divario tra ciò che l'AI generativa promette e ciò che mantiene all'interno di un'azienda reale è la tensione che definisce questo momento della tecnologia.

E ora abbiamo i numeri per dimostrarlo. L'iniziativa MIT NANDA ha pubblicato a metà del 2025 uno studio che è caduto come una granata: dei circa 30-40 miliardi di dollari che le aziende hanno riversato nell'AI generativa, all'incirca il 95% dei progetti pilota non è riuscito a produrre un impatto misurabile sul conto economico. Anche il sondaggio 2025 di McKinsey fa eco: l'88% delle organizzazioni dichiara di usare l'AI da qualche parte, ma solo il 39% riesce a indicare un qualsiasi impatto sull'EBIT.

Guido Veriprajna, dove costruiamo sistemi di deep AI per le aziende. Non sono un osservatore neutrale, qui. Ma sono stato abbastanza vicino ai disastri — e ai rari successi — da avere un quadro chiaro di ciò che sta davvero andando storto. E non è quello che pensa la maggior parte delle persone.

La demo sembrava fantastica. Poi è arrivata la realtà.

L'esperienza di quel CTO del settore sanitario non era insolita. Era praticamente il risultato mediano.

I dati del MIT tracciano un imbuto brutale: l'80% delle organizzazioni esplora strumenti di AI generativa. Solo il 20% arriva a un progetto pilota. E appena il 5% raggiunge la produzione con risultati di business misurabili. I ricercatori lo chiamano un "divario di apprendimento", che è un modo educato per dire che la maggior parte delle aziende non capisce che cosa ha comprato.

Ricordo che ero seduto nel nostro ufficio dopo aver letto il rapporto completo del MIT, a discutere con il mio co-fondatore se il dato del 95% fosse troppo drammatico. Non lo era. Semmai, sottostimava il problema, perché molti di quel 5% "di successo" avevano ridefinito il successo al ribasso: avevano misurato i tassi di adozione o la soddisfazione degli utenti invece dell'impatto reale sui ricavi.

Lo schema che continuo a vedere è questo: un team costruisce un proof of concept usando un LLM di primo piano. Gestisce alla perfezione le dieci query di esempio. Il management si entusiasma. Il budget viene approvato. Poi il sistema incontra il mondo reale — dati disordinati, casi limite, input ambigui, requisiti normativi in cui "abbastanza vicino" significa una causa legale — e crolla.

Il divario tra un'AI pronta per la demo e un'AI pronta per la produzione non è un divario. È un canyon, e la maggior parte delle aziende non si accorge di trovarsi dalla parte sbagliata finché non ha già saltato.

Il 60% degli utenti nello studio del MIT ha riferito che i modelli non riuscivano a imparare dal feedback nel tempo. Il 55% ha detto di aver dedicato uno sforzo eccessivo a fornire il contesto per ogni singolo prompt. Il 40% ha detto che i modelli semplicemente "si rompevano" quando incontravano input non standard. Non sono modalità di fallimento esotiche. Sono un martedì qualunque.

Perché le aziende costruiscono sulle sabbie mobili?

Gran parte di ciò che il mercato enterprise chiama oggi "prodotti AI" sono wrapper: interfacce utente minimali costruite sopra una chiamata API a GPT-4, Claude o Gemini. Scrivi qualcosa, il testo va al modello, il modello risponde e il wrapper lo formatta in modo gradevole.

Ho un ricordo viscerale di una riunione di presentazione in cui un potenziale cliente mi ha mostrato il suo "motore di compliance basato sull'AI". Ho chiesto che cosa sarebbe successo se il comportamento del modello sottostante fosse cambiato dopo un aggiornamento del fornitore. Nella stanza è calato il silenzio. Non ci avevano pensato. L'intero prodotto era un template di prompt e una bella dashboard. L'"intelligenza" che stavano vendendo era interamente in affitto.

Questa è la fallacia del wrapper, ed è ovunque. L'approccio si basa tipicamente su quello che nel settore chiamano "mega-prompt": stipi regole, dati, contesto e istruzioni in un'unica interazione enorme e speri che il modello ci si raccapezzi. Ho approfondito questo problema architetturale nella versione interattiva della nostra ricerca, ma in sintesi i mega-prompt creano tre problemi fatali:

Non puoi sottoporli ad audit. Non c'è modo di verificare che il modello abbia seguito le istruzioni nell'ordine corretto. Per i settori a forte carico di compliance, è improponibile.

Sono economicamente fragili. Le finestre di contesto lunghe e i tentativi ripetuti bruciano token. Ed ecco un numero che mi ha scioccato la prima volta che l'ho visto: la differenza tra un tokenizer efficiente e uno inefficiente può significare una variazione di costo del 450% per lo stesso carico di lavoro. Un'azienda che gestisce 100.000 richieste dei clienti al giorno potrebbe vedere i costi annui salire da 36.500 a oltre 164.000 dollari solo scegliendo il modello sbagliato per un caso d'uso multilingue.

Sono instabili. Cambia tre parole in un prompt e ottieni un output completamente diverso. Prova a costruirci sopra un SLA.

La trappola economica è persino peggiore di quella tecnica. Quando OpenAI o Anthropic abbassano i prezzi delle loro API — e continueranno ad abbassarli — le aziende-wrapper vedono evaporare i propri margini. Non possiedono i dati. Non possiedono il workflow. Stanno rivendendo l'intelligenza di qualcun altro con un ricarico e, nel momento in cui il padrone di casa taglia l'affitto per tutti, il subaffittuario non ha un business.

Che cosa significa davvero "deep AI"?

Ti racconto il momento in cui il concetto mi si è chiarito.

Stavamo lavorando a un sistema di elaborazione documentale per un cliente della logistica. L'approccio iniziale era lineare: inviare il documento di spedizione a un LLM, chiedergli di estrarre i campi rilevanti, restituire i risultati. Funzionava sui moduli standard. Poi ci siamo imbattuti in un manifesto di carico container proveniente da un porto del Sud-est asiatico, con annotazioni in più lingue, correzioni scritte a mano e un formato che non corrispondeva a nulla presente nei dati di addestramento. Il modello ha restituito spazzatura, con grande sicurezza.

Il mio lead engineer, frustrato dopo una settimana di prompt engineering che continuava a produrre nuove modalità di fallimento, alla fine ha detto: "Stiamo chiedendo a un solo cervello di fare sette lavori. E se affidassimo ogni lavoro a uno specialista?"

Ecco il deep AI in una frase. Invece di trattare l'LLM come un oracolo che gestisce tutto, lo tratti come un componente all'interno di un sistema più ampio. Scomponi il problema. Un agente si occupa della comprensione della query. Un altro recupera i dati da un database strutturato. Un terzo valida l'output rispetto a regole note. Un quarto formatta la risposta. Ogni agente ha una responsabilità definita e il workflow tra loro è deterministico: sei tu a controllare la sequenza, la logica e i punti di controllo.

Il deep AI tratta il modello linguistico come uno stagista di talento, non come un CEO. Gli affidi compiti specifici all'interno di una struttura governata, non le chiavi dell'edificio.

I pattern di design agentici che rendono possibile tutto questo non sono teorici. Vengono messi in produzione oggi:

Un pattern di riflessione in cui l'agente critica il proprio output prima di inviarlo all'utente. Un pattern di uso degli strumenti in cui l'agente richiama calcolatori esterni, API o database invece di provare a calcolare le risposte a memoria. Un pattern di pianificazione che scompone obiettivi complessi in passi sequenziali. E un pattern di orchestrazione in cui un agente supervisore gestisce l'intero workflow, instradando i compiti allo specialista giusto.

Quando abbiamo ricostruito quel sistema logistico usando l'orchestrazione multi-agente, l'accuratezza di estrazione sui documenti non standard è passata da circa il 60% a oltre il 95%. Ma soprattutto, quando effettivamente falliva, potevamo vedere esattamente dove e perché — dato che il sistema non era più una scatola nera. Era una pipeline con passaggi osservabili e auditabili.

Perché il costo dei token uccide il ROI dell'AI enterprise?

Questa è la parte a cui non si presta abbastanza attenzione.

Tutti parlano dell'accuratezza dei modelli. Quasi nessuno parla della unit economics di far girare questi sistemi su larga scala. Ma ho visto i costi dei token assassinare in silenzio il business case di progetti AI che per il resto funzionavano alla perfezione.

La matematica è semplice ma brutale. Modelli diversi tokenizzano il testo in modo diverso, soprattutto il testo non inglese e le scritture complesse. Una query che costa 800 token su un modello potrebbe costarne 4.500 su un altro. Moltiplicalo per centinaia di migliaia di interazioni quotidiane e ti ritrovi con una differenza di costo che annulla qualunque guadagno di efficienza che l'AI avrebbe dovuto portare.

Ho avuto un momento di autentico allarme quando abbiamo eseguito l'analisi di tokenizzazione per un cliente che opera in tamil e in inglese. Il differenziale di costo tra il loro modello attuale e un'alternativa più efficiente era di 4,5x. Perdevano soldi a ogni singola interazione e attribuivano tutto ai "costi di infrastruttura" nel loro budget. A nessuno era venuto in mente di guardare il tokenizer.

I sistemi di deep AI affrontano il problema scegliendo in modo chirurgico quando usare i costosi token degli LLM. I compiti ad alto volume e bassa complessità vengono gestiti da modelli più piccoli o da logica deterministica. La costosa capacità di ragionamento viene riservata ai passaggi in cui conta davvero. È la differenza tra assumere un consulente senior perché risponda a ogni telefonata e farlo concentrare invece sulle decisioni che richiedono giudizio.

La regola 10-20-70 che nessuno segue

Quando parlo con i dirigenti del perché i loro progetti AI si sono arenati, indicano quasi sempre la tecnologia. Il modello non era abbastanza buono. I dati non erano puliti. L'integrazione era troppo complessa.

Non hanno torto su nulla di tutto ciò. Ma si perdono il rapporto che conta davvero. Le aziende che stanno davvero vedendo un impatto sull'EBIT — e McKinsey dice che solo il 6% ottiene dall'AI più del 5% dell'EBIT totale — seguono un'allocazione delle risorse che sorprenderebbe la maggior parte dei tecnologi:

Il 10% dello sforzo va alla scelta e all'ottimizzazione degli algoritmi. Il 20% va alla costruzione dell'infrastruttura di dati e tecnologica. Il 70% va alla gestione delle persone, dei processi e della trasformazione culturale.

Settanta per cento. Non sulla tecnologia. Sul convincere le persone a cambiare il modo in cui lavorano.

Ho resistito a questa idea più a lungo di quanto avrei dovuto. Sono un ingegnere per istinto. Volevo credere che, se avessimo costruito un sistema migliore, l'adozione sarebbe arrivata da sé. C'è voluto un progetto doloroso — uno in cui abbiamo consegnato una soluzione tecnicamente eccellente che è rimasta inutilizzata per tre mesi perché nessuno aveva riprogettato il workflow attorno a essa — per interiorizzare che la tecnologia è la parte facile.

Le aziende di medie dimensioni che seguono il principio 10-20-70 migliorano il proprio EBITDA di 160-280 punti base entro 24 mesi. Quelle che spendono il 70% in tecnologia e il 10% in change management si ritrovano con software costoso che resta sullo scaffale.

Le vittorie non sono appariscenti. Gestione del ciclo dei ricavi. Automazione dell'imputazione degli incassi. Ottimizzazione dei costi cloud. Nessuno scrive post entusiasti su LinkedIn sulla riduzione degli arretrati di pratiche di pazienti dimessi ma non ancora fatturate. Ma Inova Health System ha ridotto quell'arretrato del 50% e ha risparmiato 1,3 milioni di dollari all'anno. Gli assistenti virtuali AI di OSF HealthCare hanno risparmiato 1,2 milioni di dollari mentre aumentavano i ricavi di altri 1,2 milioni di dollari. UPS risparmia 400 milioni di dollari all'anno grazie all'instradamento basato sull'AI.

Non sono risultati di progetti pilota. Sono sistemi in produzione che girano su larga scala, costruiti con quel tipo di integrazione profonda che i wrapper non possono nemmeno sfiorare.

Che cosa succede quando gli agenti AI iniziano ad agire da soli?

Il passaggio da un'AI che risponde alle domande a un'AI che compie azioni cambia completamente il calcolo della sicurezza.

Ci penso molto, anche per via di un incidente sfiorato durante i test. Stavamo costruendo un sistema agentico che doveva accedere all'ERP di un cliente per estrarre i dati di magazzino. Durante un'esecuzione di prova, l'agente — seguendo una catena di ragionamento tecnicamente logica ma contestualmente sbagliata — ha tentato di modificare un ordine di acquisto invece di limitarsi a leggerlo. Avevamo delle protezioni attive. Il tentativo non è andato a buon fine. Ma dopo sono rimasto seduto alla scrivania a pensare a che cosa sarebbe successo se fossimo stati meno attenti.

È per questo che standard come il Model Context Protocol (MCP) e il framework NANDA contano così tanto. MCP — sviluppato da Anthropic — funziona come uno strato di integrazione standardizzato tra gli agenti AI e le fonti di dati aziendali. Lo chiamano l'"USB-C dell'AI", ed è appropriato: significa che non servono integrazioni personalizzate e fragili per ogni connessione. NANDA fornisce lo strato di governance: attestazione delle capacità verificabile crittograficamente (cioè puoi dimostrare che cosa un agente è e non è autorizzato a fare), controlli di accesso zero-trust estesi agli agenti autonomi e audit trail centralizzati.

Per l'analisi tecnica completa di questi pattern architetturali e di come si incastrano tra loro, vedi il nostro paper di ricerca.

Il punto non è che l'AI agentica sia pericolosa e che dovremmo rallentare. Il punto è che l'approccio wrapper — in cui hai una visibilità minima su che cosa sta facendo il modello e perché — diventa davvero avventato quando il modello può compiere azioni nel mondo reale. I sistemi di deep AI con workflow osservabili e governati non sono solo ingegneria migliore. Sono l'unico modo responsabile di mettere in produzione agenti autonomi in un'azienda.

"Usa GPT e basta" e altri consigli costosi

Mi chiedono di continuo se non convenga semplicemente aspettare che i modelli migliorino. "GPT-5 risolverà questo problema", ho sentito dire da un investitore a cena. "Perché costruire tutta questa infrastruttura, quando la prossima versione del modello la gestirà nativamente?"

Capisco il fascino di questo argomento. È pulito. Non richiede lavoro duro. Ed è sbagliato.

I modelli migliori non risolvono il problema del wrapper. Lo peggiorano. Un modello più potente in un'architettura a mega-prompt è come mettere un motore di Formula 1 in un'auto senza volante. Vai più veloce nella direzione sbagliata. I problemi che uccidono l'AI enterprise — mancanza di auditabilità, prompt instabili, assenza di cicli di feedback, contesto di business mancante, costi fuori controllo — sono problemi architetturali, non problemi di capacità.

L'economia della shadow AI lo dimostra. Oltre il 90% dei dipendenti usa già di nascosto account personali di ChatGPT o Claude per lavoro, perché gli strumenti AI ufficiali della loro azienda sono troppo rigidi. I modelli sono abbastanza capaci. I sistemi che li circondano non lo sono.

I modelli migliori non salvano una cattiva architettura. Si limitano ad allucinare più in fretta e con più sicurezza.

L'altra domanda che ricevo riguarda i tempi. "Quanto ci vuole davvero?" La risposta onesta è dai 12 ai 18 mesi per passare da esperimenti sparsi a un'AI che muove il conto economico. I primi tre mesi sono di discovery: individuare dove l'AI può creare valore senza creare esposizione normativa. Dal terzo al sesto mese si lavora sulla data readiness, ed è lì che il 58% dei CXO dice di bloccarsi. Dal sesto al dodicesimo mese si costruiscono e si iterano prototipi multi-agente — e intendo 30+ cicli di iterazione contro dati del mondo reale, non tre demo lucidate. La fase finale è il rilascio in produzione con pieno supporto operativo: rilevamento del drift, monitoraggio dei bias, governance dei costi.

Non è veloce. Non è facile. Ma le aziende che lo fanno sono quelle che compaiono nel 6% di McKinsey con un impatto reale sull'EBIT.

Il divario è una scelta

Il "GenAI Divide" individuato dal MIT non è un divario tecnologico. È un divario decisionale.

Da un lato: aziende che hanno trattato l'AI generativa come un prodotto da comprare, un wrapper da installare, una demo da mostrare al consiglio di amministrazione. Sono il 95%. Hanno speso soldi veri e hanno ottenuto comunicati stampa.

Dall'altro lato: aziende che hanno trattato l'AI come una sfida architetturale — una sfida che richiede di scomporre i problemi, governare i workflow, riprogettare i processi e fare il lavoro poco appariscente di collegare i modelli alla realtà disordinata dei dati aziendali. Sono il 5%. Hanno speso cifre simili e hanno ottenuto un impatto sull'EBIT.

Ogni tanto ripenso a quel CTO del settore sanitario. Quello che mi ha chiamato un martedì, esausto, dopo aver appena cancellato il suo progetto AI. Mi ha richiamato quattro mesi dopo. Il suo team aveva ricostruito il sistema con un approccio multi-agente: agenti separati per l'estrazione dei dati, la validazione dei codici e il controllo di compliance, con passaggi di consegne deterministici tra loro. Non era elegante come la demo originale. È stato più lento da costruire. Ha richiesto più riflessione a monte sulla progettazione del workflow e sulle modalità di fallimento.

Funzionava. Non alla perfezione — nulla lo fa — ma in modo abbastanza affidabile da poter essere rilasciato, sottoposto ad audit e migliorato. Abbastanza affidabile da comparire su un conto economico.

L'era in cui l'AI veniva trattata come un trucco di magia è finita. Quello che viene dopo è più difficile, più lento e meno fotogenico. È anche l'unica cosa che funziona davvero.