4 cose da capire sull’architettura AI, prima di mettersi a scalare

Tre grandi analisi indipendenti, pubblicate nelle ultime settimane da Gartner, McKinsey e Deloitte, arrivano alla stessa diagnosi sull’adozione dell’AI in azienda: quattro ostacoli strutturali, dati disordinati, contesto mal progettato, governance assente, competenze insufficienti, frenano il passaggio dal progetto pilota alla scala. Nessuna delle tre società li tratta come problemi isolati: sono fondamenta che vanno costruite insieme, non una alla volta.

Un modello linguistico addestrato su miliardi di parametri non compensa un database aziendale disordinato. Se i dati di partenza sono duplicati, non aggiornati o privi di struttura, il sistema restituisce risposte plausibili ma sbagliate, e lo fa con la stessa sicurezza con cui restituirebbe risposte corrette.

I dati prima del modello, sempre

Molti progetti pilota AI falliscono per dati non pronti, non per limiti del modello scelto. Un report di settore sul data streaming ha già misurato che il 72% dei responsabili IT indica l’assenza di infrastrutture dati in tempo reale come il principale ostacolo alla scalabilità dell’AI in azienda.

La correzione non è tecnicamente complessa, ma è costosa e priva di visibilità immediata: mappare le fonti, eliminare duplicati, stabilire una governance di aggiornamento. È lavoro che non produce una demo da mostrare al comitato direttivo. Per questo viene rimandato, e i progetti pilota muoiono in produzione sei mesi dopo il lancio, quando i dati sporchi si accumulano sopra la soglia di tolleranza.

Un’alternativa che il settore sta esplorando con più decisione è la struttura del data lakehouse, pensata proprio per unire l’affidabilità dei data warehouse tradizionali con la flessibilità dei data lake su cui girano i modelli AI. È un’infrastruttura che sta diventando fondamento per l’AI aziendale, non perché sia più semplice da implementare, ma perché evita di dover scegliere tra due sistemi separati che finiscono per disallinearsi nel tempo.

Il contesto conta più del prompt

Un modello capisce solo quello che gli viene messo davanti nella finestra di contesto. Se l’azienda non ha organizzato la conoscenza interna in una forma che il sistema possa recuperare con precisione, il modello inventa, generalizza o risponde con l’informazione sbagliata presa dal training generico.

La disciplina che si occupa di questo si chiama “context engineering”: costruire i meccanismi che selezionano, aggiornano e strutturano l’informazione da fornire al modello al momento giusto. Include tecniche di recupero documentale (RAG), database vettoriali, e sempre più spesso knowledge graph che collegano entità e relazioni invece di frammenti di testo isolati.

Il punto debole tipico resta la memoria: i sistemi restano ancora smemorata oltre una certa lunghezza di conversazione o di documento, e perdono coerenza proprio quando servirebbe di più, nei flussi agentici a più passaggi.

Sono pratiche in evoluzione rapida, non standard consolidati: chi promette una soluzione definitiva sta vendendo, non descrivendo lo stato dell’arte.

Il rischio più concreto compare quando più agenti devono coordinarsi tra loro, non solo rispondere a una singola richiesta. Un sondaggio Forrester ha rilevato che il 75% delle aziende ha già introdotto agenti AI in qualche funzione, ma la maggior parte non li sa orchestrare in una catena coerente di passaggi. Il contesto non basta se manca la struttura che decide quale agente parla con quale, e in che ordine.

Governance e osservabilità non sono un livello da aggiungere dopo

McKinsey ha misurato che solo un terzo delle organizzazioni che stanno già distribuendo agenti autonomi ha un livello di maturità di governance adeguato a quel rischio. Il punteggio medio di maturità sulla responsabilità dell’AI è salito da 2,0 nel 2025 a 2,3 nel 2026, su una scala dove restare sotto 3 significa operare senza controlli sufficienti su un sistema che agisce in autonomia.

Osservabilità significa sapere cosa fa il modello in produzione: quali richieste riceve, quanto costa ogni interazione in token, dove sbaglia, chi ha accesso a cosa. Senza questo livello, un’azienda scopre di avere un problema solo quando il problema è già visibile al cliente o al regolatore.

Molte aziende che comprano tool AI non hanno ancora capito cosa farci fare in modo produttivo, e di conseguenza perdono governance proprio nella fase in cui l’adozione accelera. Gli strumenti di controllo costi e osservabilità sui modelli linguistici esistono già, ma vengono aggiunti dopo l’incidente, non prima del lancio.

Il salto di rischio tra un chatbot che risponde a una domanda e un agente che esegue transazioni, modifica record, invia comunicazioni per conto dell’azienda è enorme. Un modello che sbaglia una risposta genera un fastidio. Un agente con permessi di scrittura che sbaglia un’azione genera un incidente da comunicare a clienti, fornitori o autorità di vigilanza, a seconda del settore.

Chi resta umano nel loop, e perché è la parte più difficile da vendere

La narrativa dominante racconta l’AI aziendale come sostituzione di personale. I dati raccontano altro: secondo l’ultima rilevazione Deloitte sui trend tecnologici, quasi il 70% delle aziende intervistate prevede di far crescere i team proprio in risposta diretta alla diffusione della AI generativa, non di ridurli. La barriera principale citata è la carenza di competenze interne, non l’eccesso di personale.

Servono persone che sappiano validare l’output di un modello, riconoscere un’allucinazione plausibile, intervenire quando l’agente esce dal perimetro previsto. È una competenza che si costruisce con formazione mirata e tempo, non con un webinar aziendale di un’ora.

Anche la carenza di competenze cambia forma rispetto a un anno fa. Non serve solo chi sa scrivere prompt efficaci, servono profili ibridi capaci di leggere un’architettura dati, valutare un rischio di conformità e discutere con un fornitore di infrastruttura sullo stesso piano tecnico. Sono figure che il mercato del lavoro non produce in quantità sufficiente.

Qui si chiude il cerchio dei quattro elementi. Uno studio della ricerca MIT NANDA, “The GenAI Divide”, ha misurato che il 95% dei progetti pilota di AI generativa in azienda non produce alcun impatto misurabile sul conto economico. Non è un problema di modello: OpenAI, Anthropic e Google rilasciano aggiornamenti ogni poche settimane, e nessuno di quegli aggiornamenti risolve dati sporchi, contesto mal progettato o governance assente.

Le quattro fondamenta (dati puliti, contesto ben progettato, governance incorporata dall’inizio, persone formate) restano teoria proprio perché sono le voci di budget meno vendibili all’interno di un’azienda. Un nuovo modello si presenta bene in una demo al consiglio di amministrazione. Un progetto di pulizia dei dati o di formazione interna no, anche se è quello che decide se il pilota sopravvive oltre i primi sei mesi.

Il conflitto è tra chi controlla il budget per l’iniziativa AI e chi eredita l’infrastruttura sei mesi dopo. Chi lancia il pilota vuole un risultato dimostrabile in tempi brevi, e i quattro elementi strutturali non producono un risultato dimostrabile a breve termine: producono resilienza a medio termine, che nessun comitato direttivo applaude allo stesso modo di una demo.

Chi eredita quel pilota, di solito un team IT o data che non ha scelto la priorità iniziale, si trova a gestire un sistema costruito su fondamenta che nessuno voleva finanziare per primo. Il conto lo paga sempre chi arriva dopo, mai chi ha tagliato il nastro.