Il dibattito sull’AI sovrana è ancora spesso ricondotto a una questione geografica: se i dati rimangono entro un determinato confine nazionale o una specifica regione cloud, si presume che siano sotto controllo. Ma questa prospettiva, pur risultando comprensibile, rimane incompleta.

La localizzazione dei dati rimane un elemento fondamentale, soprattutto per le organizzazioni che operano in settori regolamentati e devono rispettare requisiti rigorosi in materia di archiviazione, accesso e gestione delle informazioni. Tuttavia, ridurre la sovranità a una sola questione geografica rischia di introdurre nuove limitazioni proprio nel momento in cui i workload AI diventano sempre più distribuiti.

Nella pratica, le aziende devono poter eseguire i propri carichi di lavoro AI nell’ambiente più adatto alle diverse esigenze: addestrare i modelli in un’infrastruttura, svolgere l’inferenza in un’altra e mantenere on-premise i dati più sensibili. In questo scenario, la sovranità non coincide semplicemente con il luogo in cui risiedono le informazioni, ma con la possibilità di decidere, e mantenere il controllo, su dove vengono archiviati i dati, dove avviene l’elaborazione e quali elementi possono essere trasferiti tra ambienti diversi, senza compromettere governance, sicurezza e conformità.

Dalla localizzazione alla mobilità controllata

La vera sovranità include la capacità di spostare i dati in modo intelligente. Un’azienda potrebbe dover addestrare un modello in un ambiente, eseguire l’inferenza in un altro, più vicino alle esigenze del business, e mantenere i dataset di maggior valore sotto uno stretto controllo locale.

Quando si tratta di spostare dati e workload tra ambienti diversi, però, la questione diventa più complessa. Se dipendono da servizi nativi, trasferirli può essere difficile o, in alcuni casi, impossibile. Per questo, la mobilità non può essere solo dichiarata: deve essere progettata e dimostrata.

Senza questa capacità, la sovranità rischia rapidamente di trasformarsi in un ulteriore vincolo. Dati che non possono essere spostati in sicurezza finiscono per limitare l’innovazione; mentre architetture progettate esclusivamente per garantire che i dati restino in un determinato luogo possono rivelarsi inadeguate quando cambiano le esigenze di business, emergono nuove normative o variano i requisiti prestazionali.

L’approccio più utile è quindi quello della flessibilità controllata. Le organizzazioni dovrebbero poter decidere dove eseguire un determinato workload in base a performance, costi, rischio e compliance, mantenendo al tempo stesso una visione coerente di dati, modelli e tracciabilità delle decisioni.

È anche in risposta a queste esigenze che stanno emergendo in Europa provider neocloud. Progettate specificamente per i workload AI, queste piattaforme si basano su un presupposto diverso rispetto alle architetture cloud tradizionali: le organizzazioni devono poter accedere a infrastrutture di intelligenza artificiale avanzate senza perdere il controllo su dove vengono conservati i dati e su come vengono spostati. La direzione del trasferimento non è il punto centrale: in alcuni casi, è il modello a spostarsi verso i dati; in altri, solo il set di lavoro viene memorizzato temporaneamente accanto alle GPU. Ciò che non deve mai accadere, però, è la creazione di una copia separata, non governata e potenzialmente fuori controllo.

Evitare il prossimo lock-in

Il dibattito attuale sulla sovranità nasconde un rischio silenzioso. Nel tentativo di rispondere ai requisiti di localizzazione e controllo, alcune architetture finiscono semplicemente per sostituire una dipendenza con un’altra. È quello che viene definito come il costo della duplicazione: ogni nuovo punto di fruizione può richiedere una propria copia dei dati, con relativi costi di storage, ciclo di vita e oneri di governance. Su scala petabyte, il fattore moltiplicativo conta più del prezzo unitario.

Abbiamo già visto questo schema in passato. VMware, per esempio, ha conquistato molte aziende anche grazie alla possibilità di adottare una piattaforma comune tra ambienti diversi. Tuttavia, quando le condizioni economiche sono cambiate, molte aziende hanno scoperto che allontanarsene era più difficile del previsto. Lo stesso rischio si ripropone oggi con l’AI: affidare grandi patrimoni di dati a un unico provider e al suo formato di storage proprietario può limitare la libertà di scelta futura, su una scala molto più ampia.

La sovranità dovrebbe quindi ampliare le possibilità di scelta, non ridurle. Il punto non è stabilire se un’architettura sia conforme oggi, ma se si possa dimostrare a un’autorità incaricata della regolamentazione di aver effettivamente spostato un dataset di produzione, indicando tempi e livello di discontinuità operativa.

Per riuscirci, è necessario disporre di un data layer coerente tra ambienti diversi: le stesse pratiche di governance, protezione e gestione operativa, indipendentemente dal fatto che i dati siano on-premise, in un cloud sovrano o in movimento tra i due.

Cosa richiede la sovranità operativa

In definitiva, le organizzazioni che intendono affrontare seriamente il tema dell’AI sovrana devono far convergere quattro elementi: un controllo dimostrabile sul luogo in cui sono conservati i dati sensibili e sulle modalità con cui vengono protetti; la capacità di spostare dati e workload senza compromettere governance o visibilità; non dipendere da architetture che risolvono i problemi di compliance di oggi creando il lock-in di domani; e infine la capacità di ripristinare e di recuperare l’operatività da una copia immutabile e segregata. L’object storage non offre di per sé protezione dal ransomware e i recenti incidenti su larga scala avvenuti nel settore retail hanno reso molto evidente il costo di questa lacuna.

Con il Digital Operational Resilience Act (DORA), in vigore da gennaio 2025, affermare di disporre di adeguati piani di resilienza non è più sufficiente. Le autorità di vigilanza chiedono alle istituzioni finanziarie di dimostrare di poter ripristinare l’operatività a partire da una copia segregata e, se necessario, di poter migrare verso un altro provider. In altre parole, una strategia di uscita solo teorica, che esiste sulla carta ma non è stata verificata nella pratica, non è sufficiente.

Quando questi elementi sono presenti, la sovranità rafforza sia la fiducia sul piano normativo sia l’agilità del business. Quando ne manca anche solo uno, l’organizzazione, prima o poi, ne paga il prezzo in termini di minori possibilità di scelta, maggiori costi operativi o tempi di risposta più lenti al cambiamento.

L’AI rende sempre più difficile ignorare questi compromessi. Workload che un tempo venivano eseguiti in un unico ambiente oggi si estendono su più sedi e domini di fiducia. E proprio per questo, se si desidera la sovranità dell’AI, non ci si può limitare a collocare un segnaposto su una mappa: bisogna garantire flessibilità controllata.

Jurgen Hofkens (nella foto di apertura) è CTO e VP Solutions Engineering EMEA/LATAM di NetApp