CADA: i quattro livelli di garanzia dell’Unione

Cosa contiene la proposta

Il problema dichiarato è la dipendenza: la capacità di calcolo nell’Unione è limitata e concentrata geograficamente, e l’UE si affida a fornitori non europei per i servizi cloud e di AI, con conseguenze sul controllo dei dati e sull’autonomia operativa. La risposta si articola in quattro blocchi.

Cloud and AI Leadership Initiatives — finanziamenti a ricerca e innovazione, una rete di Experience and Acceleration Centres per l’AI costruita sugli European Digital Innovation Hubs, il riconoscimento di progetti prioritari sull’AI di frontiera, e strategie nazionali per cloud e AI che gli Stati membri dovrebbero adottare entro un anno dall’entrata in vigore.

Capacità dei data center — gli Stati membri designano zone di accelerazione con autorizzazioni agevolate e sportelli informativi unici, la Commissione designa progetti strategici, e i progressi rispetto al divario di capacità sono monitorati a livello centrale.

Autonomia e adozione — la parte di cui parliamo qui sotto: livelli di garanzia, obblighi negli acquisti, una federazione cloud del settore pubblico, un quadro comune per gli acquisti gestito dalla Commissione, e obblighi per gli organismi dell’Unione e per gli enti pubblici di preferire l’open source e di condividere e riusare il software che commissionano.

Nella valutazione d’impatto sono gli stessi cloud provider a descrivere il meccanismo di audit dei servizi sovrani come la misura che metterebbe fine al “sovereign-washing”, e il beneficio viene presentato come un unico audit valido in tutta l’Unione invece di uno per Stato membro. È la sintesi onesta dell’ambizione: non rendere obbligatoria la sovranità, ma dare alla parola un significato abbastanza preciso da poter essere verificato con un audit.

I quattro livelli, come sono scritti

L’Allegato II fissa criteri cumulativi: ogni livello comprende tutto quello dei livelli inferiori e aggiunge i propri. Quella che segue è una sintesi in parole semplici, non il testo giuridico — e l’Allegato II è esplicitamente soggetto a revisione da parte della Commissione almeno ogni diciotto mesi. Attenzione alla riga sul perimetro in testa all’allegato: il ‘software’ come definito nel Cyber Resilience Act è incluso, l’hardware no.

La struttura merita attenzione. I livelli da 1 a 3, in fondo, riguardano dove stanno le cose e chi le tocca: stabilimento, localizzazione, residenza dei dati, personale, supporto. Il livello 4 riguarda chi controlla il fornitore e il software, e il controllo è l’unico criterio che un contratto non può fabbricare. È anche la distinzione che questo studio fa da tempo tra un sistema privato e un sistema sovrano.

Chi dovrebbe fare cosa

Settore pubblico. Gli Stati membri e gli organismi dell’Unione svolgerebbero valutazioni del rischio per stabilire quali delle loro attività contribuiscono alla tutela dell’ordine pubblico. Le amministrazioni aggiudicatrici che acquistano servizi cloud per uso proprio devono usare, come minimo, servizi riconosciuti al livello 1. Dove l’attività è stata individuata come rilevante per l’ordine pubblico — nei settori degli Allegati I o II della direttiva NIS2, e in sicurezza nazionale, sicurezza interna, gestione delle frontiere, difesa, giustizia e attività di contrasto — si possono acquistare solo i livelli 2, 3 o 4. Le deroghe sono limitate, soprattutto ai casi in cui nessun servizio riconosciuto può fornire ciò che è messo a gara.

Settore privato. Questo è il paragrafo da leggere due volte se gestisci infrastrutture in sanità, energia, trasporti, banche, acqua o infrastrutture digitali. I soggetti dell’Allegato I della NIS2 che non sono enti pubblici possono svolgere valutazioni simili a quelle del settore pubblico. La Commissione può emanare linee guida sulla metodologia e può, con atto delegato e in consultazione con gli Stati membri, stabilire che i soggetti dei settori ad alta criticità siano tenuti a svolgerle, insieme alle misure di mitigazione del rischio da adottare.

In altre parole: volontario così com’è scritto, con un meccanismo esplicito per diventare obbligatorio nei settori in cui la posta in gioco è più alta. Le organizzazioni di quei settori che sanno già dove stanno i loro dati, chi può raggiungerli e cosa succederebbe se la capogruppo di un fornitore ricevesse un ordine da un paese straniero troveranno quella valutazione un esercizio di documentazione. Per le altre sarà un progetto.

I criteri sulla supply chain non sono nuovi — ed è proprio questo il punto

Leggi i requisiti del livello 2 sulla supply chain del software accanto agli obblighi che stanno già arrivando da altre parti. Uno SBOM completo e aggiornato, definito per rinvio al Cyber Resilience Act. Controlli documentati che bloccano le funzionalità remote capaci di manomettere un sistema durante un aggiornamento. Audit del codice sorgente dei componenti di paesi terzi rilevanti per la sicurezza. Un piano di migrazione per il caso in cui il vendor venga meno o un paese terzo imponga restrizioni.

Lo SBOM è il caso più chiaro. È un elemento di prova ai sensi della direttiva sulla responsabilità da prodotto, uno strumento di vulnerability management ai sensi del CRA, e ora un artefatto di audit ai sensi del CADA — un solo artefatto, tre finalità normative. Lo stesso vale per i registri dei fornitori, la gestione delle vulnerabilità e la sorveglianza post-commercializzazione. Mappare queste convergenze — quale controllo risponde a quali regimi, e quanto si risparmia — è ciò a cui serve la metodologia Compliance-Epistemic Project Framework (CEPF).

La conseguenza pratica per chi compra è che un fornitore che oggi non sa produrre uno SBOM non è soltanto impreparato al CADA. È impreparato agli obblighi di segnalazione del CRA, che si applicano dall’11 settembre 2026, e diventerà un interlocutore scomodo quando gli Stati membri avranno recepito la direttiva sulla responsabilità da prodotto entro il 9 dicembre 2026 — il tema dell’assessment di esposizione.

Come si colloca accanto all’AI Act

I due strumenti fanno lavori diversi, e conviene non confonderli. L’AI Act regola i sistemi di AI in base alla finalità prevista e al ruolo: a cosa serve il sistema, chi lo fornisce, chi lo usa, quali evidenze deve essere in grado di produrre. Il CADA non classifica affatto i sistemi di AI. Regola il substrato — dove sta la capacità di calcolo, chi possiede l’operatore, chi può raggiungere i dati — e lo fa soprattutto attraverso gli acquisti, non attraverso obblighi di prodotto.

Si incontrano in un criterio preciso. Dal livello 2 in su, i dati generati dall’uso del servizio non possono essere usati per addestrare o fare fine-tuning di alcun sistema di AI gestito da un paese terzo o da un’entità di un paese terzo, e non possono essere trasferiti fuori dall’Unione. È un vincolo sul fornitore che finisce nella documentazione di chi compra: è il tipo di affermazione che sta in un registro dei trattamenti GDPR e nella documentazione tecnica di un sistema di AI, ed è molto più facile da fare quando i livelli di retrieval e di audit stanno dentro il perimetro fin dall’inizio.

Per un sistema già costruito per rispondere alle domande dell’AI Act — su cosa si è basato, cosa ha risposto, chi l’ha approvato — il vocabolario del CADA aggiunge un secondo asse, non un secondo programma: non cosa fa il sistema, ma chi potrebbe interferire con esso.

Cosa significa per un’installazione self-hosted

Prima una precisazione, perché è il genere di cosa che si tende a gonfiare. Il meccanismo di riconoscimento del CADA si applica ai fornitori di servizi di cloud computing che offrono servizi agli organismi dell’Unione e agli enti del settore pubblico. Una piattaforma installata sull’infrastruttura del cliente non è un servizio cloud acquistato, quindi non c’è alcun livello di garanzia da detenere e qui non se ne rivendica nessuno. Nexus MDS Core non è riconosciuto ad alcun livello di garanzia dell’Unione e, con la proposta così com’è scritta, non potrebbe esserlo.

Quello che l’allegato offre è il vocabolario pubblico più chiaro finora per descrivere dove si colloca un’installazione. Diversi suoi criteri trovano risposta nella struttura stessa di un’architettura self-hosted, non nei contratti: i dati, metadati e telemetria compresi, restano su un’infrastruttura di proprietà dell’organizzazione; nessun operatore esterno ha accesso amministrativo; il supporto lo eroga chi il cliente sceglie di incaricare; lo stack software è open source e ispezionabile, quindi SBOM, elenco delle dipendenze e piano di migrazione sono esercizi di documentazione, non negoziati.

Dove un’installazione usa un endpoint di inferenza esterno per la generazione finale — il modello ibrido sovrano documentato nel case study Federfarma — quel componente sta fuori dal perimetro e i criteri del CADA sul fornitore si applicano a chi lo gestisce. Dirlo chiaramente è il punto. La proprietà architetturale che conta è che il componente sia sostituibile, ed è esattamente la proprietà su cui l’Allegato II torna di continuo, in un altro registro: piani di migrazione, controllo effettivo sui componenti, separazione dalle entità di paesi terzi.

Se diventerà utile descrivere le installazioni nei termini del CADA — e per gli acquirenti pubblici lo diventerà — la corrispondenza con i tre modelli usati in questo sito è lineare. Un’installazione interamente locale elimina le domande che i livelli pongono, invece di rispondervi. Un’installazione ibrida sovrana risponde a tutto tranne che per l’endpoint di generazione, ed è lì che chi compra deve pretendere un servizio riconosciuto. L’inferenza privata in UE è il caso in cui il livello di garanzia del fornitore diventa l’intera risposta.

Cosa conviene fare adesso

• —Se sei un ente pubblico, o un fornitore di un ente pubblico: scopri quali delle tue attività toccherebbe una valutazione del rischio per l’ordine pubblico, perché è questo a stabilire se a tutto ciò che comprerai dopo si applica il livello 1 o i livelli 2–4.
• —Se sei un soggetto dell’Allegato I della NIS2: fai la valutazione d’impatto prima che diventi obbligatoria. L’esercizio è lo stesso in ogni caso, e farlo per tempo significa scegliere tu il perimetro.
• —Chiedi per iscritto a ogni fornitore di cloud e di AI quale livello intende ottenere e quando. La risposta, e la velocità con cui arriva, ti dicono più della slide di roadmap.
• —Fatti dare lo SBOM. È l’unico artefatto che serve insieme al CADA, al CRA e alla PLD 2024, e già la richiesta è diagnostica.
• —Individua quali componenti sarebbero insostituibili se un fornitore venisse ritirato o soggetto a restrizioni. È l’esposizione attorno a cui è costruita la proposta, ed è conoscibile già oggi.

Fonti

Questa analisi è scritta a partire dalla proposta, dai suoi allegati e dalla sintesi della valutazione d’impatto, tutti pubblicati dalla Commissione il 3 giugno 2026. Dove la pagina descrive cosa richiede una disposizione, fa fede il testo della proposta.

• COM(2026) 502 final — proposta di Cloud and AI Development Act — proposta della Commissione del 3 giugno 2026, con allegati e valutazione d’impatto
• Direttiva (UE) 2022/2555 — NIS2 — misure di gestione del rischio di cybersicurezza e notifica degli incidenti
• Regolamento (UE) 2024/2847 — Cyber Resilience Act — requisiti di sicurezza per i prodotti con elementi digitali; applicazione scaglionata
• Direttiva (UE) 2024/2853 — direttiva sulla responsabilità per danno da prodotti difettosi — il software come prodotto; recepimento da parte degli Stati membri entro il 9 dicembre 2026
• Regolamento (UE) 2024/1689 — AI Act — definizioni, classificazione del rischio, obblighi di provider e deployer
• Regolamento (UE) 2019/881 — Cybersecurity Act — la base dei sistemi europei di certificazione della cybersicurezza su cui poggiano i livelli di garanzia del CADA

Analisi normativa scritta a partire dall’esperienza di delivery in ambienti regolati. Non è una consulenza legale, descrive una proposta non ancora adottata, e i numeri degli articoli possono cambiare durante l’iter legislativo.