Il ritorno dell'IA aziendale è un problema di architettura, non di intelligenza
C'è una cifra che i CIO stanno memorizzando con crescente disagio: il 72% delle organizzazioni ammette che i propri investimenti in IA si trovano, nella migliore delle ipotesi, al punto di pareggio. Nel peggiore, stanno perdendo denaro. Gartner ha pubblicato quel numero e non ha generato panico, ma qualcosa di più persistente: una silenziosa incertezza su quanto a lungo si possa sostenere una scommessa senza dimostrare che funziona.
La risposta abituale punta ai modelli. Bisogna scegliere meglio il fornitore, affinare i prompt, aspettare che i prezzi dell'inferenza scendano. Quella risposta è comoda e quasi sempre sbagliata. Ciò che sta fallendo non è l'intelligenza della macchina. Ciò che sta fallendo è l'architettura aziendale che la circonda.
Il problema ha una meccanica molto concreta: ogni volta che un'azienda lancia un nuovo agente di IA, quell'agente riparte da zero. Riconnette dati, ricostruisce il contesto aziendale, rinegozia i permessi, riprogetta i controlli, stabilisce i propri criteri di validazione. Se ci sono sei agenti in produzione, esistono sei versioni parallele e indipendenti di quella infrastruttura. Ognuna con il proprio costo, il proprio debito tecnico, la propria opacità. Il risultato non è intelligenza artificiale su scala. È burocrazia digitale su scala.
Perché il costo reale dell'IA non appare nella voce di inferenza
La trappola contabile è sofisticata. Quando un team valuta se un progetto di IA ha senso economico, di norma guarda al costo del modello: quanto costa chiamare l'API, quanti token consuma ogni query, quale fornitore offre il miglior prezzo per capacità. Quell'analisi non è sbagliata, ma cattura appena una frazione del costo totale.
Ciò che non appare in quella voce è il costo dell'integrazione ripetuta. Ogni agente che viene distribuito senza uno strato condiviso di contesto aziendale richiede che qualcuno costruisca da zero le connessioni con i sistemi di registrazione dell'azienda, i meccanismi di autorizzazione, le regole di business, la logica di escalation. Non è un costo di modello. È un costo di ingegneria, di governance, di operazioni. E si ripete integralmente ad ogni nuovo caso d'uso.
Un team di servizi finanziari studiato da ricercatori dell'Università di Hong Kong e di Stellaris AI ha scoperto che più del 70% delle proprie query era abbastanza routinario da poter essere risolto con modelli più piccoli e meno costosi. Eppure tutto girava sulla stessa infrastruttura ad alto costo perché nessuno aveva progettato un meccanismo per discriminare in base alla complessità. La spesa di inferenza superava i 200.000 dollari mensili non perché il business fosse sofisticato, ma perché l'architettura non aveva memoria di quando esserlo.
Il problema della distribuzione dei costi ha un altro lato meno visibile: quando i costi sono dispersi tra integrazioni, team e strumenti, attribuire il valore generato diventa matematicamente impossibile. Non è che il ROI sia basso. È che non esiste modo di misurarlo perché non c'è un registro unificato di quali dati ha utilizzato ogni agente, quali decisioni ha preso, quanto è costato ogni passaggio e quale risultato ha prodotto. La frammentazione non solo rende più costosa la distribuzione. Distrugge la tracciabilità che renderebbe possibile giustificare l'investimento.
Cosa cambia uno strato condiviso nell'economia della distribuzione
La soluzione che comincia ad articolarsi tra gli architetti di sistemi aziendali non è assumere meno IA né modelli migliori. È costruire uno strato di contesto condiviso che funzioni come colonna vertebrale di tutti gli agenti e i flussi di lavoro dell'organizzazione.
L'idea ha una logica economica precisa. Se la conoscenza aziendale, i permessi, le regole di business e la logica di governance vengono costruiti una volta sola ed esposti come infrastruttura riutilizzabile, il costo marginale di distribuire il secondo, il quinto e il decimo caso d'uso cala in modo significativo. Non perché i modelli siano più economici, ma perché l'azienda non paga più il costo di riconnettere il proprio business ogni volta che aggiunge una nuova applicazione.
Un'azienda multinazionale del settore cosmetico ha attraversato questa esperienza. I suoi primi agenti funzionavano bene nelle demo, ma collassavano in produzione perché ciascuna delle sei soluzioni integrate manteneva il proprio repository di conoscenza e le proprie regole di governance in silos indipendenti. Ogni agente partiva a freddo. Ogni nuovo progetto richiedeva di riconnettere tutto da zero. Il costo non era il modello. Era la ripetizione.
La centralizzazione del contesto cambia anche la logica del routing. Quando l'infrastruttura sa che tipo di attività sta elaborando, può indirizzarla al modello appropriato: uno più potente e costoso per il ragionamento complesso, uno più piccolo e veloce per le query routinarie. La spesa di inferenza smette di essere un costo fisso e diventa una variabile che risponde alla complessità del lavoro. Non è un'ottimizzazione marginale. È una riconfigurazione del modello di costi.
In modo complementare, l'architettura a sciame di agenti specializzati produce risultati simili dal lato dell'efficienza computazionale. Invece di un superagente che deve elaborare il contesto completo di un problema a ogni passo, più agenti con domini circoscritti operano in parallelo. Ognuno lavora con una finestra di contesto più piccola, più precisa, meno costosa. Il coordinamento tra agenti richiede una governance condivisa per funzionare senza creare nuovi rischi operativi, ma quando quella governance esiste, il risparmio in token per attività può essere considerevole.
La governance non è il freno. È la condizione di scala.
McKinsey ha documentato qualcosa che molti team tecnologici hanno imparato a proprie spese: incorporare la governance dopo che l'IA è già in produzione genera costi di reingegnerizzazione che possono superare il valore che il sistema stava generando. Gartner stima che le tecnologie di governance ben integrate possano ridurre le spese regolamentari fino al 20%. Non sono numeri di compliance. Sono numeri di architettura.
Il problema della governance come strato aggiunto alla fine è lo stesso del contesto come lavoro ripetuto: viene ricostruita integralmente per ogni applicazione. Un flusso di lavoro per i sinistri assicurativi ha bisogno di accesso controllato ai dati degli assicurati, tracciabilità delle decisioni, limiti all'autonomia dell'agente e regole di escalation verso la revisione umana. Se tutto questo viene progettato solo per quel flusso, bisogna riprogettarlo per il successivo. Dieci agenti indipendenti significano dieci versioni della stessa architettura di controllo, dieci volte il costo di approvazione, dieci volte il rischio di inconsistenza.
Quando la governance viene costruita come piattaforma, i controlli vengono definiti una volta come codice e applicati trasversalmente. Il costo non scala linearmente con il numero di agenti perché i controlli esistono prima che gli agenti arrivino. Questa differenza è ciò che separa le organizzazioni in grado di scalare l'IA da quelle che accumulano debito tecnico e operativo mentre credono di stare scalando.
La tracciabilità prodotta da una piattaforma di governance ha un beneficio aggiuntivo che poche conversazioni sul ROI menzionano esplicitamente: trasforma l'IA da scatola nera in sistema verificabile. Ogni flusso di lavoro lascia un registro di quali dati ha utilizzato, quali azioni ha intrapreso, quale intervento umano ha richiesto, quanto è costato e quale risultato ha prodotto. Non è solo controllo del rischio. È l'infrastruttura che rende possibile misurare il valore economico con la granularità che i consigli di amministrazione e gli investitori richiederanno con crescente urgenza.
L'architettura come decisione di distribuzione del valore
C'è una dimensione che l'analisi tecnica tende a escludere, ma che ha conseguenze economiche dirette: l'architettura dell'IA non determina solo quanto efficientemente opera l'azienda. Determina chi cattura il valore che l'IA genera.
Un'organizzazione che costruisce uno strato di contesto condiviso, un meccanismo di routing intelligente e una piattaforma di governance unificata sta costruendo asset interni che riducono la propria dipendenza da fornitori esterni. Può cambiare il modello linguistico sottostante senza ricostruire la logica di business. Può aggiungere nuove applicazioni senza dover ripagare l'intero costo di integrazione. Può verificare il valore di ogni flusso di lavoro perché dispone dell'infrastruttura per farlo.
Un'organizzazione che non costruisce tutto questo sta invece esternalizzando permanentemente le economie di scala dell'IA. Ogni nuovo fornitore, ogni nuovo modello, ogni nuovo strumento cattura una porzione del valore perché l'azienda non dispone dell'architettura che le consentirebbe di internalizzare quella cattura. Il costo di cambio aumenta. Il potere contrattuale diminuisce. Il valore generato dall'IA si disperde verso l'esterno invece di accumularsi all'interno.
Questo ha implicazioni su come valutare la spesa in IA. La domanda a cui i CIO dovrebbero rispondere non è quanto costa il modello, ma quale parte di quella spesa sta costruendo capacità riutilizzabile e quale parte sta pagando, ancora una volta, per una capacità che si dovrebbe già avere. La risposta a questa domanda è la differenza tra un investimento in architettura e una spesa che si ripete senza accumularsi.
Il 72% delle organizzazioni che si trova al punto di pareggio o in perdita non ha necessariamente modelli scadenti. Ha un'architettura che garantisce che il costo di ogni nuovo caso d'uso sia quasi altrettanto elevato quanto quello del primo. Non è un problema di intelligenza. È un problema di design. E i problemi di design hanno soluzioni più specifiche, più durature e più misurabili rispetto all'attesa che i prezzi dell'inferenza scendano abbastanza da far quadrare i conti da soli.
