Cloud sovrano: cosa significa davvero

“Cloud sovrano” è una delle espressioni più abusate degli ultimi due anni. Ogni hyperscaler americano ha annunciato la sua versione, ogni provider europeo evita di chiamarla così — e nel frattempo chi in azienda deve scegliere si ritrova quattro presentazioni al mese che promettono “sovranità europea dei dati” senza spiegare quale garanzia stia effettivamente comprando.

Non è solo marketing fumoso: può avere conseguenze legali concrete. Un trasferimento di dati dichiarato “sovrano” che invece ricade sotto il CLOUD Act statunitense può tradursi in un rischio GDPR da valutare e documentare, con possibili obblighi di notifica al Garante a seconda del caso. Vale quindi la pena dedicare mezz’ora a capire le tre categorie reali di cloud sovrano: cosa garantisce ciascuna e, soprattutto, cosa NON garantisce.

Da dove nasce la domanda

La spinta verso il “cloud sovrano” europeo viene da tre direzioni che si sono saldate negli ultimi anni:

1. Schrems II e le sue conseguenze. La Corte di Giustizia UE nel 2020 ha invalidato il Privacy Shield. L’EU-US Data Privacy Framework del 2023 ha riaperto il canale di trasferimento, ma è già oggetto di contestazioni. La direzione della giurisprudenza europea è chiara: chi tratta i dati deve poter giustificare con prove che i trasferimenti verso gli USA siano legittimi.
2. Il CLOUD Act statunitense (2018). Consente alle autorità USA di richiedere dati a un provider con sede legale negli Stati Uniti indipendentemente da dove i dati siano fisicamente memorizzati. AWS Frankfurt, Azure Italy North e GCP Milan sono operati da entità tipicamente riconducibili a società soggette al CLOUD Act, ma la struttura esatta va verificata sul singolo contratto.
3. NIS2 e DORA. Quando devi dimostrare resilienza operativa e controllo sul fornitore, un soggetto extra-UE esposto a giurisdizioni potenzialmente in conflitto con quella europea può diventare un punto interrogativo nel tuo risk assessment, a seconda di ruolo e settore. Se non sai bene cosa comporti la direttiva per una realtà media, vale la pena partire da cosa significa davvero la NIS2 per le PMI italiane.

Da queste pressioni nasce la domanda. Le risposte sul mercato sono tre, e fanno cose molto diverse.

Categoria A — Hyperscaler “EU region”

Cos’è: una regione cloud di un hyperscaler americano fisicamente localizzata in Europa. AWS eu-central-1 (Frankfurt), Azure West Europe (Amsterdam), GCP europe-west8 (Milano). Anche le “sovereign cloud” annunciate — come la AWS European Sovereign Cloud o la Azure EU Data Boundary — tendono a ricadere qui finché la società con cui firmi il contratto resta riconducibile alla casa madre americana; conviene comunque verificare la struttura contrattuale specifica.

Cosa garantisce:

• data residency fisica (i dati restano in Europa);
• conformità GDPR sul piano tecnico (cifratura, controllo degli accessi);
• certificazioni come ISO 27001, SOC 2, C5 (lo standard del BSI tedesco).

Cosa NON garantisce:

• esenzione dal CLOUD Act statunitense;
• protezione contro richieste di accesso fondate su norme extraterritoriali USA.

Quando va bene: la gran parte dei workload commerciali, dove nessun regolatore chiede esplicitamente l’assenza di esposizione extraterritoriale. PMI italiane standard, e-commerce, gran parte del SaaS B2B rivolto al mercato europeo.

Quando NON va bene: difesa, sanità pubblica con dati clinici sensibili, alcune PA con dati classificati, casi in cui un’autorità di vigilanza chiede esplicitamente “nessuna esposizione giuridica USA”.

Categoria B — Hyperscaler con partner europeo

Cos’è: un hyperscaler americano che fornisce la tecnologia a una società europea separata, controllata da un partner europeo o in joint venture. L’idea è interporre uno strato giuridico europeo tra il cliente e la casa madre americana.

I casi rilevanti:

• Bleu (Francia): joint venture Capgemini + Orange su licenza tecnologica Microsoft Azure. Il cliente firma con Bleu, società francese, che opera l’infrastruttura su data center francesi. Secondo il modello contrattuale dichiarato, Microsoft non dovrebbe avere accesso operativo né legale ai dati del cliente.
• S3NS (Francia): joint venture Thales + Google Cloud, modello analogo, rivolta a PA e settori regolamentati francesi.
• Delos Cloud (Germania): joint venture con Microsoft pensata per la PA tedesca.

In Italia il modello equivalente è meno maturo. Il Polo Strategico Nazionale (PSN) usa tecnologie di hyperscaler americani sotto governance italiana, all’interno di un framework di sicurezza nazionale che riduce l’esposizione, ma il quadro non è del tutto sovrapponibile al modello Bleu.

Cosa garantisce:

• sovranità giuridica: il contratto è con una società europea, in linea di principio soggetta alla sola giurisdizione europea; secondo il modello dichiarato la casa madre USA non dovrebbe avere accesso ai dati;
• sovranità operativa parziale: la gestione quotidiana è europea, anche se la tecnologia di base resta americana;
• conformità GDPR piena ed esposizione al CLOUD Act fortemente mitigata (non azzerata: una pressione indiretta della casa madre è teoricamente ipotizzabile, ma giuridicamente complessa).

Cosa NON garantisce:

• sovranità tecnologica: la tecnologia resta americana. Se un domani il licenziante decidesse di terminare l’accordo, la JV dovrebbe trovare un’alternativa. In pratica improbabile, ma il rischio strategico esiste. È esattamente lo scenario per cui conviene avere già pronto un piano d’uscita scritto prima di entrare.
• parità di funzionalità: i servizi più recenti dell’hyperscaler tendono ad arrivare nelle JV con ritardo (in diversi casi 12-24 mesi).
• prezzo competitivo: i costi sono spesso sensibilmente superiori all’hyperscaler nativo equivalente.

Quando va bene: PA, sanità con dati sensibili, energia, difesa non classificata — dove serve la conformità giuridica europea ma non si vuole rinunciare alla ricchezza dei servizi cloud moderni (database gestiti, AI managed, orchestrazione container di livello enterprise).

Quando NON va bene: workload classificati o ad alto valore strategico nazionale, dove il rischio che la casa madre possa “sganciarsi” non è accettabile.

Categoria C — Cloud europeo nativo

Cos’è: provider cloud con tecnologia, capitale, sede legale e operatività interamente europei. Sotto la giurisdizione di uno o più Stati UE, in linea di principio senza esposizione extraterritoriale.

Una lista realistica per workload aziendali:

• OVHcloud (Francia)
• Aruba Cloud (Italia, con qualificazione ACN per diversi scenari PA)
• Seeweb (Italia, gruppo DHH)
• Hetzner (Germania)
• Scaleway (Francia, gruppo Iliad)
• IONOS (Germania)

Cosa garantisce (in generale, da verificare caso per caso):

• giurisdizione interamente europea, in linea di principio niente esposizione strutturale al CLOUD Act;
• assenza di legami capitalistici extra-UE che possano forzare l’accesso ai dati;
• contesto operativo che facilita una conformità GDPR meno acrobatica rispetto agli hyperscaler;
• in Italia, percorsi di qualificazione ACN (Agenzia per la Cybersicurezza Nazionale) per gli scenari PA, utili in diversi bandi.

Cosa NON garantisce:

• parità di funzionalità con AWS/Azure/GCP: meno servizi gestiti esotici, AI managed più limitata, marketplace ed ecosistema partner più ristretti;
• copertura geografica globale (se servi clienti in USA o in Asia, probabilmente ti serve un secondo provider);
• abbondanza di competenze sul mercato del lavoro: molti più tecnici conoscono AWS che non OVH o Seeweb.

Quando va bene: PA, sanità, settori regolamentati, workload con dati sensibili, e tutti i casi in cui la sovranità è essa stessa un argomento commerciale — ad esempio quando vendi a clienti che pretendono hosting esclusivamente europeo.

Quando NON va bene: workload con utenti distribuiti su più continenti, prodotti fortemente dipendenti dai servizi AI degli hyperscaler, e-commerce che richiede una CDN globale capillare.

La tabella decisionale

Esigenza	Cat. A (EU region)	Cat. B (JV)	Cat. C (nativo)
Compliance GDPR standard	✅	✅	✅
Niente CLOUD Act	❌	⚠️ (mitigato)	✅
Funzionalità sempre aggiornate	✅	⚠️ (12-24m ritardo)	❌
Copertura globale	✅	⚠️ EU+	❌
Prezzo competitivo	✅	❌	✅
OK per PA con dati classificati¹	❌	❌	⚠️ caso per caso
DevOps moderno e maturo	✅	✅	⚠️

¹ I dati classificati non si gestiscono per categoria di provider, ma per accreditamenti specifici (qualificazione ACN per la PA, requisiti di sicurezza nazionale, certificazioni di settore). Anche un cloud nativo europeo va valutato sul singolo accreditamento, non sulla bandiera.

Un’avvertenza che vale per tutte e tre le categorie: la sovranità del provider non sostituisce la tua responsabilità sui dati. Anche sul cloud più europeo del mondo, il backup dei tuoi SaaS resta una cosa che devi fare tu, perché cestino e versioning non proteggono da errori umani e ransomware.

E GAIA-X? Perché finora non ha spostato un’azienda

GAIA-X è il progetto europeo lanciato nel 2019 per standardizzare interoperabilità e regole di sovranità tra provider cloud europei. Diversi anni dopo è soprattutto un’associazione, non un’infrastruttura: ha prodotto specifiche, gruppi di lavoro e molti interventi a convegni. Non ha prodotto un cloud su cui un’azienda media possa migrare il proprio ERP.

Non è un fallimento totale. GAIA-X funziona come framework di certificazione: il suo “Trust Framework” permette a un cliente di valutare se un provider rispetta certi criteri di trasparenza e portabilità. Lo usano alcuni progetti PA tedeschi e francesi. Per la PMI italiana standard, però, resta sostanzialmente invisibile: un’etichetta di conformità in più, utile in qualche bando, irrilevante per la decisione tecnica quotidiana.

Cosa fare se ti hanno proposto “cloud sovrano”

Tre domande da mettere sul tavolo del commerciale, in quest’ordine:

1. “Con quale società firmiamo il contratto, e a quale giurisdizione è soggetta?” Se la risposta è una sussidiaria europea di una parent USA, probabilmente sei in categoria A. Se è “Bleu SAS” o “OVHcloud SAS”, sei rispettivamente in B o C.
2. “Il gruppo ha una controllante o un titolare effettivo con sede negli USA, nel Regno Unito, in Cina, in India o in altre giurisdizioni extra-UE?” Se sì, chiedi la documentazione su come gestiscono le richieste extraterritoriali di accesso ai dati.
3. “Se un’autorità di vigilanza mi chiede di dimostrare l’assenza di esposizione al CLOUD Act, cosa mi fornite?” La risposta a questa domanda aiuta a separare il marketing dalle garanzie reali.

Se le risposte sono evasive, è ragionevole trattare il servizio come categoria A, indipendentemente da cosa dice la brochure. Queste tre domande, peraltro, sono lo stesso nucleo che dovresti portare al tavolo in un audit ai fornitori da inserire al rinnovo del contratto: la sovranità è solo una delle clausole su cui hai diritto a visibilità.

Cosa fare lunedì mattina

Apri il registro dei tuoi fornitori cloud. Per ognuno, annota la categoria reale (A/B/C) sulla base delle tre domande qui sopra. Poi incrociala con la classificazione di sensibilità dei dati che ci fai girare.

Se trovi un workload con dati personali sensibili o soggetto a vincoli stringenti ospitato su un fornitore di categoria A, e nessuno l’ha mai documentato come “rischio accettato consapevolmente”, probabilmente hai la prima conversazione da portare al prossimo confronto sui rischi. Non significa migrare tutto domani: significa sapere dove sei.

E qui la buona notizia per una PMI italiana è che spesso non sei costretto a scegliere tra la potenza degli hyperscaler e la tranquillità giuridica di un provider europeo. Esistono system integrator italiani capaci di disegnare architetture miste — i dati sensibili in casa o su cloud nativo europeo, il resto dove conviene — e di farlo con clausole contrattuali pensate per reggere davanti a un’autorità di vigilanza. Lo stesso vale per l’AI: se ti serve sfruttare i modelli senza esporre i dati, puoi guardare a un’enclave AI portabile che tiene i dati in Europa. Spesso è un lavoro di mezza giornata di analisi, non un progetto da un anno. Te lo dico io.