Danni da AI: dal 30 settembre il giudice può chiedere i log

Cosa trovi in questo articolo

Cosa dice il decreto 160/2026 sul risarcimento dei danni causati dall’AI
Cosa non cambia e cosa resta regolato dal codice civile
Le norme penali e il Modello 231
Cosa sono i log e quali domande permettono di risolvere
Il rapporto con il fornitore e la supervisione umana
Cosa fare nei primi trenta giorni

Dal 30 settembre 2026 è in vigore il decreto legislativo 160/2026. Se un sistema di intelligenza artificiale causa un danno, il giudice può ordinare a chi lo usa o lo fornisce di mostrare le registrazioni delle operazioni, i cosiddetti log, e i documenti su rischi e controllo umano. Per un’azienda significa che, in caso di causa, conta poter dimostrare come usa e controlla l’AI.

Cosa è il decreto 160/2026

Il decreto legislativo 9 settembre 2026, n. 160, è stato pubblicato nella Gazzetta Ufficiale del 15 settembre ed entra in vigore il 30 settembre. Attua la legge italiana sull’intelligenza artificiale, la legge 132 del 2025, e adegua le norme nazionali all’AI Act, il regolamento europeo sull’intelligenza artificiale.

Buona parte dei suoi 22 articoli riguarda l’uso dell’AI da parte delle forze di polizia. Ci sono però due parti che toccano da vicino le imprese: il risarcimento dei danni causati dall’AI e alcune nuove norme penali, con effetti anche sui Modelli 231.

Cosa cambia se l’AI causa un danno

Fino a oggi, chi voleva un risarcimento doveva dimostrare tre cose: il danno, il comportamento scorretto di qualcuno e il collegamento tra i due. Con un programma di AI questo terzo passaggio era spesso impossibile, perché il danneggiato vede il risultato, per esempio un finanziamento negato o una candidatura scartata, ma non ha modo di guardare come il sistema ci è arrivato.

Il decreto interviene proprio qui. Il giudice può ordinare di mostrare gli elementi utili a capire come ha funzionato il sistema (articolo 17): i log, cioè le registrazioni delle operazioni, i documenti sulla gestione dei rischi e sul controllo umano, e ciò che serve a verificare il rispetto dell’AI Act. Il danneggiato deve prima portare elementi che rendano credibile la sua richiesta, e l’ordine si limita a ciò che è pertinente e proporzionato.

Se emerge che il danno deriva dalla violazione di un obbligo dell’AI Act, si presume che sia stata quella violazione a causarlo (articolo 18). È una presunzione che si può smontare: chi è chiamato in causa può dimostrare, per esempio, che il danno sarebbe successo comunque. E chi si rifiuta di mostrare i documenti ordinati rischia che il giudice valuti quel rifiuto contro di lui.

C’è anche un’azione diretta contro l’assicuratore: chi subisce un danno da un sistema coperto da polizza può rivolgersi direttamente alla compagnia.

Cosa non cambia

Il decreto non crea una nuova responsabilità “da intelligenza artificiale”. Chi deve pagare, e con quale criterio, resta regolato dal codice civile: se c’è un contratto, risponde chi non l’ha rispettato; se non c’è, valgono le regole generali sul danno ingiusto.

Il rispetto delle regole europee, anche certificato, non basta però a mettersi al riparo (articolo 19). Evita la presunzione, ma il danneggiato può ancora dimostrare con gli strumenti ordinari che il sistema ha causato il danno.

Un’ultima cautela. Molti obblighi dell’AI Act per i sistemi ad alto rischio, come quelli usati nella selezione del personale, sono stati rinviati al 2 dicembre 2027 da un regolamento europeo di luglio. La presunzione può scattare solo per obblighi già applicabili, quindi conviene verificare caso per caso quali valgono oggi per il proprio sistema.

Le norme penali e il Modello 231

Il decreto aggiunge al codice penale l’articolo 437-bis. Punisce chi omette le misure tecniche di sicurezza previste per i sistemi di AI ad alto rischio, o le misure di controllo umano, quando dall’omissione deriva un pericolo per la vita o l’incolumità delle persone. La pena va da uno a cinque anni, da due a otto se c’è un pericolo per la sicurezza dello Stato.

Non riguarda chiunque usi un programma di AI: riguarda i sistemi ad alto rischio e le omissioni che creano quei pericoli.

Nel decreto 231 del 2001, quello sulla responsabilità delle aziende per alcuni reati, entra l’articolo 25-vicies, sui reati commessi con l’uso di sistemi di AI, con una sanzione per l’azienda da 600 a 1.000 quote. Anche qui la responsabilità non è automatica: servono il reato, l’interesse o il vantaggio dell’azienda e una colpa di organizzazione. Chi ha un Modello 231 dovrebbe comunque aggiornarlo con questo rischio.

Perché l’impresa deve sapere come lavora un sistema AI

Un imprenditore che affida un compito a un collaboratore conosce normalmente il reparto, il responsabile e le procedure da seguire. Quando lo stesso compito viene svolto da un software, alcune di queste informazioni rischiano di scomparire dalla vista. Il programma produce il risultato, ma non sempre è chiaro quali dati abbia utilizzato, quali controlli siano stati eseguiti e chi avrebbe dovuto intervenire in presenza di un’anomalia. Se quel risultato provoca un danno, ricostruire i fatti diventa essenziale.

Immaginiamo un’impresa che utilizza un sistema di AI per classificare i reclami dei clienti. Un reclamo urgente viene classificato come ordinario e rimane senza risposta. Il cliente sostiene di aver subito un danno economico a causa del ritardo. La prima esigenza dell’azienda consiste nel capire che cosa è successo. Bisogna recuperare il messaggio originale, verificare le informazioni disponibili al momento della classificazione, capire quale regola o modello sia stato utilizzato e controllare se una persona avesse la possibilità di correggere la decisione.

Queste domande esistono anche quando non ci sono cause giudiziarie. Servono per migliorare il processo, rispondere al cliente e prevenire nuovi errori. Il decreto 160/2026 rende ancora più evidente l’importanza della ricostruzione perché disciplina, tra le altre cose, l’accesso a determinati elementi di prova nelle controversie che riguardano danni collegati all’uso di sistemi di intelligenza artificiale. Non significa che ogni errore di un chatbot sia automaticamente un illecito o che qualsiasi documento debba essere consegnato senza limiti.

La prospettiva corretta per una PMI è organizzativa. Ogni impiego rilevante dell’AI dovrebbe avere una persona responsabile, uno scopo preciso e un modo documentato per verificare ciò che avviene. Si tratta di requisiti che proteggono l’impresa anche quando il sistema funziona bene e nessuno presenta contestazioni.

Un registro utile risponde a domande concrete: Chi ha avviato l’operazione; Il documento era quello giusto; Chi ha approvato; Cosa è stato modificato. — Le domande a cui un registro ben costruito deve permettere di rispondere, anche quando non c’è nessuna causa.

Capire che cosa sono i log, senza tecnicismi inutili

La parola log è comune in informatica e spesso viene tradotta con registro delle operazioni. È una sequenza di informazioni che un programma conserva per descrivere eventi avvenuti durante il funzionamento. Può indicare quando è iniziato un compito, quale servizio è stato consultato, quale risposta è stata ricevuta e se un’operazione si è conclusa oppure è stata bloccata. Il contenuto dipende dal sistema: alcuni registri sono molto tecnici, altri possono essere presentati in una forma leggibile anche da chi segue il processo aziendale.

Un registro utile permette di rispondere a domande concrete. Chi ha avviato l’operazione? Quale pratica veniva trattata? Il programma ha trovato il documento corretto? Ha chiesto un’approvazione? Chi l’ha concessa? È stato modificato un dato del cliente? Quale valore compariva prima della modifica? Queste informazioni, quando sono pertinenti e raccolte correttamente, aiutano a distinguere l’errore del sistema da un dato sbagliato ricevuto in ingresso o da un’approvazione umana concessa senza i controlli previsti.

Non tutti i log sono automaticamente esaustivi. Registrare l’ora di accesso di un dipendente non consente di ricostruire il ragionamento operativo che ha portato un agente a modificare un ordine. Al contrario, conservare ogni parola presente in tutti i documenti può generare nuovi problemi di riservatezza. Il progetto dovrebbe stabilire quali eventi siano necessari per ricostruire le decisioni rilevanti e come collegarli ai documenti custoditi negli archivi aziendali.

Bisogna ricordare che una registrazione può essere errata o incompleta. Anche per questo le aziende hanno interesse a verificare periodicamente che i log vengano effettivamente prodotti, che gli orari siano coerenti e che le informazioni possano essere recuperate quando servono. Un registro previsto nel contratto ma mai provato rischia di rivelarsi inutilizzabile proprio nel momento più delicato.

Come leggere correttamente il decreto 160/2026

Il decreto legislativo 9 settembre 2026, n. 160, contiene disposizioni differenti. Per un’impresa che utilizza AI nei propri processi è importante identificare quelle pertinenti, senza trasformare l’intero testo in un generico obbligo di conservare ogni conversazione con ChatGPT. L’articolo 17 riguarda l’accesso alle prove in determinate azioni di risarcimento del danno. Prevede condizioni e limiti per l’ordine di esibizione: non basta dichiarare genericamente che un sistema è stato utilizzato e chiedere tutto ciò che esiste nei server dell’azienda.

Il riferimento a elementi specificamente pertinenti e alla proporzionalità è importante. In un procedimento si deve evitare che la richiesta di prove diventi una ricerca indiscriminata tra documenti riservati, dati dei clienti e segreti commerciali. La legge definisce il quadro; l’applicazione concreta richiede una valutazione giuridica sul caso specifico. Il testo ufficiale e aggiornato della disposizione va consultato nella Gazzetta Ufficiale o in Normattiva prima di prendere decisioni legali.

Il decreto prevede anche una presunzione collegata alla violazione di obblighi applicabili dell’AI Act. Occorre chiarire che una presunzione prevista dalla legge non equivale a una condanna automatica. I fatti, la norma concretamente applicabile, il collegamento con il danno e la possibilità di fornire prova contraria devono essere valutati secondo le condizioni stabilite dal legislatore. Anche rispettare formalmente una procedura non esclude in assoluto che possa essere contestata una responsabilità secondo le regole civili ordinarie.

Le date contano perché gli obblighi dell’AI Act non sono entrati tutti in applicazione contemporaneamente e alcune scadenze sono state modificate nel 2026. Chi interpreta il decreto per un’attività specifica deve verificare quali disposizioni siano già applicabili al momento del fatto. Non è corretto parlare dell’AI Act come di un blocco unico di obblighi immediatamente identici per ogni strumento.

Un sistema di selezione del personale come esempio

Supponiamo che una società utilizzi un programma per aiutare l’ufficio risorse umane a individuare candidature pertinenti. Il sistema legge i curriculum e propone una graduatoria. Un candidato escluso ritiene di essere stato trattato in modo discriminatorio. È una situazione ipotetica, utile per capire quali domande possono emergere: quali dati sono stati considerati, quali criteri sono stati impostati, chi ha visto la graduatoria, in che modo è stata utilizzata e quali verifiche sono state effettuate prima della decisione.

La scelta di un candidato riguarda persone reali e può avere conseguenze importanti. È perciò sbagliato trattarla come la semplice classificazione di messaggi pubblicitari. Il sistema deve essere valutato secondo le norme applicabili all’occupazione, alla protezione dei dati e all’uso dell’intelligenza artificiale. Va distinto il supporto alla lettura dei documenti dalla decisione finale, che deve avere una responsabilità chiaramente assegnata.

Un registro ben costruito aiuta a documentare la procedura, ma da solo non dimostra che il sistema fosse corretto. Occorrono criteri di selezione pertinenti, verifiche sulla qualità dei risultati, controlli sulle possibili discriminazioni e un modo effettivo per contestare l’output. La presenza di una firma umana in fondo alla graduatoria non è un controllo sufficiente se quella persona non può comprendere o modificare la valutazione proposta.

L’esempio mostra perché convenga progettare le verifiche prima dell’utilizzo. Quando un risultato è già stato impiegato per prendere una decisione, ricostruire a posteriori dati e impostazioni può essere difficile. Se nel frattempo il fornitore ha aggiornato il sistema, potrebbe non essere più possibile riprodurre esattamente le condizioni operative di allora.

Il rapporto con il fornitore del software

Molte PMI non sviluppano da sole i programmi che utilizzano. Acquistano servizi cloud, integrano funzioni AI nei gestionali o si affidano a una software house. Questa scelta può essere efficiente, ma deve essere accompagnata da una definizione contrattuale delle responsabilità. Chi conserva i registri? Per quanto tempo? L’azienda può recuperarli senza aprire una controversia con il fornitore? Come vengono segnalati gli incidenti? Che cosa succede quando il servizio cambia versione?

Una risposta generica come «il sistema è conforme» non chiarisce abbastanza. L’impresa ha bisogno di sapere quali controlli esistono concretamente per il proprio processo. Un servizio utilizzato soltanto per preparare bozze interne richiede verifiche diverse da un agente che modifica dati contabili o invia comunicazioni vincolanti. Il contratto dovrebbe descrivere i ruoli dei soggetti coinvolti e i servizi che ciascuno deve garantire.

La disponibilità dei log è un punto particolarmente delicato quando l’azienda usa una piattaforma chiusa. Può capitare che il fornitore conservi informazioni tecniche sufficienti per la propria assistenza, ma non offra al cliente una cronologia completa delle azioni compiute sui dati aziendali. Prima di acquistare conviene chiedere una dimostrazione concreta dell’esportazione dei registri, non soltanto una dichiarazione commerciale sulla tracciabilità.

Anche la possibilità di cambiare fornitore deve entrare nella valutazione. Se l’impresa decide di sostituire una soluzione, deve sapere quali dati e registrazioni potrà conservare, in quale formato e con quali vincoli. L’obiettivo è evitare che anni di attività diventino difficili da documentare perché il servizio precedente non è più accessibile.

La supervisione umana deve avere effetti reali

Nelle presentazioni commerciali compare spesso la frase «l’essere umano mantiene il controllo». È una promessa che acquista significato soltanto quando il processo descrive che cosa la persona può fare. Un responsabile deve poter vedere il risultato prima che produca certe conseguenze, chiedere correzioni, rifiutare una proposta o sospendere l’agente. Se può soltanto prendere atto di quanto è già accaduto, la sua supervisione è limitata.

Immaginiamo un agente che prepara le risposte ai reclami. Per le richieste ordinarie potrebbe compilare una bozza. Quando il cliente contesta un danno o chiede il rimborso di una somma, il caso passa a un operatore che consulta la documentazione e decide. Questa soglia va inserita nel sistema in modo tecnico, non lasciata a un’istruzione vaga del tipo «fai attenzione ai casi importanti».

La persona incaricata deve ricevere formazione sufficiente a riconoscere i limiti dell’AI. Se un agente produce una spiegazione plausibile ma priva del documento corretto, il supervisore deve poterlo scoprire. Serve quindi un’interfaccia che renda disponibili fonti, dati rilevanti e azioni già eseguite. Altrimenti il controllo diventa un gesto formale e l’azienda conserva soltanto l’apparenza della supervisione.

La responsabilità deve sopravvivere alle assenze. Se il responsabile è in ferie, chi approva le operazioni urgenti? Quali lavori restano sospesi? Chi interviene quando il sistema produce risultati anomali? Sono domande organizzative ordinarie, ma l’automazione tende a farle dimenticare proprio perché il programma continua a lavorare senza chiedere pause.

Come individuare gli usi dell’AI che meritano più attenzione

Una PMI potrebbe avere già diversi sistemi di intelligenza artificiale senza considerarli parte di un progetto comune. Un commerciale usa un assistente per le email, l’ufficio marketing genera immagini, l’amministrazione acquista un programma che estrae dati dalle fatture e il reparto personale adotta uno strumento per esaminare i curriculum. Il primo passo consiste nel fare un inventario di questi utilizzi, indicando a quali dati accedono e quali risultati producono.

L’inventario non deve diventare una compilazione burocratica fine a sé stessa. Per ogni sistema è utile annotare il reparto, il fornitore, il compito, i tipi di dati trattati, l’eventuale autonomia operativa, la persona responsabile e il modo in cui il risultato viene controllato. Con una tabella di poche colonne si ottiene già una fotografia che spesso manca alla direzione.

Dopo l’inventario occorre individuare le applicazioni che possono incidere su denaro, diritti delle persone, documenti ufficiali o accessi a sistemi riservati. Non significa che tutti gli altri utilizzi siano privi di rischio. Significa assegnare l’attenzione maggiore ai processi in cui un errore potrebbe avere conseguenze più rilevanti. Un riassunto impreciso di una riunione interna, per esempio, richiede un controllo, ma non presenta necessariamente gli stessi rischi di una decisione che riguarda un dipendente.

I responsabili dei singoli reparti devono essere coinvolti perché conoscono gli effetti pratici delle operazioni. Una società di software può descrivere le caratteristiche tecniche del modello, ma il responsabile amministrativo sa quali errori creano problemi nei pagamenti. La valutazione più utile nasce dalla combinazione delle competenze tecniche e della conoscenza del lavoro reale.

Conservare le prove senza accumulare dati inutili

Quando si parla di tracciabilità, esiste il rischio di raccogliere più dati di quanti siano necessari. Un registro indiscriminato delle conversazioni può contenere documenti riservati, informazioni personali, segreti industriali e dati di terzi. Una politica corretta deve considerare insieme la necessità di ricostruire le attività e la protezione delle informazioni registrate.

Per alcuni processi può essere sufficiente conservare l’identificativo della pratica, l’ora dell’operazione, la versione del sistema, l’esito dei controlli e il riferimento ai documenti custoditi altrove. Per altri servono informazioni più dettagliate. La decisione dipende dalle norme applicabili, dal rischio, dai contratti e dalle caratteristiche del processo. Non esiste una durata di conservazione identica per qualsiasi log aziendale.

Anche gli accessi ai registri devono essere limitati. Se un log permette di ricostruire le pratiche fiscali dei clienti, non deve essere consultabile da chiunque possieda un account amministrativo generico. È opportuno distinguere chi gestisce tecnicamente il sistema da chi è autorizzato a leggere il contenuto delle operazioni. Quando un incidente richiede verifiche straordinarie, gli accessi concessi per l’indagine dovrebbero essere a loro volta documentati.

Un’ulteriore misura consiste nel verificare che le registrazioni non possano essere modificate senza lasciare traccia. Se un documento viene corretto, deve essere possibile distinguere la versione originale da quella successiva. Le procedure tecniche variano in base alla piattaforma, ma l’esigenza organizzativa è comprensibile: un registro deve essere affidabile anche quando viene utilizzato per ricostruire un errore.

Cosa fare nei primi trenta giorni

Una piccola impresa che parte da zero può utilizzare il primo mese per costruire le fondamenta. All’inizio si censiscono i sistemi AI già presenti e si chiedono ai responsabili i processi in cui producono risultati. Successivamente si selezionano gli utilizzi con conseguenze rilevanti e si raccolgono contratti, procedure e informazioni sui controlli disponibili. Il lavoro deve essere proporzionato alla dimensione dell’azienda: lo scopo è conoscere ciò che accade, senza creare un apparato organizzativo impossibile da mantenere.

Nella fase successiva si sceglie un processo e si prova la ricostruzione di una pratica conclusa. Si chiede, per esempio, di mostrare chi ha avviato l’attività, quali dati ha letto il sistema, quale risultato ha prodotto e chi l’ha approvato. Se qualcuno non sa rispondere, l’assenza dell’informazione diventa una priorità concreta del progetto. Questo esercizio è più utile di una presentazione teorica perché mostra subito le lacune reali.

Si definisce quindi una procedura di gestione degli errori: chi deve ricevere le segnalazioni, come si sospende il processo, dove si conservano le informazioni pertinenti e quando serve coinvolgere un professionista legale o il responsabile della protezione dei dati. Nel frattempo si verifica con il fornitore la disponibilità delle registrazioni e dei documenti tecnici necessari.

Alla fine del mese l’azienda dovrebbe avere una fotografia dei sistemi più importanti, un responsabile per ciascuno e un piano realistico per migliorare gli aspetti ancora deboli. Non è una certificazione di conformità e non sostituisce una valutazione giuridica. È un modo concreto per smettere di utilizzare strumenti che nessuno sa descrivere o controllare.

La competenza interna che resta indispensabile

Anche quando un programma funziona bene, qualcuno deve conoscere il processo abbastanza da riconoscerne gli errori. Se un sistema prepara una dichiarazione o propone una decisione sul personale, l’azienda non dovrebbe perdere la capacità di capire quali verifiche siano necessarie. La competenza interna è importante per proteggere le persone coinvolte e per evitare di diventare completamente dipendenti dal fornitore.

Questa esigenza riguarda anche il dialogo con eventuali consulenti. Un avvocato può valutare gli aspetti giuridici di una controversia, ma ha bisogno di sapere come il software è stato usato concretamente. Un tecnico può recuperare i log, ma deve conoscere quale pratica e quale comportamento occorre ricostruire. La direzione aziendale deve quindi mantenere una descrizione comprensibile del sistema, aggiornata ogni volta che cambia una funzione rilevante.

Una cultura della registrazione e della supervisione non nasce quando arriva una contestazione. Nasce durante la progettazione, quando si decide chi può fare cosa e come controllarlo. Questo è il principale insegnamento operativo del decreto: l’adozione dell’AI richiede la stessa attenzione che una buona impresa dedica agli altri processi importanti, con il vantaggio aggiuntivo di poter progettare registrazioni e controlli fin dall’inizio.

Per trasformare queste indicazioni in un piano occorre confrontarle con l’attività effettiva, con il testo vigente delle norme e con le condizioni dei contratti. Nessun articolo divulgativo può sostituire questo lavoro. Può però mettere un imprenditore nelle condizioni di fare domande più precise e capire quando una risposta generica del fornitore non basta.

Cosa conviene fare in azienda

Prendiamo un esempio costruito, ma verosimile. Un’azienda usa un programma di AI per fare una prima selezione dei curriculum, e un candidato scartato fa causa sostenendo di essere stato discriminato. Il giudice può ordinare di mostrare come il programma è stato configurato, quali dati ha usato, chi controllava i risultati e cosa è stato registrato. Se l’azienda non ha niente di scritto, parte svantaggiata.

Il decreto riguarda chi sviluppa, vende, integra e anche chi usa sistemi di AI. Il ruolo si valuta in concreto, guardando a cosa fa il sistema e a quanto controllo ha l’azienda. La responsabilità cresce quando l’azienda modifica un sistema, ne cambia lo scopo, lo integra con i propri dati o usa i suoi risultati per decisioni sulle persone.

Io credo che il primo passo sia sapere dove si usa l’AI, comprese le funzioni già dentro i software di tutti i giorni. Poi servono tre cose per ogni uso che conta: chi lo controlla e con quale potere di correggerlo o fermarlo, quali registrazioni si conservano, quali rischi sono stati valutati e con quali misure.

Nei contratti con i fornitori va scritto chi conserva i log e come si accede in caso di problemi.

Cosa succede in una causa per un danno causato dall’AI con il decreto 160/2026. Il giudice può ordinare di mostrare le registrazioni delle operazioni, i documenti sui rischi e quelli sul controllo umano. — Tre passaggi che il decreto introduce nel processo civile, dal 30 settembre 2026.

Fonte normativa principale

Decreto legislativo 9 settembre 2026, n. 160 — Gazzetta Ufficiale. Le applicazioni concrete richiedono una verifica giuridica.