D.Lgs. 160/2026 e la riforma del D.Lgs. 231/2001: nuovi reati-presupposto, risk assessment e presidi di controllo per le imprese che utilizzano sistemi di AI

D.Lgs. 160/2026 e la riforma del D.Lgs. 231/2001: nuovi reati-presupposto, risk assessment e presidi di controllo per le imprese che utilizzano sistemi di AI

Abstract

Questo contributo si prefigge di analizzare l’art. 25-vicies del D.Lgs. 231/2001, introdotto con D.Lgs. 160/2026 a far data dal 30 settembre. Nello sviluppo del contributo vengono analizzati i reati presupposto introdotti nell’alveo della responsabilità amministrativa degli enti, quali imprese sono le più esposte al rischio di commissione di suddetti reati e dunque con quali modalità deve essere condotto il risk assessment per raggiungere una soddisfacente mitigazione del rischio.

Il nuovo art. 25-vicies: l’intelligenza artificiale entra nel catalogo 231

Con l’entrata in vigore del D.Lgs. 9 settembre 2026, n. 160, cioè dal 30 settembre 2026, il legislatore delegato ha compiuto un passaggio atteso già da quando è stato pubblicato lo schema di decreto legislativo[1]: i rischi connessi all’impiego di sistemi di intelligenza artificiale entrano formalmente nel perimetro della responsabilità amministrativa degli enti. L’art. 15 del decreto delegato inserisce nel D.Lgs. 8 giugno 2001, n. 231, il nuovo art. 25-vicies, rubricato “Reati commessi con l’uso di sistemi di intelligenza artificiale”, che aggancia la responsabilità dell’ente a due distinte fattispecie penali: il nuovo delitto di cui all’art. 437-bis c.p. e il delitto di illecita diffusione di contenuti generati o alterati con sistemi di AI di cui all’art. 612-quater c.p., già inserito dalla Legge delega 23 settembre 2025, n. 132.

Occorre subito sgombrare il campo da un equivoco ricorrente. L’introduzione dell’art. 25-vicies non crea una responsabilità dell’ente per ogni violazione dell’AI Act, né per ogni malfunzionamento di un sistema di AI. La responsabilità ex D.Lgs. 231/2001 sorge solo quando uno dei due reati-presupposto è commesso nell’interesse o a vantaggio dell’ente, in presenza degli ordinari criteri di imputazione soggettiva. La mera violazione tecnica di un obbligo regolatorio, l’output errato di un modello o un malfunzionamento isolato non sono sufficienti, di per sé, a integrare la responsabilità ai sensi dell’art. 25-vicies. Occorre tuttavia verificare in questi casi anche l’eventuale rilevanza di altri reati-presupposto già inclusi nel catalogo 231.

Per quanto concerne l’interesse o il vantaggio per l’ente, essi devono essere ricostruiti rispetto alla condotta contestata: in particolare, nelle ipotesi omissive possono assumere rilievo il risparmio sulle attività di verifica e sorveglianza, la riduzione del personale addetto ai controlli o l’accelerazione del rilascio del sistema per esigenze commerciali, a discapito della sicurezza. Per la diffusione illecita di contenuti, invece, possono rilevare la riduzione dei costi di produzione o l’utilità competitiva perseguita. La commissione del fatto da parte di un fornitore esterno – possibile in un campo come l’ICT in cui l’esternalizzazione di questi servizi è molto frequente – non comporta automaticamente l’imputazione all’impresa committente: occorrerà esaminare il rapporto concreto e i requisiti di cui all’art. 5 del D.Lgs. 231/2001.

I reati-presupposto: struttura e condotte a rischio per le imprese

L’art. 437-bis c.p.: omessa adozione di misure di sicurezza e alterazione illecita

Il nuovo art. 437-bis c.p., introdotto dall’art. 12 del decreto delegato, è collocato sistematicamente tra i delitti contro l’incolumità pubblica – subito dopo l’art. 437 c.p. sulle cautele contro infortuni sul lavoro – e si articola in quattro distinte ipotesi.

La prima è relativa all’omissione dolosa di misure di sicurezza o di sorveglianza umana (comma 1) e punisce «chiunque omette di adottare le misure tecniche di sicurezza, previste per la progettazione, l'addestramento, la produzione, l'immissione sul mercato di sistemi di intelligenza artificiale ad alto rischio, idonee a prevenire malfunzionamenti o alterazioni del funzionamento dei sistemi ovvero omette di adottare misure di sorveglianza umana [...] quando da tali omissioni derivi pericolo per la vita o l'incolumità pubblica o individuale. », La pena è la reclusione da uno a cinque anni, mentre nei casi in cui derivi un pericolo per la sicurezza dello Stato, la pena è aumentata da due a otto anni.

La seconda disposizione penale dell’articolo prevede l’alterazione illecita dei sistemi (comma 2). Essa prevede, con clausola di riserva, che «chiunque, al di fuori dei casi indicati al primo comma, altera sistemi di intelligenza artificiale ad alto rischio è punito, qualora dal fatto derivi un pericolo per la vita o l'incolumità pubblica o individuale». La pena in questo caso è la reclusione da due a sei anni, aumentata da tre a dieci anni in caso di pericolo per la sicurezza dello Stato.

Nei casi di omissione colposa (comma 3) la punibilità è estesa ai fatti del comma 1 commessi per colpa grave, con riduzione della pena «da un terzo a un sesto».

Infine, l’ultima ipotesi delittuosa è costituita dall’omissione intenzionale dell’utilizzatore professionale (comma 4): essa colpisce il deployer che «omette intenzionalmente le misure di sorveglianza umana», applicando le pene del primo comma quando dall’omissione derivi pericolo per la vita o l’incolumità pubblica o individuale, oppure per la sicurezza dello Stato.

Il reato di cui all’art. 437-bis c.p. è evidentemente di pericolo concreto poiché esso non presuppone necessariamente una lesione già verificatasi, ma impone di accertare il collegamento tra omissione o alterazione e pericolo per i beni protetti. Una decisione algoritmica errata, una carenza di documentazione o un difetto di sorveglianza non possono essere isolati da tale verifica. La previsione della colpa grave[2] rende necessario approfondire, tra l’altro, la conoscibilità del rischio, gli avvisi ricevuti, le carenze reiterate e l’effettiva disponibilità di misure preventive, senza presumere la colpa dalla sola verificazione dell’incidente.

Il riferimento ai sistemi “ad alto rischio” (ambito nel quale può sussistere la responsabilità ex art. 437-bis c.p.) richiede di considerare entrambe le vie di classificazione dell’art. 6 del Regolamento (UE) 2024/1689 e segnatamente i casi d’uso dell’allegato III, tenendo conto delle condizioni ed eventuali esclusioni applicabili. L’allegato III comprende, tra gli altri, specifici impieghi nella biometria, nelle infrastrutture critiche, nella selezione e gestione del personale, nell’accesso a determinati servizi essenziali e nell’amministrazione della giustizia. La qualificazione dipende dalla finalità e dalla funzione del singolo sistema: l’appartenenza dell’impresa a un settore o l’impiego di AI nella sicurezza informatica non bastano, da soli, a qualificare il sistema come ad alto rischio.

L’art. 612-quater c.p.: illecita diffusione di contenuti sintetici (deepfake)

Il secondo reato-presupposto – già introdotto dalla legge n. 132/2025 – punisce «chiunque cagiona un danno ingiusto ad una persona, cedendo, pubblicando o altrimenti diffondendo, senza il suo consenso, immagini, video o voci falsificati o alterati mediante l'impiego di sistemi di intelligenza artificiale e idonei a indurre in inganno sulla loro genuinità». Per le imprese, dunque, il rischio si annida in particolare nei processi di comunicazione, marketing e gestione del personale oltre che in quelli relativi all’ICT: campagne che simulano una testimonianza reale, contenuti promozionali che riproducono persone identificabili, comunicazioni che ricreano la voce o il volto di un dipendente senza autorizzazione. La produzione di un avatar interamente fittizio o la semplice generazione di un testo non integrano automaticamente questa fattispecie.

L’esposizione può riguardare anche contenuti diffusi in circuiti circoscritti: l’invio a clienti, partner o colleghi deve essere valutato rispetto alla condotta di cessione o diffusione prevista dalla norma. Sono scenari da approfondire la simulazione di un’approvazione commerciale da parte di una persona reale, la falsa testimonianza di un cliente, l’attribuzione a un concorrente di dichiarazioni mai rese o la manipolazione di una registrazione utilizzata in un conflitto lavorativo. I controlli devono intervenire prima della diffusione, poiché la successiva rimozione del contenuto può non impedire il danno già prodotto, tenuto conto che si tratta di un reato istantaneo.

Le sanzioni a carico dell’ente

Per il delitto di cui all’art. 437-bis c.p. la sanzione pecuniaria a carico dell’ente va da seicento a mille quote; per il delitto di cui all’art. 612-quater c.p. da duecento a settecento quote.

In entrambi i casi sono previste le sanzioni interdittive di cui all’art. 9, comma 2, lettere b), c), d) ed e)[3].

Le imprese più esposte: chi deve agire con maggiore urgenza

La riforma non riguarda in astratto ogni impresa che utilizzi un qualsiasi strumento di automazione. Per l’art. 437-bis c.p. il perimetro di rischio si concentra sulle imprese che sviluppano, immettono sul mercato o utilizzano professionalmente sistemi di AI ad alto rischio; per l’art. 612-quater c.p. rilevano invece le attività di cessione, pubblicazione o diffusione dei contenuti descritti dalla norma, anche mediante sistemi non classificati ad alto rischio. Tra le categorie più esposte si individuano:

In primo luogo, le imprese che utilizzano AI nelle infrastrutture critiche e nei relativi presidi di sicurezza: il punto 2 dell’allegato III riguarda infatti i sistemi destinati a essere componenti di sicurezza nella gestione e nel funzionamento delle infrastrutture digitali critiche, del traffico stradale o della fornitura di acqua, gas, riscaldamento o elettricità. L’esposizione può derivare dalla disattivazione di allarmi, dalla mancata gestione delle anomalie o dall’assenza di operatori capaci di interrompere l’esecuzione di decisioni pericolose.

Una seconda categoria di imprese a rischio sono quelle che utilizzano AI nei processi di selezione e gestione del personale: lo screening dei candidati e determinati sistemi di valutazione, assegnazione di compiti e decisione sui rapporti di lavoro rientrano nei casi d’uso dell’allegato III e la sorveglianza meramente formale espone a rischi di decisioni discriminatorie e di violazioni regolatorie, ma non determina automaticamente il reato di cui all’art. 437-bis c.p. Per quest’ultimo deve essere infatti verificato il pericolo per i beni indicati dalla norma: ad esempio, un sistema che assegna mansioni pericolose ignorando limitazioni sanitarie o requisiti di abilitazione può presentare un profilo diverso da un sistema che si limita a ordinare curricula.

Altro cluster di soggetti esposti al rischio afferisce alle imprese industriali, sanitarie e fornitrici di servizi essenziali: occorre esaminare in questo caso i sistemi impiegati come componenti di sicurezza di macchinari o dispositivi medici e quelli riconducibili ai casi d’uso dell’allegato III. Nei servizi idrici possono rilevare, ad esempio, sistemi che incidono sulla sicurezza del trattamento e della distribuzione dell’acqua; in ambito sanitario, specifici sistemi di triage di emergenza o integrati in dispositivi medici. La gestione operativa di un servizio essenziale non è, in ogni sua applicazione, ad alto rischio per definizione ma il rischio penale deve essere collegato alla concreta omissione o alterazione e al pericolo che ne deriva.

Infine è opportuno considerare le imprese che producono o diffondono contenuti generativi, comprese agenzie di comunicazione, broadcaster e società con attività di marketing: l’esposizione al rischio richiede di esaminare l’intera filiera, dalla disponibilità di immagini e campioni vocali fino alla pubblicazione da parte di agenzie, influencer o partner. L’assenza di un processo di ottenimento dei contenuti, elaborazione e approvazione facilita condotte illecite, ma il reato per intendersi consumato richiede anche l’idoneità ingannatoria e il danno ingiusto alla persona.

Le modalità concrete di esposizione dell’impresa

Nello sviluppo e nell’acquisto di sistemi, il rischio sussiste in primo luogo quando le verifiche di sicurezza vengono ridotte per rispettare tempi commerciali, quando il sistema è acquistato senza istruzioni e informazioni tecniche adeguate o quando nessuna funzione valuta se il suo impiego reale coincida con quello dichiarato dal fornitore.

Nell’esercizio dei sistemi, inoltre, assumono rilievo la mancata presa in carico degli allarmi, la disattivazione di controlli giudicati troppo frequenti, l’assenza di copertura della sorveglianza durante turni e assenze e l’affidamento sistematico agli output senza verifica. La pressione a mantenere la continuità produttiva può favorire la prosecuzione dell’utilizzo anche dopo anomalie significative. L’analisi deve individuare chi può decidere la sospensione e quali condizioni impongono l’escalation.

La qualità dei dati incide sulla sicurezza quando gli input sono incompleti, non aggiornati o incompatibili con le condizioni per cui il sistema è stato validato. Nei processi industriali, dati provenienti da sensori non calibrati possono alterare la valutazione di una situazione pericolosa; nella gestione delle mansioni, informazioni sanitarie o abilitazioni non aggiornate possono produrre assegnazioni inappropriate.

L’accesso privilegiato a modelli, dati e configurazioni costituisce un ulteriore punto di esposizione. Amministratori, manutentori e fornitori possono modificare soglie, disabilitare registrazioni o installare nuove versioni. L’impresa in questo caso deve distinguere l’attacco esterno di cui è vittima da condotte interne o omissioni organizzative eventualmente rilevanti ai fini 231.

Per i contenuti sintetici, infine, il rischio cresce quando i materiali originali sono raccolti senza verificarne la provenienza, le liberatorie non coprono la clonazione vocale o la manipolazione del volto e le campagne sono pubblicate attraverso account cui accedono più soggetti senza responsabilità definite. Una precedente autorizzazione all’uso di una fotografia in queste ipotesi non deve essere trattata automaticamente come consenso a qualunque elaborazione con AI ma devono essere verificati contenuto dell’autorizzazione, finalità, destinatari e versione concretamente diffusa.

Questi scenari costituiscono ipotesi di lavoro per il risk assessment e per ciascuno devono essere individuati la fattispecie potenzialmente rilevante, il soggetto che può realizzarla, il possibile interesse o vantaggio dell’ente e i presidi capaci di interrompere la sequenza della condotta.

Risk assessment e aggiornamento del Modello 231: metodo e presidi

Il punto di partenza: la mappatura dei sistemi AI realmente utilizzati

Il primo passo, spesso il più sottovalutato, è l’identificazione integrale dei sistemi di AI effettivamente in uso nell’organizzazione, inclusa la cosiddetta shadow AI: strumenti adottati informalmente dalle funzioni operative senza passare dai canali di approvazione ICT o Legal. Un censimento attendibile deve rispondere alle domande: quali sistemi sono in uso, in quali processi incidono, quale classificazione di rischio li accompagna e quale ruolo assume l’impresa rispetto a ciascuno (fornitore, importatore, distributore, utilizzatore professionale).

Il registro dei sistemi dovrebbe indicare almeno il processo servito, la finalità dichiarata e quella effettiva, il fornitore, la versione utilizzata, le integrazioni con altri sistemi, i dati trattati, le persone potenzialmente interessate e il grado di autonomia decisionale. Deve inoltre registrare il responsabile aziendale, la motivazione della classificazione e i documenti disponibili. Il censimento va verificato attraverso interviste ai process owner e tramite il confronto con acquisti, licenze, contratti e applicazioni autorizzate: una ricognizione affidata soltanto alla funzione ICT può non intercettare strumenti adottati direttamente da HR o Marketing.

L’impresa, per essere compliant con l’AI Act e di riflesso con l’art. 25-vicies del D.Lgs. 231/2001, deve riesaminare il proprio ruolo quando personalizza un sistema, ne cambia la finalità o lo commercializza con il proprio nome[4].

La proporzionalità dell’aggiornamento del Modello

L’inserimento di un nuovo articolo nel catalogo dei reati presupposto richiede una verifica dell’adeguatezza del sistema preventivo rispetto alle attività dell’ente ma non comporta necessariamente l’introduzione, per tutte le società, dello stesso protocollo dedicato. Se il censimento e l’analisi dei processi non individuano sistemi ad alto rischio né attività concretamente esposte all’art. 437-bis c.p., l’esito può essere documentato nel risk assessment, motivando la mancata introduzione di specifici presidi ulteriori. La conclusione deve derivare da una ricognizione attendibile e includere anche sistemi sviluppati, addestrati o in fase di acquisizione. In presenza di un’esposizione concreta, devono invece essere adeguati i protocolli pertinenti o introdotti quelli mancanti, considerando anche i controlli già operanti.

Una valutazione di non rilevanza dovrebbe identificare il perimetro esaminato, le funzioni consultate, le motivazioni della classificazione e le condizioni che rendono necessario il riesame. Nuovi acquisti, modifiche delle finalità, maggiore autonomia decisionale o integrazione in funzioni di sicurezza devono attivare una nuova valutazione.

L’esclusione dell’art. 437-bis c.p. non assorbe l’analisi dell’art. 612-quater c.p.: anche un’impresa priva di sistemi ad alto rischio può affidare a dipendenti o agenzie la produzione di immagini e voci sintetiche. Per quest’ultima fattispecie occorre verificare separatamente le attività di produzione e diffusione e l’adeguatezza delle regole già applicate a comunicazione, marketing e canali digitali.

La valutazione del rischio-reato: dal rischio AI al rischio 231

La mappatura dei sistemi quindi è la precondizione, non il risultato del risk assessment. L’analisi rilevante ai fini 231, come noto, non è quella del rischio tecnico del sistema in sé, ma quella del rischio-reato cioè in quali processi e con quale meccanismo causale la condotta di un soggetto apicale o sottoposto potrebbe integrare le fattispecie dell’art. 437-bis c.p. o dell’art. 612-quater c.p., nell’interesse o a vantaggio dell’ente.

Per ciascun sistema ad alto rischio identificato, il risk assessment dovrebbe valutare almeno: (i) la completezza e la documentazione delle misure tecniche di sicurezza adottate in fase di progettazione, addestramento e deploy; (ii) l’effettività della sorveglianza umana, non la sua esistenza formale, ma la capacità concreta del soggetto preposto di comprendere i limiti del sistema e di intervenire; (iii) la governance delle modifiche al sistema (aggiornamenti, nuovi addestramenti, variazione delle soglie di allerta), che costituisce un’area di esposizione specifica per il comma 2 dell’art. 437-bis; (iv) per l’art. 612-quater, la ricognizione autonoma degli strumenti generativi e dei flussi informatici, la pubblicazione o diffusione dei contenuti, anche interni, indipendentemente dalla classificazione del sistema come ad alto rischio e la conseguente gestione degli output del sistema generativo, con particolare attenzione ai flussi che portano alla diffusione esterna di contenuti sintetici.

Per ogni processo sensibile è utile documentare uno scenario sufficientemente preciso: ad esempio, la modifica della soglia di allarme per ridurre i fermi di un impianto o la prosecuzione dell’utilizzo dopo segnalazioni di pericolo o pubblicazione di una testimonianza artificiale senza consenso. A ciascuno scenario devono essere associati soggetti coinvolti, modalità di commissione, possibili utilità per l’ente, controlli esistenti e relativa evidenza. La valutazione del rischio residuo deve considerare l’effettivo funzionamento dei controlli, non soltanto la presenza di una procedura.

La gap analysis dovrebbe tradurre le carenze in interventi con responsabile, termine, risorse ed evidenza di completamento e le priorità dipenderanno dalla gravità delle conseguenze, dall’autonomia del sistema, dalla possibilità di rilevare tempestivamente l’anomalia e dalla vulnerabilità delle persone interessate. L’aggiornamento deve investire le attività sensibili della Parte Speciale, i protocolli, i flussi verso l’Organismo di Vigilanza (di seguito “OdV”) e, ove necessario, la Parte Generale e il sistema disciplinare.

L’autonomia della responsabilità dell’ente e la ricostruzione dei contributi individuali

L’art. 8 del D.Lgs. 231/2001 stabilisce che «la responsabilità dell'ente sussiste anche quando: a) l'autore del reato non è stato identificato o non è imputabile». Nei processi che impiegano AI, sviluppo, configurazione, manutenzione, utilizzo e sorveglianza possono essere distribuiti tra più persone e organizzazioni, rendendo complessa l’individuazione del contributo individuale. L’assenza di un autore nominativamente identificato non costituisce, quindi, una garanzia di esclusione della responsabilità dell’ente ma rimangono comunque necessari l’accertamento del reato-presupposto e degli ulteriori requisiti di imputazione: l’art. 8 non attribuisce soggettività penale al sistema di AI e non introduce una responsabilità dell’ente per il solo malfunzionamento, dunque anche in caso di mancata identificazione dell’autore del reato-presupposto sussisterà la responsabilità 231 per l’ente.

Per rendere verificabile questa catena, i protocolli dovrebbero permettere di ricostruire chi abbia definito la finalità del sistema, approvato il rilascio, modificato le configurazioni, ricevuto un allarme e deciso di proseguire l’utilizzo. La matrice delle responsabilità deve essere coerente con contratti, autorizzazioni e privilegi effettivi. Nei rapporti con soggetti esterni occorre chiarire quali attività siano loro affidate e quali verifiche rimangano interne, evitando zone prive di un responsabile o controlli reciprocamente presunti. La tracciabilità serve sia a prevenire queste lacune sia a ricostruire le decisioni in caso di contestazione.

I presidi di controllo da implementare o aggiornare

I presidi devono essere costruiti sul ruolo dell’impresa, sulle caratteristiche dei sistemi e sui processi effettivamente esposti. Gli obblighi direttamente imposti dall’AI Act devono essere individuati separatamente, verificandone ambito soggettivo, condizioni e decorrenza. Il rinvio ai requisiti europei non consente di qualificare ogni misura proposta come obbligo normativo già applicabile a qualunque impresa.

I processi aziendali di seguito descritti costituiscono indicazioni organizzative per la prevenzione del rischio-reato.

In primo luogo, per ciascun sistema ad alto rischio deve essere nominato un responsabile interno, con indicazione scritta di chi esercita la sorveglianza umana e con poteri effettivi di intervento, inclusa la possibilità di arrestare o correggere il sistema. Una firma a valle di un processo automatizzato non integra sorveglianza umana quando chi firma non comprende i limiti del modello o non dispone dell’autorità o della capacità tecnica per dissentire. L’attribuzione dei compiti deve distinguere chi propone il sistema, chi valuta sicurezza e conformità, chi autorizza l’uso e chi ne controlla il funzionamento. Per i sistemi più critici è opportuno separare sviluppo e validazione, nonché richiesta e approvazione delle modifiche. Devono essere previste sostituzioni in caso di assenza, accesso alle informazioni tecniche e risorse coerenti con le responsabilità.

La sorveglianza deve essere verificata con prove pratiche al fine di comprendere se l’operatore sappia riconoscere un output incompatibile con le condizioni operative, consultare informazioni alternative e arrestare il sistema senza aggravare il pericolo. Devono essere altresì definite soglie di intervento, tempi di risposta e modalità di passaggio a una gestione sicura ed occorre prevenire l’automation bias, ossia l’accettazione acritica delle indicazioni del sistema, attraverso formazione e criteri che consentano un riesame effettivo e infine le verifiche vanno ripetute dopo modifiche rilevanti o cambiamenti del contesto d’uso.

Con riferimento alla tracciabilità delle decisioni e dei controlli, la documentazione delle operazioni di sorveglianza umana, dei log di sistema e degli interventi deve consentire di ricostruire ciò che è effettivamente avvenuto[5]. La conservazione di questi elementi contribuisce alla prova dell’attuazione dei presidi, ma non costituisce un’esimente autonoma o una garanzia di esonero dalla responsabilità 231, che resta subordinato alle condizioni degli artt. 6 e 7 del decreto[6].

Per quanto concerne la gestione delle modifiche, ognuna di quelle rilevanti per il sistema – aggiornamenti del modello, variazione dei dati di addestramento, modifiche alle soglie di allerta – deve essere sottoposta a valutazione, autorizzazione e validazione proporzionate al rischio. Si noti però che la modifica non autorizzata non coincide automaticamente con il reato di alterazione: per l’art. 437-bis, comma 2, c.p. devono essere verificati anche gli ulteriori elementi della fattispecie e il pericolo richiesto. Il comma 3 riguarda invece i fatti del primo comma commessi per colpa grave, senza estendere indiscriminatamente la punibilità colposa a qualunque alterazione. Il processo di modifica dovrebbe prevedere richiesta motivata, valutazione dell’impatto, prova in ambiente separato, approvazione da parte di un soggetto distinto dall’esecutore e verifica dopo l’installazione e devono essere disponibili un inventario delle versioni e, quando tecnicamente possibile, una procedura di ripristino. Le modifiche urgenti richiedono criteri specifici e un riesame tempestivo, evitando che l’urgenza diventi una deroga permanente. Anche gli aggiornamenti automatici del fornitore devono essere governati: un sistema può cambiare comportamento senza una modifica richiesta dalla funzione aziendale.

Nei processi che comportano produzione e diffusione di contenuti sintetici, devono essere introdotte procedure di verifica del consenso, approvazione tracciata e controllo prima della pubblicazione. I contratti con i fornitori di contenuto devono prevedere obblighi di notifica e cooperazione in caso di incidente, oltre a diritti di audit. La procedura per i contenuti dovrebbe richiedere l’identificazione delle persone rappresentate, la verifica della provenienza dei materiali e l’acquisizione di un consenso documentato coerente con l’elaborazione e la diffusione previste[7]. Il controllo deve valutare se il contenuto attribuisca alla persona dichiarazioni, comportamenti o avalli non reali e se possa provocarle un danno. Prima della pubblicazione, il materiale va sottoposto a un’approvazione proporzionata al rischio, con coinvolgimento di Legal nei casi di riproduzione di persone reali, clonazione vocale o contenuti potenzialmente lesivi e deve essere conservata la versione approvata insieme alle autorizzazioni e ai canali consentiti; successive variazioni sostanziali richiedono un nuovo controllo[8].

Infine, con riferimento ai flussi informativi verso l’OdV, esso deve essere destinatario di informazioni dal contenuto strutturato su censimento dei sistemi AI e loro classificazione, modifiche rilevanti, anomalie e incidenti, esito dei controlli periodici e azioni correttive intraprese dall’ente. La funzione dell’OdV rimane quella di verifica indipendente dell’effettività dei presidi, senza che esso diventi gestore operativo dei sistemi. Il flusso periodico dovrebbe indicare nuovi sistemi, variazioni di impiego, verifiche svolte, carenze aperte e relativo piano di rimedio. Un flusso tempestivo dovrebbe essere previsto per incidenti con possibile rilevanza penale, disattivazione di presidi, modifiche non autorizzate e diffusione contestata di contenuti. L’OdV può verificare a campione il collegamento tra procedure ed evidenze, ricorrendo a competenze tecniche specialistiche ove necessarie. L’autorizzazione dell’utilizzo, la gestione degli allarmi e la conduzione operativa della sorveglianza rimangono affidate alle funzioni aziendali.

Controlli sul ciclo di vita e sulla catena di fornitura

Prima dell’acquisto o del rilascio di un software da implementare nell’operatività aziendale occorre acquisire informazioni sufficienti su finalità, limiti, prestazioni, istruzioni, sorveglianza e gestione delle anomalie. Per i sistemi che lo richiedono, vanno verificati documentazione tecnica, valutazioni di conformità e altri adempimenti pertinenti al ruolo dell’impresa e l’approvazione interna deve essere subordinata alla disponibilità di controlli effettivamente utilizzabili. La dichiarazione di conformità del fornitore non dimostra che l’azienda abbia configurato e impiegato correttamente il sistema ma al contrario sono necessari elementi probanti ulteriori a sostegno della tesi che l’ente abbia posto in essere tutte le misure idonee a garantire un presidio di controllo per la mitigazione del rischio di commissione di uno dei reati-presupposto dell’art. 25-vicies[9]. Questi presidi concretizzano, secondo il sistema e il ruolo, esigenze di robustezza e cibersicurezza.

I contratti con sviluppatori, fornitori e agenzie dovrebbero disciplinare informazioni tecniche da fornire, comunicazione delle modifiche, assistenza nella gestione degli incidenti, accessibilità delle evidenze e tempi di intervento nonché prevedere verifiche o audit, regole sul subaffidamento e rimedi per le violazioni. Per i contenuti sintetici, inoltre, devono essere documentati i materiali utilizzati, autorizzazioni e strumenti impiegati. Garanzie contrattuali e manleve non sostituiscono i controlli della committente e non trasferiscono per contratto la responsabilità penale o 231.

Formazione e gestione delle anomalie

La formazione deve differenziare sviluppatori, amministratori di sistema, operatori addetti alla sorveglianza, responsabili degli acquisti e personale che produce contenuti e deve vertere su condotte vietate, limiti dei sistemi, segnali di pericolo e modalità di segnalazione. Il sistema disciplinare deve ricomprendere, nei limiti applicabili, uso non autorizzato, aggiramento dei controlli e omissione delle segnalazioni previste.

La gestione degli incidenti deve stabilire chi valuta il rischio, chi dispone l’arresto o il passaggio a una modalità sicura e chi coordina gli adempimenti pertinenti. Per i contenuti illeciti, deve consentire il blocco della pubblicazione, la richiesta di rimozione ai partner e la gestione delle contestazioni. Vanno preservate le evidenze, ricostruite le cause e riesaminati i presidi prima della ripresa. Le eventuali comunicazioni a fornitori, autorità e persone interessate devono seguire la disciplina concretamente applicabile, senza confondere segnalazioni interne e notifiche obbligatorie.

Monitoraggio dell’effettività dei presidi

Il programma di controllo dovrebbe misurare la copertura del censimento, i rilasci autorizzati, le modifiche prive di approvazione, la tempestività di gestione degli allarmi, l’esito delle prove di arresto e la presenza dei consensi nei contenuti pubblicati. Le funzioni di controllo devono selezionare campioni basati sulla criticità e verificare la chiusura delle azioni correttive. I casi di ripetizione delle anomalie, ritardi e mancata disponibilità delle evidenze – comunicati tramite un idoneo sistema di flussi informativi come sopra accennato – devono alimentare il riesame del rischio residuo e le informazioni all’organo amministrativo e all’OdV.

L’OdV dunque deve poter comprendere e valutare criticamente le informazioni ricevute. Flussi che riportino soltanto il numero dei sistemi o l’assenza di incidenti non consentono, da soli, di verificare la qualità della mappatura e l’effettività della sorveglianza. È opportuno che le funzioni competenti forniscano anche motivazioni delle classificazioni, limiti delle verifiche eseguite, risultati delle prove e carenze non risolte. In questo modo, l’OdV può individuare gli approfondimenti necessari e verificare che le conclusioni tecniche siano coerenti con le attività e i presidi descritti nel Modello.

Quando le competenze interne all’OdV non consentano di valutare aspetti tecnici rilevanti, esso dovrebbe disporre di risorse allocate al suo budget annuale e accesso a specialisti quali consulenti esterni competenti in AI e data science[10]. L’apporto tecnico, quindi, deve sostenere la vigilanza e mantenere distinta la valutazione dei controlli dalla loro progettazione e gestione operativa.

Conclusioni operative

Il D.Lgs. 160/2026 non inventa una logica nuova per il sistema 231, ma al contrario porta nei processi assistiti dall’AI la stessa struttura che il D.Lgs. 231/2001 applica a ogni rischio organizzativo, struttura composta da questi step: valutare il rischio, attribuire responsabilità, definire regole applicabili, inserire controlli nel processo e verificarne l’attuazione. La discrasia rispetto al resto delle aree a rischio reato è nella velocità: versioni, dati, fornitori e finalità dei sistemi di AI evolvono più rapidamente di quanto qualsiasi procedura statica possa seguire. Le imprese che vorranno dimostrare l’adeguatezza del proprio Modello dovranno costruire presidi dinamici, capaci di riesaminare i controlli al mutare del profilo di rischio del sistema.

L’adeguatezza del sistema preventivo dipenderà dalla capacità di dimostrare che i controlli individuati per ciascuno scenario sono disponibili, conosciuti e concretamente applicati prima del fatto. Il Modello deve quindi collegare obblighi, responsabilità operative, risorse ed evidenze, con riesami attivati anche da nuovi utilizzi, modifiche del sistema e incidenti.