Cloud, Masera: “Senza governance l’AI nei processi rimane un esperimento”

Un agente di intelligenza artificiale può continuare a funzionare anche quando i dati che utilizza sono incompleti, il modello è superato o una risorsa di calcolo è congestionata. Per le imprese che affidano all’AI attività e decisioni, la continuità operativa comprende anche la qualità dei risultati prodotti. La disponibilità dei servizi va quindi accompagnata da un controllo sulle condizioni in cui lavorano.

Questa esigenza influenza le scelte su cloud e data center. Contano la posizione delle informazioni, i tempi di risposta richiesti dalle applicazioni, la riservatezza e i costi al crescere dei volumi. Distribuire i carichi di lavoro tra ambienti pubblici, privati e risorse vicine al luogo in cui vengono generati i dati richiede una gestione coordinata, capace di individuare anomalie e ricostruirne le cause.

In questa intervista a CorCom Matteo Masera, Head of 7CIRCLE at Var Group, approfondisce i requisiti infrastrutturali per portare l’intelligenza artificiale nei processi aziendali. Nel giorno di chiusura di Zing, l’evento annuale che l’azienda dedica alla propria community per “aiutare le aziende a colmare il divario tra ciò che è possibile e ciò che viene realmente fatto”, Masera illustra il modello Dual Layer AI, che separa il trattamento delle informazioni sensibili dall’utilizzo dei servizi pubblici, e il contributo dell’AIOps, l’applicazione dell’intelligenza artificiale alla gestione dei sistemi informatici. Nel confronto entrano anche gli obblighi di sicurezza e la tracciabilità delle azioni di risposta agli incidenti.

Masera, dal vostro osservatorio, che cosa serve oggi alle imprese sul fronte cloud e data center per portare l’intelligenza artificiale nei processi aziendali?

Le imprese che vogliono portare l’AI nei processi aziendali si scontrano quasi subito con un problema di fondamenta: l’AI non è un’applicazione, è un carico di lavoro continuo, distribuito, asimmetrico. E le infrastrutture progettate per il mondo applicativo tradizionale, che sono tipicamente centralizzate, dimensionate sul picco, ottimizzate per la latenza umana, non reggono.

Dal nostro osservatorio notiamo la convergenza di tre bisogni strutturali. Primo, la capacità di trattare il dato dove si trova, in tempo reale, senza dover ogni volta accentrare tutto in un unico data center. Secondo, la potenza computazionale per accelerare l’inferenza AI senza colli di bottiglia. Terzo, la capacità di orchestrare tutto questo in modo intelligente: sapere dove girare un workload, quando spostarlo, come garantire prestazioni costanti.

È qui che entra il modello che noi chiamiamo infrastruttura distribuita intelligente: non un’unica nuvola, non un unico data center, ma un continuum di risorse (cloud pubblico, privato, edge, co-location) governato da un livello di intelligenza operativa che osserva, decide e adatta in autonomia. Senza quel layer di governance, l’AI nei processi rimane un esperimento.

Quali criteri guidano la scelta fra cloud pubblico, privato, ibrido e multi-cloud, considerando prestazioni, costi e sovranità dei dati?

La domanda che ci poniamo sempre con i clienti non è “quale cloud scegli?” ma “dove vive il dato, chi lo usa, quanto velocemente deve rispondere, e cosa succede se non è disponibile?”. Da queste risposte emerge quasi naturalmente il modello architetturale corretto.

Il cloud pubblico rimane insuperabile per elasticità e per accedere rapidamente a servizi AI già pronti, ovvero i modelli fondazionali degli hyperscaler e i servizi gestiti di machine learning. Ma ha due limiti che nella nostra esperienza diventano presto critici: il costo a regime quando i volumi crescono, e la sovranità del dato.

Qui entra un tema che vediamo esplodere trasversalmente a tutti i settori: la riservatezza dei dati dei clienti. Non parliamo solo di compliance normativa in senso stretto (GDPR) ma di un problema strutturale che riguarda qualsiasi azienda che gestisce dati di terzi. Un’azienda manifatturiera ha dati di produzione che non possono mescolarsi con ambienti condivisi. Una banca non può fare inferenza AI su dati di un cliente usando un modello che potrebbe essere stato influenzato da dati di un competitor.

Il rischio concreto, e spesso sottovalutato, è che i modelli AI assorbono dati che non dovrebbero: per prompt injection, per logging implicito, per policy di retention dei provider non sempre trasparenti. È il motivo per cui i DPO di molte aziende stanno bloccando l’adozione di certi strumenti AI as-a-service.

È per questo che abbiamo adottato e stiamo proponendo ai clienti una logica di Dual Layer AI, ovvero un’adozione di infrastrutture ibride di ospitalità e trattamento del dato, che generalmente è composta da un layer pubblico, dove dati aggregati e non sensibili confluiscono su cloud pubblico, per garantire elasticità, velocità e servizi AI pronti all’uso, e da un layer privato, dove i dati dei clienti e i dati soggetti a compliance risiedono nel nostro data center. In quest’ultima modalità è possibile sperimentare AI su modelli privati, isolati, con governance completa e auditabile. Nessun dato sensibile esce quindi dal perimetro.

I due layer comunicano ma con regole di separazione rigide e controllate. Il risultato è che l’azienda non deve scegliere tra potenza dell’AI e protezione del dato: ha entrambe, in due ambienti distinti che lavorano insieme.

Questo approccio risponde anche ai requisiti normativi della NIS2, la direttiva europea sulla sicurezza delle reti e dei sistemi informativi. NIS2 impone obblighi precisi su come i dati vengono protetti, conservati, tracciati e resi disponibili in caso di incidente. Nel nostro data center, la catena del dato è documentabile, auditabile, difendibile davanti a un’autorità di controllo. Il data center non è più una scelta conservatrice: è la risposta corretta alla normativa, per i dati che contano.

Il modello ibrido e multi-cloud è la realtà di quasi tutte le aziende mature che seguiamo. Il problema non è sceglierlo ma governarlo. Senza una piattaforma unificata di orchestrazione, visibilità e separazione dei dati, il multi-cloud diventa un moltiplicatore di complessità, di costi nascosti e, soprattutto, di rischio compliance.

Come si garantisce la continuità operativa con applicazioni e agenti AI distribuiti su più infrastrutture cloud? Quali rischi vengono sottovalutati?

La continuità operativa in ambienti AI distribuiti è il punto dove molte aziende si trovano impreparate. Con le applicazioni classiche, il problema è binario: il servizio funziona o non funziona. Con gli agenti AI e i workload distribuiti, il rischio è più sottile: il sistema continua a girare, ma prende decisioni degradate perché un modello non è aggiornato, un dato non è arrivato, un nodo è congestionato.

I rischi che vediamo sistematicamente sottovalutati sono tre. Il primo è la dipendenza dai modelli fondazionali esterni: se un’azienda ha costruito processi critici su un modello cloud di un hyperscaler, cosa succede se quell’endpoint cambia, rallenta o viene deprecato? Il secondo è la deriva del dato: i dati che alimentano i modelli in diversi nodi possono andare out of sync, generando decisioni incoerenti. Il terzo è la mancanza di observability reale, sapere che il sistema “gira” non è sufficiente se non sai con quale qualità gira ogni componente.

Se questo non bastasse, con l’introduzione della NIS2, la continuità operativa non è più solo un obiettivo di business: è un obbligo legale con tempistiche precise. In caso di incidente significativo, NIS2 impone notifica alle autorità entro 24 ore, rapporto dettagliato entro 72 ore, e misure dimostrabili di risposta e ripristino. Devi poter dimostrare, con log e audit trail, cosa è successo, quando, su quale infrastruttura, e come hai risposto. Un ambiente multi-cloud non governato rende questo esercizio enormemente complesso.

La risposta a tutto questo è il modello AIOps: un livello di gestione intelligente dell’infrastruttura che osserva il comportamento del sistema in modo olistico, correla anomalie su domini diversi (rete, compute, storage, applicazione, dato) e interviene proattivamente. Un’infrastruttura con un piano di osservabilità unificato diventa non solo un vantaggio operativo, ma uno strumento di compliance normativa.

AIOps: cosa significa concretamente per un’azienda che deve gestire un’infrastruttura distribuita? È uno strumento, un approccio, una piattaforma?

È una domanda che mi fa piacere perché su questo tema abbiamo iniziato a investire in Var Group più di due anni fa. AIOps è uno di quei termini che il mercato ha già consumato prima che la maggior parte delle aziende capisse davvero cosa significa. Vale la pena fare chiarezza.

AIOps non è uno strumento. È un modello operativo: il modo in cui un’organizzazione usa l’intelligenza artificiale per gestire l’infrastruttura che fa girare il business. La differenza con il monitoring tradizionale è radicale: il monitoring ti dice che qualcosa è andato storto. AIOps ti dice che qualcosa sta per andare storto, perché ha imparato a riconoscere i pattern che precedono il problema.

I modelli AIOps permettono di correlare le anomalie tra domini diversi. Ad esempio, un’anomalia sulla rete può essere il segnale precoce di un problema applicativo. Un sistema AIOps che osserva tutti i domini in modo unificato lo intercetta prima. Inoltre, AIOps permette di ottenere root cause analysis automatiche, identificando l’evento radice e proponendo, e a volte anche eseguendo, l’azione correttiva.

Di certo una cosa è chiara: non puoi gestire un’infrastruttura AI-driven con strumenti operativi pre-AI. È una contraddizione in termini. AIOps è la risposta: usi l’intelligenza artificiale per garantire che l’intelligenza artificiale funzioni. È il livello meta che tiene insieme tutto il resto.

C’è un ultimo aspetto urgente con NIS2: AIOps non è solo uno strumento operativo, è uno strumento di compliance. NIS2 richiede di dimostrare controllo continuo sull’infrastruttura, capacità di rilevazione degli incidenti, tracciabilità delle azioni correttive. Un sistema AIOps ben configurato produce esattamente quella traccia: ogni anomalia rilevata, ogni correlazione identificata, ogni azione intrapresa è loggata, tracciata e auditabile.

Nel nostro modello, AIOps è la logica con cui progettiamo e gestiamo l’infrastruttura distribuita dei nostri clienti. Dal data center al cloud pubblico, dall’edge al core, con un unico piano di osservabilità e governo che non lascia zone d’ombra e non lascia l’infrastruttura non governata. E investire in AIOps non è solo una scelta tecnologica: è una scelta di governance aziendale.