Dal 30 settembre 2026 l’omessa adozione delle misure tecniche di sicurezza e di sorveglianza umana nei sistemi di intelligenza artificiale ad alto rischio può assumere rilievo penale quando produce un pericolo per la vita o l’incolumità pubblica o individuale. Il decreto legislativo 9 settembre 2026, n. 160 inserisce nel Codice penale l’articolo 437-bis e amplia anche il catalogo dei reati presupposto della responsabilità degli enti. Per le imprese non basta quindi una policy generale sull’IA: occorre identificare i sistemi interessati, assegnare responsabilità, documentare i controlli e integrare l’analisi nel modello organizzativo 231.

La nuova disciplina non criminalizza ogni errore algoritmico. Il perimetro dipende dalla qualificazione del sistema, dalle misure di sicurezza previste, dall’omissione concretamente contestata e dall’esistenza del pericolo richiesto dalla fattispecie. Proprio per questo il controllo deve partire dall’inventario degli strumenti utilizzati e dai ruoli effettivamente assunti dall’organizzazione: fornitore, deployer, importatore, distributore o soggetto che modifica il sistema. Un software acquistato da terzi non rende automaticamente estranea l’impresa alle responsabilità connesse al suo impiego.

Risposta breve: che cosa cambia dal 30 settembre

L’articolo 12 del Dlgs 160/2026 introduce l’articolo 437-bis del Codice penale. La prima parte della norma punisce chi omette le misure tecniche di sicurezza previste per progettazione, addestramento, produzione o immissione sul mercato di sistemi di IA ad alto rischio, oppure omette le misure di sorveglianza umana, quando dall’omissione deriva pericolo per la vita o l’incolumità. La pena prevista è la reclusione da uno a cinque anni. Il controllo non può quindi essere ridotto alla sola cybersecurity: comprende qualità dei dati, robustezza, supervisione umana, gestione delle anomalie e possibilità di arrestare o correggere il funzionamento.

La disposizione riguarda inoltre l’alterazione o la manipolazione illecita di sistemi di intelligenza artificiale quando ne deriva il pericolo indicato dalla legge. L’azienda deve distinguere l’errore tecnico, la configurazione negligente e l’intervento deliberato, conservando log, versioni, autorizzazioni e tracciabilità delle modifiche. Senza queste evidenze diventa difficile ricostruire chi abbia effettuato un intervento, con quali privilegi e sulla base di quale procedura autorizzativa.

Il nuovo articolo 437-bis e i sistemi ad alto rischio

Il decreto nazionale rinvia alle definizioni del Regolamento UE 2024/1689. La qualificazione di un sistema come “ad alto rischio” non dipende dal fatto che l’algoritmo sia percepito come sofisticato o importante, ma dalle categorie e dalle condizioni previste dalla disciplina europea. Nelle imprese possono assumere rilievo, tra gli altri, sistemi destinati alla selezione del personale, alla gestione dei lavoratori, all’assegnazione dei compiti, alla valutazione delle prestazioni o a decisioni che incidono sull’accesso a servizi essenziali, nei casi e nei limiti stabiliti dal regolamento.

Il primo presidio è dunque un censimento reale. Per ogni applicazione devono risultare finalità, proprietario del processo, fornitore, versione, dati trattati, decisioni supportate o automatizzate, categorie di persone interessate e meccanismi di supervisione. L’inventario deve includere anche soluzioni inserite in piattaforme HR, gestionali, sistemi di controllo qualità o sicurezza fisica. Un servizio acquistato come funzionalità accessoria può comunque svolgere un’attività rilevante ai fini della classificazione.

Il secondo presidio riguarda le istruzioni e i limiti d’uso. L’adozione formale di un prodotto conforme non copre un utilizzo diverso da quello previsto, una configurazione che disattiva i controlli o l’alimentazione con dati non adeguati. Contratto, documentazione tecnica e procedure interne devono essere coerenti. Le modifiche sostanziali e gli aggiornamenti vanno valutati prima del rilascio in produzione, non soltanto dopo un incidente.

Sorveglianza umana, sicurezza tecnica e prova dei controlli

La sorveglianza umana deve essere effettiva. Nominare un responsabile senza garantirgli informazioni, competenze, tempo e potere di intervento non realizza il controllo richiesto. La persona incaricata deve comprendere gli output, riconoscere anomalie e bias, evitare l’affidamento automatico al risultato e poter interrompere o correggere il processo. Nei sistemi che incidono sulle persone, va inoltre definita una procedura per riesaminare decisioni contestate e registrare le motivazioni dell’eventuale conferma.

Le misure tecniche devono essere proporzionate al rischio e al ruolo dell’impresa. Test prima del rilascio, gestione degli accessi, segregazione dei privilegi, validazione dei dati, monitoraggio delle prestazioni, protezione da alterazioni e risposta agli incidenti devono essere documentati. È necessario individuare soglie che generano un allarme e stabilire chi decide il blocco del sistema. Le prove non consistono in un documento una tantum: servono verbali di test, ticket, log, registri delle modifiche, esiti del monitoraggio e tracciabilità delle azioni correttive.

Un punto delicato è il rapporto con il fornitore. I contratti dovrebbero disciplinare accesso alla documentazione, notifica delle vulnerabilità, tempi di intervento, aggiornamenti, audit, conservazione dei log e cooperazione in caso di indagine o incidente. Clausole generiche di esclusione della responsabilità non sostituiscono gli obblighi imposti dalla legge. L’impresa che utilizza il sistema deve sapere quali controlli restano al fornitore e quali devono essere svolti internamente.

Responsabilità dell’ente e aggiornamento del modello 231

Il Dlgs 160/2026 coordina il nuovo reato con il decreto legislativo 231/2001. L’inserimento nel catalogo dei reati presupposto rende necessario valutare se e come la fattispecie possa essere commessa nell’interesse o a vantaggio dell’ente. La revisione del modello non dovrebbe limitarsi ad aggiungere il numero dell’articolo in un elenco: occorre mappare i processi nei quali vengono progettati, acquistati, addestrati, configurati o utilizzati sistemi di IA e verificare i poteri decisionali e di spesa.

I protocolli devono coprire almeno l’approvazione dei nuovi sistemi, la classificazione del rischio, i test, la gestione delle modifiche, la supervisione umana, gli incidenti e i rapporti con i fornitori. L’organismo di vigilanza deve ricevere flussi informativi comprensibili: inventario aggiornato, incidenti significativi, deroghe, esiti degli audit e azioni correttive scadute. Un flusso composto soltanto da dichiarazioni di conformità non consente un controllo sostanziale.

Formazione e segregazione dei compiti completano il presidio. Chi sviluppa o configura il sistema non dovrebbe essere l’unico soggetto a validarne la sicurezza. Gli amministratori devono disporre di un quadro sintetico dei rischi, mentre le funzioni tecniche devono conservare le evidenze analitiche. Nei gruppi societari occorre chiarire quale entità assume le decisioni e dove sono conservati dati e log, evitando che la responsabilità si perda fra capogruppo, società operative e fornitori.

La verifica operativa da chiudere prima dell’entrata in vigore

Il controllo iniziale può essere organizzato in cinque passaggi: inventario dei sistemi; classificazione e ruolo dell’impresa; verifica delle misure tecniche; verifica della sorveglianza umana; raccordo con modello 231 e gestione degli incidenti. Ogni passaggio deve produrre un’evidenza datata e un responsabile. Le carenze non risolvibili entro il 30 settembre devono essere formalizzate con misure compensative, limitazioni d’uso e una scadenza ravvicinata, valutando se sospendere le funzioni più rischiose.

Un caso tipico è il software HR che ordina candidati o lavoratori sulla base di un punteggio. L’impresa deve sapere quali dati alimentano il risultato, quali decisioni ne dipendono, come interviene il responsabile umano e come vengono gestiti risultati inattendibili. Se l’output viene seguito automaticamente, il presidio umano esiste soltanto sulla carta. Lo stesso metodo vale per sistemi che governano macchinari, sicurezza fisica o accessi: la mappatura deve seguire il rischio prodotto dall’uso concreto.

La verifica deve coordinarsi con privacy, sicurezza sul lavoro, cybersecurity e diritto del lavoro, ma senza confondere i piani. Una valutazione d’impatto privacy non sostituisce automaticamente l’analisi richiesta per la sicurezza del sistema né il presidio 231; allo stesso modo, la conformità del fornitore non esaurisce gli obblighi dell’utilizzatore. Il fascicolo finale deve mostrare come le diverse valutazioni dialogano e quali controlli restano specifici.

In sintesi

Dal 30 settembre 2026 la sicurezza dei sistemi di IA ad alto rischio entra anche nel perimetro penale attraverso il nuovo articolo 437-bis. L’omissione di misure tecniche o di sorveglianza umana rileva quando determina il pericolo previsto dalla norma; il decreto amplia inoltre il rischio 231 per gli enti. Inventario, classificazione, supervisione effettiva, log delle modifiche e protocolli sugli incidenti diventano quindi evidenze centrali, non adempimenti accessori.

Mettere in sicurezza la governance dell’IA prima del 30 settembre

Le imprese che utilizzano sistemi di intelligenza artificiale nei processi operativi o nella gestione delle persone dovrebbero completare subito la mappatura e il raccordo con il modello 231. Un controllo indipendente consente di individuare sistemi non censiti, responsabilità non assegnate e misure di supervisione soltanto formali, prima che un’anomalia si trasformi in un rischio per persone e organizzazione.