Sovereign cloud in Europa: la residenza non è la stessa cosa della giurisdizione.

Questa pagina rappresenta la prospettiva ingegneristica. Se il tuo DPO, il tuo auditor o un gate di procurement ti sta chiedendo cosa significhi davvero "sovrano" nel 2026, questa è la versione che regge sotto esame.

Residenza vs sovranità: la distinzione che decide tutto

L'industria del cloud ha impiegato quindici anni ad addestrare gli acquirenti a porre la domanda sbagliata. "Dove sono ospitati i dati?" è una domanda sulla residenza. La risposta può essere tecnicamente corretta e legalmente irrilevante allo stesso tempo, perché la sovranità non riguarda la geografia. Riguarda quali tribunali possono obbligare un provider ad agire.

Una region UE su un hyperscaler statunitense, come AWS Frankfurt, Azure West Europe o GCP Belgium, mantiene i dati nella UE. Non sottrae la società madre alla giurisdizione statunitense. In base al US CLOUD Act (2018), un provider con sede negli USA può essere obbligato a divulgare i dati dei clienti ovunque siano conservati nel mondo, incluse le region UE. Il FISA 702 impone la stessa esposizione sul fronte della sorveglianza. L'European Data Protection Board ha segnalato esplicitamente questo come un problema Schrems II.

"Sovrano" significa quindi tre cose concrete, tutte insieme:

1. L'entità legale che detiene i tuoi dati non ha una società madre in un paese terzo con leggi extraterritoriali sulla divulgazione dei dati.
2. Nessun subprocessor nel percorso dei dati si trova in un paese simile.
3. Tu, non il provider, controlli le chiavi di crittografia, oppure le chiavi risiedono presso un custode al di fuori del paese terzo.

Se superi tutti e tre i test hai sovranità. Se ne fallisci anche solo uno, hai residenza. La terminologia nel tuo DPA, nella tua privacy policy e nelle pagine rivolte ai clienti dovrebbe riflettere quale delle due sia realmente.

Perché "filiale UE" non è la risposta

Una soluzione comune proposta dagli hyperscaler statunitensi è la struttura della filiale UE. Microsoft Ireland, AWS EMEA SARL, Google Cloud EMEA Ltd. L'argomentazione è che l'entità europea sia la controparte contrattuale ai sensi del diritto UE.

Questo non risolve il problema giurisdizionale. Ai sensi del CLOUD Act, il test non riguarda quale filiale abbia firmato il contratto. Riguarda se la società madre ha "possesso, custodia o controllo" dei dati. Una filiale UE interamente controllata è, per definizione, sotto il controllo della società madre. L'analisi della CGUE e dell'EDPB nel caso Schrems II considera l'esposizione della società madre come quella determinante.

Quindi quando un vendor offre un piano "europeo" gestito da una filiale UE di un gruppo statunitense, la domanda giusta da porre è: "La vostra società madre statunitense può essere obbligata a istruirvi affinché divulghiate dati senza il nostro consenso o la nostra conoscenza?" La risposta onesta è sì.

Il livello intermedio pseudo-sovrano

Dal 2024 al 2026 si è assistito a un'ondata di partnership "sovrane" annunciate, tipicamente un systems integrator europeo che concede in licenza lo stack tecnologico di un hyperscaler statunitense e lo gestisce sotto management europeo. Esempi sul mercato oggi:

• Offerte sovrane su licenza, costruite sulla tecnologia di un hyperscaler statunitense, gestite da una sussidiaria di Europeane Telekom.
• Bleu, un cloud sovrano francese costruito sulla tecnologia Microsoft Azure, gestito da Capgemini e Orange.
• S3NS, una joint venture tra Thales e Google in Francia.

Queste offerte possono essere utili per specifici regimi di conformità, ma non sono ciò che un team di ingegneria dovrebbe definire sovrano senza qualificazioni. Lo stack tecnologico, gli aggiornamenti della piattaforma, le patch di sicurezza e, cosa cruciale, il know-how operativo provengono dal partner statunitense. Nello scenario di minaccia peggiore, in cui la parte statunitense ritira la cooperazione o è costretta a farlo, l'operatore europeo eredita uno stack che non è in grado di mantenere in modo indipendente.

Per la maggior parte dei buyer, la risposta architetturale più pulita è costruire su un'infrastruttura priva di qualsiasi dipendenza dagli USA nella supply chain. È questo che intendiamo quando parliamo di stack sovrano in Binadit.

Come si presenta realmente uno stack sovrano EU

Ecco un'architettura di riferimento concreta per un workload SaaS mid-market o regolamentato che opera interamente sotto giurisdizione EU. Nessuno di questi elementi è esotico; sono tutti production-grade.

• Compute e storage: compute gestito Binadit e hardware dedicato, su infrastruttura UE sotto giurisdizione UE.
• Object storage: Ceph o MinIO, compatibili S3, gestiti da noi sulla stessa infrastruttura.
• CDN: Bunny.net (SI), KeyCDN (CH), oppure gestito autonomamente all'edge per il pieno controllo.
• DNS: PowerDNS o Knot, autoritativo e firmato DNSSEC, oppure Bunny DNS dove lo si vuole integrato con il CDN.
• Consegna email: Mailgun EU (con cautela, a causa della società madre statunitense), oppure opzioni interamente UE come Postmark EU, Mailpace, Tuta business, o Postfix self-hosted sulla stessa infrastruttura.
• Error tracking: GlitchTip o Sentry self-hosted, oppure il deployment nella regione UE di Sentry con i compromessi documentati.
• Analytics: Plausible (hosting in UE), Matomo (self-hosted o cloud UE), Pirsch.
• Observability: Prometheus + Grafana + Loki self-hosted, oppure equivalenti gestiti nella UE (Grafana Cloud EU, Last9 con region EU).
• Gestione delle chiavi: Hashicorp Vault su infrastruttura UE, oppure provider KMS gestiti in UE; per scenari ad alta fiducia, HSM on-premises con BYOK lato cloud.
• CI/CD: GitLab self-hosted, Forgejo, Gitea, oppure l'istanza GitLab.com UE. Mai il default github.com per codice che tratta dati personali senza misure supplementari.

Il punto non è che una di queste sia "la" risposta. Il punto è che l'intero stack può essere assemblato con provider con sede in UE, e un partner di infrastruttura gestita può gestirlo per te allo stesso modo in cui un partner AWS-native gestirebbe AWS.

Il test delle quattro domande, nel dettaglio

1. Residenza: dove, esattamente

Non "nell'EU" ma quale datacenter, in quale paese, sotto quale giurisdizione. L'EU non è un unico regime giuridico; il GDPR è armonizzato ma l'autorità di controllo è locale, così come il rimedio legale in caso di inadempienza del provider. Documenta il codice del paese per le location primaria, secondaria e di backup nel tuo DPA.

2. Subprocessor: ognuno di essi

Nei nostri audit di ambienti mid-market, la catena di subprocessor non mappata è il riscontro più comune in assoluto. L'applicazione è su infrastruttura EU, il che è positivo. Ma l'API di ottimizzazione immagini che richiama è ospitata negli USA. L'email transazionale viene inviata tramite un ESP statunitense. L'error tracker è quello predefinito USA. Il widget di customer support carica JavaScript da un CDN statunitense. Ognuno di questi è un flusso di dati separato. Ognuno richiede una base giuridica se i dati vengono trasferiti verso un paese terzo.

Uno stack sovrano richiede un elenco completo dei subprocessor, incluse le API di terze parti utilizzate dalla vostra applicazione e non solo i provider di infrastruttura. Il nostro è indicato per intero nel data-processing agreement, e lo inviamo prima che firmiate qualsiasi cosa.

3. Giurisdizione: chi può imporre la divulgazione

La domanda sul processo legale. Per ciascuna entità nel tuo percorso dei dati, identifica la sede della società madre. Se una qualsiasi società madre si trova negli USA, in Cina, in Russia o in un altro paese con leggi extraterritoriali sull'accesso ai dati, quell'entità è esposta. Lo status di filiale UE di una società madre statunitense non risolve il problema.

È qui che il diagramma architetturale diventa un documento legale. Disegnalo una volta, rivedilo trimestralmente.

4. Custodia delle chiavi: chi può tecnicamente leggere i dati

La crittografia at rest è necessaria ma non sufficiente. La domanda è chi detiene le chiavi. Le chiavi gestite dal provider non offrono alcuna protezione contro l'obbligo del provider di decrittografare i dati. BYOK (Bring Your Own Key) aiuta la narrativa di compliance; il provider mantiene comunque una copia a runtime. HYOK (Hold Your Own Key) è l'unico modello in cui il cloud provider non può fisicamente leggere i dati senza una chiamata attiva al vostro key custodian. Scegliete il modello richiesto dal threat model.

Il percorso di migrazione: da AWS Francoforte a uno stack sovrano

Il timore di abbandonare un hyperscaler è di solito più grande del progetto reale. Una tipica migrazione mid-market si svolge in tre fasi:

1. Inventario e audit (1-2 settimane). Mappare ogni flusso di dati, identificare ogni subprocessor, classificare per esposizione statunitense. Output: una lista di remediation classificata per rischio e complessità di migrazione.
2. Rimozioni a basso impatto (2-4 settimane). Sostituire prima le dipendenze secondarie: error tracking, analytics, CDN, DNS, email. Questi cambiamenti richiedono poche o nessuna modifica all'applicazione.
3. Migrazione core (4-8 settimane). Compute, storage, database. Usare la replica in streaming per spostamenti del database a downtime zero; usare pattern blue-green o DNS-failover a livello applicativo. La parte difficile raramente è la tecnologia. È la coreografia.

Tempo totale trascorso per un team di ingegneria di 6-8 persone che lo fa oltre al proprio lavoro quotidiano: dieci a sedici settimane. Con un partner di infrastruttura gestita a guidare la migrazione, quattro a dodici. La differenza di costo tra l'esecuzione dello stack sovrano e quella dell'hyperscaler è, nella nostra esperienza, neutra o negativa per i workload prevedibili, moderatamente più alta per i workload irregolari, e significativamente più bassa una volta considerati egress e larghezza di banda.

"Il cloud sovrano è più costoso?" La risposta onesta

Per l'80% dei workload mid-market, lo stack sovrano è più economico su un orizzonte di cinque anni, principalmente perché i provider europei non applicano fee di egress punitive e perché il pricing dedicated e bare-metal è nettamente migliore rispetto ai tipi di istanza equivalenti degli hyperscaler. I casi in cui lo stack sovrano risulta più costoso sono: workload fortemente bursty che beneficiano di autoscaling sub-secondo, workload che dipendono da uno specifico servizio managed (DynamoDB, BigQuery, Lambda) privo di un equivalente diretto, e workload di training ML che richiedono una specifica generazione di acceleratori.

Una revisione tecnica competente vi dirà in una settimana in quale categoria vi trovate. Se ne desiderate una, è il nostro lavoro.

Spinta normativa: NIS2, DORA, EHDS e AI Act

La direzione normativa fino al 2025-2027 va verso una maggiore responsabilità della supply chain:

• NIS2 (Articolo 21): le entità essenziali e importanti devono condurre valutazioni del rischio della supply chain e trasferire contrattualmente gli obblighi di sicurezza ai subprocessor. Un subprocessor sotto giurisdizione statunitense è difficile da difendere in questa valutazione senza misure supplementari.
• DORA (in vigore da gennaio 2025): le entità finanziarie devono mantenere un registro dei fornitori ICT terzi e una strategia di uscita per i fornitori critici. Il linguaggio sul rischio di concentrazione è esplicitamente rivolto alla dipendenza da fornitori dominanti non UE.
• European Health Data Space (EHDS): l'uso secondario dei dati sanitari è limitato ad ambienti di elaborazione sotto giurisdizione UE.
• EU AI Act: i sistemi di IA ad alto rischio richiedono una provenienza tracciabile dei dati di addestramento, il che è praticamente molto difficile su un'API di foundation model statunitense.

Nessuna di queste normative vieta i provider statunitensi. Rendono però l'onere documentale e delle misure supplementari abbastanza elevato da far sì che, per la maggior parte dei casi d'uso, uno stack sovrano rappresenti la scelta con minore attrito.

Ciò che non affermiamo

Per onestà: esistono workload per cui uno stack sovrano EU è più complesso rispetto a un hyperscaler. Multi-region active-active con latenza globale sub-50ms. Data warehouse analitici managed specifici. Inferenza ML su larga scala sugli acceleratori più recenti. Ti diremo se il tuo workload rientra in questa categoria. Per il 90% dei SaaS, e-commerce, piattaforme B2B e workload regolamentati che vediamo, lo stack sovrano non è solo conforme. È anche più veloce, più economico e più semplice da gestire dal punto di vista architetturale.

Dove si inserisce Binadit

Siamo un responsabile del trattamento ai sensi dell'Articolo 28 con sede a Rotterdam, Paesi Bassi. La nostra infrastruttura è al 100% su provider con sede nell'UE. Il nostro elenco di subprocessor è indicato per intero nell'accordo sul trattamento dei dati e disponibile su richiesta. Non accettiamo incarichi che richiederebbero un subprocessor sotto giurisdizione statunitense nel percorso dati predefinito. Quando un workload richiede effettivamente uno di questi (un SaaS di terze parti su cui il cliente insiste), lo documentiamo per iscritto, includiamo le misure supplementari e portiamo il rischio residuo all'attenzione del DPO prima della firma.

Se questo ti sembra il tipo di partner che stavi cercando, il passo successivo è una call di scoping di 30 minuti.