Il D.Lgs. 160/2026 adegua le norme italiane all’AI Act ed entra in vigore il 30 settembre 2026. Nelle cause per un danno legato a un sistema di intelligenza artificiale il giudice può far esibire le prove anche al terzo che ne dispone, e se è violato un obbligo dell’AI Act il nesso di causalità è presunto, salvo prova contraria.
Il nome completo è decreto legislativo 9 settembre 2026, n. 160, pubblicato nella Gazzetta Ufficiale il 15 settembre; l’AI Act è il regolamento (UE) 2024/1689. Il titolo nomina tre materie: l’uso dell’IA nell’attività di polizia, la responsabilità civile e quella penale. Le ultime due riguardano chi ha messo una funzione di IA nel software dell’azienda, che sia un modello che classifica i documenti in arrivo o un assistente che risponde ai clienti sul portale.
Il parere sul caso concreto lo dà un legale. Qui ci sono le domande da portargli, e quelle da portare al fornitore prima di firmare o rinnovare un contratto.
Da quando si applica: dal 30 settembre 2026, e l’alto rischio slitta al 2027 e al 2028
Le regole che valgono per qualunque sistema di IA si applicano dal 30 settembre 2026; quelle che dipendono dagli obblighi dell’AI Act seguono il calendario europeo, che nel frattempo è cambiato.
L’articolo 16 dice che le regole sull’accesso alle prove dell’articolo 17 si applicano alle azioni di risarcimento del danno, sia contrattuale sia extracontrattuale, cagionato nell’utilizzo di un sistema di intelligenza artificiale. Nessuna restrizione all’alto rischio.
Lo stesso articolo, al comma 2, limita gli articoli 18 e 19 ai casi in cui il danno deriva dalla violazione di uno o più obblighi del regolamento (UE) 2024/1689. Ed è qui che entra la seconda data. Il regolamento (UE) 2026/1744, il cosiddetto Digital Omnibus sull’IA, pubblicato nella Gazzetta Ufficiale dell’Unione europea il 24 luglio 2026, ha fissato nuove scadenze per gli obblighi dell’AI Act sui sistemi ad alto rischio: 2 dicembre 2027 per i sistemi autonomi, 2 agosto 2028 per quelli integrati nei prodotti.
Fino a quelle date, quindi, gli obblighi che il regolamento riserva ai sistemi ad alto rischio non si applicano ancora. Che cosa questo voglia dire per la presunzione dell’articolo 18 è una domanda per il legale. L’accesso alle prove invece vale da subito, per tutti.
La conseguenza pratica è una: un contratto firmato oggi con un fornitore, per un software che l’azienda userà per anni, può essere ancora in vigore nel dicembre 2027. Le clausole che servono allora si scrivono adesso.
Prima domanda: è un sistema di intelligenza artificiale?
Lo è se risponde alla definizione dell’articolo 3 dell’AI Act, a cui l’articolo 11 del decreto rimanda. È il primo testo da leggere, e viene prima di ogni discussione sul rischio.
Un motore di raccomandazione su un e-commerce B2B, o un classificatore che smista le richieste di assistenza, entra nel perimetro se risponde a quelle definizioni. La risposta va chiesta al legale con in mano la descrizione tecnica del sistema, compreso che cosa decide da solo.
Poi c’è la parola «contrattuale». Il danno può colpire un terzo qualunque, e può colpire un cliente con cui avete firmato un contratto. Se il vostro portale usa un modello per decidere qualcosa che riguarda i clienti, per esempio a quale richiesta dare la precedenza o quale offerta mostrare, l’articolo 16 copre anche le azioni che nascono da quel contratto.
Chi deve esibire le prove sull’IA (articolo 17)
Per qualunque sistema di IA, su istanza di chi allega di aver subito il danno, il giudice ordina all’altra parte o «al terzo che ne dispone» di esibire gli elementi di prova specificamente pertinenti sul funzionamento del sistema. Serve che chi fa causa presenti fatti ed elementi idonei a rendere verosimile la fondatezza della domanda, e l’ordine è limitato a quanto necessario e proporzionato rispetto alla domanda.
Fra gli elementi di prova il comma 2 elenca i registri, la documentazione sul sistema di gestione dei rischi, le informazioni pertinenti della documentazione tecnica e le informazioni sui parametri e le modalità di supervisione umana. Sono documenti che il regolamento chiede ai sistemi ad alto rischio, con il calendario visto sopra: oggi l’ordine si può dare per qualunque sistema, ma quei documenti possono non esistere ancora.
Le conseguenze del rifiuto sono diverse per chi è in causa e per chi non lo è. Se la parte, senza giustificato motivo, non esibisce la documentazione dell’elenco, il giudice, valutato ogni altro elemento di prova, ritiene come ammessi i fatti allegati da chi ha fatto causa. Il terzo che, senza giustificato motivo, non adempie è condannato a una pena pecuniaria da 1.500 a 10.000 euro.
Se l’ordine arriva all’azienda e i documenti stanno presso il fornitore, conta che cosa il contratto le permette di ottenere. Se non averli sia un giustificato motivo è una domanda per il legale; averli a disposizione la toglie di mezzo.
Quando il nesso di causalità è presunto (articolo 18)
Quando il danno deriva dalla violazione di uno o più obblighi dell’AI Act, il nesso di causalità fra la violazione e il danno è presunto, salvo prova contraria.
Per ogni sistema, quindi, la domanda è quali obblighi del regolamento lo riguardano e da quale data. Per l’alto rischio la risposta ha le due scadenze del 2027 e del 2028; per gli altri obblighi il calendario va ricostruito con il legale, sistema per sistema.
La certificazione di conformità all’AI Act esclude la responsabilità?
Non da sola. Per l’articolo 19, fermo quanto previsto dalla normativa di recepimento della direttiva (UE) 2024/2853, la conformità del sistema agli obblighi dell’AI Act, anche se certificata ai sensi del capo III, sezione 5, non esclude di per sé la responsabilità del convenuto. Vale, come l’articolo 18, quando il danno deriva dalla violazione di un obbligo del regolamento.
Con il rinvio, per un sistema ad alto rischio quella certificazione può non esserci ancora. Con o senza certificato, conviene poter ricostruire come il sistema è stato costruito e come si comporta: con quali dati è stato addestrato o configurato, e come è stato provato prima di andare in produzione. È materiale che l’azienda deve poter recuperare anche quando il sistema l’ha scritto qualcun altro.
Quale reato introduce l’articolo 437-bis, e che cosa cambia nella 231 (art. 25-vicies)?
Il decreto inserisce nel codice penale l’articolo 437-bis. Punisce chi omette di adottare le misure tecniche di sicurezza previste per la progettazione, l’addestramento, la produzione o l’immissione sul mercato di sistemi di IA ad alto rischio, o omette di adottare misure di sorveglianza umana, quando da quelle omissioni derivi pericolo per la vita o l’incolumità pubblica o individuale.
Il comma che riguarda più da vicino un’azienda che il sistema lo usa è l’ultimo: punisce l’utilizzatore professionale di sistemi ad alto rischio che omette intenzionalmente di adottare misure di sorveglianza umana, se ne deriva quel pericolo. La condizione del pericolo vale in tutti e due i casi.
Nel d.lgs. 231/2001 entra l’articolo 25-vicies: per il 437-bis all’ente si applica una sanzione pecuniaria da seicento a mille quote, più le sanzioni interdittive dell’articolo 9, comma 2, lettere b), c), d) ed e), dello stesso decreto.
Nel software la sorveglianza umana diventa una funzione da progettare come le altre: che cosa una persona vede di quello che il sistema sta decidendo, come lo ferma, che traccia lascia l’intervento. Quali misure siano «previste» per un certo sistema è una domanda per il legale. Chi aggiorna il modello organizzativo 231 avrà bisogno di sapere dal reparto IT dove quelle misure stanno, nel codice e nelle procedure.
La domanda da portare al legale: quali sistemi dell’azienda potrebbero rientrare fra quelli ad alto rischio, e da quale data.
Il fornitore del software può ricevere l’ordine di esibizione?
Può riceverlo, se non è parte in causa e custodisce registri e documentazione: in quel caso può essere il «terzo che ne dispone» dell’articolo 17, e se non adempie senza giustificato motivo la pena pecuniaria è sua. Una funzione di IA può arrivare dentro un software scritto da altri, o come servizio in cloud chiamato da un’integrazione. L’azienda, intanto, deve rispondere in causa con quello che riesce a ottenere.
Prima di firmare il prossimo contratto, o di rinnovare quello che c’è, sono quattro le domande che il fornitore dovrebbe chiudere per iscritto.
- Di chi è il codice, e dove sta: in un repository a cui l’azienda accede, o solo sulle macchine del fornitore.
- Dove girano il modello e i dati, e chi ci può accedere.
- Che cosa registra il sistema quando decide o suggerisce qualcosa, per quanto lo conserva, e se l’azienda può estrarlo senza chiedere il permesso al fornitore.
- Che cosa si consegna a fine progetto, e che cosa resta disponibile se il rapporto finisce.
Sulla prima e sull’ultima domanda, il codice e la consegna, il nostro impegno è scritto nelle domande frequenti della pagina sul software su misura: «Sorgenti, documentazione e ambienti di sviluppo sono di vostra proprietà, e restano vostri anche se un giorno cambiate fornitore.» Sulle altre due la risposta dipende da dove gira il sistema.
Un caso: il modello sui server del committente
Per una pubblica amministrazione dell’Emilia-Romagna abbiamo costruito un software di trascrizione dei verbali. Riconoscimento vocale, installazione on-premise, due mesi di lavoro con tre persone: due sul backend, una sul frontend.
L’audio non lascia l’infrastruttura del committente. Il modello di riconoscimento vocale gira nell’installazione on-premise, sulle macchine del committente, e fra la registrazione e il testo finale non passa nessun servizio di terzi.
Il caso non dice niente sulla classificazione di quel sistema rispetto al regolamento. Lo raccontiamo per una delle quattro domande, dove girano il modello e i dati, a cui quel progetto ha risposto con l’installazione.
L’installazione on-premise ha costi suoi, e per molti sistemi un servizio in cloud è la scelta sensata. In quel caso le stesse quattro domande vanno fatte a chi gestisce il servizio, e le risposte vanno nel contratto.
Che cosa decidere, e quando
Dal 30 settembre 2026 valgono l’accesso alle prove e le sue conseguenze, per qualunque sistema di IA. Le decisioni che non aspettano:
- L’inventario. Quali sistemi usano un modello, se rientrano nelle definizioni dell’articolo 3 del regolamento, chi li ha scritti e dove girano.
- I contratti. Codice, dati, registri e documentazione: che cosa consegna il fornitore e che cosa resta accessibile all’azienda, anche dopo la fine del rapporto. Un contratto firmato adesso può coprire anche il periodo in cui arriveranno gli obblighi sull’alto rischio.
Prima del 2 dicembre 2027, con il legale, per i sistemi che potrebbero essere ad alto rischio: quali obblighi del regolamento varranno, come è progettata la sorveglianza umana, e se serve la certificazione del capo III, sezione 5.