La responsabilità per danno da prodotto difettoso è stata a lungo costruita intorno a un modello industriale nel quale il prodotto coincideva, nella maggior parte dei casi, con un bene materiale. La trasformazione digitale ha reso questa impostazione sempre meno aderente alla realtà: il software governa dispositivi, processi produttivi e servizi; i sistemi di intelligenza artificiale elaborano informazioni e incidono su decisioni che possono avere conseguenze concrete sulle persone. Il fatto che il rischio si origini in un programma o in un modello algoritmico, anziché in un componente fisico, non lo rende meno meritevole di tutela.
Indice degli argomenti
Responsabilità da prodotto per software e IA: il nuovo quadro UE
È su questo terreno che interviene la direttiva (UE) 2024/2853, destinata a sostituire la direttiva 85/374/CEE. La riforma estende la nozione di prodotto al software e aggiorna le regole sulla difettosità, sulla responsabilità degli operatori della filiera e sull’accertamento probatorio. In Italia, il Consiglio dei ministri ha approvato in via definitiva il 28 ottobre 2026 lo schema di decreto legislativo di recepimento, Atto del Governo n. 434, in attesa dei successivi passaggi formali di emanazione e pubblicazione.
Il termine per il recepimento è il 9 dicembre 2026; la direttiva si applicherà ai prodotti immessi sul mercato o messi in servizio dopo l’8 dicembre. Il dato non esaurisce la portata dell’intervento: il punto è comprendere come cambiano i criteri con cui il diritto civile individua il rischio tecnologico e ne distribuisce le conseguenze.
Software e IA entrano nella nuova nozione di prodotto
La disciplina europea del 1985, recepita in Italia prima con il d.P.R. n. 224/1988 e poi negli articoli 114 e seguenti del Codice del consumo, aveva come riferimento il prodotto materiale. Il software poteva già essere fonte di responsabilità secondo le regole contrattuali o extracontrattuali, ma la sua riconduzione al regime speciale del prodotto difettoso non era priva di incertezze. La nuova direttiva supera il problema includendo espressamente il software nella definizione di prodotto, a prescindere dalle modalità con cui viene fornito o utilizzato.
Cloud, SaaS e sistemi di intelligenza artificiale
La regola vale, quindi, per il programma incorporato in un dispositivo, per quello distribuito tramite rete e per le applicazioni accessibili in cloud o secondo il modello Software as a Service. La qualificazione non dipende dal fatto che l’utente scarichi una copia del programma o ne utilizzi soltanto le funzionalità attraverso un servizio remoto. Anche i sistemi di intelligenza artificiale rientrano nel perimetro: il considerando 13 chiarisce che il software, compresi i sistemi di IA, può essere immesso sul mercato come prodotto autonomo o integrato in un altro prodotto.
Servizi digitali correlati e software open source
La direttiva considera inoltre i servizi digitali correlati, quando sono integrati o interconnessi con un prodotto in modo tale che, in loro assenza, questo non possa svolgere una o più delle proprie funzioni. In tale ipotesi il servizio può assumere la qualità di componente. Non ne deriva, però, che qualsiasi servizio digitale, attività di hosting o prestazione online diventi un prodotto: restano fuori i servizi autonomi che non presentano il necessario legame funzionale. È escluso anche il software libero e open source sviluppato o fornito nell’ambito di un’attività non commerciale, ferma la possibile responsabilità del fabbricante che integri quel codice in un prodotto commercializzato.
Quando l’errore di software e IA diventa un difetto
L’inclusione del software non significa che ogni errore di un sistema di IA integri automaticamente un difetto ai sensi della direttiva. L’articolo 7 mantiene come criterio centrale la sicurezza che il consumatore può legittimamente attendersi, insieme a quella prescritta dal diritto dell’Unione o nazionale. La valutazione deve essere compiuta considerando tutte le circostanze pertinenti, tra cui la presentazione del prodotto, le sue caratteristiche, le istruzioni, l’uso ragionevolmente prevedibile e gli effetti dell’interconnessione con altri prodotti.
Apprendimento, aggiornamenti e cybersicurezza
Per i sistemi di IA assumono particolare rilievo due aspetti. Il primo è la capacità del prodotto di continuare ad apprendere o acquisire nuove funzionalità dopo l’immissione sul mercato o la messa in servizio. Il secondo è il controllo che il fabbricante conserva sul prodotto nel tempo. La sicurezza, dunque, non può essere valutata soltanto sulla base della versione iniziale: occorre considerare anche l’evoluzione del software, gli aggiornamenti e le vulnerabilità che emergano successivamente, quando ricadano nella sfera di controllo del produttore. La direttiva richiama inoltre i requisiti di cybersicurezza pertinenti alla sicurezza del prodotto.
Perché un output errato non basta
Il punto va tenuto distinto dalla semplice inesattezza dell’output. Una risposta errata, un’allucinazione o una raccomandazione inopportuna non bastano, da sole, a dimostrare la difettosità. Occorre verificare la funzione per la quale il sistema è stato progettato, le caratteristiche dichiarate, il contesto di utilizzo e il livello di sicurezza ragionevolmente esigibile. Un sistema destinato a fornire suggerimenti generali non presenta necessariamente gli stessi requisiti di uno strumento impiegato per supportare diagnosi mediche o governare macchinari. L’errore diventa rilevante ai fini della responsabilità da prodotto quando rivela una carenza di sicurezza rispetto a ciò che poteva legittimamente attendersi dall’utilizzatore.
La responsabilità da prodotto nella filiera di software e IA
La filiera di un sistema di IA può coinvolgere sviluppatori del modello, fornitori dell’infrastruttura, integratori, distributori e utilizzatori professionali. La direttiva individua, oltre al fabbricante del prodotto, il fabbricante del componente difettoso e, alle condizioni previste, importatore, rappresentante autorizzato, prestatore di servizi di logistica e distributore.
Distributori e piattaforme online
La responsabilità del distributore opera in via sussidiaria quando non sia possibile identificare un operatore economico stabilito nell’Unione e non vengano fornite, nei termini previsti, le informazioni necessarie a individuarlo. Anche una piattaforma online può essere trattata come distributore, ma non per il solo fatto di ospitare un’offerta. Occorre che consenta ai consumatori di concludere contratti a distanza e presenti il prodotto o organizzi la transazione in modo da indurre il consumatore medio a ritenerlo fornito dalla piattaforma stessa o da un operatore che agisce sotto la sua autorità o il suo controllo, secondo l’articolo 6, paragrafo 3, del Digital Services Act. La responsabilità segue poi il meccanismo sussidiario previsto per il distributore.
Provider e deployer secondo l’AI Act
Va poi distinta la figura del fabbricante da quelle di provider e deployer utilizzate dall’AI Act. Il provider sviluppa o fa sviluppare il sistema e lo immette sul mercato o lo mette in servizio con il proprio nome o marchio; il deployer lo utilizza sotto la propria autorità nell’ambito di un’attività professionale. Le categorie hanno finalità differenti e non coincidono necessariamente. Il provider potrà spesso assumere il ruolo di fabbricante del software, ma il deployer non diventa responsabile del difetto per il solo fatto di utilizzare il sistema.
Modifiche sostanziali e controllo del rischio
La condotta del deployer può tuttavia rilevare secondo le regole generali se il danno dipenda da configurazione inadeguata, uso non conforme alle istruzioni o omessa supervisione. Se l’utilizzatore modifica sostanzialmente il prodotto al di fuori del controllo del fabbricante, la modifica può inoltre incidere sull’individuazione del responsabile, nei casi previsti dalla direttiva. Occorre dunque guardare al ruolo effettivo di ciascun operatore e alla sua possibilità concreta di prevenire il danno.
Come si prova il difetto di software e IA
Nei contenziosi che riguardano software e IA, il problema probatorio è spesso più complesso dell’individuazione del danno. Il funzionamento del modello, i dati utilizzati, le versioni del sistema e le registrazioni degli eventi possono trovarsi nella disponibilità esclusiva del produttore o del fornitore. Pretendere che il danneggiato ricostruisca autonomamente questi elementi rischierebbe di rendere eccessivamente difficile l’esercizio dell’azione.
Esibizione delle prove e tutela dei segreti
Gli articoli 9 e 10 intervengono su questo squilibrio. Il danneggiato deve provare difetto, danno e nesso causale, ma, se ha fornito elementi sufficienti a rendere plausibile la domanda, può chiedere al giudice di ordinare l’esibizione delle prove pertinenti. L’ordine deve essere necessario e proporzionato e deve salvaguardare segreti commerciali e informazioni riservate.
Le presunzioni su difetto e nesso causale
La direttiva introduce inoltre presunzioni relative: il difetto può presumersi in caso di mancata esibizione, violazione di requisiti obbligatori di sicurezza pertinenti al rischio verificatosi o malfunzionamento evidente durante un uso normale o ragionevolmente prevedibile. Il nesso causale può essere presunto quando il difetto sia accertato e il danno sia normalmente compatibile con esso.
Presunzioni di difetto o causalità sono ammesse anche quando la complessità tecnica o scientifica renda la prova eccessivamente difficile, purché il danneggiato dimostri la probabilità dei relativi presupposti.
L’opacità algoritmica può quindi rilevare, ma non determina un’inversione automatica dell’onere della prova. La direttiva riequilibra l’asimmetria informativa: il danneggiato deve offrire una base fattuale credibile, ma il produttore non può beneficiare della disponibilità esclusiva delle informazioni tecniche.
Quali danni copre la responsabilità da prodotto digitale
Il regime riguarda i danni subiti da persone fisiche: morte o lesioni personali, compresi i danni psicologici riconosciuti da un punto di vista medico; danneggiamento o distruzione di beni, salvo le esclusioni previste per il prodotto difettoso e per i beni impiegati esclusivamente a fini professionali; distruzione o corruzione di dati non utilizzati a fini professionali.
Gli altri rimedi tra Codice civile e GDPR
Non ogni perdita economica o reputazionale causata da un output algoritmico rientra, dunque, nella responsabilità da prodotto. Restano però salvi gli altri rimedi: la direttiva non pregiudica l’applicazione del GDPR né le norme nazionali sulla responsabilità contrattuale ed extracontrattuale.
Il rapporto tra fornitore e impresa utilizzatrice può ricadere nell’articolo 1218 c.c. in caso di inadempimento; nei confronti dei terzi può venire in rilievo l’articolo 2043 c.c. Una violazione del GDPR può fondare l’autonoma domanda risarcitoria dell’articolo 82. La responsabilità da prodotto si affianca a questi rimedi, senza assorbirli: presupposti e condizioni di ciascuna azione vanno verificati separatamente.
Contratti e governance per i rischi di software e IA
La riforma rende poco utile una contrattualistica fondata su generiche esclusioni di responsabilità. Nei rapporti tra provider, integratori e deployer occorre chiarire chi controlla gli aggiornamenti, verifica i dati, gestisce le vulnerabilità, conserva i log e interviene in caso di anomalia. La tracciabilità delle versioni e degli incidenti può essere decisiva per ricostruire il software effettivamente utilizzato.
Manleve, solidarietà e regresso tra operatori
Manleve e clausole di regresso possono distribuire i costi tra gli operatori, ma non comprimere i diritti del danneggiato. Quando più operatori sono responsabili del medesimo danno, la solidarietà consente alla persona lesa di agire nei confronti di ciascuno di essi; nei rapporti interni, il regresso potrà tener conto del contributo causale e delle rispettive responsabilità. Restano fermi i limiti inderogabili, tra cui l’articolo 1229 c.c. e le norme a tutela dei consumatori.
Prevenzione e documentazione prima del contenzioso
La direttiva (UE) 2024/2853 non trasforma, in definitiva, ogni malfunzionamento dell’intelligenza artificiale in un illecito del produttore. Compie un passaggio diverso e più rilevante: riconosce che il software può essere un prodotto e che la sua sicurezza deve essere valutata anche quando il sistema evolve, opera a distanza o dipende da componenti e servizi interconnessi. Per le imprese, la responsabilità non si governa soltanto con una clausola contrattuale o dopo il verificarsi del danno. Richiede di conoscere la filiera, attribuire compiti verificabili e mantenere traccia delle decisioni tecniche. È in questa capacità di prevenzione e documentazione, prima ancora che nel contenzioso, che si misurerà l’impatto concreto della riforma.
Partecipa alla community