Audit trail e AI: cosa cambia con il D.Lgs. 160/2026

L’audit trail di un sistema AI è il registro cronologico di ciò che il sistema ha fatto: quali dati ha ricevuto, quale risultato ha prodotto, quale versione del modello era attiva e quale persona ha verificato, corretto o scartato quel risultato. Un log di sistema registra che il software ha girato; l’audit trail permette di ricostruire le ragioni di una decisione e il controllo umano che l’ha accompagnata. Dal 30 settembre 2026, con l’entrata in vigore del D.Lgs. 160/2026, questo registro pesa come prova. Chi chiede il risarcimento di un danno causato da un sistema AI può ottenere dal giudice l’esibizione dei log e della documentazione tecnica, e l’azienda che non li consegna rischia che i fatti contestati vengano considerati ammessi.

Nelle fabbriche e negli uffici l’AI controlla già i lotti in uscita dalle linee, assegna priorità alle commesse, filtra le candidature. Quando un pezzo difettoso supera il controllo automatico, o una decisione del sistema provoca un danno a qualcuno, chi ha subito il danno non interroga la macchina. Chiama in causa l’azienda e chi la dirige. A quel punto, per dimostrare di aver governato la tecnologia con diligenza, servono evidenze ordinate, datate e difficili da contestare.

Per il vertice aziendale la conseguenza è molto pratica. Saper ricostruire, anche a distanza di mesi, come ha lavorato un sistema e chi lo ha controllato pesa ormai su tre piani: la responsabilità civile, quella dell’ente prevista dal D.Lgs. 231/2001 e, per i sistemi ad alto rischio, quella penale delle persone.

Cosa cambia dal 30 settembre 2026?

Il decreto legislativo 9 settembre 2026, n. 160, pubblicato in Gazzetta Ufficiale il 15 settembre, attua la delega della legge italiana sull’intelligenza artificiale (L. 132/2025) e adegua il nostro ordinamento all’AI Act europeo. Ha 22 articoli. La prima parte riguarda l’uso dell’AI da parte delle forze di polizia, dal riconoscimento facciale all’identificazione biometrica in tempo reale. La seconda parla direttamente alle imprese e interviene su tre fronti.

• Sul fronte penale nasce un nuovo reato, l’art. 437-bis del codice penale. Riguarda chi, nella filiera di un sistema AI ad alto rischio, non adotta le misure tecniche di sicurezza o di sorveglianza umana previste, quando da questa omissione deriva un pericolo per la vita o l’incolumità delle persone. Risponde anche l’utilizzatore professionale che rinuncia di proposito alla sorveglianza umana.
• Sul fronte della responsabilità d’impresa, questo reato entra nel catalogo del D.Lgs. 231/2001 insieme alla diffusione illecita di deepfake, esponendo l’azienda a sanzioni fino a 1000 quote e a misure interdittive, come il divieto di contrattare con la pubblica amministrazione.
• Sul fronte civile cambiano le regole della prova nelle cause per danni causati da sistemi AI, di qualunque classe di rischio.

Sul terzo fronte l’audit trail smette di essere un adempimento tecnico e diventa materiale da processo.

Serve una precisazione sul calendario. Il Regolamento (UE) 2026/1744, il cosiddetto Digital Omnibus, ha spostato al 2 dicembre 2027 gli obblighi dell’AI Act per i sistemi ad alto rischio dell’Allegato III, come quelli usati nella selezione del personale. Per l’AI integrata in prodotti già regolati, come macchinari e dispositivi medici, la data è il 2 agosto 2028. Il rinvio non sospende le nuove regole processuali italiane: dal 30 settembre chi si ritiene danneggiato può chiedere l’esibizione delle prove sul funzionamento di qualsiasi sistema AI. Resta da capire come i giudici tratteranno, fino al 2027, i documenti che l’AI Act richiede per l’alto rischio e che per molti sistemi non sono ancora obbligatori. Chi aspetta quella data per mettere ordine nei propri log, comunque, parte in ritardo.

Perché i log contano più di una certificazione?

Si potrebbe pensare che una certificazione di conformità basti a mettere l’azienda al riparo. Il decreto lo esclude in modo esplicito: la conformità all’AI Act, anche se certificata, non esclude di per sé la responsabilità (art. 19). La certificazione dice che il sistema rispetta i requisiti in generale. In una causa conta altro: che cosa è successo quel giorno, con quel dato, davanti a quale operatore.

Il meccanismo del decreto passa dai registri in tutti e tre i suoi passaggi.

Il primo è l’accesso alle prove (art. 17). Il danneggiato che porta elementi sufficienti a rendere verosimile la sua richiesta può ottenere dal giudice l’ordine di esibire i log, la documentazione sulla gestione dei rischi, la documentazione tecnica e le informazioni sulla sorveglianza umana. Il secondo riguarda la mancata collaborazione: se l’azienda non consegna quei documenti senza un giustificato motivo, il giudice, valutate le altre prove, considera ammessi i fatti allegati dall’altra parte. Il terzo è la presunzione (art. 18): quando il danno deriva dalla violazione di un obbligo dell’AI Act, il legame tra violazione e danno si presume. L’impresa può ancora difendersi, ma tocca a lei dimostrare che il danno ha un’altra causa.

Quella dimostrazione, in pratica, si costruisce con i log.

Un audit trail lacunoso produce quindi un doppio svantaggio: non si riesce a consegnare ciò che il giudice chiede, e non si riesce a ribaltare la presunzione. Il decreto impone al giudice di limitare l’ordine a quanto necessario e di proteggere i segreti commerciali, e questa è una tutela reale. L’onere di avere i dati in ordine, però, resta interamente all’azienda.

Cosa deve registrare un audit trail per l’AI?

Il decreto non detta un elenco di campi. Rinvia ai registri che l’AI Act chiede per i sistemi ad alto rischio e alle informazioni su come è organizzata la sorveglianza umana. In termini operativi, per ogni risultato rilevante prodotto dal sistema l’audit trail dovrebbe permettere di sapere:

• quando è stato generato, con una marcatura temporale affidabile;
• quale versione del modello e quale configurazione erano attive;
• su quali dati di ingresso ha lavorato, o dove quei dati sono conservati;
• quale output ha restituito;
• chi lo ha visto e che cosa ha deciso (confermato, modificato, scartato);
• quali anomalie, incidenti o correzioni sono seguiti.

Contano poi due proprietà del registro nel suo insieme. La prima è l’integrità, cioè la garanzia che nessuno lo abbia ritoccato dopo i fatti. La seconda è una conservazione coerente con i tempi di un possibile contenzioso, che spesso si apre molti mesi dopo l’evento.

Per l’integrità esiste una tecnica semplice e collaudata, la catena di hash, che la guida sull’audit trail dell’Associazione Italiana Professionisti dell’Intelligenza Artificiale (AIPIA) indica come il meccanismo che rende difendibile un registro. A ogni voce viene calcolata un’impronta numerica che incorpora anche l’impronta della voce precedente. Basta cambiare una cifra in un record di marzo perché cambino l’impronta di quel record e quelle di tutti i successivi, così la manomissione emerge verificando la catena, senza rileggere i contenuti. Da sola non basta. Servono anche supporti di archiviazione WORM (write once, read many), su cui un dato si scrive una volta e non si può più sovrascrivere, cifratura dei dati e nessun accesso privilegiato che sfugga al tracciamento, nemmeno quello degli amministratori di sistema.

Un dettaglio del decreto aiuta a capire che cosa un giudice considererà credibile. Per i propri sistemi più delicati, quelli di identificazione biometrica usati dalle forze di polizia, il legislatore ha previsto file di log registrati automaticamente, non modificabili e conservati per cinque anni (artt. 9 e 10). Alle aziende private il decreto non impone lo stesso standard. A nostro avviso è comunque il metro giusto: un registro che si può correggere a posteriori, in un’aula di tribunale, vale poco.

Come si dimostra la sorveglianza umana?

La sorveglianza umana è il punto in cui audit trail e responsabilità penale si toccano. Per un’impresa che usa professionalmente un sistema ad alto rischio, il nuovo reato scatta quando la sorveglianza umana viene omessa intenzionalmente e da quell’omissione deriva un pericolo per le persone. Nominare un responsabile non basta. Bisogna poter mostrare che quella persona ha controllato davvero, e quando.

Due esempi. In una linea di controllo qualità basata su computer vision, il registro dovrebbe indicare chi ha validato lo scarto di un lotto segnalato dal sistema, a che ora e guardando quale immagine. In un processo di selezione del personale supportato dall’AI (un ambito che l’AI Act classifica ad alto rischio) dovrebbe risultare quale recruiter ha riesaminato la candidatura scartata dal sistema, e con quale esito. Se questi passaggi restano affidati alla memoria delle persone o a una email che nessuno ritroverà, per un giudice è difficile considerarli avvenuti.

Lo stesso vale per la preparazione di chi sorveglia. Chi ha ricevuto quale formazione, su quale sistema, in che data: anche questo è audit trail.

Serve un audit trail anche a chi usa l’AI senza svilupparla?

Sì, in forma proporzionata. Una PMI o uno studio professionale che usa strumenti di terzi non addestra modelli, quindi non deve documentarne l’addestramento. Deve però sapere che cosa usa, su quali dati e chi ha controllato il risultato. Per questi casi la guida AIPIA propone un registro essenziale, che può essere anche un foglio strutturato, con una riga per ogni uso rilevante:

• data e ora;
• sistema e versione utilizzati;
• finalità e persona che ha fatto la richiesta;
• tipo di dati in ingresso, e se erano anonimizzati;
• sintesi dell’output;
• esito della verifica umana (accettato, modificato, scartato) con una riga di motivazione;
• chi ha controllato prima dell’uso.

Non ha la complessità dell’audit trail di una banca, e non deve averla. Il campo che pesa di più è la motivazione: senza quella riga, a distanza di mesi, nessuno potrà dimostrare che una persona ha davvero esaminato l’output prima di usarlo. E poiché dal 30 settembre le regole sulle prove valgono per qualsiasi sistema AI, anche un foglio compilato con costanza aiuta a difendersi in una contestazione.

Chi deve conservare i log, l’azienda o il fornitore?

Molti sistemi AI in uso nelle aziende sono forniti da terzi, e i log stanno spesso sui server del fornitore. Il decreto ne tiene conto: l’ordine di esibizione può essere rivolto anche al terzo che dispone delle prove, e il terzo che non collabora senza giustificato motivo viene condannato a una pena pecuniaria da 1.500 a 10.000 euro. Resta però il problema dell’azienda chiamata in causa, che deve difendersi con dati che non controlla direttamente e che arrivano con i tempi di qualcun altro.

Il contratto con il fornitore va quindi riletto con alcune domande precise:

• dove sono conservati i log e per quanto tempo;
• in quali tempi e in quale formato il fornitore li mette a disposizione in caso di reclamo o contenzioso;
• se il fornitore è tenuto a preservare le evidenze appena si apre un incidente;
• come vengono protetti i segreti commerciali di entrambe le parti quando la documentazione va consegnata.

Le stesse domande valgono, rovesciate, per chi fornisce sistemi AI ad altre aziende. Anche per noi.

Da dove partire nelle prossime settimane?

L’analisi pubblicata da Agenda Digitale propone alle imprese un piano di adeguamento in otto punti. Letto con la lente dell’audit trail, si può ridurre a sette mosse:

• fare l’inventario dei sistemi AI in uso, compresi quelli dei fornitori, e individuare quelli ad alto rischio;
• stabilire, sistema per sistema, che cosa viene registrato, dove e per quanto tempo;
• rendere i registri non alterabili, o almeno tracciare ogni modifica;
• definire una procedura che «congeli» log ed evidenze quando arrivano un incidente, un reclamo o una richiesta di risarcimento;
• documentare chi esercita la sorveglianza umana e con quale formazione;
• aggiornare il modello 231 e i flussi informativi verso l’Organismo di Vigilanza, dove esistono;
• verificare le polizze, perché dal 30 settembre chi si ritiene danneggiato può chiedere all’azienda se è assicurata e la risposta va data entro 30 giorni.

Un audit trail si costruisce prima dei fatti. Dopo, si possono solo raccogliere frammenti.

Come affrontiamo la tracciabilità in Aidia

Nei progetti che seguiamo la tracciabilità si decide sempre in fase di progettazione, perché aggiungerla a posteriori su un sistema già in produzione costa il triplo e lascia buchi informativi. Nei progetti su misura basati su visione artificiale e controllo qualità, integriamo nativamente un audit trail digitale completo e conforme ai requisiti di linea. Con la nostra suite AVA, l’installazione può avvenire interamente on-premise: in questo modo registri, log operativi e dati aziendali non escono mai dal perimetro del cliente.

Nessun prodotto, nostro o di altri, esonera un’azienda dalla propria responsabilità legale: il decreto lo dice in modo inequivocabile. Un’architettura progettata bene fa una cosa molto più concreta: mette l’azienda nelle condizioni di dimostrare con precisione che cosa è successo.

Se stai mappando i tuoi sistemi AI e vuoi capire dove l’audit trail è incompleto, contattaci.

Domande frequenti

Che cos’è un audit trail per un sistema di intelligenza artificiale?

È il registro cronologico e non alterabile delle attività di un sistema AI: quali dati ha ricevuto, quale output ha prodotto, con quale versione del modello e quali interventi umani sono seguiti. Serve a ricostruire come e perché il sistema ha generato un certo risultato, anche a distanza di mesi. Dal 30 settembre 2026 ha anche valore di prova nelle cause per danni.

Il D.Lgs. 160/2026 obbliga tutte le aziende ad avere un audit trail?

Non in modo esplicito. I registri sono un obbligo dell’AI Act per i sistemi ad alto rischio, con scadenze rinviate al 2 dicembre 2027 per quelli dell’Allegato III. Il decreto però consente al danneggiato di chiedere l’esibizione delle prove sul funzionamento di qualsiasi sistema AI, e chi non ha registri fatica a difendersi.

Cosa succede se un’azienda non consegna i log richiesti dal giudice?

Se l’azienda non adempie senza giustificato motivo, anche solo in parte, il giudice può trarne argomenti a suo sfavore. Quando mancano i documenti indicati dal decreto (log, gestione dei rischi, documentazione tecnica, sorveglianza umana), il giudice, valutate le altre prove, considera ammessi i fatti allegati dal danneggiato.

L’audit trail rischia di rivelare segreti industriali durante una causa?

Il rischio esiste, e il decreto lo considera. L’ordine di esibizione va limitato a quanto necessario e, se c’è pericolo di divulgare segreti commerciali, il giudice adotta misure di tutela richiamando l’art. 121-ter del Codice della proprietà industriale. Su richiesta dell’azienda può vietare a parti e consulenti di usare le informazioni riservate, restringere l’accesso agli atti e oscurare i passaggi sensibili.

Una certificazione di conformità all’AI Act esclude la responsabilità?

No. Il decreto stabilisce che la conformità agli obblighi dell’AI Act, anche se certificata, non esclude di per sé la responsabilità dell’azienda. La certificazione attesta che il sistema rispetta i requisiti in generale. In una causa conta ricostruire che cosa è successo nel caso specifico, ed è lì che serve l’audit trail.

Il fornitore del sistema AI può essere obbligato a consegnare i log?

Sì. Il giudice può ordinare l’esibizione anche al terzo che dispone delle prove, per esempio il fornitore che conserva i log sui propri server. Se il terzo non collabora senza giustificato motivo, rischia una pena pecuniaria da 1.500 a 10.000 euro. Per questo conviene regolare nel contratto accesso, conservazione e tempi di consegna dei registri.

Fonti:

• Gazzetta Ufficiale della Repubblica Italiana, DECRETO LEGISLATIVO 9 settembre 2026, n. 160, (26G00179) (GU Serie Generale n.214 del 15-09-2026), Gazzetta Ufficiale
• Nadia Martini, «AI e responsabilità d’impresa, cosa cambia e come adeguarsi», (21 settembre 2026) Agenda Digitale
• Francesco Machina Grifeo, «Intelligenza artificiale, dal 30 settembre nuove regole su responsabilità e riconoscimento facciale», (16 settembre 2026) Il Sole 24 Ore