Quando si parla di sovranità digitale, la collocazione dei dati è una delle prime questioni che emergono. Per un’organizzazione, però, il controllo dei propri sistemi dipende da molte altre decisioni: chi può amministrarli, come vengono protette le informazioni durante l’elaborazione, quali dipendenze tecnologiche rimangono e come proseguono le attività quando cambiano le condizioni operative.
L’intelligenza artificiale amplia ulteriormente questo perimetro. Accanto ai dati entrano in gioco modelli, processi di inferenza, indici, strumenti di sviluppo e agenti capaci di interagire con i sistemi aziendali.
Gli annunci recenti di Microsoft delineano una proposta che collega questi elementi attraverso cloud pubblico, infrastrutture controllate dal cliente e soluzioni operate dai partner. Il riferimento comune è Microsoft Sovereign Cloud, organizzato attorno ai requisiti dei singoli workload. Advancing digital sovereignty with greater control and choice.
Il principio da cui partirei è questo:
Una strategia di sovranità diventa concreta quando i requisiti di controllo vengono tradotti in architetture, responsabilità operative ed evidenze verificabili.
Prima i requisiti di controllo, poi la piattaforma
Per valutare un’architettura sovrana è utile partire dalle domande che riguardano il processo aziendale.
Quali informazioni devono rimanere entro un determinato perimetro? Chi può accedere all’ambiente? Quali attività amministrative richiedono supervisione? Quanto può durare un’interruzione della connettività? Come si aggiornano infrastruttura, applicazioni e modelli? Quali componenti devono poter essere sostituiti?
Le risposte possono essere diverse anche all’interno della stessa organizzazione.
Un servizio rivolto al pubblico può attribuire grande valore all’elasticità. Un’applicazione industriale può richiedere elaborazione vicina agli impianti. Un assistente AI che utilizza documenti riservati può avere vincoli specifici su inferenza, accessi e gestione delle fonti.
L’impostazione descritta da Microsoft collega quindi la sovranità al workload placement, estendendo la valutazione a tutta la catena tecnologica: infrastruttura, sicurezza, dati e AI. Designing for sovereign AI: A shared foundation from edge to cloud.
Dal punto di vista architetturale, questo richiede un passaggio preciso: definire il modello di controllo dell’organizzazione e valutare, al suo interno, la destinazione dei workload.
Un continuum di controllo
Microsoft articola la proposta in tre componenti complementari.
| Componente | Ruolo nell’architettura |
|---|---|
| Sovereign Public Cloud | Aggiunge controlli e trasparenza ai workload che utilizzano il cloud pubblico Azure. |
| Sovereign Private Cloud | Porta capacità cloud negli ambienti gestiti dal cliente, comprese configurazioni disconnesse. |
| Sovereign Partner Ecosystem | Introduce competenze locali, servizi specializzati e ambienti con modelli operativi indipendenti. |
Le tre componenti possono convivere nello stesso patrimonio applicativo, in funzione dei requisiti di ciascun servizio. Microsoft Sovereign Cloud: il continuum di controllo.
A mio avviso, il valore di questa impostazione dipende dalla capacità di mantenere coerenti governance e operazioni mentre cambia il luogo di esecuzione. Questa coerenza va valutata insieme alle differenze effettive tra gli ambienti: servizi disponibili, responsabilità del cliente e procedure di gestione.
Sovereign Public Cloud: rendere il controllo visibile
Nel cloud pubblico, una parte significativa del problema riguarda la possibilità di dimostrare che i controlli previsti siano effettivamente applicati.
Sovereign Control Panel introduce una vista unificata nel portale Azure, organizzata attorno a tre attività: conoscere la propria situazione, applicare i controlli e intervenire sugli scostamenti.
La piattaforma combina valutazioni relative alle Azure Policy e letture delle configurazioni delle risorse. L’obiettivo è raccogliere evidenze su residenza, riservatezza, operazioni e continuità, facilitando l’individuazione delle aree da correggere. Sovereign Control Panel.
La public preview è prevista a Microsoft Ignite. Il perimetro annunciato comprende anche valutazioni delle dipendenze e della preparazione alla portabilità: informazioni utili per pianificare un eventuale cambiamento di ambiente, che richiederà comunque lavoro sull’architettura applicativa. What is new in Sovereign Public Cloud.
Per chi gestisce la piattaforma, la conseguenza pratica è rilevante: il controllo può entrare nel ciclo operativo ordinario, con responsabilità, verifiche periodiche e interventi sulle configurazioni.
Accessi amministrativi e tracciabilità
Data Guardian aggiunge supervisione regionale agli accessi operativi. Nell’aggiornamento di ottobre, Microsoft descrive un rollout graduale in UE ed EFTA con supervisione di residenti europei attraverso un partner UE fidato, per gli accessi remoti degli ingegneri che rientrano nel perimetro previsto.
Production Touch Ledger registra tali accessi e le azioni eseguite mediante evidenze che consentono di rilevare eventuali manomissioni. Controlli operativi di Sovereign Public Cloud.
Il modello associa quindi autorizzazione, supervisione e tracciabilità. Per valutarne l’efficacia sul proprio ambiente occorre verificare quali sistemi e operazioni siano inclusi e come utilizzare le evidenze nei processi di audit.
Custodia esterna delle chiavi
Con External Key Management per Azure Key Vault Managed HSM, generalmente disponibile, la chiave che protegge le chiavi di cifratura dei dati può rimanere in un HSM esterno all’infrastruttura Microsoft, operato dal cliente o da un soggetto scelto.
Il dettaglio tecnico è importante. La chiave esterna, la Key Encryption Key, resta nell’HSM; le operazioni autorizzate permettono al servizio Azure di ottenere la Data Encryption Key necessaria a elaborare i dati. Il servizio continua quindi a svolgere le operazioni di cifratura e decifratura.
Il controllo riguarda la custodia esterna della chiave e la protezione dei dati a riposo nei servizi compatibili. Proxy, HSM e collegamenti diventano inoltre componenti della disponibilità complessiva, con responsabilità operative del cliente o del suo fornitore. Managed HSM External Key Management.
La scelta va quindi collegata a un requisito preciso di custodia, accompagnato da un progetto di disponibilità, monitoraggio e ripristino.
Applicare i controlli attraverso la landing zone
La Sovereign Landing Zone permette di integrare queste scelte nella struttura di governance. Microsoft la descrive come una variante architetturale adottabile anche progressivamente su una landing zone esistente, con implementazioni Bicep e Terraform. Sovereign Landing Zone: opzioni di implementazione.
L’aggiornamento introduce anche un management group Local per includere Azure Local nel disegno di governance. Sul fronte dell’analisi condivisa, Azure Confidential Clean Rooms, in limited preview, applica il confidential computing a elaborazioni approvate su dati sensibili di più partecipanti. Novità di Sovereign Public Cloud.
Sovereign Private Cloud: portare il modello operativo nell’ambiente del cliente
Azure Local costituisce il fondamento di Sovereign Private Cloud: infrastruttura eseguita nell’ambiente controllato dal cliente, sulla quale ospitare workload e servizi supportati.
Qui è essenziale distinguere il luogo di esecuzione dal luogo in cui risiedono le funzioni di gestione.
Nelle connected operations, applicazioni e dati possono rimanere locali mentre Azure fornisce capacità di gestione, governance e lifecycle. La piattaforma tollera interruzioni temporanee della connettività, ma alcune funzioni dipendono dai servizi cloud. Connected operations per Azure Local.
Anche i flussi informativi richiedono attenzione: la documentazione distingue i dati applicativi dai dati di gestione conservati nel cloud, come nomi delle risorse, utilizzo e fatturazione. Servizi opzionali, per esempio il backup, possono introdurre ulteriori trasferimenti.
Nelle disconnected operations, il control plane viene invece portato nell’ambiente del cliente. Gestione, identità, monitoraggio e manutenzione devono seguire configurazioni e procedure locali supportate, comprese le operazioni offline per aggiornamenti e onboarding.
Questo modello offre un sottoinsieme delle capacità cloud e richiede preparazione: hardware idoneo, capacità dimensionata, un cluster di gestione dedicato, competenze e processi operativi. Disconnected operations per Azure Local.
La domanda progettuale diventa quindi molto concreta: quali funzioni devono continuare a essere disponibili quando il collegamento con Azure manca, e per quanto tempo?
Microsoft annuncia inoltre l’ingresso in public preview della transizione da ambienti connessi a disconnessi. Questa possibilità va inserita in un percorso pianificato, con dipendenze, passaggi e verifiche definiti prima che emerga la necessità di utilizzarla. Sovereign Private Cloud: novità operative.
La sovranità si estende ai servizi applicativi e allo sviluppo
L’autonomia operativa coinvolge anche ciò che le applicazioni utilizzano per funzionare.
SQL Server su Azure Local è già disponibile per distribuzioni connesse e disconnesse. DocumentDB e Blob Storage su Azure Local entreranno in public preview a Ignite, ampliando rispettivamente le opzioni per dati documentali e object storage.
È inoltre annunciato il supporto multitenant, inizialmente rivolto a opportunità qualificate, per separare risorse, governance e gestione di tenant diversi sulla stessa infrastruttura. Servizi e multitenancy in Sovereign Private Cloud.
La stessa logica raggiunge il ciclo di sviluppo.
GitHub Enterprise Local, con GA prevista a Ignite, porta GitHub Enterprise Server su Azure Local come appliance. Repository, pipeline e artefatti possono essere gestiti nell’infrastruttura del cliente, utilizzando anche GitHub Actions con runner autogestiti. Restano da progettare componenti come lo storage degli artefatti e la manutenzione applicativa di GitHub Enterprise Server. GitHub Enterprise Local.
Per la collaborazione, Microsoft 365 Local comprende Exchange Server, SharePoint Server e Skype for Business Server su architetture Azure Local validate. Il perimetro è quello di questi prodotti server, con requisiti hardware e di distribuzione specifici. Microsoft 365 Local.
Il punto architetturale è la completezza della catena: un’applicazione locale può continuare a dipendere da repository, identità, librerie, servizi di collaborazione o processi di rilascio esterni. Queste relazioni devono entrare nella valutazione dell’autonomia.
Foundry Local: dall’inferenza alle applicazioni AI sui dati aziendali
Con Foundry Local su Azure Local, Microsoft porta l’esecuzione dei modelli nell’infrastruttura del cliente. La GA è annunciata per Ignite, anche per operazioni connesse e disconnesse supportate. Advancing sovereign AI with Foundry Local and Azure Local.
La soluzione utilizza Kubernetes abilitato da Azure Arc e introduce gestione del ciclo di vita dei modelli, distribuzioni su CPU o GPU, scalabilità su più nodi e API compatibili con i pattern OpenAI. I modelli possono provenire dal catalogo oppure da sorgenti proprie supportate.
Questo offre una base operativa per pubblicare e gestire endpoint di inferenza vicino alle applicazioni. Richiede però capacità adeguata ai modelli, gestione Kubernetes, protezione degli endpoint e procedure coerenti con il tipo di connettività scelto. Foundry Local on Azure Local: architettura e capacità.
Per un’organizzazione, la scelta del modello deve quindi incontrare la realtà del servizio: qualità delle risposte, tempi di elaborazione, utenti simultanei, memoria disponibile e sostenibilità operativa.
Collegare i modelli alla conoscenza aziendale
Agentic Retrieval aggiunge acquisizione dei documenti, indicizzazione e recupero delle informazioni attraverso più passaggi, con risposte accompagnate da citazioni.
Gli annunci includono inoltre, in preview, agenti e connettori verso sistemi aziendali tramite Model Context Protocol (MCP), insieme a guardrail configurabili per i workload AI locali. Foundry Local: retrieval, agenti e controlli.
La documentazione descrive una pipeline locale che comprende ingestione, embedding, ricerca, orchestrazione e generazione. AI workloads on Azure Local.
È questo passaggio a rendere l’architettura particolarmente interessante per i dati aziendali: il modello può utilizzare informazioni aggiornate provenienti dalle fonti dell’organizzazione.
Il perimetro da governare comprende quindi anche indici, credenziali dei connettori, autorizzazioni sui documenti, conversazioni e azioni consentite agli agenti. Ogni componente deve rispettare il modello di accesso previsto per il servizio.
La fiducia deve arrivare fino all’hardware
La protezione dei dati durante l’elaborazione rappresenta un ulteriore livello della proposta.
Le confidential virtual machine, nelle configurazioni supportate, introducono un confine di isolamento basato sull’hardware tra il workload e lo stack di virtualizzazione. L’attestazione permette di verificare proprietà dell’ambiente prima di avviare determinate operazioni o rilasciare chiavi. Azure confidential VMs.
Le confidential VM su Azure Local sono disponibili all’uso. Sicurezza di Sovereign Private Cloud.
Nella collaborazione con Intel, Microsoft evidenzia tecnologie come Intel TDX per l’isolamento, Intel AMX per accelerare specifici workload AI sulle CPU e OpenVINO per ottimizzazione e distribuzione dei modelli. La fondazione hardware della sovereign AI.
Per chi progetta l’ambiente, sicurezza e prestazioni diventano quindi decisioni collegate. Modello, runtime e configurazione hardware devono essere valutati insieme, attraverso misure sul workload previsto.
Come tradurre la proposta in una scelta architetturale
Un esempio aiuta a collegare le capacità ai requisiti.
Immaginiamo un’organizzazione con tre servizi diversi.
| Workload | Requisito principale | Direzione da valutare |
|---|---|---|
| Portale utilizzato da utenti distribuiti | Elasticità, disponibilità e controllo degli accessi operativi | Azure con i controlli Sovereign Public Cloud applicabili. |
| Assistente sui documenti tecnici di stabilimento | Elaborazione vicina ai dati e risposta rapida | Azure Local e Foundry Local, verificando le dipendenze della pipeline. |
| Servizio essenziale in un ambiente isolato | Operazioni prolungate senza accesso al cloud pubblico | Architettura disconnessa con gestione e servizi applicativi locali supportati. |
Sono tre decisioni che possono convivere nello stesso modello operativo.
Per ciascuna, chiederei un’evidenza concreta del requisito soddisfatto: una verifica degli accessi, una mappa dei flussi informativi, una misura delle prestazioni o una prova di funzionamento senza connettività.
Anche la portabilità va affrontata a questo livello. Il trasferimento di un workload coinvolge dati, identità, servizi applicativi, automazioni e procedure operative. Il progetto deve chiarire quali componenti possano essere spostati direttamente e quali richiedano adattamenti.
Infine, maggiore controllo locale significa assumere responsabilità precise su capacità, aggiornamenti, sicurezza e ripristino. La valutazione economica deve comprendere anche queste attività.
Il controllo va progettato nel tempo
Leggo la strategia Microsoft come un ampliamento delle possibilità di applicare controlli diversi mantenendo una base tecnologica comune.
Per le organizzazioni, il lavoro più importante rimane definire quali decisioni devono poter prendere autonomamente, quali dipendenze sono accettabili e quali condizioni operative devono poter affrontare.
Le funzionalità annunciate acquistano valore quando entrano in questo disegno: con responsabilità assegnate, configurazioni verificabili e procedure provate.
La qualità di un’architettura sovrana si misura nella capacità dell’organizzazione di governare i propri workload, continuare a operare e adattare le scelte quando i requisiti cambiano.