Il 28 ottobre 2026 il Consiglio dei ministri ha approvato in esame definitivo il decreto legislativo che attua la direttiva (UE) 2024/2853 sulla responsabilità per danno da prodotti difettosi, con modifica del Codice del consumo. Il decreto non risulta ancora pubblicato in Gazzetta Ufficiale e numero, testo e decorrenze andranno verificati alla pubblicazione. La direttiva, però, ha già una data: l’articolo 2, paragrafo 1, nel testo rettificato il 7 maggio 2026, si applica ai prodotti immessi sul mercato o messi in servizio dopo l’8 dicembre 2026. La novità più discussa è che il software è un prodotto, per l’articolo 4, punto 1, della direttiva, e che nella valutazione del difetto contano anche la cybersicurezza e gli aggiornamenti. Per capire che cosa questo cambia nei processi di un’impresa conviene seguire un caso.
Una pressa, un firmware, un servizio cloud
Un fabbricante italiano immette sul mercato una pressa piegatrice nel gennaio 2027. La data non è casuale: la macchina entra sul mercato dopo l’8 dicembre 2026 e ricade quindi nel nuovo regime. Il controllore di sicurezza monta un firmware sviluppato da un fornitore specializzato e la macchina è collegata a un servizio cloud, gestito dal fabbricante, che raccoglie i dati di funzionamento e distribuisce gli aggiornamenti. A marzo il fornitore segnala una vulnerabilità nel modulo di comunicazione e rilascia una correzione. Il fabbricante la testa secondo la propria procedura, la approva e la distribuisce a tutte le macchine installate. Ad aprile, in un’officina cliente, l’arresto comandato dalla barriera fotoelettrica interviene con qualche decina di millisecondi di ritardo e un operatore si ferisce a una mano. La correzione aveva modificato la priorità di un processo del controllore.
Chi risponde
L’articolo 8, paragrafo 1, della direttiva chiama a rispondere il fabbricante del prodotto difettoso e il fabbricante del componente difettoso, se il componente è stato integrato nel prodotto sotto il controllo del fabbricante e ne ha causato il difetto. Il fornitore del firmware non è quindi soltanto una controparte contrattuale: può essere chiamato a rispondere direttamente dal danneggiato. Importatori, rappresentanti autorizzati e distributori rispondono alle condizioni previste dallo stesso articolo, non tutti e non allo stesso modo. Per l’impresa questo significa che l’anagrafica dei fornitori non basta: per ciascuna famiglia di prodotto occorre sapere chi ha sviluppato ogni componente software, chi autorizza i rilasci e chi li distribuisce.
Il difetto nato dopo la vendita
L’articolo 7 considera difettoso il prodotto che non offre la sicurezza che una persona ha diritto di attendersi e, tra le circostanze da valutare, il paragrafo 2 include i requisiti di cibersicurezza rilevanti per la sicurezza e, se il fabbricante mantiene il controllo sul prodotto dopo la vendita, il momento in cui il prodotto esce da quel controllo. Il controllo del fabbricante, per l’articolo 4, punto 5, comprende la capacità di fornire aggiornamenti del software.
Con il regime precedente il produttore poteva liberarsi provando che il difetto non esisteva quando il prodotto era stato messo in circolazione. L’articolo 11, paragrafo 2, della nuova direttiva esclude questa causa di esonero quando il difetto deriva dal software, compresi i suoi aggiornamenti, o dalla mancanza degli aggiornamenti necessari a mantenere la sicurezza, se il prodotto è sotto il controllo del fabbricante. Il fabbricante della pressa, che ha approvato e distribuito l’aggiornamento dal proprio cloud, non potrà dire che la macchina era sicura quando ha lasciato lo stabilimento. Per i fabbricanti di dispositivi connessi la gestione della sicurezza non si esaurisce con la commercializzazione: quando il fabbricante mantiene il controllo sul prodotto, gli aggiornamenti possono assumere rilievo nella valutazione della difettosità, senza che ogni aggiornamento diventi per questo una nuova immissione sul mercato o una modifica sostanziale.
Il ticket chiuso 2 settimane prima
Nella ricostruzione emerge che 2 settimane prima un altro cliente aveva segnalato un arresto in ritardo. L’assistenza aveva controllato da remoto, non aveva trovato codici di errore e aveva chiuso il ticket come non riproducibile, senza collegarlo all’aggiornamento e senza informare la Progettazione. Quel ticket peserà nella valutazione del difetto, può rientrare tra i documenti di cui il danneggiato chiede l’esibizione e racconta un processo di assistenza che classifica i reclami solo per la loro risoluzione tecnica.
La procedura di assistenza può distinguere il guasto che tocca solo la disponibilità di una funzione dal malfunzionamento che tocca la sicurezza, con indicatori di escalation verso Progettazione, Qualità, Sicurezza informatica e Legale: funzione protettiva coinvolta, possibile danno alle persone, ripetizione sulla stessa versione, rapporto con un rilascio recente. È una soluzione organizzativa, non un obbligo della direttiva. Va tenuta distinta dalle comunicazioni verso l’esterno: il Cyber Resilience Act prevede dall’11 settembre 2026 obblighi di segnalazione delle vulnerabilità attivamente sfruttate per i fabbricanti che rientrano nel suo campo di applicazione e, se il cloud tratta dati personali degli operatori, una violazione va valutata ai sensi degli articoli 33 e 34 del GDPR. Lo stesso evento può richiedere più valutazioni, con presupposti e destinatari diversi.
Le prove che verranno chieste
L’articolo 9 consente al danneggiato di chiedere al giudice l’esibizione degli elementi di prova a disposizione del convenuto, nei limiti di quanto è necessario e proporzionato e con tutela dei segreti commerciali. L’articolo 10, paragrafo 2, presume il difetto se il convenuto non esibisce quanto ordinato, se il prodotto non rispetta requisiti obbligatori di sicurezza o se il danno deriva da un malfunzionamento evidente durante un uso ragionevolmente prevedibile. Le presunzioni sono confutabili e la direttiva non ribalta in ogni caso l’onere della prova. Un fabbricante che non trova i rapporti di test della correzione, le note di rilascio, l’approvazione e il registro di quale versione girava su quale macchina vede però compromessa la propria capacità difensiva e, nelle condizioni previste dagli articoli 9 e 10, l’indisponibilità delle evidenze può concorrere all’applicazione delle presunzioni.
Da qui il valore del change management. La correzione aveva superato i test funzionali e nessuno aveva valutato il suo effetto sulla temporizzazione dell’arresto. Classificare le modifiche per funzione interessata e sottoporre quelle che toccano funzioni protettive a test di regressione documentati è il controllo che mancava. Per chi lavora con ISO 9001:2026 e ISO/IEC 27001:2022 questi passaggi hanno una collocazione naturale nei processi di controllo delle modifiche e di gestione delle vulnerabilità. Sono standard volontari: offrono un contenitore per le evidenze, non una presunzione di assenza del difetto.
I contratti non spostano la responsabilità verso chi si è fatto male
Il contratto tra fabbricante e fornitore del firmware prevede che il fornitore assuma ogni responsabilità per i danni derivanti dal proprio software. La correzione, però, è stata testata, approvata e distribuita dal fabbricante, e il suo ruolo nella validazione della modifica entra nella ricostruzione delle responsabilità secondo l’articolo 8. Se entrambi risultano responsabili dello stesso danno, l’articolo 12 consente di ritenerli responsabili in solido e l’articolo 15 rende prive di effetto le clausole che escludono o limitano la responsabilità verso il danneggiato: l’operatore ferito può rivolgersi al fabbricante della pressa per l’intero danno e la clausola regola solo il regresso tra le 2 imprese. Il contratto con il fornitore di un componente critico non dovrebbe quindi limitarsi a ripartire le responsabilità, ma disciplinare anche gli obblighi operativi e informativi che servono a gestire la sicurezza del prodotto: notifica delle vulnerabilità, rapporti di test con ogni correzione, cooperazione nell’analisi degli incidenti, conservazione delle evidenze. E va conosciuto da chi gestisce il prodotto: nel caso, il contratto prevedeva la consegna dei rapporti di test, ma la Progettazione non li aveva mai chiesti.
Da dove cominciare
Il nuovo regime non chiede di costruire un sistema di controllo nuovo. Chiede di collegare processi che esistono già e che spesso restano separati: il censimento dei componenti software con chi li sviluppa e chi li distribuisce, la classificazione delle modifiche che toccano la sicurezza, i criteri di escalation dei reclami, i contratti con i fornitori di componenti critici e la decisione su quali evidenze conservare. L’Internal Audit può verificare questi passaggi partendo da un prodotto commercializzato: una versione, i suoi componenti, chi ha autorizzato gli aggiornamenti, un reclamo significativo e come è stato trattato. Alla pubblicazione del decreto il lavoro andrà confrontato con il testo nazionale, in particolare per decorrenze e per le scelte lasciate agli Stati membri.