Livello di servizio nei contratti SaaS: disponibilità, assistenza e sanzioni

L'SLA come strumento di gestione nel contratto SaaS

Un accordo sul livello di servizio (SLA) fissa, quale componente contrattuale o in un documento contrattuale separato, le caratteristiche prestazionali concrete di un servizio IT: disponibilità, tempi di reazione, tempi di risoluzione dei guasti. Queste caratteristiche sono indicatori chiave di prestazione (KPI), con i quali è possibile misurare la qualità di un servizio IT. Gli SLA sono diffusi in tutti i settori IT, dai contratti di esercizio alle soluzioni SaaS fino al classico outsourcing IT. Sono diventati noti nel settore IT grazie a ITIL; fanno parte della gestione del livello di servizio (SLM).

I prodotti SaaS spaziano dagli strumenti di collaborazione come Microsoft 365 e Google Workspace ai sistemi CRM fino all'IA generativa. A seconda dell'applicazione, varia la criticità dei processi aziendali e, di conseguenza, il necessario rigore dell'SLA.

Nei contratti SaaS, l'SLA si concentra su tre aree: disponibilità, assistenza e sanzioni. Ogni area richiede indicazioni specifiche: valore percentuale, periodo di riferimento e metodo di misurazione per la disponibilità; reperibilità nonché tempi di reazione, intervento e risoluzione per l'assistenza; conseguenze giuridiche, soglie e competenze per le sanzioni.

Nei contratti SaaS l'SLA ha un peso maggiore perché concorrono due circostanze: i prodotti SaaS supportano regolarmente processi aziendali importanti o critici e i clienti pagano solitamente un corrispettivo mensile. È quindi necessario concordare quali standard qualitativi il prodotto debba soddisfare, quando l'assistenza sia raggiungibile e entro quale tempo debba essere possibile risolvere un errore.

L'SLA rende la prestazione qualitativamente misurabile: le parti ottengono la certezza se il prodotto corrisponda agli standard concordati – e quindi quando sussista un «errore» o un «vizio». Da ciò si può stimare se e in quale misura si debba pagare nonostante il mancato rispetto degli standard concordati.

Spesso si conclude un SLA quando le norme legali sulla garanzia non sono sufficienti o appropriate per il caso concreto. In assenza di clausole SLA chiare, restano aperti l'ambito delle prestazioni, la responsabilità o i meccanismi di escalation – spesso costosi in caso di controversia. Un SLA crea la base per definire con precisione i contenuti della prestazione e valutare oggettivamente le violazioni contrattuali.

Il rovescio della medaglia: nella pratica le clausole SLA sono spesso imprecise o incomplete e non coprono le esigenze concrete. Di solito ci si accorge di questo solo quando la prestazione viene fornita in modo difettoso.

Un SLA crea linee guida e prescrizioni chiare: offre alle parti una panoramica sul contenuto della prestazione nonché sui diritti e doveri concreti e permette di stimare preventivamente il rischio in caso di interruzioni. Per le aziende significa maggiore sicurezza giuridica e meno zone grigie.

Per i prodotti SaaS sono importanti un'assistenza tempestiva e una rapida risoluzione degli errori. Pertanto, nel contratto devono figurare disposizioni speciali sui diritti e doveri in caso di problemi e disturbi delle prestazioni; le obbligazioni principali di prestazione vanno descritte nel modo più preciso possibile. In mancanza di una regolamentazione esplicita, si applicano le disposizioni di legge, che spesso risultano svantaggiose per il caso concreto.

Vantaggi e rischi delle clausole SLA nei contratti SaaS

Disponibilità: periodo di riferimento, metodo di misurazione e finestre di manutenzione

Una promessa di disponibilità consiste in tre elementi che il contratto deve fissare singolarmente: il valore percentuale, il periodo di calcolo o di riferimento e il metodo di misurazione. Nella pratica, questi tre elementi vanno chiariti per primi. Un'interruzione ha un impatto diverso a seconda del periodo di calcolo: la stessa interruzione pesa di più in una finestra breve che in una lunga.

Le finestre di manutenzione sono generalmente escluse dalla disponibilità concordata. Il contratto deve quindi definire quali aspetti rientrano in una finestra di manutenzione e quali condizioni quadro si applicano – ad esempio una comunicazione preventiva ai clienti o orari chiaramente definiti per i lavori di manutenzione. In assenza di queste condizioni quadro, in seguito non è possibile valutare se un'interruzione conti come manutenzione pianificata o come guasto.

Nel modello SaaS, il gestore si occupa dei lavori di manutenzione e degli aggiornamenti software. Tali interventi sono i tipici contenuti di una finestra di manutenzione e devono essere inclusi nel contratto con preavviso, canale di comunicazione e orari chiaramente definiti.

Per la misurazione ne consegue che i lavori di manutenzione pianificati non devono confluirne nel calcolo della disponibilità. Altrimenti ogni manutenzione regolarmente annunciata verrebbe conteggiata come interruzione, abbassando il valore misurato.

Un esempio svizzero mostra quanto possano divergere promessa e misurazione: il fornitore BESA QSys indica per la sua piattaforma SaaS RAI-System che il gestore garantisce contrattualmente una disponibilità del 99%, mentre la disponibilità attualmente misurata è vicina al 100%. Secondo le stesse indicazioni, i dati e l'infrastruttura SaaS si trovano in un data center nei dintorni di Zurigo.

Valore garantito e valore misurato sono quindi due grandezze diverse. Quale sia determinante in caso di controversia non deriva dalla percentuale, ma dal metodo di misurazione concordato e dal periodo di riferimento.

Promesse di disponibilità e metodi di misurazione nell'SLA

Assistenza: tempi di reazione, intervento e risoluzione

Un SLA distingue tipicamente tre concetti temporali: il tempo di reazione, il tempo di intervento e il tempo di risoluzione. Decisive non sono solo le loro definizioni, ma anche eventuali differenziazioni.

Spesso i tempi vengono stabiliti in modo graduato a seconda della gravità di un caso, in un modello di incidenti graduato con livelli di severità (Severity Levels). Il grado di gravità determina poi quali termini si applicano: un disturbo che blocca l'attività aziendale attiva termini diversi rispetto a una richiesta senza interruzione operativa.

Centrale è il momento in cui inizia a decorrere il tempo di reazione: con la segnalazione da parte del cliente, con il suo arrivo in un determinato sistema, con la conferma di ricezione o solo con la classificazione del caso. Una semplice definizione nell'SLA risponde a questa domanda. Senza di essa, in caso di controversia resta aperto se un termine sia stato violato.

Ai concetti temporali è legata la reperibilità dell'assistenza: va concordato quando l'assistenza sia raggiungibile e entro quale tempo possa avvenire la risoluzione di un errore. Nella pratica si distingue tra orari d'ufficio e una postazione costantemente presidiata. Quale variante sia adatta dipende da quanto sia critico il processo aziendale che gira sul prodotto SaaS. Un modello di incidenti graduato combina entrambi gli aspetti: collega il grado di gravità alla reperibilità e ai termini, invece di fissare lo stesso tempo per tutti i casi.

Un esempio di modello basato sugli orari d'ufficio: WEKA indica per il suo servizio clienti telefonico lun–ven dalle 08:00 alle 12:00 e dalle 13:30 alle 16:30; le richieste scritte vengono risposte anche fuori dagli orari telefonici a seconda della disponibilità. Chi promette assistenza solo durante gli orari d'ufficio li indica nell'SLA e stabilisce come vengano accettate le segnalazioni al di fuori di tali orari.

I tre concetti temporali sono allo stesso tempo i parametri di riferimento delle sanzioni. Un termine mancato fornisce la prova misurabile a cui si aggancia un accredito o un livello di escalation.

Definizioni ed esclusioni: affinché l'SLA non rimanga privo di denti

Definizioni chiare sono il primo punto di controllo, anche se sembrano poco spettacolari. Bisogna rispondere a domande come: «A cosa si riferisce la disponibilità?» e «Quando inizia a decorrere il tempo di reazione?». Le risposte possono essere fissate relativamente facilmente come definizioni nell'SLA.

Vi rientra anche la descrizione di errori e vizi. Solo tramite questa definizione è possibile stabilire quando sussiste una deviazione dallo standard concordato e quali diritti ne derivano.

Le esclusioni stabiliscono quali eventi non debbano essere rilevanti ai fini dell'SLA. Esempi tipici sono le dipendenze da terzi, gli attacchi DDoS e la forza maggiore. Tali esclusioni sono legittime, ma devono essere circoscritte in modo rigoroso: più aperta è la formulazione, più facilmente un'interruzione che il fornitore potrebbe influenzare viene classificata come caso escluso.

Clausole poco chiare o incomplete hanno conseguenze concrete. Nella pratica gli SLA non sono raramente rudimentali e formulati in modo poco chiaro, rischiando così di rimanere inefficaci. Le debolezze si mostrano regolarmente solo in caso di prestazione carente, non alla stipula del contratto. Un SLA che non definisce cosa sia un errore, cosa una finestra di manutenzione e cosa una circostanza esclusa, non offre in caso di controversia alcuna base per una valutazione oggettiva.

Le definizioni agiscono in tutte e tre le aree: decidono quale interruzione conta come guasto, quando inizia a decorrere un termine di assistenza e se viene attivata una sanzione. Errore, vizio, disturbo, inizio della reazione, finestra di manutenzione ed esclusione devono quindi figurare espressamente nel contratto.

Misurazione, reporting e prova

Metodi di misurazione e periodi di riferimento sono il secondo punto di controllo: chi misura cosa, come e per quali periodi? Senza queste determinazioni, una promessa SLA è difficilmente valutabile oggettivamente, poiché già il periodo di riferimento modifica il risultato. Chi non regola la misurazione, lascia di fatto la valutazione a colui che fornisce i numeri.

Il reporting include la questione in quale forma e con quale periodicità il fornitore riferisca sui valori misurati e se vengano forniti i punti di misurazione o i dati grezzi. Per la prova va quindi regolato chi abbia accesso ai dati di misurazione e come si proceda in caso di lacune nei dati. Quale numero sia determinante in caso di controversia non deriva dalla promessa, ma dalle regole di misurazione – dal metodo di misurazione, dal periodo di riferimento e dalla questione di quale misurazione venga riconosciuta come riferimento.

Il reporting è il ponte verso le sanzioni: senza valori di misurazione evidenziati non è possibile provare un mancato rispetto. Forma, periodicità e diritti di accesso vanno quindi regolati insieme all'accredito.

Controlli regolari per la protezione da accessi non autorizzati non costituiscono una prova della disponibilità. BESA QSys indica per il sistema RAI tali controlli; per l'SLA contano i valori misurati e la loro documentazione.

Passi per un'implementazione sicura di un SLA nel contratto SaaS

Sanzioni e conseguenze in caso di violazioni dell'SLA

In mancanza di una regolamentazione sulle conseguenze in caso di violazione, l'SLA rimane una «tigre di carta». Le promesse di disponibilità e tempi di reazione restano vincolanti solo se vi è collegata una conseguenza giuridica. Senza clausole chiare restano aperti anche i meccanismi di escalation – costosi in caso di controversia.

Le sanzioni si collegano ai valori misurati. Senza una misurazione regolamentata manca la base per accertare una violazione e attivare un accredito.

Come conseguenze nella pratica vengono spesso discussi accredito sulla remunerazione ricorrente, inoltre livelli di escalation dal primo interlocutore fino alla direzione aziendale nonché diritti di disdetta straordinaria o recesso in caso di violazioni ripetute o gravi. Quali meccanismi intervengano e a partire da quale soglia, deve far parte della regolamentazione delle conseguenze. L'escalation dovrebbe collegarsi agli stessi livelli di severità concordati per i tempi di assistenza.

Quattro indicazioni rendono verificabile una clausola sanzionatoria: la soglia a partire dalla quale interviene, l'importo dell'accredito come quota della remunerazione ricorrente, un eventuale limite superiore e il numero di ripetizioni a partire dal quale scatta un diritto di disdetta straordinaria. Solo con queste indicazioni è possibile calcolare in caso di controversia.

Accreditamenti, livelli di escalation e diritti di disdetta funzionano solo se sono nominate soglie e competenze. Senza queste indicazioni ogni sanzione rimane una dichiarazione d'intenti.

Alle sanzioni si affianca la questione della responsabilità. Nei contratti SaaS, le regolamentazioni su responsabilità, garanzia e diritti di proprietà intellettuale fanno parte del normale contenuto contrattuale. Un SLA viene concluso proprio quando le norme legali sulla garanzia non sono sufficienti o appropriate. Va quindi chiarito come interagiscano le sanzioni SLA e le norme generali di responsabilità – in particolare se un accredito resti la conseguenza definitiva o se sussistano ulteriori pretese.

Integrazione nel contratto SaaS, nelle CGC e nella pratica svizzera

Nei modelli SaaS standardizzati, contratto SaaS, CGC, livelli di servizio, contratto di elaborazione dati (DPA) e documentazione sulla protezione dei dati dovrebbero essere coordinati tra loro. Altrettanto importanti sono le questioni sull'utilizzo dei dati, l'esportazione dei dati e l'exit. I modelli SaaS e software necessitano inoltre di regolamentazioni chiare su ambito delle prestazioni, disponibilità, diritti d'uso, aggiornamenti, assistenza, responsabilità e cessazione (Lezzi Legal, Zurigo). Se l'SLA indica valori diversi rispetto alle CGC o alla documentazione del prodotto, nasce una contraddizione che in caso di controversia deve essere risolta per prima.

I prodotti SaaS vengono sviluppati in modo iterativo; funzioni, modelli di prezzo, integrazioni e dipendenze tecniche cambiano continuamente. La documentazione giuridica dovrebbe quindi poter crescere con il prodotto e non dover essere ricostruita ad ogni adattamento tecnico (Lezzi Legal).

Per l'SLA ne consegue che le modifiche al metodo di misurazione, alle finestre di manutenzione e agli orari di assistenza necessitano di un percorso ordinato nel contratto. Per i contratti SaaS in Svizzera, l'hosting nel paese può essere un elemento contrattuale utile. Il contratto modello WEKA per SaaS cita come vantaggi la disponibilità garantita con regolamentazioni SLA chiaramente definite, l'hosting in Svizzera con backup nonché la trasparenza dei costi attraverso tariffe chiare e un modello di fatturazione comprensibile.

Si aggiungono regolamentazioni su responsabilità, garanzia e diritti di proprietà intellettuale nonché il controllo sui propri dati inclusa la loro consegna senza diritto di ritenzione. L'accesso può essere concretizzato contrattualmente: il fornitore BESA QSys indica che l'accesso alla soluzione SaaS è limitato di default tramite geoblocking o può essere ristretto a determinati luoghi di accesso durante il setup. Tali indicazioni vanno confrontate con l'SLA, poiché un blocco dell'accesso può attivare gli stessi termini di disponibilità e assistenza.

Al coordinamento appartengono ulteriori punti: regolamentazioni sul diritto d'autore e IP, su responsabilità e garanzia nonché su cosa accade ai dati dopo la fine del contratto. Per i contratti soggetti al diritto tedesco, le CGC predisposte vanno misurate sugli §§ 305–310 BGB. Per i contratti con riferimento internazionale, specialmente per i servizi cloud, è indicata una verifica aggiuntiva.

Checklist per la negoziazione contrattuale

La checklist verifica le tre aree dell'SLA in questo ordine: disponibilità, assistenza, sanzioni. Ogni punto è soddisfatto solo quando il contratto contiene un'indicazione verificabile – un valore, un periodo, un termine o una soglia.

Definizioni: Cos'è un errore, cos'è un vizio, cos'è un disturbo? A cosa si riferisce la disponibilità? Quando inizia a decorrere un tempo di reazione? Le definizioni nell'SLA rispondono a queste domande e sono presupposto affinché il documento non rimanga inefficace.

Misurazione e periodi di riferimento: Chi misura cosa, come e per quali periodi? Quale periodo di calcolo vale per la disponibilità e quale valore misurato è determinante in caso di controversia?

Orari di assistenza: Annotare separatamente tempi di reazione, intervento e risoluzione e differenziare per grado di gravità (modello di incidenti graduato con livelli di severità). Regolamentare inoltre la reperibilità dell'assistenza.

Finestre di manutenzione ed esclusioni: Definire quali aspetti rientrano in una finestra di manutenzione e quali condizioni quadro si applicano (comunicazione preventiva, orari chiaramente definiti). Circoscrivere rigorosamente le esclusioni – candidati tipici sono dipendenze da terzi, attacchi DDoS e forza maggiore.

Conseguenze e coordinamento: Una regolamentazione sulle conseguenze delle violazioni dell'SLA compresi i meccanismi di escalation è obbligatoria, altrimenti l'SLA rimane privo di denti. Verificare infine se livelli di servizio, contratto SaaS, CGC, contratto di elaborazione dati (DPA) e documentazione sulla protezione dei dati siano coordinati tra loro.

Prova: Fissare forma e periodicità del reporting, regolamentare i diritti di accesso ai dati di misurazione, chiarire la gestione delle lacune nei dati e determinare quale misurazione venga riconosciuta come riferimento.

Responsabilità: Verificare come interagiscano le sanzioni SLA e le norme generali di responsabilità – in particolare se un accredito resti definitivo o se sussistano ulteriori pretese.

Fine del contratto: Regolamentare cosa accade ai dati dopo la fine del contratto e chiarire la situazione dei diritti IP e d'autore.

Lista di controllo per le negoziazioni contrattuali SLA