Quando l’AI entra nei processi aziendali, accede a informazioni sensibili, interagisce con applicazioni e database, supporta centinaia o migliaia di utenti oppure comincia ad agire attraverso agenti autonomi. A quel punto la domanda non è più soltanto quale modello utilizzare, ma quale architettura sia in grado di sostenerlo. L’Enterprise AI sta infatti introducendo caratteristiche molto diverse da quelle sulle quali sono state costruite molte infrastrutture cloud degli ultimi anni:
- nuovi workload;
- necessità di accelerazione hardware;
- grandi quantità di dati distribuiti;
- requisiti di sicurezza, compliance e costi che possono variare sensibilmente a seconda del modello e dell’utilizzo.
Portare l’AI “in produzione” significa quindi ripensare anche ciò che sta sotto il modello. Dove eseguire i workload? Come gestire dati e accessi tra ambienti diversi? Come garantire prestazioni, controllo e sostenibilità economica? Ecco che quindi diventa necessario ripensare l’architettura cloud come infrastruttura capace di sostenere l’AI, una componente sempre più determinante dei processi aziendali.
Non tutti i workload AI sono uguali
Uno dei primi elementi da considerare riguarda proprio il tipo di carico che l’infrastruttura deve sostenere. Parlare genericamente di “workload AI” rischia infatti di semplificare troppo la questione-. Training, fine-tuning, inferenza batch, inferenza real time e sistemi agentici hanno caratteristiche molto diverse e possono richiedere risorse, livelli di latenza e modalità di gestione differenti.
Un processo di training, ad esempio, può avere bisogno di una capacità computazionale molto elevata per un periodo limitato. Un servizio di inferenza utilizzato ogni giorno da centinaia di utenti deve invece garantire continuità, tempi di risposta prevedibili e disponibilità delle risorse. I workload batch possono essere eseguiti in finestre temporali specifiche, mentre alcune applicazioni possono richiedere elaborazione vicino alla sorgente del dato per ridurre la latenza o evitare trasferimenti non necessari.
Questo significa che non esiste necessariamente un unico ambiente ideale per tutti i casi d’uso AI. Il public cloud può offrire rapidità di accesso a servizi, modelli e capacità di calcolo avanzata; infrastrutture private o on-premise possono rispondere meglio a esigenze di controllo, riservatezza o prevedibilità; l’edge può diventare strategico quando la prossimità al dato e la velocità di elaborazione sono determinanti. La scelta dell’ambiente non dovrebbe quindi partire dalla tecnologia disponibile, ma dalle caratteristiche del workload e dai requisiti che deve rispettare.
Hybrid cloud: una scelta di placement, non solo una combinazione di ambienti
L’hybrid cloud assume un significato diverso rispetto al passato. Non si parla più soltanto della convivenza tra infrastrutture on-premise e public cloud, ma entra in gioco la possibilità di collocare ogni workload nell’ambiente più adatto, valutando caso per caso fattori come performance, latenza, disponibilità di risorse, sensibilità del dato, compliance e costi.
Per l’Enterprise AI questo approccio diventa particolarmente rilevante. Spostare indiscriminatamente dati e workload verso un unico ambiente può infatti introdurre inefficienze, aumentare i costi di trasferimento o generare copie difficili da governare. In molti scenari può essere più efficace fare il contrario: portare l’elaborazione vicino al dato, mantenendo le informazioni più sensibili nel perimetro più appropriato e utilizzando il cloud pubblico dove elasticità e capacità computazionale rappresentano un vantaggio concreto.
In questo modo l’hybrid cloud smette di essere una conseguenza della stratificazione tecnologica e diventa una scelta architetturale intenzionale. Una scelta che richiede però coerenza tra ambienti diversi: identità, autorizzazioni, policy di sicurezza e strumenti di controllo devono poter seguire workload e dati ovunque vengano eseguiti.
Dati e contesto diventano parte dell’architettura
La collocazione dei workload, però, è solo una parte della questione. Con l’AI generativa cambia anche il modo in cui deve essere considerato il dato. In un’applicazione tradizionale, lo stato viene generalmente gestito attraverso database ben definiti. In un sistema AI, invece, il contesto che contribuisce a generare una risposta può essere distribuito tra repository documentali, cataloghi, indici vettoriali, cache, cronologia delle conversazioni, prompt, policy e informazioni prodotte dagli agenti.
Il risultato generato non dipende quindi soltanto dal modello utilizzato, ma anche da quali informazioni vengono recuperate, dalla loro versione e dalle autorizzazioni applicate nel momento in cui vengono utilizzate. Una stessa richiesta potrebbe produrre un risultato differente perché è cambiato un documento, è stato aggiornato il corpus informativo oppure una determinata risorsa non è più accessibile all’utente. Per questo conservare semplicemente l’output finale non è sufficiente: diventa necessario poter ricostruire quali informazioni siano state utilizzate e quali controlli siano intervenuti prima della generazione della risposta.
È proprio su questo terreno che data architecture e cloud architecture iniziano a sovrapporsi. Centralizzare tutte le informazioni nello stesso ambiente non rappresenta necessariamente la soluzione migliore: può aumentare la latenza, i costi legati allo spostamento dei dati e il numero di copie da controllare. In determinati casi, quindi, può essere preferibile avvicinare l’elaborazione alla fonte del dato e mantenere le informazioni più sensibili o soggette a vincoli all’interno del perimetro più appropriato.
Questo presuppone però una gestione coerente delle identità e delle autorizzazioni tra ambienti differenti. L’accesso a un assistente AI, ad esempio, non dovrebbe trasformarsi automaticamente nella possibilità di interrogare qualsiasi documento presente nelle fonti alle quali il sistema è collegato.
Dall’infrastruttura al comportamento: cambia anche l’observability
L’introduzione dell’AI modifica anche ciò che deve essere osservato e misurato. Le tradizionali metriche infrastrutturali – capacità computazionale, memoria, rete o storage – continuano a essere importanti, ma raccontano soltanto una parte di ciò che accade. Due interazioni con tempi di risposta molto simili possono infatti avere un comportamento completamente diverso: possono cambiare il numero di token utilizzati, la quantità di contesto elaborato, i documenti recuperati, il modello coinvolto oppure il numero di chiamate effettuate da un agente.
Per questo l’observability dell’Enterprise AI deve estendersi lungo più livelli. Da una parte rimane necessario controllare l’infrastruttura e le risorse utilizzate. Dall’altra occorre osservare modello e pipeline, monitorando aspetti come token, latenza, errori, retrieval e versioni. A questi elementi si aggiungono poi la qualità del risultato, il rispetto delle policy, eventuali variazioni nel comportamento del sistema e la necessità di intervento umano.
Ma c’è anche un quarto livello: quello economico. Per comprendere realmente l’efficienza di un servizio AI non basta conoscere il costo della singola chiamata o del singolo token. È molto più significativo mettere quel costo in relazione con il risultato prodotto: ad esempio una pratica elaborata, un ticket risolto o un documento verificato.
Anche le scelte tecniche cambiano quindi significato. Utilizzare modelli differenti a seconda della complessità della richiesta, ottimizzare l’uso della cache o aggregare determinate elaborazioni diventano decisioni che incidono contemporaneamente su performance e sostenibilità economica. In altre parole, con l’AI il FinOps non riguarda più soltanto quanto costa l’infrastruttura, ma anche come viene consumata per produrre un determinato risultato.
Da dove iniziare per ripensare l’architettura cloud per l’AI?
Ripensare l’architettura non significa ricostruire da zero quanto realizzato negli ultimi anni. Microservizi, API, container, Infrastructure as Code e automazione rimangono elementi fondamentali. A cambiare è soprattutto ciò che l’infrastruttura deve essere in grado di amministrare e controllare.
Il primo passo può essere quindi comprendere quali tipi di workload AI siano già presenti o previsti, distinguendo sperimentazione, training, elaborazioni batch, inferenza interattiva e agenti. A questa analisi deve affiancarsi una mappatura dei dati e del contesto utilizzati dai sistemi: dove si trovano, quanto sono sensibili, chi ne è responsabile, per quanto tempo devono essere conservati e quali autorizzazioni ne regolano l’accesso.
Solo a questo punto diventa possibile stabilire criteri coerenti per il placement dei workload, considerando contemporaneamente latenza, costi, residenza del dato, disponibilità degli acceleratori, portabilità e continuità operativa.
La stessa logica deve riguardare l’observability, che deve collegare ciò che accade sull’infrastruttura alla qualità dell’output e al valore generato per il business, e la governance, separando chiaramente esecuzione e controllo.
Infine, progettare un’architettura per l’Enterprise AI significa considerare fin dall’inizio anche la possibilità di cambiare. Dati, artefatti dei modelli, test e telemetria dovrebbero poter essere trasferiti, così da evitare che una scelta tecnologica iniziale si trasformi in un vincolo difficilmente superabile in futuro.
L’Enterprise AI cambia ciò che l’infrastruttura deve governare
La sfida, quindi, non è sostituire le architetture cloud costruite fino a oggi, ma estenderne il perimetro. Con l’Enterprise AI non devono più essere governati soltanto applicazioni, servizi e risorse infrastrutturali. Entrano in gioco anche il contesto utilizzato dai modelli, il loro comportamento, i dati recuperati durante l’esecuzione, i costi generati da ogni interazione e le azioni che un sistema può attivare.
È proprio per questo che portare l’AI dalla sperimentazione ai processi aziendali richiede una riflessione che va ben oltre la scelta del modello. Significa progettare un’architettura capace di decidere dove eseguire i workload, quali dati mettere a loro disposizione, come osservarne il comportamento e fino a dove consentire loro di agire.
L’Enterprise AI, in altre parole, non rende obsolete le fondamenta del cloud. Le costringe a confrontarsi con un oggetto molto più dinamico, distribuito e difficile da governare rispetto alle applicazioni per cui erano state originariamente progettate.
