Contratti per software cloud: durata, livelli di servizio e disdetta

Inquadramento giuridico dei contratti cloud: mandato, appalto o contratto misto

Prima della stipula è necessario definire clausole concrete su durata, livelli di servizio e disdetta, non semplici dichiarazioni d’intenti.

Tre elementi determinano l’esigibilità delle prestazioni: durata, livelli di servizio (SLA) e disdetta. Devono figurare nel contratto con valori numerici – durata minima in mesi, disponibilità in percentuale, termini di preavviso in giorni e mesi – e non come mere dichiarazioni d’intenti. In assenza di cifre precise, ogni verifica successiva diventa una questione interpretativa.

I contratti cloud non costituiscono una tipologia contrattuale autonoma. A seconda dell’oggetto della prestazione, rientrano nel diritto del mandato o dell’appalto, quasi sempre integrati da elementi di altri contratti innominati.

Lo spettro va dalle soluzioni cloud ai contratti di consulenza e manutenzione, fino allo sviluppo di software su misura. Decisivo non è l’etichetta «cloud», bensì il contenuto concreto della prestazione dovuta.

Per la responsabilità, l’inquadramento è centrale. Nel diritto del mandato conta l’esecuzione diligente della prestazione; nell’appalto, il prestatore deve garantire un risultato concreto, ad esempio un’applicazione funzionante. A seconda dell’inquadramento, il fornitore risponde per la diligenza nell’operato o per il risultato concordato.

I contratti cloud sono regolarmente contratti misti. Esaminate separatamente i complessi di obblighi: esercizio e supporto, concessione di licenze, trattamento dei dati, prestazioni progettuali e migrazione. Per ciascun complesso deve essere chiaro quali obblighi siano dovuti come risultato e quali come impegno diligente.

Chi desidera un risultato deve ancorarlo espressamente nel contratto come prestazione dovuta, con riferimento a funzioni, volumi, tempi e parametri di misurazione. Se l’obbligo prestazionale rimane aspecifico, far valere un risultato risulta difficile.

Se un contratto è sottoposto al diritto tedesco, vanno indicate le norme pertinenti: contratto di servizi ai sensi degli artt. 611 ss. del BGB, contratto d’appalto ai sensi dell’art. 631 del BGB; il SaaS viene inquadrato secondo il diritto locatizio ai sensi dell’art. 535 del BGB. L’inquadramento decide quale regime di responsabilità si applichi e quali clausole siano ammissibili.

Definire ambito delle prestazioni, diritti d’uso e delimitazione delle licenze

L’ambito delle prestazioni, i diritti d’uso e la conformità alla protezione dei dati vanno definiti con precisione. I diritti di licenza e le condizioni d’uso devono essere delimitati nei dettagli, per evitare costose rinegoziazioni.

Il SaaS può essere riassunto così: il fornitore ospita il software generalmente sui propri server e ne assume la manutenzione e l’aggiornamento. L’utilizzo avviene tramite browser, la fatturazione per lo più sotto forma di abbonamento. Questi punti appartengono alla descrizione delle prestazioni.

Elementi tipici dell’ambito delle prestazioni includono: moduli e funzioni gestiti, numero di utenti e mandanti, volume di archiviazione e transazioni, interfacce supportate, orari di servizio, finestre di manutenzione, livelli di supporto nonché prestazioni espressamente escluse. Va regolato anche il trattamento di release e aggiornamenti: quali adattamenti sono inclusi e quali vengono fatturati come prestazioni supplementari.

Per i diritti d’uso, la questione riguarda portata, durata e trasferibilità dell’utilizzo, la sottoslicenza, l’uso all’interno di gruppi aziendali, l’uso multiplo da parte di terzi, nonché i diritti su configurazioni, analisi e dati propri. Chi lascia aperti questi punti rischia controversie proprio quando il sistema viene utilizzato in produzione.

Si è rivelata efficace una chiara comparazione tra «incluso» e «non incluso», unita a una regola su come attivare e tariffare le estensioni. In questo modo, l’ambito resta comprensibile per tutta la durata del contratto.

Durata e consumo minimo: esaminare criticamente i vincoli prolungati

Per i servizi cloud vale la pena esaminare criticamente la durata e l’eventuale consumo minimo.

Vanno scrutinati con attenzione le clausole di rinnovo automatico, i termini di preavviso e il momento in cui è possibile adeguare il numero di utenti o i volumi. Un vincolo legato al numero di utenti o a strutture quantitative equivale di fatto a un obbligo di consumo minimo: il cliente paga anche quando non ha più bisogno della capacità.

Allineate la durata all’orizzonte del progetto o dell’utilizzo, non lasciate che i rinnovi avvengano tacitamente e prevedete diritti di adeguamento per volumi e numero di utenti. Verificate se il vincolo sia effettivamente necessario.

Spesso è negoziabile più di quanto si pensi: inizio della decorrenza dalla messa in produzione, diritto di recesso in caso di mancato raggiungimento dei livelli di servizio concordati o in caso di venir meno dello scopo contrattuale. Tali punti di uscita sono solitamente più preziosi di uno sconto sul prezzo di listino.

In ogni clausola sulla durata devono figurare concretamente: durata minima, modalità di rinnovo e termine di preavviso. Se manca un elemento, nasce un vincolo di fatto, difficile da correggere in seguito.

Una clausola sulla durata diventa verificabile solo con numeri precisi: durata della periodo minimo, passo di rinnovo, termine di preavviso e la data limite entro cui esercitare la disdetta. Formule come «ragionevole» o «consueto sul mercato» non reggono in caso di controversia.

Un esempio pratico mostra una soluzione diversa: secunet cloud regola al § 10 delle sue CGC «Durata del contratto e disdetta», stabilendo che il contratto quadro è concluso a tempo indeterminato e inizia con il completamento del servizio di onboarding. L’inizio della decorrenza dipende quindi da un evento definito, non da una data.

Durata del contratto e disdetta secondo secunet cloud (CGC § 10)

Concordare livelli di servizio misurabili

L’utilizzo di servizi IT è soggetto generalmente ad accordi sui livelli di servizio (SLA). Il contenuto viene negoziato individualmente ed è suscettibile a formulazioni vaghe, difficili da verificare.

Affinché un SLA sia verificabile in caso di controversia, i punti rilevanti devono essere determinati o determinabili. Ciò include: cosa viene misurato, come viene misurato, su quale periodo temporale e quali conseguenze comporta il mancato rispetto.

Esigete per ogni livello di servizio un valore numerico e un metodo di misurazione: disponibilità in percentuale, finestra di misurazione, strumento di misura e la sanzione sotto forma di accredito in percentuale del canone mensile. Senza queste indicazioni, la soglia non è verificabile.

Va distinta la differenza tra tempi di reazione – ad esempio fino alla conferma di una segnalazione di guasto – e tempi di ripristino fino alla ripresa dell’esercizio.

Negli SLA vanno inseriti anche gli orari di servizio e le esclusioni: periodi per manutenzioni annunciate, interruzioni dovute a mancata fornitura da parte di terzi, uso improprio da parte del cliente e interruzioni pianificate. Senza questa delimitazione, ogni discussione sulla disponibilità diventa una questione interpretativa.

Vanno regolati anche la prova e l’escalation: report e protocolli di misurazione, diritti di accesso ai dati di monitoraggio, interlocutori definiti e livelli di escalation con scadenze.

Come sanzioni sono possibili accrediti contrattuali, obblighi di rimedio o, in caso di ripetuto mancato rispetto, diritti di recesso straordinario.

Dal 17 gennaio 2025, il regolamento DORA richiede, per i contratti con fornitori terzi di servizi TIC, descrizioni della qualità del servizio con obiettivi di prestazione precisi (art. 30 DORA). I modelli standard vanno esaminati prima di qualsiasi firma; si aggiungono ulteriori prescrizioni come NIS2 ed EVB-IT Cloud.

Ai sensi dell’art. 307 cpv. 1 frase 2 del BGB, le clausole SLA devono essere trasparenti. Regole opache sulla disponibilità o sulle finestre di manutenzione sono inefficaci e la responsabilità legale resta pienamente vigente. Determinante è il controllo delle condizioni generali di contratto ai sensi degli artt. 305 ss. del BGB.

Le clausole sugli accrediti di servizio che escludono globalmente nelle condizioni generali ulteriori pretese risarcitorie sono regolarmente inefficaci. Si risponde allora secondo il tipo contrattuale legale; per il SaaS, secondo il diritto locatizio ai sensi dell’art. 535 del BGB.

Un fornitore indica come orario di servizio un’attività 24/7 con livelli di servizio definiti. Tali indicazioni sono concrete, ma senza finestra di misurazione, strumento di misura e sanzione non sono ancora esigibili.

Protezione dei dati, ubicazione dei dati e accesso dalla Svizzera

La conformità alla protezione dei dati secondo la Legge federale sulla protezione dei dati revisionata (LPD) deve essere regolata contrattualmente, specialmente in caso di flussi transfrontalieri di dati. Il contratto non dovrebbe limitarsi a rinviare alla legge, ma stabilire chi è responsabile di quale trattamento e quali obblighi assume il fornitore.

Sono diffuse le regolamentazioni sul trattamento per conto: vincolo alle istruzioni, riservatezza, misure tecniche e organizzative, coinvolgimento di subappaltatori, notifica di violazioni della protezione dei dati nonché restituzione e cancellazione dei dati.

Chi tratta dati in un cloud dovrebbe inoltre sapere in quali paesi essi risiedono e da quali paesi vi si può accedere.

È quindi pratico non solo definire il luogo di archiviazione, ma anche la via di accesso. Ciò include la disponibilità delle prove in un formato leggibile, l’accesso dalla Svizzera, la possibilità di esportazione senza collaborazione del fornitore e una regolamentazione per il caso in cui il fornitore cessi il servizio.

Come prove per l’esercizio e l’ubicazione servono certificazioni e indicazioni sul data center. secunet cloud cita ISO 27001, BSI C5 e data center tedeschi. Per i clienti svizzeri, ciò non sostituisce una regolamentazione contrattuale su luogo di archiviazione e via di accesso.

Regolare disdetta, uscita e migrazione dei dati prima della stipula

Per le soluzioni cloud, le strategie di uscita e le migrazioni dei dati vanno definite vincolantemente prima della stipula del contratto. Ciò che viene negoziato solo nella fase di disdetta diventa costoso: allora il fornitore non ha più interesse a una consegna rapida ed economica.

Da chiarire sono formato e portata della restituzione dei dati, i termini per la consegna, la cancellazione dopo l’avvenuta migrazione, un eventuale esercizio transitorio e la questione di chi sostiene i costi di migrazione.

Va inoltre stabilito se configurazioni, documentazioni delle interfacce, analisi e protocolli vengano forniti.

Si è rivelato utile un formato standard per l’esportazione. Vanno altresì concordati un termine di consegna definito dopo l’efficacia della disdetta, un esercizio continuato a tempo determinato contro compenso precedentemente concordato e una conferma scritta della cancellazione allo scadere del periodo transitorio.

È sensato prevedere un diritto di recesso straordinario non solo in caso di disdetta ordinaria, ma anche in caso di ripetute violazioni del servizio, venir meno dell’opportunità o cambiamenti del quadro normativo. Prima tali punti di uscita figurano nel contratto, minore è il rischio di un blocco.

Anche la clausola di disdetta necessita di numeri: data di disdetta, termine di preavviso e forma. Se vi figura solo «con preavviso ragionevole», l’uscita è di fatto bloccata.

Durata e disdetta spesso figurano nella stessa disposizione. Il § 10 delle CGC di secunet cloud si intitola «Durata del contratto e disdetta» e collega l’inizio della decorrenza al completamento del servizio di onboarding. Chi vuole calcolare la prima data utile per la disdetta, legge insieme entrambe le indicazioni.

Costi, prestazioni supplementari e controllo del budget

Costi supplementari imprevisti sorgono soprattutto dove la delimitazione delle prestazioni resta poco chiara. Ciò che non è descritto espressamente come incluso viene fatturato, se necessario, come prestazione aggiuntiva – un impatto percepibile con l’aumento dell’utilizzo.

Strumenti di controllo includono, tra l’altro, il budget IT, gli accordi sui livelli di servizio tra l’azienda e il suo fornitore IT, nonché contratti di progetto e altri obiettivi. Tali strumenti funzionano solo se formulati in riferimento a progetti e volumi concreti.

Per le collettività pubbliche svizzere sorge una domanda aggiuntiva: la contabilizzazione dei contratti cloud; il trattamento va chiarito prima della stipula.

Per le estensioni si raccomanda una procedura regolamentata: richiesta, descrizione della prestazione, stima dell’onere e del prezzo, approvazione e conferma scritta. Senza un tale processo di change request, le prestazioni sorgono di fatto automaticamente e vengono fatturate a posteriori.

La trasparenza dei costi richiede un listino prezzi comprensibile per i volumi aggiuntivi, regole per gli adeguamenti dei prezzi durante la durata e un tetto di budget oltre il quale è necessaria una nuova approvazione. In questo modo, l’evoluzione dei costi resta governabile, invece di essere meramente constatabile.

Per il proprio lavoro contrattuale, sul mercato svizzero sono disponibili modelli: modello di contratto di prestazione di servizi IT e modello di contratto di consulenza IT a CHF 50.00 ciascuno, modello di contratto software per lo sviluppo a CHF 80.00, CGC hosting a CHF 100.00 e il pacchetto download di modelli IT a CHF 248.00. La fonte è weka.ch; la checklist sulla sicurezza IT è disponibile gratuitamente.

Checklist per l’esame del prossimo contratto cloud

Inquadramento: È chiaro quali prestazioni siano dovute come risultato e quali come esecuzione diligente? I complessi di obblighi – esercizio, licenza, dati, progetto, migrazione – sono regolati separatamente?

Ambito delle prestazioni: Sono elencati moduli, numero di utenti, volumi, interfacce, orari di supporto e prestazioni espressamente escluse? Aggiornamenti e release sono assegnati correttamente?

Diritti d’uso: Portata, durata, trasferibilità e sottoslicenza sono regolamentate? I diritti su configurazioni, analisi e dati del cliente sono chiariti?

Durata: Quanto dura il periodo minimo, come si rinnova il contratto e con quale preavviso si può recedere? Come si possono adeguare volumi o numero di utenti?

Livelli di servizio: Cosa viene misurato, come e su quale periodo? Tempi di reazione e di ripristino, orari di servizio, esclusioni, reporting, escalation e sanzioni sono definiti?

Protezione dei dati: Responsabilità, vincolo alle istruzioni, subappaltatori, obblighi di notifica e cancellazione sono regolati conformemente alla LPD revisionata? Luogo di archiviazione e via di accesso dalla Svizzera sono regolamentati?

Uscita: Formato e portata della restituzione dei dati, termini, esercizio transitorio e ripartizione dei costi sono stabiliti prima della stipula? La cancellazione viene confermata?

Costi: Listino prezzi per prestazioni supplementari, regole di adeguamento dei prezzi, procedura di change request e un limite di approvazione nel budget sono concordati?

Basi giuridiche: In caso di diritto tedesco, le norme pertinenti sono indicate – artt. 611 ss. BGB, art. 631 BGB, art. 535 BGB – ed è considerato il controllo delle CGC ai sensi degli artt. 305 ss. BGB nonché dell’art. 307 cpv. 1 frase 2 BGB?

Normativa: Per i contratti con fornitori terzi di servizi TIC, le prescrizioni ai sensi dell’art. 30 DORA dal 17 gennaio 2025, nonché NIS2 ed EVB-IT Cloud, sono state esaminate?

Indicazioni del fornitore: Sono disponibili CGC e SLA – ad esempio il § 10 sulla durata del contratto e la disdetta – e sono comprovati orari di servizio come l’attività 24/7 nonché attestazioni ISO 27001 e BSI C5?

Punti chiave: Durata, livelli di servizio e disdetta figurano nel contratto ciascuno con un numero preciso – durata del vincolo, disponibilità in percentuale, termine di preavviso? Se manca uno di questi numeri, la clausola non è verificabile.