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

SLA come strumento di gestione nel contratto SaaS

Un accordo sul livello di servizio (SLA) fissa, come parte integrante del contratto 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 gestione alle soluzioni SaaS fino all’outsourcing IT classico. Nel settore IT sono diventati noti 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’intelligenza artificiale generativa. A seconda dell’applicazione, varia la criticità dei processi aziendali e, di conseguenza, il rigore necessario 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; gli obblighi principali di prestazione vanno descritti 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.

Elementi SLA nel contratto SaaS: disponibilità, assistenza e sanzioni

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 costituiscono i tipici contenuti di una finestra di manutenzione e devono figurare nel contratto con preavviso, canale di comunicazione e orari chiaramente definiti.

Per la misurazione ne consegue che i lavori di manutenzione pianificati non devono confl uire nel calcolo della disponibilità. Altrimenti ogni manutenzione regolarmente annunciata verrebbe conteggiata come guasto, 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 risulta dalla percentuale, ma dal metodo di misurazione concordato e dal periodo di riferimento.

Assistenza: tempi di reazione, intervento e risoluzione

Un SLA distingue tipicamente tre nozioni 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à del caso, in un modello di incidenti scalare con livelli di gravità (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 sapere quando inizia a decorrere un 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 definizione semplice nell’SLA risponde a questa domanda. Senza di essa, in caso di controversia resta aperto se un termine sia stato violato.

Alle nozioni 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. La variante adatta dipende da quanto sia critico il processo aziendale che gira sul prodotto SaaS. Un modello di incidenti scalare 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 con 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 evase 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.

Le tre nozioni temporali sono contemporaneamente i parametri di riferimento delle sanzioni. Un termine mancato fornisce la prova misurabile alla quale si aggancia un credito o un livello di escalation.

Gradi di gravità nel modello di incidenti scalare (Severity Levels)

Definizioni ed esclusioni: affinché l’SLA non resti 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 come vengono descritti errori e vizi. Solo tramite questa definizione si può 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 stretto: 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 restare inefficaci. I punti deboli si mostrano regolarmente solo in caso di prestazione difettosa, 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 precisazioni, 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 chi fornisce i numeri.

Al reporting appartiene 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 nella misurazione. Quale numero sia determinante in caso di controversia non risulta 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 indicati non è possibile provare un mancato rispetto. Forma, periodicità e diritti di accesso vanno quindi regolati insieme al credito.

Controlli regolari per proteggersi 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.

Sanzioni e conseguenze in caso di violazione dell’SLA

In mancanza di una regolamentazione sulle conseguenze in caso di violazione, l’SLA resta 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 agganciano ai valori misurati. Senza una misurazione regolamentata manca la base per accertare una violazione e attivare un credito.

Come conseguenze nella pratica si discutono spesso crediti sul corrispettivo ricorrente, inoltre livelli di escalation dal primo punto di contatto fino alla direzione aziendale nonché diritti di recesso o rescissione straordinari in caso di violazioni ripetute o gravi. Quali meccanismi intervengano e a partire da quale soglia deve figurare nella regolamentazione delle conseguenze. L’escalation dovrebbe agganciarsi agli stessi livelli di gravità concordati per i tempi di assistenza.

Quattro indicazioni rendono verificabile una clausola sanzionatoria: la soglia a partire dalla quale interviene, l’importo del credito come quota del corrispettivo ricorrente, un eventuale limite superiore e il numero di ripetizioni a partire dal quale interviene un diritto di recesso straordinario. Solo con queste indicazioni si può calcolare in caso di controversia.

Crediti, livelli di escalation e diritti di recesso funzionano solo se sono indicate soglie e competenze. Senza queste indicazioni ogni sanzione resta 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 contenuto contrattuale usuale. 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 credito resti la conseguenza definitiva o se sussistano ulteriori pretese.

Procedura in caso di violazione SLA: dalla segnalazione al credito

Integrazione nel contratto SaaS, CGC e pratica svizzera

Nei modelli SaaS standardizzati, contratto SaaS, condizioni generali di contratto (CGC), livelli di servizio, contratto di elaborazione degli ordini (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 va prima risolta.

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 a 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 una procedura ordinata 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 tramite 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 sulla proprietà intellettuale, sulla responsabilità e sulla garanzia nonché su cosa accada ai dati dopo la fine del contratto. Per i contratti con diritto tedesco, le CGC predisposte vanno misurate sugli §§ 305–310 del BGB (Codice civile tedesco). Per i contratti con riferimento internazionale, in particolare 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 resti 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: fissare separatamente tempi di reazione, intervento e risoluzione e differenziarli in base alla gravità (modello di incidenti scalare con Severity Levels). 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 strettamente le esclusioni – candidati tipici sono le dipendenze da terzi, gli attacchi DDoS e la forza maggiore.

Conseguenze e coordinamento: una regolamentazione sulle conseguenze delle violazioni SLA con meccanismi di escalation è indispensabile, altrimenti l’SLA resta privo di denti. Verificare infine se livelli di servizio, contratto SaaS, CGC, contratto di elaborazione degli ordini (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 nella misurazione 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 credito resti definitivo o se sussistano ulteriori pretese.

Fine del contratto: regolamentare cosa accada ai dati dopo la fine del contratto e chiarire la situazione dei diritti di proprietà intellettuale e d’autore.

Checklist per la negoziazione contrattuale: criteri SLA