Un cambio di parola che cambia tutto #
Per anni ho avuto la sensazione che il software vivesse in una specie di bolla. Non nel senso romantico del termine, più una zona grigia comoda, quasi protettiva. Se un prodotto fisico faceva male a qualcuno, la responsabilità era un tema immediato e concreto. Se invece era “solo” software, la conversazione scivolava spesso su bug, patch, workaround, e su quel sottinteso un po’ indulgente per cui “è normale, tanto si aggiorna”.
La direttiva 85/374/cee sulla responsabilità per prodotti difettosi, in fondo, parlava di beni mobili, roba tangibile. Il software, intangibile per definizione, ci stava dentro male. E quando una norma ti sta addosso male, spesso finisce che non ti sta addosso per niente.
Dal 9 dicembre 2026, con la direttiva (ue) 2024/2853, questa ambiguità si chiude. La nuova product liability directive (pld) dice esplicitamente che il software è un prodotto. E non solo il software “dentro” un oggetto, ma tutto: standalone, embedded, firmware, applicazioni, cloud, saas, sistemi di ai. Indipendentemente da dove gira e da come lo distribuisci.
Non è una nota a piè di pagina. È un cambio di paradigma, e forse la cosa più interessante è che non riguarda solo chi scrive codice. Riguarda chi decide cosa costruire, chi lo vende, chi lo rilascia, chi lo mantiene e chi decide quando smettere.
La responsabilità oggettiva: il punto in cui cambia la prospettiva #
La pld si appoggia su un concetto che nel mondo software è facile sottovalutare finché non ti cade addosso: la responsabilità oggettiva (strict liability).
In pratica, chi subisce un danno da un prodotto difettoso non deve dimostrare che tu sei stato negligente. Non deve ricostruire la tua catena di decisioni, non deve provare che “avresti potuto fare meglio”. Deve dimostrare tre cose: che il prodotto era difettoso, che c’è stato un danno, e che c’è un nesso causale.
Per chi è abituato a ragionare in termini di “abbiamo fatto il possibile”, “era un edge case”, “era una dipendenza terza”, è uno spostamento mentale notevole. La diligenza continua a contare, certo, ma non come scudo automatico.
E c’è un altro pezzo che rende tutto più concreto: la direttiva introduce meccanismi di presunzione.
Se per il danneggiato è “eccessivamente difficile” provare il difetto o il nesso causale, cosa che con software complesso o sistemi di ai è quasi la norma, il tribunale può presumere difettosità e causalità. Può anche ordinare al produttore di esibire documentazione tecnica, e deve essere presentata in modo “accessibile e comprensibile”. Se non collabori, quella mancata collaborazione può diventare un elemento a tuo sfavore.
Detta senza giri: in molti casi ti troverai a dover dimostrare che il software non era difettoso. E per farlo, servono prove. Tracce. Scelte motivate. Dati.
Chi fa prodotto: la responsabilità inizia molto prima del codice #
Quando si parla di responsabilità, l’istinto è guardare allo sviluppo. Ma la pld mette sotto lente anche ciò che viene prima, e cioè le decisioni di prodotto.
La difettosità si valuta sulle aspettative ragionevoli di sicurezza. Un prodotto è difettoso se non offre il livello di sicurezza che una persona è legittimamente autorizzata ad attendersi. E questo giudizio dipende da come presenti il prodotto, dall’uso ragionevolmente prevedibile, dal momento della messa in servizio. Ma anche da elementi modernissimi, tipo l’interconnessione con altri sistemi, la conformità ai requisiti di cybersecurity, e perfino la capacità di apprendere.
Qui mi viene da pensare a quante volte una roadmap nasce da trade-off che sembrano puramente “business”: consegnare prima, tagliare una feature di sicurezza, rimandare la hardening phase, integrare un componente ai perché “fa figo” e perché i competitor lo hanno già.
Con la pld, quelle non sono solo scelte di prodotto. Sono scelte che possono diventare rilevanti in una contestazione.
Se prometti nelle specifiche commerciali una certa affidabilità o un certo standard di sicurezza, stai creando un’aspettativa. Se integri un componente ai che cambia comportamento nel tempo, ti stai prendendo la responsabilità anche di quel comportamento futuro. E l’imprevedibilità dell’ai, per come è impostata la direttiva, non è una difesa.
La conseguenza più pratica, secondo me, è questa: il risk assessment entra nel product management. Non come documento che si fa una volta e poi si dimentica, ma come abitudine.
E soprattutto entra la documentazione delle decisioni. Non per burocrazia, ma perché tra qualche anno potrebbe essere necessario spiegare perché una certa scelta era ragionevole in quel momento. Gli architecture decision record, che oggi molti team usano per non perdersi, iniziano ad assomigliare a un pezzo della tua difesa.
Chi vende: il contratto non è più uno scudo #
C’è un riflesso condizionato diffuso nel software: se il rischio aumenta, si aggiunge una clausola. Limitazione di responsabilità, cap, manleva, disclaimer nei terms.
La pld qui è piuttosto brutale: la responsabilità prevista dalla direttiva non può essere esclusa o limitata contrattualmente quando il danno riguarda una persona fisica. Vale in b2c, e in pratica ti tocca anche in b2b ogni volta che esistono utenti finali persone.
Questo non significa che i contratti diventino inutili. Significa che devono cambiare funzione.
In particolare, nei rapporti b2b serve chiarire le responsabilità lungo la supply chain. Se sviluppi per un cliente che mette il prodotto sul mercato con il proprio brand, chi è il “fabbricante” ai sensi della pld? Se il tuo software è un componente dentro un sistema più grande, come si gestisce il regresso tra le parti? Non puoi eliminare la responsabilità verso l’esterno, ma puoi e devi chiarire cosa succede tra voi.
Poi c’è un pezzo che spesso viene sottovalutato da sales e marketing: le promesse commerciali.
Demo, brochure, claim tipo “massimi standard di sicurezza”, slide con “zero downtime”, pagine di pricing che implicano certe garanzie. Tutto questo contribuisce a definire cosa l’utente era legittimato ad aspettarsi. E quindi entra, indirettamente, nella valutazione della difettosità.
Infine, il tema assicurativo e di pricing. La rc professionale classica copre la negligenza, non necessariamente la strict liability. È probabile che molte aziende debbano rivedere coperture e massimali, includendo aspetti come cybersecurity, data loss e danni immateriali. E quel costo finirà nel prezzo. Con un effetto collaterale interessante: chi si muove bene prima può trasformare la compliance in un argomento competitivo credibile.
Chi rilascia: ogni deploy diventa un atto che lascia tracce #
Se lavori su release, devops, qa, o se sei la persona che alla fine dice “ok, si va in produzione”, questa è forse la parte più concreta.
Nel software moderno, il rilascio non è la fine. È l’inizio. Perché quasi sempre il produttore mantiene controllo tramite update, accesso remoto, feature flag, patch, aggiornamenti di sicurezza.
La pld, letta insieme al contesto normativo, rende molto rischioso un approccio “rilascio e poi si vede”. La mancata fornitura di aggiornamenti di sicurezza per vulnerabilità note può essere considerata essa stessa un difetto. E un aggiornamento che introduce un problema può essere visto come una modifica sostanziale, con effetti anche sui termini.
La responsabilità base dura 10 anni, e per lesioni personali latenti può arrivare a 25. Quando leggo questi numeri mi chiedo sempre se abbiamo davvero la cultura della conservazione delle evidenze per un orizzonte simile. Perché non basta aver fatto le cose bene, bisogna poterlo dimostrare.
Qui entra la tracciabilità.
Sapere cosa conteneva una certa versione in una certa data. Quali dipendenze. Quali vulnerabilità note. Quali test sono stati eseguiti. Chi ha approvato. Cosa è stato deciso e perché.
L’sbom (software bill of materials) diventa centrale. Anche perché il cyber resilience act lo rende obbligatorio in molti casi, e la pipeline ci/cd diventa di fatto un’infrastruttura di compliance: generazione automatica sbom (cyclonedx o spdx), scanning vulnerabilità, audit trail dei deploy, conservazione degli artefatti.
E c’è un dettaglio che sembra banale finché non lo vivi: anche la decisione di non rilasciare una patch è una decisione. Se oggi scegli di rimandare una correzione per ragioni sensate, probabilmente va bene. Ma tra cinque anni potresti dover spiegare perché era sensato. Meglio avere quella spiegazione scritta quando la memoria è fresca.
Chi sviluppa: documentare non è burocrazia, è memoria difendibile #
Per gli sviluppatori, la pld non chiede magie. Non ti dice “scrivi codice perfetto”, cosa che non esiste. Ti chiede, in sostanza, di rendere ricostruibile il percorso.
Test automatici che dimostrano il comportamento atteso. Code review tracciate. Scan di sicurezza integrati. Commit message che non siano “fix”. Ticket che raccontano il contesto.
Sono cose che molti team fanno già, magari in modo irregolare. La differenza è che da “buona pratica” diventano anche un pezzo di tutela.
E qui il collegamento con il cyber resilience act è diretto: se non sei conforme a requisiti come secure by design, gestione delle vulnerabilità e sbom, quella non conformità può rafforzare una contestazione di difettosità in ottica pld. Le norme, insomma, non vivono più in compartimenti stagni.
Il mito del b2b come zona franca #
Capisco la tentazione: “noi vendiamo solo ad aziende, quindi non ci riguarda”.
Però basta guardare un attimo gli utenti reali.
Software per la pa: cittadini. Sistemi hr: dipendenti. E-learning: studenti. Parcheggi: automobilisti. Sanità: pazienti. In tutti questi casi il cliente è un’organizzazione, ma l’impatto ricade su persone fisiche.
In più, la pld ragiona anche per componenti. Se fornisci un modulo, un’api, un microservizio che finisce dentro il prodotto di un altro, puoi essere considerato fabbricante del componente.
E poi c’è l’estensione dei danni risarcibili: la distruzione o corruzione di dati non usati a fini professionali, senza soglia minima e senza tetto massimo. È un passaggio che molte aziende non hanno ancora metabolizzato.
Open source: protetto, ma non è una scappatoia #
La direttiva esclude il software open source sviluppato o fornito al di fuori di un’attività commerciale. Ma se c’è un corrispettivo, anche sotto forma di dati personali, il discorso cambia.
E soprattutto, se integri open source dentro un prodotto commerciale, la responsabilità per eventuali difetti ricade su chi integra e mette sul mercato.
Questo sposta il baricentro: non è più solo un tema di compliance licenze. Diventa gestione del rischio tecnico e legale. Scelta delle dipendenze, processi di vetting, vulnerability management serio, e di nuovo sbom.
La pld non è sola: un ecosistema che si incastra #
La sensazione, guardando il quadro europeo, è che l’ue stia costruendo un’idea precisa di “software come prodotto” e la stia sostenendo da più lati.
La pld si incastra con il cyber resilience act (cybersecurity by design, sbom, gestione vulnerabilità), con l’ai act (che rende i fornitori ai fabbricanti anche ai fini pld), con il gdpr (data breach e danni), con nis2, con il gpsr, con la representative actions directive per le azioni collettive, e persino con l’european accessibility act.
Il punto non è ricordare tutte le sigle. Il punto è che una lacuna in un’area può propagarsi e rafforzare un contenzioso in un’altra. La compliance diventa un sistema.
Il recepimento italiano: una scelta da tenere d’occhio #
L’italia deve recepire la pld entro il 9 dicembre 2026. Essendo una direttiva di massima armonizzazione, non ci sono grandi spazi per “interpretazioni creative”. Però un margine importante c’è: la difesa dello stato dell’arte.
In sostanza, lo stato può decidere se mantenere l’idea per cui il fabbricante non risponde se il difetto non era riconoscibile con le conoscenze disponibili al momento della messa in servizio. Oppure può eliminarla.
Non è un dettaglio, e vale la pena monitorarlo. Perché cambia il profilo di rischio, specialmente su software complesso e su scenari ai.
Non solo rischi: la parte che può diventare un vantaggio #
Se la leggi tutta in modalità “catastrofe”, la pld sembra solo un costo. Più documentazione, più processi, più assicurazioni, più discussioni interne.
Però c’è un’altra lettura, e forse è quella più utile se devi prendere decisioni adesso.
La pld crea un terreno di gioco dove qualità, sicurezza e trasparenza della supply chain diventano vantaggi competitivi misurabili. Non più “fidati di noi”, ma “abbiamo processi e prove che reggono a una richiesta formale, e se serve a un tribunale”.
Per le software house, arrivare compliant prima della deadline può diventare un argomento forte con enterprise e pa. Per consulenza e system integration, si apre una domanda enorme di competenze che oggi, almeno nel tessuto delle pmi italiane, non è così diffusa. Per chi fa prodotto, è un incentivo a investire in cose che, alla lunga, migliorano davvero il software.
Una conclusione senza trionfalismi #
Per quarant’anni abbiamo potuto pensare al software come a qualcosa di speciale. Più flessibile, più aggiornabile, più perdonabile.
La pld dice che questa eccezionalità è finita. Il software è un prodotto, con responsabilità simili a quelle di un macchinario, di un dispositivo medico, di un’auto.
Non riguarda solo chi scrive codice. Riguarda roadmap e trade-off. Riguarda contratti e promesse commerciali. Riguarda release e supporto, e persino l’end-of-life.
La cosa che mi sembra più sensata, oggi, è spostare la domanda da “come ci proteggiamo” a “come rendiamo il nostro modo di lavorare dimostrabile”. Perché prepararsi non è solo mettere pezze legali. È fare meglio il proprio lavoro, con più memoria, più tracciabilità e meno fiducia cieca nel fatto che tanto “poi si sistema”.
La domanda non è se prepararsi. È quanto velocemente.
fonti principali: direttiva (ue) 2024/2853; cyber resilience act (regolamento ue 2024/2847); analisi di reed smith, iba, fladgate, taylor wessing, clyde & co, dla piper, hogan lovells, iclg, covington.