Siete direttori IT di un’assicurazione sanitaria tedesca soggetta a DORA e vigilanza BaFin. Il vostro consiglio vi ha appena inoltrato l’annuncio della Commissione europea sul Tech Sovereignty Package, adottato martedì 3 giugno 2026, con una sola frase: cosa significa questo per il nostro approvvigionamento cloud 2027? La gara vale 18 milioni di euro su cinque anni. Il vostro CIO vuole una nota di una pagina entro venerdì.

Il proposto Cloud and AI Development Act (CADA) è la parte del pacchetto che tocca più direttamente il vostro approvvigionamento. Classificherà i fornitori cloud in quattro livelli di sovranità. Il livello più alto — per la logica giuridica della proposta — non è raggiungibile dai fornitori con sede negli Stati Uniti, perché il CLOUD Act crea un conflitto strutturale. I dati finanziari, giudiziari e sanitari dei governi e delle organizzazioni del settore pubblico dovranno funzionare su infrastruttura al livello di sovranità più alto. La proposta è un regolamento ai sensi dell’Articolo 114 TFUE, che produce effetto direttamente applicabile sul mercato interno. Se passa intatta, gli Stati membri non potranno indebolirne l’applicazione individualmente.

Non passerà intatta, e non passerà entro il 2027. Il trilogo richiederà dai 18 ai 24 mesi. Il primo effetto pratico sul vostro approvvigionamento non è il regolamento in sé; è il linguaggio di gara che gli offerenti accorti stanno già preparando. La vostra gara da 18 milioni di euro che si chiude nell’autunno 2026 sarà letta da offerenti che si stanno posizionando per la classificazione CADA che presumono arriverà nel 2028 o 2029. Le risposte degli offerenti vi diranno chi prende sul serio la futura regolazione e chi no.

Questo articolo è l’audit di ciò che CADA propone, di ciò che i quattro livelli effettivamente richiedono, di ciò che il vostro fascicolo di gara dovrebbe già assumere sulla direzione del regolamento, e della domanda specifica a cui la nota di una pagina del vostro CIO deve rispondere prima della chiusura del ciclo di bilancio.

Cosa propone il pacchetto

Il Tech Sovereignty Package contiene quattro strumenti. Il primo è il Cloud and AI Development Act (CADA) con il quadro di classificazione della sovranità. Il secondo è il Chips Act 2.0, che aggiorna lo statuto del 2023 per elevare la quota target UE di produzione mondiale di chip. Il terzo è una Strategia Open Source che formalizza l’open source come elemento strutturale della politica digitale UE. Il quarto è una Roadmap Strategica per la Digitalizzazione e l’IA nell’Energia, presentata sul podio dal Commissario Dan Jørgensen insieme alla Commissaria Henna Virkkunen.

La cornice di Virkkunen al pacchetto, in conferenza stampa: “We want to be sure nobody has a kill switch.” — vogliamo essere sicuri che nessuno abbia un kill switch. Ursula von der Leyen ha avvolto la politica attorno: “We cannot afford to depend on others for the technologies that keep our hospitals running, our energy grids stable and our services secure.” — non possiamo permetterci di dipendere da altri per le tecnologie che mantengono i nostri ospedali in funzione, le nostre reti energetiche stabili e i nostri servizi sicuri. La cornice politica era la sovranità. La cornice di approvvigionamento — che è quella con cui la vostra gara deve confrontarsi — è classificazione, requisiti di livello obbligatori, e la base giuridica ai sensi dell’Articolo 114 TFUE che conferisce al regolamento effetto direttamente applicabile sul mercato interno.

La componente cloud è la più sostanziale per le decisioni di approvvigionamento di oggi. Il quadro a quattro livelli di CADA è una scala graduata di separazione strutturale dal controllo extra-UE: il Tier 1 copre dichiarazioni minime di residenza dei dati; il Tier 2 stabilisce indipendenza operativa dal controllo extra-UE; il Tier 3 richiede piena separazione architetturale dalle dipendenze extra-UE; il Tier 4 rivendica continuità verificabile in condizioni geopolitiche ostili. Il requisito Tier 3 obbligatorio per i dati governativi finanziari, giudiziari e sanitari è la parte che incide direttamente sul vostro approvvigionamento. Lo faranno rispettare le autorità nazionali designate.

Cosa richiedono effettivamente i quattro livelli, in linguaggio operativo

Il testo della proposta della Commissione descrive i livelli in linguaggio regolatorio. La traduzione operativa è ciò di cui il vostro team architetturale ha bisogno.

Il Tier 1 è la dichiarazione di residenza dei dati. Il vostro fornitore si impegna, contrattualmente, a mantenere i dati su suolo UE. Questo è ciò che la maggior parte delle attuali offerte cloud sovrane europee dichiara — Microsoft Azure Sovereign Cloud, AWS European Sovereign Cloud, Google Cloud Sovereign — e ciò che la maggior parte di tali offerte effettivamente consegna. Il Tier 1 è compatibile con l’operatività dei fornitori con sede negli Stati Uniti. La maggior parte dei contratti M365 esistenti, con le clausole di residenza dei dati già in essere, soddisferebbe il Tier 1 senza alcun cambiamento architetturale.

Il Tier 2 aggiunge indipendenza operativa dal controllo extra-UE. Il vostro fornitore si impegna non soltanto alla residenza UE, ma a decisioni operative prese da entità con sede UE. Questo è il livello in cui le varianti sovrane dei fornitori con sede negli Stati Uniti si qualificano o meno a seconda della struttura contrattuale. L’architettura attuale di Microsoft Sovereign Cloud è ingegnerizzata per qualificarsi per il Tier 2 strutturando il controllo operativo attraverso la filiale irlandese di Microsoft con un’opzione di residenza dati in Polonia. Se questa qualificazione sopravviverà all’interpretazione di “operational independence” — indipendenza operativa — da parte del trilogo è una delle domande aperte.

Il Tier 3 richiede piena separazione architetturale dalle dipendenze extra-UE. Questo è il livello da cui la logica giuridica della proposta esclude i fornitori con sede negli Stati Uniti. Il CLOUD Act crea un conflitto strutturale che nessuna struttura contrattuale può eliminare. Il Tier 3 è il regno di OVHcloud, Outscale, StackIT di Schwarz Digits, IONOS, T-Systems Open Telekom Cloud, e la piattaforma federale KIPITZ. Per il vostro approvvigionamento di assicurazione sanitaria, il Tier 3 è il vincolo sostanziale: i carichi di lavoro con dati finanziari e sanitari dovranno, sulla proposta attuale, funzionare lì.

Il Tier 4 rivendica continuità verificabile in condizioni geopolitiche ostili. I criteri per il Tier 4 non sono ancora enumerati nella proposta pubblica. La continuità in condizioni ostili è la proprietà che un’organizzazione possiede quando può continuare a operare se un qualsiasi singolo fornitore, incluso quello principale, diventa indisponibile. Operativamente, il Tier 4 richiede portabilità multi-fornitore, infrastruttura mirror extra-UE per le dipendenze di distribuzione del codice sorgente, e un piano di continuità che sia stato esercitato. Secondo la definizione di lavoro che il testo della proposta suggerisce, il Tier 4 è la proprietà che nessun fornitore europeo attuale può ancora credibilmente rivendicare. La definizione dei criteri sarà tra gli elementi più contestati del trilogo.

Cosa il vostro fascicolo di gara dovrebbe assumere nel 2026

La vostra gara da 18 milioni di euro che si chiude nell’autunno 2026 sarà aggiudicata in un ambiente regolatorio che ancora non esiste. Tre assunzioni, scritte nel bando e nel fascicolo di gara, determineranno se il contratto aggiudicato nel 2026 sopravvive a CADA quando CADA atterrerà.

Assumete il Tier 3 per i carichi di lavoro con dati sanitari e finanziari. Anche se CADA fosse ammorbidito nel trilogo, lo strato di appalti federali tedesco, lo strato di vigilanza BaFin e il quadro DORA stanno convergendo sull’assunzione che i dati sensibili finanziari e sanitari non debbano funzionare su infrastruttura cloud con sede negli Stati Uniti. Una gara del 2026 che blocca i sistemi core della vostra assicurazione sanitaria in un’offerta Tier 1 di un fornitore statunitense per cinque anni, entro il 2028, opererà sotto un quadro regolatorio che la vuole migrata. Costruite l’opzionalità di migrazione nel contratto 2026; è più economico negoziare clausole di uscita alla firma che in sede di modifica.

Richiedete agli offerenti di rivelare la loro roadmap di livello CADA. La vostra gara dovrebbe chiedere a ciascun offerente, formalmente, a quale livello CADA prevede di poter essere certificato entro il 2028 e quali cambiamenti architetturali ha assunto come impegno per raggiungere tale livello. Gli offerenti con una roadmap seria risponderanno per iscritto con cambiamenti tecnici nominati. Gli offerenti con una risposta di posizionamento daranno linguaggio di marketing. La differenza è il dato più informativo che il vostro processo di approvvigionamento estrarrà.

Inserite nella gara già ora i riferimenti a EVB-IT e §58 VgV Nr. 4. Lo strato del diritto federale degli appalti supporta già il linguaggio di cui avrete bisogno quando CADA atterrerà. Citare il §58 VgV Nr. 4 e i termini contrattuali EVB-IT per l’open source nella gara 2026 fa due cose: stabilisce precedente sul vostro stesso fascicolo di gara, e segnala agli offerenti che il vostro ufficio appalti è impegnato con lo strato federale di sovranità anziché reattivo a esso.

Cosa CADA non affronta

I quattro livelli coprono l’infrastruttura cloud e certe categorie di dati governativi. Non affrontano, nella proposta attuale, gli strati sotto il cloud.

L’infrastruttura di hosting del codice resta prevalentemente ospitata negli Stati Uniti. Il codice sorgente dello stack di sovranità europea vive su GitHub — di proprietà Microsoft. Il requisito Tier 3 di CADA di separazione architetturale dalle dipendenze extra-UE non, su una lettura rigorosa del testo della proposta, si estende all’infrastruttura di build e distribuzione delle componenti open source su cui il cloud gira. Questo è lo stesso divario che il lancio di Euro-Office rende visibile altrove, e CADA al momento non lo chiude.

Catene di fiducia crittografica. Le autorità di certificazione e le operazioni dei server radice DNS restano dominate dagli Stati Uniti. I livelli di sovranità di CADA non enumerano esplicitamente criteri di catena di fiducia. Un fornitore classificato Tier 3 può ancora dipendere da autorità di certificazione le cui chiavi radice sono controllate negli Stati Uniti.

CI/CD e distribuzione dei pacchetti. GitHub Actions, npm, PyPI, Docker Hub, Maven Central — l’infrastruttura di build, packaging e distribuzione da cui dipende ogni cosa rimane prevalentemente ospitata negli Stati Uniti. Un fornitore può essere Tier 3 sulla dimensione runtime e Tier 1 sulla dimensione della catena di fornitura. CADA al momento non distingue.

Questa non è una critica all’ambito redatto. È l’osservazione che CADA non, da solo, consegna sovranità della catena di fornitura ai livelli sotto l’infrastruttura cloud. Il vostro fascicolo di gara dovrebbe riconoscere il limite esplicitamente. Un lettore che celebra CADA come il completamento del progetto di sovranità europea leggerà qualcosa che la proposta non rivendica — e che il vostro CIO trarrà beneficio dal nominare per iscritto prima del prossimo ciclo regolatorio.

Cosa non è questo articolo

Non è un’affermazione secondo cui CADA passerà come redatto — il trilogo modificherà la proposta; la domanda è di quanto. Non è un’affermazione secondo cui la Strategia Open Source sia vuota — inquadra strutturalmente l’OSS; se produca budget è una domanda separata, decisa nel prossimo ciclo del Multiannual Financial Framework piuttosto che a giugno 2026. Non è un’affermazione secondo cui la sovranità europea sia risolta dal pacchetto. Il pacchetto affronta uno strato di dipendenza, ne lascia altri intoccati, e dipende da un processo legislativo che corre nel 2027 o 2028.

La nota che il vostro CIO vuole entro venerdì

La nota di una pagina dovrebbe fare tre affermazioni e raccomandare due azioni.

Le tre affermazioni: CADA sarà legge entro il 2028 o 2029; il probabile requisito Tier 3 per i carichi di lavoro finanziari e sanitari sopravviverà al trilogo sostanzialmente nella forma proposta; lo strato della catena di fornitura non sarà affrontato da CADA in questo ciclo e richiederà attenzione di approvvigionamento separata.

Le due azioni raccomandate: redigere la gara dell’autunno 2026 con divulgazione obbligatoria da parte dell’offerente della roadmap di livello CADA e della tempistica di separazione architetturale; costruire audit della catena di fornitura e infrastruttura mirror Codeberg-o-equivalente lato cliente, indipendentemente dal fornitore eventuale, perché quel lavoro è richiesto indipendentemente dal livello CADA a cui il fornitore alla fine si certificherà.

Una nota che fa quelle affermazioni e raccomanda quelle azioni, a livello del consiglio, si legge come impegno con la direzione regolatoria. Una nota che dice “la situazione è in evoluzione e monitoreremo” si legge come il tipo di preparazione che non sopravvive a un audit di conformità BaFin del 2029. La gara dell’autunno 2026 è il fascicolo che sarà citato in tale audit se va bene, o di cui si scriverà nella stampa regolatoria se non va bene.

Fonti

Panoramica del tema: Sovranità Digitale in Europa Articoli correlati: Come citare il §58 VgV Nr. 4, Il fornitore ha scritto il test