Un contratto fra le persone sbagliate
Il contratto era stato firmato a fine 2023, e dal punto di vista del fornitore principale era un contratto pulito, ben strutturato, con tutte le clausole di salvaguardia che l’ufficio legale aveva preteso negli anni. Specificava chiaramente l’oggetto della fornitura, individuava i livelli di servizio, fissava le penali per il mancato rispetto, definiva il perimetro della responsabilità del fornitore con limitazioni standard al valore annuo del contratto, escludeva i danni indiretti, regolava la subfornitura attraverso una clausola che richiedeva al cliente di approvare i sub-fornitori principali e che spostava sul cliente la responsabilità di verificarne l’adeguatezza. Era stato negoziato per quattro mesi, era passato attraverso tre cicli di revisione legale da entrambe le parti, era stato firmato da figure dirigenziali con le procure necessarie. Il fornitore principale, una software house di cinquanta persone, lo considerava un buon contratto. Il cliente, una società di servizi sanitari privati con un milione di assistiti, lo considerava un contratto equilibrato. Per due anni il rapporto è andato bene.
A fine 2025 un assistito ha subito un danno da quello che il sistema clinico avrebbe dovuto fare e non ha fatto. La causa tecnica è stata attribuita a una libreria di valutazione del rischio che il sistema usava per classificare le priorità di intervento. La libreria era stata fornita da un sub-fornitore approvato dal cliente quattro anni prima, era stata aggiornata silenziosamente dal sub-fornitore stesso ottanta giorni prima dell’incidente con un cambiamento di algoritmo che nessuno aveva comunicato al fornitore principale, e nessuno aveva richiesto un cambiamento di documentazione perché il sub-fornitore considerava il proprio aggiornamento come una manutenzione ordinaria. Il sub-fornitore aveva sede in un paese terzo, non aveva rappresentante legale nell’Unione, e nei mesi successivi alla causa è risultato di fatto irraggiungibile per le notifiche giudiziarie.
Il fornitore principale ha reagito alla richiesta di danni del legale dell’assistito mostrando il contratto. Ha sostenuto che il sub-fornitore era stato approvato dal cliente, che la modifica era stata introdotta unilateralmente dal sub-fornitore senza alcuna comunicazione, che il contratto escludeva i danni indiretti e limitava la responsabilità al valore annuo, e che comunque la responsabilità materiale ricadeva sul cliente in qualità di soggetto che gestiva direttamente la relazione con l’assistito. Il legale dell’assistito non ha contestato nessuno di questi punti contrattuali. Ha semplicemente notato che il contratto fra fornitore e cliente non lo riguardava, perché lui non lo aveva firmato, e che la sua azione era basata sul nuovo regime europeo di responsabilità del prodotto, sotto il quale il fornitore principale era qualificabile come produttore del prodotto difettoso e rispondeva a titolo oggettivo verso il danneggiato finale a prescindere dalle clausole contrattuali pattuite con il proprio cliente. Quelle clausole, ha aggiunto, regolavano la rivalsa fra le parti firmatarie, non l’esposizione verso terzi. Il contratto, in altre parole, era un buon contratto fra le persone sbagliate.
L’obiezione tradizionale
L’obiezione che vorrei affrontare subito, perché è la più radicata e la più sincera, è quella che viene dai legali tradizionali con cui ho lavorato in questi anni. Suona così: tutto questo è un problema di scrittura del contratto. Se le clausole sono ben scritte, se le manleve sono complete, se le procedure di sub-fornitura sono rigorose, il fornitore principale è protetto. È un’obiezione formalmente coerente con il modo in cui il diritto contrattuale ha funzionato per quarant’anni nel software. Era un’obiezione che fino a qualche anno fa era anche sostanzialmente vera, perché il regime di responsabilità del produttore di software era debole, le azioni dei terzi danneggiati passavano quasi sempre attraverso il cliente diretto, e il fornitore principale poteva ragionevolmente attendersi che la propria esposizione si esaurisse nei limiti contrattuali pattuiti.
Quell’epoca è finita. Il regime giuridico che si sta consolidando in Europa fra il 2024 e il 2027, e di cui ho già scritto in questa serie a proposito del prodotto software valutato come promessa scritta e della specifica come asset giuridicamente rilevante, introduce un livello di responsabilità che opera al di fuori del contratto e che il contratto può solo parzialmente disciplinare. La revisione della Product Liability Directive, applicabile dal 9 dicembre 2026, qualifica esplicitamente il software come prodotto e applica al produttore di software un regime di responsabilità oggettiva verso i danneggiati finali. Il Cyber Resilience Act, applicabile pienamente dall’11 dicembre 2027, introduce obblighi di sicurezza del prodotto digitale che gravano sul produttore lungo tutto il ciclo di vita, e che si estendono ai componenti integrati. L’AI Act distribuisce obblighi lungo la catena dei fornitori di sistemi di AI in modo che il provider del sistema finale debba garantire che i componenti che integra siano conformi. Il Digital Operational Resilience Act, applicabile dal 17 gennaio 2025, impone alle entità finanziarie e ai loro fornitori critici di ICT obblighi di gestione del rischio della catena di fornitura che attraversano i confini contrattuali. NIS2, applicabile dal 18 ottobre 2024, fa lo stesso movimento per i settori critici allargati. Ognuno di questi atti, preso singolarmente, sarebbe gestibile con qualche aggiustamento contrattuale. Presi insieme, e nelle loro intersezioni, definiscono una struttura di responsabilità che il contratto di fornitura non è più in grado di contenere.
I quattro presupposti caduti
Il modello contrattuale tradizionale del software è cresciuto in un’epoca in cui valevano alcuni presupposti impliciti, ed è diventato inadeguato perché tutti questi presupposti sono saltati nello stesso decennio. C’era anzitutto l’idea che la responsabilità del fornitore verso il cliente esaurisse l’esposizione del fornitore, perché il cliente intermediario assorbiva e gestiva qualsiasi responsabilità verso terzi danneggiati. C’era poi la convinzione che il software fosse un oggetto delimitato nel tempo della consegna, valutabile sulla base di un capitolato statico al momento del rilascio. Si dava per scontato, in terzo luogo, che la catena di fornitura fosse essenzialmente bilaterale dal punto di vista giuridico, cioè che ogni anello potesse essere disciplinato da un contratto fra due parti senza dover preoccuparsi delle dinamiche complessive della catena. E si presupponeva infine che il regime di responsabilità rimanesse stabile nel tempo, abbastanza da rendere ragionevole firmare contratti pluriennali sulla base del quadro giuridico vigente al momento della firma. Erano presupposti che sembravano leggi di natura della contrattazione software fino al 2020 circa, e che a posteriori si rivelano essere semplicemente le caratteristiche di un’epoca giuridica specifica.
Il primo presupposto è stato eroso dall’allargamento della legittimazione attiva dei terzi danneggiati nella nuova PLD. Sotto il vecchio regime di responsabilità del prodotto, il danneggiato finale poteva agire contro il produttore ma in pratica le azioni passavano per lo più attraverso il rivenditore o l’integratore commerciale, e il produttore di software, fino al 2024, godeva di un’incertezza interpretativa sul fatto stesso di rientrare nella definizione di produttore. La nuova Direttiva, includendo il software esplicitamente nella definizione di prodotto e introducendo presunzioni di difettosità che alleggeriscono l’onere probatorio del danneggiato, rende la posizione del produttore di software molto più esposta. Aggiunge inoltre un meccanismo di disclosure documentale che permette al giudice di ordinare al fornitore di esibire la documentazione tecnica del prodotto, e di presumere il difetto in caso di mancata esibizione. Da quel momento il legale del danneggiato non ha più bisogno di passare attraverso il cliente intermediario, e può agire direttamente contro il fornitore principale del software che ha causato il danno, ignorando del tutto le clausole contrattuali fra fornitore e cliente, perché quelle clausole regolano un rapporto a cui il danneggiato è terzo. La cosa è scritta esplicitamente nell’Articolo 15 della Direttiva, intitolato «Esclusione o limitazione della responsabilità», che impone agli Stati membri di assicurare che la responsabilità dell’operatore economico verso il danneggiato non possa essere limitata o esclusa né da clausole contrattuali né da disposizioni di diritto nazionale. È un articolo breve e tecnico, ma è la chiave di volta dell’intero impianto, perché trasforma quello che sembrava un margine di manovra contrattuale in una zona di indisponibilità giuridica.
Il secondo presupposto è stato eroso dal Cyber Resilience Act e dall’AI Act, che entrambi introducono obblighi di sicurezza e di gestione del rischio che gravano sul produttore lungo tutto il ciclo di vita del prodotto, non solo al momento della consegna. Il software ha cessato di essere un oggetto delimitato nel tempo della consegna, e si configura come un oggetto continuamente esposto al regime regolatorio, e ogni aggiornamento, ogni modifica, ogni integrazione di nuovi componenti, può essere riqualificato come modifica sostanziale che fa rientrare il prodotto nel regime applicativo, anche se il prodotto era stato immesso sul mercato in epoca precedente. Il fornitore principale che ha consegnato il sistema nel 2023 non si è scaricato della responsabilità nel 2026 quando una libreria di terze parti integrata in quel sistema ha smesso di essere mantenuta e ha sviluppato vulnerabilità di sicurezza. La responsabilità si è semplicemente spostata sul piano della manutenzione, e il fornitore che non ha aggiornato è un fornitore che è venuto meno a un obbligo continuativo, non a un obbligo limitato al momento della consegna originaria.
Anche il terzo presupposto, quello sulla bilateralità della catena di fornitura, è stato eroso dall’introduzione di catene di responsabilità che attraversano la contrattazione bilaterale. Sotto il regime DORA, l’entità finanziaria deve mappare e gestire i propri ICT third-party risk lungo tutta la catena, e quando un fornitore è qualificato come critico le obbligazioni si estendono in modo che le clausole contrattuali fra l’entità finanziaria e il fornitore critico devono contenere elementi specifici imposti dal Regolamento, indipendentemente dalla volontà delle parti. Il CRA, da parte sua, impone al produttore di un prodotto digitale di garantire la sicurezza del prodotto integrato, e questa garanzia non si esaurisce nei rapporti contrattuali con i propri sub-fornitori, perché il regolatore valuta il prodotto come un tutto unitario indipendentemente dalla composizione interna della catena di fornitura. La PLD revisionata aggiunge un’ulteriore complicazione, prevedendo che il modificatore sostanziale di un prodotto possa diventare lui stesso responsabile come produttore, e questo crea una dinamica di responsabilità circolare in cui il fornitore principale, l’integratore intermedio, il sub-fornitore e l’utilizzatore finale possono essere chiamati in causa con titoli diversi per lo stesso danno. NIS2 e l’AI Act completano il quadro estendendo obblighi analoghi rispettivamente ai settori critici allargati e ai sistemi di intelligenza artificiale ad alto rischio, con il risultato che ogni segmento della catena è oggi attraversato da almeno due o tre regimi sovrapposti che le clausole contrattuali bilaterali non riescono a comporre.
Il quarto presupposto, quello della stabilità del regime giuridico nel tempo, è quello la cui erosione produce gli effetti più subdoli, perché i contratti pluriennali firmati oggi sotto il quadro vigente saranno applicati domani sotto un quadro che si sarà evoluto. Il fornitore che firma un contratto a sei o sette anni nel 2026 si troverà a eseguirlo nel 2032 o 2033 sotto regimi che potrebbero essere cambiati a quel punto in modo significativo, perché la PLD prevede una clausola di revisione, perché il CRA sarà oggetto di linee guida che modificheranno l’interpretazione di intere sezioni, perché l’AI Act è già stato definito un cantiere aperto dalla Commissione stessa. Il contratto pluriennale sotto il modello tradizionale presupponeva un’inerzia regolatoria che non c’è più.
Quattro fenomeni che il contratto non indirizza
Ognuno di questi quattro fenomeni ha conseguenze pratiche che il contratto tradizionale non sa indirizzare. La responsabilità solidale dei fornitori di componenti critici, introdotta in modi diversi da PLD e CRA, fa sì che il fornitore principale risponda dei difetti dei componenti integrati anche quando i sub-fornitori sono inadempienti o irraggiungibili. Le clausole contrattuali che disciplinano la rivalsa contro i sub-fornitori restano valide fra le parti firmatarie, ma non spostano la responsabilità verso il danneggiato finale, che può sempre agire contro il fornitore principale come anello accessibile e patrimonialmente più solido della catena. Il fornitore principale che voleva traslare il rischio sul sub-fornitore mediante clausole contrattuali si trova quindi a doverlo assorbire e a poter solo successivamente provare a recuperare per via di rivalsa, ammesso che il sub-fornitore sia ancora esistente, solvibile e raggiungibile.
Gli obblighi di disclosure documentale introdotti dalla nuova PLD sono il secondo fenomeno, e sono particolarmente insidiosi perché trasformano il fornitore in un soggetto che deve esibire al giudice la propria documentazione tecnica anche quando questa documentazione include scelte progettuali, configurazioni di sicurezza, dataset di addestramento, decisioni architetturali che l’azienda considererebbe segreto industriale. Il giudice deve bilanciare il diritto alla disclosure con la tutela dei segreti commerciali, ma in pratica il fornitore si trova esposto a richieste documentali che il contratto con il cliente non può limitare, perché il contratto non vincola il giudice né il danneggiato. Il fornitore può aver pattuito con il cliente l’inaccessibilità della documentazione, ma se il danneggiato chiede l’esibizione il fornitore deve produrre, e l’eventuale rifiuto di esibire genera presunzione di difettosità ai sensi dell’Articolo 10 della Direttiva.
Le presunzioni di difettosità che il singolo fornitore non può sfatare da solo sono il terzo fenomeno, e sono il più sottile dei quattro. La nuova PLD prevede che il giudice possa presumere la difettosità del prodotto quando il prodotto è tecnicamente o scientificamente complesso e la prova del difetto sarebbe eccessivamente difficile per il danneggiato. Per i sistemi software complessi, in particolare per quelli che integrano componenti AI, questa presunzione si attiva quasi automaticamente, e l’onere di sfatare la presunzione ricade sul fornitore. Sfatare la presunzione richiede di dimostrare che il prodotto al momento della consegna non presentava il difetto, oppure che il difetto è stato introdotto successivamente da modifiche fuori dal controllo del fornitore. Entrambe le dimostrazioni richiedono documentazione storica dettagliata del sistema, e il fornitore che non ha mantenuto questa documentazione si trova a non poter provare nulla, e quindi a soccombere alla presunzione.
L’accountability del modificatore sostanziale è il quarto fenomeno, ed è quello che più radicalmente rompe la struttura del contratto bilaterale. Quando un cliente o un integratore intermedio modifica sostanzialmente un prodotto software fornito da un terzo, può diventare lui stesso responsabile come produttore del prodotto modificato, e questo apre una dinamica in cui il fornitore originale potrebbe non essere più responsabile per il prodotto come è stato modificato, ma il modificatore potrebbe non avere le competenze, la documentazione e la struttura per assumere la responsabilità che ha materialmente assunto. Il risultato è una zona grigia di responsabilità in cui il danneggiato sceglie chi citare in giudizio sulla base di criteri di accessibilità patrimoniale e procedurale, e in cui le parti coinvolte si rimpallano la responsabilità con esiti spesso paradossali.
L’assestamento che non arriva subito
Si potrebbe obiettare, e qualcuno lo farà, che tutto questo è esagerato e che la prassi giudiziaria troverà un modo per riportare l’ordine nel sistema. È un’obiezione che merita rispetto, perché la prassi giudiziaria ha sempre questa funzione assestante, e perché i regolamenti europei, una volta tradotti in giurisprudenza nazionale, perdono spesso la rigidità che hanno sulla carta. La risposta che mi sento di dare, dopo aver osservato come si sta muovendo la prassi nelle giurisdizioni europee dove i primi casi stanno emergendo, è che l’assestamento avverrà, ma avverrà in cinque o sette anni, e nel frattempo la finestra di esposizione per i fornitori che operano sotto contratti tradizionali è molto larga. Le prime sentenze rilevanti in materia di responsabilità del produttore di software sotto la nuova PLD non arriveranno prima del 2028, perché il regime si applica ai prodotti immessi sul mercato dopo il 9 dicembre 2026 e le cause hanno tempi minimi di un anno e mezzo. Da quel momento occorreranno altri tre o quattro anni perché si formi una giurisprudenza consolidata. Nel frattempo, ogni fornitore che opera con contratti del modello vecchio sta accumulando esposizione retroattiva, perché molti dei sistemi che sta consegnando oggi saranno ancora in produzione quando la giurisprudenza si sarà assestata, e saranno valutati con i criteri che si saranno consolidati a quel punto.
I settori che ci precedono
Sarebbe disonesto non riconoscere che ci sono settori dove queste dinamiche esistono già da decenni, e dove i contratti di fornitura hanno una struttura che riconosce l’inadeguatezza del modello bilaterale tradizionale. Sono settori che vivono sotto regimi di responsabilità del prodotto stretti da molto prima del software generalista, e che hanno sviluppato pratiche contrattuali che meritano di essere studiate. L’aviazione civile è uno di questi, e i contratti di fornitura di componenti aeronautici incorporano da sempre obblighi di tracciabilità documentale, di certificazione di parte terza, di gestione coordinata delle non conformità, di responsabilità solidale verso le autorità regolatorie. Il dispositivo medico è un altro, e i contratti di fornitura di componenti per dispositivi medici prevedono accordi quadro di qualità che vanno al di là del singolo contratto commerciale, e che disciplinano la relazione fra le parti come una relazione regolatoria oltre che commerciale. L’automotive è il terzo, soprattutto dopo l’introduzione delle norme ISO 26262 sulla sicurezza funzionale dei sistemi elettronici dei veicoli, e i contratti di fornitura di software per automotive incorporano da una decina d’anni clausole di responsabilità lungo la catena che riconoscono l’impossibilità di confinare l’esposizione nei rapporti bilaterali.
Quello che sta accadendo nel software generalista è la convergenza, accelerata dal pacchetto regolatorio europeo, verso il modello che questi settori già praticano. La differenza è che aviazione, dispositivi medici e automotive hanno avuto trent’anni per costruire le pratiche contrattuali, le competenze interne, gli standard di settore, e le relazioni di fornitura strutturate. Il software generalista ha cinque o sette anni per fare la stessa cosa, e lo deve fare mentre continua a operare in mercati dove la maggior parte dei competitor ancora ragiona con il modello vecchio. È una transizione asimmetrica, in cui chi si muove per primo paga un costo di posizionamento che chi si muove dopo non paga, ma chi si muove per primo costruisce anche capacità di assorbire le evoluzioni regolatorie successive che chi si muove dopo dovrà acquistare a mercato consolidato.
Cinque dimensioni operative
Su un piano operativo, la trasformazione del contratto di fornitura software ha cinque dimensioni che vanno gestite contemporaneamente. La prima è il passaggio dal contratto come documento ai documenti contrattuali come ecosistema. Un contratto di fornitura software sotto il nuovo regime non si esaurisce in un documento singolo che vale fino al rinnovo, ma costituisce un sistema di documenti correlati che includono il contratto principale, gli allegati di livelli di servizio, gli allegati di sicurezza, gli accordi di qualità simili a quelli del medical device, gli accordi di trattamento dei dati personali ai sensi dell’Articolo 28 GDPR, gli accordi di gestione coordinata delle vulnerabilità, gli accordi di disclosure reciproca della catena di fornitura. Ognuno di questi documenti vive con un proprio ciclo di aggiornamento, e il contratto principale diventa il quadro che li tiene insieme, non il contenitore di tutte le clausole.
La seconda dimensione è la trasformazione della clausola di limitazione della responsabilità. Le clausole tradizionali che limitano la responsabilità del fornitore al valore annuo del contratto, o che escludono i danni indiretti, restano valide fra le parti firmatarie ma non producono effetti verso i terzi danneggiati. Per il fornitore questo significa che l’esposizione effettiva è quella verso il danneggiato finale, non quella concordata con il cliente, e le polizze assicurative devono essere dimensionate su quella esposizione effettiva, non sui massimali contrattuali. La pratica assicurativa del settore è in questo momento confusa, perché le compagnie stanno ridefinendo i prodotti per la responsabilità civile dei produttori di software in funzione del nuovo regime, e i premi stanno aumentando in modo non lineare. Per le software house italiane di dimensione media, il costo assicurativo della responsabilità di prodotto sta diventando una voce di bilancio rilevante, dove fino a qualche anno fa era una voce trascurabile.
La terza dimensione è la riscrittura delle clausole sulla subfornitura, che devono passare da un modello in cui il cliente approva i sub-fornitori principali al momento della firma a un modello in cui esiste una procedura continua di valutazione, monitoraggio e disclosure dei sub-fornitori lungo tutta la durata del contratto. Il fornitore principale deve poter dimostrare in qualsiasi momento la composizione della propria catena di fornitura, deve poter produrre la SBOM ai sensi del CRA, deve poter rispondere a richieste di audit del cliente o del regolatore, deve gestire le situazioni in cui un sub-fornitore esce dal mercato o cessa la manutenzione di un componente. Tutto questo richiede strumenti di gestione della catena di fornitura che il modello contrattuale tradizionale dava per scontati e che oggi diventano oggetto di attività operativa continua.
La quarta dimensione è l’introduzione di clausole di gestione coordinata delle vulnerabilità e degli incidenti di sicurezza. Sotto il CRA, sotto NIS2 e sotto DORA per il finanziario, il fornitore e il cliente hanno entrambi obblighi di reporting in finestre temporali strette, e il rispetto di queste finestre richiede un coordinamento che il contratto deve disciplinare in modo operativo, non solo formale. Una clausola che dice «le parti collaborano nella gestione degli incidenti» è inutile se non specifica chi notifica, in quanto tempo, attraverso quali canali, con quali soglie di gravità. La clausola deve essere quasi un mini-runbook contrattuale, e la sua qualità si misura nella capacità di funzionare nel momento in cui un incidente reale è in corso, non nella sua eleganza giuridica.
La quinta dimensione è la più sottile, e riguarda la gestione del ciclo di vita del prodotto. Sotto il CRA il produttore deve dichiarare il periodo di supporto del prodotto e mantenerlo per quel periodo, e deve gestire l’uscita del prodotto dal mercato in modo che gli utilizzatori siano informati e abbiano percorsi di transizione. Il contratto di fornitura software deve disciplinare questo aspetto, perché il fornitore principale è esposto verso il danneggiato finale anche dopo la fine della relazione contrattuale con il cliente, e perché la gestione dell’end of support diventa un momento critico in cui responsabilità residue possono materializzarsi. Le clausole tradizionali di perpetual licence o di no warranty after termination non producono effetti verso i terzi danneggiati, e questo significa che il fornitore deve gestire il ciclo di vita del prodotto come una funzione che eccede la durata del contratto.
Disclosure: diciotto mesi di riscrittura
Devo essere trasparente su un punto, perché su questo argomento sto descrivendo trasformazioni che sto vivendo in prima persona. La revisione dei nostri contratti di fornitura, dentro l’azienda dove lavoro, è un’attività in corso da diciotto mesi e non è ancora arrivata a una forma stabile. Stiamo lavorando con il nostro studio legale di riferimento per riscrivere il contratto base di fornitura di servizi software, e quello che sta venendo fuori dista molto dal contratto pulito ed elegante che speravamo di produrre, e ha la forma di un sistema di documenti più articolato del precedente, con allegati che esistono per ragioni diverse e che non si possono ridurre a un singolo template. Alcuni clienti accettano la nuova struttura, altri la trovano inutilmente complessa e chiedono di tornare al modello vecchio. La pressione del mercato verso la semplicità contrattuale è ancora forte, e in qualche caso noi stessi accettiamo di firmare contratti del modello vecchio quando il cliente lo impone, sapendo che stiamo accumulando esposizione retroattiva. È una scelta che facciamo per ragioni commerciali immediate, e che ho chiamato esposizione composta nelle nostre conversazioni interne, perché si accumula in modo non lineare al crescere del portafoglio clienti.
Un’opportunità, non solo un peso
Voglio anche dire, perché altrimenti il pezzo sembrerebbe una previsione pessimistica sull’industria del software italiano, che la trasformazione che sto descrivendo è un’opportunità prima di essere un peso. Le software house italiane di dimensione media che decideranno di costruire competenze contrattuali coerenti con il nuovo regime, di affiancare al lavoro di delivery un lavoro continuo di mantenimento documentale e di gestione della catena di fornitura, di formare al proprio interno le figure ibride che ho descritto nel pezzo precedente di questa serie, avranno fra cinque anni una posizione competitiva difficile da erodere. Le software house che continueranno a firmare contratti tradizionali nella speranza che il quadro regolatorio non si applichi davvero, o che la giurisprudenza nazionale lo addolcisca, si troveranno esposte e dovranno colmare il ritardo a costi molto più alti di quelli sostenibili oggi. È una di quelle situazioni in cui la decisione di non decidere è la più costosa di tutte, perché il tempo lavora contro chi non si muove, e perché ogni contratto firmato oggi sotto il modello vecchio è una passività che si rivelerà fra qualche anno, quando i casi che la PLD ha disegnato come scenario standard cominceranno a comparire nelle sezioni cronaca dei giornali specializzati.
La centralità che muore
Mettendo insieme i quattro pezzi di questa serie, l’argomento generale che sto cercando di costruire è il seguente. Il software, come oggetto industriale e come oggetto giuridico, sta cambiando natura sotto i nostri occhi, e la cultura ingegneristica e commerciale del settore non si sta adeguando con la velocità che il momento richiede. Il primo pezzo, Cruft, non patina, argomentava che il software non sa invecchiare come gli oggetti materiali. Quello successivo, Il debito di specifica, spostava l’attenzione sul fatto che la specifica scritta è diventata l’asset giuridicamente rilevante del prodotto e che la nostra industria non ha gli strumenti per mantenerla viva. Poi è arrivato L’ascesa del compliance engineer, dedicato alla figura professionale ibrida che sta emergendo per presidiare il vuoto fra ingegneria e regolazione. In questo quarto pezzo l’argomento si sposta dal piano del prodotto e del lavoro al piano della relazione fra organizzazioni, e la tesi è che il contratto di fornitura, lo strumento giuridico classico di quella relazione, sta diventando uno strumento fra altri di una relazione più ampia e più strutturata, che il diritto contrattuale tradizionale può solo parzialmente disciplinare.
Il contratto di fornitura software non è morto, e niente di quello che ho scritto va letto come una previsione della sua scomparsa. Quello che è morto è la sua centralità, l’idea che la relazione fra fornitore e cliente possa essere descritta esaurientemente da un documento bilaterale negoziato all’inizio del rapporto e aggiornato ai rinnovi. La relazione contemporanea è una relazione multilaterale, regolatoriamente carica, dinamicamente esposta a soggetti terzi che il contratto non vincola, e attraversata da obblighi documentali continui che il contratto può solo sintetizzare. Pensare che basti scrivere meglio le clausole è una nostalgia comprensibile e umana, ed è anche il modo più rapido per accumulare esposizione mentre si crede di essere protetti. Le clausole servono ancora, anzi servono più di prima, ma servono come elementi di un dispositivo più ampio che le contiene e le supera.
Il contratto, così come lo abbiamo conosciuto, è diventato l’inganno gentile che permette ai fornitori di software di credere di sapere a cosa si stanno esponendo. I contratti tradizionali continueranno a essere firmati per qualche anno ancora, perché il mercato si muove più lentamente del diritto, e perché il modello vecchio è familiare e i nuovi modelli sono ancora in formazione. Ma chi continua a firmare contratti tradizionali nei prossimi cinque anni sta firmando, oltre al contratto, una scommessa silenziosa sul fatto che le cose non cambieranno davvero. È una scommessa che la mia generazione di chi fa software in Europa probabilmente perderà, perché le cose stanno già cambiando, e quello che oggi sembra un eccesso di prudenza dei pochi che si stanno muovendo si rivelerà fra qualche anno il minimo prudenziale che era richiesto fin dal principio.
Cosa ti porti a casa
L’Articolo 15 della PLD revisionata è la chiave di volta del nuovo regime: la responsabilità verso il danneggiato non può essere limitata né esclusa da clausole contrattuali. Quello che sembrava margine di manovra contrattuale diventa zona di indisponibilità giuridica.
Quattro presupposti impliciti del modello contrattuale tradizionale sono caduti nello stesso decennio: l’esposizione del fornitore esauribile nei rapporti col cliente, il software come oggetto delimitato nella consegna, la catena di fornitura come somma di rapporti bilaterali, la stabilità regolatoria che permetteva contratti pluriennali sotto un quadro fisso.
Quattro fenomeni che il contratto tradizionale non sa indirizzare: responsabilità solidale dei componenti critici, disclosure documentale al giudice (con presunzione di difetto in caso di mancata esibizione), presunzioni di difettosità per sistemi tecnicamente complessi, accountability del modificatore sostanziale che frantuma la struttura bilaterale.
I settori che vivono questo regime da decenni — aviazione civile, dispositivi medici, automotive — hanno avuto trent’anni per costruire le pratiche. Il software generalista ha cinque o sette anni per fare la stessa cosa, mentre la maggior parte dei competitor ragiona ancora con il modello vecchio.
Il contratto non è morto: è morta la sua centralità. La relazione contemporanea è multilaterale, regolatoriamente carica, esposta a soggetti terzi che il contratto non vincola, attraversata da obblighi documentali continui. Le clausole servono ancora — anzi, più di prima — ma come elementi di un dispositivo più ampio che le contiene e le supera.
Domande e risposte
Perché il contratto di fornitura software ha «smesso di essere centrale»?
Perché il regime giuridico che si sta consolidando in Europa fra il 2024 e il 2027 introduce un livello di responsabilità che opera al di fuori del contratto e che il contratto può solo parzialmente disciplinare. La PLD revisionata, il CRA, l’AI Act, NIS2 e DORA convergono nel rendere il fornitore esposto verso il danneggiato finale a prescindere dalle clausole pattuite con il cliente intermediario, e nell’imporre obblighi documentali, di sicurezza, di gestione della catena che attraversano la contrattazione bilaterale. Le clausole continuano a regolare la rivalsa fra le parti firmatarie, ma non spostano la responsabilità verso terzi. Il contratto non è morto: è morta la sua centralità.
Cosa cambia con l'Articolo 15 della PLD revisionata?
L’Articolo 15, intitolato «Esclusione o limitazione della responsabilità», impone agli Stati membri di assicurare che la responsabilità dell’operatore economico verso il danneggiato non possa essere limitata o esclusa né da clausole contrattuali né da disposizioni di diritto nazionale. È un articolo breve e tecnico, ma è la chiave di volta dell’intero impianto: trasforma quello che sembrava un margine di manovra contrattuale in una zona di indisponibilità giuridica. Il fornitore che si protegge con clausole di limitazione del proprio massimale o di esclusione dei danni indiretti scopre che quelle clausole regolano la rivalsa col cliente firmatario, non l’esposizione verso il terzo danneggiato.
Quali sono i quattro fenomeni operativi che il contratto tradizionale non sa indirizzare?
Primo, la responsabilità solidale dei fornitori di componenti critici: il fornitore principale risponde dei difetti dei sub-fornitori anche quando questi sono inadempienti o irraggiungibili. Secondo, gli obblighi di disclosure documentale al giudice, con presunzione di difetto in caso di mancata esibizione (Articolo 10 PLD). Terzo, le presunzioni di difettosità per sistemi tecnicamente complessi, che si attivano quasi automaticamente per software che integrano componenti AI. Quarto, l’accountability del modificatore sostanziale: il cliente o l’integratore intermedio che modifica un prodotto può diventare lui stesso produttore responsabile, frantumando la struttura del contratto bilaterale.
Quali sono i settori che già operano sotto un regime simile, e cosa possiamo imparare?
Aviazione civile, dispositivi medici e automotive vivono sotto regimi di responsabilità del prodotto stretti da decenni e hanno sviluppato pratiche contrattuali utili. I contratti aeronautici incorporano obblighi di tracciabilità documentale e certificazione di parte terza. Il dispositivo medico prevede accordi quadro di qualità che vanno oltre il singolo contratto commerciale. L’automotive, soprattutto dopo ISO 26262, incorpora clausole di responsabilità lungo la catena. La differenza è che questi settori hanno avuto trent’anni per costruire le pratiche; il software generalista ha cinque o sette anni per fare la stessa cosa.
Quali sono le cinque dimensioni operative della trasformazione contrattuale?
Primo, dal contratto come documento ai documenti contrattuali come ecosistema correlato (contratto base, SLA, accordi di sicurezza, accordi di qualità, accordi di trattamento dei dati ex Articolo 28 GDPR, gestione coordinata delle vulnerabilità, disclosure della catena). Secondo, ridimensionamento delle clausole di limitazione di responsabilità, che restano valide fra le parti ma non producono effetti verso i terzi (e implicano una revisione delle polizze assicurative). Terzo, riscrittura della subfornitura da approvazione iniziale a procedura continua di valutazione e disclosure. Quarto, clausole operative di gestione vulnerabilità e incidenti, costruite quasi come mini-runbook contrattuali. Quinto, gestione del ciclo di vita del prodotto e dell’end of support, che eccedono la durata della relazione contrattuale.
C'è una connessione fra questo pezzo e i tre saggi precedenti della serie?
Sì, e questo è il quarto e ultimo della serie. Cruft, non patina argomenta che il software non sa invecchiare. Il debito di specifica sposta l’attenzione sul fatto che la specifica scritta è diventata l’asset giuridicamente rilevante e che mancano gli strumenti per mantenerla viva. L’ascesa del compliance engineer descrive la figura ibrida che presidia il vuoto fra ingegneria e regolazione. Questo pezzo sposta l’argomento al piano della relazione fra organizzazioni: il contratto, lo strumento giuridico classico di quella relazione, sta diventando uno strumento fra altri di un dispositivo più ampio. La tesi unificante è che il software, come oggetto industriale e come oggetto giuridico, sta cambiando natura sotto i nostri occhi, e la cultura ingegneristica e commerciale del settore non si sta adeguando alla velocità che il momento richiede.
L'autore
