I modelli AI non sono mai stati così potenti. Eppure, secondo McKinsey quasi due terzi delle organizzazioni che li hanno adottati non sono riuscite a portare l’AI oltre la fase pilota. Il paradosso è architetturale.
Indice degli argomenti
AI in azienda: perché la potenza dei modelli non basta
Avere la macchina da corsa più veloce del mondo non serve a nulla senza benzina, senza pista e senza un pilota che sappia guidarla senza finire contro il muro. E di ostacoli, nel contesto enterprise, ce ne sono parecchi: la complessità dei sistemi esistenti, la sensibilità dei dati proprietari, la rigidità dei flussi di lavoro interni.
Il McKinsey Global Survey State of AI 2025, condotto su quasi 2.000 organizzazioni in 105 paesi, rileva che l’88% delle aziende usa AI in almeno una funzione, ma solo un terzo ha iniziato a scalare davvero la tecnologia all’interno dell’azienda. La maggioranza è bloccata in quello che gli analisti chiamano “pilot purgatory“: sperimentazioni isolate che non escono mai dai confini del progetto prova. Il report MIT NANDA The GenAI Divide, basato sull’analisi di 300 deployment pubblici, stima che il 95% dei pilot enterprise non producano impatto misurabile sul conto economico. Il problema non è nella qualità dei modelli, bensì nel modo in cui gli stessi sono innestati all’interno delle aziende: senza un’architettura dedicata, non riescono a valorizzare le unicità del contesto in cui vengono applicati.
Il patrimonio informativo aziendale e i rischi dell’integrazione diretta
Un’azienda con anni di storia porta con sé qualcosa che nessun modello ha: dati proprietari, IP consolidato, conoscenza profonda del proprio settore e un tech stack operativo già in funzione. Questo è il patrimonio che la mera adozione di un LLM non riesce a sfruttare a pieno. Connettere un modello ai propri sistemi senza un’architettura dedicata significa esporre dati sensibili, perdere controllo sui workflow interni e accumulare costi token difficili da prevedere. Significa, soprattutto, cedere all’esterno la parte più preziosa di quello che l’azienda sa fare. A questo si aggiunge l’esposizione crescente ai rischi di compliance: AI Act e GDPR sono vincoli strutturali che un’integrazione diretta e non governata non è in grado di rispettare.
La corsa dei big tech verso il forward deployment
Il mercato ha già identificato il problema. A maggio 2026, OpenAI ha lanciato la OpenAI Deployment Company — una raccolta da oltre 4 miliardi di dollari da 19 investitori tra cui TPG, Bain Capital e McKinsey — acquisendo contestualmente Tomoro, società britannica di consulenza AI con 150 ingegneri specializzati nell’adozione dell’AI nelle aziende. Quasi contestualmente, Anthropic ha annunciato una joint venture con Blackstone, Goldman Sachs e Hellman & Friedman per portare Claude nelle attività core delle aziende mid-market, con circa 1,5 miliardi di dollari impegnati.
Il modello Palantir applicato all’AI
Il modello operativo di entrambe le iniziative si ispira esplicitamente a Palantir: ingegneri “forward deployed” che entrano fisicamente nelle organizzazioni clienti per costruire l’integrazione dall’interno.
La diagnosi è corretta; la terapia proposta, però, risponde a interessi diversi da quelli dell’impresa cliente. Il contesto finanziario è rilevante per capire il movente: per ogni euro generato sul software, il mercato ne produce storicamente sei in servizi di implementazione e consulenza. È uno spazio che i lab stanno cercando di occupare, non per vocazione, ma per necessità di revenue in una fase in cui le valutazioni richiedono dimostrazione di adozione reale.
I limiti del forward deployment vendor-specific
Il forward deployment vendor-specific porta con sé un limite strutturale che gli analisti di Gartner hanno già segnalato: il vendor del modello non ha visibilità sull’architettura complessiva dell’impresa cliente. Un’organizzazione enterprise non vive in un ecosistema mono-vendor.
Convive con SAP, Salesforce, strumenti verticali di settore, basi dati eterogenee costruite in decenni di stratificazioni tecnologiche. Chi arriva a implementare un singolo modello conosce il proprio prodotto, non l’architettura che deve integrare. Il rischio concreto è costruire un’isola di AI efficiente che non dialoga con il resto, o peggio, che ci dialoga male. Si consideri un caso tipico nel manifatturiero: un modello di demand forecasting addestrato su dati storici aggregati produce previsioni tecnicamente accurate, ma non vede i vincoli di capacità produttiva in tempo reale, i fermi macchina, i lotti in lavorazione nel MES.
Il risultato è un forecast brillante sulla carta e inutilizzabile nelle decisioni operative. A questo limite tecnico si aggiunge un doppio conflitto di interessi: il vendor del modello ha incentivo a massimizzare il consumo del proprio prodotto; il fondo di private equity co-investitore ha incentivo a promuovere l’adozione di quel modello specifico nei propri portfolio company, indipendentemente dalla qualità della soluzione rispetto alle alternative di mercato.
L’architettura di orchestrazione come alternativa
La risposta è costruire una logica di orchestrazione che governi l’utilizzo dei modelli nell’interesse dell’impresa.
Un’architettura di questo tipo tiene i dati di contesto interrogabili su infrastruttura locale o cloud privato, chiama i modelli solo quando il compito lo richiede davvero, integra i sistemi software già in uso e disegna workflow AI-native che rispettano le regole di sicurezza e compliance dell’organizzazione. In questo schema, il modello linguistico diventa uno strumento intercambiabile: il vantaggio competitivo non sta nel modello scelto oggi, ma nell’architettura che l’azienda controlla e che può aggiornare o sostituire senza perdere ciò che ha costruito. Il punto che spesso viene perso è che questa architettura non è solo difensiva. È il luogo dove il vantaggio competitivo dell’azienda — i suoi dati, il suo IP, la sua conoscenza settoriale — diventa azionabile dall’AI.
Non si cede valore verso l’esterno, ma si moltiplica il valore che esiste già all’interno. Costruire questa architettura non è solo una scelta tecnica, ma soprattutto una decisione su chi detiene la sovranità su processi e dati che rendono l’azienda unica.
Chi può costruire il layer di orchestrazione
Chi costruisce questo layer? Non il vendor del modello, per le ragioni già descritte. Non il system integrator tradizionale, che conosce l’architettura enterprise ma non ha ancora maturato sufficiente competenza in ambito AI per progettare orchestrazione complessa.
Lo spazio è occupato da una categoria emergente di player: aziende con competenza AI nativa, capacità di integrazione multisistema e approccio vendor-agnostic, che non vendono un modello ma un’architettura per far funzionare l’AI. Il loro vantaggio competitivo non è tecnologico in senso stretto, sta piuttosto nella capacità di leggere l’architettura esistente del cliente, identificare dove l’AI produce valore reale e costruire un layer che connette senza esporre a rischi. È una figura che non esisteva cinque anni fa e che il mercato sta iniziando a riconoscere come distinta sia dai grandi player AI, sia dalle grandi società di consulenza tradizionale.
Le soluzioni pre-packaged per le piccole organizzazioni
Per le organizzazioni di minori dimensioni, il layer di orchestrazione custom rimane fuori portata per complessità e costo. Il mercato sta rispondendo con soluzioni pre-packaged — come Claude for Work di Anthropic, che arriva con integrazioni native su Google Workspace, Microsoft 365 e i principali strumenti SaaS — abbassando la barriera di adozione al prezzo di una minore personalizzazione. In questo schema, il modello linguistico è uno strumento fungibile: QuickBooks o HubSpot possono sostituire Claude con GPT o Gemini se il prezzo o le performance cambiano. Il vantaggio competitivo non appartiene al modello, ma a chi possiede la relazione con il cliente e i dati di settore accumulati in anni di utilizzo.
È un trade-off accettabile per chi non ha patrimonio informativo da proteggere a quel livello di granularità; per le grandi organizzazioni, affidarsi a soluzioni precostruite dal vendor equivale a esternalizzare la parte più strategica della propria trasformazione digitale. Il movimento dei grandi operatori verso il forward deployment è la conferma che il mercato dell’adozione AI sta ancora cercando di stabilizzarsi.
Non l’ha ancora trovata. I grandi operatori portano il modello ma non la neutralità. I consulenti tradizionali portano la conoscenza dell’architettura ma non la competenza AI. Nel mezzo si sta aprendo uno spazio preciso, per chi sa fare entrambe le cose nell’interesse del cliente. Le aziende che lo occuperanno per prime avranno un vantaggio difficile da erodere, non perché utilizzano la migliore tecnologia, ma perché portano al cliente una soluzione adottabile senza compromessi sulla sovranità del proprio patrimonio di conoscenza.
Partecipa alla community