Lo switching cloud Data Act è una delle leve più dirompenti del Regolamento UE 2023/2854. Il Capo VI (artt. 23-31) impone ai fornitori di servizi di trattamento dei dati obblighi tecnici e contrattuali pensati per eliminare il vendor lock-in: tempi precisi per il passaggio, clausole contrattuali standard, abolizione delle tariffe di uscita entro il 12 gennaio 2027. Per chi usa AWS, Azure, Google Cloud o piattaforme SaaS le regole sono cambiate. Per chi vende cloud, IaaS, PaaS e SaaS l’adeguamento contrattuale è già scaduto.

1. Cosa cambia con il Capo VI del Data Act

Il Capo VI del Regolamento è la parte del Data Act che colpisce direttamente l’ecosistema cloud europeo. Si applica a tutti i fornitori di servizi di trattamento dei dati ai sensi dell’art. 2, n. 8: una definizione ampia che copre cloud computing, edge computing, IaaS, PaaS, SaaS, ma anche varianti emergenti come Storage-as-a-Service, Database-as-a-Service, Data-as-a-Service e AI-as-a-Service. Il legislatore ha scelto deliberatamente una formulazione tecnologicamente neutra, per evitare che il Regolamento invecchi rapidamente.

L’obiettivo è dichiarato nel considerando 79: la capacità di passare da un servizio all’altro mantenendo funzionalità minima e senza tempi di inattività è “una condizione fondamentale per un mercato più competitivo con minori barriere all’ingresso”. In altre parole, l’Unione vuole rompere il dominio dei grandi provider extraeuropei e dare ai clienti europei una vera libertà di scelta.

Le regole sono applicabili dal 12 settembre 2025. Una particolarità rilevante: a differenza del Capo IV sulle clausole abusive, il Capo VI non prevede un regime transitorio per i contratti già in essere. Significa che gli accordi cloud sottoscritti prima di quella data devono comunque essere adeguati ai nuovi obblighi, e questo è un punto su cui molti contratti di lungo periodo sono ancora carenti.

2. Le tre fasi dello switching: un processo strutturato

L’art. 25 del Regolamento disciplina il passaggio come un processo articolato in tre fasi distinte, ciascuna con tempi e oneri precisi.

2.1 Prima fase: l’avvio e il preavviso

Il processo è attivato dalla comunicazione del cliente al fornitore. Il Regolamento non prescrive una forma specifica, ma il contratto può legittimamente stabilire requisiti formali, purché non costituiscano ostacoli irragionevoli. Il termine massimo di preavviso non può superare due mesi (art. 25, par. 2, lett. d). Le parti possono pattuire termini più brevi, ma non più lunghi.

Durante il preavviso il fornitore deve garantire la continuità operativa, fornire assistenza ragionevole al cliente e ai terzi autorizzati, comunicare ogni rischio noto che potrebbe compromettere il servizio.

2.2 Seconda fase: il periodo transitorio

Alla scadenza del preavviso si apre il periodo transitorio massimo obbligatorio di 30 giorni di calendario durante il quale deve avvenire il trasferimento effettivo. Il contratto resta applicabile per tutto il periodo, e l’art. 25, par. 2, lett. a) elenca quattro obblighi che gravano sul fornitore di origine:

• fornire assistenza ragionevole al cliente e ai terzi da questi autorizzati;
• agire con la diligenza dovuta per mantenere la continuità operativa e proseguire la fornitura delle funzioni e dei servizi previsti dal contratto;
• dare informazioni chiare sui rischi noti per la continuità della fornitura;
• garantire un elevato livello di sicurezza per tutto il processo, in particolare durante il trasferimento dei dati e per l’intero periodo di conservazione.

Il Regolamento non fissa un termine per notificare un incidente durante questa fase: gli obblighi di notifica restano quelli che derivano da altre discipline, a partire dal GDPR per i dati personali e dalla NIS 2 per i soggetti che vi rientrano. Chi vuole un termine contrattuale deve negoziarlo, perché non lo trova nel Data Act.

Una deroga è prevista in caso di impossibilità tecnica (art. 25, par. 4): il fornitore può estendere il periodo transitorio fino a sette mesi, ma deve informare il cliente entro 14 giorni lavorativi dalla richiesta motivando l’impossibilità. La versione inglese del Regolamento parla di technical unfeasibility, non di impossibilità in senso assoluto. Il considerando 87 chiarisce che l’onere della prova è interamente del fornitore. È un’eccezione che va negoziata e documentata caso per caso.

C’è poi una facoltà che sta dal lato opposto e che i contratti dimenticano quasi sempre. L’art. 25, par. 5 impone che il contratto riconosca al cliente il diritto di prorogare il periodo transitorio una volta, per la durata che il cliente stesso ritiene più appropriata ai propri fini. Non è una concessione del fornitore: è una clausola che il contratto deve contenere, e la sua assenza è di per sé una carenza.

2.3 Terza fase: il recupero dei dati

Dopo il periodo transitorio inizia un periodo minimo di 30 giorni per il recupero dei dati esportabili (art. 25, par. 2, lett. g). Solo allo scadere di questo termine il fornitore può procedere alla cancellazione definitiva. Il contratto resta applicabile durante questa fase, ma con effetti limitati agli aspetti di accesso e recupero, non all’erogazione del servizio originario.

Riassumendo: tra preavviso, periodo transitorio e recupero dati, un’azienda può chiudere uno switching completo in circa quattro mesi nel caso standard, fino a dodici mesi nel caso di impossibilità tecnica documentata.

3. Equivalenza funzionale e interfacce aperte: la differenza tra IaaS, PaaS e SaaS

L’art. 30 del Regolamento differenzia gli obblighi tecnici a seconda del modello di servizio. È una distinzione fondamentale che molti contratti cloud ancora non rispecchiano correttamente.

3.1 Per i servizi IaaS: equivalenza funzionale

I fornitori di servizi IaaS (Infrastructure-as-a-Service) devono garantire l’equivalenza funzionale dopo il passaggio. L’art. 2, n. 37 la definisce come il ripristino di un livello minimo di funzionalità nell’ambiente del nuovo servizio dello stesso tipo, con risultati sostanzialmente comparabili in risposta al medesimo input. La scelta normativa si spiega: l’infrastruttura IaaS si basa su risorse relativamente standardizzate (vCPU, RAM, storage, networking), quindi un’equivalenza tecnica è teoricamente raggiungibile e il lock-in si annida nelle configurazioni e nelle orchestrazioni specifiche.

3.2 Per i servizi PaaS e SaaS: interfacce aperte

Per i fornitori PaaS (Platform-as-a-Service) e SaaS (Software-as-a-Service) l’art. 30, par. 2 impone invece di rendere disponibili interfacce aperte, e aggiunge due qualificazioni che pesano più di quanto sembri: devono essere messe a disposizione a titolo gratuito e in egual misura per tutti i clienti e per i fornitori di destinazione interessati. Un’interfaccia a pagamento, o riservata ai clienti del piano superiore, non soddisfa la norma. Le interfacce devono inoltre contenere informazioni sufficienti sul servizio da consentire lo sviluppo di software che vi comunichi, ai fini della portabilità e dell’interoperabilità.

Va ricordato anche l’art. 30, par. 3, che per gli stessi servizi impone la compatibilità con le specifiche comuni basate su specifiche di interoperabilità aperte o norme armonizzate, almeno dodici mesi dopo la pubblicazione dei relativi riferimenti. L’offerta PaaS e SaaS è troppo eterogenea per imporre equivalenza funzionale: ogni fornitore costruisce il servizio con asset e processi propri. Le interfacce aperte (tipicamente REST API) sono un compromesso tra portabilità e libertà progettuale.

3.3 Verifica pratica del contratto

Una clausola che prevedesse “equivalenza funzionale” per un servizio SaaS sarebbe tecnicamente fuorviante. Allo stesso modo, un contratto IaaS che si limitasse a promettere “interfacce aperte” senza equivalenza funzionale sarebbe carente rispetto agli obblighi del Regolamento. La revisione contrattuale richiede di mappare correttamente il modello di servizio offerto e di calibrare gli obblighi tecnici di conseguenza.

4. Le clausole contrattuali standard: dal gruppo di esperti al progetto della Commissione

Qui il quadro si è mosso, e vale la pena ricostruirlo in ordine perché i due documenti circolano insieme e non sono la stessa cosa.

L’art. 41 del Regolamento imponeva alla Commissione, «prima del 12 settembre 2025», di elaborare e raccomandare clausole contrattuali tipo per l’accesso ai dati e clausole contrattuali standard per i contratti di cloud computing. Il lavoro preparatorio è stato svolto dall’Expert Group on B2B Data Sharing and Cloud Computing Contracts, che ha pubblicato il proprio Final Report il 2 aprile 2025 proponendo sette serie di clausole.

Il 19 novembre 2025 la Commissione ha approvato, sulla base di quel report, un progetto di raccomandazione che raccoglie le clausole per i servizi di trattamento dei dati negli allegati da VI a XII.

È un progetto, e va detto. Il documento porta l’intestazione «draft», il blocco della firma è in bianco, e la pagina istituzionale della Commissione dedicata al Data Act lo elenca ancora come progetto. Il termine dell’art. 41 è quindi scaduto senza che una raccomandazione formale sia stata adottata.

4.1 Cosa cambia in pratica

Poco, e in meglio. Le clausole erano già utilizzabili quando erano una proposta di un gruppo di esperti, e restano utilizzabili adesso: sono non vincolanti per definizione, e la loro utilità è di offrire un testo già calibrato sugli obblighi del capo VI a chi deve negoziare.

Quello che cambia è il peso da attribuirvi. Un allegato a un progetto di raccomandazione della Commissione non è la stessa cosa di un allegato al report di un gruppo di lavoro, ed è un argomento più solido nella trattativa con un fornitore che le rifiuti.

Le sette serie coprono definizioni ed elementi comuni, il passaggio e l’uscita, la risoluzione del contratto, sicurezza e continuità operativa, responsabilità, stabilità contrattuale e accessibilità centralizzata della documentazione.

La logica è che siano integrate in un unico master services agreement, in modo da coprire tutti i servizi offerti dallo stesso fornitore e garantire continuità anche nei passaggi parziali. Cliente e fornitore possono scegliere quali adottare, ma conviene prenderle in blocco per coerenza interpretativa.

Sul passaggio e l’uscita sono previste due opzioni. La prima si fonda su un piano dettagliato di switching ed exit allegato al contratto, adatto ai servizi complessi. La seconda si fonda su strumenti automatizzati di self-service, che possono risultare inadeguati per i servizi SaaS in cui il passaggio richiede interventi manuali.

5. L’abolizione delle tariffe di passaggio: il calendario

L’art. 29 del Regolamento disciplina l’abolizione graduale delle tariffe di passaggio, con un calendario in due fasi che cambia profondamente i modelli di business dei fornitori cloud.

Fino al 12 gennaio 2027 opera un regime transitorio: i fornitori possono continuare ad addebitare tariffe per il processo di passaggio, ma in misura limitata. L’art. 29, par. 2 stabilisce che le tariffe non possono superare i costi direttamente connessi al processo di passaggio sostenuti dal fornitore.

Dal 12 gennaio 2027 scatta l’abolizione totale. Da quella data i fornitori non possono più richiedere alcun compenso economico per gli asset digitali necessari al passaggio, né per l’uscita dei dati dalla piattaforma (le cosiddette egress fees, oggi tra le voci di costo più pesanti del cloud).

Una distinzione cruciale spesso fraintesa: l’abolizione non riguarda le spese standard di servizio. Il considerando 89 lo chiarisce espressamente. Le tariffe per la normale fornitura del servizio continuano ad applicarsi fino alla cessazione del contratto: quello che viene abolito è soltanto il sovrapprezzo legato al passaggio.

Distinta è anche la situazione del trasferimento continuativo: quando il cliente usa simultaneamente più servizi interoperabili tramite API, il flusso continuo di dati non rientra nelle tariffe di passaggio e può continuare a essere remunerato anche dopo il 2027, nei limiti dei costi effettivamente sostenuti.

6. Trasparenza informativa: cosa il fornitore deve pubblicare

Il Capo VI introduce obblighi di trasparenza articolati su due livelli, ai sensi degli artt. 26 e 28 del Regolamento.

Verso il cliente, il fornitore deve mettere a disposizione un registro online aggiornato con le procedure di passaggio, i formati di dati esportabili, gli strumenti tecnici disponibili (incluse le interfacce aperte), le specifiche di interoperabilità e le restrizioni tecniche note. Il registro può essere accessibile solo ai clienti, senza obbligo di pubblicazione web.

Verso il pubblico, l’art. 28, par. 1 impone al fornitore di pubblicare sul proprio sito web informazioni sulla giurisdizione cui è soggetta l’infrastruttura TIC utilizzata per il trattamento e sulle misure tecniche, organizzative e contrattuali adottate per impedire l’accesso governativo internazionale ai dati non personali detenuti nell’Unione. È un obbligo che si lega all’art. 32 sul trasferimento extra-UE dei dati non personali. L’art. 28, par. 2 aggiunge che quei siti web vanno elencati nei contratti: non basta pubblicare la pagina, il contratto deve dire dove si trova.

Un ulteriore obbligo informativo precontrattuale è previsto dall’art. 29, par. 4: prima della stipula del contratto, il fornitore deve informare il cliente sulle spese standard, sulle eventuali sanzioni per risoluzione anticipata e sulle tariffe di passaggio ridotte applicabili fino alla scadenza del periodo transitorio.

7. Casi speciali: cosa cambia per offerte gratuite, servizi su misura e cloud credits

L’art. 31 del Regolamento individua regimi differenziati per due categorie di servizi.

I servizi non destinati alla produzione, forniti a fini di prova e valutazione per un periodo limitato, beneficiano di un’esenzione completa dagli obblighi del Capo VI. Si tratta delle versioni beta, dei sandbox di test e delle anteprime.

I servizi su misura, definiti dall’art. 31, par. 1 come servizi le cui caratteristiche principali sono state personalizzate per le esigenze di un singolo cliente o i cui componenti sono stati sviluppati per uno specifico cliente, beneficiano di un’esenzione mirata. L’art. 31, par. 1 disapplica tre gruppi di obblighi, e conviene nominarli con precisione perché vengono spesso scambiati fra loro: l’art. 23, lett. d), cioè il conseguimento dell’equivalenza funzionale; l’art. 29, cioè l’intera disciplina sull’abolizione graduale delle tariffe di passaggio; e l’art. 30, paragrafi 1 e 3, cioè l’equivalenza funzionale sul piano tecnico e la compatibilità con le specifiche comuni.

Resta invece pienamente applicabile l’art. 30, par. 2, che non figura fra le esclusioni: le interfacce aperte sono dovute anche per i servizi su misura. Il limite sta nel testo stesso: l’esenzione vale a condizione che i servizi non siano offerti su vasta scala commerciale tramite il catalogo del fornitore. Un servizio personalizzato ma a listino resta pienamente soggetto agli obblighi.

L’art. 31, par. 3 aggiunge un dovere informativo che si dimentica facilmente: prima di concludere il contratto, il fornitore deve dire al potenziale cliente quali obblighi del capo VI non si applicano.

Opposto è il caso delle offerte gratuite e dei cloud credits: l’art. 23, lett. c) impone di eliminare gli ostacoli al trasferimento dei dati esportabili e delle risorse digitali verso un altro fornitore anche dopo aver beneficiato di un’offerta gratuita. Una precisazione importante per startup e PMI che spesso iniziano con offerte gratuite e poi si ritrovano in lock-in dopo aver investito risorse nell’integrazione.

8. Errori frequenti e rischi pratici

Cinque errori ricorrono spesso nei contratti cloud dopo l’applicazione del Regolamento.

Il primo è la mancata distinzione tra IaaS, PaaS e SaaS nella formulazione degli obblighi tecnici: contratti che promettono equivalenza funzionale per un SaaS o interfacce aperte per un IaaS, senza calibrazione corretta.

Il secondo è l’assenza di un piano di switching ed exit documentato. I contratti spesso si limitano a richiamare gli artt. 23-31 senza tradurli in procedure operative.

Il terzo è l’uso improprio della deroga per impossibilità tecnica, invocata come clausola generica di salvaguardia anziché come eccezione motivata caso per caso.

Il quarto è la confusione tra tariffe di passaggio e spese standard di servizio, che porta sia a violazioni (continuare ad addebitare egress oltre il 12 gennaio 2027) sia a errori di trasparenza informativa precontrattuale.

Il quinto è la mancata pubblicazione delle informazioni sulla giurisdizione dell’infrastruttura, prevista dall’art. 28. Molti fornitori extraeuropei si sono adeguati, molti fornitori europei minori no.

I rischi sono significativi: nullità delle clausole non conformi, responsabilità contrattuale per inadempimento, contenziosi B2B dei clienti che vogliano lasciare il fornitore, sanzioni amministrative una volta che il decreto attuativo italiano sarà adottato. Si aggiunge il rischio commerciale di perdere gare dove la conformità Data Act è ormai requisito di partecipazione.

Conclusioni

Il capo VI è la parte del Data Act che incide di più sui rapporti già in corso, e per una ragione strutturale: non ha un regime transitorio. Il capo IV sulle clausole abusive concede tempo fino al 2027 per i contratti vecchi; qui no. Gli obblighi sullo switching valgono dal 12 settembre 2025 anche per accordi firmati anni prima, e un contratto cloud pluriennale mai toccato da allora è quasi certamente carente.

Il calendario che resta è breve. Il 12 gennaio 2027 cadono del tutto le tariffe di passaggio, comprese le egress fees, che per molti fornitori sono una voce di ricavo e non un rimborso di costi. Chi vende cloud ha poco più di un anno per capire come assorbirla; chi lo compra ha poco più di un anno per smettere di considerarla un dato di fatto.

La nostra valutazione, dichiarata come tale: la parte contrattuale è più facile di quella tecnica, e le aziende fanno l’errore di fermarsi alla prima. Riscrivere le clausole su preavviso, periodo transitorio e recupero dei dati è un lavoro di settimane. Garantire davvero l’equivalenza funzionale, o interfacce aperte gratuite e uguali per tutti, è un lavoro di ingegneria che tocca il prodotto. Un contratto che promette ciò che l’infrastruttura non sa fare sposta il problema, non lo risolve, e lo sposta nel punto peggiore: il momento in cui un cliente chiede davvero di andarsene.

Per chi compra, infine, un consiglio che vale più di molte clausole: la conformità al capo VI si verifica prima di firmare, non dopo. Il fornitore ha l’obbligo di consegnare il contratto prima della firma e di pubblicare le informazioni sul passaggio. Sono documenti che si leggono in mezza giornata e dicono, meglio di qualunque dichiarazione commerciale, quanto sarà costoso andarsene.

Punti chiave

Fonti