Enterprise AI, perché è tempo di ripensare l’architettura cloud

Per oltre dieci anni l’architettura cloud è stata costruita attorno a questa idea: scomporre le applicazioni in servizi il più possibile stateless, distribuirli su infrastrutture elastiche e misurarne disponibilità, latenza e throughput. Tutto bene fin quando è arrivata l’intelligenza artificiale. Quando un modello AI entra in un processo operativo, il suo comportamento dipende anche dai dati recuperati, dalla versione del prompt, dagli strumenti invocati, dai controlli applicati e dal contesto accumulato. In altre parole, l’unità da governare non coincide più con il singolo workload.

Le applicazioni basate sull’AI introducono requisiti nuovi, tra cui memoria contestuale persistente, pipeline di retrieval (l’insieme dei componenti che permettono a un’applicazione di recuperare informazioni pertinenti da fonti esterne prima di generare la risposta), processi di valutazione continua e una governance più articolata. Il modello è solo uno degli elementi in gioco. Affidabilità operativa, scalabilità e sostenibilità economica dipendono in larga misura dall’architettura che lo supporta. È per questo che l’adozione dei tradizionali modelli cloud-native per portare l’AI in produzione mostra spesso i propri limiti soltanto dopo la fase sperimentale.

Il salto dal prototipo alla produzione

Durante la sperimentazione, alcuni documenti indicizzati e un servizio gestito possono bastare. Ma quando un’applicazione AI entra in produzione cambiano sia la scala sia le responsabilità: quale versione del modello ha generato una risposta? Con quali fonti? Quali autorizzazioni aveva l’utente? Quanto è costata l’interazione? Che cosa accade se l’output attiva un processo su un sistema aziendale?

È proprio in questo passaggio dalla prototipazione all’esercizio operativo che emerge il tema della piattaforma. Le pratiche cloud-native continuano a rappresentare una base solida per affrontare requisiti di scalabilità, automazione e resilienza. La survey annuale 2024 della Cloud Native Computing Foundation rilevava che il 91% delle organizzazioni utilizzava container in produzione e che il 93% usava, sperimentava o valutava Kubernetes.

Sul fronte dell’AI, però, il livello di maturità è inferiore: il 48% degli intervistati non eseguiva workload AI o machine learning su Kubernetes, mentre inferenza in tempo reale e sperimentazione sui modelli raccoglievano ciascuna il 10% delle risposte. I dati suggeriscono che, se per il software tradizionale il percorso verso la produzione è ormai consolidato, per l’AI molte organizzazioni sono ancora nella fase di sperimentazione e stanno cercando di adattare le piattaforme esistenti alle nuove esigenze operative.

L’architettura fra stato e contesto

Se un’applicazione tradizionale può delegare lo stato a database ben delimitati, un sistema di AI generativa distribuisce il proprio contesto fra più componenti: repository documentali, cataloghi dati, indici vettoriali, cache semantiche, cronologia delle conversazioni, prompt, policy, tracce degli agenti e risultati delle valutazioni. Questi elementi influenzano l’output quanto il modello selezionato.

Una risposta può cambiare perché è stato aggiornato il corpus, è mutato l’algoritmo di ranking o un documento non è più accessibile all’utente. Conservare la sola risposta finale non consente di ricostruire l’accaduto. Servono metadati su provenienza, classificazione, versione, autorizzazioni e scadenza dei contenuti; occorre registrare quali frammenti sono stati recuperati e quali controlli hanno preceduto l’output.

Siamo all’intersezione fra data architecture e cloud architecture. Spostare tutti i dati verso un unico ambiente può aumentare latenza, costi di egress e rischio di copie incontrollate. In molti casi è preferibile portare l’elaborazione vicino alla fonte, lasciando dati sensibili o regolamentati nel perimetro appropriato.

Il disegno ibrido smette così di essere un compromesso ereditato dal passato: diventa una decisione per workload, basata su residenza del dato, latenza, disponibilità degli acceleratori, costo e livello di controllo richiesto.

Questa impostazione richiede un piano dati federato, con catalogo e policy comuni, più che la promessa di concentrare ogni informazione nello stesso luogo. Richiede anche identità coerenti fra ambienti e autorizzazioni applicate durante il retrieval, non soltanto all’ingresso dell’applicazione. Un utente autorizzato a interrogare un assistente non deve per questo acquisire accesso indiretto a ogni documento indicizzato.

Il cloud ibrido diventa un portafoglio di collocamento

I task specifici dell’AI, come training, fine-tuning, inferenza batch, inferenza interattiva e agenti hanno profili diversi. Il training richiede grandi quantità di calcolo per periodi delimitati; l’inferenza real time privilegia latenza e continuità; i job batch possono sfruttare capacità meno costosa; i modelli piccoli possono essere eseguiti vicino ai dati o all’edge. Una sola regola di allocazione dei workload difficilmente ottimizza tutti questi casi.

Questo assunto si ripercuote nella scelta architetturale. Il public cloud mantiene un vantaggio per accesso rapido a modelli, acceleratori e servizi gestiti. Il private cloud o il data center possono risultare più adatti a carichi stabili, dati sottoposti a vincoli o applicazioni che richiedono isolamento.

La portabilità non significa che tutti gli ambienti siano uguali. Container e Kubernetes consentono di standardizzare deployment e orchestrazione, ma non eliminano le differenze tra infrastrutture, che possono riguardare GPU, reti, storage, servizi gestiti e modelli di costo.

Per questo motivo, l’obiettivo non dovrebbe essere replicare ovunque lo stesso stack in modo indistinto, ma rendere portabili gli elementi che contano davvero per evitare il lock-in: dati, artefatti dei modelli, pipeline di valutazione, telemetria e policy. Cercare invece di astrarre ogni componente dell’infrastruttura rischia di ridurre i vantaggi offerti dalle singole piattaforme, con possibili impatti su prestazioni ed efficienza economica.

Dalle metriche infrastrutturali all’osservabilità del comportamento

Due richieste con la stessa latenza possono avere costi e qualità molto differenti: cambiano il numero di token, la lunghezza del contesto, i documenti recuperati, il modello scelto e il numero di chiamate effettuate da un agente.

L’osservabilità deve quindi collegare quattro livelli.

• Il primo è infrastrutturale: acceleratori, memoria, rete, storage e consumo energetico.
• Il secondo riguarda modello e pipeline: token, latenza, errori, cache hit, retrieval e versioni.
• Il terzo misura qualità e rischio: accuratezza sul caso d’uso, violazioni delle policy, drift e interventi umani.
• Il quarto traduce il servizio in valore economico: costo per pratica elaborata, ticket risolto, documento verificato o decisione assistita.

Il solo costo per token offre una vista incompleta. Un modello più caro per chiamata può ridurre il numero di passaggi o gli errori; un modello piccolo può essere sufficiente per classificare una richiesta e lasciare a un modello più capace soltanto i casi complessi. Routing, caching, quantizzazione e batching diventano così decisioni economiche oltre che tecniche.

La FinOps Foundation rilevava nel 2025 che il 63% dei professionisti FinOps gestiva già la spesa AI, contro il 31% dell’anno precedente. La priorità iniziale era capire e attribuire i costi (ingestion, reporting, anomaly detection, pianificazione) prima ancora di ottimizzarli.

La capacità fisica torna nelle decisioni del CIO

L’elasticità del cloud può far apparire il “calcolo” come una risorsa astratta. L’AI riporta in primo piano disponibilità elettrica, densità dei rack, raffreddamento e tempi di approvvigionamento. L’International Energy Agency stima che la domanda elettrica mondiale dei data center andrà a raddoppiarsi entro il 2030, raggiungendo circa 945 TWh, poco più del consumo attuale del Giappone. La domanda dei data center ottimizzati per l’AI è prevista più che quadruplicare nello stesso periodo.

Anche la capacità esistente è distribuita in modo diseguale. Nel Global Data Center Survey 2025, Uptime Institute rileva che oltre l’80% degli operatori non aveva rack sopra i 30 kW; i sistemi HPC e AI risultavano concentrati in una quota limitata di siti. La localizzazione di un workload AI dipende dunque anche da vincoli fisici che i normali criteri di placement raramente consideravano.

Per l’impresa questo non implica possedere un’infrastruttura specializzata. Impone però di includere energia, capacità garantita, resilienza e raffreddamento nella valutazione dei fornitori e nei piani di continuità. Se da un lato una strategia multi-region aumenta la resilienza, dall’altro può complicare residenza e replica dei dati.

Un control plane per modelli, dati e azioni

La governance documentale non basta quando un sistema sceglie dinamicamente fonti, modelli e strumenti. Occorre un livello di controllo capace di applicare policy durante l’esecuzione. Gli analisti propongono un control stack separato dai singoli servizi AI: raccoglie telemetria, valuta il comportamento, gestisce il ciclo di vita e può intervenire a runtime.

In termini operativi, questo livello dovrebbe:

• registrare versioni di modello e prompt;
• verificare identità e autorizzazioni a ogni accesso;
• applicare filtri coerenti fra canali;
• limitare strumenti e azioni disponibili agli agenti;
• prevedere escalation umana, arresto e rollback;
• conservare evidenze proporzionate al rischio. La separazione fra sperimentazione e produzione deve includere anche dataset di valutazione, prompt e policy, con passaggi approvati e riproducibili.

Non a caso, il profilo per l’AI generativa del NIST AI Risk Management Framework sottolinea la necessità di governare il rischio lungo l’intero ciclo di vita dei sistemi, dalla progettazione allo sviluppo, fino all’utilizzo e alla valutazione. Nella stessa direzione si muove anche l’AI Act europeo, che introduce requisiti concreti di tracciabilità per ruoli, processi e artefatti. Dal 2 agosto 2025, i fornitori di modelli di AI general-purpose sono tenuti ad adottare misure quali documentazione tecnica, policy sul copyright e sintesi dei dati utilizzati per l’addestramento. Per i modelli classificati come a rischio sistemico si aggiungono obblighi di valutazione e mitigazione dei rischi, gestione degli incidenti e protezione della cybersicurezza. Anche le organizzazioni che utilizzano tali modelli senza svilupparli direttamente devono essere in grado di distinguere con chiarezza le proprie responsabilità da quelle del fornitore lungo l’intera catena del valore..

Da dove partire: sei decisioni architetturali

La revisione può cominciare da sei scelte verificabili.

1. Classificare i workload AI, separando sperimentazione, training, batch, inferenza interattiva e sistemi agentici.
2. Mappare dati e stato, indicando posizione, sensibilità, proprietario, retention e autorizzazioni di repository, indici, prompt, tracce ed evaluation set.
3. Definire criteri di placement, includendo latenza, costo totale, residenza, disponibilità degli acceleratori, portabilità e continuità.
4. Costruire una catena di osservabilità end-to-end, dal consumo infrastrutturale alla qualità dell’output e al valore per unità di business.
5. Separare esecuzione e controllo, applicando policy, valutazioni e limiti operativi in modo coerente fra modelli e ambienti.
6. Progettare l’uscita, conservando dati, artefatti, test e telemetria in formati trasferibili e provando periodicamente la sostituzione di un modello o di un servizio.

Riconsiderare l’architettura cloud per l’AI non richiede di abbandonare ciò che l’impresa ha costruito. Microservizi, API, container, infrastructure as code e automazione restano essenziali. Cambia l’oggetto da amministrare: insieme al software entrano nel perimetro operativo il comportamento probabilistico, il contesto che lo alimenta e le azioni che ne derivano.