Il 3 giugno 2026 la Commissione europea ha presentato la proposta di regolamento che istituisce un quadro di misure per il rafforzamento dell’ecosistema cloud e di intelligenza artificiale dell’Unione: il Cloud and AI Development Act, in sigla CADA (COM(2026) 502 final, procedura legislativa ordinaria 2026/0138 (COD)). Lo stesso giorno la Commissione ha pubblicato la Comunicazione sulla sovranità tecnologica europea (COM(2026) 503 final), che colloca il CADA dentro un pacchetto più ampio.
Si tratta dello strumento con cui l’Unione trasforma la sovranità del cloud da slogan a criterio misurabile e certificabile — e, per il settore pubblico, vincolante in sede di appalto.
Non è una proposta relativa alla sanità o ai dati sanitari, ma per questo mondo la rilevanza sarà tutt’altro che marginale.
Vediamo allora le principali novità, e poi analizziamo gli impatti in sanità.
Indice degli argomenti
Il pacchetto sulla sovranità tecnologica: cosa è il CADA
La Comunicazione COM(2026) 503 final costruisce un pacchetto sulla sovranità tecnologica fondato su quattro iniziative: un Chips Act 2.0, il CADA, una strategia per l’open source (contenuta nella Comunicazione stessa) e una Roadmap strategica per la digitalizzazione e l’IA nel settore energetico.
Il motore di partenza è il Rapporto Draghi: l’Unione è oggi dipendente da fornitori extra-UE per oltre l’80% dei propri prodotti, servizi e infrastrutture digitali; sul cloud, la quota di mercato dei fornitori europei è circa al 15%, con oltre il 70% del mercato in mano a tre hyperscaler statunitensi.
Fondamentale quindi lavorare per riportare la sovranità digitale in Europa.
L’art. 1 della proposta enuncia quindi cinque misure: l’istituzione delle Cloud and AI Leadership Initiatives; un quadro per il dispiegamento accelerato dei data center; la disponibilità di un’offerta cloud e IA sovrana a tutela dell’ordine pubblico dell’Unione; la riduzione delle dipendenze dalle tecnologie critiche; la promozione dell’adozione del cloud nel settore pubblico.
Due sono gli obiettivi generali dichiarati: competitività e capacità di innovazione dell’ecosistema cloud e IA, da un lato; miglioramento del funzionamento del mercato interno mediante un quadro uniforme per la resilienza e l’autonomia strategica, dall’altro.
L’architettura della proposta: dalle leadership initiatives ai quattro livelli di sovranità
La proposta si articola poi in cinque Titoli.
Dopo il Titolo I sugli obiettivi e definizioni, il Titolo II disciplina le Cloud and AI Leadership Initiatives (artt. 3-9): sostegno alla ricerca e all’innovazione, capacità su larga scala, progetti prioritari di frontier AI (art. 8) e allocazione delle risorse di calcolo (art. 9). In particolare poi l’art. 7 impone agli Stati membri di adottare una strategia nazionale per il cloud e l’IA entro un anno dall’entrata in vigore. Il Titolo III riguarda la capacità di data center (artt. 10-15): obbligo per gli Stati membri di designare zone di accelerazione per i data center (art. 10), procedure autorizzative semplificate (con l’obiettivo dichiarato di rilasciare i permessi in meno di 18 mesi) e progetti strategici (art. 14); l’obiettivo è triplicare la capacità entro il 2030.
Il cuore della proposta è però il Titolo IV, dedicato all’autonomia.
L’art. 16 istituisce un quadro di sovranità del cloud computing articolato in quattro livelli di garanzia (Union assurance levels), i cui criteri sono fissati nell’Allegato II (che la Commissione deve riesaminare almeno ogni 18 mesi – art. 16, par. 3). Il riconoscimento del fornitore di cloud e del relativo livello di garanzia passa dall’autorità nazionale competente del luogo di stabilimento (art. 17): più precisamente, per il livello 1 il fornitore potrà procedere in autovalutazione di conformità (art. 19), mentre i livelli 2, 3 e 4 dovranno essere sottoposti a audit indipendente di terza parte (art. 20), con iscrizione in un repository centrale tenuto dalla Commissione (art. 22).
L’art. 29 impone poi a Stati membri e soggetti dell’Unione (entro un anno dall’entrata in vigore e poi ogni due anni) di svolgere valutazioni del rischio per: (a) individuare le attività del settore pubblico che utilizzano il cloud e contribuiscono a preservare l’ordine pubblico nei settori di cui agli Allegati I o II della Direttiva (UE) 2022/2555 (NIS2) – oltre che negli ambiti sicurezza nazionale, sicurezza interna, gestione delle frontiere, difesa, giustizia e attività di contrasto; (b) determinare quale livello (2, 3 o 4) sia appropriato per quelle attività.
L’art. 30 traduce poi la valutazione in futuri obblighi di gara.
Più precisamente, le amministrazioni le cui attività non saranno qualificate come rilevanti per l’ordine pubblico dovranno utilizzare servizi cloud riconosciuti almeno al livello 1 (art. 30, par. 2); le amministrazioni aggiudicatrici le cui attività saranno qualificate come rilevanti per l’ordine pubblico nei settori NIS2 potranno approvvigionarsi soltanto di servizi riconosciuti ai livelli 2, 3 o 4 (art. 30, par. 3).
Infine la proposta di regolamento disciplina le valutazioni d’impatto per il settore privato (art. 31), i criteri di valore aggiunto europeo nelle gare (art. 32), la federazione EuroCloud (artt. 34-36) e le misure sull’open source (artt. 41-44).
Quanto ai tempi, l’art. 48 prevede l’applicazione a un anno dall’entrata in vigore.
I dati sanitari: localizzazione, accesso dei paesi terzi e divieto di addestrare l’IA estera
Veniamo ora al contenuto concreto dei 4 livelli, letto con gli occhi di chi tratta dati sanitari.
I requisiti dei diversi livelli sono disciplinati nell’Allegato II e crescono in intensità man mano che si sale.
Il livello 1 (autovalutazione, art. 19) richiede che il fornitore sia stabilito nell’Unione; che infrastrutture e asset siano localizzati nell’Unione; che i dati del cliente – inclusi metadati e dati di telemetria – restino esclusivamente nell’Unione, salvo diversa richiesta dell’organismo pubblico; oltre a misure di cybersicurezza allo stato dell’arte e piena trasparenza sui subfornitori. L’organismo pubblico può poi autorizzare una diversa localizzazione.
Ai livelli 2, 3 e 4 (quelli sottoposti ad audit indipendente, art. 20) la vite si stringe.
I dati del cliente, inclusi metadati e telemetria, devono restare esclusivamente nell’Unione (Allegato II, livelli 2 e 3, lett. c; per il livello 4 la lett. c riguarda i dati identificati come sensibili a valle di una valutazione del rischio) ed occorre altresì un certificato europeo ai sensi del Regolamento (UE) 2019/881 (Cybersecurity Act) di livello almeno substantial per i livelli 2 e 3 e high per il livello 4.
Vi è poi una previsione di particolare interesse, presente per livelli 2, 3 e 4: i dati generati dall’uso del servizio non possono essere utilizzati per addestrare o per il fine-tuning di alcun sistema di IA gestito da un paese terzo o da un soggetto stabilito in un paese terzo, e in nessun caso possono essere trasferiti fuori dall’Unione (nella versione inglese della proposta: i dati “are not used to train or fine-tune any AI system operated by a third country”). Obiettivo: i log, la telemetria, i metadati e i dati derivati dall’uso del servizio non possono diventare carburante per l’addestramento di un modello extra-UE.
Infine il nodo del controllo da parte di paesi terzi.
I livelli 3 e 4 esigono che fornitore e subfornitori non siano soggetti al controllo di un paese terzo o di un soggetto ivi stabilito (Allegato II, livello 3, lett. g; livello 4, lett. g, senza deroga): è la previsione che affronta in maniera diretta il problema della portata extraterritoriale delle leggi dei paesi terzi. Si segnala che il livello 3 ammette però una deroga per i paesi terzi “associati”, cioè quelli che la Commissione potrà riconoscere con atto di esecuzione come offerenti garanzie sufficienti (art. 18 della proposta), a partire dall’esistenza di una decisione di adeguatezza ai sensi dell’art. 45 GDPR.
Per i dati sanitari dunque il CADA introdurrà una seconda dimensione di valutazione accanto al GDPR: non più solo dove vanno i dati e con quale base giuridica, ma chi controlla, in ultima istanza, l’infrastruttura che li ospita.
La sanità pubblica come soggetto chiave: appalti, migrazione e sovranità accanto al GDPR
Le conseguenze operative per le strutture pubbliche sanitarie si misureranno su tre piani.
Il primo è la valutazione del rischio (art. 29): sulla base della metodologia che la Commissione fisserà con atti di esecuzione (art. 29, par. 3), le strutture dovranno mappare quali attività supportate dal cloud siano rilevanti per l’ordine pubblico — sapendo che la Commissione potrà sindacare il livello individuato (art. 29, par. 5).
Il secondo piano è l’appalto. L’art. 30 ridisegna infatti le gare: base al livello 1, livelli 2-3-4 per le attività rilevanti per l’ordine pubblico. A ciò si aggiunge l’art. 32 sul valore aggiunto europeo: nelle gare per servizi cloud e sistemi di IA innovativi, le amministrazioni dovranno includere, nella valutazione qualitativa, criteri non basati sul prezzo che misurino il contributo dell’offerente allo sviluppo di un ecosistema europeo del cloud e dell’IA (uso di software o hardware progettati o fabbricati nell’Unione, integrazione di tecnologie sviluppate nell’Unione). Criteri che, precisa l’art. 32, par. 2, lett. d, devono restare accessori e non decisivi: orientano la gara, ma non la dettano.
Il terzo piano è la migrazione. L’art. 29, par. 6, prevede che, quando la valutazione del rischio imponga il passaggio a un altro servizio cloud, l’organismo migri entro un periodo di transizione ragionevole comunque non superiore a 12 mesi. Per un ospedale che oggi tiene un sistema clinico su un cloud non sovrano, dopo la valutazione del rischio quei 12 mesi diventano una scadenza obbligatoria.
Da ultimo preme evidenziare che esiste poi una via alternativa per chi sul mercato non trova ciò che serve: la federazione EuroCloud (artt. 34-36), federazione volontaria del cloud del settore pubblico che consentirà la condivisione di servizi di data center e di cloud tra soggetti dell’Unione e organismi pubblici. Una possibile scialuppa sovrana per chi non ne trovi una sul mercato.
Tutto questo presuppone ovviamente che esistano davvero, nel repository centrale (art. 22), servizi riconosciuti ai livelli 2, 3 o 4. Non a caso lo stesso art. 30, par. 4, contempla una deroga per i casi in cui nessun servizio riconosciuto possa soddisfare l’esigenza o lo possa solo a costi sproporzionati.
In sostanza il legislatore manifesta la piena consapevolezza che il vero collo di bottiglia è l’offerta di servizi cloud conformi.
Il settore life science: dispositivi medici, pharma, ricerca e le Grand Challenges
Sul versante privato si evidenziano due distinzioni rilevanti.
La prima distinzione corre tra mondo pharma e mondo medical device, e nasce da come la NIS2 li colloca nei propri Allegati.
Occorre infatti ricordare che gli obblighi visti finora — valutazione del rischio (art. 29) e vincoli di gara (art. 30) — riguardano il solo settore pubblico.
Per i privati la porta d’ingresso è l’art. 31, e si apre in due tempi.
Il par. 1 riconosce ai soggetti privati dei settori ad alta criticità (Allegato I NIS2) la facoltà — il verbo è «possono», non un obbligo — di svolgere valutazioni d’impatto analoghe a quelle dell’art. 29, per stabilire se le proprie attività in cloud richiedano un fornitore ai livelli 2, 3 o 4. Il par. 3 consente però alla Commissione, con atto delegato, di trasformare quella facoltà in obbligo per i medesimi settori ad alta criticità.
Tutto si gioca dunque sulla collocazione NIS2.
Nel settore salute, l’Allegato I comprende i prestatori privati di assistenza sanitaria, i laboratori di riferimento UE, la ricerca e sviluppo di medicinali, i fabbricanti di prodotti farmaceutici di base e i soli fabbricanti di dispositivi medici critici in emergenza sanitaria: il pharma, in sostanza, è dentro il meccanismo — oggi su base volontaria, domani potenzialmente obbligato.
I fabbricanti di dispositivi medici e IVD, invece, stanno nell’Allegato II (fabbricazione): restano fuori sia dalla facoltà del par. 1 sia dall’aggancio del par. 3.
Il risultato è una distinzione (ingiustificata, a parere di chi scrive): la ricerca e la produzione farmaceutica entrano nel perimetro dell’alta criticità, la produzione di dispositivi medici e IVD no — salvo i pochi dispositivi inseriti nelle liste di criticità in emergenza sanitaria.
La seconda distinzione riguarda i dispositivi medici che vivono nel cloud.
Sempre più software medicali (Software as a Medical Device) e soluzioni di IA girano su infrastruttura cloud. L’intreccio è evidente: un software medicale che sia un sistema di IA e che funga da componente di sicurezza soggetto a valutazione di conformità di terza parte ai sensi di MDR/IVDR è classificato ad alto rischio dall’AI Act (Regolamento (UE) 2024/1689, art. 6, par. 1, e Allegato I). Quando quel dispositivo gira su un’infrastruttura cloud acquistata da un ospedale pubblico, i vincoli di appalto del CADA – cioè il livello di garanzia richiesto – entrano nel quadro accanto a MDR/IVDR e all’AI Act. Per il fabbricante che vende ad acquirenti pubblici, su quale cloud gira il dispositivo e a quale livello di sovranità diventa una domanda di market access.
Implicazioni pratiche e uno sguardo più ampio sul CADA
Il CADA al momento è solo una proposta di regolamento e potrà certamente cambiare nel corso del negoziato.
È però già chiaro lo sguardo d’insieme.
Il CADA è il segnale chiaro che l’Unione ha deciso di trattare il cloud come già tratta i dati: una questione di sovranità, non solo di mercato.
Per la sanità – il settore in cui i dati più sensibili incontrano la dipendenza più pesante da una manciata di hyperscaler extra-UE – non è un ritocco marginale, ma un riposizionamento strutturale.
La scommessa è poi chiara: costruire uno European technology stack anche al prezzo, nel breve periodo, di costi più alti e di un mercato dell’offerta più sottile. Se la scommessa pagherà per la sanità dipenderà meno dalla norma che dalla capacità di far nascere davvero un’offerta europea di cloud sovrano nel repository centrale, prima che le valutazioni del rischio entrino in funzione.
La norma può imporre la domanda di sovranità ma non può, da sola, creare l’offerta.
E qui – diciamocelo – si gioca la differenza tra una sovranità reale e una sovranità sulla carta.
