Prodotti difettosi e software: quando l’aggiornamento diventa il difetto

Indice

1. Il caso
2. Che cosa è il prodotto e chi lo ha fabbricato
3. Il difetto nato dopo la vendita
4. Il ticket chiuso 2 settimane prima
5. Le prove che verranno chieste
6. I contratti non spostano la responsabilità verso il danneggiato
7. I termini e il tempo delle evidenze
8. Che cosa verifica l’Internal Audit e che cosa arriva al vertice
9. Che cosa fare ed entro quando

Il Consiglio dei ministri, nella seduta n. 195 del 28 ottobre 2026, ha approvato in esame definitivo il decreto legislativo di attuazione della direttiva (UE) 2024/2853 del Parlamento europeo e del Consiglio, del 23 ottobre 2024, sulla responsabilità per danno da prodotti difettosi. Il decreto interviene sul Codice del consumo e sostituisce il regime che risaliva alla direttiva 85/374/CEE. Al momento in cui scriviamo non risulta pubblicato in Gazzetta Ufficiale ma la direttiva è nota da 2 anni e il suo calendario è fissato: l’articolo 2, paragrafo 1, nel testo rettificato con la rettifica pubblicata il 7 maggio 2026, si applica ai prodotti immessi sul mercato o messi in servizio dopo l’8 dicembre 2026. L’articolo 22 fissa al 9 dicembre 2026 il termine di recepimento e l’articolo 21 abroga la direttiva 85/374/CEE dalla stessa data, lasciandola applicabile ai prodotti immessi sul mercato o messi in servizio prima. La data dell’esempio del prossimo paragrafo, non è casuale: la macchina entra sul mercato dopo l’8 dicembre 2026 e ricade quindi nel nuovo regime, mentre un prodotto identico venduto un mese prima resterebbe soggetto alla direttiva 85/374/CEE anche se l’incidente avvenisse nel 2027.

Il caso

Una pressa piegatrice viene immessa sul mercato nel gennaio 2027 da un fabbricante italiano. Il controllore di sicurezza della macchina monta un firmware sviluppato da un fornitore specializzato, con cui il fabbricante ha un contratto di fornitura e manutenzione. La macchina è collegata a un servizio cloud, gestito dal fabbricante, che raccoglie i dati di funzionamento e distribuisce gli aggiornamenti. Nel marzo 2027 il fornitore del firmware segnala una vulnerabilità nel modulo di comunicazione e rilascia una correzione. Il fabbricante la sottopone ai test funzionali previsti dalla propria procedura, la approva e la distribuisce a tutte le macchine installate. Nell’aprile 2027, in un’officina che ha acquistato la macchina, la funzione di arresto comandata dalla barriera fotoelettrica interviene con qualche decina di millisecondi di ritardo e un operatore riporta una lesione alla mano. L’analisi successiva mostra che la correzione ha modificato la priorità di un processo del controllore e che il ritardo compare soltanto in combinazione con una specifica configurazione dell’hardware.

Che cosa è il prodotto e chi lo ha fabbricato

La prima domanda è apparentemente banale: qual è il prodotto. L’articolo 4, punto 1, della direttiva definisce prodotto qualsiasi bene mobile, anche se integrato o interconnesso con un altro bene mobile o con un bene immobile, e comprende espressamente l’elettricità, i file per la fabbricazione digitale, le materie prime e il software. Nel caso la pressa è il prodotto, il firmware del controllore è un componente e il servizio cloud va qualificato a parte: l’articolo 4, punto 3, definisce servizio correlato il servizio digitale integrato in un prodotto o interconnesso con esso in modo tale che la sua assenza impedisce al prodotto di svolgere una o più funzioni. Se la pressa continua a lavorare anche senza connessione, il servizio di raccolta dati e distribuzione degli aggiornamenti potrebbe non rientrare nella definizione. Se invece una funzione di sicurezza dipende dalla connessione, la qualificazione cambia. La risposta non viene dal contratto di assistenza o dal nome commerciale del servizio, ma dalla relazione funzionale con il prodotto.

La seconda domanda è chi risponde. L’articolo 8, paragrafo 1, lettera a), individua il fabbricante del prodotto difettoso e la lettera b) il fabbricante di un componente difettoso, se il componente è stato integrato nel prodotto o interconnesso con esso sotto il controllo del fabbricante e ne ha causato il carattere difettoso. Il fornitore del firmware non è quindi soltanto una controparte contrattuale del fabbricante della pressa: è un operatore economico che può essere chiamato a rispondere direttamente verso il danneggiato. L’articolo 8, paragrafo 2, aggiunge che chi modifica in maniera sostanziale un prodotto al di fuori del controllo del fabbricante è considerato fabbricante del prodotto modificato. Nel caso l’aggiornamento è stato distribuito dal fabbricante stesso e la disposizione non entra in gioco, ma sarebbe diverso se un integratore avesse riprogrammato il controllore per inserire la pressa in una linea automatica. Importatori, rappresentanti autorizzati e fornitori di servizi di logistica rispondono alle condizioni previste dall’articolo 8 e il distributore risponde soltanto se, richiesto dal danneggiato, non indica entro 1 mese l’operatore economico responsabile. Non ogni soggetto della filiera risponde allo stesso modo: ciascuna posizione va ricostruita sulle definizioni della direttiva e sull’attività effettivamente svolta.

Per l’impresa questo significa che l’anagrafica dei fornitori non basta. Per ciascuna famiglia di prodotto occorre poter dire chi ha sviluppato ciascun componente software, chi decide quali versioni rendere disponibili, chi le distribuisce e chi interviene sul prodotto dopo la vendita. Una società può essere fornitore nel contratto e fabbricante di un componente ai sensi della direttiva. Un inventario dei componenti software e delle dipendenze, costruito con il concorso di Progettazione, IT e Acquisti, è lo strumento con cui questa ricostruzione diventa possibile. La direttiva definisce condizioni di responsabilità e lascia all’impresa la scelta di come mettersi in condizione di rispondere.

Il difetto nato dopo la vendita

L’articolo 7, paragrafo 1, considera difettoso il prodotto che non offre la sicurezza che una persona ha diritto di attendersi o che è richiesta dal diritto dell’Unione o nazionale. Il paragrafo 2 elenca le circostanze da considerare e tre di esse riguardano direttamente il caso. La lettera c) considera gli effetti sul prodotto della sua capacità di continuare a imparare o di acquisire nuove funzionalità. La lettera f) considera i pertinenti requisiti di sicurezza del prodotto, compresi i requisiti di cibersicurezza rilevanti per la sicurezza. La lettera e) fissa il momento di riferimento: quello in cui il prodotto è stato immesso sul mercato o messo in servizio oppure, se il fabbricante mantiene il controllo sul prodotto dopo quel momento, quello in cui il prodotto esce dal suo controllo. L’articolo 4, punto 5, definisce il controllo del fabbricante e vi comprende, alla lettera b), la capacità di fornire aggiornamenti o migliorie del software, direttamente o tramite terzi.

Qui il caso si decide. Nel regime della direttiva 85/374/CEE il produttore poteva liberarsi provando che il difetto non esisteva al momento in cui il prodotto era stato messo in circolazione. La nuova direttiva conserva questa causa di esonero all’articolo 11, paragrafo 1, lettera c), ma il paragrafo 2 la esclude quando il carattere difettoso deriva da un servizio correlato, dal software compresi i suoi aggiornamenti o dalla mancanza degli aggiornamenti necessari a mantenere la sicurezza, a condizione che il prodotto sia sotto il controllo del fabbricante. Il fabbricante della pressa, che ha approvato e distribuito l’aggiornamento attraverso il proprio servizio cloud, non potrà sostenere che la macchina era sicura quando è uscita dallo stabilimento. Lo stesso articolo 11, paragrafo 2, copre il caso opposto: se il fabbricante non avesse distribuito la correzione della vulnerabilità e un attacco avesse sfruttato la falla, la mancanza dell’aggiornamento necessario a mantenere la sicurezza sarebbe entrata nella valutazione del difetto. Un aggiornamento reso disponibile e non installato dall’utilizzatore pone invece una questione diversa, che va esaminata sui fatti e sulle istruzioni fornite.

Per i fabbricanti di dispositivi connessi, la gestione della sicurezza non si esaurisce necessariamente con la commercializzazione. Quando il fabbricante mantiene il controllo sul prodotto, gli aggiornamenti software possono assumere rilievo nella valutazione della difettosità e delle condizioni di responsabilità, secondo quanto previsto dalla direttiva. Non ne deriva che ogni aggiornamento sia una nuova immissione sul mercato: la direttiva distingue gli aggiornamenti ordinari dalla modifica sostanziale definita all’articolo 4, punto 18, e soltanto a questa collega conseguenze specifiche, come la decorrenza di un nuovo periodo di estinzione del diritto al risarcimento ai sensi dell’articolo 17, paragrafo 1. Il ciclo di vita del prodotto comprende comunque gli aggiornamenti, le componenti aggiunte dopo la prima versione e le decisioni sul mantenimento del supporto.

Il ticket chiuso 2 settimane prima

Nella ricostruzione dell’incidente emerge un dettaglio. Due settimane prima della lesione, un altro cliente aveva aperto un ticket di assistenza: la macchina si fermava con un ritardo percepibile e poi riprendeva. Il servizio di assistenza aveva controllato da remoto, non aveva trovato codici di errore e aveva chiuso il ticket come non riproducibile. Nessuno lo aveva collegato all’aggiornamento distribuito pochi giorni prima e nessuno lo aveva portato alla Progettazione.

Questo ticket pesa in 3 modi: 1. Nella valutazione del difetto, perché mostra che il fabbricante aveva un segnale di malfunzionamento di una funzione di sicurezza e non lo ha esaminato. 2. Nella prova, perché può rientrare tra gli elementi di cui il danneggiato chiede l’esibizione. 3. Nel processo interno, perché rivela che l’assistenza classificava i reclami soltanto per la loro risoluzione tecnica. Un ticket chiuso perché il servizio è stato ripristinato non risponde alla domanda se l’anomalia riveli un difetto ricorrente.

La procedura di assistenza può distinguere il guasto che incide solo sulla disponibilità di una funzione dal malfunzionamento che tocca la sicurezza del prodotto. Gli indicatori che giustificano l’escalation possono essere il coinvolgimento di una funzione protettiva, un possibile danno alle persone, la ripetizione su macchine con la stessa versione, il rapporto con un rilascio recente e la presenza di una vulnerabilità sfruttabile. Dove uno di questi segnali compare, l’istruttoria dovrebbe raggiungere Progettazione, Qualità e, se necessario, Legale e Sicurezza informatica. È una soluzione organizzativa, non un obbligo della direttiva.

L’escalation interna va tenuta distinta dalle comunicazioni verso l’esterno. Il regolamento (UE) 2024/2847, il Cyber Resilience Act, prevede dall’11 settembre 2026 obblighi di segnalazione delle vulnerabilità attivamente sfruttate e degli incidenti gravi per i fabbricanti di prodotti con elementi digitali che rientrano nel suo campo di applicazione, mentre la parte restante del regolamento si applica dall’11 dicembre 2027. Se il servizio cloud tratta dati personali degli operatori, una vulnerabilità sfruttata può costituire una violazione dei dati personali da valutare ai sensi degli articoli 33 e 34 del regolamento (UE) 2016/679: l’articolo 2, paragrafo 4, lettera a), della direttiva fa espressamente salva l’applicabilità del diritto dell’Unione sulla protezione dei dati personali. Lo stesso evento può quindi richiedere più valutazioni con presupposti, termini e destinatari diversi. Un registro degli eventi che colleghi i ticket tra loro aiuta, purché tenga separati i fatti dalle qualificazioni giuridiche e non converta ogni anomalia in tutte le categorie normative disponibili.

Le prove che verranno chieste

Il danneggiato, l’operatore dell’officina, agisce contro il fabbricante della pressa. L’articolo 9 gli consente di chiedere al giudice che il convenuto esibisca i pertinenti elementi di prova a sua disposizione, se la domanda è sufficientemente plausibile, nei limiti di quanto è necessario e proporzionato e con la tutela delle informazioni riservate e dei segreti commerciali. Non è un diritto di accesso al codice sorgente di qualunque software: il giudice valuta cosa serve e come proteggerlo. Per il fabbricante la domanda pratica è se sappia dove si trovano i rapporti di test della correzione, le note di rilascio, l’approvazione alla distribuzione, i registri di distribuzione per macchina e versione, la storia del ticket chiuso come non riproducibile.

L’articolo 10 collega direttamente le prove alla difettosità. Il paragrafo 2 presume il carattere difettoso quando il convenuto omette di esibire gli elementi di prova ordinati ai sensi dell’articolo 9, quando il prodotto non rispetta requisiti obbligatori di sicurezza o quando il danno è stato causato da un malfunzionamento evidente durante un uso ragionevolmente prevedibile. Il paragrafo 4 consente al giudice di presumere il difetto o il nesso di causalità quando la complessità tecnica o scientifica rende eccessivamente difficile la prova per il danneggiato. Sono presunzioni confutabili e la direttiva non ribalta in ogni caso l’onere della prova sul fabbricante. L’indisponibilità delle evidenze tecniche può però compromettere la capacità difensiva dell’impresa e, nelle condizioni previste dagli articoli 9 e 10, concorrere all’applicazione delle presunzioni legali sulla difettosità.

Da qui il valore del change management. Nel caso, la correzione di una vulnerabilità nel modulo di comunicazione aveva superato i test funzionali ma nessuno aveva valutato il suo effetto sulla temporizzazione della funzione di arresto. Un criterio operativo può prevedere che ogni modifica venga classificata per funzione interessata, dipendenze coinvolte e possibili effetti sui presidi di protezione delle persone, e che le modifiche classificate come rilevanti ricevano test di regressione sulle funzioni di sicurezza, proporzionati e documentati. Non è una qualifica che nasce dal nome del rilascio: una patch di sicurezza può toccare una funzione protettiva più di una major release. Il registro dei rilasci, che molte imprese tengono per esigenze commerciali, diventa il documento con cui si ricostruisce quale versione girava su quale macchina nel giorno dell’incidente. Per chi lavora con ISO 9001:2026 questi passaggi hanno una collocazione naturale nei processi di progettazione e sviluppo, di controllo delle modifiche e di gestione degli output non conformi. Per chi lavora con ISO/IEC 27001:2022 la gestione delle vulnerabilità e delle modifiche è tra i controlli dell’Allegato A e, se il servizio cloud fosse fornito da un terzo, entrerebbero in gioco i controlli sui fornitori da 5.19 a 5.23.

I contratti non spostano la responsabilità verso il danneggiato

Il fabbricante della pressa chiama in causa il fornitore del firmware. Il contratto tra i 2 contiene una clausola per cui il fornitore assume ogni responsabilità per i danni derivanti dal proprio software. Nel caso, però, la correzione è stata sviluppata dal fornitore e poi testata, approvata e distribuita dal fabbricante: non si può dare per scontato che il difetto sia imputabile soltanto al fornitore, perché il ruolo del fabbricante nell’integrazione e nella validazione della modifica entra nella ricostruzione dei presupposti dell’articolo 8. Se entrambi gli operatori risultano responsabili dello stesso danno, l’articolo 12, paragrafo 1, prevede che possano essere ritenuti responsabili in solido e l’articolo 15 rende prive di effetto le clausole contrattuali che escludono o limitano la responsabilità verso il danneggiato. In quella ipotesi l’operatore ferito può rivolgersi al fabbricante della pressa per l’intero danno e la clausola regola soltanto il rapporto interno tra le 2 imprese, in sede di regresso. Una clausola di distribuzione interna del rischio ha una funzione legittima. Una clausola che pretende di escludere i diritti del danneggiato non ne ha nessuna.

Il contratto con il fornitore di un componente da cui dipende la sicurezza non dovrebbe quindi limitarsi alla distribuzione economica delle responsabilità, ma disciplinare anche gli obblighi operativi e informativi necessari a gestire la sicurezza del prodotto. Possono essere utili le informazioni minime sulle versioni, i tempi di notifica delle vulnerabilità, la fornitura dei rapporti di test insieme alla correzione, la cooperazione nell’analisi di un incidente, la conservazione delle evidenze per un periodo proporzionato e le condizioni di cessazione del servizio. Queste clausole vanno calibrate sulla criticità del componente e sul potere negoziale effettivo. Il fornitore avrà interesse a proteggere il proprio codice e la direttiva non impone che la contrattazione riproduca l’accesso giudiziale alle prove: si tratta di stabilire quali informazioni tecniche circolano durante il rapporto, con quali limiti di riservatezza.

Il presidio deve funzionare anche dopo la firma. Nel caso, il contratto con il fornitore del firmware prevedeva la consegna dei rapporti di test con ogni correzione, ma la Progettazione non lo sapeva e non li aveva mai chiesti. Una clausola corretta e sconosciuta al reparto tecnico vale poco. Il passaggio tra Acquisti, Legale e Progettazione dovrebbe prevedere un referente operativo per ciascun componente critico e la disponibilità delle informazioni essenziali a chi gestisce modifiche, assistenza e anomalie.

I termini e il tempo delle evidenze

L’articolo 16 fissa in 3 anni il termine di prescrizione, decorrente dal giorno in cui il danneggiato ha avuto o avrebbe ragionevolmente dovuto avere conoscenza del danno, del difetto e dell’identità dell’operatore economico responsabile. L’articolo 17, paragrafo 1, fissa in 10 anni il periodo oltre il quale il diritto al risarcimento si estingue, decorrente dall’immissione sul mercato o dalla messa in servizio del prodotto o, per i prodotti modificati in maniera sostanziale, dal momento della modifica. Il paragrafo 2 porta il periodo a 25 anni quando il danneggiato non ha potuto agire entro i 10 anni a causa del periodo di latenza delle lesioni personali. I termini decorrono dal prodotto e dagli eventi indicati, non dal giorno in cui l’incidente è stato scoperto.

Per il fabbricante della pressa il tema diventa la conservazione delle evidenze. La direttiva non obbliga a conservare ogni log per 10 anni e la conservazione di dati personali degli operatori nel servizio cloud incontra i limiti del regolamento (UE) 2016/679. Ma la decisione su quali evidenze tenere, per quanto tempo e in quale forma va presa in modo consapevole, sapendo che una richiesta di esibizione può arrivare molti anni dopo il rilascio.

Che cosa verifica l’Internal Audit e che cosa arriva al vertice

L’Internal Audit non sostituisce Qualità, Sicurezza informatica, Legale e Compliance. Verifica se la loro interazione è definita, se le eccezioni raggiungono il livello decisionale competente e se c’è evidenza dell’effettiva applicazione dei presidi. Un test di audit utile parte da un prodotto commercializzato: l’auditor seleziona una versione, ne ricostruisce i componenti critici, verifica chi ha autorizzato gli aggiornamenti, esamina un reclamo significativo e accerta se le anomalie siano state valutate oltre il ripristino tecnico. Nel caso della pressa avrebbe trovato il ticket chiuso come non riproducibile, la correzione approvata senza test sulle funzioni di sicurezza e i rapporti di test del fornitore mai richiesti. Il rilievo deve indicare quale requisito è stato violato oppure, in assenza di un obbligo specifico, quale debolezza del controllo è stata osservata. Questa distinzione è ciò che impedisce di trasformare ogni scelta prudenziale in un precetto di legge.

La Compliance può mantenere una matrice delle fonti applicabili per famiglia di prodotto e per ruolo economico dell’impresa, distinguendo il regime di responsabilità della direttiva, gli obblighi preventivi del Cyber Resilience Act, le norme di prodotto di settore (nel caso, la direttiva macchine e dal 2027 il regolamento (UE) 2023/1230) e gli obblighi contrattuali. Una certificazione non è una conclusione di conformità. Il consiglio di amministrazione non è chiamato dalla direttiva a deliberare ogni rilascio software. Dall’ordinaria governance deriva però la necessità di conoscere le esposizioni significative: quali prodotti dipendono da modifiche critiche, quali fornitori sono essenziali, quali incidenti hanno toccato la sicurezza, quali decisioni sul mantenimento del supporto sono aperte. Un rapporto che indica il numero di bug corretti non dà questa informazione.

Che cosa fare ed entro quando

Le indicazioni che seguono traducono le disposizioni della direttiva in possibili interventi sui processi aziendali, con l’obiettivo di rafforzare la gestione dei rischi e il sistema dei controlli interni.

Entro l’8 dicembre 2026, per i prodotti che saranno immessi sul mercato dopo quella data:

• censire i prodotti e i componenti digitali, distinguendo quelli di cui l’impresa è fabbricante dai servizi che semplicemente utilizza, e individuare per ciascuno chi sviluppa, chi autorizza i rilasci e chi distribuisce. Il censimento consente di ricostruire il ruolo effettivo dell’impresa e degli altri operatori della filiera, ai fini della valutazione delle responsabilità previste dall’articolo 8
• rileggere i contratti con i fornitori di componenti critici e valutare se aggiungere alla ripartizione delle responsabilità gli obblighi di notifica delle vulnerabilità, di consegna dei rapporti di test e di cooperazione nell’analisi degli incidenti. Sono strumenti contrattuali di gestione del rischio, non clausole imposte dalla direttiva: la loro necessità dipende dalla natura del componente, dal rapporto tra le parti e dagli altri obblighi normativi applicabili. In ogni caso la Progettazione deve conoscerli
• definire quali evidenze relative a progettazione, test, versioni software e aggiornamenti sia opportuno conservare, individuando tempi e modalità proporzionati ai rischi e agli obblighi applicabili. In questa valutazione possono assumere rilievo anche i termini previsti dall’articolo 17 della direttiva, che non costituiscono tuttavia un obbligo generalizzato di conservazione per un periodo corrispondente.

Queste verifiche sono particolarmente utili prima dell’immissione sul mercato, perché consentono di individuare tempestivamente ruoli, dipendenze e responsabilità. Devono tuttavia essere mantenute aggiornate durante il ciclo di vita del prodotto, soprattutto in presenza di modifiche, aggiornamenti o variazioni della filiera.

Prima del primo aggiornamento distribuito su un prodotto nel nuovo regime, quindi di fatto nelle stesse settimane:

• rivedere la classificazione delle modifiche nel change management, in modo che le correzioni che toccano funzioni di sicurezza ricevano test di regressione documentati, perché l’articolo 11, paragrafo 2, limita, nelle condizioni previste, la possibilità del fabbricante di invocare l’assenza del difetto al momento dell’immissione sul mercato quando la difettosità deriva da software, aggiornamenti o dalla mancata disponibilità degli aggiornamenti necessari a mantenere la sicurezza del prodotto
• inserire nella procedura di assistenza i criteri di escalation dei reclami che coinvolgono funzioni protettive o si ripetono su una stessa versione, perché un ticket chiuso come non riproducibile può rientrare tra gli elementi di prova di cui il danneggiato chiede l’esibizione ai sensi dell’articolo 9, secondo la rilevanza e le condizioni previste.

Fonti

• Unione europea, Direttiva (UE) 2024/2853 del Parlamento europeo e del Consiglio, del 23 ottobre 2024, sulla responsabilità per danno da prodotti difettosi, articoli 2, 4, 7, 8, 9, 10, 11, 12, 15, 16, 17, 21 e 22.
• Unione europea, Rettifica della direttiva (UE) 2024/2853, Gazzetta ufficiale dell’Unione europea, maggio 2026 (articolo 2, paragrafo 1: da «dopo il 9 dicembre 2026» a «dopo l’8 dicembre 2026»).
• Unione europea, Regolamento (UE) 2024/2847, Cyber Resilience Act, articoli 14 e 71.
• Presidenza del Consiglio dei ministri, Comunicato stampa del Consiglio dei ministri n. 195, ottobre 2026.
• Camera dei deputati, Servizio Studi, Atto del Governo n. 434, attuazione della direttiva (UE) 2024/2853, settembre 2026.