Si ampliano i controlli europei sugli accessi al cloud Microsoft e le possibilità di eseguire dati, applicazioni e AI nelle infrastrutture dei clienti. Le novità di Microsoft Sovereign Cloud comprendono il rilascio graduale di Data Guardian e Production Touch Ledger nell’UE e nell’EFTA, per supervisionare e tracciare gli accessi degli ingegneri Microsoft, e la disponibilità commerciale della gestione esterna delle chiavi crittografiche. Sul versante locale, DocumentDB, Blob Storage e il passaggio dalle operazioni connesse a quelle disconnesse entrano in anteprima pubblica, mentre GitHub Enterprise Local e Foundry Local su Azure Local saranno disponibili commercialmente a Ignite. Nella stessa occasione entrerà in anteprima pubblica Sovereign Control Panel, il pannello che riunisce nel portale Azure i controlli di sovranità e la valutazione delle dipendenze operative.
Per le organizzazioni europee, il tema comprende residenza dei dati, autorità operativa, protezione delle informazioni e continuità dei servizi. La piattaforma Microsoft Sovereign Cloud articola queste esigenze in tre modelli combinabili: il cloud pubblico con controlli aggiuntivi, il cloud privato gestito dal cliente o da un partner e i cloud nazionali con un proprio modello operativo. La scelta può variare tra le applicazioni della stessa organizzazione, mantenendo un’impostazione coerente di governance.
Un servizio rivolto al pubblico può utilizzare la capacità di Azure, mentre un sistema essenziale può richiedere infrastrutture locali e un’applicazione AI può mantenere dati e modelli nel perimetro aziendale.
Accessi al cloud sotto supervisione europea
Nel cloud pubblico, i controlli coprono sia l’autorizzazione all’accesso sia la possibilità di ricostruire le operazioni effettuate. L’accesso just-in-time limita temporalmente i privilegi, mentre Customer Lockbox permette al cliente di esaminare, approvare o rifiutare richieste di accesso ai propri dati.
Per Unione europea ed EFTA, l’Associazione europea di libero scambio, Microsoft sta distribuendo Data Guardian, con supervisione da parte di personale residente in Europa attraverso un partner UE fidato per gli accessi remoti degli ingegneri Microsoft ai sistemi di produzione inclusi nel perimetro del servizio. A questo si affianca il rilascio graduale di Production Touch Ledger, che registra accessi e azioni con meccanismi capaci di rendere rilevabili eventuali manomissioni.
Il valore operativo di Data Guardian risiede nella supervisione umana regionale e nella tracciabilità delle sessioni: le attività diventano verificabili per audit, controlli di sicurezza e valutazioni di conformità. Il registro utilizza Azure confidential ledger per proteggere l’integrità delle registrazioni.
Una vista unificata arriverà con Sovereign Control Panel, attualmente in anteprima privata e previsto in anteprima pubblica a Microsoft Ignite. Integrato nel portale Azure, il pannello riunisce le informazioni necessarie a valutare la situazione dell’organizzazione, identificare lacune e rischi e applicare interventi correttivi.
Il suo modello operativo Discover, Control, Act comprende la raccolta delle evidenze, la definizione dei controlli e delle responsabilità, il rilevamento degli scostamenti e la correzione guidata. Include inoltre la valutazione delle dipendenze delle applicazioni e della preparazione alla loro portabilità tra ambienti operativi, utile alla pianificazione della continuità. Il pannello integra le regole preventive delle Sovereign Landing Zone con una valutazione continuativa dello stato effettivo delle risorse.
Chiavi crittografiche fuori dall’infrastruttura Microsoft
La gestione esterna delle chiavi con Azure Key Vault Managed HSM è ora disponibile commercialmente. Un HSM, Hardware Security Module, è un dispositivo che protegge le chiavi crittografiche ed esegue operazioni di sicurezza. Alla protezione dedicata a un singolo cliente già offerta da Managed HSM si aggiunge la possibilità di custodire la chiave radice su hardware esterno all’infrastruttura Microsoft, gestito in sede o tramite un soggetto fidato.
Il collegamento ai servizi Azure compatibili avviene attraverso un proxy gestito dal cliente o dal fornitore dell’HSM: le operazioni proteggono e sbloccano le chiavi usate per cifrare i dati, mentre la chiave principale resta nel dispositivo esterno. La gestione esterna delle chiavi richiede l’abilitazione per sottoscrizione; l’integrazione Azure Private Link è ancora in anteprima.
Questa scelta comporta responsabilità precise sulla continuità: disponibilità e ripristino del proxy e dell’HSM esterno spettano al cliente o all’operatore designato. Un loro guasto può interrompere i servizi dipendenti e tali interruzioni restano escluse dagli accordi sui livelli di servizio Azure. Al costo standard di Managed HSM si aggiungono le risorse del proxy e le licenze del fornitore hardware.
Proteggere i dati durante l’elaborazione
Il confidential computing protegge i dati mentre vengono elaborati, all’interno di un ambiente di esecuzione fidato basato sull’hardware. L’attestazione consente di verificare le caratteristiche dell’ambiente prima di affidargli informazioni sensibili. Microsoft estende anche la trasparenza sulle tecnologie alla base di queste garanzie.
Le Azure Confidential Clean Rooms, in anteprima limitata, applicano questo approccio alla collaborazione tra organizzazioni. I partecipanti possono analizzare dati condivisi mantenendo protette le informazioni sottostanti rispetto agli altri collaboratori e all’operatore cloud. Il servizio di analisi multiparte utilizza Spark SQL, con approvazione delle interrogazioni da parte dei soggetti che contribuiscono i dati e controlli sulle colonne accessibili e sui risultati aggregati.
L’attuale anteprima delle Clean Rooms è destinata a test e valutazioni: esclude l’uso in produzione e il trattamento di dati personali o soggetti a requisiti di conformità normativa. È un limite concreto per i settori regolamentati cui si rivolge l’offerta sovrana.
Azure Local e continuità senza connessione
Nel cloud privato, basato su Azure Local, entra in anteprima pubblica la transizione dei carichi di lavoro dalla modalità connessa a quella disconnessa. Microsoft pubblica anche nuove indicazioni e modelli architetturali per progettare, implementare e provare la continuità operativa.
SQL Server su Azure Local è già disponibile per entrambe le modalità; DocumentDB e Blob Storage entrano in anteprima pubblica. Si amplia così la scelta dei servizi dati eseguibili nell’ambiente controllato dal cliente.
Microsoft annuncia inoltre la disponibilità commerciale delle macchine virtuali riservate su Azure Local. La cifratura della memoria e l’isolamento hardware proteggono i dati in elaborazione, mentre l’attestazione verifica l’ambiente prima del rilascio di dati o chiavi. La scheda tecnica delle confidential VM, ancora riferita alla precedente anteprima, descrive l’isolamento anche rispetto all’hypervisor e agli amministratori dell’host; conserva però l’etichetta preview, mentre l’annuncio del 20 ottobre comunica il rilascio commerciale.
Azure Local supporterà anche la multitenancy: più ambienti potranno condividere l’infrastruttura mantenendo separate risorse, governance e gestione, con applicazioni per divisioni aziendali e operatori di servizi locali.
Sviluppo software e AI nel perimetro del cliente
Con GitHub Enterprise Local, il cui rilascio commerciale è previsto a Ignite, repository, codice e componenti dello sviluppo restano su Azure Local. Una procedura guidata prepara l’infrastruttura e l’appliance GitHub Enterprise Server attraverso Workload Orchestration; i segreti di distribuzione sono custoditi in Azure Key Vault. L’organizzazione mantiene le scelte su rete, sicurezza e configurazione.
L’aggiornamento specifico di GitHub Enterprise Local precisa le opzioni per l’assistenza AI. Con accesso internet autorizzato si può usare GitHub Copilot, che richiede identità GitHub.com e relativa licenza. Nei contesti disconnessi, Foundry Local esegue modelli approvati all’interno dell’infrastruttura del cliente, raggiungibili attraverso gli strumenti GitHub supportati. L’assistenza locale ha un proprio insieme di capacità, distinto dall’esperienza completa di Copilot basata sui servizi cloud: la formulazione generale dell’annuncio sui modelli locali va letta con questa distinzione.
Anche Foundry Local su Azure Local sarà disponibile commercialmente da Ignite per operazioni connesse e disconnesse, con un catalogo esteso a modelli Microsoft, dei partner, a pesi aperti e open source. Inferenza e recupero agentico delle informazioni permettono di interrogare in linguaggio naturale i dati aziendali locali e ottenere risposte fondate su quei contenuti.
Negli scenari AI del Sovereign Private Cloud, il recupero agentico combina ricerca nei dati, ragionamento in più passaggi e uso di strumenti. L’integrazione con Microsoft 365 Local, in anteprima per clienti approvati, estende l’interazione ai server SharePoint ed Exchange gestiti localmente: documenti, messaggi e informazioni delle riunioni possono alimentare le risposte mantenendo elaborazione e accesso ai contenuti nel perimetro controllato.
Il ruolo degli operatori europei
Ai modelli pubblico e privato si affiancano i National Partner Clouds, tra cui Bleu in Francia e Delos Cloud in Germania, con ambienti gestiti in modo indipendente e un diverso assetto proprietario e operativo. La specializzazione dei partner nella sovranità digitale riguarda la capacità di realizzare soluzioni sicure, conformi e governate localmente usando le tecnologie Microsoft.
L’ecosistema comprende fornitori software che completano Azure Local su sicurezza, identità, osservabilità, backup e ripristino, migrazione, dati, rete e applicazioni. I partner specializzati aggiungono competenze normative e settoriali locali, mentre quelli impegnati nella co-innovazione della piattaforma estendono la scelta dell’infrastruttura dal datacenter ai sistemi edge.
ECIPE: il paradosso della sovranità cloud, tra appalti nazionali e infrastrutture globali
Le politiche per la sovranità cloud possono consolidare mercati nazionali già chiusi alla concorrenza europea, lasciando intatte dipendenze tecnologiche dagli hyperscaler. È la tesi del rapporto Cloud Sovereignty and the Single Market: A Better Understanding of Government Procurement and National Cloud Technology Preferences, pubblicato nell’ottobre 2026 dallo European Centre for International Political Economy (ECIPE) e firmato da Matthias Bauer, Andrea Dugo, Fredrik Erixon, Dyuti Pandya ed Elena Sisto. Lo studio è stato realizzato con il sostegno di Microsoft, dichiarato nella pubblicazione.
Gli autori distinguono una sovranità funzionale, misurata sulla capacità del cliente di proteggere i dati, limitare l’esposizione giuridica, garantire la continuità e cambiare fornitore, e una sovranità industriale, che mira a rafforzare le imprese europee attraverso criteri di proprietà, origine e accesso al mercato. Il punto critico, per ECIPE, è che favorire un’impresa nazionale e aumentare il controllo effettivo del cliente sono obiettivi che possono divergere.
La sovranità del cliente dipende dalle scelte che può esercitare. Nella prospettiva funzionale adottata da ECIPE, l’amministrazione deve poter decidere chi accede ai dati, verificare le operazioni, mantenere i servizi attivi durante una crisi e sostituire una tecnologia o un fornitore. La varietà dell’offerta, la ridondanza e la possibilità concreta di migrare fanno quindi parte della sovranità. Ridurre i fornitori ammissibili può indebolire queste capacità anche quando l’obiettivo dichiarato è aumentare l’autonomia.
Le preferenze nazionali ostacolano la costruzione di un mercato europeo. Gli acquisti pubblici cloud esaminati dal rapporto si concentrano su fornitori del Paese dell’amministrazione acquirente, con una partecipazione transfrontaliera europea molto limitata. Questa struttura precede la diffusione delle politiche di sovranità, che secondo gli autori rischiano di consolidarla. Il problema industriale riguarda la possibilità delle imprese europee di crescere oltre il mercato domestico: requisiti e qualificazioni diversi in ogni Stato limitano la scala commerciale, rendono più onerosa l’espansione e riducono gli incentivi a investire in servizi utilizzabili nell’intera Unione.
La conseguenza individuata da ECIPE è che una politica concepita per rafforzare il cloud europeo può sostenere soprattutto operatori nazionali protetti. La presenza di più imprese europee, ciascuna concentrata sul proprio Paese, non produce automaticamente un’offerta capace di servire clienti in tutta l’UE. La dimensione del mercato accessibile conta per finanziare infrastrutture, competenze e sviluppo dei servizi.
I requisiti di sovranità possono consolidare gli operatori già affermati. Il rapporto associa i nuovi riferimenti alla sovranità a una partecipazione più ristretta alle gare e a un maggior peso degli affidamenti con un solo offerente. La questione riguarda anche i criteri che attribuiscono punteggio, capaci di orientare la competizione pur senza escludere formalmente i concorrenti. Nella lettura degli autori, una procedura aperta sulla carta può risultare difficilmente contendibile se i requisiti favoriscono pochi soggetti già inseriti nei sistemi nazionali di qualificazione.
Questo aspetto collega concorrenza e autonomia dell’acquirente: una scelta limitata fra servizi, architetture e operatori riduce anche le alternative disponibili per diversificare le dipendenze. La partecipazione di più imprese a un raggruppamento non risolve da sola il problema, perché un’offerta congiunta resta una sola proposta fra cui scegliere.
La nazionalità del contraente non descrive tutta la catena tecnologica. Un operatore locale può erogare il servizio attraverso infrastrutture, software e piattaforme di gruppi internazionali. Il rapporto richiama il Polo Strategico Nazionale italiano e modelli come Bleu e Delos, basati su tecnologie Microsoft, e S3NS, basato su Google Cloud. Questi assetti combinano responsabilità operative europee e tecnologie globali: il contratto con un soggetto nazionale lascia aperta la valutazione di chi controlla i diversi componenti e delle dipendenze che restano lungo la filiera.
È il paradosso della sovranità descritto da ECIPE: la selezione dei contraenti segue confini nazionali, mentre le piattaforme restano inserite in filiere globali. Per gli autori, la presenza di un hyperscaler può essere compatibile con una sovranità effettiva quando esistono controllo degli accessi, separazione operativa, continuità, verificabilità e protezioni giuridiche applicabili. La proprietà europea, a sua volta, richiede una verifica delle dipendenze infrastrutturali e software.
Il rischio di estendere il filtro di origine a tutta la filiera. I livelli più restrittivi della proposta Cloud and AI Development Act cercano di intervenire anche sul controllo dei fornitori, dei subfornitori e del software. ECIPE teme che un’applicazione troppo ampia escluda le combinazioni fra operatori europei e piattaforme internazionali già utilizzate per erogare servizi sovrani, restringendo l’offerta prima che esistano alternative adeguate. Ne deriverebbero meno possibilità di sostituzione e ridondanza, proprio mentre l’obiettivo della resilienza richiede di poter distribuire il rischio.
La proposta degli autori è sviluppare un modello aperto di partnership operativa: integratori, operatori cloud, imprese di cybersecurity e fornitori di servizi gestiti europei devono poter realizzare, controllare e verificare le garanzie di sovranità su più piattaforme, competendo nell’intero mercato unico. Il contributo industriale europeo comprende così la capacità di governare i servizi, proteggere i dati e assicurare continuità, oltre alla produzione della tecnologia sottostante.
Le cinque raccomandazioni sul Cloud and AI Development Act. Le proposte riguardano CADA, la proposta di regolamento europeo che collega livelli di garanzia della sovranità e acquisti pubblici. Gli autori contestano soprattutto l’impiego esteso dei livelli più restrittivi, nei quali assumono rilievo proprietà, controllo societario, personale e filiera software. Chiedono di riservare le condizioni più severe ai carichi effettivamente sensibili e critici.
Valutare le garanzie effettivamente dimostrabili. ECIPE individua quattro controlli da riconoscere come percorsi equivalenti o complementari per soddisfare i requisiti: chiavi crittografiche custodite dal cliente tramite gestione esterna; confidential computing con attestazione remota; accessi amministrativi approvati e registrati; residenza dei dati vincolante per contratto e verificabile tramite audit. I primi due consentono verifiche crittografiche, gli altri controlli indipendenti. L’obiettivo è permettere alle amministrazioni di scegliere, combinare e sostituire servizi sulla base delle protezioni offerte, mantenendo disponibili più fornitori e soluzioni di riserva.
Rendere vincolante la metodologia europea di valutazione del rischio. Secondo gli autori, la metodologia prevista dall’articolo 29 lascia agli Stati troppo margine per adottare interpretazioni diverse degli stessi livelli di garanzia. Le deviazioni dovrebbero essere motivate, pubblicate e limitate nel tempo. Un metodo comune dovrebbe valutare sensibilità dei dati, rischio di accessi illeciti, interruzioni e necessità di ricorrere a più fornitori; i requisiti più severi andrebbero circoscritti agli impieghi realmente critici. ECIPE propone anche un repertorio centrale, accessibile e aggiornato dei servizi riconosciuti, per rendere prevedibili acquisti e investimenti.
Stabilire un percorso prevedibile per il riconoscimento dei Paesi terzi. Per il meccanismo dell’articolo 18, il rapporto chiede criteri realistici e dimostrabili, una procedura di domanda con tempi definiti e motivazioni delle decisioni. L’adeguatezza della protezione dei dati e la reciprocità nell’accesso agli appalti costituiscono, nella lettura degli autori, basi utili. Il riconoscimento dovrebbe dare certezza agli operatori che investono in capacità cloud e AI in Europa, evitando che l’accesso al mercato dipenda da decisioni discrezionali imprevedibili.
Far valere il riconoscimento in tutto il mercato unico. Per ECIPE, il riconoscimento ottenuto nello Stato di stabilimento deve permettere di operare nell’intera Unione senza nuove condizioni nazionali aggiuntive. Gli autori chiedono una clausola esplicita che le impedisca e un meccanismo di revisione capace di contestare sia riconoscimenti troppo permissivi sia requisiti nazionali eccessivamente restrittivi. Chiedono inoltre un termine per le decisioni della Commissione sulle obiezioni, così da evitare ritardi indefiniti. L’effetto atteso è consentire a integratori, operatori cloud, imprese di cybersecurity e fornitori di servizi gestiti europei di competere oltre il proprio mercato nazionale.
Sottoporre l’eventuale estensione al privato alla procedura legislativa ordinaria. Il rapporto contesta la possibilità, prevista dall’articolo 31 della proposta, di rendere obbligatorie tramite atti delegati le valutazioni e le misure di mitigazione per soggetti privati dei settori ad alta criticità individuati dalla direttiva NIS2 sulla sicurezza informatica. Un ampliamento di questa portata dovrebbe, secondo ECIPE, passare attraverso una clausola di revisione, criteri chiari, una valutazione completa dell’impatto e il confronto fra i legislatori europei. La preoccupazione è che una riduzione dei servizi utilizzabili e dei fornitori ammissibili si trasferisca ai settori più critici dell’economia.
