Software e AI difettosi: cosa cambia dal 9 dicembre 2026 e chi paga i danni

Un aggiornamento software introduce una vulnerabilità che permette a un aggressore di compromettere un dispositivo. Un sistema AI modifica autonomamente il proprio comportamento, causando un incidente. Un’applicazione difettosa danneggia irreversibilmente i file personali dell’utente. Chi risponde delle conseguenze? Di chi è la responsabilità?

Dal 9 dicembre 2026 il quadro europeo della responsabilità per i prodotti difettosi cambia in modo decisivo: la direttiva (UE) 2024/2853 riconosce infatti il software come prodotto, includendo applicazioni, sistemi operativi, firmware e sistemi di intelligenza artificiale.

Sgombriamo subito il campo dagli equivoci e dai facili allarmismi: la presenza di bug – è fisiologico che un software li contenga (lo sanno bene gli sviluppatori sempre più sottoposti al pressing dell’AI che ricerca e trova imperfezioni o falle di sicurezza sempre più di frequente) – non comporterà subito l’obbligo di un risarcimento. Sarebbe una visione miope del problema.

Le novità in arrivo riguardano invece le modalità con cui si individuano le responsabilità, si valutano i difetti di sicurezza e si dimostra il collegamento tra un malfunzionamento e un danno concreto.

Perché il 9 dicembre 2026 è una data importante per il software

La direttiva, entrata in vigore l’8 dicembre 2024, sostituisce la precedente disciplina europea del 1985.

Gli Stati membri devono appunto recepirla entro il 9 dicembre 2026, mentre le nuove regole riguardano i prodotti immessi sul mercato o “portati in funzione” a partire da tale scadenza. Non è quindi prevista alcuna responsabilità retroattiva generalizzata per tutti i programmi già distribuiti.

In Italia il recepimento è stato avviato attraverso la legge 17 marzo 2026, n. 36. Il Governo ha predisposto lo schema di decreto legislativo n. 434, che interviene sugli articoli 114-127 del Codice del consumo. Al 6 novembre 2026 il testo definitivo non risulta ancora pubblicato: le disposizioni nazionali devono quindi essere verificate nella loro versione conclusiva.

La riforma introduce comunque un principio cardine: la sicurezza di un prodotto digitale non può essere “cristallizzata” al momento in cui il software viene commercializzato. Vi ricordate la classica clausola in cui si riportava che il software è messo a disposizione dell’utente “as is” ovvero “così com’è“: ecco, dal prossimo 9 dicembre ci sarà da discutere.

Anche software cloud e intelligenza artificiale possono essere prodotti difettosi

L’articolo 4 della direttiva estende esplicitamente la definizione di prodotto al software, indipendentemente dalle modalità di distribuzione.

Un’applicazione installata sul PC, un firmware integrato in un router o un programma utilizzato attraverso un servizio cloud possono rientrare nella disciplina. Il considerando 13 cita espressamente anche il modello Software-as-a-Service (SaaS).

Per i sistemi AI conta soprattutto il comportamento effettivo del software: un algoritmo che controlla un dispositivo fisico potrebbe generare condizioni pericolose anche dopo il rilascio, per effetto dell’apprendimento automatico o di modifiche introdotte dal produttore.

La Commissione europea chiarisce che la responsabilità può riguardare difetti manifestatisi successivamente alla distribuzione, quando derivano da elementi rimasti sotto il controllo del fabbricante.

Sono comunque previste delle esclusioni: non tutti i servizi digitali costituiscono automaticamente prodotti o componenti rilevanti; il semplice contenuto informativo di un file, come un ebook, non diventa un prodotto difettoso soltanto perché contiene informazioni errate.

Aggiornamenti mancanti e vulnerabilità: è la fine del concetto di End of Life (EoL)?

Secondo quanto disposto all’articolo 11, il produttore non può escludere la propria responsabilità semplicemente sostenendo che il difetto sia comparso dopo l’immissione sul mercato, quando deriva da software, aggiornamenti o servizi correlati rimasti sotto il suo controllo.

La direttiva contempla espressamente anche la mancata distribuzione di aggiornamenti necessari per mantenere la sicurezza.

Immaginiamo un dispositivo connesso a Internet: il produttore conosce una vulnerabilità critica, mantiene il controllo degli aggiornamenti ma non interviene. Se il difetto di sicurezza provoca un danno risarcibile, l’assenza di una correzione potrebbe assumere rilevanza nella valutazione della responsabilità.

La nuova direttiva europea non obbliga gli sviluppatori ad aggiornare i propri programmi per sempre e non elimina il concetto di End of Life (EoL), ossia la fine del supporto ufficiale di un prodotto, che sia un hardware o un software. Lo chiarisce espressamente il considerando 51 della direttiva 2024/2853.

Cosa succede quando un software raggiunge la fine del supporto? Il produttore può interrompere gli aggiornamenti, purché rispetti gli obblighi di legge applicabili.

Un produttore può certamente stabilire che un programma riceverà aggiornamenti di sicurezza fino a una determinata data. Una volta terminato il periodo di supporto, non è automaticamente obbligato a correggere tutte le vulnerabilità che emergeranno in futuro.

Facciamo un esempio: un router viene commercializzato con un periodo di supporto di 7 anni; trascorso tale periodo, il produttore interrompe gli aggiornamenti. Se dopo altri 2 anni emerge una nuova vulnerabilità, la direttiva europea non impone di sviluppare e distribuire una correzione.

Diverso è il caso di un aggiornamento difettoso distribuito durante il periodo di supporto: se quel difetto provoca un danno, la successiva scadenza del supporto non esclude automaticamente la responsabilità del produttore.

Un riferimento importante arriva dal Cyber Resilience Act: per i prodotti che rientrano nel suo ambito, il periodo di gestione delle vulnerabilità dovrà generalmente durare almeno 5 anni, salvo prodotti destinati a un utilizzo più breve. La durata dovrà essere maggiore quando la vita utile ragionevolmente prevista del prodotto lo richiede. Tali obblighi generali diventeranno applicabili dall’11 dicembre 2027.

Quali danni saranno effettivamente risarcibili?

L’articolo 6 identifica specifiche categorie di danni:

• Morte o lesioni personali, comprese le compromissioni della salute psicologica riconosciute dal punto di vista medico.
• Danneggiamento o distruzione di beni, con le esclusioni previste dalla direttiva.
• Distruzione o corruzione di dati non utilizzati per finalità professionali.

L’ultima categoria rappresenta una novità particolarmente significativa per il settore informatico.

Pensiamo a un software di gestione delle fotografie che, per un difetto, cancelli irreversibilmente un archivio personale. Il danno ai dati potrebbe rientrare nella disciplina, purché ricorrano gli altri presupposti della responsabilità.

Diversa la situazione di un gestionale aziendale che perda fatture e documenti commerciali: i dati utilizzati a fini professionali non beneficiano della specifica tutela introdotta dall’articolo 6, pur potendo trovare protezione attraverso altre norme.

Una risposta sbagliata di un chatbot, un crash applicativo o un servizio temporaneamente indisponibile non danno diritto a un risarcimento ai sensi della nuova direttiva. Il legislatore presuppone la presenza di un difetto di sicurezza, un danno contemplato dalla norma e un rapporto causale tra i due.

Come dimostrare che il software ha provocato il danno?

Come può un utente dimostrare che un malfunzionamento dipende da una specifica versione di un programma, da un modello AI oppure da un componente software integrato in un dispositivo? Gli articoli 9 e 10 introducono meccanismi destinati ad agevolare l’accertamento.

Il giudice può ordinare la produzione di elementi di prova pertinenti e necessari, nel rispetto della proporzionalità e della protezione delle informazioni riservate.

In determinate circostanze, inoltre, il difetto o il nesso causale possono essere presunti: la direttiva considera infatti anche le difficoltà probatorie derivanti dalla particolare complessità tecnica o scientifica del prodotto. Non si tratta di un’inversione dell’onere della prova: il danneggiato deve comunque fornire gli elementi richiesti dalla normativa e le presunzioni possono essere contestate.

Per gli sviluppatori diventa importante conservare documentazione tecnica attendibile, risultati dei test, versioni distribuite e informazioni sugli aggiornamenti.

Open source: gli sviluppatori sono responsabili?

L’articolo 2 esclude il software libero e open source sviluppato o fornito al di fuori di un’attività commerciale.

Il volontario che pubblica gratuitamente una libreria open source non diventa responsabile secondo la nuova disciplina per ogni problema provocato dal codice che pubblica e condivide. L’esclusione non si estende però indistintamente a qualsiasi prodotto contenente componenti open source.

Se un’azienda integra una libreria in un dispositivo commercializzato, la natura aperta del codice non esclude di per sé la responsabilità del fabbricante del prodotto finale.

La direttiva prevede inoltre disposizioni specifiche sui rapporti tra produttori di componenti software e fabbricanti che li integrano.

Cosa devono fare sviluppatori e aziende?

La riforma rende ancora più importante l’esigenza di tenere costantemente traccia della storia tecnica di un prodotto.

Per un produttore software significa documentare le versioni rilasciate, le dipendenze utilizzate, le vulnerabilità individuate, le decisioni sugli aggiornamenti e i risultati delle verifiche di sicurezza.

Per chi sviluppa sistemi AI è particolarmente utile conservare anche informazioni sulle modifiche dei modelli, sui test di affidabilità e sui controlli introdotti per impedire comportamenti pericolosi.

La necessità di documentare non equivale, com’è ovvio, a un obbligo generalizzato di pubblicare codice sorgente, pesi dei modelli o segreti industriali.

Quanto tempo c’è per chiedere un risarcimento: 3, 10 o 25 anni?

La direttiva stabilisce anche entro quanto tempo un utente può chiedere il risarcimento per i danni provocati da un prodotto difettoso. L’articolo 16 prevede un termine di prescrizione di 3 anni, che inizia a decorrere quando il danneggiato conosce, o avrebbe ragionevolmente dovuto conoscere, tre elementi: il danno subito, il difetto del prodotto e l’identità del soggetto che può esserne considerato responsabile.

Esiste però un secondo limite, previsto dall’articolo 17: il diritto al risarcimento si estingue generalmente dopo 10 anni dalla data in cui il prodotto difettoso è stato immesso sul mercato o messo in servizio, salvo che nel frattempo sia stata avviata un’azione giudiziaria. In caso di modifiche sostanziali al prodotto, il termine decorre dalla sua nuova immissione sul mercato o messa in servizio.

Il limite massimo sale a 25 anni quando una lesione personale si manifesta così tardi da impedire al danneggiato di agire entro i primi 10 anni. L’estensione non riguarda genericamente tutti i difetti software o la perdita di dati, ma le specifiche situazioni di danni alla persona caratterizzati da una lunga latenza.

Come avevamo già spiegato nell’approfondimento dedicato alla responsabilità degli sviluppatori per i bug del software, la nuova disciplina europea impone di considerare con maggiore attenzione anche le conseguenze giuridiche dei difetti informatici.

In conclusione, il cambiamento più importante non consiste nel rendere gli sviluppatori responsabili di qualsiasi errore. Consiste nel riconoscere che software e AI possono compromettere la sicurezza delle persone e dei loro beni, proprio come un dispositivo fisico difettoso.