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. Nel periodo transitorio il fornitore di origine deve mantenere lo stesso livello di sicurezza dell’erogazione ordinaria, garantire la business continuity e notificare al cliente qualsiasi incidente significativo entro 48 ore (entro 24 ore se previsto da normative settoriali più stringenti come la NIS 2).

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 andrà negoziata e documentata caso per caso.

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 documentate e accessibili, idonee a garantire l’esportazione e la portabilità dei dati. 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 (SCC) della Commissione

Il Final Report dell’Expert Group on B2B Data Sharing and Cloud Computing Contracts della Commissione europea (pubblicato il 2 aprile 2025) propone sette set di clausole contrattuali standard (SCC) progettati per coprire gli obblighi del Capo VI. Non sono obbligatorie, ma costituiscono il punto di riferimento per la redazione di contratti conformi.

I sette set sono: SCCs General (definizioni ed elementi comuni), SCCs Switching & Exit (gestione del processo di passaggio), SCCs Termination (risoluzione del contratto), SCCs Security & Business Continuity (sicurezza e continuità operativa), SCCs Liability (responsabilità delle parti), SCCs Non-Amendment (stabilità contrattuale), SCCs Non-Dispersion (accessibilità centralizzata della documentazione contrattuale).

La logica del gruppo di esperti è che le SCC siano integrate in un unico master services agreement, in modo da coprire tutti i servizi di trattamento dei dati offerti dallo stesso fornitore e garantire continuità anche nei passaggi parziali. La negoziazione tra cliente e fornitore può scegliere quali SCC adottare, ma è consigliato l’utilizzo dell’intero set per garantire coerenza interpretativa.

Un elemento importante riguarda le SCCs Switching & Exit: prevedono due opzioni di realizzazione. L’opzione A si basa su un piano dettagliato di switching ed exit allegato al contratto, particolarmente adatto a servizi complessi. L’opzione B si fonda su strumenti automatizzati di self-service. Quest’ultima può essere problematica per i servizi SaaS che richiedono 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 e che molti fornitori globali non hanno ancora pienamente recepito.

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: non si applicano l’obbligo di equivalenza funzionale (art. 23, lett. d), gli aspetti tecnici del passaggio (art. 29) e l’obbligo di abolizione delle tariffe (art. 30, par. 1 e 3). Restano invece pienamente applicabili gli obblighi di interfacce aperte e di portabilità dei dati. Il considerando 98 chiarisce un punto chiave: servizi venduti su vasta scala commerciale non rientrano nell’esenzione, anche se personalizzati.

Opposto è il caso delle offerte gratuite e dei cloud credits: l’art. 23, lett. c) stabilisce esplicitamente che i clienti che hanno usufruito di cloud credits beneficiano pienamente delle disposizioni in materia di switching. 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.

Conclusione in sintesi