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 dovrebbe fare

La proposta era attesa per la prima parte del 2026 come norma di punta del programma di lavoro della Commissione. Gli obiettivi dichiarati sono gli stessi in tutti gli annunci:

Rafforzare la capacità europea di sviluppare, distribuire e scalare cloud e IA. In concreto vuol dire calcolo, data center e possibilità di addestrare e far girare grandi modelli dentro l'UE.

Colmare i vuoti normativi. Oggi il cloud è coperto soprattutto dalle disposizioni sul cambio fornitore del regolamento sui dati e dagli obblighi di sicurezza di NIS2. Né le une né gli altri toccano capacità e dipendenza strategica.

Promuovere l'interoperabilità. Cioè abbassare il costo tecnico di spostarsi da un fornitore all'altro, lo stesso obiettivo che il regolamento sui dati affronta dal lato contrattuale.

Definire una politica cloud a livello UE per le amministrazioni pubbliche e gli appalti. Questa è quella che morde davvero. Un approccio comune al modo in cui gli enti pubblici degli Stati membri comprano cloud, con una dimensione di preferenza europea.

Sostenere un ecosistema europeo di cloud e IA sicuro e competitivo. La voce buona per tutto.

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 di quanto annunciato lascia pensare che alle aziende private verrà vietato 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. Se questo basti a soddisfare una futura regola di appalto è esattamente la domanda a cui la norma dovrà rispondere, e a cui finora non ha risposto.

È una proposta. Finché non c'è un testo con attorno le posizioni di Consiglio e Parlamento, i dettagli non si possono sapere. Quello che si sa è 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 dell'interoperabilità.

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, seguite il fronte degli appalti più da vicino della norma stessa. È lì che il requisito comparirà per primo, sotto forma di criterio di qualificazione.

Non migrate sulla base di ipotesi. Spostare l'infrastruttura per una proposta non ancora pubblicata è 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.