Il Cloud and AI Development Act: cosa sta davvero cercando di risolvere l'Europa

Il Cloud and AI Development Act è finora la dichiarazione più esplicita di cosa sia diventata la politica tecnologica europea. Non è una norma di tutela del consumatore e non è una norma di sicurezza. È politica industriale puntata su un problema solo: l'Europa fa girare gran parte della propria economia digitale su infrastrutture che non controlla.

È una regolazione di natura diversa dal GDPR o dal regolamento sull'IA, e vi arriverà addosso per una strada diversa. Capire quale sia conta più che leggersi i considerando.

Il problema a cui risponde

Sui numeri di partenza non discute nessuno. La stragrande maggioranza della spesa cloud europea finisce a fornitori non europei. I modelli di IA più grandi che le aziende europee usano sono addestrati e ospitati fuori dall'Europa. La capacità di calcolo europea è una frazione minima del totale mondiale.

Per un decennio è stato considerato un normale esito di mercato. Dal 2022 è considerato una vulnerabilità strategica, per ragioni che con la tecnologia non c'entrano nulla: tensioni commerciali, controlli sulle esportazioni e la scoperta che la dipendenza infrastrutturale è un'arma negoziale.

Il Cloud and AI Development Act è il braccio legislativo di questo ripensamento. Si affianca al piano d'azione per il continente dell'IA, all'iniziativa InvestAI, al programma delle gigafabbriche di IA e all'agenda per la competitività uscita dal rapporto Draghi.

Cosa prevede la proposta

La Commissione ha pubblicato la proposta il 3 giugno 2026 come COM(2026) 502, insieme a un Chips Act 2.0. È un regolamento, costruito attorno a tre obiettivi e a una serie di misure per il settore pubblico:

Ricerca e innovazione. Cloud and AI Leadership Initiatives per grandi progetti intersettoriali, una rete di AI Experience and Acceleration Centres costruita sui poli europei dell'innovazione digitale, capacità di calcolo assegnata a progetti prioritari di IA di frontiera e una strategia nazionale per il cloud e l'IA in ogni Stato membro entro un anno dall'entrata in vigore.

Capacità dei data center. Gli Stati membri designano zone di accelerazione per i data center con un punto unico di informazione e autorizzazioni più rapide, e la Commissione può designare progetti strategici di data center. L'obiettivo dichiarato è almeno triplicare la capacità dei data center dell'UE entro il 2030, con ogni autorizzazione per un nuovo data center ottenibile in meno di 18 mesi.

Un quadro di sovranità per il cloud. Quattro livelli di affidabilità dell'Unione. Il livello 1 è un'autovalutazione; i livelli da 2 a 4 sono verificati da terzi. Il livello 3 richiede che il fornitore non sia controllato da un paese terzo, a meno che la Commissione non abbia riconosciuto che quel paese offre garanzie sufficienti. I servizi riconosciuti finiscono in un registro centrale dell'UE.

Adozione nel settore pubblico. Questa è quella che morde davvero. Gli acquirenti pubblici devono acquistare servizi cloud riconosciuti almeno al livello 1. Se una valutazione del rischio stabilisce che un'attività contribuisce all'ordine pubblico (tra l'altro nei settori NIS2, nella sicurezza nazionale, nella difesa, nella giustizia e nelle attività di contrasto), sono ammessi solo i livelli 2, 3 o 4. Gli Stati membri devono inoltre applicare criteri di valore aggiunto dell'Unione quando comprano cloud e IA, una EuroCloud Federation permette agli enti pubblici di condividere servizi cloud, e gli enti pubblici devono incoraggiare e agevolare l'uso dell'open source rispetto al software proprietario.

Poco che vincoli gli acquirenti privati. Le aziende dei settori NIS2 possono svolgere la stessa valutazione del rischio su base volontaria, e la Commissione potrebbe renderla obbligatoria per i settori altamente critici con un atto delegato. Così com'è proposto, il regolamento si applicherebbe un anno dopo l'entrata in vigore, ma deve ancora passare per Parlamento e Consiglio.

Il meccanismo che vi raggiungerà davvero

Ecco il punto da capire su questo dossier. La maggior parte della regolazione tecnologica arriva alle aziende private per via diretta: trattate dati personali, quindi il GDPR vi si applica. Il Cloud and AI Development Act, alla maggior parte delle aziende, arriverà con ogni probabilità per via indiretta, attraverso gli appalti.

La spesa tecnologica del settore pubblico nell'UE è enorme. Se gli enti pubblici degli Stati membri saranno obbligati, o fortemente incoraggiati, a comprare cloud europeo, cambia il mercato raggiungibile di ogni fornitore che vende al settore pubblico, e l'effetto scende a cascata dai contraenti principali fino ai loro subfornitori.

Lo schema lo conosciamo già dall'accessibilità. La direttiva europea sull'accessibilità impone obblighi diretti, ma nella pratica gran parte del lavoro sull'accessibilità è stata spinta dalle regole di appalto che escludevano i fornitori non conformi molto prima che la direttiva diventasse applicabile.

Aspettatevi lo stesso qui. Se vendete software ad acquirenti pubblici europei, le domande su dove gira l'infrastruttura, chi la gestisce e se è migrabile passeranno dal questionario di sicurezza ai criteri di qualificazione.

Cosa comporta per l'architettura

Davanti a una politica di sovranità l'istinto è ignorarla oppure migrare tutto in preda al panico. Nessuna delle due strade va bene. Quello che ha senso è assicurarsi che alla domanda si sappia rispondere.

Sappiate dove girano davvero dati e calcolo

Sembra banale, e non lo è. In un sistema maturo la risposta onesta a «dove gira questa cosa» chiama in causa una regione primaria, una di backup, una CDN con nodi edge poco chiari, un database gestito, tre dipendenze SaaS con i loro subresponsabili, un fornitore di osservabilità e un'API di IA di cui non è documentato dove avvenga l'inferenza.

Costruire una mappa accurata è il primo lavoro serio, ed è la stessa mappa che serve per l'analisi dei trasferimenti GDPR e per le domande di NIS2 sulla catena di fornitura. Fatela una volta sola.

Separate ciò che è portabile da ciò che non lo è

Quasi ogni sistema ha un nucleo portabile e una serie di dipendenze legate al singolo fornitore. Il nucleo portabile di solito è l'applicazione. Le parti non portabili di solito sono i servizi gestiti: database proprietari, runtime serverless, code, identità e, sempre di più, le API dei modelli.

Non è detto che vadano eliminate. Va però saputo quali sono, perché quell'elenco è la risposta onesta a quanto costerebbe una migrazione, ed è esattamente ciò che un questionario di gara vi sta chiedendo.

Trattate i fornitori di modelli come un confine di astrazione

È il punto più recente e quello che si salta più spesso. Le applicazioni che chiamano direttamente l'API di un singolo fornitore, con formati di prompt e gestione delle risposte sparsi per il codice, hanno preso una decisione di dipendenza senza accorgersene.

Un sottile strato di astrazione sulle chiamate ai modelli costa pochissimo da scrivere e vi lascia la libertà di dirottare il traffico su un fornitore europeo, su un modello a pesi aperti ospitato in Europa o su un fornitore completamente diverso. Vista la velocità con cui si muove il panorama dei modelli, conviene farlo anche solo per ragioni commerciali.

Provate l'uscita, non limitatevi a documentarla

Il regolamento sui dati vi dà già il diritto di cambiare fornitore cloud, e dal 12 gennaio 2027 i costi di passaggio spariscono del tutto. Pochissimi acquirenti usano quel diritto, e ancora meno verificano se l'esportazione a cui hanno diritto basterebbe davvero a rimettere in piedi il servizio.

Eseguite davvero l'esportazione. Provate a interpretarla. Il divario tra ciò che un fornitore dichiara esportabile e ciò che è effettivamente utilizzabile è il posto in cui abita il lock-in, ed è anche la risposta onesta a una domanda sulla sovranità.

Cosa non è

Un po' di sano scetticismo ci sta, ed è meglio guardarci dentro adesso che restarne sorpresi dopo.

Non è un divieto del cloud americano. Nulla nella proposta vieta alle aziende private di usare fornitori non europei. Il meccanismo è la preferenza negli appalti e la costruzione di capacità, non il divieto.

La capacità non nasce perché lo scrive una legge. La capacità cloud europea è limitata perché costruire data center e addestrare modelli di frontiera richiede molto capitale, e fino a poco tempo fa l'Europa non ne aveva impegnato alla scala necessaria. I programmi di finanziamento descritti nella nostra guida ai finanziamenti tecnologici UE sono lo strumento vero. La norma è la cornice che ci sta attorno.

Un'etichetta «sovrano» non fa sovranità. Diverse offerte si presentano come cloud sovrano pur girando su tecnologia non europea concessa in licenza, con gradi molto diversi di indipendenza operativa. La risposta della proposta sono i livelli di affidabilità: il controllo da un paese terzo tiene un servizio fuori dal livello 3 e superiori, a meno che la Commissione non riconosca quel paese. Dove cadrà alla fine il confine tra i livelli 2 e 3 lo decideranno i negoziati.

È una proposta. Ora un testo c'è, ma al 10 ottobre 2026 né il Consiglio né il Parlamento hanno una posizione in merito, e in Parlamento il fascicolo è ancora nelle commissioni ITRE e IMCO. I livelli di affidabilità sono la parte che ha più probabilità di cambiare. La direzione è rimasta la stessa in tre anni di comunicazioni della Commissione.

Come si collega a tutto il resto

Il Cloud and AI Development Act è un pezzo di una spinta coordinata, e letto da solo sembra più debole di quanto sia.

Il regolamento sull'IA disciplina il comportamento dei sistemi di IA. Il regolamento sui dati aggredisce il lock-in cloud per via contrattuale. NIS2 fa scendere lungo la filiera il controllo sui fornitori. Il regolamento sulla ciberresilienza mette obblighi di sicurezza sui prodotti. InvestAI e il programma delle gigafabbriche mettono soldi sulla capacità di calcolo. Il Cloud and AI Development Act aggiunge il livello degli appalti e della sovranità.

Presi uno per uno sembrano tanti oneri aggiuntivi. Messi insieme descrivono una scommessa piuttosto coerente: che l'Europa possa arrivare a una base tecnologica propria a colpi di norme, combinando regole di accesso al mercato e denaro pubblico.

Se la scommessa sia vincente è una domanda legittima. Che la puntata sia stata fatta, no.

Cosa fare nei prossimi dodici mesi

Costruite la mappa dell'infrastruttura. Dove gira ogni cosa, chi la gestisce, qual è la via d'uscita contrattuale. Vi tornerà utile in altri quattro contesti.

Individuate le dipendenze davvero non portabili e quantificate onestamente il costo della migrazione, anche se non la farete mai. È la risposta alla domanda che vi arriverà in gara ed è comunque buona igiene architetturale.

Mettete un'astrazione sopra i fornitori di modelli, se non l'avete già. Costa poco adesso e costerà molto dopo, e serve per ragioni che con la politica non c'entrano.

Se vendete ad acquirenti pubblici europei, verificate quale livello di affidabilità potrebbe raggiungere il vostro servizio. È nelle regole sugli appalti della norma che il requisito comparirebbe per primo, sotto forma di criterio di qualificazione, e il Public Procurement Act proposto il 9 settembre 2026 ci aggiunge sopra un quadro generale di preferenza europea.

Non migrate sulla base di ipotesi. Spostare l'infrastruttura per una proposta che nessuno ha ancora negoziato è il modo classico di bruciare un anno e un budget importante per qualcosa che poi non serviva.

Ottenere aiuto

Progettiamo e costruiamo infrastruttura cloud, piattaforme di dati e integrazioni di IA per aziende che operano in Europa, compreso il lavoro ingrato di rendere un sistema davvero portabile e non portabile soltanto sulla carta.

Se vi serve una mappa di infrastruttura e dipendenze, una prova di uscita dal vostro fornitore attuale o uno strato di astrazione sopra i fornitori di modelli, scrivete a office@c9group.dev. Trovate altro sul nostro lavoro infrastrutturale alla pagina sull'ottimizzazione dei costi AWS e sul nostro lavoro europeo alla pagina dedicata all'ingresso nel mercato UE.

Il quadro legislativo più ampio è nella nostra pipeline legislativa digitale dell'UE, e i soldi dietro questa agenda sono mappati nella guida ai finanziamenti tecnologici UE.

Siamo ingegneri, non consulenti di politiche pubbliche. Questo è uno sguardo di pianificazione su una proposta, non una consulenza legale.