Chi sviluppa software, o costruisce soluzioni di IA per i clienti, fino a oggi ha ragionato sulla responsabilità soprattutto in termini di contratto: garanzie, livelli di servizio, limitazioni di responsabilità. Dal 9 dicembre 2026 non basta più. La direttiva (UE) 2024/2853 sulla responsabilità per danno da prodotti difettosi, che sostituisce la direttiva 85/374/CEE in vigore da quasi quarant'anni, qualifica espressamente il software, sistemi di IA compresi, come «prodotto». Significa che chi lo produce risponde dei danni causati da un difetto senza che il danneggiato debba provare la sua colpa, e senza che una clausola contrattuale possa escluderlo.
Cosa cambia e da quando
La direttiva (pubblicata in Gazzetta ufficiale UE il 18 novembre 2024) va recepita entro il 9 dicembre 2026 e si applica ai prodotti immessi sul mercato o messi in servizio dopo quella data; per quelli precedenti resta il regime attuale. In Italia la delega è nella legge di delegazione europea (legge 17 marzo 2026, n. 36). Il 4 agosto 2026 il Consiglio dei ministri ha approvato in esame preliminare lo schema di decreto, trasmesso alle Camere come Atto del Governo n. 434: riscrive il Titolo II della Parte IV del Codice del consumo (artt. 114-127, più un nuovo art. 126-bis sulla pubblicazione delle sentenze). A fine ottobre 2026 il decreto non risulta ancora approvato in via definitiva: i contenuti essenziali, però, sono fissati dalla direttiva.
Le novità che interessano chi lavora con software e IA:
| Tema | Regime attuale | Dal 9 dicembre 2026 |
|---|---|---|
| Software e IA | Non espressamente inclusi | Prodotti, comunque forniti (installati, in cloud, SaaS) |
| Danni a cose | Franchigia di 387 euro | Nessuna franchigia, nessun massimale |
| Dati | Non coperti | Distruzione o corruzione di dati non usati a fini professionali |
| Danno psicologico | Non espressamente previsto | Coperto se medicalmente riconosciuto |
| Prova | A carico del danneggiato | Esibizione delle prove e presunzioni di difetto e nesso causale |
Resta invece ferma una regola: il risarcimento spetta solo alle persone fisiche. I beni usati esclusivamente per lavoro e le perdite puramente economiche restano fuori.
Chi risponde: sviluppatore, integratore, chi modifica
L'art. 8 costruisce una catena di soggetti responsabili. In prima linea c'è il fabbricante, cioè chi sviluppa il software o il sistema di IA e lo immette sul mercato con il proprio nome; insieme a lui, il fabbricante del componente difettoso integrato nel prodotto. Se il fabbricante è fuori dall'UE rispondono l'importatore o il rappresentante autorizzato e, in mancanza, il fornitore di servizi di logistica; distributori e piattaforme online rispondono in via residuale, se non indicano entro un mese chi è il responsabile.
Due casi riguardano da vicino le PMI che costruiscono soluzioni di IA:
- Integrare è produrre. Chi assembla un prodotto usando un modello di terzi, librerie o componenti risponde del prodotto finito, e risponde anche dell'open source che vi integra: l'esclusione dell'art. 2, par. 2, vale solo per il software libero fornito fuori da un'attività commerciale.
- Modificare in modo sostanziale è produrre. Chi modifica un prodotto fuori dal controllo del fabbricante originale, in un modo non previsto dalla sua valutazione dei rischi, e lo rimette sul mercato, diventa a sua volta fabbricante. È lo stesso ragionamento che l'AI Act applica a chi personalizza un modello o un sistema di altri.
Quando un software è «difettoso»
Il difetto riguarda la sicurezza, non l'utilità: un prodotto è difettoso se non offre la sicurezza che una persona può legittimamente attendersi o che il diritto UE o nazionale richiede. L'art. 7 elenca le circostanze da considerare, e alcune sono pensate proprio per il software:
- la capacità del prodotto di continuare ad apprendere o acquisire nuove funzioni dopo l'immissione sul mercato;
- gli effetti prevedibili dell'interconnessione con altri prodotti;
- i requisiti di cibersicurezza pertinenti, come quelli del Cyber Resilience Act;
- i richiami e gli altri interventi delle autorità.
Il punto più delicato è il tempo. Per il software il fabbricante non può difendersi dicendo che il difetto non esisteva al momento della vendita, se il difetto dipende da un aggiornamento, da un servizio correlato o dalla mancata fornitura di un aggiornamento di sicurezza sotto il suo controllo (art. 11, par. 2). La direttiva non impone di aggiornare, ma chi aggiorna, o smette di farlo, ne porta le conseguenze. Una modifica sostanziale, inoltre, fa ripartire il termine di dieci anni entro cui si può agire (art. 17); la prescrizione resta di tre anni dalla conoscenza del danno, del difetto e del responsabile (art. 16).
Il processo: prove da esibire e presunzioni
Il vero cambio di passo è processuale. Se il danneggiato presenta elementi sufficienti a rendere plausibile la sua domanda, il giudice può ordinare al convenuto di esibire le prove pertinenti (art. 9), con tutele per i segreti commerciali. Se il convenuto non lo fa, il difetto si presume. Si presume anche quando il prodotto non rispetta i requisiti obbligatori di sicurezza previsti per quel rischio, o quando il malfunzionamento è evidente durante un uso ragionevolmente prevedibile (art. 10). Il nesso causale si presume se il danno è tipicamente coerente con il difetto; e quando la complessità tecnica, tipica dei sistemi di IA, rende la prova eccessivamente difficile, il giudice può presumere difetto, nesso o entrambi se il danneggiato ne dimostra la probabilità. Sono presunzioni relative: si superano con la prova contraria, cioè con la documentazione.
È lo stesso filo che lega il D.Lgs. 160/2026, che sul piano nazionale regola i danni causati nell'uso dei sistemi di IA. Le due strade sono cumulabili: quella della direttiva non richiede di provare né la colpa né una violazione dell'AI Act. La proposta di direttiva europea sulla responsabilità extracontrattuale per l'IA, invece, è stata ritirata dalla Commissione nel 2025.
Cosa fare prima del 9 dicembre
- Censire i prodotti. Quali software e soluzioni di IA immetterete sul mercato, o modificherete in modo sostanziale, dopo il 9 dicembre 2026, e chi ne sono gli utilizzatori finali (persone fisiche incluse).
- Mappare i componenti. Modelli di terzi, librerie open source, servizi cloud correlati: per ognuno, chi è il fabbricante e che regresso avete verso di lui.
- Documentare la sicurezza. Valutazione dei rischi, test, gestione delle vulnerabilità, log e cronologia delle versioni: è il materiale che un giudice può ordinare di esibire e che serve a vincere le presunzioni.
- Definire la politica degli aggiornamenti. Per quanto tempo fornite aggiornamenti di sicurezza, come li distribuite, cosa succede se il cliente non li installa.
- Rivedere i contratti di filiera. Le clausole di esonero non valgono verso il danneggiato, ma regolano il regresso tra imprese: con fornitori e clienti, e con le micro e piccole imprese di cui integrate componenti software (art. 12, par. 2).
- Verificare l'assicurazione. Controllate che la polizza RC prodotti copra espressamente software, dati e danno psicologico.
Da dove partire
Per chi sviluppa soluzioni di IA, la nuova direttiva trasforma la documentazione tecnica da adempimento a strumento di difesa. Il primo passo è capire quali dei vostri prodotti ricadono nel nuovo regime e se la documentazione che avete oggi reggerebbe a un ordine di esibizione. Un gap assessment indipendente incrocia prodotti, componenti, contratti e documentazione con gli obblighi della direttiva, dell'AI Act e del Cyber Resilience Act, e indica cosa sistemare prima del 9 dicembre.