Il Disclaimer muore.

Essere tornato a scrivere codice – questa volta per alcune applicazioni mission-critical in ambito sovereign-UE – mi ha costretto a sottopormi a diversi corsi di awareness riguardanti le novità europee in materia di software. La nuova direttiva europea in arrivo è destinata a cambiare radicalmente il panorama e, a mio avviso, rischia di creare l'equivalente del Muro di Berlino, ma questa volta sull'Atlantico.

​

Mi riferisco a clausole quali quelle relative alla Product Liability Directive (PLD), che entrerà in vigore il 9 dicembre 2026 e che include esplicitamente il software – sia esso embedded, standalone o erogato come servizio – nella definizione di "prodotto" soggetto a regime di responsabilità oggettiva. Si tratta di un cambiamento paradigmatico: il software, i firmware, le applicazioni, i sistemi di intelligenza artificiale e persino i file digitali per la produzione manifatturiera sono ora sottoposti allo stesso regime di strict liability applicato tradizionalmente ai beni fisici.

​Mi riferisco alle clausole di questo tipo:

Che trovate spesso nel software. Il corso che sto facendo si riferisce alla situazione tedesca, ovviamente, ma riguarda tutta Europa.

La Germania sta implementando la nuova Direttiva UE sulla Responsabilità per Prodotti Difettosi (Product Liability Directive 2024/2853), che entrerà in vigore a dicembre 2026. Per la prima volta, il software viene equiparato ai prodotti fisici ai fini della responsabilità civile.

Cosa prevede la normativa

La direttiva introduce una responsabilità oggettiva per i produttori di software. Il consumatore che subisce un danno deve solo dimostrare il difetto del prodotto e il nesso causale con il danno, senza dover provare colpa o negligenza del produttore. La definizione di "prodotto" è molto ampia e include software standalone, in cloud, firmware, app, sistemi SaaS e software integrato in dispositivi come automobili o elettrodomestici smart.

I danni risarcibili comprendono danni materiali, ai dati digitali (come cancellazione o corruzione di file), fisici e persino lesioni psicologiche certificate.

Non sono ammesse esclusioni di responsabilità tramite licenze o disclaimer.

Termini di responsabilità

Il termine massimo di responsabilità è di 10 anni dall'immissione del prodotto sul mercato. Tuttavia, per i danni alla persona che si manifestano tardivamente, la direttiva prevede un limite esteso fino a 25 anni.

IMPORTANTE: Open source e responsabilità a catena

Il software open source puro (non profit) resta escluso dalla responsabilità. Tuttavia, la responsabilità si riattiva se il software open source viene integrato in prodotti commerciali o monetizzato in qualsiasi forma, compresa la raccolta dati personali. Redhat , sei avvisata. Chi integra componenti o librerie open source in un prodotto commerciale risponde dei danni che queste possono causare, senza possibilità di rivalersi sullo sviluppatore originario se questi è rimasto nell'ambito non profit.

Implementazione in Germania

Il Ministero Federale della Giustizia tedesco ha presentato una bozza di legge di implementazione l'11 settembre 2025, con l'obiettivo di recepire completamente la direttiva entro il 9 dicembre 2026. La nuova legge si applicherà a tutti i prodotti immessi sul mercato dopo quella data. La Germania non ha definito esplicitamente il termine "software" per rimanere aperta ai futuri sviluppi tecnologici.

Impatti per l'industria

Questo rappresenta un cambio di paradigma completo per l'ecosistema europeo del software. I produttori dovranno ripensare le policy di sicurezza e gestione del rischio in modo radicale. La mancata conformità a normative UE come NIS 2 o GDPR costituisce indizio di difettosità del prodotto, rendendo ancora più critica la compliance.

E in Italia?

La direttiva dovrà essere recepita in Italia entro il 9 dicembre 2026, stesso termine previsto per tutti gli Stati membri dell'Unione Europea. La Direttiva UE 2024/2853 è entrata formalmente in vigore l'8 dicembre 2024, dando agli Stati membri esattamente due anni per implementarla nella legislazione nazionale.

​Applicazione della normativa

La nuova normativa si applicherà a tutti i prodotti (incluso il software) immessi sul mercato o messi in servizio dopo il 9 dicembre 2026. I prodotti già sul mercato prima di quella data continueranno a essere regolati dalla vecchia Direttiva sulla Responsabilità per Prodotti Difettosi del 1985 (85/374/EEC).

​Normativa italiana attuale

Attualmente in Italia la responsabilità per prodotti difettosi è regolata dal Codice del Consumo, che viene interpretato congiuntamente alle disposizioni del Codice Civile sulla responsabilità extracontrattuale e per attività pericolose. Questa normativa dovrà essere aggiornata per recepire le nuove disposizioni europee, che non permettono agli Stati membri di introdurre disposizioni nazionali diverse da quelle previste dalla Direttiva.​

Novità per l'Italia

La nuova direttiva, mi dicono, viene accolta positivamente in Italia perché offre una protezione più ampia ai consumatori e un quadro giuridico aggiornato per i prodotti digitali. Tra le novità principali c'è il riconoscimento dei danni causati da software, inclusi quelli derivanti da aggiornamenti e la perdita di dati. La responsabilità si estende a tutti i soggetti che concorrono alla commercializzazione del prodotto: non solo il fabbricante, ma anche distributori, fornitori e piattaforme online.​

Le aziende italiane, come quelle degli altri paesi UE, dovranno prepararsi effettuando nuove valutazioni del rischio, rivedendo i sistemi di conformità, i meccanismi di richiamo dei prodotti, la copertura assicurativa e gli accordi con distributori terzi.

Le conseguenze

Sulle conseguenze è difficile fare previsioni. La direttiva copre molti aspetti di molti prodotti, non solo software.

Per quanto riguarda il software, si tratta in pratica di una dichiarazione di indipendenza dall'industria americana, che ha il disclaimer of warranty come paradigma centrale. Non dico che il software negli USA sia peggiore o migliore, ma il fatto di essere disegnato col disclaimer in mente significa diverse cose:

• Si butta fuori il software appena è appena passabile, poi lo si aggiorna e lo si patcha per correggere i problemi. Questo consente di "uscire per primi" e battere la concorrenza, privilegiando metodi "agili" per la costruzione del software: il prodotto, di fatto, è in divenire.
• Le valutazioni dei contratti di garanzia, come quelli richiesti dalle amministrazioni pubbliche, costruiscono il prezzo finale tenendo conto delle liability: quanto potresti pagare se il software facesse danni. Il guaio è che prima la risposta era "quasi niente". Sono pochi i contratti di manutenzione o assistenza che prevedano delle liability; in genere sono focalizzati sullo SLA e sull'ETA della soluzione.
• L'equilibrio tra system integrator e produttori di software tiene conto della (s)proporzione delle responsabilità tra chi produce il codice e chi lo installa o lo integra. Sinora conveniva al produttore: Microsoft, se si ferma un server Exchange per un baco, non paga nulla. Se un system integrator installa il server e ha un contratto di manutenzione, potrebbe perdere soldi per il fermo. Adesso li perderanno entrambi, anzi il system integrator potrebbe fare causa a Microsoft.

In che senso è una dichiarazione di indipendenza? Perché di fatto cambia la liability a seconda che il prodotto venga venduto in Europa o prodotto negli USA, dove i disclaimer sono un'arte.

​Ed è pesante, perché cambia un paradigma di base sul quale si è basato molto del pionierismo e, a volte, dell'innovazione che hanno caratterizzato la produzione di software fino ad ora.

Il motto "move fast, break things" può funzionare e sembrare attraente, a meno che... a meno che non diventi "move fast, break things, get sued, pay shitload of money". Detto così, perde molto del suo fascino.

È molto interessante, invece, lo status privilegiato dell'Open Source. Ed è per questo che credo si tratti di un cambiamento strategico. Perché l'UE, contemporaneamente, fa questo:

• Vara e finanzia programmi di sovranità digitale europei, quasi sempre basati su software esistenti e open source.
• Sgravia dai rischi di ritorsioni legali i software sui quali si baseranno le future infrastrutture digitali "sovrane" europee.
• Punisce i modelli proprietari, che guarda caso sono caratteristici della dipendenza dall'industria americana. Da ora in poi, cioè, il vendor lock-in si paga.

Questo ha l'aspetto di una strategia, e non è una strategia amichevole verso le industrie americane.

Ma si va oltre.

Il nuovo regolamento, infatti, va oltre.

Mi riferisco ai criteri di sovranità digitale che l'UE sta progressivamente definendo attraverso un framework normativo complesso e interconnesso.

Residenza e localizzazione dei dati: Il GDPR (Regolamento Generale sulla Protezione dei Dati) costituisce l'ancoraggio giuridico della sovranità digitale europea, affermando la giurisdizione sui dati personali dei residenti UE indipendentemente da dove vengano processati. La sentenza Schrems II della Corte di Giustizia UE ha rafforzato questo principio, stabilendo che i trasferimenti di dati verso paesi terzi richiedono un livello di protezione "essenzialmente equivalente" a quello garantito nell'UE. Quando questo non è possibile, le autorità di supervisione devono sospendere o vietare i trasferimenti. Settori come finanza e sanità devono già rispettare requisiti stringenti di data residency all'interno dei confini UE.

Controllo dell'infrastruttura critica: Il Digital Operational Resilience Act (DORA) impone alle istituzioni finanziarie e ai loro fornitori ICT critici, inclusi i servizi cloud, di mantenere continuità operativa, trasparenza dei dati e conformità legale. Il framework EUCS (EU Cybersecurity Certification Scheme for Cloud Services), in fase di sviluzione dal 2020, mira a certificare la cybersecurity dei servizi cloud includendo requisiti di sovranità. Nel settembre 2024, il Consiglio dell'Unione Europea ha esplicitamente sollecitato la Commissione e l'ENISA ad accelerare l'integrazione del Cloud Sovereignty Framework (CSF) nell'EUCS.

Protezione da ingiunzioni extraterritoriali: La sentenza Schrems II stabilisce chiaramente che se le leggi del paese terzo impongono al destinatario dei dati obblighi contrari alle clausole contrattuali standard (SCC) e quindi capaci di compromettere le garanzie contrattuali, il trasferimento deve essere sospeso o terminato. Il ricevente dei dati è obbligato a informare l'esportatore di qualsiasi impedimento alla conformità, e se le leggi locali di sorveglianza impediscono l'allineamento con il GDPR, l'esportatore deve interrompere il trasferimento e terminare il contratto.

Minimizzazione delle dipendenze: Il Digital Markets Act e l'AI Act forniscono alle autorità maggiore supervisione sulle piattaforme digitali e sui sistemi di intelligenza artificiale, proteggendo i diritti fondamentali e regolando le applicazioni AI per garantire la conformità. I criteri di sovranità (SEAL + Score) stanno diventando punti di riferimento obbligatori negli appalti pubblici UE per servizi cloud e digitali, con l'EUCS come meccanismo di verifica per la conformità.

Temo che il 2026 sarà l'anno in cui volano gli stracci. L'UE sta lavorando in maniera silenziosa: anziché dire "adesso non usiamo più software americano per le questioni mission-critical, nella PA e nelle industrie strategiche", sta emanando uno sciame di piccoli regolamenti che, uno ad uno, sono giustificabili e persino sacrosanti.

Ma se li metti tutti insieme, presto per l'industria IT extra-UE sarà difficilissimo vendere prodotti software in Europa.

Anche qui, fare previsioni è difficile. Il problema è che le aziende americane vogliono guadagnarci, come è ovvio. Se aumentiamo i rischi di liability, non faranno altro che scaricare il costo sui clienti. Le licenze di Windows a 25 dollari, per dire, sono possibili solo perché, per un baco di Windows, non potete denunciare Microsoft per aver fermato il vostro studio. Non è difficile prevedere un aumento di prezzi, che vada a coprire il rischio legale.

Ma questo non fa altro che rendere più competitivo l'Open Source, non perché ne migliori le prestazioni o la facilità d'uso, ma semplicemente perché il concorrente proprietario dovrà costare molto di più.

Altro che 120 milioni di euro di multa a X. Qui siamo a regolamenti che di fatto pesano quanto un dazio. Regolamenti come quelli del cloud sovrano che rendono rischioso, per le aziende grandi europee, stare nei cloud come Azure o AWS, anche se sono situati in Europa.​

È difficile pensare che gli USA, specialmente oggi che sono sotto l'influenza chiara ed esplicita dei grandi OTT, possano lasciarlo passare, se 120 milioni di multa hanno irritato Trump come hanno fatto. Finora, per come sono fatti questi regolamenti, gli USA non si sono ancora resi conto di cosa significhino, perché da soli sono già preoccupanti ma giustificabili.

Ma se li mettiamo tutti insieme, diventano un problema enorme per le aziende extra-UE che vogliano vendere software e hardware IT in Europa. E sappiamo benissimo di chi stiamo parlando.

Cosa posso presumere?

Che inizialmente ci sarà un aumento dei prezzi verso clienti business e/o enterprise, ed enti pubblici. Da quel momento, molti decideranno di adottare l'OSS, ma non quello di Red Hat che è considerato come un prodotto di IBM, bensì quello mantenuto da community.

Poi aumenteranno i prezzi dei cloud "non sovereign" in UE. E questo porterà clienti a quelli europei.

Alla fine, prima o poi gli USA noteranno che stanno perdendo un sacco di soldi. E sappiamo che, come dire, sono "abbastanza sensibili" a queste cose.

Non so onestamente per quale motivo seguire una traiettoria di scontro così marcata. Quando queste normative "coaguleranno" voleranno davvero gli stracci: un conto è impedire la vendita di pollo al cloro, un conto è agire sul software e sui prodotti IT, anche hardware, e sui cloud.

Ma la cosa certa è che il 2026 sarà un anno critico. Anche perché l'UE non ha uno stile di chi lancia gridi di battaglia. Questo scontro avviene sotto i radar, molto rasoterra, a basso profilo.

Ma questi nuovi regolamenti urlano molto, molto forte.