Regolare la restituzione e la cancellazione dei dati all'uscita dal SaaS

Perché regolare tempestivamente la restituzione e la cancellazione dei dati

I contratti SaaS disciplinano l'ambito delle prestazioni, la disponibilità, i diritti d'uso, gli aggiornamenti, il supporto, la responsabilità e la risoluzione. Secondo Lezzi Legal (Zurigo), le questioni relative all'utilizzo dei dati, all'esportazione dei dati e all'exit sono altrettanto importanti. Chi chiarisce la restituzione e la cancellazione solo al momento della disdetta, si trova a negoziare nella fase in cui il fornitore controlla gli accessi.

All'uscita bisogna distinguere due categorie di dati: i dati personali, per i quali valgono obblighi di protezione dei dati, e i dati non personali. Secondo MME, l'EU Data Act si applica parallelamente al GDPR e riguarda anche i dati macchina o di prodotto non personali. Un'uscita può quindi attivare due quadri normativi.

La valutazione giuridica dipende dall'architettura tecnica: quali dati vengono elaborati, quali fornitori sono coinvolti, come comunicano i sistemi e quale parte controlla dati e funzioni (Lezzi Legal). Le clausole sull'utilizzo dei dati, sull'esportazione e sull'exit devono pertanto essere adattate ai reali flussi di dati di ogni prodotto, invece di essere adottate come testo standard.

I prodotti SaaS cambiano più rapidamente dei contratti: funzionalità, modelli di prezzo, integrazioni e dipendenze tecniche si adeguano continuamente. Secondo Lezzi Legal, la documentazione giuridica deve poter crescere con il prodotto e non deve essere ricostruita da zero ad ogni adattamento tecnico.

Per i dati personali va considerata la legislazione svizzera sulla protezione dei dati (IFPDP). Per le aziende SaaS con legami al mercato UE, secondo MME l'EU Data Act si applica parallelamente al GDPR e anche ai dati macchina o di prodotto non personali (MME).

Rilevare il patrimonio dati e le dipendenze prima della disdetta

Prima della disdetta va stilato un inventario: dati centrali dell'applicazione, report, output OCR, dati di contatti e calendari, chiavi API e WebHook. Per ogni voce va indicato se essa nasce esclusivamente nel SaaS o se confluisce anche in altri sistemi. Solo questa distinzione mostra quali dati possono essere coperti da un'esportazione dal SaaS e quali devono essere salvati separatamente.

Le estensioni di un software ERP e per agenzie mostrano tipiche dipendenze: il riconoscimento OCR legge direttamente i documenti contabili, evidenzia in giallo i dati compilati automaticamente e impara con ogni ulteriore documento dello stesso fornitore. Tramite CardDAV i dati aziendali di contatto relativi a imprese, personale e persone di riferimento vengono recuperati, gestiti centralmente nell'applicazione e visualizzati sincronizzati sui dispositivi. L'attivazione del collegamento Zapier genera una chiave API specifica per l'account, con cui collegare altri strumenti business basati sul web. Per il centralino telefonico 3CX viene inserita una chiave API dall'area del profilo (MOCO).

Le estensioni possono avere una propria logica di terminazione. Verificate quindi per ogni connessione quando termina, chi disattiva l'accesso e se un'esportazione ne dipende. Pianificate il backup prima che una funzione o un'interfaccia venga disattivata.

Oltre ai flussi di dati vanno rilevate le chiavi: chi detiene le chiavi API, verso quali sistemi di destinazione puntano i WebHook e quali accessi devono essere revocati all'uscita. Senza questo elenco, dopo la disdetta permangono connessioni attive verso sistemi esterni.

Anche gli stati appresi fanno parte dell'inventario: l'OCR impara con ogni ulteriore documento dello stesso fornitore e i dati compilati automaticamente vengono evidenziati in giallo (MOCO). Tali assegnazioni ed evidenziazioni costituiscono patrimoni propri che devono essere trasferiti alla restituzione o successivamente cancellati.

Procedura prima dell'uscita dal SaaS: dalla rilevazione dei dati alla migrazione

Clausola di exit: intrecciare restituzione, cancellazione e migrazione

La clausola di exit va intrecciata con le altre regole di risoluzione: termini di preavviso, date di disdetta, durata e rinnovo automatico incidono direttamente sul tempo disponibile per l'esportazione e la migrazione. Chi regola l'exit separatamente, crea termini che non coincidono.

Se la prestazione concordata contrattualmente rientra nell'EU Data Act, la formulazione non è più libera. Secondo MME, le durate contrattuali tipiche da 12 a 24 mesi saranno in futuro vietate non appena la prestazione rientrerà nella legge. Allineate quindi durata, disdetta e consegna alle prescrizioni valide per il singolo contratto (MME).

La clausola deve contemplare tre prestazioni: restituzione dei dati, cancellazione dopo la scadenza di eventuali obblighi di conservazione e supporto nella migrazione verso un altro fornitore. Definite per ogni prestazione l'ambito, il termine, la regolamentazione dei costi e l'obbligo di collaborazione. In caso di legame con l'UE, va verificata l'applicabilità dell'EU Data Act prima di considerare un obbligo di supporto come legalmente vincolante.

La durata va già indicata nell'offerta: secondo le CGC di Libra AI, l'offerta deve menzionare la durata dell'abbonamento con l'indicazione del rinnovo automatico. I termini di exit vanno allineati a questo rinnovo.

Secondo le CGC di Libra AI, l'offerta comprende inoltre la versione scelta, il numero di utenti, il prezzo, i dati di contatto e di pagamento, la data di inizio dell'utilizzo e l'indicazione se è inclusa una versione di prova gratuita o a pagamento. I termini di exit possono essere calcolati solo quando queste informazioni sono disponibili.

Gli obblighi postcontrattuali vanno espressamente inclusi nella clausola. Il parere cloud per la città di Zurigo contiene una regola secondo cui un obbligo persiste anche dopo la risoluzione. Gli obblighi di restituzione e cancellazione vanno quindi formulati in modo da sopravvivere alla fine del contratto.

Lista di controllo: punti importanti per la clausola di exit nel contratto SaaS

Restituzione dei dati: concordare formato, termine e accesso all'esportazione

Per ogni tipo di dato va stabilito in quale forma, tramite quale canale e entro quando esso viene restituito. Come canali sono possibili API, WebHook ed esportazioni standard. Il collegamento API dipende nella pratica da chiavi specifiche per l'account – ad esempio, nell'integrazione Zapier l'attivazione genera una chiave API specifica per l'account (MOCO). La clausola deve quindi regolare quali chiavi rimangono valide durante la finestra di esportazione, chi le revoca e cosa vale se la chiave viene bloccata prima del completamento della restituzione.

Non va restituito solo ciò che si trova nel database dell'applicazione. I dati recuperati tramite CardDAV, secondo la descrizione del fornitore, vengono visualizzati sincronizzati sui dispositivi su cui sono stati aggiunti i contatti. Un'esportazione dal SaaS non cattura automaticamente queste copie sui dispositivi finali; di conseguenza va chiarito contrattualmente chi le rimuove dopo l'uscita.

Per la concretizzazione rientrano: le responsabilità di entrambe le parti, i termini di consegna, il formato della fornitura, indicazioni sulla completezza (ad esempio set di dati riconciliati) e una fase di accettazione, in cui il cliente può verificare l'esportazione. Va inoltre regolato cosa accade in caso di esportazione fallita o incompleta e fino a quando l'accesso viene mantenuto dopo la consegna. Le prestazioni possono terminare a breve termine – l'estensione OCR può essere interrotta in qualsiasi momento senza termini di preavviso –, motivo per cui l'esportazione deve essere collocata in una finestra temporale con accesso garantito.

Formula modello per la restituzione: «Il fornitore mette a disposizione i dati del cliente indicati in [Elenco dati] entro [Termine di restituzione] dopo [Evento scatenante] completamente in [Formato concordato] tramite [Canale di consegna]. Il cliente può verificare la completezza entro [Termine di verifica]; il fornitore colma le lacune riscontrate entro [Termine supplementare].» Inserite un'indicazione vincolante per ogni segnaposto; «esportazione standard» da sola non definisce né il formato target né l'ambito.

Anche la granularità fa parte della specifica del formato: l'output OCR può essere letto complessivamente come una singola voce o come voci singole (MOCO). La clausola dovrebbe stabilire quale livello il cliente necessita per l'ulteriore utilizzo.

Nel collegamento 3CX, il file di configurazione viene caricato nel centralino telefonico e la chiave API MOCO viene inserita nel profilo sotto Integrazioni (MOCO). Tali accessi vanno revocati solo quando l'esportazione è completata e accettata.

Regolare cancellazione e conservazione con prova

La clausola di cancellazione deve coprire quattro categorie: dati personali, dati di prodotto e macchina, backup nonché copie presso subappaltatori e altri prestatori di servizi impiegati. Per ogni categoria vanno determinati il termine di cancellazione, le eccezioni (ad esempio obblighi legali di conservazione) e la prova che attesta la cancellazione. Nella migrazione dei dati di prodotto possono additionally applicarsi requisiti del GDPR, nella misura in cui siano interessati dati personali (MME).

La catena di istruzioni va assicurata contrattualmente. Nelle CGC di Libra AI, il responsabile del trattamento si impegna a informare immediatamente il cliente se un'istruzione, a suo avviso, viola la vigente normativa sulla protezione dei dati. Un'istruzione di cancellazione che entra in conflitto con gli obblighi di conservazione scatena quindi un obbligo di informazione – la procedura为此 (punto di contatto, termine, forma) dovrebbe essere stabilita prima dell'uscita.

Come prove vanno previste una conferma scritta di cancellazione con data, un elenco dei destinatari della richiesta di cancellazione e un'informazione sulla cerchia dei subappaltatori. Va inoltre regolato in quale forma avvengono queste conferme e entro quando devono essere disponibili dopo il completamento della cancellazione.

Formula modello per la cancellazione: «Dopo la scadenza della fase concordata di restituzione e verifica, il fornitore cancella i dati dagli ambienti indicati in [Sistemi e copie], nella misura in cui nessun obbligo indicato in [Obbligo di conservazione e set di dati] richieda la conservazione. Il fornitore trasmette entro [Termine per la prova] una conferma scritta con data di cancellazione e destinatari registrati.» Concretizzate i segnaposti per ogni categoria di dati; in caso di eccezione, nominate i dati interessati e il motivo.

Questo obbligo di conservazione riguarda i documenti commerciali menzionati, non globalmente tutti i dati SaaS. In caso di legame con l'UE, secondo MME l'EU Data Act si applica parallelamente al GDPR e anche ai dati macchina o di prodotto non personali; nella migrazione dei dati di prodotto possono applicarsi requisiti del GDPR, nella misura in cui siano interessati dati personali (MME).

Per i dati personali va considerata la legislazione svizzera sulla protezione dei dati; l'Incaricato federale della protezione dei dati e della trasparenza (IFPDP) non ha competenza sanzionatoria secondo il nuovo diritto (IFPDP). Ai sensi dell'art. 958f CO, i libri commerciali, le scritture contabili nonché i rapporti commerciali e di revisione devono essere conservati per dieci anni (BDO).

Termini giuridici importanti e requisiti nell'uscita dal SaaS

Cancellazione dei dati dopo la fine del contratto: procedura con prova

Assicurare contrattualmente la migrazione verso il nuovo fornitore

MME descrive come opportunità della legge sui dati il fatto che sia diventato più semplice migrare la propria infrastruttura cloud verso un altro fornitore. Per la clausola di exit resta da definire quali dati e formati il fornitore mette a disposizione, per quanto tempo viene prestato supporto e quale collaborazione deve il cliente. Nominate prestazioni e limiti in modo così concreto che le parti possano pianificare la migrazione.

I limiti della prestazione di aiuto vanno tracciati contrattualmente: quali dati e formati, quale periodo, quali persone di contatto, quale collaborazione del cliente. Senza tale precisazione resta aperto cosa comprenda concretamente «supportare attivamente».

L'applicazione va presa sul serio. MME segnala che le aziende che non implementano questi requisiti nei loro contratti devono aspettarsi azioni legali da parte dei concorrenti e rischiano multe elevate, paragonabili alle sanzioni secondo il diritto europeo sulla protezione dei dati. Già oggi alcuni clienti SaaS adattano i loro contratti e in alcuni casi anche i loro modelli di business e di vendita.

Allineare contratto, CGC, DPA e documentazione sulla protezione dei dati

Nei modelli standardizzati, contratto SaaS, CGC, livelli di servizio, contratto di elaborazione dei dati (DPA) e documentazione sulla protezione dei dati dovrebbero essere allineati tra loro (Lezzi Legal). Se le regole di exit in un documento e le regole di conservazione o cancellazione in un altro divergono, nascono contraddizioni che in caso di controversia vengono interpretate a sfavore del fornitore.

La gerarchia decide quale documento vale. Le CGC di Libra AI prevedono che le condizioni commerciali divergenti del cliente non trovino applicazione. Diversamente vale solo se il fornitore acconsente espressamente per iscritto alla loro validità. Le CGC sono parte integrante di tutti i contratti nonché di tutte le prestazioni e offerte future. Chi fissa le regole di exit in un allegato o nel DPA deve quindi verificare se questi documenti prevalgono sulle CGC.

In pratica significa: condurre le regole di exit completamente in un unico punto, rinviarvi da tutti gli altri documenti e aggiornarle ad ogni modifica del prodotto. Poiché funzionalità, modelli di prezzo e integrazioni cambiano continuamente, la documentazione deve essere concepita secondo Lezzi Legal in modo da crescere con il prodotto.

Secondo le CGC di Libra AI, la lingua determinante per la conclusione del contratto è il tedesco; le traduzioni servono solo a scopo informativo e in caso di contraddizioni vale la versione tedesca. Le regole di exit in un allegato tradotto possono quindi restare in secondo piano rispetto alla versione tedesca.

Diritto svizzero e toccata dell'UE nell'uscita dal SaaS

L'EU Data Act (Regolamento (UE) 2023/2854 su norme armonizzate per un accesso equo ai dati e un uso equo dei dati) si applica dalla sua entrata in vigore a metà settembre 2025. Per le aziende SaaS e IoT svizzere attive sul mercato UE, esso ha creato un nuovo ambiente normativo (MME, «EU Data Act: Was Schweizer SaaS- und IoT-Unternehmen jetzt tun müssen», 12 gennaio 2026).

Prima dell'adattamento contrattuale sta la verifica di applicabilità: non tutti i modelli SaaS rientrano nella regolamentazione, anche se circolano parzialmente affermazioni contraddittorie (MME). Verificate quindi il prodotto concreto, la prestazione concordata contrattualmente e il legame con il mercato UE prima di adottare clausole del Data Act. Così si possono allineare le regole contrattuali alla rispettiva offerta, invece di trasferirle globalmente ad ogni modello SaaS.

L'EU Data Act e il GDPR vanno distinti: secondo MME il Data Act si applica parallelamente al GDPR e riguarda anche i dati macchina o di prodotto non personali. Nella migrazione dei dati di prodotto possono additionally applicarsi requisiti del GDPR, nella misura in cui siano interessati dati personali (MME). Rilevate quindi categoria di dati e possibile toccata dell'UE separatamente dagli obblighi di conservazione svizzeri.

Per i contratti con riferimento svizzero va verificata la scelta del diritto. Il parere cloud per la città di Zurigo nomina la regola «Si applica il diritto svizzero concordato nel contratto.» Chi concorda il diritto svizzero, regola restituzione e cancellazione secondo questo diritto e non solo secondo le CGC del fornitore.

Diritto svizzero vs. EU Data Act: differenze nella restituzione e cancellazione dei dati