Quando ho configurato per la prima volta l’infrastruttura cloud di una piccola PMI nella Lombardia nel 2024, il CTO mi ha chiesto: «Dario, i nostri dati sono in Frankfurt con AWS, giusto? Allora siamo in compliance con GDPR.» Ho dovuto spiegare il problema che oggi nel 2026 è diventato la questione centrale della sovranità digitale europea: data residency e data sovereignty sono due cose completamente diverse.
In questo articolo, affrontiamo la valutazione comparativa tra sovereign cloud infrastructure e hyperscaler, il ruolo dell’EU Data Residency, la portabilità dati, i rischi geopolitici e come il framework NIS2 sta cambiando le carte in tavola per gli hoster europei nel 2026.
Che cosa significa veramente Sovereign Cloud nel 2026?
Data sovereignty significa che i dati sono soggetti alle leggi e alle strutture di governance della giurisdizione in cui vengono raccolti, archiviati ed elaborati, e l’organizzazione che li controlla mantiene diritti esecutivi su accesso, utilizzo e movimento, ed è distinta da data residency, che affronta solo dove i dati sono fisicamente archiviati.
Nel mio lavoro quotidiano su Plesk, vedo hosting provider che confondono sistematicamente questi due concetti. Nella pratica:
- Data Residency: I dati si trovano fisicamente in un data center europeo (es. Francoforte). È un requisito geografico.
- Data Sovereignty: Chi ha il potere legale di accedere ai dati, quale giurisdizione governa i sistemi, se l’organizzazione mantiene controllo operativo quando le condizioni geopolitiche cambiano. È un requisito legale e operativo.
Il problema è il CLOUD Act statunitense. La legge CLOUD Act statunitense consente alle autorità statunitensi di costringere i provider cloud incorporati negli Stati Uniti a consegnare dati archiviati ovunque nel mondo, inclusi nei data center dell’UE, il che significa che le imprese europee che archiviavano dati con provider a sede statunitense — anche in zone di disponibilità dell’UE — potrebbero ancora affrontare l’esposizione al CLOUD Act.
Il divario fatale: Residency vs Sovereignty in azione
Nel 2026, la maggior parte delle imprese europee ha risolto il problema della data residency — una questione diversa e più ristretta — e data sovereignty non riguarda dove si trovano i dati, ma chi ha l’autorità legale di costringere l’accesso ad essi, quali leggi governano i sistemi che li elaborano, e se l’organizzazione mantiene controllo operativo significativo quando le condizioni politiche o legali cambiano.
Ho visto questa dinamica giocarsi su hosting cloud multi-tenant:
- Una banca olandese utilizza AWS eu-central-1 in Germania con encryption BYOK.
- GDPR? Soddisfatto (trasferimenti standard con SCC).
- NIS2? Creato, perché i dati rimangono nell’UE.
- Sovranità? No. AWS è una società statunitense. Se il Dipartimento di Giustizia USA emette una richiesta CLOUD Act, AWS deve consegnare i dati, indipendentemente da dove si trovano fisicamente.
Questo non è teorico. Le multa cumulative GDPR hanno raggiunto 7,1 miliardi di euro, con violazioni di trasferimento dati che rimangono un’area di enforcement ad alto rischio, e il framework Privacy Framework del 2026 di Microsoft riconosce che non può fornire una garanzia assoluta che i dati dell’UE non saranno mai richiesti dalle autorità statunitensi.
I tre livelli di sovereign cloud nel 2026
Gli analisti inquadrano la sovranità su quattro dimensioni: territoriale (dove risiedono fisicamente dati e calcolo), operativa (chi li gestisce e protegge), tecnologica (chi possiede lo stack sottostante e la proprietà intellettuale), e legale (quale giurisdizione governa accesso e compliance).
Ho costruito una matrice di valutazione con cui lavoro quando confronto architetture:
Tier 1: Hyperscaler EU Region (il minimo assoluto)
I dati sono fisicamente ospitati in-region su un hyperscaler statunitense, soddisfacendo requisiti di residency, ma questo è il tier più basso: affronta la posizione fisica ma non l’isolamento legale, poiché il provider rimane soggetto a giurisdizione straniera.
Esempio: AWS eu-central-1, Azure West Europe, Google Cloud Europe-west1.
Tier 2: EU-Incorporated Provider (il minimo per la sovranità vera)
I dati sono elaborati da un’entità legale locale su infrastruttura che opera o contratta all’interno della giurisdizione, il CLOUD Act non si applica, e gli obblighi di conformità diventano diretti — questo è il soglia minima che la maggior parte degli acquirenti regolati intendono quando dicono «sovereign cloud».
Nel mio lavoro su infrastrutture eteronee, Tier 2 è dove i miei client regolati (banche, healthcare, governo) iniziano a sentire davvero di avere controllo.
Esempio: OVHCloud (Francia), Hetzner (Germania), IONOS (Germania), Scaleway (Francia), UpCloud (Finlandia) — UE-headquartered, UE-jurisdictioned, nessuna esposizione al CLOUD Act.
Tier 3: Air-Gapped o On-Premises (isolamento totale)
Il modello, l’infrastruttura di inference, e tutta l’elaborazione dei dati girano all’interno del perimetro dell’acquirente, completamente disconnesso da cloud esterni.
Raro per la maggior parte delle PMI, ma vedo questo in difesa, agenzie di intelligence, e infrastrutture critiche nazionali.
GAIA-X e il framework europeo per la sovranità del cloud
Gaia-X — l’iniziativa cloud sovrana dell’Europa — ha raggiunto più di 400 provider di servizi certificati nel 2025, creando l’ecosistema cloud sovrano più grande a livello globale, fornendo un framework per servizi cloud interoperabili e conformi a GDPR governati interamente dal diritto dell’UE.
Nel 2026, GAIA-X non è più uno slogan. È diventato concreto:
- Il Cloud Sovereignty Framework stabilisce una definizione strutturata e operativa della sovranità per i servizi cloud acquistati dalle istituzioni dell’UE, completando gli schemi di sicurezza e certificazione esistenti introducendo obiettivi di sovranità specifici che coprono autonomia strategica, controllo legale e giurisdizionale, governance dei dati e dell’IA, resilienza operativa, trasparenza della supply chain, apertura tecnologica, e conformità alla legge dell’UE.
- Label Level 3 si estende più chiaramente in sovranità dei dati e dell’IA, sovranità operativa, e sostenibilità ambientale.
Ho lavorato con provider che affrontano il processo GAIA-X Label Level 3. È rigoroso: richiede proprietà 100% europea, staff operativo solo europeo, nessuna affiliazione azionaria con entità non europee.
Il ruolo cruciale di NIS2 nella scelta dell’hosting
NIS2 estende gli obblighi di cybersecurity attraverso infrastrutture critiche e fornitori di servizi digitali, mandando gestione robusta dei rischi, segnalazione di incidenti entro 24 ore, e sicurezza della supply chain, con carichi di lavoro cloud che gestiscono dati di infrastrutture critiche che ora comportano requisiti di audit e protezione espliciti.
Nella pratica con Plesk e infrastrutture multi-tenant:
- NIS2 copre 18 settori critici oltre a energy, transport, healthcare, finance, water management, digital infrastructure — provider di comunicazioni elettroniche pubbliche, più servizi digitali (come piattaforme sociali), gestione rifiuti e acque reflue, manifattura di prodotti critici, servizi postali e corrieri, pubblica amministrazione a livello centrale e regionale, e settore spaziale.
- NIS2 non riguarda direttamente il mandato di residency dati, ma richiede gestione dei rischi della supply chain — se la giurisdizione del provider cloud introduce rischi legali, questo è un rischio della supply chain che devi valutare e documentare.
Per i miei client in settori NIS2-regolati (healthcare, energia), la scelta dell’hosting non è più solo una decisione tecnica. È una decisione di conformità normativa.
La portabilità dati: l’arma segreta del 2026
L’EU Data Act è pienamente applicabile da settembre 2025 — e riconfigura radicalmente l’equilibrio di potere tra provider cloud e clienti, permettendo ai clienti di terminare contratti cloud con solo due mesi di preavviso, fino a gennaio 2027 è possibile addebitare solo i costi di switching diretti, e da gennaio 2027 nessuna commissione di switching.
Ho già visto hyperscaler che cercano di aggirare questo:
- Le sovereign cloud degli hyperscaler mantengono le stesse dipendenze tecniche sottostanti, strutture di pricing, e rischi di vendor lock-in delle loro offerte standard — adottarne una è simile ad adottare un provider completamente nuovo, isolato per design.
I provider cloud devono eliminare le commissioni di switching entro 2027 e supportare formati di export standardizzati e API, supportando direttamente i requisiti di trasparenza e verificabilità dell’AI Act, con sviluppatori di AI che hanno bisogno di log verificabili di dove risiedono i dati, come si muovono, e se sono conformi ai standard dell’UE — i vendor cloud che non forniscono percorsi di migrazione puliti e verificabili espongono i clienti ai rischi di conformità dell’AI Act.
Dal punto di vista dell’hosting: L’EU Data Act aggiunge requisiti di portabilità dei dati per i servizi cloud — i provider devono offrire strumenti per export dati e switching, e strategie di lock-in che impediscono la migrazione sono ora regolate.
AWS European Sovereign Cloud: L’esperimento del 2026
AWS European Sovereign Cloud è diventato operativo a gennaio 2026 con la sua prima regione a Brandeburgo, Germania, gestita da staff residente in UE sotto un’entità legale AWS separata.
Ma qui è dove AWS ha strutturato come GmbH tedesco indipendente, con esecutivi a base UE — ma la società madre rimane statunitense e il CLOUD Act ancora si applica.
Ho parlato con due CIO che hanno adottato AWS ESC per workload NIS2-regulated:
- Vantaggio: Familiarità con AWS; transizione tecnica senza attrito; il 90% del catalogo di servizi è disponibile come in Standard AWS.
- Svantaggio: Rimane un guardrail model, non isolamento completo. La giurisdizione finale è ancora negli Stati Uniti. E, per l’onestà, il prezzo è più alto del 25-30% rispetto a EU-native per la stessa capacità.
La realtà economica: il costo della sovranità
La spesa in Sovereign Cloud IaaS raggiunge $80 miliardi a livello globale nel 2026, con l’Europa che rappresenta 12,6 miliardi di euro, e entro 2027, il mercato europeo triplica e sorpassa il Nord America (Gartner, febbraio 2026).
Nel mio stack tecnico (Plesk multi-tenant, Elastic per observability, stack LAMP su OVHCloud regionale), vedo questa dinamica di prezzo:
- Hyperscaler EU Region: €0,12/GB/mese (compute), elasticity, global tooling.
- EU-Native (Hetzner, OVHCloud): €0,04-0,07/GB/mese, meno managed services, ecosistema più stretto.
- AWS/Azure Sovereign Variant: €0,15-0,18/GB/mese, guardrails, ma CLOUD Act exposure residua.
La vera lotta non è il prezzo assoluto. È il mercato sovereign cloud cresce al 27% annuale perché il problema è reale e il costo dell’inazione sta salendo.
I rischi geopolitici che nessuno vuole affrontare
Nel 2026, il contesto geopolitico ha accelerato la migrazione verso la sovranità:
- Airbus ha emesso una gara a dicembre 2025 per migrare sistemi mission-critical verso un cloud europeo sovrano: un contratto da oltre 50 milioni di euro, con durata decennale, a partire da gennaio 2026.
- Lo Schleswig-Holstein ha migrato 40.000 account email da Microsoft Exchange/Outlook a Open-Xchange/Thunderbird, e le Forze Armate tedesche hanno sottoscritto un contratto settennale con ZenDiS per openDesk (come sostituto di Microsoft 365).
Il messaggio è chiaro: I provider statunitensi sono partner benvenuti nell’economia cloud e dati dell’Europa — ma sono incapaci di fornire il tipo di sovranità digitale che l’Europa vuole ora per i suoi workload più sensibili, e il livello più elevato di sovranità per i clienti finali europei può essere fornito solo da provider con quartier generale in Europa.
Strategie pratiche per le PMI e gli hoster: La mia approach nel 2026
Ho sviluppato un framework di valutazione a tre strati per i miei client su Plesk:
Workload Classification
- Tier A (Sensibilità massima): Dati personali dei cittadini UE, dati finanziari soggetti a DORA, dati sanitari. → Full EU Isolation obbligatorio; nessun variante sovrana dell’hyperscaler.
- Tier B (Business standard): Compute SaaS, tooling interno, dati cliente B2B. → EU-native preferito; ibrido con hyperscaler accettabile dove non esiste equivalente EU-native.
- Tier C (Bassa sensibilità): CDN pubblico, training AI globale, CI/CD tooling. → Hyperscaler accettabile; prioritize EU-native dove disponibile.
Certifications That Matter in 2026
- SecNumCloud 3.2 (settore pubblico francese, healthcare, difesa-adiacente): Outscale.
- BSI C5 Tipo 2 (governo federale tedesco, healthcare tedesco): Open Telekom Cloud, STACKIT.
- GAIA-X Label Level 3 (sovranità totale): Cloud Temple, STACKIT, OVHCloud (progressivamente).
Multi-Cloud Hybrid (la realtà pragmatica del 2026)
Non ho mai consigliato un hyperscaler exit completo. Piuttosto:
- Regulated/Sensitive Workload: EU-native (Hetzner, OVHCloud).
- Scale-Dependent Workload (ML training, global CDN): Hyperscaler EU region.
- Development/CI/CD: Dove tecnicamente opportuno, con data governance chiara.
Metriche di conformità per Hosting Provider nel 2026
Ho creato una checklist che uso quando valuto provider per i miei client:
- ✅ Data Residency: Tutte le copie di dati vivono in una geografia specifica? Documentato nei SLA?
- ✅ Jurisdictional Control: Chi ha il potere legale di accedere ai dati? Quale tribunale ha autorità finale?
- ✅ Encryption & Key Management: BYOK disponibile? Customer-managed HSM?
- ✅ Data Portability: Export in standard format? Tempo di migrazione promesso?
- ✅ Supply Chain Transparency: Subcontractors europei? Third-party risk assessment?
- ✅ NIS2 Readiness: Audit trail documentati? Incident reporting process?
- ✅ GAIA-X Alignment: Label certification? Roadmap?
FAQ
1. AWS EU Region è sovrano per GDPR?
No. AWS eu-central-1 in Francoforte soddisfa data residency, ma non data sovereignty. AWS è una società statunitense; il CLOUD Act si applica ancora. Per data sovereignty vera, hai bisogno di un provider incorporato nell’UE (Tier 2) o isolamento completo (Tier 3).
2. Quando ha senso pagare il premium per AWS/Azure Sovereign Variants?
Quando il tuo stack tecnico è profondamente accoppiato a proprietà AWS/Azure e la migrazione a EU-native richierebbe rearchitecture significativa. Il 25-30% premium potrebbe essere inferiore al costo della migrazione tecnica. Ma è un compromesso temporale, non una soluzione a lungo termine.
3. GAIA-X Label significa automaticamente NIS2-compliant?
No. GAIA-X certifica portabilità dati e interoperabilità. NIS2 riguarda cybersecurity risk management e incident reporting. Sono complementari, non sinonimi. Hai bisogno di entrambi per workload NIS2-regulated.
4. Quale è il miglior EU-native provider per le PMI nel 2026?
Dipende dal workload:
– General-purpose compute/storage: Hetzner (prezzo), OVHCloud (scale), Scaleway (developer-friendly).
– Regulated sectors (healthcare): Open Telekom Cloud, STACKIT.
– Full sovereignty mandate: Cloud Temple, Outscale (SecNumCloud).
Nessuno eguaglia AWS in breadth di managed services. Ma per Tier A workload, Tier B, non devi.
5. L’EU Data Act ha davvero messo fine al vendor lock-in?
Non del tutto. Ha imposto obblighi contrattuali e legali di portabilità. Ma la realtà tecnica rimane: migrare da AWS Lambda a OVHCloud Cloud Function è ancora un rework architetturale. L’EU Data Act ha reso il diritto legale chiaro; reso il percorso tecnico ancora economicamente difficile.
Conclusione: La sovranità non è un’opzione, è una strategia
Nel 2026, la Sovereign Cloud non è più un argomento di marketing — è una decisione seria con peso normativo, tecnico ed economico.
Nel mio lavoro quotidiano come System Administrator e specialist di hosting su Plesk, Linux, e infrastrutture multi-tenant, vedo questa transizione in tempo reale. I miei client che hanno:
✅ Classificato i workload chiaramente
✅ Scelto provider eurepei per Tier A
✅ Mantenuto hyperscaler per scale
✅ Implementato GAIA-X alignment
✅ Documentato il tutto per NIS2
… sono quelli che dormono tranquilli quando i loro auditor regolatori arrivano.
Quelli che ancora pensano che “data in Francoforte = sovranità” non lo sono.
La sovranità digitale nel 2026 non è sulla cartografia dei data center. È sulla cartografia del potere legale, del controllo operativo, e della capacità di agire quando l’ambiente geopolitico si sposta. Costruisci per quello.
Se stai valutando una migrazione verso sovereign cloud per la tua infrastruttura o quella dei tuoi clienti, commenta qui sotto: qual è il tuo scenario più complicato? Sono curioso di sentire come gli hoster e i CIO stanno navigando questa transizione in pratica.