D.Lgs. 160/2026 e responsabilità da intelligenza artificiale: prova, causalità, governance e nuove fattispecie penali

Abstract

Il D.Lgs. 9 settembre 2026, n. 160, pubblicato nella Gazzetta Ufficiale del 15 settembre 2026, n. 214 ed efficace dal 30 settembre 2026, costituisce il segmento nazionale di adeguamento al regolamento (UE) 2024/1689, noto come regolamento sull’intelligenza artificiale. Il decreto non costruisce un codice generale della responsabilità da IA e non sostituisce le regole sostanziali già operanti nel diritto civile, penale, processuale e della protezione dei dati. Interviene, invece, su tre piani coordinati: l’impiego dei sistemi di IA nelle attività di polizia, la repressione di alcune condotte illecite connesse a sistemi di IA e l’introduzione di strumenti processuali civili destinati a ridurre l’asimmetria informativa tra danneggiato e soggetti che controllano il sistema o la relativa documentazione.

Nel settore civile, gli artt. 16-20 sono il nucleo più innovativo. L’art. 17 consente al giudice, a fronte di una domanda resa verosimile, di ordinare l’esibizione di registri, documentazione del sistema di gestione dei rischi, documentazione tecnica e informazioni sulla supervisione umana. L’art. 18 stabilisce una presunzione relativa del nesso di causalità quando il danno deriva dalla violazione di uno o più obblighi del regolamento IA. L’art. 19 chiarisce che la conformità al regolamento, anche certificata, non esclude di per sé la responsabilità. L’art. 20 introduce un’azione diretta nei confronti dell’assicuratore, nei limiti della copertura e con il responsabile individuato quale litisconsorte necessario.

Sul piano penale, l’art. 12 inserisce l’art. 437-bis c.p., incentrato sull’omessa adozione di misure tecniche di sicurezza o di sorveglianza umana e sull’alterazione illecita di sistemi di IA ad alto rischio, quando ne derivi un pericolo qualificato. L’art. 13 inserisce l’art. 359-ter c.p.p., che disciplina l’identificazione e la localizzazione mediante sistemi di IA per l’identificazione biometrica remota in tempo reale, con autorizzazione del giudice per le indagini preliminari, limiti temporali, banca dati specifica e divieto di scraping non mirato. Il decreto valorizza inoltre, nel nuovo art. 25-vicies del D.Lgs. 231/2001, l’art. 437-bis c.p. e il preesistente art. 612-quater c.p., relativo alla diffusione illecita di contenuti falsificati o alterati mediante IA.

La tesi centrale del commento è che la governance dell’IA non costituisce soltanto un insieme di adempimenti amministrativi. Registri, versioni del modello, documentazione tecnica, valutazioni del rischio, audit, log, tracciabilità della supervisione e contratti con il fornitore possono diventare prova processuale diretta. La completezza, coerenza e conservazione di tale patrimonio documentale influiranno sulla possibilità di ricostruire il rapporto tra output e danno. La riforma resta tuttavia incompleta: non definisce un criterio sostanziale autonomo di imputazione, frammenta il regime probatorio tra le diverse fonti dell’illecito, lascia aperta la portata della presunzione causale e non risolve tutte le interazioni con GDPR, responsabilità da prodotto, disciplina del lavoro, responsabilità professionale e D.Lgs. 231/2001.

Estratto per il Commentario

Il D.Lgs. 160/2026 non introduce una responsabilità civile generale per l’intelligenza artificiale, ma modifica il modo in cui il danno da IA potrà essere provato e discusso in giudizio. L’ordine di esibizione dell’art. 17 e la presunzione relativa dell’art. 18 incidono sul rapporto tra informazione tecnica, causalità e difesa dell’impresa. La conformità all’AI Act, ai sensi dell’art. 19, conserva rilievo ma non opera come esimente automatica. La documentazione di governance diviene così un possibile luogo di prova: non soltanto dimostra l’adozione di procedure, ma può consentire di ricostruire quale versione del sistema abbia prodotto un determinato risultato, con quali dati, parametri, controlli e interventi umani. Nel penale, l’art. 437-bis c.p. punisce omissioni di sicurezza e alterazioni di sistemi ad alto rischio in presenza di pericoli qualificati; l’art. 359-ter c.p.p. circonda l’identificazione biometrica remota in tempo reale di garanzie giudiziali e temporali. Il nuovo art. 25-vicies D.Lgs. 231/2001 completa il quadro, ma lascia interrogativi sulla procedibilità a querela dell’art. 612-quater c.p. e sull’operatività dell’art. 8 del decreto 231 quando manchi la colpevolezza della persona fisica. Il risultato è una disciplina di coordinamento, destinata a essere precisata dalla prassi giudiziaria.

1. Introduzione: evoluzione normativa europea, percorso italiano e funzione del decreto

1.1. Il punto di partenza europeo

Il regolamento (UE) 2024/1689 rappresenta, nel perimetro delle fonti qui verificate, il riferimento europeo essenziale. La sua funzione è quella di stabilire regole armonizzate sull’intelligenza artificiale, secondo una logica che collega classificazione dei sistemi, pratiche vietate, requisiti per i sistemi ad alto rischio, documentazione, supervisione e responsabilità organizzativa. Il regolamento opera soprattutto come disciplina di conformità. Stabilisce condizioni, obblighi e divieti destinati a orientare la progettazione, l’immissione sul mercato e l’utilizzo dei sistemi. Non coincide, per ciò solo, con una disciplina completa dell’illecito civile. La distinzione è decisiva: una violazione regolatoria può assumere rilievo nella causa di danno, ma la regola europea di compliance non risponde automaticamente alla domanda su chi debba risarcire, in base a quale criterio sostanziale e con quale distribuzione dell’onere probatorio.

Il legislatore italiano si muove dentro questa distinzione. Il preambolo del decreto richiama gli artt. 76 e 87, quinto comma, della Costituzione, la legge 400/1988, la legge 234/2012, la legge 23 settembre 2025, n. 132, il regolamento IA, il GDPR, la direttiva (UE) 2016/680 e la direttiva (UE) 2024/2853 sulla responsabilità per danno da prodotti difettosi, che abroga la direttiva 85/374/CEE. Richiama inoltre il codice penale, il codice di procedura penale, il codice civile, il D.Lgs. 231/2001, il codice privacy, il D.Lgs. 51/2018, la legge 121/1981 e il D.Lgs. 271/1989. L’insieme dei richiami mostra che l’adeguamento non è circoscritto alla tecnologia: coinvolge sicurezza pubblica, trattamento dei dati, prova civile, imputazione penale e responsabilità degli enti.

1.2. La delega e l’iter del D.Lgs. 160/2026

La legge 23 settembre 2025, n. 132, “Disposizioni e deleghe al Governo in materia di intelligenza artificiale”, è indicata dal decreto come fonte di delega. In questa revisione è confermato il dato relativo all’art. 26, comma 1, lettera c), che ha inserito l’art. 612-quater c.p.; non viene invece ricostruito il contenuto integrale della delega né il rapporto tra tutti i criteri direttivi e le singole scelte del D.Lgs. 160/2026, perché il testo integrale non è stato verificato direttamente.

L’iter riportato nel preambolo comprende la deliberazione preliminare del Consiglio dei ministri del 10 giugno 2026, l’acquisizione del parere del Garante per la protezione dei dati personali, il parere della Conferenza unificata espresso nella seduta del 20 luglio 2026, i pareri delle competenti Commissioni parlamentari di Camera e Senato e la deliberazione definitiva del Consiglio dei ministri del 4 agosto 2026. La proposta è stata presentata dal Presidente del Consiglio e dai Ministri per gli affari europei, il PNRR e le politiche di coesione, dell’interno e della giustizia, di concerto con i Ministri degli affari esteri e della cooperazione internazionale, della difesa e dell’economia e delle finanze. Gli atti dell’iter non sono stati esaminati nel loro testo integrale e, pertanto, non possono essere utilizzati per ricostruire intenzioni legislative ulteriori rispetto a quelle desumibili dal testo verificato.

1.3. Ratio e collocazione sistematica

Il decreto ha tre Titoli. Il Titolo I riguarda l’utilizzo dei sistemi di IA per l’attività di polizia e comprende disposizioni generali, ricerca e sperimentazione, spazi di sperimentazione normativa, formazione, dati biometrici, identificazione biometrica remota in tempo reale, valutazione d’impatto sui diritti fondamentali, conservazione delle registrazioni, notifica dell’utilizzo e videosorveglianza con riconoscimento facciale a posteriori. Il Titolo II comprende disposizioni penali sostanziali e processuali, modifiche al codice penale, al codice di procedura penale, alle norme di attuazione e al D.Lgs. 231/2001, nonché gli strumenti processuali civili per il risarcimento. Il Titolo III contiene disposizioni transitorie sull’utilizzo dei sistemi di IA per attività di polizia e la clausola di invarianza finanziaria.

Il decreto è quindi una fonte di raccordo. L’art. 16, comma 1, estende l’applicazione dell’art. 17 alle azioni di risarcimento contrattuale ed extracontrattuale cagionato nell’utilizzo di un sistema di IA. Gli artt. 18 e 19, ai sensi del comma 2, operano invece quando il danno deriva dalla violazione di uno o più obblighi del regolamento IA. Questa differenza, apparentemente tecnica, produce un effetto sistematico rilevante: l’accesso alle prove ha un perimetro più ampio della presunzione causale e della regola sulla conformità. Il decreto non sostituisce gli artt. 1218, 2043, 2050 e 2051 c.c.; offre strumenti che incidono sul modo in cui i presupposti della responsabilità potranno essere accertati.

2. Il quadro europeo della responsabilità per l’intelligenza artificiale

2.1. Compliance e responsabilità non sono categorie sovrapponibili

La prima distinzione da mantenere è quella tra disciplina di conformità e disciplina della responsabilità. Il regolamento IA definisce un ambiente di progettazione e utilizzo nel quale determinate pratiche sono vietate, i sistemi ad alto rischio sono sottoposti a requisiti specifici e il ciclo di vita deve essere documentato. Gli obblighi richiamati dall’art. 17 del decreto confermano questa architettura: registri ai sensi dell’art. 12 del regolamento, sistema di gestione dei rischi ai sensi dell’art. 9, documentazione tecnica ai sensi dell’art. 11 e parametri e modalità di supervisione umana ai sensi dell’art. 14. Questi riferimenti non trasformano automaticamente ogni irregolarità di compliance in un illecito civile, ma attribuiscono alla conformità una rilevanza probatoria e, quando la violazione del regolamento è causa del danno, una rilevanza causale secondo l’art. 18.

La responsabilità civile segue una logica diversa. Occorre individuare il danno, il rapporto causale, il titolo contrattuale o extracontrattuale, il soggetto al quale il fatto è imputabile e le eventuali cause di esclusione. Il decreto lascia questi elementi alle categorie generali e alle discipline speciali richiamate. Sul piano sistematico, il testo verificato consente di descrivere la scelta del decreto come intervento sugli strumenti processuali, senza attribuirgli un criterio sostanziale generale di imputazione. Le regole sull’illecito aquiliano non sono armonizzate nell’Unione e un intervento selettivo sui criteri nazionali avrebbe potuto creare sovrapposizioni e disallineamenti.

2.2. AI Act e direttiva sulla responsabilità da prodotto difettoso

La direttiva (UE) 2024/2853 del Parlamento europeo e del Consiglio, del 23 ottobre 2024, sulla responsabilità per danno da prodotti difettosi, è una direttiva e non una disciplina nazionale già verificata in questa sede. Il termine di recepimento indicato per gli Stati membri è il 9 dicembre 2026. Il D.Lgs. 160/2026 ne salva l’operatività nei limiti espressamente verificati, ma non consente di ricostruire l’esistenza o il contenuto di una normativa italiana di recepimento. Il rapporto con la responsabilità da prodotto deve quindi essere presentato come coordinamento da verificare caso per caso.

La presente revisione non assume come verificati ulteriori sviluppi della disciplina unionale della responsabilità civile per l’IA oltre alle fonti normative elencate nella sezione finale. Questo dato spiega la tecnica normativa italiana, ma non autorizza ad affermare ulteriori vicende di proposte europee non verificate documentalmente. In particolare, il profilo delle sorti formali di eventuali proposte di direttiva sulla responsabilità da IA non è stato oggetto di verifica diretta e deve essere lasciato fuori da conclusioni assertive. Il punto rilevante per il decreto è un altro: in mancanza di una disciplina europea civile completa, gli ordinamenti nazionali conservano un ruolo significativo nella definizione delle regole sostanziali e processuali, entro il quadro dell’AI Act e delle altre fonti europee.

2.3. GDPR, direttiva 2016/680 e clausole di salvaguardia

Il GDPR mantiene uno spazio autonomo. L’art. 16, comma 3, stabilisce che restano ferme le disposizioni dell’art. 82 del regolamento (UE) 2016/679 e della normativa nazionale di recepimento della direttiva (UE) 2024/2853. La clausola impedisce di leggere l’azione del decreto come sostitutiva dell’azione risarcitoria prevista dal GDPR. Possono quindi coesistere, secondo i fatti allegati, una violazione della disciplina dei dati personali e un danno cagionato nell’utilizzo di un sistema di IA. La qualificazione del rapporto tra le domande, il divieto di duplicazione risarcitoria e la prova del medesimo pregiudizio dovranno essere risolti secondo le regole processuali applicabili e secondo la concreta struttura delle pretese.

Il Garante conserva inoltre la propria natura di autorità amministrativa competente a emanare provvedimenti preventivi, inibitori o conformativi e a irrogare sanzioni, come rilevato dalla Cass. civ., sez. I, ord. 22 luglio 2026, n. 23755. La pronuncia non riguarda il D.Lgs. 160/2026 e viene utilizzata soltanto per analogia istituzionale. Il coordinamento tra controllo amministrativo, documentazione di accountability e giudizio civile è destinato a essere concreto: un provvedimento dell’autorità può costituire materiale valutabile nel processo, ma non sostituisce automaticamente l’accertamento degli elementi della domanda risarcitoria.

3. Struttura e ambito di applicazione del decreto

3.1. I tre Titoli e i diversi oggetti regolati

Il Titolo I è dedicato alle attività di polizia. Le definizioni dell’art. 2, per quanto verificate, includono il regolamento IA, la legge IA, il sistema di IA, le pratiche vietate, il sistema ad alto rischio, le categorie particolari di dati personali, i dati relativi a condanne penali e reati, i dati operativi sensibili, l’output, lo scraping non mirato, le autorità nazionali per l’intelligenza artificiale, il Garante, le forze di polizia, l’attività di polizia e le finalità di polizia. Per quanto non espressamente previsto, l’art. 2, comma 2, rinvia alle definizioni dell’art. 2 della legge 132/2025 e dell’art. 3 del regolamento IA. Il dato è importante anche per il Titolo II: il decreto non costruisce, nel Capo II, un catalogo autonomo di soggetti come provider, deployer, importatore o distributore.

Il Titolo II si articola in un Capo I penale e in un Capo II civile. Il Capo I contiene gli artt. 11-15: definizioni, modifiche al codice penale, modifiche al codice di procedura penale, intervento sulle norme di attuazione e modifiche al D.Lgs. 231/2001. Il Capo II contiene gli artt. 16-20. Il Titolo III riguarda le disposizioni transitorie e la clausola di invarianza finanziaria. L’assenza di un’autonoma definizione civilistica dei soggetti obbligati impone di ricostruire la posizione concreta sulla base del rapporto contrattuale, del controllo sul sistema, della disponibilità della documentazione e delle categorie definite dal regolamento IA.

3.2. Soggetti coinvolti e rinvio definitorio

Nelle controversie civili potranno assumere rilievo il fornitore o provider, il deployer o utilizzatore professionale, l’importatore, il distributore, il datore di lavoro, il professionista, il produttore del prodotto nel quale il sistema è integrato, il soggetto che dispone degli elementi di prova, il danneggiato e, quando ricorrono i presupposti, il consumatore. Queste categorie sono utilizzate in senso descrittivo e non come definizioni autonome del decreto. L’art. 2, comma 2, del Titolo I e il rinvio all’art. 3 del regolamento IA sono il punto di collegamento. Per il Capo II civile, il testo verificato opera soprattutto attraverso le espressioni “altra parte”, “terzo che ne dispone”, “convenuto”, “danneggiato” e “soggetto individuato quale responsabile”.

La conseguenza pratica è che il processo potrà coinvolgere soggetti diversi a seconda del bene o servizio e del luogo in cui si trova l’informazione. Un fornitore può non essere il convenuto principale ma può disporre della documentazione tecnica; un deployer può aver assunto la supervisione umana; un assicuratore può essere convenuto in via diretta ai sensi dell’art. 20; un importatore o distributore può assumere rilievo nel quadro della disciplina da prodotto, ma il testo nazionale di recepimento della direttiva 2024/2853 non è stato verificato. Il ruolo processuale non deriva quindi soltanto dall’etichetta tecnologica, ma dal titolo della domanda e dal controllo esercitato sulla specifica evidenza.

3.3. La differenza tra art. 16, comma 1, e comma 2

L’art. 16, comma 1, delimita l’ambito dell’art. 17 alle azioni di risarcimento del danno, contrattuale o extracontrattuale, cagionato nell’utilizzo di un sistema di IA. Non richiede, per l’accesso alle prove, che sia già allegata una violazione del regolamento IA. Il comma 2 restringe invece l’applicazione degli artt. 18 e 19 ai casi in cui il danno derivi dalla violazione di uno o più obblighi previsti dal regolamento. L’operatore deve quindi separare fin dall’atto introduttivo due piani: la domanda di esibizione e, eventualmente, la domanda che invoca la presunzione causale o discute l’effetto della conformità.

La frammentazione non è soltanto terminologica. Un danno derivante da un uso improprio di un sistema, senza violazione dimostrabile di un obbligo dell’AI Act, potrà beneficiare dell’art. 17 ma non necessariamente dell’art. 18. Una violazione regolatoria priva di danno non attiva la presunzione, perché la norma presuppone il danno. Una domanda fondata sul GDPR resta inoltre soggetta all’art. 82 GDPR, come espressamente stabilito dall’art. 16, comma 3. Sul piano interpretativo, la separazione suggerisce di indicare nel giudizio quali strumenti siano invocati e per quale presupposto, evitando di presentare l’intero Capo II come un unico regime probatorio.

4. Responsabilità contrattuale ed extracontrattuale

4.1. Neutralità del decreto rispetto al criterio sostanziale di imputazione

Il D.Lgs. 160/2026 non modifica, per quanto verificato, gli artt. 1218, 2043, 2050 e 2051 c.c. e non stabilisce che ogni danno prodotto da un sistema di IA debba essere trattato come responsabilità oggettiva, attività pericolosa o responsabilità da cosa in custodia. La scelta è coerente con la tecnica processuale degli artt. 16-20. L’art. 17 facilita l’accesso a informazioni tecniche; l’art. 18 interviene sul nesso causale in una sottocategoria di violazioni; l’art. 19 nega un effetto esimente automatico alla conformità. Restano da qualificare il rapporto giuridico, la condotta, il danno, il nesso e il criterio di imputazione.

Nei rapporti contrattuali, la domanda potrà riguardare l’inadempimento di una prestazione che include l’uso di IA, l’insufficiente supervisione, la mancata comunicazione di limiti del sistema o l’inosservanza di obblighi di sicurezza assunti nel contratto. Nel rapporto extracontrattuale, la qualificazione dipenderà dalle circostanze concrete e dal dovere violato. Il sistema può essere uno strumento dell’attività, una componente di un prodotto, un servizio autonomo o un elemento di un’organizzazione. Il decreto non autorizza a saltare la qualificazione del rapporto per il solo fatto che l’output sia generato automaticamente.

4.2. Art. 2050 c.c. e attività pericolosa: una questione aperta

La possibilità di qualificare l’attività svolta mediante IA come attività pericolosa ai sensi dell’art. 2050 c.c. è controversa e resta aperta. Gli argomenti favorevoli muovono dal carattere potenzialmente opaco, scalabile e non facilmente prevedibile di alcuni sistemi, soprattutto quando operano su larga scala o incidono su salute, credito, sicurezza o diritti fondamentali. La presenza di un rischio tecnologico organizzato potrebbe essere valorizzata per sostenere che la pericolosità riguardi l’attività complessiva, non il semplice strumento informatico. In questa prospettiva, il sistema di gestione dei rischi e la supervisione umana assumerebbero rilievo anche nella prova liberatoria.

La qualificazione dell’attività svolta mediante IA come attività pericolosa ai sensi dell’art. 2050 c.c. resta una questione interpretativa, non risolta dal D.Lgs. 160/2026. L’IA non è una categoria omogenea: la valutazione dovrebbe dipendere dal concreto caso d’uso, dal rischio dell’attività e dalle circostanze dell’evento, senza attribuire al decreto una qualificazione automatica. La presente revisione non utilizza precedenti non verificati per sostenere questa ricostruzione.

4.3. Custodia, attività professionale e responsabilità da prodotto

Anche la responsabilità da cosa in custodia può assumere rilievo soltanto in ipotesi concrete, quando il sistema di IA sia incorporato in una cosa o in un’infrastruttura sottoposta a custodia. La Cass. civ., sez. III, sent. 11 febbraio 2026, n. 3062, riguarda la responsabilità da cosa in custodia e precisa che il comportamento del danneggiato può interrompere il nesso causale quando costituisca causa esclusiva dell’evento; la pronuncia non riguarda l’IA e viene qui richiamata esclusivamente come riferimento analogico, senza estenderne l’oggetto.

Nella responsabilità professionale il sistema di IA non sostituisce necessariamente il professionista. Può essere un supporto, un filtro, un dispositivo di selezione o un componente della decisione. Il contratto e la disciplina professionale potranno incidere sull’estensione della prestazione, ma le fonti specifiche non sono state verificate oltre i riferimenti indicati. Per la responsabilità da prodotto, l’art. 16, comma 3, e l’art. 19 conservano la disciplina di recepimento della direttiva 2024/2853. La qualificazione del danno dovrà quindi considerare il rapporto tra componente software, servizio, prodotto e decisione organizzativa senza presumere che uno solo di questi elementi sia sempre decisivo.

5. L’accesso alle prove ex art. 17

5.1. Funzione dell’ordine di esibizione

L’art. 17 è il dispositivo processuale più articolato del Capo II. La norma parte da una situazione tipica dei contenziosi tecnologici: il danneggiato conosce il risultato, il momento dell’evento e il pregiudizio, ma non dispone dei registri, della documentazione tecnica, dei parametri di supervisione o della storia delle versioni che consentono di comprendere come il risultato sia stato generato. La risposta legislativa non consiste in una presunzione generale di responsabilità. Consiste in un ordine di esibizione mirato, che il giudice impartisce su istanza di parte quando l’istante presenta fatti ed elementi idonei a rendere verosimile la fondatezza della domanda, anche con riferimento al collegamento tra risultato prodotto dal sistema e danno lamentato.

L’ordine può essere rivolto all’altra parte o al terzo che dispone degli elementi di prova. Questa formula supera una visione ristretta del processo tra attore e convenuto. Il fornitore può conservare i log e la documentazione tecnica anche quando il rapporto processuale principale è tra utente e danneggiato; un subfornitore può disporre della versione del modello; un gestore dell’infrastruttura può avere registrazioni essenziali. La legittimazione passiva dell’ordine non coincide quindi necessariamente con la responsabilità sostanziale. Il terzo è chiamato a collaborare in quanto detentore della prova, non perché il decreto lo qualifichi automaticamente come autore del danno.

5.2. Verosimiglianza della fondatezza e soglia probatoria

La verosimiglianza della fondatezza non equivale alla prova piena della domanda. Il testo richiede tuttavia qualcosa di più di una richiesta esplorativa o di una congettura tecnologica. L’istante deve allegare fatti ed elementi idonei a rendere plausibile la domanda e il collegamento tra output e danno. Possono rilevare, secondo il caso, la sequenza temporale, la corrispondenza tra uso del sistema e decisione lesiva, la presenza di un contratto, l’identificazione del sistema, una comunicazione che attribuisca l’esito a un modello, un malfunzionamento osservabile, una contestazione interna o un documento già disponibile.

La soglia deve essere sufficiente a impedire la fishing expedition, ma non così elevata da pretendere dal danneggiato proprio la prova che l’ordine dovrebbe rendere accessibile. Sul piano interpretativo, una possibile lettura della disposizione è che il giudice debba verificare tre elementi collegati: l’esistenza del danno allegato, la plausibilità dell’impiego del sistema e la plausibilità del nesso tra output ed evento. Non è necessario dimostrare già la violazione di uno specifico requisito tecnico, soprattutto perché l’art. 17, per effetto dell’art. 16, comma 1, opera anche fuori dalla violazione dell’AI Act. Occorre però indicare una domanda concreta e una prova specifica.

Il giudice dovrà considerare anche la posizione processuale dell’istante. Un consumatore può avere minori conoscenze e minori possibilità di accesso; un’impresa concorrente può invece disporre di competenze tecniche tali da dover formulare una richiesta più precisa. La soglia non dovrebbe diventare una penalizzazione della parte priva di informazioni che la controparte controlla, ma nemmeno una presunzione di fondatezza fondata sul solo verificarsi di un risultato sfavorevole. Si tratta di una valutazione interpretativa, che deve restare ancorata alla verosimiglianza, alla pertinenza e alla proporzionalità richieste dall’art. 17.

5.3. Specifica pertinenza e delimitazione della richiesta

L’art. 17 richiede elementi di prova “specificamente pertinenti” relativi al funzionamento del sistema. La specificità impedisce di ordinare la consegna indiscriminata di interi archivi, del codice sorgente completo o di ogni documento dell’organizzazione. La pertinenza impone un rapporto concreto tra documento, funzionamento contestato e danno lamentato. Una richiesta corretta dovrebbe indicare il sistema o la funzione utilizzata, il periodo, l’evento, la versione presumibilmente operativa, la decisione o output oggetto di contestazione e il tipo di informazione necessaria.

La specifica pertinenza va coordinata con la necessità e proporzionalità del comma 3. Il giudice deve limitare l’ordine a quanto necessario rispetto alla domanda, tenendo conto degli interessi di tutte le parti. Una richiesta relativa a un singolo diniego automatizzato non dovrebbe trasformarsi in un audit generale dell’impresa; una richiesta su un errore sistemico, ripetuto e potenzialmente lesivo di numerosi soggetti potrebbe invece richiedere una finestra documentale più ampia. La proporzionalità non è soltanto un limite al danneggiato: è anche un criterio per costruire una disclosure utilizzabile, leggibile e compatibile con la tutela dei segreti.

5.4. I documenti del comma 2

Il comma 2 individua quattro categorie. La prima comprende i registri di cui all’art. 12 del regolamento IA. Nel processo, tali registri possono servire a collocare temporalmente le operazioni, identificare l’uso del sistema e collegare un output a un determinato episodio. Il testo verificato non consente di elencare contenuti ulteriori rispetto al richiamo legislativo; è quindi prudente parlare di registrazioni pertinenti all’operatività del sistema e non di un contenuto uniforme per ogni caso.

La seconda categoria è la documentazione relativa al sistema di gestione dei rischi di cui all’art. 9 del regolamento. Essa può riguardare, nei limiti del richiamo verificato, l’identificazione e la gestione dei rischi del sistema. In giudizio sarà rilevante distinguere tra documento generale, valutazione riferita alla versione del sistema e registrazione dell’effettiva attuazione delle misure. Un manuale non aggiornato non equivale a una prova dell’esecuzione concreta; una valutazione coerente con la versione impiegata può invece incidere sulla ricostruzione della condotta e della prevedibilità.

La terza categoria riguarda le informazioni pertinenti contenute nella documentazione tecnica di cui all’art. 11 del regolamento. Il riferimento consente di chiedere le parti utili a comprendere caratteristiche, limiti, dati, prestazioni o condizioni d’uso, ma la pertinenza resta decisiva. La consegna può essere graduata mediante estratti, sintesi tecniche, accesso riservato, oscuramento o verifica da parte di consulenti vincolati alla riservatezza. L’ordine non deve essere interpretato come un diritto generalizzato alla conoscenza del know-how non collegato alla domanda.

La quarta categoria comprende le informazioni relative ai parametri e alle modalità di supervisione umana di cui all’art. 14 del regolamento. È una categoria particolarmente significativa perché collega il funzionamento del sistema alla decisione organizzativa di affidarsi, controllare o correggere l’output. Non è sufficiente sapere che un operatore era formalmente assegnato alla supervisione. Occorre poter ricostruire, quando pertinente, quali avvisi ricevesse, quali facoltà avesse, quali tempi di intervento fossero previsti e se l’intervento fosse concretamente praticabile. Il comma 2 non esaurisce ogni prova possibile, ma indica il nucleo documentale che il legislatore considera tipicamente decisivo.

5.5. Rapporto con gli artt. 210 ss. c.p.c.

L’art. 17 si colloca accanto e non necessariamente al posto degli strumenti ordinari di esibizione. Il riferimento verificato all’art. 116 c.p.c. nel comma 5 mostra che il decreto presuppone la disciplina generale dell’apprezzamento degli argomenti di prova. La dottrina di commento qualifica l’ordine come modellato sulla falsariga della discovery già nota in materia di proprietà industriale e private antitrust enforcement. Il confronto è utile per due ragioni: da un lato, conferma che l’esibizione può essere mirata e proporzionata; dall’altro, segnala che il giudice deve proteggere segreti commerciali e informazioni riservate.

Il rapporto tra l’ordine di esibizione, la vicinanza della prova e il comportamento processuale deve essere ricostruito sulla base dell’art. 17 e delle regole processuali applicabili. L’ordine non è una surrogazione automatica dell’onere probatorio: la mancata produzione deve essere valutata nel quadro della domanda, della precisione della richiesta, della disponibilità effettiva dei documenti e delle giustificazioni addotte.

5.6. Segreti commerciali, riservatezza e diritto di difesa

I commi 3 e 4 impongono al giudice di contemperare prova e riservatezza. Quando l’esecuzione dell’ordine comporta il rischio di divulgazione di segreti commerciali o altre informazioni riservate, il giudice adotta misure idonee alla tutela e applica l’art. 121-ter del codice della proprietà industriale, di cui al D.Lgs. 10 febbraio 2005, n. 30. Il testo verificato non elenca le singole misure concretamente disponibili; la norma consente tuttavia di ricorrere al modello di protezione processuale dei segreti, con accesso selettivo, oscuramento, limitazione ai difensori e consulenti, deposito riservato o altre cautele compatibili con il contraddittorio.

La riservatezza non può diventare una formula per sottrarre ogni informazione tecnica. Se l’impresa invoca il segreto per impedire la ricostruzione dell’output, il giudice deve verificare sia l’effettiva natura riservata sia la proporzione della misura. Il diritto di difesa del convenuto richiede che esso possa contestare autenticità, integrità, significato e attualità dei documenti. Il diritto di difesa dell’attore richiede che la protezione non renda impossibile comprendere la relazione tra il sistema e l’evento. Sul piano interpretativo, una soluzione equilibrata è quella di distinguere il contenuto tecnico non divulgabile dalla sua funzione probatoria: il primo può essere protetto, la seconda deve restare intelligibile al giudice e, in misura adeguata, alle parti.

5.7. Esibizione, consulenza tecnica e prova digitale

L’ordine non risolve da solo il problema della lettura dei dati. Log, registri e versioni possono essere tecnicamente complessi, incompleti o prodotti da sistemi diversi. La parte che chiede l’esibizione dovrebbe spiegare quale quesito documentale intende affrontare; la parte che esibisce dovrebbe fornire metadati, chiavi di lettura e indicazioni sulla continuità della registrazione. Il giudice potrà coordinare l’esibizione con una consulenza tecnica, senza trasformare la consulenza in un’indagine esplorativa priva di oggetto.

La tracciabilità digitale incide sulla prova dell’autenticità. Un documento tecnico senza indicazione di versione, data di applicazione o responsabile può avere valore limitato. Un log non accompagnato da informazioni sulla sincronizzazione temporale o sulla politica di conservazione può essere contestato. L’art. 17 non detta una disciplina generale dell’evidenza digitale, ma rende prevedibile che il processo dovrà confrontarsi con integrità, provenienza, completezza e intelligibilità dei dati. La governance interna dovrebbe quindi essere progettata anche per rendere i documenti utilizzabili in giudizio, senza confondere la conservazione probatoria con una conservazione illimitata.

6. Mancata esibizione e conseguenze processuali

6.1. Il primo periodo del comma 5: argomenti di prova

L’art. 17, comma 5, disciplina due conseguenze diverse. Se la parte non adempie, anche parzialmente, senza giustificato motivo, il giudice può desumere argomenti di prova ai sensi dell’art. 116 c.p.c. La formulazione è facoltativa e riguarda l’inadempimento all’ordine in termini generali. Il giudice deve valutare la ragione dell’omissione, la chiarezza dell’ordine, la disponibilità effettiva del documento, la possibilità tecnica di estrarlo, la tutela del segreto e il comportamento complessivo. L’argomento di prova non equivale necessariamente alla dimostrazione del fatto principale, ma può concorrere con altri elementi.

La facoltà non è una sanzione automatica per ogni documento mancante. Se il documento è stato distrutto secondo una politica lecita e documentata, se l’ordine chiede dati mai prodotti o se il terzo non dispone più dell’informazione per una ragione non imputabile, il giudice dovrà motivare diversamente. Il “giustificato motivo” è la soglia che impedisce di trasformare l’ordine in responsabilità per impossibilità oggettiva. Anche una produzione parziale può essere valutata: l’incompletezza immotivata può incidere sulla credibilità della ricostruzione.

6.2. Il secondo periodo del comma 5: fatti ritenuti ammessi

Quando l’inadempimento riguarda la documentazione di cui al comma 2, il giudice, valutato ogni altro elemento di prova, ritiene come ammessi i fatti allegati dall’istante. Questa è una conseguenza più intensa rispetto al primo periodo. La norma non dice semplicemente che il giudice può trarre un argomento: impone di ritenere ammessi i fatti allegati, ma conserva la clausola “valutato ogni altro elemento di prova”. La qualificazione dogmatica è controversa. Si può parlare di ficta confessio processuale, perché l’effetto deriva da un comportamento omissivo; si può parlare di presunzione legale relativa temperata, perché la valutazione degli altri elementi impedisce di isolare l’ammissione dal complessivo materiale probatorio. Nessuna delle due letture può essere presentata come consolidata.

Una possibile lettura della disposizione è che siano ammessi soltanto i fatti storici specificamente allegati e collegati alla documentazione omessa, non le qualificazioni giuridiche, le conclusioni sulla responsabilità o l’intero nesso causale. Se l’attore allega che una determinata versione del sistema era operativa il giorno dell’evento e che il log avrebbe potuto confermare l’assenza di supervisione, l’effetto dovrebbe riguardare fatti verificabili, non la definitiva responsabilità dell’impresa. La clausola di valutazione degli altri elementi consente al giudice di escludere che un fatto allegato in modo generico o contraddetto da prove autonome venga assunto senza esame.

La disposizione pone questioni di diritto di difesa. L’ordine deve essere sufficientemente preciso, il documento deve rientrare effettivamente nelle categorie del comma 2 e la parte deve poter spiegare l’impossibilità o la ragione dell’inadempimento. La motivazione del provvedimento dovrà distinguere tra documentazione inesistente, non disponibile, non conservata, non pertinente e semplicemente non prodotta. In mancanza di queste distinzioni, l’effetto dell’ammissione potrebbe diventare sproporzionato. Sul piano costituzionale, la questione non è automaticamente fondata né automaticamente esclusa: dipende dalla lettura concreta della clausola “valutato ogni altro elemento di prova” e dalle garanzie offerte nel procedimento.

6.3. La sanzione al terzo

Se il terzo non adempie senza giustificato motivo, anche parzialmente, il giudice lo condanna a una pena pecuniaria da euro 1.500 a euro 10.000. Il testo usa una formula sanzionatoria autonoma rispetto agli argomenti di prova applicabili alla parte. La sanzione mira a rendere effettiva la collaborazione del soggetto che dispone dell’elemento, ma deve essere applicata considerando disponibilità reale, chiarezza dell’ordine, costi di estrazione, segreto, sicurezza e impossibilità tecnica. Il terzo non è automaticamente responsabile del danno e non dovrebbe subire una penalizzazione per il solo fatto di non poter consegnare informazioni che non possiede.

La posizione del terzo è particolarmente delicata per provider, cloud provider, integratori e subfornitori. Contratti di cooperazione, clausole di conservazione e procedure di risposta agli ordini giudiziari possono ridurre l’incertezza. L’art. 17, comma 6, rende la cooperazione non soltanto una buona prassi commerciale ma un tema di rischio processuale. La dottrina di commento collega questa tecnica agli strumenti di disclosure già conosciuti nell’ordinamento, ma l’ampiezza delle categorie tecnologiche e la natura spesso transnazionale dei fornitori potrebbero richiedere adattamenti giurisprudenziali.

7. La presunzione del nesso causale ex art. 18

7.1. Presupposti e natura relativa

L’art. 18 dispone che, quando il danno deriva dalla violazione di uno o più obblighi previsti dal regolamento IA, il nesso di causalità tra violazione e danno è presunto, salvo prova contraria. La presunzione è relativa. Non esonera l’attore dalla prova del danno, né dalla prova della violazione regolatoria, né dall’allegazione di un collegamento tra la violazione e il pregiudizio. La norma opera sul rapporto causale tra violazione e danno; non stabilisce da sola che il convenuto sia il soggetto responsabile, né determina il criterio sostanziale di imputazione.

La collocazione sistematica, collegata all’art. 16, comma 2, limita l’effetto degli artt. 18 e 19 ai danni derivanti dalla violazione di uno o più obblighi del regolamento (UE) 2024/1689. L’art. 17 ha invece il perimetro più ampio indicato dall’art. 16, comma 1. Il giudice dovrà quindi identificare la fonte dell’illecito e il presupposto dell’azione prima di applicare gli strumenti previsti dal Capo II.

7.2. Causalità materiale e causalità giuridica

Il testo dell’art. 18 parla di nesso tra violazione e danno. Occorre distinguere, sul piano analitico, tra causalità materiale, cioè il collegamento fattuale tra violazione, funzionamento o decisione e evento lesivo, e causalità giuridica, cioè la delimitazione delle conseguenze risarcibili secondo il titolo della responsabilità e la disciplina applicabile. La presunzione non sembra eliminare la necessità di provare quale danno sia stato concretamente subito, né decide se una conseguenza remota o indiretta sia imputabile. Sul piano interpretativo, essa dovrebbe incidere sul primo passaggio, lasciando al giudice la valutazione del danno-conseguenza e della sua risarcibilità.

L’art. 2697 c.c. resta lo sfondo generale della distribuzione dell’onere della prova, ma il decreto modifica il modo in cui una parte del nesso viene provata. Si può discutere se si tratti di vera inversione dell’onere o di alleggerimento probatorio. La formula “è presunto, salvo prova contraria” sembra attribuire al convenuto l’onere di superare la presunzione, ma l’attore deve comunque costruire il presupposto: violazione, danno e collegamento pertinente. La presunzione non copre l’intero fatto costitutivo della domanda.

7.3. La prova contraria

La prova contraria dovrà riguardare il rapporto causale. Potrà consistere nella dimostrazione che la violazione non ha inciso sul risultato, che il danno si sarebbe verificato comunque, che un fattore autonomo ha interrotto la catena, che l’output non è stato utilizzato per la decisione contestata o che il sistema non era operativo nel momento rilevante. Non è invece sufficiente invocare genericamente la conformità, perché l’art. 19 chiarisce che la conformità non esclude di per sé la responsabilità. Conformità e causalità sono piani diversi: la prima può essere un elemento della condotta e della prova, la seconda riguarda la relazione tra violazione ed evento.

Il rapporto tra presunzione causale, responsabilità da custodia e attività pericolosa deve essere valutato con prudenza. Anche nei regimi che agevolano la prova non scompare la necessità di un collegamento concreto tra condotta, funzionamento o violazione e danno. L’art. 18 può spostare il peso della contestazione nei limiti della presunzione relativa, ma non autorizza un risarcimento fondato sul solo fatto che un obbligo sia stato violato.

7.4. Il modello del doppio ciclo causale

La sequenza del giudizio deve essere ricostruita distinguendo il sistema utilizzato, il fatto lesivo e il danno dal successivo esame dell’incidenza della violazione regolatoria. L’art. 18 introduce una presunzione specifica, ma non elimina la necessità di allegare e provare il danno e di individuare l’obbligo del regolamento (UE) 2024/1689 che si assume violato.

Il fallimento di un risultato non dimostra da solo l’inadempimento o la responsabilità. Nel contesto dell’art. 18, se l’attore dimostra una violazione regolatoria pertinente e il danno, la presunzione modifica la posizione probatoria nei limiti previsti dalla norma. Il punto decisivo resta l’identificazione dell’obbligo violato e della relazione con il rischio concretizzato.

7.5. Strategie processuali

L’attore dovrà allegare separatamente il fatto regolatorio, il danno e la ragione per cui la violazione è pertinente all’evento. Il convenuto dovrà evitare una difesa limitata alla certificazione e predisporre una ricostruzione causale alternativa, documentata e tecnicamente comprensibile. L’ordine dell’art. 17 potrà precedere o accompagnare la discussione dell’art. 18, ma il testo non prevede espressamente un procedimento ante causam. L’esperibilità preventiva è quindi una questione aperta, non una regola già risolta. Nei casi privi di violazione dell’AI Act, l’art. 17 resterà comunque disponibile se ricorrono i presupposti.

8. La conformità all’AI Act non esclude la responsabilità ex art. 19

8.1. Compliance come elemento e non come esimente

L’art. 19 stabilisce che, fermo quanto previsto dalla normativa nazionale di recepimento della direttiva (UE) 2024/2853, la conformità del sistema agli obblighi del regolamento IA, anche se certificata ai sensi del capo III, sezione 5, non esclude di per sé la responsabilità del convenuto. La norma impedisce una lettura formalistica dell’AI Act. Il rispetto degli obblighi può dimostrare una parte della condotta diligente o ridurre la plausibilità di determinate contestazioni, ma non decide automaticamente il nesso, il danno, il difetto, l’inadempimento o la relazione tra sistema e organizzazione.

La certificazione ha quindi un valore probatorio potenziale, non un effetto esimente generalizzato. Una possibile lettura della disposizione è che la certificazione possa essere valorizzata per dimostrare l’adozione di misure ragionevoli, la verifica di requisiti o la coerenza di un sistema con il regolamento alla data della verifica. Non dovrebbe però impedire di provare un comportamento successivo, un uso diverso da quello certificato, un aggiornamento non valutato, un difetto di supervisione o un danno non riconducibile al requisito certificato.

8.2. Conformità formale e diligenza concreta

La distinzione tra conformità formale e diligenza concretamente esigibile assume rilievo nei settori a elevato impatto. Un sistema può essere conforme nelle condizioni previste dal provider ma impiegato dal deployer in un contesto diverso, con dati diversi, tempi incompatibili con la supervisione o finalità non documentate. Anche un sistema aggiornato può produrre un output in un’organizzazione priva di procedure di controllo. L’art. 19 non attribuisce automaticamente il fatto a un soggetto, ma invita il giudice a non confondere la regolarità regolatoria del prodotto con la correttezza dell’intero ciclo decisionale.

Le analogie con altri settori regolamentati sono possibili soltanto in termini generali. La conformità a uno standard o il possesso di un’autorizzazione può essere un elemento valutabile, ma non necessariamente esaurisce la diligenza dovuta nel caso concreto. Il decreto formula questo principio in modo esplicito per l’IA. Il convenuto dovrebbe quindi produrre non solo il certificato, ma la documentazione che dimostri il perimetro della verifica, la versione esaminata, le condizioni d’uso e le attività svolte dopo la certificazione.

9. AI governance come prova giudiziaria

9.1. Dalla governance amministrativa alla governance probatoria

La tesi centrale di questa sezione è che la documentazione predisposta per la governance dell’IA assume una funzione processuale e probatoria diretta. L’art. 17, comma 2, elenca registri, gestione dei rischi, documentazione tecnica e supervisione umana; il comma 5 attribuisce conseguenze all’inadempimento relativo a tali documenti. La governance non è più soltanto un’area di conformità interna. Diventa la memoria del sistema: consente di ricostruire quale modello esistesse, quali dati e configurazioni fossero in uso, chi abbia controllato l’output, quali anomalie siano state rilevate e come l’organizzazione abbia reagito.

La funzione probatoria non significa che ogni documento interno sia vero o completo. Significa che, nel contenzioso, il documento potrà essere richiesto, valutato, contestato e collegato alla domanda. L’impresa che costruisce la governance come insieme di policy astratte ma non registra l’attuazione rischia di non poter dimostrare la distanza tra regola e prassi. L’impresa che registra in modo disordinato o contraddittorio può offrire alla controparte elementi per sostenere che la supervisione era solo nominale, che il sistema non era tracciato o che la valutazione del rischio non rifletteva l’uso effettivo.

9.2. Logging e tracciabilità

Il logging deve essere valutato per la funzione che svolge nel singolo sistema. Un log utile dovrebbe consentire, quando tecnicamente possibile e giuridicamente lecito, di ricostruire il momento della richiesta, la versione del modello, il tipo di input, l’output, le soglie decisionali, gli interventi umani e gli eventuali errori. Non è necessario affermare che ogni log debba contenere sempre tutti questi elementi: il testo dell’art. 17 non li elenca singolarmente. È però ragionevole, come raccomandazione operativa e non come obbligo aggiuntivo attribuito al decreto, progettare la registrazione in modo coerente con il rischio e con la possibile necessità di prova.

La tracciabilità deve comprendere anche la catena organizzativa. Se un output è stato ricevuto da un fornitore, trasformato da un integratore e utilizzato da un dipendente, il processo deve consentire di distinguere i passaggi. Il risultato finale può non coincidere con l’output originario. L’operatore umano può averlo corretto o ignorato. Senza questa distinzione, il giudizio rischia di attribuire al sistema ciò che dipende dall’utilizzo o all’utilizzatore ciò che dipende da una malfunzione. La documentazione dovrebbe quindi conservare relazioni tra componenti, non soltanto file isolati.

9.3. Versionamento e gestione delle modifiche

Il versionamento è essenziale perché un sistema non è necessariamente identico nel tempo. Aggiornamenti, retraining, sostituzione dei dati, modifiche alle soglie o nuove interfacce possono cambiare il comportamento. La prova della versione in uso alla data dell’evento può essere decisiva per la pertinenza della documentazione tecnica. Una policy che non conserva il collegamento tra versione e periodo operativo non consente di stabilire se il documento prodotto riguardi il sistema effettivamente contestato.

La conservazione deve essere compatibile con minimizzazione e limitazione della conservazione dei dati personali, ma non può essere pensata senza considerare le esigenze difensive. Il problema non si risolve conservando tutto indistintamente. Occorre definire finalità, categorie, accessi, tempi e modalità di cancellazione, assicurando che l’organizzazione possa spiegare perché un dato non è più disponibile. Una cancellazione conforme a una policy non rende automaticamente irrilevante l’assenza, ma la documentazione della policy e della sua applicazione può evitare che l’omissione appaia arbitraria.

9.4. Valutazioni del rischio e decisioni organizzative

La valutazione del rischio non deve essere un documento statico. Deve essere collegata al caso d’uso, alla popolazione interessata, all’impatto possibile, alla supervisione prevista e alle misure di mitigazione. Nel processo, la valutazione può dimostrare che un rischio era stato individuato, che una misura era stata adottata o, al contrario, che il rischio contestato era stato ignorato. L’ordine dell’art. 17 può raggiungere la documentazione relativa al sistema di gestione dei rischi e non soltanto la versione finale della policy.

Le decisioni di introduzione del sistema, di ampliamento del perimetro, di riduzione dei controlli o di accettazione di un rischio dovrebbero essere attribuibili a ruoli e date. Questa raccomandazione è operativa, non una nuova disposizione normativa certa. Serve a distinguere la responsabilità del provider da quella del deployer e a comprendere se l’uso effettivo corrispondesse alla valutazione iniziale. Nei sistemi utilizzati per selezione, credito, sanità o sicurezza, la documentazione delle decisioni organizzative può assumere un peso superiore a una descrizione generica del modello.

9.5. Supervisione umana e registrazione delle decisioni

L’art. 17, comma 2, lettera d), richiama i parametri e le modalità di supervisione umana di cui all’art. 14 del regolamento. La supervisione deve essere letta come funzione concreta, non come presenza nominale di un operatore. Il processo dovrà poter chiarire chi poteva intervenire, quando, con quali informazioni e con quale obbligo o facoltà. Se l’operatore riceve un output senza indicazione di affidabilità, non può comprendere i limiti o non dispone del tempo per controllarlo, la discussione sulla supervisione sarà diversa rispetto al caso in cui il sistema offra strumenti di verifica e l’operatore scelga consapevolmente di non usarli.

La registrazione delle decisioni umane non deve trasformarsi in una raccolta indiscriminata di dati personali. Occorre documentare il passaggio decisivo: conferma, modifica, rifiuto o mancata utilizzazione dell’output. Nei rapporti di lavoro ciò incide anche sulla dignità e sulla trasparenza del controllo; in sanità incide sulla distinzione tra suggerimento e decisione clinica; nel credito incide sulla spiegazione del profilo; nelle forze di polizia si collega ai limiti autorizzativi dell’art. 359-ter c.p.p. La governance probatoria deve quindi essere sensibile al contesto.

9.6. Incident reporting, audit e conservazione

Un incidente, un reclamo, una correzione o un audit possono diventare il punto di partenza per ricostruire il funzionamento del sistema. La documentazione dovrebbe distinguere tra segnalazione, accertamento, misura correttiva e verifica successiva. Non è corretto attribuire al decreto un obbligo generale di conservare ogni rapporto di incidente non espressamente verificato; è tuttavia prudente, come raccomandazione, prevedere registrazioni coerenti con il rischio e con gli obblighi applicabili. In giudizio, una segnalazione interna può essere letta sia come prova della consapevolezza del rischio sia come prova della tempestiva risposta.

Gli audit devono indicare perimetro, metodo, versione, campioni, risultati, limitazioni e follow-up. Un audit privo di oggetto o riferito a una versione diversa può avere valore ridotto. La documentazione dell’audit non dovrebbe essere redatta per costruire ex post una difesa, ma per lasciare una traccia verificabile delle verifiche eseguite. L’organizzazione dovrà comunque gestire il rischio che l’audit contenga informazioni sensibili e definire accessi e modalità di disclosure.

9.7. Dati, documentazione del fornitore e contratti

La data governance comprende origine, qualità, trasformazioni e limiti dei dati utilizzati. L’art. 17 non crea un diritto astratto a conoscere ogni dataset; consente di chiedere elementi specificamente pertinenti al funzionamento e alla domanda. Il fornitore dovrebbe poter distinguere dati di addestramento, dati di validazione, dati operativi e dati dell’utente, quando questa distinzione sia prevista dal sistema. Il deployer dovrebbe conservare la documentazione relativa alla finalità, alle configurazioni e alle modifiche proprie.

I contratti devono disciplinare chi conserva, chi estrae e chi consegna i documenti. L’espressione “terzo che ne dispone” rende rischiosa una catena contrattuale nella quale nessuno assume la responsabilità pratica della conservazione. Le clausole dovrebbero identificare il soggetto che risponde a richieste giudiziarie, i tempi di cooperazione, i formati, le misure di riservatezza, la conservazione dopo la cessazione del rapporto e l’obbligo di trasferire la documentazione in caso di cambio fornitore. Si tratta di raccomandazioni operative, non di requisiti espressamente elencati dal decreto.

9.8. Il rischio della documentazione incompleta: il parallelismo con la cartella clinica

La Cass. civ., sez. III, ord. 1° settembre 2026, n. 24912 (udienza del 2 aprile 2026) ha affermato, nel contesto sanitario, che l’incompletezza o lacunosità della cartella clinica è una circostanza di fatto che il giudice deve utilizzare nell’accertamento del nesso causale secondo il principio di vicinanza della prova; quando l’incompletezza impedisce di ricostruire ragioni e necessità di un intervento, a fronte di una condotta astrattamente idonea a provocare il pregiudizio, l’incertezza non può ridondare a favore della struttura nei rigorosi limiti indicati dalla giurisprudenza. La pronuncia non riguarda l’IA e viene qui utilizzata dichiaratamente per analogia.

Il parallelismo con logging e documentazione tecnica è forte ma non automatico. Il provider o deployer può avere una posizione di vicinanza rispetto alla prova del funzionamento; il danneggiato può non poter ricostruire un output senza l’accesso ai registri. Una documentazione incompleta, disallineata o contraddittoria può quindi essere valutata insieme all’art. 17, comma 5, e agli altri elementi. Non si deve però trasformare l’analogia in una regola secondo cui ogni lacuna equivale ad ammissione. L’art. 17 contiene una disciplina propria: occorre un ordine, un inadempimento senza giustificato motivo e, per l’effetto più intenso, documentazione rientrante nel comma 2.

La lezione organizzativa è netta: la governance deve essere progettata per sopravvivere al contenzioso. Un sistema che produce output ma non conserva il contesto della produzione è fragile non solo sotto il profilo regolatorio, ma anche sotto quello probatorio. La documentazione deve essere leggibile da un giudice e da un consulente, non soltanto da chi ha costruito il modello. L’assenza di documentazione non prova sempre l’illecito, ma può rendere più difficile contestare una ricostruzione avversaria e attivare le conseguenze processuali del decreto.

10. Rapporti con il GDPR

10.1. Accountability, privacy by design e DPIA

Il rapporto tra D.Lgs. 160/2026 e GDPR deve essere costruito senza sovrapposizioni improprie. Il materiale verificato richiama l’art. 5 GDPR, l’accountability, la privacy by design, la valutazione d’impatto e l’art. 22 come temi rilevanti. Il testo integrale delle disposizioni europee non è stato riprodotto o verificato direttamente in questa sede, ragione per cui il riferimento è sistematico e problematico. In termini generali, il titolare deve poter dimostrare la conformità dei trattamenti e valutare i rischi per le persone; l’uso di sistemi di IA può rendere necessario coordinare documentazione tecnica, registri e valutazioni privacy.

L’art. 17 del decreto può condurre all’esibizione di documenti che contengono dati personali, segreti commerciali o informazioni relative a terzi. Il giudice dovrà quindi coordinare accesso, minimizzazione e riservatezza. La documentazione utile alla difesa non può essere conservata senza limiti e senza finalità, ma la cancellazione deve essere compatibile con gli obblighi applicabili e con la necessità di poter dimostrare il funzionamento del sistema per il periodo rilevante. La tensione tra minimizzazione, limitazione della conservazione ed esigenze difensive non è risolta dal decreto.

10.2. Art. 22 GDPR, decisioni automatizzate e spiegabilità

Il rapporto tra art. 17 del D.Lgs. 160/2026 e diritti di accesso o informazione previsti dal GDPR deve essere ricostruito soltanto nei limiti delle fonti qui confermate. L’art. 17 riguarda l’accesso a elementi di prova pertinenti al funzionamento del sistema e al danno; il richiamo all’art. 82 GDPR nell’art. 16, comma 3, lascia ferma la distinta tutela risarcitoria prevista dal regolamento. Non viene utilizzata, in questa revisione, giurisprudenza europea non verificata.

In termini interpretativi, la documentazione dovrebbe rendere comprensibili il percorso rilevante per il risultato e i dati o parametri pertinenti, senza che ciò implichi automaticamente la consegna del codice sorgente o di informazioni estranee alla domanda. La richiesta ex art. 17 e gli eventuali diritti di accesso previsti dal GDPR perseguono finalità diverse e devono essere coordinati evitando duplicazioni e divulgazioni non necessarie.

10.3. Art. 82 GDPR e cumulo delle azioni

L’art. 16, comma 3, salva espressamente l’art. 82 GDPR. Il danneggiato potrà quindi valutare se il fatto integra una violazione della disciplina dei dati, una violazione di obblighi del regolamento IA, un inadempimento contrattuale, un illecito extracontrattuale o più titoli collegati. Il cumulo non implica automaticamente il cumulo dei risarcimenti per lo stesso pregiudizio. Occorrerà distinguere danni, nessi, soggetti e fonti, applicando il divieto di duplicazione e le regole processuali pertinenti.

Quando il trattamento dei dati e l’uso del sistema di IA incidono sulla medesima decisione, la qualificazione dei fatti e la pluralità dei possibili titoli devono essere esaminate in modo unitario. Il richiamo all’art. 82 GDPR resta distinto dagli strumenti processuali del D.Lgs. 160/2026 e non comporta duplicazione del risarcimento per il medesimo pregiudizio.

11. Intelligenza artificiale e rapporto di lavoro

11.1. Recruiting, performance e organizzazione

Nel recruiting, un sistema può filtrare curricula, attribuire punteggi, ordinare candidati o suggerire esclusioni. Il rischio giuridico non dipende soltanto dall’accuratezza statistica, ma dalla qualità dei dati, dalla definizione dell’obiettivo, dalla possibilità di contestare l’esito e dalla supervisione del datore. L’AI Act e il GDPR possono operare su piani distinti; il D.Lgs. 160/2026 offre strumenti probatori civili quando il danno è cagionato nell’utilizzo del sistema. Un candidato potrebbe chiedere documentazione relativa all’output, ai parametri, alla supervisione e alla decisione finale, ma l’esito dell’ordine dipenderà dalla verosimiglianza della domanda e dalla pertinenza.

La valutazione delle performance, il monitoraggio, l’organizzazione dei turni, il ranking e i sistemi disciplinari possono incidere sulla posizione del lavoratore. Il riferimento all’art. 4 dello Statuto dei lavoratori e agli obblighi informativi del datore è svolto in termini generali, perché il testo di tali disposizioni non è stato oggetto di verifica diretta in questa sede. In termini sistematici, il datore deve comunque interrogarsi sulla trasparenza del controllo, sulla base giuridica del trattamento, sull’accesso del lavoratore alle informazioni pertinenti e sulla possibilità che un output automatizzato influenzi decisioni sfavorevoli senza adeguata valutazione umana.

11.2. Discriminazione algoritmica e prova

La prova di una discriminazione algoritmica può essere difficile quando il datore non spiega variabili, gruppi di riferimento, soglie e processo decisionale. L’art. 17 può essere utile se la domanda è formulata come azione di risarcimento per danno cagionato nell’utilizzo di IA, anche senza allegare già una violazione specifica dell’AI Act. La presunzione dell’art. 18, invece, richiede una violazione di uno o più obblighi del regolamento. L’attore deve distinguere il fatto discriminatorio, il danno e la violazione regolatoria, evitando di far coincidere la mera differenza statistica con la responsabilità definitiva.

Le registrazioni della supervisione umana sono essenziali. Se l’operatore ha ricevuto un ranking e lo ha seguito senza verifica, la prova è diversa dal caso in cui abbia controllato i criteri e motivato la decisione. La documentazione deve inoltre consentire di distinguere la selezione automatizzata dalla decisione finale. Una possibile lettura interpretativa è che l’organizzazione debba poter dimostrare non soltanto l’esistenza di una procedura, ma la concreta capacità del supervisore di correggere l’output.

11.3. Lavoro tramite piattaforma e rider

Nel lavoro tramite piattaforma, ranking, assegnazione di corse, sospensioni e reputazione digitale possono produrre effetti economici e professionali che richiedono tracciabilità e possibilità di contestazione. La presente revisione non attribuisce a decisioni non verificate principi specifici sul rapporto di lavoro o sul GDPR; le questioni relative alla qualificazione del rapporto e alle garanzie applicabili restano da verificare.

Il datore o gestore della piattaforma dovrebbe quindi distinguere i dati raccolti, le finalità, i criteri di ranking e la decisione umana. Le clausole contrattuali con fornitori tecnologici dovrebbero garantire accesso ai log pertinenti e cooperazione in caso di richiesta giudiziaria. Si tratta di raccomandazioni, non di un’estensione automatica del testo verificato del decreto. Le questioni relative alla qualificazione del rapporto di lavoro, alle garanzie specifiche e alle disposizioni non controllate direttamente devono restare aperte.

12. IA, sanità e responsabilità professionale

12.1. Sistemi diagnostici e decision support

Un sistema diagnostico o di supporto decisionale può produrre una previsione, segnalare un rischio o suggerire un esame. L’esito sfavorevole non dimostra da solo l’inadempimento: occorre ricostruire il rapporto tra output, dati disponibili, decisione clinica, supervisione e danno secondo le fonti applicabili. L’art. 17 può facilitare l’accesso alla documentazione tecnica e alla supervisione; l’art. 18 può operare soltanto nei limiti del presupposto regolatorio previsto dall’art. 16, comma 2.

La responsabilità sanitaria e professionale resta da qualificare sulla base del rapporto concreto e delle fonti applicabili. Il D.Lgs. 160/2026 non sostituisce i criteri di imputazione pertinenti; gli artt. 17 e 18 possono incidere, rispettivamente, sull’accesso alla documentazione e sulla prova del nesso soltanto quando ricorrano i presupposti normativi verificati.

12.2. Cartella clinica, logging e vicinanza della prova

La documentazione tecnica e il logging possono assumere rilievo nel processo quando il soggetto che li controlla si trovi in posizione di effettiva disponibilità della prova. L’analogia con altri settori non crea una presunzione generale: l’incompletezza può essere valutata insieme all’art. 17, ma gli effetti processuali dipendono dai presupposti e dall’inadempimento descritti dalla norma.

La distinzione tra danno da errore tecnico, danno da deficit informativo e danno derivante da una decisione non adeguatamente sorvegliata deve essere mantenuta. Il sistema di IA può incidere sulla comunicazione dei rischi o sulla scelta terapeutica, ma la responsabilità richiede la ricostruzione concreta della condotta, del danno e del nesso secondo le fonti applicabili.

12.3. Medico, struttura e produttore

Il medico può essere responsabile per l’uso non critico dell’output; la struttura per l’organizzazione, la selezione del sistema, la formazione e la supervisione; il produttore o fornitore per difetti, istruzioni o documentazione secondo il titolo applicabile. Il D.Lgs. 160/2026 non determina una gerarchia automatica. L’ordine ex art. 17 può essere rivolto anche al terzo che dispone dei documenti, mentre l’azione sostanziale resta da qualificare. Il contratto tra struttura e fornitore dovrebbe disciplinare versionamento, incidenti, accesso ai log, audit e cooperazione.

Il testo della legge 24/2017 non è stato verificato direttamente. Il suo eventuale rilievo è quindi trattato soltanto in termini generali e problematici: la disciplina della responsabilità sanitaria, se applicabile al caso, dovrà essere coordinata con il decreto, senza attribuire alla riforma del 2026 effetti modificativi non verificati. Una possibile lettura è che l’IA aggiunga un livello probatorio e organizzativo, non che sostituisca la distinzione tra decisione clinica e strumento di supporto.

13. IA, banche, assicurazioni e settore finanziario

13.1. Credito, antifrode e AML

Nel credito e nei sistemi antifrode, la documentazione deve consentire, per quanto pertinente, di comprendere la funzione dell’output e il ruolo dell’operatore. L’art. 17 può consentire di chiedere registrazioni, parametri e documentazione tecnica quando il danno sia reso verosimile; non viene attribuito in questa revisione alcun principio a una decisione europea non verificata.

L’art. 17 può consentire di chiedere parametri pertinenti, registrazioni e documentazione tecnica quando il danno sia reso verosimile. Nei casi di diniego automatizzato, l’attore dovrà allegare il provvedimento, il pregiudizio e il collegamento con il sistema. La banca o l’intermediario potrà contestare che l’output fosse soltanto un supporto, che la decisione fosse stata assunta da un operatore o che il danno dipendesse da dati esterni. La documentazione della supervisione diventa quindi decisiva.

13.2. Assicurazioni e azione diretta

L’art. 20 introduce un’azione diretta nei confronti dell’impresa di assicurazione che presta la copertura della responsabilità civile al convenuto, nei limiti delle somme per cui il contratto è stipulato. Il danneggiato può chiedere preventivamente al soggetto ritenuto responsabile se esiste una copertura; la richiesta non è condizione di procedibilità. Il soggetto deve comunicare entro trenta giorni l’esistenza del contratto, gli estremi e la denominazione dell’impresa. L’omessa o incompleta comunicazione può essere valutata ai sensi dell’art. 116 c.p.c.

Nel giudizio diretto è litisconsorte necessario il soggetto individuato quale responsabile. Sono opponibili le eccezioni derivanti dal contratto purché anteriori al sinistro; l’assicuratore che paga può rivalersi sull’assicurato nella misura in cui avrebbe potuto rifiutare o ridurre la prestazione; l’azione è soggetta al medesimo termine di prescrizione dell’azione contro il responsabile. La norma non introduce un obbligo assicurativo generale. In assenza di copertura, l’azione diretta non potrà essere esercitata contro un assicuratore inesistente, ma il soggetto potrà comunque agire contro il responsabile secondo il titolo applicabile.

13.3. Robo-advisory, compliance e DORA

Robo-advisory e sistemi automatizzati di compliance sollevano questioni analoghe: la rilevanza dell’output, il ruolo dell’operatore, la documentazione delle soglie e la gestione degli alert. DORA è menzionato come riferimento di contesto, ma il relativo testo non è stato oggetto di verifica diretta in questa sede. Non è quindi possibile attribuirgli obblighi o conseguenze specifiche. Il richiamo serve a segnalare che il settore finanziario opera in un ambiente regolato plurimo, nel quale la governance tecnologica deve essere coordinata con regole diverse senza presumere che il D.Lgs. 160/2026 le sostituisca.

14. Profili penali

14.1. Il nuovo art. 437-bis c.p.: collocazione e bene protetto

L’art. 12, comma 1, del D.Lgs. 160/2026 inserisce l’art. 437-bis c.p., rubricato “Omessa adozione di misure di sicurezza nei sistemi di intelligenza artificiale e alterazione illecita dei sistemi”. La fattispecie è collocata nel Libro II, Titolo VI, dei delitti contro l’incolumità pubblica, Capo I, dei delitti di comune pericolo mediante violenza. La collocazione orienta la lettura verso il pericolo per la vita, l’incolumità pubblica o individuale e, nelle ipotesi aggravate, per la sicurezza dello Stato. Non è corretto leggere la norma come una sanzione generale per ogni non conformità all’AI Act: il testo richiede condotte determinate e un evento di pericolo.

14.2. Primo comma: omissione di misure tecniche e di supervisione

Il primo comma punisce “chiunque” omette di adottare misure tecniche di sicurezza previste per progettazione, addestramento, produzione e immissione sul mercato di sistemi di IA ad alto rischio, idonee a prevenire malfunzionamenti o alterazioni del funzionamento, ovvero omette di adottare misure di sorveglianza umana. La condotta è omissiva e il soggetto attivo è indeterminato: può essere chiunque si trovi nella posizione concreta di adottare la misura. La norma non attribuisce automaticamente la responsabilità a ogni dipendente o a ogni fornitore; occorrerà individuare potere, dovere, disponibilità e collegamento con il sistema.

L’evento è il pericolo per la vita o l’incolumità pubblica o individuale. Se dal fatto deriva un pericolo per la sicurezza dello Stato, la pena è la reclusione da due a otto anni; altrimenti la reclusione è da uno a cinque anni. Il dolo deriva dalla condotta intenzionale di omettere, ma il terzo comma prevede una specifica riduzione quando uno dei fatti del primo comma è commesso per colpa grave. La lettura dell’elemento soggettivo deve quindi distinguere la forma dolosa dalla forma colposa espressamente contemplata.

14.3. Secondo comma: alterazione illecita

Il secondo comma punisce, salvo che il fatto costituisca più grave reato, chiunque altera sistemi di IA ad alto rischio, fuori dai casi indicati al primo comma, quando dall’alterazione deriva pericolo per la vita o l’incolumità pubblica o individuale. La pena è da due a sei anni; se deriva pericolo per la sicurezza dello Stato, è da tre a dieci anni. La condotta è commissiva e la clausola di riserva impone di coordinare la fattispecie con reati più gravi. L’alterazione può riguardare il funzionamento, ma il testo verificato non consente di specificare tecniche o modalità ulteriori. Sarà la prova a dover distinguere aggiornamento autorizzato, configurazione lecita, errore e alterazione illecita.

Il secondo comma non riproduce il riferimento alla colpa grave del terzo comma, che riguarda i fatti previsti dal primo comma. Non è quindi prudente estendere automaticamente la riduzione colposa al fatto commissivo del secondo comma. La clausola di riserva evita il concorso apparente quando l’alterazione integra un reato più grave, ma non risolve ogni possibile rapporto con reati informatici o contro l’incolumità: il materiale verificato non consente di costruire una casistica definitiva.

14.4. Terzo comma: colpa grave e riduzione di pena

Il terzo comma prevede che, se taluno dei fatti del primo comma è commesso per colpa grave, la pena è ridotta da un terzo a un sesto. La norma descrive una forma colposa qualificata e non una responsabilità per semplice negligenza. Il giudizio dovrà riguardare la gravità della violazione rispetto alle misure tecniche o di supervisione concretamente esigibili, alla posizione del soggetto, al rischio prevedibile e alle informazioni disponibili. Non basta che il sistema abbia prodotto un pericolo; occorre collegare la colpa grave all’omissione prevista dal primo comma.

14.5. Quarto comma: utilizzatore professionale

Il quarto comma riguarda l’utilizzatore professionale di sistemi di IA ad alto rischio che omette intenzionalmente di adottare misure di sorveglianza umana. Le pene sono quelle del primo comma, primo e secondo periodo, quando dalla omissione derivi rispettivamente pericolo per la vita o l’incolumità pubblica o individuale oppure pericolo per la sicurezza dello Stato. Il soggetto attivo è più specifico; la condotta richiede un’omissione intenzionale. Non è sufficiente dimostrare che la supervisione sia stata inefficace: occorre provare l’omissione intenzionale di adottare le misure.

14.6. Art. 612-quater c.p.: fattispecie preesistente

L’art. 612-quater c.p. non è stato introdotto dal D.Lgs. 160/2026. È stato inserito dall’art. 26, comma 1, lettera c), della legge 23 settembre 2025, n. 132, in vigore dal 10 ottobre 2025, e riguarda l’illecita diffusione di contenuti generati o alterati con sistemi di intelligenza artificiale. La distinzione deve essere sottolineata: si tratta di una fattispecie preesistente, resa rilevante ai fini della responsabilità 231 dal nuovo decreto.

La condotta consiste nel cagionare un danno ingiusto a una persona cedendo, pubblicando o altrimenti diffondendo, senza consenso, immagini, video o voci falsificati o alterati mediante IA e idonei a indurre in inganno sulla loro genuinità. La pena è la reclusione da uno a cinque anni. Il delitto è punibile a querela della persona offesa, salvo procedibilità d’ufficio se connesso con altro delitto procedibile d’ufficio, commesso nei confronti di persona incapace per età o infermità, oppure di una pubblica autorità a causa delle funzioni esercitate. Gli elementi da provare sono diffusione, assenza di consenso, idoneità decettiva, danno ingiusto e collegamento con la persona offesa.

14.7. Art. 359-ter c.p.p.: identificazione e localizzazione mediante IA

L’art. 13, comma 1, del D.Lgs. 160/2026 introduce l’art. 359-ter c.p.p., relativo all’identificazione e alla localizzazione mediante sistemi di IA per l’identificazione biometrica remota in tempo reale. In questa revisione è confermata l’introduzione della disposizione e la sua collocazione nel quadro delle modifiche processuali penali del Titolo II. Non vengono riprodotti ulteriori dettagli su autorizzazioni, termini, banche dati, urgenza, cancellazione o inutilizzabilità oltre quelli direttamente verificati nel testo disponibile; tali profili devono essere ricavati dal testo integrale della disposizione prima di essere utilizzati in un atto o parere.

L’art. 13, comma 1, inserisce l’art. 359-ter c.p.p., rubricato “Identificazione e localizzazione mediante sistemi di intelligenza artificiale per l’identificazione biometrica remota in tempo reale”, nella Parte II, Libro V, Titolo V, relativo all’attività del pubblico ministero. Quando occorre confermare l’identificazione di una persona indiziata di determinati delitti dell’allegato II al regolamento IA, puniti con reclusione non inferiore nel massimo a quattro anni, oppure ricercare e localizzare tale persona, può essere autorizzato l’impiego del sistema. La stessa tecnica è prevista per ricercare un latitante ai fini dell’esecuzione di un’ordinanza cautelare coercitiva o di un ordine di esecuzione non sospeso per i medesimi delitti.

Il confronto biometrico deve avvenire con una banca dati di riferimento adeguata alla specifica finalità, formata con i soli dati pertinenti e cancellata al termine della validità dell’autorizzazione. Il set non può essere alimentato incrementalmente rispetto ad autorizzazioni pregresse. È vietato l’uso di banche dati alimentate, anche in parte, mediante scraping non mirato o costituite in violazione delle disposizioni sulla protezione dei dati personali. La ricerca mirata può riguardare specifiche vittime di sottrazione, tratta o sfruttamento sessuale nell’ambito di un procedimento penale.

Il pubblico ministero chiede l’autorizzazione al giudice per le indagini preliminari. Il g.i.p. decide con decreto motivato, delimitando area geografica, persone ricercate e tempo strettamente necessario, non superiore a quindici giorni, prorogabile per periodi successivi di quindici giorni con decreto motivato. L’autorizzazione richiede la previa effettuazione delle valutazioni di cui all’art. 5, paragrafo 2, del regolamento IA. In urgenza, il pubblico ministero può disporre l’utilizzo con decreto motivato, da comunicare entro ventiquattro ore al g.i.p.; il giudice convalida nelle successive quarantotto ore e autorizza la prosecuzione. Se neppure il provvedimento del pubblico ministero può essere atteso, provvedono gli ufficiali di polizia giudiziaria, con trasmissione entro dodici ore, richiesta del p.m. entro ventiquattro ore e decisione giudiziale nelle successive quarantotto.

Il comma 8 stabilisce che i risultati non possono essere utilizzati se il sistema è stato impiegato fuori dai casi consentiti o se non sono state osservate le disposizioni dei commi 6 e 7. In tali casi dati personali, risultati e output sono cancellati, salvo che costituiscano corpo del reato. La sanzione è quindi di inutilizzabilità, accompagnata dalla cancellazione. Il divieto di scraping e la specificità della banca dati delimitano non solo la privacy, ma la stessa validità processuale dell’acquisizione.

14.8. Doppio binario tra prevenzione e repressione

La distinzione tra finalità preventive e finalità repressive deve essere ricostruita sulla base delle disposizioni effettivamente applicabili e dei presupposti del procedimento. In questa revisione non vengono attribuite a contributi redazionali non inclusi tra le fonti confermate soluzioni ulteriori rispetto al dato normativo verificato.

Sul piano interpretativo, la finalità dovrebbe essere verificata attraverso oggetto, procedimento, persone ricercate, banca dati, durata e uso successivo dei risultati. Non basta dichiarare “prevenzione” se il sistema è utilizzato per costruire una prova di reato già individuato; non basta dichiarare “repressione” se mancano gli indizi e il procedimento richiesti. Si tratta di una possibile lettura, non di una regola consolidata. L’art. 14, che interviene sulle norme di attuazione, coordinamento e transitorie del codice di procedura penale, è verificato soltanto quanto alla sua funzione; il contenuto specifico non è stato controllato direttamente.

15. D.Lgs. 231/2001

15.1. Il nuovo art. 25-vicies

L’art. 15, comma 1, inserisce dopo l’art. 25-undevicies il nuovo art. 25-vicies del D.Lgs. 231/2001, rubricato “Reati commessi con l’uso di sistemi di intelligenza artificiale”. Il comma 1 collega all’art. 437-bis c.p. la sanzione pecuniaria da seicento a mille quote. Il comma 2 collega all’art. 612-quater c.p. la sanzione da duecento a settecento quote. Il comma 3 applica le sanzioni interdittive previste dall’art. 9, comma 2, lettere b), c), d) ed e), escludendo la lettera a), cioè l’interdizione dall’esercizio dell’attività.

Le lettere b), c), d) ed e) corrispondono, secondo il materiale verificato, alla sospensione o revoca di autorizzazioni, licenze o concessioni; al divieto di contrattare con la pubblica amministrazione; all’esclusione da agevolazioni, finanziamenti, contributi o sussidi e all’eventuale revoca di quelli concessi; al divieto di pubblicizzare beni o servizi. L’esclusione della sanzione più grave appare, secondo la dottrina redazionale verificata, coerente con un approccio di proporzionalità, ma colloca le fattispecie in una fascia intermedia che dovrà essere valutata alla luce della prassi.

15.2. Interesse o vantaggio e governance

L’inserimento nel catalogo 231 non rende automaticamente responsabile l’ente per ogni uso di IA. Dovranno essere verificati i presupposti generali del D.Lgs. 231/2001, inclusi il reato-presupposto, la commissione nell’interesse o a vantaggio dell’ente e gli elementi organizzativi pertinenti. Il risk assessment dovrebbe includere sistemi ad alto rischio, contenuti sintetici, sicurezza, supervisione, rapporti con fornitori e gestione degli incidenti. I protocolli dovrebbero descrivere approvazione, controllo, registrazione, accesso e escalation. Il sistema disciplinare dovrebbe essere coordinato con le procedure interne; i flussi verso l’Organismo di Vigilanza dovrebbero consentire di rilevare anomalie senza trasformare ogni incidente tecnico in reato.

Queste indicazioni sono raccomandazioni operative e non obblighi specifici introdotti dal nuovo art. 25-vicies. Gli obblighi normativi già vigenti devono essere distinti dalle best practice e dalle scelte prudenziali. La cybersecurity, l’audit, la formazione, il versionamento e la conservazione documentale possono sostenere la difesa, ma non costituiscono automaticamente un modello organizzativo idoneo. La valutazione deve essere concreta e collegata ai rischi dell’ente.

15.3. Collocazione autonoma e art. 24-bis

Il legislatore ha scelto un titolo autonomo di reato-presupposto dedicato all’IA, anziché ricondurre le nuove fattispecie a categorie esistenti, come l’art. 24-bis sui delitti informatici, rispetto al quale l’art. 437-bis presenta contiguità. La scelta segnala che il disvalore non è soltanto informatico: riguarda sicurezza, incolumità e uso illecito del sistema. Sul piano sistematico, tuttavia, la collocazione autonoma richiederà di risolvere i rapporti con reati preesistenti e con i casi in cui la condotta tecnologica sia strumentale a un delitto più grave.

15.4. Querela per art. 612-quater e art. 8

La procedibilità di norma a querela dell’art. 612-quater crea un possibile disallineamento: la responsabilità dell’ente ex art. 25-vicies, comma 2, dipenderà in concreto dall’iniziativa della persona offesa, salvo le ipotesi di procedibilità d’ufficio. Il rischio di under-enforcement è stato segnalato dalla dottrina redazionale, soprattutto per contenuti sintetici diffusi da soggetti collettivi, campagne pubblicitarie o comunicative e deepfake non autorizzati. Si tratta di un problema di effettività, non di una regola che modifichi il regime di procedibilità.

Il rapporto tra la responsabilità dell’ente, l’art. 8 del D.Lgs. 231/2001 e l’elemento soggettivo della persona fisica resta una questione da verificare alla luce del testo integrale delle disposizioni applicabili. L’inserimento dell’art. 612-quater c.p. nel catalogo dell’art. 25-vicies non consente, da solo, di risolvere tale questione né di estendere analogicamente la responsabilità dell’ente.

16. Responsabilità degli amministratori

16.1. Adeguati assetti e decisioni sull’IA

Il collegamento tra D.Lgs. 160/2026 e responsabilità degli amministratori può essere tracciato attraverso gli artt. 2086, 2392 e 2476 c.c., richiamati in termini sistematici. Il testo di tali disposizioni non è stato oggetto di verifica testuale diretta in questa sede. Non è quindi possibile attribuire al decreto una modifica o una specifica regola applicativa. Una possibile lettura interpretativa è che la decisione di introdurre un sistema di IA debba essere inserita nella gestione dei rischi dell’impresa, con valutazione del caso d’uso, delle competenze, dei costi di controllo, della sicurezza, della documentazione e della continuità operativa.

La responsabilità degli amministratori non deriva dal semplice verificarsi di un danno algoritmico. Occorrerà ricostruire informazione disponibile, decisione assunta, deleghe, controlli, segnalazioni e possibilità di intervento. La documentazione di governance potrà dimostrare che il rischio era stato valutato e monitorato oppure che le decisioni erano state adottate senza adeguate informazioni. Il D.Lgs. 160/2026 offre elementi probatori rilevanti, ma non stabilisce un’autonoma responsabilità degli organi sociali.

16.2. Controllo, deleghe e flussi informativi

Gli organi amministrativi dovrebbero ricevere flussi periodici su incidenti, audit, aggiornamenti, deviazioni dall’uso previsto, reclami e richieste di accesso. Questa è una raccomandazione organizzativa. La responsabilità concreta dipenderà dal ruolo, dalla dimensione dell’impresa, dalla natura del sistema e dalla conoscibilità del rischio. Le deleghe non eliminano il dovere di controllo, ma la loro struttura può incidere sulla ricostruzione dei poteri e delle omissioni.

17. Contrattualistica AI

17.1. Allocazione della responsabilità e manleve

I contratti AI dovrebbero essere riconsiderati alla luce dell’art. 17. Una clausola di allocazione della responsabilità non può impedire al giudice di applicare il decreto, ma può organizzare rapporti interni, obblighi di cooperazione e disponibilità documentale. Le manleve devono descrivere fatti, limiti, esclusioni, massimali e procedure di gestione della controversia. È opportuno evitare formule generiche che attribuiscano al cliente ogni rischio dell’output senza distinguere difetti del sistema, uso non previsto, dati forniti dal cliente, mancata supervisione e modifiche del fornitore.

Il contratto dovrebbe stabilire chi decide finalità e modalità d’uso, chi controlla aggiornamenti, chi gestisce incidenti e chi conserva la documentazione. Le obbligazioni tecniche devono essere tradotte in prestazioni verificabili: consegna di report, indicazione della versione, accesso a registri pertinenti, notifica di modifiche, assistenza in audit e conservazione dopo la cessazione. Queste clausole non sostituiscono la legge, ma riducono il rischio che il terzo che dispone della prova resti estraneo o non collabori.

17.2. Audit, logging e document retention

I diritti di audit devono essere calibrati sul rischio e sulla riservatezza. Un audit senza limiti può essere impraticabile; un divieto assoluto può rendere impossibile accertare il funzionamento. Le parti dovrebbero disciplinare accesso remoto o in sede, consulenti indipendenti, segreti commerciali, report, rimedi e tempi. La document retention deve coordinare obblighi di protezione dei dati, sicurezza e necessità di prova. Non si tratta di conservare ogni dato a tempo indeterminato, ma di definire periodi e modalità coerenti con finalità, rischio e contenzioso prevedibile.

17.3. Incident notification, subfornitura ed exit strategy

La notifica degli incidenti deve identificare soglie, tempi, contenuti e interlocutori. La subfornitura deve essere trasparente quando modifica l’accesso ai dati, al modello o ai log. Il fornitore principale dovrebbe restare responsabile della cooperazione documentale anche quando l’informazione è presso un subfornitore. L’exit strategy deve prevedere esportazione dei log, documentazione della versione, cancellazione o restituzione dei dati, continuità del servizio e assistenza nella transizione.

Il collegamento tra art. 17, commi 1 e 6, è diretto: il giudice può ordinare al terzo che dispone degli elementi di prova e può sanzionarlo in caso di mancato adempimento senza giustificato motivo. Il contratto dovrebbe quindi evitare che il deployer non sappia chi possieda i documenti o che il provider possa cancellarli senza coordinamento. La clausola di cooperazione processuale non garantisce l’esito, ma rende più chiara la catena di disponibilità.

18. Il contenzioso futuro: scenari ipotetici

Gli scenari che seguono sono costruiti a fini illustrativi e non descrivono casi reali. Servono a mostrare come potrebbero operare art. 17, art. 18, art. 19 e art. 20, senza anticipare soluzioni giurisprudenziali.

18.1. Discriminazione nel recruiting

Un candidato escluso sostiene che un sistema abbia penalizzato il suo curriculum. Potrebbero essere convenuti datore di lavoro e, secondo il titolo della domanda, fornitore o integratore. L’attore dovrebbe provare candidatura, esclusione, uso del sistema, danno e fatti che rendano verosimile il collegamento. Potrebbe chiedere registri, versione del modello, criteri di ranking, supervisione e documentazione tecnica. L’art. 18 opererebbe soltanto se fosse allegata e dimostrata una violazione di obblighi del regolamento IA. Le difese potrebbero sostenere che il sistema fosse solo supportivo, che la decisione finale fosse umana, che non vi fosse differenza rilevante o che il danno dipendesse da fattori autonomi.

18.2. Errore diagnostico assistito da IA

La prova dovrebbe distinguere output, decisione clinica, supervisione, dati disponibili e dinamica dell’evento. L’art. 17 può consentire l’esibizione di log e documentazione tecnica se sono specificamente pertinenti e la domanda è resa verosimile; l’art. 18 opera soltanto se ricorre la violazione regolatoria richiesta dall’art. 16, comma 2.

18.3. Diniego automatizzato del credito

La documentazione sulla logica operativa del sistema può essere rilevante per comprendere il risultato, ma l’art. 17 richiede una domanda resa verosimile e elementi specificamente pertinenti. Le difese possono riguardare il ruolo meramente supportivo dell’output, la decisione umana o fattori esterni; tali questioni devono essere accertate nel caso concreto.

18.4. Danno da sistema industriale

Un sistema ad alto rischio controlla un impianto e un malfunzionamento provoca un danno. Il danneggiato potrebbe agire contro gestore, produttore, integratore e altri soggetti. L’art. 17 può raggiungere registri, gestione dei rischi, documentazione tecnica e supervisione. La qualificazione ex artt. 2050 o 2051 c.c. resta controversa e va valutata in concreto. L’art. 19 impedisce di considerare la conformità certificata come esimente automatica. Il convenuto potrebbe provare uso non conforme, manomissione, evento esterno o assenza di collegamento causale.

18.5. Deepfake e contenuto generato dall’IA

Una persona sostiene che immagini o voci alterate siano state diffuse senza consenso e abbiano prodotto un danno ingiusto. La fattispecie di riferimento è l’art. 612-quater c.p., preesistente al D.Lgs. 160/2026. Occorre provare diffusione, assenza di consenso, alterazione mediante IA, idoneità a ingannare e danno. La procedibilità è di norma a querela. Ai fini 231, il nuovo art. 25-vicies aggiunge la fattispecie al catalogo, con il possibile problema di under-enforcement se la querela non viene proposta.

18.6. Consulenza professionale assistita da IA

Un cliente sostiene che un parere o un atto predisposto con IA contenga un errore dannoso. Il professionista potrebbe rispondere del modo in cui ha selezionato, verificato e utilizzato l’output; il fornitore potrebbe essere coinvolto se il titolo della domanda riguarda il sistema. La responsabilità professionale resta da qualificare secondo le fonti applicabili, non verificate integralmente in questa sede. L’art. 17 può rendere accessibili documenti del sistema, ma non sostituisce la prova dell’inadempimento, del danno e del nesso.

19. Questioni aperte e primi problemi interpretativi

19.1. Frammentazione tra art. 16, comma 1, e comma 2

Dato certo: l’art. 17 si applica alle azioni contrattuali ed extracontrattuali cagionate nell’utilizzo di IA; artt. 18 e 19 richiedono danno derivante da violazione del regolamento IA. Possibile interpretazione: il legislatore ha voluto separare accesso alle prove e agevolazione causale. Problema rimesso alla giurisprudenza: definire quanto debba essere specifica l’allegazione della violazione per attivare gli artt. 18 e 19.

19.2. Quali obblighi del regolamento attivano l’art. 18

Dato certo: la norma parla di uno o più obblighi previsti dal regolamento IA. Possibile interpretazione: la presunzione riguarda ogni obbligo pertinente alla produzione del danno, non soltanto gli obblighi relativi ai sistemi ad alto rischio. Orientamenti dottrinali verificati: la dottrina segnala la frammentazione ma non una soluzione definitiva. Problema: stabilire se un obbligo organizzativo generale, un requisito tecnico o un obbligo relativo ad altra categoria di sistema possa essere sufficiente.

19.3. Natura dell’effetto del comma 5, secondo periodo

Dato certo: per mancata esibizione della documentazione del comma 2 il giudice ritiene come ammessi i fatti allegati, valutato ogni altro elemento. Possibile interpretazione: ficta confessio o presunzione legale relativa temperata. Problema: garantire contraddittorio e motivazione senza svuotare l’effetto della norma.

19.4. Fatti allegati dall’istante

Dato certo: la norma riguarda i fatti allegati dall’istante. Possibile interpretazione: solo fatti storici specifici e pertinenti alla documentazione omessa. Problema: distinguere fatto, inferenza tecnica, nesso, colpa e qualificazione giuridica.

19.5. Ordine ante causam

Dato certo: il testo dell’art. 17 disciplina l’ordine nelle azioni di risarcimento e non prevede espressamente un procedimento ante causam. Possibile interpretazione: accesso soltanto nel processo già instaurato, salvo strumenti ordinari compatibili. Problema: capire se e come esigenze urgenti di conservazione o acquisizione possano essere gestite senza estendere il testo per via interpretativa.

19.6. Posizione del terzo e sanzione pecuniaria

Dato certo: il terzo che dispone degli elementi può essere destinatario dell’ordine e, se non adempie senza giustificato motivo, riceve una pena pecuniaria da 1.500 a 10.000 euro. Possibile interpretazione: responsabilità processuale del detentore effettivo, non del soggetto solo formalmente collegato. Problema: adeguatezza della sanzione rispetto a grandi provider, costi di estrazione e rapporti transnazionali.

19.7. Prova contraria ex art. 18

Dato certo: il nesso tra violazione e danno è presunto salvo prova contraria. Possibile interpretazione: il convenuto deve provare fattore alternativo o irrilevanza della violazione. Problema: stabilire se la prova contraria riguardi causalità materiale, causalità giuridica o entrambe.

19.8. Art. 18 e criteri sostanziali

Dato certo: il decreto non detta un criterio generale di responsabilità e lascia ferme le altre discipline. Possibile interpretazione: la presunzione opera indipendentemente da 2043, 2050 e 2051, ma non li sostituisce. Problema: coordinare il nesso presunto con colpa, custodia, pericolosità, contratto e responsabilità da prodotto.

19.9. Art. 19 e direttiva 2024/2853

Dato certo: conformità e certificazione non escludono di per sé la responsabilità e resta ferma la normativa nazionale di recepimento della direttiva 2024/2853. Possibile interpretazione: la certificazione conserva valore probatorio. Problema: il testo della normativa nazionale di recepimento non è stato verificato e non consente una ricostruzione completa.

19.10. Cumulo con art. 82 GDPR

Dato certo: l’art. 16, comma 3, salva art. 82 GDPR. Possibile interpretazione: azioni e strumenti possono concorrere quando tutelano profili diversi. Problema: evitare doppio risarcimento e coordinare accesso ai documenti con minimizzazione e riservatezza.

19.11. Azione diretta senza obbligo assicurativo

Dato certo: l’art. 20 consente azione diretta contro l’assicuratore che presta copertura, entro il limite contrattuale; non prevede un obbligo generale di assicurazione. Possibile interpretazione: la norma opera soltanto se la copertura esiste. Problema: protezione effettiva del danneggiato quando nessuna polizza è stata stipulata.

19.12. Fattispecie penali di pericolo e normativa tecnica

Dato certo: l’art. 437-bis punisce omissioni e alterazioni quando deriva pericolo qualificato. Possibile interpretazione: la normativa tecnica aiuta a identificare le misure idonee, ma non sostituisce gli elementi della fattispecie. Problema: determinatezza della condotta, ruolo delle regole tecniche e distinzione tra errore, aggiornamento e alterazione illecita.

19.13. Residuo esercizio della delega

Il residuo esercizio della delega e l’eventuale adozione di ulteriori interventi non sono oggetto di una conclusione in questa revisione. Il testo integrale della legge delega e dei criteri direttivi non è stato verificato direttamente; non vengono quindi anticipate modifiche future sulla prova o sulla responsabilità.

20. Indicazioni operative

20.1. Checklist per provider

• Mappare ogni versione del sistema, indicando periodo di operatività, finalità e condizioni d’uso, per consentire l’identificazione della tecnologia rilevante in un eventuale giudizio.
• Conservare registri, documentazione tecnica, valutazioni del rischio e informazioni sulla supervisione in formati leggibili e con metadati, per sostenere la prova del funzionamento.
• Definire una procedura per rispondere agli ordini di esibizione, individuando responsabili, tempi, canali e misure di tutela dei segreti commerciali.
• Documentare aggiornamenti, retraining, modifiche alle soglie e interventi correttivi, per distinguere la versione contestata da quelle successive.
• Prevedere nei contratti con integratori e subfornitori obblighi di conservazione e cooperazione processuale, riducendo il rischio di essere considerati privi della prova o di non poterla reperire.
• Registrare incidenti, reclami, audit e misure correttive con indicazione delle limitazioni dell’accertamento, per dimostrare reazione e tracciabilità senza creare documentazione contraddittoria.

20.2. Checklist per deployer e utilizzatori professionali

• Definire finalità, contesto e limiti dell’uso del sistema, verificando che l’impiego effettivo non ecceda quello documentato.
• Assegnare la supervisione umana a ruoli con potere reale di intervenire, correggere o disattendere l’output.
• Registrare decisioni, eccezioni e motivi per cui l’output è stato seguito, modificato o rifiutato, con attenzione alla minimizzazione dei dati.
• Verificare periodicamente prestazioni, anomalie, bias, incidenti e deviazioni dal caso d’uso, conservando evidenze verificabili.
• Stabilire chi possiede log e documentazione quando il sistema è gestito da un fornitore esterno, per rendere effettivo l’art. 17.
• Preparare una procedura di sospensione o exit in caso di malfunzionamento, indisponibilità del provider o impossibilità di ricostruire le decisioni.

20.3. Checklist per datori di lavoro

• Identificare le decisioni lavoristiche influenzate da IA, distinguendo supporto, ranking e decisione finale.
• Informare i lavoratori e gli interessati secondo le disposizioni applicabili, precisando che il testo dell’art. 4 dello Statuto dei lavoratori non è stato verificato direttamente in questa sede.
• Verificare effetti discriminatori nel recruiting, nella valutazione, nei turni, nel ranking e nelle misure disciplinari.
• Conservare la documentazione della supervisione e della motivazione delle decisioni sfavorevoli, per sostenere trasparenza e difesa.
• Coordinare trattamento dati, accesso, minimizzazione e conservazione con la necessità di ricostruire l’output in caso di contenzioso.

20.4. Checklist per professionisti e strutture sanitarie

• Indicare quando l’IA è strumento di supporto e quando incide sulla decisione finale.
• Registrare versione, output rilevante, verifica professionale, eventuali scostamenti e motivazione della scelta.
• Integrare documentazione clinica e tecnica senza duplicare dati non necessari.
• Verificare che il professionista abbia tempo, competenze e strumenti per esercitare una supervisione effettiva.
• Conservare contratti e canali di cooperazione con il fornitore per ottenere log e documentazione tecnica.

20.5. Checklist per DPO e compliance officer

• Coordinare registri e documentazione AI con accountability, minimizzazione, DPIA e diritti di accesso, nei limiti delle fonti applicabili.
• Individuare i casi in cui un documento contiene dati personali, segreti commerciali o informazioni di terzi e definire accessi graduati.
• Mappare interazioni tra art. 82 GDPR e artt. 16-20 del decreto, evitando duplicazioni risarcitorie e lacune documentali.
• Verificare che le spiegazioni sul funzionamento siano comprensibili e coerenti con la Corte di giustizia dell’Unione europea, sez. I, 27 febbraio 2025, causa C-203/22, C.K. c. Magistrat der Stadt Wien quando pertinente.

• In caso di processo decisionale automatizzato, compresa la profilazione ai sensi dell’art. 22, par. 1, del GDPR, l’interessato può pretendere dal titolare del trattamento, a titolo di “informazioni significative sulla logica utilizzata”, che quest’ultimo gli spieghi, mediante informazioni pertinenti e in forma concisa, trasparente, comprensibile e facilmente accessibile, la procedura e i principi concretamente applicati per utilizzare, con mezzi automatizzati, i dati personali al fine di ottenerne un risultato determinato, come un profilo di solvibilità.

  La sentenza precisa altresì che, quando il titolare ritenga che tali informazioni contengano segreti commerciali o dati di terzi, deve comunicarle all’autorità di controllo o al giudice competente, cui spetta ponderare i diritti in gioco.

  Riferimenti editoriali: Foro italiano, 2025, 4, 4, 169; nota di PARENZO in Nuova Giurisprudenza Civile, 2025, 4, 972.

• Documentare decisioni di conservazione e cancellazione, spiegando la ragione della durata e la gestione di eventuali controversie.

20.6. Checklist per Organismi di Vigilanza 231

• Aggiornare il risk assessment in relazione all’art. 437-bis c.p. e all’art. 612-quater c.p., distinguendo obblighi normativi da best practice.
• Verificare protocolli su sistemi ad alto rischio, sorveglianza umana, alterazioni, contenuti sintetici e autorizzazioni.
• Stabilire flussi informativi su incidenti, reclami, richieste giudiziarie, audit e modifiche dei sistemi.
• Verificare interesse o vantaggio dell’ente e il rapporto con i soggetti apicali o sottoposti, senza presumere responsabilità per ogni incidente.
• Considerare il rischio di procedibilità a querela dell’art. 612-quater e le conseguenze di mancata iniziativa della persona offesa.

20.7. Checklist per organi amministrativi, IT e cybersecurity

• Approvare un inventario dei sistemi, dei responsabili, dei fornitori e dei casi d’uso.
• Ricevere report periodici su rischi, incidenti, versioni, audit e azioni correttive.
• Verificare controllo degli accessi, integrità dei log, backup, sincronizzazione temporale e gestione delle chiavi.
• Predisporre procedure di risposta a manomissioni, alterazioni e richieste dell’autorità giudiziaria.
• Integrare l’exit strategy nei contratti e nei piani di continuità, prevedendo trasferimento della documentazione e dei dati pertinenti.
• Documentare le decisioni strategiche e le ragioni per cui un rischio è stato accettato, mitigato o trasferito.

21. Conclusioni ragionate

Il D.Lgs. 160/2026 introduce cambiamenti reali ma circoscritti. Sul piano civile, gli artt. 16-20 istituiscono un insieme di strumenti processuali che rende più accessibili le informazioni sul funzionamento dei sistemi e, in una sottocategoria definita, presume il nesso tra violazione del regolamento IA e danno. L’art. 19 impedisce di trasformare la conformità in esenzione automatica. L’art. 20 rende azionabile la copertura assicurativa esistente, con limiti, eccezioni e litisconsorzio necessari. Sul piano penale, l’art. 437-bis crea una fattispecie di pericolo per omissioni di sicurezza, omissioni di supervisione e alterazioni illecite; l’art. 359-ter c.p.p. disciplina la biometria remota in tempo reale con garanzie giudiziali, temporali e di banca dati. Sul piano 231, l’art. 25-vicies inserisce due fattispecie nel catalogo con sanzioni pecuniarie e interdittive selezionate.

Le conseguenze più importanti derivano tuttavia dall’interazione con norme preesistenti. La responsabilità sostanziale resta affidata alle categorie generali del codice civile, alla disciplina da prodotto, al GDPR, ai contratti e alle regole professionali. La documentazione di governance può diventare prova, ma il decreto non risolve la sua autenticità, completezza, conservazione o interpretazione. La presunzione causale non copre ogni danno da IA e non esonera dalla prova della violazione e del danno. La procedibilità a querela dell’art. 612-quater può limitare l’effettività della responsabilità dell’ente. Le fonti non verificate, tra cui testo integrale della delega, normativa nazionale di recepimento della direttiva 2024/2853, DORA e legge 24/2017, non possono essere utilizzate per costruire conclusioni ulteriori.

Le questioni aperte sono numerose: natura dell’ammissione processuale, ordine ante causam, estensione degli obblighi rilevanti, prova contraria, rapporto con 2043, 2050 e 2051 c.c., cumulo con GDPR, coordinamento con attività di polizia e disciplina tecnica. In assenza di giurisprudenza applicativa del D.Lgs. 160/2026, le pronunce richiamate valgono solo per analogia e non sostituiscono l’elaborazione che seguirà. La linea prudente per imprese e professionisti è considerare la governance un’infrastruttura di responsabilità: non elimina il rischio, ma rende più verificabile la condotta, più ordinata la difesa e più chiaro il rapporto tra sistema, organizzazione e danno.

FAQ finali

1. Il D.Lgs. 160/2026 introduce una responsabilità civile generale per l’IA?

No. Introduce soprattutto strumenti processuali civili e lascia alle discipline generali e speciali l’individuazione del criterio sostanziale di imputazione.

2. L’art. 17 si applica solo quando è violato l’AI Act?

No. Ai sensi dell’art. 16, comma 1, l’art. 17 si applica alle azioni contrattuali ed extracontrattuali per danni cagionati nell’utilizzo di un sistema di IA. La violazione dell’AI Act è richiesta per gli artt. 18 e 19.

3. La presunzione dell’art. 18 esonera dalla prova del danno?

No. Presume il nesso tra violazione di obblighi del regolamento IA e danno, salvo prova contraria. L’attore deve provare o allegare in modo adeguato violazione e danno.

4. La certificazione AI Act esclude la responsabilità?

No. L’art. 19 stabilisce che conformità e certificazione non escludono di per sé la responsabilità, pur potendo avere rilievo probatorio.

5. Il giudice può ordinare documenti anche a un terzo?

Sì. L’art. 17 consente l’ordine alla parte o al terzo che dispone degli elementi di prova. Il terzo può essere sanzionato se non adempie senza giustificato motivo.

6. Che cosa accade se manca la documentazione del comma 2?

Il giudice può desumere argomenti di prova per l’inadempimento generico; se l’inadempimento riguarda la documentazione del comma 2, valutato ogni altro elemento, ritiene come ammessi i fatti allegati dall’istante.

7. L’art. 437-bis punisce ogni violazione di sicurezza?

No. Richiede omissioni o alterazioni relative a sistemi di IA ad alto rischio e un pericolo per la vita, l’incolumità pubblica o individuale oppure per la sicurezza dello Stato.

8. L’art. 612-quater è stato introdotto dal D.Lgs. 160/2026?

No. È stato introdotto dalla legge 132/2025 ed è stato reso rilevante ai fini 231 dal nuovo art. 25-vicies.

9. Chi autorizza la biometria remota in tempo reale nel procedimento penale?

Il pubblico ministero richiede l’autorizzazione e il giudice per le indagini preliminari autorizza con decreto motivato; sono previste procedure urgenti di convalida.

10. Il decreto impone un’assicurazione per i danni da IA?

No. L’art. 20 consente l’azione diretta contro l’assicuratore che presta una copertura esistente, nei limiti del contratto, ma non istituisce un obbligo assicurativo generale.

Fonti normative

• Decreto legislativo 9 settembre 2026, n. 160, “Adeguamento della normativa nazionale alle disposizioni del regolamento (UE) 2024/1689 ...”, in vigore dal 30 settembre 2026. Sono utilizzati, nei limiti verificati, l’art. 16 sull’ambito di applicazione e sulla salvezza dell’art. 82 del regolamento (UE) 2016/679, l’art. 17 sull’ordine di esibizione e sui relativi presupposti ed effetti, gli artt. 18 e 19 nei limiti del presupposto regolatorio indicato dall’art. 16, gli artt. 12-15 per le modifiche penali e processuali richiamate nel titolo e nel sommario, nonché il titolo e il sommario del decreto.
• Legge 23 settembre 2025, n. 132, “Disposizioni e deleghe al Governo in materia di intelligenza artificiale”; è confermato che l’art. 26, comma 1, lettera c), ha inserito l’art. 612-quater c.p., in vigore dal 10 ottobre 2025.
• Regolamento (UE) 2024/1689 del Parlamento europeo e del Consiglio, del 13 giugno 2024, che stabilisce regole armonizzate sull’intelligenza artificiale.
• Direttiva (UE) 2024/2853 del Parlamento europeo e del Consiglio, del 23 ottobre 2024, sulla responsabilità per danno da prodotti difettosi; il termine di recepimento è il 9 dicembre 2026. La normativa italiana di recepimento non è stata verificata.
• Regolamento (UE) 2016/679, limitatamente al richiamo espresso all’art. 82 contenuto nell’art. 16, comma 3, D.Lgs. 160/2026.
• Art. 437-bis c.p., introdotto dall’art. 12, comma 1, D.Lgs. 160/2026 e in vigore dal 30 settembre 2026; art. 612-quater c.p., inserito dall’art. 26, comma 1, lettera c), legge 23 settembre 2025, n. 132.
• Art. 359-ter c.p.p., introdotto dall’art. 13, comma 1, D.Lgs. 160/2026.
• Art. 25-vicies D.Lgs. 8 giugno 2001, n. 231, in vigore dal 30 settembre 2026: sanzione da 600 a 1.000 quote per l’art. 437-bis c.p., da 200 a 700 quote per l’art. 612-quater c.p. e applicazione delle sanzioni interdittive di cui all’art. 9, comma 2, lettere b), c), d) ed e).