Un cambio epocale che arriva in punta di piedi, ma che cambierà tutto per chi sviluppa, vende o usa software — inclusa l’intelligenza artificiale.
Permettetemi di partire da un ricordo.
Fine anni Novanta. Ero tra i pionieri dell’Internet nella mia provincia, e il software che si installava sui server arrivava in una scatola con dentro un manuale e un foglio con scritto, più o meno, questo: “Il prodotto viene fornito ‘così com’è’. Il produttore non garantisce che funzioni, che sia privo di errori, che faccia quello che dice. Usatelo a vostro rischio.”
Quella clausola — il famoso “AS IS” — era la norma. Era il contratto sociale implicito del software: tu mi paghi, io ti do il codice, poi arrangiati. Se si rompe, non sono affari miei.
Per quarant’anni, più o meno, è andata così.
Il 9 dicembre 2026 quella storia finisce.
1985: quando il software era ancora un alieno
Per capire quanto sia rivoluzionario quello che sta per succedere, bisogna tornare al 1985. Quell’anno l’Unione Europea adottò la Direttiva 85/374/CEE sulla responsabilità per danno da prodotti difettosi. Una norma importante, pensata per tutelare i consumatori da frigoriferi difettosi, automobili con freni che cedono, farmaci mal prodotti.
Il software? Non pervenuto. Non esisteva come problema giuridico rilevante. MS-DOS era appena nato. Internet era roba da accademici. L’idea che un programma potesse causare un “danno” risarcibile sembrava fantascienza — e in un certo senso lo era.
Nei decenni successivi, mentre il software conquistava silenziosamente ogni angolo della nostra vita — dai bancomat agli aerei, dai sistemi ospedalieri alle auto — la norma del 1985 è rimasta lì, immobile, come un fossile.
Il risultato? Un paradosso clamoroso. Se compravi un’automobile difettosa che ti causava un danno, il produttore rispondeva. Se compravi un software difettoso che mandava in crash il tuo sistema gestionale causandoti perdite per milioni, eri solo. Il tuo unico strumento era il contratto che avevi firmato — e quasi sempre quel contratto ti diceva: “AS IS, buona fortuna.”
La grande eccezione: il software come “opera dell’ingegno”
Come si è giustificata per decenni questa anomalia? Con una distinzione concettuale: il software non è un prodotto, è un’opera dell’ingegno. Come un romanzo, una sinfonia, un dipinto. Il pittore non garantisce che il suo quadro ti faccia felice. Lo scrittore non risponde se il suo libro ti annoia. Perché il programmatore dovrebbe rispondere se il suo codice ha un bug?
Questa analogia, per quanto affascinante sul piano filosofico, ha prodotto conseguenze pratiche assurde:
- Licenze software con clausole di limitazione di responsabilità talmente ampie da sembrare scritte dagli avvocati di Sauron
- Software critico — quello che gestisce infrastrutture, ospedali, dati personali — senza nessun obbligo di qualità minima garantita
- Produttori liberi di rilasciare aggiornamenti (o di non rilasciarli) senza alcuna accountability reale
- Consumatori e imprese che, in caso di danno, si trovavano soli davanti a contratti incomprensibili
Nel frattempo, il software è diventato tutto. E l’intelligenza artificiale ha reso il problema ancora più acuto: chi risponde quando un algoritmo prende una decisione sbagliata che causa un danno reale?
La svolta: la Direttiva (UE) 2024/2853
Il 18 novembre 2024, nella Gazzetta Ufficiale dell’Unione Europea, è apparso un testo che pochi hanno notato ma che cambierà le regole del gioco: la Direttiva 2024/2853, nota come Product Liability Directive (PLD 2024).
Sostituisce la vecchia direttiva del 1985. E risolve l’anomalia storica con una formulazione netta, senza margini di ambiguità:
“Prodotto” include […] il software.
Punto. Fine della storia. Fine dell’era “AS IS”.
Dal 9 dicembre 2026 — data entro cui gli Stati membri devono recepire la direttiva — il software immesso sul mercato è soggetto allo stesso regime di responsabilità oggettiva di qualsiasi altro prodotto. Se è difettoso e causa un danno, il produttore risponde. Senza necessità di dimostrare dolo o negligenza. Senza schermarsi dietro un contratto scritto in corpo 6 su 47 pagine.
Cosa cambia, nel concreto
La PLD 2024 non è solo una riformulazione semantica. Porta con sé cambiamenti strutturali che impattano tutta la filiera del software.
Il software è prodotto indipendentemente da come viene erogato
Non importa se il software gira sul dispositivo dell’utente, in cloud, come SaaS, come API. La forma di distribuzione non modifica la natura giuridica. Questo significa che anche i modelli in abbonamento — dal gestionale in cloud all’agente AI — rientrano nel perimetro.
L’unica eccezione? Il software libero e open source sviluppato al di fuori di un’attività commerciale. Se lo metti a pagamento o lo scambi con dati personali, però, rientra immediatamente nel perimetro.
I danni risarcibili si ampliano
La nuova direttiva estende il concetto di danno risarcibile includendo esplicitamente la perdita di dati e il danno psicologico. Non solo danni fisici o patrimoniali diretti. Questo apre scenari del tutto nuovi nel contenzioso digitale.
L’onere della prova si alleggerisce
Uno dei problemi storici delle cause contro i produttori di software era la difficoltà per il danneggiato di dimostrare il difetto e il nesso causale. La PLD 2024 introduce meccanismi che alleggeriscono questo onere. In certi casi è prevista una presunzione di difettosità: se il danno è del tipo che tipicamente deriva da quel tipo di difetto, il giudice può presumere il nesso causale.
AI Act + PLD: il binomio che spaventa i vendor
Qui si apre lo scenario più interessante — e più insidioso. La PLD 2024 introduce la responsabilità per i sistemi AI come per qualsiasi altro software. Ma non definisce da sola lo standard di sicurezza: rinvia all’AI Act.
Il cortocircuito è questo: se un sistema di intelligenza artificiale non è conforme all’AI Act, quella non conformità può diventare automaticamente prova di difettosità ai sensi della PLD. Compliance normativa e responsabilità civile si intrecciano in modo diretto. Non adempiere all’AI Act non è più solo un problema regolatorio — è un rischio legale concreto, con risarcimenti potenzialmente molto significativi.
Chi deve preoccuparsi (e non sta dormendo sereno)
Facciamo un po’ di chiarezza su chi è esposto.
I produttori di software — grandi vendor come Microsoft, SAP, Salesforce, ma anche le migliaia di software house europee — dovranno ripensare i propri processi di sviluppo, test e rilascio. Il concetto di “quality by design” smette di essere un’aspirazione e diventa un requisito legale.
I system integrator e i partner — come i partner Microsoft che personalizzano soluzioni Copilot, costruiscono agenti AI con Copilot Studio, integrano Azure OpenAI in applicazioni verticali — si trovano in una posizione delicata. La customizzazione di un prodotto di terze parti può spostare la responsabilità, in tutto o in parte, sul soggetto che ha effettuato la personalizzazione.
I distributori e i rivenditori sono anch’essi nel perimetro, seppur con responsabilità attenuata.
Le imprese clienti che adottano soluzioni software critiche — gestionali, sistemi di controllo, strumenti AI per il processo decisionale — devono comprendere che il quadro contrattuale cambia. Le clausole “AS IS” e le limitazioni di responsabilità non spariranno dall’oggi al domani, ma la loro efficacia legale verrà messa alla prova come mai prima.
Cosa fare, ora (e non tra 18 mesi)
Il 9 dicembre 2026 sembra lontano. Non lo è. E le aziende che si faranno trovare impreparate pagheranno il conto — in senso letterale.
Per chi sviluppa software:
- Rivedere i processi di QA e release management con un occhio alla documentazione delle scelte progettuali (servirà in caso di contenzioso)
- Implementare policy strutturate per la gestione delle vulnerabilità e il rilascio tempestivo di aggiornamenti di sicurezza
- Rivedere le condizioni contrattuali, sapendo che le clausole di esonero totale di responsabilità avranno vita sempre più difficile
Per chi vende e integra software (partner, system integrator):
- Mappare con precisione la catena di responsabilità: cosa è del vendor, cosa è del partner, cosa è della customizzazione
- Rivedere i contratti con i clienti alla luce del nuovo scenario
- Valutare coperture assicurative specifiche per product liability digitale — un mercato ancora acerbo in Italia, ma destinato a crescere rapidamente
Per le imprese clienti:
- Comprendere che avrete più tutele — ma anche più responsabilità nell’adottare software conforme
- Verificare che i vostri fornitori stiano effettivamente preparandosi al cambio normativo
- Inserire il tema PLD 2024 nelle valutazioni di vendor selection
Una riflessione finale: ne valeva la pena aspettare quarant’anni?
Sì e no.
Sì, perché una regolamentazione prematura avrebbe probabilmente frenato l’innovazione in un settore che, lasciato libero, ha prodotto la più grande trasformazione tecnologica della storia umana. Internet, il cloud, gli smartphone, l’AI generativa: tutto questo è nato in un ecosistema dove sbagliare era permesso, dove si iterava veloce, dove il codice poteva essere imperfetto.
No, perché quarant’anni di impunità hanno anche prodotto una cultura diffusa di trascuratezza: software critico rilasciato con bug noti, aggiornamenti di sicurezza rimandati per motivi commerciali, sistemi AI messi in produzione senza adeguata valutazione del rischio.
La PLD 2024 non è una punizione. È una maturazione. È il momento in cui l’industria del software viene trattata come quello che è diventata: un’infrastruttura essenziale della vita moderna, con le responsabilità che ne derivano.
Quarant’anni fa il software era un alieno incompreso. Oggi è l’aria che respiriamo. Era ora che qualcuno cominciasse a chiedersi cosa succede quando quell’aria è inquinata.
Il 9 dicembre 2026, l’Europa dà la risposta.
Hai domande su come la PLD 2024 impatta sulla tua strategia di adozione del software o delle soluzioni AI? Scrivimi — ne parliamo volentieri.
Rispondi