Anche il software è prodotto: cosa cambia nell’ambito della responsabilità del produttore

La nuova direttiva Ue 2024/2853 aggiorna la disciplina sulla responsabilità per danno da prodotto difettoso e può avere un impatto rilevante anche sulla filiera del software.

Il recepimento è obbligatorio da parte dei Singoli Stati entro fine anno e la struttura della direttiva deve restare inalterata.

Il software entra nella nozione di “prodotto” (insieme, tra l’altro, a file per la fabbricazione digitale e servizi correlati), con ricadute dirette su cyber security e data integrity.

Ecco quali, dl momentp che cambiano anche i profili operativi (danni risarcibili – inclusa corruzione/ distruzione dati -, gestione richiami/azioni correttive, responsabilità lungo la supply chain, disclosure probatoria).

Il quadro

Con la Direttiva (UE) 2024/2853 del Parlamento europeo e del Consiglio del 23 ottobre 2024 [1], l’UE aggiorna le regole sulla responsabilità per danno da prodotto difettoso e ricomprende anche il software nella nozione di “prodotto”.

Il recepimento negli Stati membri dovrà avvenire entro il 9 dicembre 2026: da quel momento, scelte di progettazione, aggiornamento e gestione delle vulnerabilità diventano ancora più rilevanti anche sul piano civilistico e probatorio, con effetti su governance di prodotto, supply chain e gestione delle evidenze tecniche.

In altre parole, il software ‘difettoso’ può diventare anche un problema di responsabilità da prodotto.

Il recepimento richiede l’adozione di una normativa interna di attuazione; in caso di ritardo, la Commissione può avviare una procedura d’infrazione, con i conseguenti richiami formali e, nei casi previsti, possibili ricadute economiche.

Per questo è opportuno monitorare l’iter di recepimento italiano, perché in quella sede si definiranno scelte applicative e raccordi con la normativa nazionale.

La struttura e i contenuti essenziali della direttiva, però, non possono essere alterati dal legislatore nazionale: il recepimento potrà incidere su modalità e strumenti di attuazione, non sul nucleo degli obblighi e delle definizioni.

Di conseguenza, la griglia di lettura e le schede operative proposte restano valide come base di lavoro, già nella fase di preparazione interna.

L’impatto in ambito cyber security

Probabilmente il titolo della direttiva, da solo, non ne disvela la portata potenziale: l’impatto in ambito cyber security emerge con chiarezza solo se si evidenzia che anche il software viene considerato un “prodotto” ai fini della responsabilità.

Si tratta di un cambiamento tutt’altro che marginale, destinato ad avere ripercussioni significative lungo la filiera dei produttori di software.

Le questioni giuridiche e le implicazioni tecniche che il recepimento di questa direttiva comporterà sono molte, per tutte le aziende che operano – in senso ampio – nel settore della produzione software.

Come, per esempio, nel caso in cui venga utilizzato un software Free Open Source.

Infatti, la Direttiva UE 2024/2853 non si applica al software Free Open Source quando è sviluppato o fornito fuori da un’attività commerciale (quindi senza corrispettivo economico o “monetizzazione” assimilabile).

Attenzione, però, se quel FOSS viene integrato da un’azienda in un prodotto commercializzato, la possibile responsabilità per i difetti ricade sul produttore del prodotto finale, non sul maintainer/fornitore FOSS non commerciale.

Di seguito viene proposto uno schema di analisi della direttiva partendo dalle definizioni chiave fino a quelle delle schede di sintesi con i consigli operativi per le aziende.

Struttura della direttiva Ue sul software: focus su 3 prospettive

Le schede che seguono offrono una panoramica della struttura della direttiva, con focus sulle principali implicazioni aziendali da tre prospettive: IT (Tech), legale (Legal) e compliance.

Inoltre, si prefiggono di fornire una strategia operativa che aiuti le singole aziende a valutare la portata della nuova direttiva e a mettere in campo azioni pratiche.

Quadro normativo e calendario di applicazione

Nel 2024 la Unione Europea ha aggiornato la disciplina sulla responsabilità per danno da prodotto difettoso, adottando una nuova direttiva che gli Stati membri dovranno integrare negli ordinamenti nazionali entro una scadenza fissata nel dicembre 2026 (art. 22, par. 1) e che si applicherà ai prodotti immessi sul mercato o messi in servizio successivamente a tale data (art. 2, par. 1) [2].

Implicazioni aziendali:

• Tech: mappare il portafoglio prodotti (inclusi componenti e software) e impostare una “roadmap compliance-by-design” per le release post-2026: logging, tracciabilità, gestione versioni, meccanismi di aggiornamento e rollback.
• Legal: avviare un “gap assessment” tra regime vigente e nuove regole; predisporre clausole contrattuali su responsabilità e cooperazione probatoria nella supply chain.
• Compliance: istituire un programma trasversale (Legal–Engineering–Quality–Procurement) con ownership chiara e KPI (es. tempo di risposta a richieste di disclosure, completezza della documentazione tecnica).

I 3 driver della direttiva

L’aggiornamento normativo risponde a tre driver [3]:

• tecnologie digitali e sistemi “software-driven” (con particolare attenzione ai sistemi autonomi e all’IA);
• modelli di economia circolare (riparazione, ricondizionamento, riuso);
• filiera globalizzata con ruoli frammentati tra produttori, integratori, importatori e piattaforme.

Implicazioni aziendali

Le implicazioni enterprise sono le seguenti:

• Tech: classificare i prodotti “digital-first” (software embedded, cloud, app, modelli ML, pipeline dati) e definire controlli di sicurezza/qualità che riducano rischi di difettosità (secure SDLC, test regressivi, monitoraggio post-market).
• Legal: rivedere l’allocazione del rischio tra attori della filiera (in particolare per componenti software, dipendenze e fornitori extra-UE); aggiornare policy su sorveglianza post-commercializzazione e risposta agli incidenti.
• Compliance: Rafforzare la governance degli acquisti (procurement), includendo la valutazione e qualifica dei fornitori (vendor assessment), audit e SLA su sicurezza e aggiornamenti, e consolidare il raccordo tra le funzioni tecniche e la compliance di prodotto.

Definizione di “prodotto”: inclusione di software e output digitali

La definizione di prodotto viene estesa: non si parla più solo di bene materiale “tradizionale”, ma anche di beni mobili integrati o interconnessi e di asset digitali funzionali alla fabbricazione o al funzionamento (in particolare software e file per fabbricazione digitale) (art. 4, par. 1–2).

L’effetto pratico è che la “difettosità” può riguardare anche componenti immateriali che incidono su sicurezza/affidabilità (cfr. anche “component”, art. 4, par. 4) [4].

Implicazioni aziendali:

• Tech: classificare i prodotti “digital-first” (software embedded, cloud, app, modelli ML, pipeline dati) e definire controlli di sicurezza/qualità che riducano rischi di difettosità (secure SDLC, test regressivi, monitoraggio post-market).
• Legal: rivedere l’allocazione del rischio tra attori della filiera (in particolare per componenti software, dipendenze e fornitori extra-UE); aggiornare policy su sorveglianza post-commercializzazione e risposta agli incidenti.
• Compliance: Rafforzare la governance degli acquisti (procurement), includendo la valutazione e qualifica dei fornitori (vendor assessment), audit e SLA su sicurezza e aggiornamenti, e consolidare il raccordo tra le funzioni tecniche e la compliance di prodotto.

Ampliamento dei danni risarcibili: non solo fisico/patrimoniale

Il ventaglio dei pregiudizi risarcibili viene ampliato includendo, oltre ai danni tradizionali, anche:

• pregiudizi di natura psicologica, quando accertati in modo idoneo sul piano medico (art. 6, par. 1, lett. a));
• compromissione, distruzione o corruzione dei dati (art. 6, par. 1, lett. c)).

Questo sposta l’attenzione verso impatti “intangible” e verso la dimensione cyber e data integrity (sul perimetro dei pregiudizi risarcibili/materiali e non materiali, cfr. art. 6, par. 2) [5].

Implicazioni aziendali:

• Tech: potenziare misure di resilienza dati (backup, immutabilità, controlli integrità, disaster recovery) e sicurezza (hardening, patching, segmentation, access control, audit trail); definire metriche su incidenti.
• Legal: coordinare responsabilità prodotto con gestione incidenti cyber e perdita di dati (anche in parallelo a obblighi privacy/cyber); Predisporre una strategia di gestione dei claim e di conservazione documentale.
• Compliance: addestrare i due team customer care e incident response su escalation legale e raccolta prove; introdurre un processo unico di gestione reclami/sinistri.

Richiami e interventi delle autorità: elemento di valutazione della difettosità

Nel valutare se un prodotto sia difettoso, assumono rilievo anche richiami, azioni correttive e interventi dell’operatore economico o delle autorità competenti (art. 7, par. 2, lett. g)) [6].

Pur senza creare automaticamente una “presunzione” di difettosità, tali interventi rilevano come circostanza di contesto (considerando 34). In parallelo, assumono peso anche i requisiti di sicurezza del prodotto, inclusi quelli cyber security-relevant (art. 7, par. 2, lett. f)).

Implicazioni aziendali:

• Tech: Predisporre procedure tecniche per campagne di richiamo (recall) e aggiornamenti massivi, includendo rollout controllati, canary release e rollback; implementare sistemi di tracciabilità di lotti/versioni installate e processi di comunicazione ai clienti.
• Legal: definire criteri decisionali e soglie per avviare azioni correttive; standardizzare comunicazioni (evitare ammissioni improprie) e coordinare con autorità ove applicabile.
• Compliance: Playbook end-to-end per i richiami (recall): ruoli, tempi, governance, comunicazione interna/esterna e registro delle decisioni; simulazioni periodiche (tabletop exercise).

Chi risponde del danno: responsabilità lungo tutta la filiera

La responsabilità viene estesa (o comunque chiarita in modo più inclusivo) verso una pluralità di soggetti della catena del valore [7]:

• produttore del prodotto finito (art. 8, par. 1, lett. a)),
• produttore del componente difettoso integrato (art. 8, par. 1, lett. b)),
• importatore e soggetti “ponte” quando il produttore è extra-UE (art. 8, par. 1, lett. c), punti i)–iii)),
• in determinate ipotesi anche provider di piattaforme online (art. 8, par. 4).

Il punto sostanziale è che il danneggiato può avere più “porte” a cui bussare; per le imprese diventa cruciale la gestione contrattuale e documentale della filiera.

Implicazioni aziendali:

• Tech: definire requisiti tecnici minimi imposti ai fornitori (secure coding, test evidence, vulnerability disclosure, patch SLA); integrare assessment di sicurezza/qualità in onboarding e monitoraggio.
• Legal: rinegoziare contratti: manleve, limiti di responsabilità (dove ammessi), obblighi di cooperazione probatoria, audit rights, tracciabilità e notifica incidenti; attenzione ai ruoli in marketplace e distribuzione.
• Compliance: creare una funzione/rituale di “supplier governance” con scorecard e audit; istituire un registro dei ruoli (chi è fabbricante, integratore, importatore, rappresentante autorizzato, eccetera) per prodotto/mercato.

Modifiche sostanziali e ricondizionamento: chi altera il prodotto può diventare responsabile

È prevista una responsabilità specifica per chi apporta modifiche sostanziali al prodotto al di fuori del controllo del fabbricante originario (art. 8, par. 2) (es. ricondizionamento, refitting, upgrade hardware/software rilevanti).

In pratica, l’operatore che “trasforma” il bene si avvicina al ruolo di produttore rispetto ai rischi derivanti dalla modifica (sulla nozione di “modifica sostanziale”, art. 4, par. 18) [8].

Implicazioni aziendali:

• Tech: definire cosa costituisce “modifica sostanziale” in termini tecnici (soglie su firmware, sostituzione componenti critici, alterazione algoritmi); predisporre test di sicurezza/validazione post-modifica; tracciamento seriali e configurazioni.
• Legal: disciplinare contrattualmente il perimetro delle modifiche ammesse e le responsabilità; policy di garanzia e condizioni d’uso per prodotti ricondizionati; gestione delle istruzioni e avvertenze aggiornate.
• Compliance: governare la rete di partner/centri di assistenza: certificazione, formazione, audit; processi di quality assurance specifici per refurbished e “second life”.

Regole processuali: disclosure obbligatoria e “asimmetria” probatoria ridotta

Sul piano procedurale, la direttiva introduce meccanismi che incidono sulla dinamica del contenzioso [9]:

• obbligo di divulgazione di elementi di prova rilevanti in possesso dell’operatore economico convenuto, quando la domanda sia sufficientemente plausibile (art. 9, par. 1);
• alleggerimento dell’onere della prova in capo al danneggiato, con presunzioni/agevolazioni in scenari tipici: mancata disclosure (art. 10, par. 2, lett. a)); complessità tecnico-scientifica e difficoltà eccessive (art. 10, par. 4, lett. a)); dimostrazione di probabilità/“likelihood” che il prodotto sia difettoso o che vi sia nesso causale (art. 10, par. 4, lett. b)); oltre a presunzioni su nesso causale in condizioni specifiche (art. 10, par. 3).

In pratica, aumenta il valore strategico della documentazione tecnica e della capacità aziendale di produrre evidenze ordinate, coerenti e tempestive (con bilanciamento verso la tutela di riservatezza e segreti commerciali, art. 9, par. 4–5).

Implicazioni aziendali:

• Tech: costruire un sistema “evidence-ready”: logging sicuro, time-stamping, conservazione artefatti (requisiti, test, validazioni, risk assessment, change log), tracciabilità dei bug e patch; segregazione dei dati sensibili e accessi controllati.
• Legal: predisporre un litigation readiness plan (tempi, responsabilità, confidenzialità, legal privilege dove applicabile); definire criteri di retention e gestione richieste di accesso/disclosure.
• Compliance: costituire un team interfunzionale per contenzioso e incidenti (Legal + Engineering Security + QA); procedure di “document hold” e canali rapidi di escalation; formazione mirata su come scrivere ticket/rapporti tecnici “difendibili”.

Riferimenti

[1] GUUE L, 18.11.2024; CELEX 32024L2853.

[2] Art. 2, par. 1; art. 21 (transitorio); art. 22, par. 1; art. 23.

[3] Artt. 1 e 4 (definizioni su prodotto/componenti/servizi connessi).

[4] Artt. 1 e 4 (definizioni su prodotto/componenti/servizi connessi).

[5] Art. 6, par. 1, lett. a) e lett. c); art. 6, par. 2.

[6] Art. 7, par. 2, lett. g); art. 7, par. 2, lett. f); considerando 34.

[7] Art. 8, par. 1, lett. a)–c), punti i)–iii); art. 8, par. 4.

[8] Art. 8, par. 2; art. 4, par. 18 (definizione di “modifica sostanziale”).

[9] Art. 9; art. 10, par. 2–4; art. 9, par. 4–5 (confidenzialità).