Contratti software, SaaS e cloud

La prima domanda non è quanto costa, ma cosa ricevi giuridicamente. Il software è tutelato come opera dell’ingegno (l. 633/1941, artt. 64-bis ss.). Nella stragrande maggioranza dei contratti non compri il programma: ottieni una licenza d’uso, cioè un diritto d’uso limitato dal contratto quanto a durata, utenti, finalità, territorio e modalità tecniche, su qualcosa che resta del fornitore. La cessione dei diritti — rara, tipica solo degli sviluppi su commessa — trasferisce invece la titolarità. Se firmi una «licenza», non compri un bene: acquisisci un diritto d’uso perimetrato.

Nell’on-premise il software è installato sui tuoi sistemi: mantieni il controllo dell’infrastruttura e, spesso, una licenza perpetua e una copia che può continuare a funzionare secondo durata, condizioni e dipendenze tecniche della licenza — cioè solo se la licenza è perpetua o non condizionata al rinnovo di manutenzione, attivazione o servizi esterni.

Nel SaaS/cloud il rapporto riguarda normalmente l’accesso continuativo a un ambiente applicativo e l’erogazione di servizi digitali (assistenza, manutenzione, aggiornamenti, gestione dell’infrastruttura). La qualificazione giuridica dipende dal contenuto concreto del contratto e dalla sua causa prevalente: può trattarsi di un contratto atipico complesso riconducibile, secondo i casi, allo schema dell’appalto di servizi e, per quanto compatibile, alla disciplina delle prestazioni continuative o periodiche (art. 1677 c.c.). La giurisprudenza non è uniforme: Cass. civ., ord. n. 21230/2023, ha qualificato come appalto di servizi una licenza con installazione, manutenzione e aggiornamenti; in senso diverso App. Bologna, sent. n. 931/2026, ha valorizzato la prevalenza traslativa della licenza di software standardizzato con servizi accessori. La qualificazione va fatta sul singolo contratto.

Nel SaaS il cliente normalmente non riceve una copia autonoma e utilizzabile del programma, ma accede a una funzionalità erogata dal fornitore per la durata del rapporto (possono comunque esistere copie temporanee, cache, componenti locali, client). Quando il servizio si interrompe, non ti resta in mano una copia autonoma su cui continuare a lavorare.

Lo SLA rende misurabile la promessa di funzionamento. Parametri: uptime, RTO, tempi di risposta e presa in carico. Un SLA serio definisce come si calcola la percentuale, cosa è escluso (le «manutenzioni programmate» possono svuotare un 99,9%) e chi misura. La clausola penale (art. 1382 c.c.) predetermina il risarcimento senza provare il danno: di norma lo limita a quanto convenuto, salvo patto sul danno ulteriore, e il giudice può ridurla se manifestamente eccessiva (art. 1384 c.c.). Il service credit (credito o sconto sul canone per SLA mancato) è la forma tipica nel cloud; la sua portata si riduce quando è irrisorio rispetto al danno o è configurato come «sole and exclusive remedy».

Dietro il contratto c’è quasi sempre una catena: hyperscaler, moduli di terzi, supporto delocalizzato. Sul piano civilistico il fornitore resta l’unico interlocutore e risponde di norma di ausiliari e subfornitori, salvo limitazione espressa. Sul piano della protezione dati, se tratta dati personali per tuo conto è responsabile (art. 28 GDPR); ogni subfornitore che tratta quei dati è sub-responsabile. L’art. 28 richiede autorizzazione scritta del titolare, specifica o generale; con autorizzazione generale il responsabile deve informare il titolare delle modifiche (aggiunta o sostituzione di sub) dando modo di opporsi; al sub vanno imposti per contratto gli stessi obblighi di protezione dati; il responsabile principale risponde verso il titolare dell’inadempimento del sub in materia di protezione dati, non di ogni inadempimento commerciale o tecnico (che segue le regole civilistiche del contratto).

Un cattivo exit è la forma più efficace di lock-in. Quattro elementi: formati aperti e interoperabili; tempi certi con periodo di reversibilità; assistenza alla migrazione a condizioni definite in anticipo; cancellazione certificata a fine rapporto, backup e copie dei sub inclusi (art. 28, par. 3, lett. g, GDPR per i dati personali).

Portabilità: attenzione al fondamento. L’art. 20 GDPR non è il fondamento generale della portabilità di tutti i dati aziendali: riconosce la portabilità solo dei dati personali dell’interessato, entro il suo specifico ambito. Per i servizi cloud il riferimento principale a portabilità e passaggio è oggi il Data Act; il GDPR resta per i dati personali.

Cap di responsabilità: limite al risarcimento (spesso 6-12 mesi di canone), legittimo tra imprese ma da pesare sul danno potenziale. Esclusioni: danni indiretti, lucro cessante, perdita di dati — da soppesare voce per voce. Limiti inderogabili: l’art. 1229 c.c. rende nullo il patto che esclude o limita la responsabilità per dolo o colpa grave; gli artt. 1341-1342 c.c. operano quando il contratto è su condizioni generali predisposte unilateralmente: in tal caso, e ricorrendone i presupposti, le clausole dell’art. 1341, co. 2 (limitazioni di responsabilità, recesso o sospensione, decadenze, deroghe alla competenza) sono inefficaci se non specificamente approvate per iscritto — non è una regola generale per ogni SaaS, e con un consumatore vale il regime degli artt. 33 ss. C. Cons. La manleva tipica è quella IP: attenzione a esclusioni e cap che la svuotano.

Non esiste un default unico: la titolarità dipende dal contratto e dalla natura dell’apporto creativo. Distingui: codice preesistente del fornitore (background) — resta suo, licenza a te; codice sviluppato dal fornitore nel servizio — dipende dal contratto; configurazioni e parametrizzazioni — da regolare quanto a riutilizzo; documentazione; sviluppi commissionati (foreground) — per la titolarità serve cessione espressa, in mancanza resti con una licenza dal perimetro contrattuale; materiali del cliente — restano tuoi. Quando lo sviluppo su misura prevale, il rapporto si avvicina all’appalto (art. 1655 c.c.), con la disciplina di vizi e difformità (artt. 1667-1668 c.c.).

I tuoi dati non sono un blocco unico. Il contratto dovrebbe distinguere dati forniti o generati dal cliente, dati personali, metadati, dati aggregati, output e componenti proprietarie del fornitore. Per ciascuna categoria vanno definiti accesso, uso, riutilizzo, portabilità, conservazione e cancellazione. Diffida delle clausole che qualificano genericamente come proprietà del fornitore i dati generati nel servizio; regola l’uso ulteriore (training, profilazione, benchmark). (Per la PA valgono regole specifiche di riuso, art. 69 CAD, non estensibili ai privati.)

Per banche e altri soggetti destinatari della disciplina prudenziale della Banca d’Italia, le regole sull’esternalizzazione e sulla gestione dei sistemi informativi vanno verificate nella versione vigente della Circolare n. 285/2013 e nelle disposizioni applicabili alla categoria del soggetto. Il riferimento non è automaticamente estendibile a ogni soggetto vigilato: per intermediari finanziari, istituti di pagamento, IMEL e altri operatori possono operare fonti e disposizioni settoriali differenti. Per gli istituti di pagamento, ad esempio, la disciplina primaria su esternalizzazione e vigilanza ha riferimenti nel TUB (tra cui l’art. 114-quaterdecies TUB).