Il cosiddetto cloud sovrano.
Ci sono delle volte in cui ti stupisci, nel senso che ci sono delle volte in cui ti chiedi: ma davvero ci credono cosi' stupidi? Nel senso che puo' succedere che qualcuno cerchi di prenderti in giro, ma secondo me oltre un certo livello, la cosa diventa offensiva. Che qualcuno cerchi di venderti il colosseo puo' succedere, se qualcuno cerca di vendertene due , insomma, devi avere la faccia di uno che ci casca, ma se poi vuole farti il tre per due, ecco, allora forse si esagera.
Ed ecco che qualcuno ci prova.
Francesco Bertolino
Ho gia' scritto qui:
Uriel Fanelli
Cosa sta succedendo a livello normativo, nei territori UE. A questo si aggiunge il cosiddetto DNA Act, che dovrebbe completare il quadro giuridico europeo, includendo gli operatori delle telecomunicazioni, con obblighi e doveri. Il DNA act sta venendo presentato proprio in questi giorni.
Andiamo a completare, il quadro, poi vediamo bene cosa sta cercando di fare Amazon AWS per non subire le nuove leggi europee.
Due parole sul DNA
Il Digital Networks Act (DNA) è una proposta della Commissione UE per riformare la regolamentazione delle telecomunicazioni europee, sostituendo il Codice Europeo delle Comunicazioni Elettroniche. La Commissione dovrebbe adottarlo il 20 gennaio 2026, dopo ritardi dovuti a forti opposizioni.
Obiettivi dichiarati
Il DNA punta a creare un quadro normativo più efficiente per accelerare gli investimenti nelle reti digitali, coordinare lo spettro radioelettrico tra Stati membri, rafforzare la sicurezza cibernetica (con possibile esclusione di fornitori ad alto rischio come Huawei e ZTE) e facilitare operazioni transfrontaliere.
Punti critici e polemici
Deregulation delle ex-monopoliste: La critica più aspra riguarda l'allentamento della regolamentazione ex ante per operatori con potere di mercato significativo come Deutsche Telekom , TIM e Orange. I competitor temono che questo permetta alle vecchie monopoliste di abusare della posizione dominante e danneggiare la concorrenza, con effetti negativi sull'espansione della fibra ottica.
Network fees abbandonate: I grandi telco europei volevano imporre contributi obbligatori ai big tech (Netflix, Google, Meta) per l'espansione delle reti, ma la bozza finale ha abbandonato questo approccio. Aziende come Amazon/AWS avevano criticato duramente il meccanismo di risoluzione delle dispute proposto come "network fees sotto altro nome", avvertendo che avrebbe violato la neutralità della rete e aumentato i costi per consumatori e PMI.
Conflitto con accordo USA-UE: L'accordo commerciale USA-UE dell'agosto 2025 include un impegno dell'UE a non introdurre network fees, creando ambiguità su come questo si concili con alcuni elementi del DNA
Opposizione degli Stati membri: Austria, Francia, Germania, Ungheria, Italia e Slovenia hanno presentato richiesta congiunta al Consiglio per preservare il controllo nazionale sulla politica delle frequenze e altre competenze regolatorie. Il Regulatory Scrutiny Board della Commissione ha inoltre dato parere negativo sulla valutazione d'impatto, ritardando la pubblicazione.
Il DNA , tra le normative europee, e' molto piu' morbido, specialmente nei confronti di aziende americane. Questo e' dovuto a diversi fatti:
- il discorso dei fee di rete agli OTT e' gia' stato risolto a livello commerciale. In pratica, gli operatori si staccano dagli scambiatori pubblici, ove pagano per porta fisica, e si attaccano a dei corrispondenti privati che possono pratica subscriber policies a pagamento.
Uriel Fanelli
- il DNA si occupa, piu' che altro di reti di accesso e telco. Siccome gli americani non sono molto presenti in EU come infrastruttura, e' abbastanza blando a riguardo, tranne per il problema che nessuno vuole vedere, cioe' Starlink. Il DNA, in fatti, si occupa delle frequenze satellitari.
Starlink e altri operatori satellitari rientrano nel DNA Act attraverso proposte di gestione coordinata a livello UE delle frequenze satellitari. Questo rappresenta effettivamente un punto dove l'UE cerca di esercitare controllo su operatori non europei come Starlink (SpaceX).
Framework comune per operatori satellitari
Il DNA propone di aggiornare il quadro normativo UE per permettere l'implementazione di requisiti comuni nei framework nazionali di autorizzazione per fornitori di servizi satellitari. Attualmente, operatori come Starlink ottengono licenze spettro paese per paese: ad esempio, la Bundesnetzagentur tedesca ha rilasciato diritti d'uso dello spettro a SpaceX nel dicembre 2020.
Meccanismi di enforcement
La proposta include procedure per quando uno Stato membro identifica una non-conformità con i requisiti comuni che non viene risolta a livello nazionale. Questi meccanismi prevedono reporting, valutazione e reazione collettiva a livello UE, come procedure per gestire casi di non-conformità.
Ruolo rafforzato della Commissione
Il DNA rafforza il ruolo della Commissione nelle relazioni con paesi terzi riguardo a disruzioni e accordi di coordinamento delle frequenze. Questo darebbe all'UE maggiore leva negoziale verso operatori americani che necessitano di accesso coordinato allo spettro per servizi Direct-to-Device.
Quindi, anche se il DNA non impone network fees o sanzioni dirette alle big tech, cerca di centralizzare il controllo sullo spettro satellitare, obbligando operatori come Starlink a conformarsi a standard UE comuni anziché negoziare bilateralmente con singoli Stati membri.
Per chiarirlo in soldoni: se immaginiamo che l' Ukraina entri nella UE, Starlink non potrebbe piu' minacciare di sospendere il servizio sul paese, in quanto a quel punto l' Ukraina potrebbe denunciare la non conformita', e Starlink perderebbe l'uso delle frequenza su tutta la UE.
Ok, abbiamo divagato abbastanza. Spero sia chiaro che l' EU sta chiudendo il cerchio regolatorio sull' IT.
Torniamo ad AWS.
Chiarito il perimetro dell'ennesima "Fortezza Europa" nel campo della tecnologia, (Il DNA si unisce a tutto il resto dei regolamenti, formando effettivamente una fortezza dalla quale e' sempre piu' difficile estrarre ricchiezza, arriva la mossa di Amazon.
Amazon cerca in qualche modo di rientrare nelle norme del "cloud sovrano", come dicono le nuove norme che dovranno essere completamente in vigore entro settembre di quest'anno, dimenticando la piccola postilla dei regolamenti, che... di fatto la mettono fuori norma.
Non parlo ne' di un regolamento né di una direttiva: il “Cloud Sovereignty Framework” (Version 1.2.1 – Oct. 2025) è un documento della Commissione (DG DIGIT) pensato per essere usato dentro specifiche procedure di gara come metodo di valutazione e come requisito nei capitolati/tender specifications.
Quindi diventa “vincolante” solo nella misura in cui l’amministrazione lo incorpora nei documenti di gara e poi nel contratto, non perché sia una fonte normativa UE direttamente applicabile. Quindi dopo l'adozione nazionale.
SOV: cosa sono
I SOV (SOV-1…SOV-8) sono otto obiettivi di sovranità su cui la stazione appaltante valuta un servizio cloud.
Nel framework sono elencati con descrizione e “contributing factors” (i criteri/indicatori che la PA deve considerare).
- SOV-1 Strategic Sovereignty.
- SOV-2 Legal & Jurisdictional Sovereignty (include esposizione a leggi extraterritoriali tipo US CLOUD Act e canali con cui autorità non-UE potrebbero imporre accesso).
- SOV-3 Data & AI Sovereignty (include controllo effettivo delle chiavi crittografiche da parte del cliente, confinamento UE, auditabilità).
- SOV-4 Operational Sovereignty.
- SOV-5 Supply Chain Sovereignty.
- SOV-6 Technology Sovereignty.
- SOV-7 Security & Compliance Sovereignty (include GDPR/NIS2/DORA, SOC sotto giurisdizione UE, audit).
- SOV-8 Environmental Sustainability.
SEAL: cosa sono
I SEAL (SEAL-0…SEAL-4) sono i livelli di “Sovereignty Effectiveness Assurance” con cui la PA esprime “quanto bene” un provider soddisfa un singolo obiettivo SOV.
Le definizioni sono trasversali (valgono per tutti i SOV) e vanno da “No Sovereignty” (SEAL-0) a “Full Digital Sovereignty” (SEAL-4).
Come funziona in una gara dopo questo regolamento (davvero)
- La PA definisce nel capitolato il SEAL minimo richiesto per ciascun SOV (cioè 8 “soglie”: una per ogni obiettivo).
- La valutazione avviene tramite questionario: ogni domanda è “taggata” con il SOV a cui contribuisce, e il fornitore risponde fornendo evidenze (documenti e/o info pubbliche sul servizio).
- La PA assegna un livello SEAL per ciascun SOV “prendendo in considerazione” i contributing factors relativi a quel SOV.
- Se emergono “material weaknesses” anche su uno o più contributing factors, la PA abbassa il SEAL assegnato a quell’obiettivo.
- Se il tender richiede “minimo SEAL-4” e un solo SOV viene valutato sotto SEAL-4, l’offerta viene respinta (“rejected”).
- Separatamente, la PA calcola anche un Sovereignty Score (con pesi per SOV e formula indicata) per ordinare/valutare le offerte come criterio qualitativo (“Award Criterion”).
Facciamo un esempio di cui si straparla: l'accordo tra Palantir e il Policlinico Gemelli.
Il contratto, ovvero la gara, e' stato stipulato nel 2023. Di consequenza, NON erano ancora in vigore norme di questo genere, e non erano ancora state quindi assorbite dal diritto italiano. Di conseguenza, per ora questa regola non si applica.
Se pero' supponiamo che il contratto ad un certo punto scada, e bisognera' fare una gara, allora il Gemelli dovra' per forza dedicere quale livello di SEAL richiede per ogni SOV. E finche' rimane in vigore negli USA il Cloud Act, il SOV/2 non andra' mai oltre SEAL-2 . Il Gemelli quindi dovra' indicare Seal-2 per tutti i requisiti, perche' il SEAL vale per tutta l'offerta, se dici Seal-3, per esempio, nessuno dei SOV puo' essere sotto SEAL-3.
Interessante, ma non perche' esistono degli obblighi europei. E' il legislatore che assorbe la legislazione europea e decide se per caso esistano dei livelli SEAL obbligatori per un ospedale.
MA.
Sì: per un appalto che coinvolge dati clinici è del tutto plausibile (e spesso sensato) fissare livelli minimi SEAL, ma questi minimi non sono “automatici” né uguali ovunque. Nel Cloud Sovereignty Framework, infatti, è la stazione appaltante che indica nei documenti di gara il SEAL minimo richiesto per ciascun SOV, e le offerte che non lo rispettano vengono respinte.
Come si imposta il minimo
Nel framework la valutazione è “twofold”: un SEAL per ogni obiettivo SOV usato come Minimum Assurance Level e IN AGGIUNTA un Sovereignty Score usato come criterio qualitativo di aggiudicazione. Il testo dice esplicitamente che “le tender specifications indicano un livello SEAL minimo che il provider deve raggiungere per ciascun SOV” e che le offerte non coerenti con questi minimi “will be rejected”. Inoltre la Commissione indica che i risultati possono essere usati in esercizio per decidere “che natura di sistemi” può stare su un provider, perché “profili di rischio diversi richiedono livelli di assurance diversi”.
Perché in sanità il minimo tende a salire
I dati sanitari sono “categorie particolari” (art. 9 GDPR) e quindi richiedono condizioni e cautele più stringenti rispetto a dati ordinari. Nel CSF, i contributing factors di SOV-2 chiedono di valutare l’esposizione a leggi non-UE con portata extraterritoriale (esempi: US CLOUD Act) e i canali con cui autorità non-UE potrebbero imporre accesso a dati o sistemi. Sempre nel CSF, SOV-3 include aspetti come controllo effettivo delle chiavi da parte del cliente e confinamento rigoroso di storage/processing in giurisdizioni europee senza “fallback” verso paesi terzi.
Cosa “ha senso” chiedere (senza inventare obblighi)
Il framework non dice “per la sanità serve SEAL-X”, quindi non esiste un minimo UE predefinito per ospedali dentro il CSF. Però, se una PA vuole ridurre davvero i rischi tipici del dominio sanitario, è ragionevole che il capitolato tenda a essere più severo almeno su:
- SOV-2 (Legal & Jurisdictional): per limitare la “compellability” da governi terzi.
- SOV-3 (Data & AI): per garantire controllo UE sulle chiavi e confinamento UE dei trattamenti.
- SOV-7 (Security & Compliance): per SOC/monitoring sotto giurisdizione UE e auditabilità.
Nota concreta: già dalle definizioni, SEAL-2 ammette “material non‑EU dependencies” e “indirect control of non‑EU third parties”, mentre SEAL-3 restringe a “marginal control” non‑UE. Se l’obiettivo è minimizzare l’area di attacco giuridica (non solo tecnica), è lì che si gioca la differenza.
Cosa significa? Il problema che noterete e' che questo e' un framework che , per essere attivo, deve essere incluso nella gara di appalto. Se non viene incluso, cosa puo' succedere?
- Il primo rischio, enorme quando le leggi sono cosi' poco vincolanti, e' quello di vedersi impugnato il contratto, o se l'appalto era dato su soldi europei, allora e' facile portare la gara di fronte a dei giudici che possano annullare l'assegnazione.
- Siccome la EU sta costruendo servizi IT propri, cloud compresi - direttamente o indirettamente, come finanziamento pubblico a progetti opensource, rischia di diventare il frameworrk che di fatto "tiene fuori gli americani dai trattati "UE".
E qui andiamo ad AWS. AWS sta cercando di minimizzare il rischio “giurisdizionale” (SOV‑2) offrendo un AWS European Sovereign Cloud dichiarato “fisicamente e logicamente separato” dagli altri ambienti AWS e operato da residenti UE (in transizione verso soli cittadini UE), con sistemi IAM e billing dedicati e metadati creati dal cliente mantenuti nell’UE.
Detto questo, non è una “certificazione SOV‑2”: SOV‑2, nel Cloud Sovereignty Framework, include esplicitamente il “degree of exposure to non‑EU laws with cross‑border reach (e.g., US CLOUD Act)”.
In teoria, nel caso del Gemelli, il Gemelli stesso potrebbe anche mandare sul cloud di Palantir (basato su AWS) tutti i dati cifrati end‑to‑end, trattenendo per sé le chiavi di cifratura.
Questa sarebbe una mitigazione materiale: un ordine USA verso AWS o Palantir potrebbe ottenere al massimo ciphertext e metadati, perché AWS dichiara che può rispondere a richieste legali solo quando ha la “technical ability” e che “encrypted content is useless without the applicable decryption keys”.
Questo però è un effetto materiale, non “giuridico”: il CLOUD Act resta parte del rischio SOV‑2 proprio perché l’esposizione alla legge (e la possibilità di ordini) non sparisce, anche se il contenuto non è leggibile senza chiavi.
Se questa mitigazione sia da considerarsi sufficiente dipende da come la stazione appaltante imposta il livello minimo SEAL e da come valuta (in concreto) i canali di accesso forzoso residui, perché SOV‑2 non è solo cifratura ma anche esposizione giurisdizionale e catena contrattuale/operativa.
In altre parole: l’appalto può diventare impugnabile se i requisiti (o la valutazione) risultano arbitrari, non proporzionati o non verificabili ex ante, proprio perché la “sufficienza” qui non è un automatismo tecnico ma una scelta da capitolato
Quindi, la pretesa di AWS di aver creato un cloud “conforme” è quantomeno fuorviante: il Cloud Sovereignty Framework non è uno schema di certificazione generale, ma un meccanismo di valutazione per gare specifiche.
Di fatto, però, quando una stazione appaltante decide di adottarlo, il CSF impone una logica di “conformità” dentro quella gara: il capitolato deve indicare un livello minimo SEAL per ciascun obiettivo (SOV) e le offerte che non raggiungono i minimi vengono respinte.
Questa impostazione lascia inevitabilmente margini di discrezionalità (scelta delle soglie e valutazione delle “debolezze materiali”) che possono diventare terreno di contenzioso.
Quindi no: l’UE non ha creato un “divieto anti‑USA” automatico;
pero'....
ha reso più semplice costruire (e, simmetricamente, contestare) capitolati che penalizzino o escludano operatori extra‑UE su dimensioni come l’esposizione a leggi non‑UE con portata extraterritoriale (esempio esplicito: CLOUD Act).
Dal punto di vista procurement, il Cloud Sovereignty Framework non “certifica” un cloud in astratto: impone che l’ente appaltante scelga, per quella gara e per quel servizio, un livello minimo SEAL per ciascun obiettivo di sovranità e respinga le offerte che non raggiungono quei minimi.
Questa è discrezionalità pura (ma vincolata): il cuore della partita sta nel disegno dei requisiti (minimi SEAL, evidenze richieste, controlli compensativi ammessi) e nella motivazione della scelta, perché due enti diversi possono imporre soglie diverse per lo stesso tipo di tecnologia a seconda del rischio e del tipo di dato trattato.
Qui entra bene l’esempio del BSI tedesco: il BSI dichiara che il proprio BSI‑Portal “basiert auf einer Cloud‑Infrastruktur von Amazon Web Services” e che il portale viene costruito come piattaforma informativa e di scambio (con dati in tempo reale e analisi) per reagire rapidamente agli incidenti.
Nello stesso comunicato il BSI chiarisce che nel portale vengono anche pubblicati i “Tageslageberichte” e le “IT‑Sicherheitsmitteilungen”, e che vulnerabilità e falle possono essere segnalate anche anonimamente e senza registrazione: elementi che, in molti casi, abbassano drasticamente il peso del requisito “confidenzialità” rispetto a integrità e disponibilità.
Se, come in questo caso, il servizio tratta soprattutto dati che sono pubblici o destinati alla pubblicazione (o comunque a diffusione controllata), l’ente può ragionevolmente impostare un profilo di sovranità meno “massimalista” sul dato e più focalizzato su continuità operativa, scalabilità e time‑to‑market—e quindi tollerare, motivandolo, un’architettura su hyperscaler anche non‑UE.
In più, il BSI esplicita una posizione che rende questa scelta coerente a livello di policy: “sovranità” come doppia strategia (rafforzare il mercato europeo e adattare/integrare prodotti non‑europei per un uso sicuro e indipendente), specialmente in cloud attraverso istanze europee operate separatamente sul piano tecnico e organizzativo.
Come mai la BSI ha scelto AWS, quindi?
Ipotesi tecniche (ripeto: ipotesi)
- Classificazione dati: se il contenuto è pubblico/publishable, il requisito forte non è “segretezza”, ma “non alterabilità” (integrità) + “non indisponibilità” (availability); questo cambia completamente il compromesso tra SEAL/SOV richiesti e scelta del provider.
- Controlli compensativi: anche con AWS, un ente può spostare il baricentro su misure verificabili (IAM minimale, segregazione tenant, logging immutabile, chiavi gestite fuori dal perimetro del provider, exit plan).
- Soglia SEAL: fissare una soglia minima “non massimalista” è una scelta, e il CSF rende questa scelta esplicita (quindi discutibile e impugnabile se sproporzionata o incoerente), ma non la impedisce.
Trattandosi di dati sanitari, invece, altri ospedali italiani che vogliano affidare a Palantir (a quanto pare, oggi diventata l'azienda del demonio) i loro dati, per evitare ricorsi dovranno disegnare i requisiti di sovranita'.
Se i prossimi appalti ospedalieri su dati sanitari non traducono la “sovranità” in requisiti SEAL espliciti (con soglie minime e criteri verificabili), lasciano troppo margine a valutazioni ex post e quindi aumentano il rischio di ricorsi.
Nel Cloud Sovereignty Framework, infatti, la sovranità non è una certificazione “automatica” del fornitore: è un set di obiettivi per cui l’ente deve fissare minimi e regole di ammissibilità della gara.
Se quei minimi non ci sono (o sono vaghi), l’aggiudicazione diventa più facile da contestare in tribunale, perché manca il collegamento chiaro tra rischio trattato e requisiti richiesti.