Per anni una delle promesse più potenti del cloud è stata anche una delle metafore meglio riuscite dell’industria tecnologica: rendere l’infrastruttura quasi invisibile, trasformandola da insieme di macchine, server e data center in una capacità disponibile apparentemente ovunque e in qualsiasi momento. Non era più necessario sapere dove si trovasse fisicamente il server sul quale girava un’applicazione, quale macchina stesse elaborando un determinato dato o in quale edificio fosse conservato un database, perché ciò che contava era poter ottenere capacità computazionale, storage e servizi rapidamente, scalarli secondo necessità e pagarli in funzione dell’utilizzo.

Questa astrazione ha cambiato profondamente l’IT e, insieme all’IT, il modo in cui le imprese progettano servizi, sviluppano prodotti e affrontano l’innovazione. Tuttavia, aver reso invisibile l’infrastruttura dal punto di vista dell’utente non significa averne eliminato la dimensione fisica: dietro ogni console attraverso la quale selezioniamo una “region” esistono data center collocati in territori precisi, reti, sistemi energetici, operatori, società, contratti, personale, fornitori e ordinamenti giuridici. I dati possono muoversi con una velocità tale da rendere quasi irrilevante la distanza nell’esperienza quotidiana, ma continuano a esistere all’interno di infrastrutture che appartengono a qualcuno, sono amministrate da qualcuno e rispondono a determinate regole.

È proprio in questo passaggio che la sovranità digitale smette di essere soltanto un tema politico o regolatorio e diventa una questione architetturale, perché la geografia, che pensavamo di aver progressivamente espulso dall’informatica, sta tornando a essere una delle variabili attraverso le quali valutare le nostre scelte tecnologiche.

La regione cloud non è soltanto una scelta tecnica

Quando un’organizzazione seleziona una regione cloud, la decisione viene tradizionalmente affrontata attraverso parametri molto concreti: latenza, disponibilità dei servizi, resilienza, costi, prossimità agli utenti, possibilità di replica, business continuity e disaster recovery. Sono criteri ancora fondamentali, ma oggi non possono più rappresentare l’intero perimetro della valutazione, perché la posizione di un workload determina anche una parte del contesto giuridico e operativo nel quale quel workload esiste.

Sapere che un database risiede fisicamente in Europa, per esempio, non significa automaticamente aver risolto ogni questione relativa alla sovranità del dato. Occorre comprendere chi gestisce l’infrastruttura, quale soggetto societario eroga il servizio, quali entità possono intervenire nelle attività di assistenza e manutenzione, da quali Paesi possono essere effettuati determinati accessi amministrativi, quali subfornitori partecipano alla catena operativa, dove vengono conservati backup e log e quali ordinamenti possono produrre effetti sul provider che controlla quella tecnologia.

La distinzione tra residenza del dato e controllo del dato diventa quindi essenziale. Un’infrastruttura può essere fisicamente collocata all’interno dell’Unione europea e contemporaneamente appartenere a una catena tecnologica, societaria e operativa molto più ampia, nella quale intervengono soggetti sottoposti a giurisdizioni differenti. Per questo la domanda apparentemente semplice “dove sono i nostri dati?” dovrebbe essere accompagnata da un interrogativo più maturo: chi può esercitare un controllo effettivo sull’ambiente nel quale quei dati vengono conservati, elaborati e amministrati?

Quando alla mappa dei data center sovrapponiamo quella delle giurisdizioni

La questione diventa ancora più evidente quando alla geografia fisica delle infrastrutture sovrapponiamo quella del diritto, perché un servizio digitale non esiste soltanto nel luogo in cui si trova il server, ma all’interno di una rete di rapporti contrattuali, societari e normativi che può estendersi ben oltre quel territorio.

Il GDPR ha contribuito a rendere evidente come il trasferimento internazionale dei dati non possa essere interpretato semplicemente come lo spostamento di informazioni da un server a un altro. Le regole europee sui trasferimenti verso Paesi terzi, insieme alla crescente attenzione verso modalità di trattamento, accessi, garanzie e responsabilità dei diversi soggetti coinvolti, hanno progressivamente ampliato il significato stesso di “localizzazione” del dato.

Per un’impresa questo comporta un cambiamento di prospettiva non secondario. La rappresentazione tradizionale dell’architettura, composta da applicazioni, database, storage, reti e sistemi di sicurezza, dovrebbe essere affiancata da una seconda mappa capace di rendere leggibili proprietà, controllo, dipendenze, catene di fornitura e giurisdizioni. Non si tratta di aggiungere un ulteriore livello burocratico alla gestione dell’IT, ma di includere nella valutazione del rischio elementi che per molto tempo sono rimasti sullo sfondo e che oggi possono avere conseguenze sulla continuità operativa, sulla compliance e sulla libertà strategica dell’organizzazione.

Sovranità digitale non significa isolamento

Il dibattito sulla sovranità digitale rischia tuttavia di produrre un equivoco opposto, trasformando una necessaria riflessione sul controllo delle infrastrutture in una sorta di nuova autarchia tecnologica. Sarebbe una lettura semplicistica e, soprattutto, poco utile alle imprese, perché le grandi piattaforme cloud globali hanno reso disponibili capacità tecnologiche, livelli di resilienza, sicurezza, strumenti di sviluppo e potenza computazionale che hanno contribuito in maniera decisiva all’accelerazione digitale degli ultimi anni.

Il punto non è quindi stabilire se il cloud globale sia positivo o negativo, né immaginare che ogni organizzazione debba necessariamente costruire un’infrastruttura nazionale o esclusivamente europea. La questione strategica consiste piuttosto nel conoscere il livello di dipendenza che si sta accettando e comprendere se tale dipendenza sia coerente con il valore e la criticità degli asset coinvolti.

Ogni architettura contiene inevitabilmente dipendenze: da un hyperscaler, da una piattaforma SaaS, da un database proprietario, da specifiche API, da un sistema di identità, da una determinata tecnologia di virtualizzazione o da uno stack applicativo. Il problema emerge quando queste dipendenze diventano talmente profonde da risultare difficili da identificare e, di conseguenza, impossibili da governare.

È significativo che anche a livello europeo il concetto di sovranità cloud venga progressivamente tradotto in parametri più concreti, andando oltre la semplice localizzazione geografica e includendo dimensioni legate alla sovranità giuridica, operativa e tecnologica, alla supply chain, alla sicurezza, alla compliance e alla capacità di mantenere un controllo effettivo sulle informazioni e sulle infrastrutture. Si tratta di un’evoluzione importante perché porta a considerare la sovranità non come una condizione binaria, nella quale un sistema è semplicemente “sovrano” oppure “non sovrano”, ma come un insieme di livelli di controllo e dipendenza che devono essere misurati in relazione alle esigenze dell’organizzazione.

Dal vendor lock-in al geography lock-in

Per anni il settore tecnologico ha discusso di vendor lock-in prevalentemente in termini tecnici ed economici: quanto sarebbe difficile migrare un’applicazione verso un altro provider, quanto codice dovrebbe essere riscritto, quale quantità di dati dovrebbe essere trasferita e quanto profondamente l’organizzazione dipenda dai servizi proprietari di una determinata piattaforma.

La nuova fase del cloud aggiunge una dimensione ulteriore che potremmo definire, provocatoriamente, geography lock-in. Non si tratta soltanto di capire quanto siamo legati a una tecnologia, ma quanto l’architettura dell’organizzazione dipenda da una specifica combinazione di territori, operatori, ordinamenti giuridici, infrastrutture fisiche e catene di fornitura.

Il tema diventa particolarmente rilevante quando si progettano sistemi critici, piattaforme che trattano informazioni strategiche, infrastrutture pubbliche o applicazioni basate sull’intelligenza artificiale, nelle quali dati, modelli, capacità computazionale e servizi esterni tendono a intrecciarsi molto più profondamente rispetto alle architetture tradizionali. In questi scenari la portabilità non rappresenta semplicemente una caratteristica tecnica desiderabile, ma diventa una componente della resilienza complessiva dell’organizzazione.

Sapere se un workload possa essere trasferito, se i dati possano essere realmente esportati, se esistano formati interoperabili, se le chiavi crittografiche rimangano sotto il controllo dell’organizzazione e se un servizio possa continuare a funzionare anche cambiando provider significa, in ultima analisi, misurare quanta libertà futura sia stata conservata nel momento in cui è stata progettata l’architettura.

Anche l’evoluzione normativa europea sta andando in questa direzione, intervenendo sulla possibilità di passare più efficacemente tra fornitori di servizi di data processing e introducendo una riflessione più ampia sulla portabilità. La capacità di cambiare infrastruttura non riguarda più soltanto la convenienza commerciale di poter scegliere un’offerta migliore, ma diventa uno degli elementi attraverso i quali valutare la solidità e l’autonomia di una strategia tecnologica.

Quando l’architettura diventa una decisione aziendale

La conseguenza probabilmente più rilevante riguarda il rapporto tra tecnologia e governance, perché la collocazione dell’infrastruttura non può più essere considerata esclusivamente una questione tecnica da delegare all’IT. Nel momento in cui un’organizzazione decide dove conservare il proprio patrimonio informativo, attraverso quali piattaforme elaborarlo e quali soggetti possano amministrarlo, sta assumendo decisioni che riguardano contemporaneamente continuità operativa, compliance, sicurezza, capacità negoziale, rischio e libertà strategica.

Questo non significa che ogni dato debba essere trattato allo stesso modo. Un sito corporate, un ambiente di sviluppo, una piattaforma che custodisce proprietà intellettuale, un sistema sanitario, un archivio documentale contenente informazioni riservate e un modello di intelligenza artificiale addestrato su dati proprietari presentano profili di rischio e requisiti molto differenti. Proprio questa distinzione consente di portare il tema della sovranità digitale fuori dal terreno ideologico e dentro quello della strategia aziendale, perché l’obiettivo non dovrebbe essere collocare tutto nello stesso luogo, bensì comprendere quali asset richiedano quale livello di controllo e progettare l’architettura di conseguenza.

In alcuni casi la risposta continuerà legittimamente a essere un grande cloud globale; in altri potrà essere un servizio cloud con maggiori garanzie di sovranità, un provider europeo, un’architettura ibrida, una strategia multicloud o una combinazione di soluzioni differenti. La maturità non consiste nella scelta di un modello considerato universalmente corretto, ma nella capacità di sapere perché sia stato scelto e quali conseguenze produca nel medio e lungo periodo.

La nuova mappa dell’infrastruttura digitale

Negli ultimi quindici anni abbiamo progressivamente imparato a pensare l’IT in termini di servizi anziché di macchine, capacità anziché di hardware, disponibilità anziché di luoghi. È stata una trasformazione straordinaria e non esiste alcuna ragione per immaginare un ritorno al passato, ma proprio la maturità raggiunta dal cloud ci permette oggi di osservare ciò che l’astrazione tecnologica aveva temporaneamente nascosto: l’infrastruttura digitale continua a essere parte di un sistema economico, industriale, energetico, giuridico e geopolitico molto concreto.

La prossima evoluzione delle strategie cloud difficilmente sarà quindi una contrapposizione tra cloud e non cloud oppure tra globale e locale. Sarà piuttosto la capacità di progettare infrastrutture nelle quali performance, innovazione e scalabilità convivano con una maggiore consapevolezza del controllo, delle dipendenze e della possibilità di mantenere aperte alternative future.

In questa prospettiva, la geografia torna nell’architettura IT non come un vincolo nostalgico dell’epoca dei data center aziendali, ma come una nuova variabile strategica. Sapere dove risiede un’informazione rimane importante, ma sapere chi controlla l’infrastruttura che la ospita, quali ordinamenti possono incidere su di essa, quali dipendenze ne renderebbero complessa la migrazione e quale margine di scelta conserverà l’organizzazione tra cinque o dieci anni diventa ancora più significativo.

Il cloud continuerà probabilmente a diventare più distribuito, più potente e più invisibile agli utenti. Proprio per questo, paradossalmente, le imprese dovranno imparare a vedere meglio ciò che si trova dietro quell’invisibilità, perché la vera sovranità digitale non consiste necessariamente nel possedere l’infrastruttura, ma nel conoscere e governare le condizioni dalle quali dipende la propria capacità di utilizzarla.

La domanda, allora, non è più soltanto dove siano i tuoi dati. È quella che dovrebbe interessare sempre di più chi prende decisioni tecnologiche e strategiche: sai non soltanto dove sono i tuoi dati, ma sotto quali regole vivono?