Contenuto realizzato con il supporto di strumenti di intelligenza artificiale e revisionato dall'autore.
Un singolo incidente informatico, gestito senza un sistema di controllo integrato, può aprire quattro fronti sanzionatori: fino a 1.549.370 euro di sanzione pecuniaria ex D.Lgs. 231/2001, fino a 10 milioni di euro o al 2% del fatturato per violazioni NIS2 dei soggetti essenziali (7 milioni o 1,4% per i soggetti importanti), fino a 20 milioni di euro o al 4% del fatturato globale per violazioni GDPR e, per gli obblighi dell'AI Act, fino a 15 milioni di euro o al 3%: per i sistemi ad alto rischio dell'Allegato III questi obblighi si applicano dal 2 dicembre 2027. Sono massimi teorici, ma i procedimenti possono sommarsi in capo a un'azienda che ha gestito in silos ciò che avrebbe dovuto governare come sistema unico.
Quattro normative, un solo fatto: ecco perché il modello a silos non regge più
Immaginate questo scenario: un'azienda subisce un attacco ransomware. Il sistema di intelligenza artificiale usato per la gestione delle anomalie di rete non segnala l'intrusione in tempo utile. I dati di migliaia di clienti vengono esfiltrati. L'amministratore delegato non era stato formato sulle procedure di incident response. La notifica al Garante non parte entro le 72 ore previste dal GDPR.
In quel momento si aprono contemporaneamente quattro fronti. Il Garante Privacy avvia un'istruttoria per violazione dell'art. 33 GDPR. L'ACN verifica se l'azienda rientra nel perimetro NIS2 e se le misure di gestione del rischio informatico erano adeguate. La Procura valuta se il difetto organizzativo configuri una colpa di organizzazione ai sensi del D.Lgs. 231/2001 in relazione al reato-presupposto di accesso abusivo a sistema informatico. E, se il sistema AI era classificabile come strumento di monitoraggio ad alto rischio, l'AgID o l'ACN — autorità di controllo designate dal D.Lgs. 7 ottobre 2026, n. 179 — possono avviare una verifica per violazioni dell'AI Act.
Quattro autorità distinte. Quattro procedimenti paralleli. Una sola omissione alla radice: l'assenza di un assetto organizzativo unitario che presidiasse tutti e quattro i rischi come un sistema coerente, non come quattro checklist separate.
Dal 1° novembre 2026: l'enforcement NIS2 è operativo
L'ACN ha concluso il periodo di accompagnamento il 31 ottobre 2026. Da novembre 2026 la fase di accompagnamento prevista dalla normativa tecnica si è chiusa: per i soggetti essenziali e importanti ai sensi del D.Lgs. 4 settembre 2024, n. 138 — recepimento italiano della Direttiva NIS2 — valgono le misure di gestione del rischio informatico nella loro pienezza, con verifiche ispettive e sanzioni dirette.
Questo passaggio ha una ricaduta diretta sulla compliance 231. Il Documento CNDCEC di maggio 2026 sulla cybersecurity e il Modello 231 ha chiaramente indicato che i rischi informatici devono essere integrati organicamente nel MOG — cioè nel modello di organizzazione, gestione e controllo previsto dal D.Lgs. 231/2001 — e non trattati come adempimento parallelo. Un'azienda in perimetro NIS2 che non ha coordinato il proprio piano di gestione del rischio informatico con la parte speciale del modello 231 dedicata alla cybersecurity presenta già oggi una lacuna organizzativa rilevante su entrambi i fronti.
Il D.Lgs. 160/2026: quando l'AI diventa reato-presupposto
Il D.Lgs. 9 settembre 2026, n. 160 ha inserito nel catalogo dei reati-presupposto del D.Lgs. 231/2001 il nuovo art. 25-vicies, dedicato ai reati commessi con l'uso di sistemi di intelligenza artificiale. La norma non crea una responsabilità automatica per ogni utilizzo di un sistema AI: la responsabilità dell'ente sorge solo quando il reato-presupposto viene commesso nell'interesse o a vantaggio dell'ente e si dimostra la colpa di organizzazione specifica, cioè il difetto di presidi destinati a prevenire quel tipo di condotta.
Il punto pratico è sottile ma determinante. Un sistema di AI usato per la selezione del personale, per la valutazione del credito o per il monitoraggio dei dipendenti può configurare reati di discriminazione o violazione della privacy se non è governato da procedure interne adeguate. Quelle stesse procedure — mappatura del sistema, analisi di rischio, supervisione umana delle decisioni — coincidono quasi esattamente con gli obblighi previsti dall'AI Act per i sistemi ad alto rischio. Costruire due documenti separati, uno per l'AI Act e uno per il 231, non è solo inefficiente: è pericoloso, perché introduce il rischio di disallineamento e di lacune che sfuggono a entrambi i presidi.
Cosa dice la Cassazione: la colpa di organizzazione non si presume
La giurisprudenza recente ha chiarito il perimetro della responsabilità dell'ente con tre pronunce di rilievo sistematico.
Con la sentenza Cass. pen., Sez. IV, 4 marzo 2026, n. 8397 (ud. 28 gennaio 2026), la Corte ha ribadito che "la mera assenza o inidoneità degli specifici modelli di organizzazione non è sufficiente a fondare la responsabilità dell'ente": serve la dimostrazione concreta della colpa di organizzazione come elemento costitutivo autonomo del fatto tipico, distinto dalla colpa individuale dell'autore del reato. Non basta, insomma, che il modello non esista o sia scritto male: occorre che il difetto organizzativo abbia concretamente favorito la commissione del reato.
La Cass. pen., Sez. IV, 23 maggio 2026, n. 18643 ha precisato che la colpa di organizzazione dell'ente non è automatica rispetto a quella dell'apicale: anche quando l'autore del reato è un soggetto in posizione apicale, l'accusa deve dimostrare separatamente il deficit organizzativo dell'ente come tale.
La Cass. pen., Sez. III, 7 luglio 2026, n. 34744 (Pres. Aceto, Rel. Di Stasi) ha affrontato il rapporto tra colpa di organizzazione e prescrizione del reato-presupposto, chiarendo che gli elementi costitutivi dell'illecito dell'ente — relazione organica e teleologica, colpa di organizzazione, nesso causale — devono essere tutti autonomamente accertati, anche quando il reato presupposto si estingue per prescrizione.
Lette insieme, queste tre sentenze disegnano un messaggio preciso per chi costruisce e mantiene sistemi di compliance: la qualità dell'assetto organizzativo — quali rischi siano stati mappati, quali controlli siano stati effettivamente operativi — è ciò che protegge l'ente, non la presenza cartolare del documento.
Il DDL del 4 agosto 2026: il modello preventivo diventa condizione per accedere al rito premiale
Il 4 agosto 2026 il Consiglio dei Ministri ha approvato, su proposta del Ministro della Giustizia, un disegno di legge di revisione organica del D.Lgs. 231/2001. Si tratta del primo tentativo di riscrittura complessiva del sistema da quando il decreto è entrato in vigore nel 2001. Il DDL deve ancora completare l'iter parlamentare e, fino alla sua entrata in vigore, continuano ad applicarsi le norme attuali.
La novità strutturale è la positivizzazione della colpa di organizzazione come criterio espresso di imputazione: la proposta elimina la diversa disciplina oggi prevista per reati commessi da soggetti apicali rispetto ai dipendenti, e impone all'accusa di individuare la carenza specifica del modello e dimostrarne il collegamento causale con il reato. La riforma rafforza anche il sistema premiale: l'ente che abbia adottato e attuato un MOG prima della commissione del reato può chiedere al giudice, entro novanta giorni dalla notifica dell'avviso di conclusione delle indagini preliminari, un termine per eliminare le carenze riscontrate — e l'accesso a questo percorso è subordinato alla preesistenza di un modello che abbia i requisiti minimi richiesti.
Vigilantibus iura subveniunt: il diritto soccorre chi si è organizzato in anticipo, non chi corre ai ripari dopo. È la logica che il DDL traduce in norma positiva.
Il sistema 231 — riformato o no — funziona esattamente su questo principio: non punisce chi voleva delinquere, ma chi non ha costruito le condizioni per prevenire.
Come costruire il modello unico: dove iniziare davvero
Il modello integrato non è un documento più lungo: è un'architettura di governance in cui le stesse funzioni aziendali presidiano rischi che appartengono a più normative. Concretamente, questo significa tre cose.
La prima è la mappatura unificata dei processi esposti. Un processo di selezione del personale che usa un sistema AI è contemporaneamente un processo a rischio 231 (discriminazione, tutela della privacy dei candidati), un processo a rischio AI Act (sistema potenzialmente ad alto rischio), e un processo a rischio GDPR (trattamento di dati di candidati, a volte dati particolari). Mappare quel processo tre volte in tre documenti diversi è uno spreco; peggio, produce disallineamenti. Mapparlo una volta, con un'analisi che identifica tutti i profili di rischio applicabili, è la sola soluzione che regge a un'ispezione.
La seconda è il coordinamento tra i presidi di controllo. L'Organismo di Vigilanza (OdV), il DPO (Data Protection Officer, cioè il responsabile della protezione dei dati), il CISO (Chief Information Security Officer) e il responsabile AI governance devono condividere flussi informativi strutturati. Non riunioni occasionali: protocolli scritti che definiscano chi notifica chi, entro quanto, e con quale contenuto. La Cass. pen., Sez. IV, n. 8397/2026 ha chiarito che il MOG deve dimostrare la sua efficacia pratica, non la sua eleganza teorica.
La terza è la gestione unificata degli incidenti. Un incidente informatico che coinvolge dati personali e sistemi AI deve attivare, in modo coordinato e nei tempi rispettivi, la notifica al Garante (72 ore dalla conoscenza, ex art. 33 GDPR), la segnalazione all'ACN (24 ore per la pre-notifica, 72 ore per la notifica definitiva in ambito NIS2), il flusso informativo verso l'OdV (nei termini previsti dal MOG), e la procedura di incident response AI se il sistema AI ha contribuito al danno.
Nota dall'esperienza dello studio
Nelle pratiche che seguiamo, l'errore più frequente non è l'assenza totale di documenti: è la moltiplicazione di documenti che non si parlano. L'azienda ha un MOG aggiornato l'anno scorso, un registro dei trattamenti GDPR aggiornato due anni fa, un piano di sicurezza NIS2 in corso di redazione e nessuno che sappia dove finisce l'uno e dove inizia l'altro. Quando arriva un'ispezione — o peggio, un incidente — il tempo che si perde a ricostruire chi doveva fare cosa è spesso il fattore che trasforma un problema gestibile in una contestazione formale. Il modello integrato non è un lusso organizzativo: è la condizione per poter dimostrare, in un procedimento, che l'organizzazione funzionava davvero.
Domande frequenti
La mia azienda ha già un MOG 231 aggiornato: devo rifarlo per integrare NIS2 e AI Act?
Non necessariamente da zero. Il punto di partenza è verificare se la parte speciale dedicata alla cybersecurity del MOG copre già i rischi informatici rilevanti anche ai fini NIS2, e se sono stati inseriti presidi specifici per i sistemi AI ora che il D.Lgs. 160/2026 ha introdotto il nuovo art. 25-vicies. Nella maggior parte dei casi si tratta di integrare sezioni esistenti piuttosto che riscrivere l'intero documento — ma l'integrazione deve essere documentata, approvata dall'organo dirigente e comunicata all'OdV.
Chi coordina OdV, DPO e CISO nell'impresa? Non esiste una figura unica.
È una delle domande più concrete che riceviamo. Non esiste una figura unica obbligatoria per legge: la soluzione dipende dalla dimensione e dalla struttura aziendale. Nelle PMI è spesso l'avvocato esterno o il compliance officer a svolgere una funzione di coordinamento. Ciò che conta è che i flussi informativi tra queste funzioni siano scritti, periodici e tracciabili — perché in caso di procedimento sarà su quei documenti che si costruisce o si smonta la prova dell'efficacia esimente.
Entro quando devo adeguare il MOG alle novità del D.Lgs. 160/2026 e del D.Lgs. 179/2026?
Il D.Lgs. 179/2026 è in vigore dal 23 ottobre 2026; il D.Lgs. 160/2026, che ha introdotto il nuovo art. 25-vicies nel catalogo 231, è in vigore dal 30 settembre 2026. Non esiste un termine transitorio espresso per l'aggiornamento del MOG, ma la giurisprudenza è chiara: il modello deve mantenere nel tempo la propria idoneità preventiva, e un MOG che non presidia rischi divenuti rilevanti per legge è già oggi un modello inadeguato. Aspettare equivale ad accettare consapevolmente il rischio di colpa di organizzazione.
Redazione - Staff Studio Legale MP
