Reati presupposto 231 e AI: cosa preparare (D.Lgs. 160/2026)

Il 15 settembre 2026 è stato pubblicato in Gazzetta Ufficiale il D.Lgs. 9 settembre 2026, n. 160, che dal 30 settembre porta l'intelligenza artificiale tra i reati presupposto 231.

Significa che un'azienda può rispondere in proprio, con sanzioni pecuniarie e interdittive, per reati commessi con o attraverso sistemi di AI.

Su questo decreto leggerai molti commenti giuridici. Questo non è uno di quelli: io sono uno sviluppatore, costruisco e integro sistemi AI per le aziende.

La domanda che mi interessa è un'altra. Quando qualcuno chiederà di dimostrare che l'azienda aveva messo in sicurezza i suoi sistemi AI, cosa gli mostri? Log, permessi, procedure, versioni. Roba tecnica.

Qui trovi cosa dice davvero il testo ufficiale, chi riguarda e la checklist tecnica di quello che serve predisporre. Ho letto il decreto direttamente sulla Gazzetta Ufficiale, non sulle sintesi circolate prima dell'approvazione definitiva.

In breve: il decreto aggiunge al D.Lgs. 231/2001 l'articolo 25-vicies, con due reati presupposto 231 sull'intelligenza artificiale: il nuovo art. 437-bis c.p. (omesse misure di sicurezza e sorveglianza umana sui sistemi AI ad alto rischio, e loro alterazione) e l'art. 612-quater c.p. (diffusione illecita di deepfake).

Inoltre, nelle cause civili per danni da AI, i log e la documentazione tecnica diventano prove che il giudice può ordinarti di esibire.

Cosa prevede il D.Lgs. 160/2026 in due minuti

Il decreto attua la delega della legge 23 settembre 2025, n. 132, la legge italiana sull'intelligenza artificiale. È diviso in tre parti, e solo due interessano le aziende private.

• Titolo I: uso dell'AI da parte delle Forze di polizia, dal riconoscimento facciale all'identificazione biometrica. Non riguarda le imprese, ma contiene indicazioni tecniche utili come riferimento.
• Titolo II, Capo I: nuovo reato all'art. 437-bis del codice penale e nuovo art. 25-vicies nel D.Lgs. 231/2001.
• Titolo II, Capo II: regole processuali per le cause di risarcimento dei danni causati da sistemi AI.
• Pubblicazione: Gazzetta Ufficiale, Serie Generale n. 214 del 15 settembre 2026.
• Entrata in vigore: 30 settembre 2026.

I due nuovi reati presupposto 231 sull'intelligenza artificiale

L'articolo 15 del decreto inserisce nel D.Lgs. 231/2001, dopo l'articolo 25-undevicies, il nuovo articolo 25-vicies, "Reati commessi con l'uso di sistemi di intelligenza artificiale". I reati che fanno scattare la responsabilità dell'ente sono due.

Art. 437-bis c.p.: misure di sicurezza e sorveglianza umana

È il reato nuovo, introdotto dall'articolo 12 del decreto. Riguarda i sistemi di intelligenza artificiale ad alto rischio, quelli individuati dall'AI Act, e punisce quattro condotte:

• Omesse misure tecniche di sicurezza: chi omette di adottare le misure previste per la progettazione, l'addestramento, la produzione e l'immissione sul mercato, idonee a prevenire malfunzionamenti o alterazioni, oppure omette le misure di sorveglianza umana. Reclusione da uno a cinque anni se ne deriva un pericolo per la vita o l'incolumità pubblica o individuale, da due a otto se il pericolo riguarda la sicurezza dello Stato.
• Alterazione dei sistemi: chi altera un sistema AI ad alto rischio, con pericolo per la vita o l'incolumità, rischia da due a sei anni, da tre a dieci se è in pericolo la sicurezza dello Stato.
• Colpa grave: se le omissioni del primo comma sono commesse per colpa grave, la pena è ridotta.
• Utilizzatore professionale: chi usa professionalmente un sistema ad alto rischio e omette intenzionalmente di adottare misure di sorveglianza umana è punito con le stesse pene del primo comma.

Due dettagli tecnici contano molto. Il primo: il reato richiede che dall'omissione derivi un pericolo concreto.

Il secondo: per chi usa il sistema, e non lo produce, la norma parla di omissione intenzionale della sorveglianza umana. Non basta una svista, ma "non avevamo previsto nessuno che controllasse" è esattamente il tipo di situazione su cui si discuterà.

Art. 612-quater c.p.: diffusione illecita di deepfake

Questo reato esiste già dal 10 ottobre 2025, introdotto dalla legge 132/2025. Punisce con la reclusione da uno a cinque anni chi causa un danno ingiusto a una persona cedendo, pubblicando o diffondendo senza il suo consenso immagini, video o voci falsificati o alterati con l'AI e idonei a ingannare sulla loro genuinità.

La novità del 30 settembre è che entra tra i reati presupposto 231: se il deepfake esce dall'azienda nel suo interesse o a suo vantaggio, per esempio in una campagna marketing, ne risponde anche l'ente.

Le sanzioni per l'azienda

Il valore di una quota va da circa 258 a 1.549 euro, secondo l'articolo 10 del D.Lgs. 231/2001.

In entrambi i casi si applicano le sanzioni interdittive dell'articolo 9, comma 2, lettere b), c), d) ed e): sospensione o revoca di autorizzazioni, licenze e concessioni, divieto di contrattare con la pubblica amministrazione, esclusione da agevolazioni e finanziamenti, divieto di pubblicizzare beni o servizi. Resta fuori la lettera a), l'interdizione dall'esercizio dell'attività.

La parte che riguarda tutti: i tuoi log diventano prova

Qui c'è la novità che, secondo me, peserà di più nella pratica quotidiana, perché non richiede un reato. Gli articoli 16-20 cambiano le regole delle cause civili per danni causati da un sistema di intelligenza artificiale, qualunque sistema, non solo quelli ad alto rischio.

• Accesso alle prove (art. 17): se chi ha subito il danno rende verosimile la sua domanda, il giudice può ordinarti di esibire gli elementi sul funzionamento del sistema. Tra questi il decreto cita espressamente i registri (log) dell'articolo 12 dell'AI Act, la documentazione sulla gestione dei rischi, la documentazione tecnica e i parametri di sorveglianza umana.
• Se non li esibisci: il giudice può trarne argomenti di prova. E se l'inadempimento riguarda proprio quella documentazione, ritiene ammessi i fatti sostenuti da chi ti ha fatto causa.
• Presunzione del nesso causale (art. 18): se il danno deriva dalla violazione di un obbligo dell'AI Act, il collegamento tra violazione e danno si presume, salvo prova contraria.
• La certificazione non basta (art. 19): la conformità all'AI Act, anche certificata, non esclude di per sé la responsabilità.
• Assicurazione (art. 20): chi vuole farti causa può chiederti se hai una polizza RC per quel danno, e hai 30 giorni per rispondere con gli estremi del contratto. Il danneggiato ha azione diretta verso l'assicuratore.

Tradotto in termini tecnici: un sistema AI senza log conservati e ricostruibili è un sistema che in tribunale lavora contro di te. Non per un reato, ma per una normale richiesta di risarcimento.

Ti riguarda davvero? I tre profili aziendali

La prima cosa da fare è capire in quale situazione ti trovi, perché gli obblighi sono molto diversi.

La maggior parte delle PMI sta nel terzo profilo. Non significa essere al riparo: il rischio deepfake e le regole sulla prova valgono anche per te.

Se hai un chatbot sul sito, ricordati anche degli obblighi di trasparenza che ho spiegato nell'articolo su cosa devi dichiarare secondo l'articolo 50 dell'AI Act.

Reati presupposto 231 e AI: la checklist tecnica

Ecco le misure che metterei in piedi in un'azienda che usa sistemi AI, in ordine di priorità. Nessuna richiede budget da multinazionale, ma tutte richiedono di essere documentate: una misura che esiste ma non lascia traccia, in un contenzioso, vale poco.

1. Inventario dei sistemi AI

Non puoi proteggere quello che non sai di avere. Serve un registro aggiornato con, per ogni sistema:

• Nome, fornitore e modello con la versione usata, per esempio via API.
• Finalità e processo aziendale in cui è inserito.
• Classificazione secondo l'AI Act: alto rischio, trasparenza, rischio minimo.
• Dati trattati, in particolare dati personali e categorie particolari.
• Responsabile interno e chi può modificarne la configurazione.

Includi anche gli strumenti usati "spontaneamente" dai dipendenti con account personali. È lì che nascono i problemi più frequenti.

2. Log: cosa registrare e per quanto

È il cuore di tutto. L'AI Act chiede ai sistemi ad alto rischio la registrazione automatica degli eventi e, a chi li usa, di conservare i log generati per almeno sei mesi, salvo diverse disposizioni.

Per gli altri sistemi non c'è un obbligo generalizzato, ma gli articoli 17 e 18 del decreto rendono comunque i log la tua prima difesa.

Per ogni interazione rilevante io registrerei:

• Timestamp e identificativo univoco della richiesta.
• Utente o processo che ha avviato la richiesta.
• Sistema, modello e versione, inclusa la versione del prompt di sistema o della configurazione.
• Input e output, o almeno un loro riferimento e un hash quando il contenuto è troppo sensibile per essere conservato in chiaro.
• Intervento umano: chi ha approvato, modificato o scartato l'output, e quando.
• Errori, blocchi e anomalie, compresi i rifiuti del modello e i timeout.

Due requisiti tecnici fanno la differenza. I log devono essere non modificabili: storage append-only o con blocco degli oggetti, accessi separati da chi amministra il sistema.

E devono essere ricostruibili: se in una causa ti chiedono cosa ha fatto il sistema il 12 marzo alle 10, devi poterlo estrarre in ore, non in settimane.

Come riferimento, per i sistemi usati dalle Forze di polizia lo stesso decreto prevede log non modificabili conservati per cinque anni. Non è un obbligo per le imprese, ma dà l'idea del livello che il legislatore considera serio.

3. Accessi e identità

L'art. 437-bis punisce anche chi altera un sistema. La prima difesa contro l'alterazione, interna o esterna, è controllare chi può toccare cosa.

• Autenticazione centralizzata con SSO e autenticazione a più fattori per tutti gli strumenti AI aziendali.
• Ruoli separati: chi usa il sistema non modifica prompt e configurazioni, chi li modifica non amministra i log.
• Chiavi API in un secret manager, mai nel codice o in file condivisi, con rotazione e limiti di spesa. Le chiavi rubate sono oggi uno dei vettori principali, come racconto nell'articolo sul threat report di Anthropic sulle API key.
• Revoca immediata degli accessi quando una persona cambia ruolo o lascia l'azienda.

4. Sorveglianza umana dimostrabile

Per chi usa sistemi ad alto rischio è il punto più delicato, perché l'omissione intenzionale è reato. Ma dimostrare la sorveglianza umana conviene a tutti. Serve:

• Una persona designata per ogni sistema, con competenze e formazione adeguate.
• Punti di controllo nel flusso: quali output richiedono approvazione prima di produrre effetti, per esempio lo scarto di un candidato.
• Un pulsante di arresto documentato: chi può fermare il sistema e come.
• Traccia dell'approvazione nei log, altrimenti la sorveglianza esiste solo sulla carta.

5. Misure di sicurezza contro malfunzionamenti e alterazioni

Il testo parla di misure "idonee a prevenire malfunzionamenti o alterazioni del funzionamento". In concreto, per chi sviluppa o integra sistemi AI:

• Versionamento di prompt, configurazioni, modelli e dati di addestramento, con change management e approvazione delle modifiche.
• Test prima del rilascio su casi noti, da ripetere a ogni cambio di modello o di fornitore.
• Protezione dagli input malevoli: prompt injection, documenti manipolati, dati avvelenati, soprattutto negli agenti che leggono email o pagine web.
• Permessi minimi per gli agenti: un agente AI non deve poter fare più di quello che serve al suo compito. Ho raccolto le regole pratiche nell'articolo sull'incidente degli agenti Claude.
• Monitoraggio in produzione di errori, anomalie e degrado della qualità, con soglie di allarme.

6. Policy interne

Le policy sono il ponte tra la parte tecnica e il Modello 231. Ne servono almeno tre, brevi e applicabili:

• Policy d'uso dell'AI: strumenti ammessi, dati che non si possono inserire, chi autorizza nuovi strumenti.
• Policy sui contenuti sintetici: nessuna immagine, video o voce di una persona reale generata o alterata senza consenso scritto, etichettatura dei contenuti generati, revisione prima della pubblicazione. È la misura diretta contro il rischio 612-quater.
• Procedura incidenti AI: cosa fare se un sistema produce output dannosi, come si conservano le prove, chi avvisare.

A questo si aggiunge la formazione: l'AI Act chiede già a chi usa sistemi AI di garantire un livello sufficiente di alfabetizzazione del personale. Tieni traccia di chi l'ha fatta e quando.

7. Fornitori e contratti

Se usi sistemi di terzi, molte delle prove che il giudice potrebbe chiederti stanno presso il fornitore. Nei contratti verificherei:

• Accesso ai log e tempi di conservazione garantiti.
• Documentazione tecnica e di gestione dei rischi disponibile su richiesta.
• Notifica dei cambi di modello e degli incidenti.
• Copertura assicurativa RC, tua e del fornitore, che includa i danni da sistemi AI.

Esempio pratico: una PMI con tre sistemi AI

Prendiamo un caso che vedo spesso: un'azienda di 40 dipendenti con un chatbot per il servizio clienti sul sito, un filtro AI per i CV dei candidati e un grafico che genera immagini per i social.

• Chatbot: non è ad alto rischio. Servono dichiarazione di trasparenza, log delle conversazioni con conservazione definita, prompt di sistema versionato e un canale per passare a un operatore umano. Se un cliente sostiene di aver ricevuto un'informazione sbagliata che gli ha causato un danno, i log sono la prova di cosa è stato detto davvero.
• Filtro CV: la selezione del personale rientra tra gli usi ad alto rischio dell'AI Act. Qui l'art. 437-bis si applica all'azienda come utilizzatore professionale: serve una persona che riveda gli scarti, log delle decisioni e degli override, formazione documentata.
• Immagini social: policy sui contenuti sintetici, nessun volto reale senza consenso scritto, revisione prima della pubblicazione. È il presidio contro il 612-quater.

Tre sistemi, tre livelli di rischio, tre set di misure diversi. Trattarli tutti allo stesso modo significa o spendere troppo sul chatbot, o troppo poco sul filtro CV.

Cosa fare adesso, e in che ordine

1. Entro il 30 settembre: inventario dei sistemi AI e policy sui contenuti sintetici. Sono le due cose che richiedono meno tecnica e coprono subito il rischio più diffuso.
2. Nelle settimane successive: log centralizzati e non modificabili per i sistemi in produzione, a partire da quelli ad alto rischio.
3. Poi: revisione di accessi e chiavi API, sorveglianza umana documentata, clausole contrattuali con i fornitori.
4. In parallelo: coinvolgi chi segue il tuo Modello 231 e l'Organismo di Vigilanza per aggiornare la mappatura dei rischi con i nuovi reati presupposto 231 dell'art. 25-vicies.

Se stai già lavorando sull'AI Act, molte di queste misure si sovrappongono a quelle che servono per rispondere a eventuali verifiche delle autorità, di cui ho parlato nell'articolo sui controlli UE sull'AI Act. Conviene farle una volta sola.

Cosa questo articolo non è

Questa è una lettura tecnica di un testo di legge, scritta da uno sviluppatore. Non è una consulenza legale e non sostituisce il parere di un avvocato penalista o di chi cura il tuo Modello 231.

L'interpretazione delle nuove norme, a partire dai confini di "alto rischio" e "utilizzatore professionale", la daranno la prassi e i tribunali. Il mio compito è un altro: fare in modo che, quando servirà dimostrare cosa hai fatto, i log, i permessi e la documentazione ci siano davvero.

Fonte: D.Lgs. 9 settembre 2026, n. 160, Gazzetta Ufficiale Serie Generale n. 214 del 15 settembre 2026, articoli 12, 15 e 16-20.

Leggi anche

• Chatbot sul sito e AI Act: cosa devi dichiarare (art. 50)
• Controlli AI Act: l'UE interroga 30 società, cosa fare ora
• Threat report Anthropic: le API key sono il nuovo bottino
• Anthropic, 4° incidente di Claude: cosa insegna sugli agenti

Conclusione

Con il D.Lgs. 160/2026 i reati presupposto 231 legati all'intelligenza artificiale smettono di essere un'ipotesi. Dal 30 settembre un'azienda può rispondere per omesse misure di sicurezza sui sistemi ad alto rischio e per i deepfake.

E in qualsiasi causa per danni da AI, i suoi log possono diventare la prova decisiva, a favore o contro.

La buona notizia è che le misure che servono sono le stesse di un sistema AI costruito bene: inventario, log non modificabili, accessi controllati, sorveglianza umana tracciata, policy chiare. Se vuoi capire da dove partire sui tuoi sistemi, scrivimi: ti dico cosa manca dal punto di vista tecnico e quanto lavoro serve per sistemarlo.