Audit trail: come tracciare accessi a dati e codice

Cos'è un audit trail e perché serve per la conformità AI Act e NIS2. Come sapere sempre chi ha fatto cosa, su quali dati, con quale strumento AI.

di Elias Mahdavi · Pubblicato il · 9 min

Audit trail: come tracciare accessi a dati e codice

Un audit trail è il registro cronologico e verificabile di chi ha avuto accesso a un dato, un sistema o uno strumento AI, quando e con quale azione. È un requisito esplicito dell'AI Act (Art. 12, Regolamento UE 2024/1689) per i sistemi ad alto rischio e una base per dimostrare conformità NIS2 durante un controllo dell'ACN.

In sintesi

  • Un audit trail è il registro verificabile di chi ha avuto accesso a un dato, un sistema o uno strumento AI, quando e con quale azione.
  • Deve rispondere a quattro domande in ogni singola voce: chi, su quali dati, con quale strumento, in quale momento.
  • L'AI Act richiede la conservazione automatica dei log per i sistemi ad alto rischio (Art. 12); la NIS2 lo richiede implicitamente come prova delle misure di sicurezza (Art. 21).
  • Un audit trail basato solo su policy scritte, senza log tecnici verificabili, non regge a un controllo dell'ACN né a un'ispezione di conformità.
  • DevKira genera un audit trail continuo per ogni accesso a modelli AI, dati e strumenti DevTools, senza configurazione aggiuntiva da parte dei team.

Indice

Cos'è un audit trail?

Un audit trail è una sequenza cronologica di record che documenta chi ha fatto cosa, su quale risorsa e in quale momento, in modo sufficientemente affidabile da poter essere usata come prova in una verifica di conformità o in un'indagine su un incidente.

Non è la stessa cosa di un log tecnico generico. Un log applicativo registra eventi di sistema per finalità di debug; un audit trail deve essere attribuibile a un'identità specifica, non modificabile da chi lo genera, e conservato per un periodo definito. Un sistema che produce log ma li sovrascrive dopo pochi giorni, o che registra un evento senza collegarlo a una persona identificabile, non costituisce un audit trail utilizzabile in sede di controllo.

Audit trail: come tracciare accessi a dati e codice — schema

Cosa deve registrare un audit trail per essere utile?

Un audit trail utile risponde sempre a quattro domande per ogni singola voce: chi ha compiuto l'azione, su quali dati o sistemi, con quale strumento, e in quale momento esatto.

CampoEsempioPerché serve
ChiNome utente o identità autenticata, non un IP anonimoAttribuisce l'azione a una persona responsabile
Su quali datiIl documento, la tabella o il repository coinvoltoPermette di valutare la sensibilità dell'accesso
Con quale strumentoIl modello AI, l'applicazione o il servizio usatoDistingue un uso autorizzato da uno shadow AI
QuandoTimestamp preciso, non solo la dataConsente di ricostruire la sequenza degli eventi in un incidente

Se anche uno solo di questi quattro campi manca sistematicamente, l'audit trail non è in grado di rispondere alla domanda più semplice che un'ispezione pone: "chi ha fatto cosa, e quando?"

Come si verifica se esiste già un audit trail affidabile?

Si verifica in sette passaggi, senza bisogno di un audit esterno: dalla mappatura dei punti di accesso fino al tentativo di ricostruire un evento reale usando solo i log disponibili. Questi passaggi distinguono un audit trail realmente utilizzabile dalla semplice illusione di averne uno.

1. Identifica tutti i punti di accesso a dati e strumenti AI

Elenca ogni sistema, repository e strumento AI usato dai team, incluso ciò che non passa da un processo IT centralizzato: è il punto di partenza, perché non si può tracciare ciò che non si sa che esiste.

2. Verifica se i log vengono generati automaticamente

Un log che dipende da un'attivazione manuale, o che va richiesto esplicitamente al fornitore di un servizio, non è affidabile: deve esistere di default, senza intervento umano.

3. Controlla se i log sono attribuibili a una persona specifica

Un log che registra solo un indirizzo IP o un account condiviso da più persone non permette di rispondere a "chi": verifica che ogni accesso sia collegato a un'identità individuale autenticata.

4. Verifica il periodo di conservazione dei log

Un audit trail conservato per pochi giorni non copre il tempo tipico che intercorre tra un incidente e la sua scoperta: verifica quanto a lungo i log restano disponibili e consultabili.

5. Controlla se i log sono immutabili

Se chi genera un log può anche modificarlo o cancellarlo, l'audit trail perde valore probatorio: verifica che la scrittura dei log sia separata da chi ha i permessi di modificarli.

6. Verifica se i log coprono anche gli strumenti AI, non solo i sistemi IT tradizionali

Molte organizzazioni tracciano bene gli accessi ai sistemi IT classici ma non registrano nulla sull'uso di chatbot o strumenti AI: è spesso il punto cieco più grande, e il più rilevante per l'AI Act.

7. Prova a ricostruire un accesso specifico partendo solo dai log disponibili

Scegli un caso concreto, ad esempio "chi ha avuto accesso a questo documento la settimana scorsa", e prova a rispondere usando solo i log esistenti: se non riesci a farlo in pochi minuti, l'audit trail non è pronto per un controllo reale.

Come si collega un audit trail agli obblighi AI Act e NIS2?

Un audit trail affidabile non è un adempimento a sé stante, ma la prova concreta richiesta da due normative distinte: l'AI Act per i sistemi ad alto rischio, e la NIS2 per dimostrare l'efficacia delle misure di sicurezza adottate.

L'<a href="https://eur-lex.europa.eu/eli/reg/2024/1689/oj" target="_blank" rel="noopener">AI Act</a> impone, all'Art. 12, che i sistemi ad alto rischio siano progettati per generare automaticamente log degli eventi durante il loro funzionamento, in misura sufficiente a garantire un livello di tracciabilità adeguato al rischio. Senza questi log, un'azienda non può dimostrare di aver rispettato gli obblighi di supervisione umana e gestione del rischio previsti dal regolamento.

La <a href="https://eur-lex.europa.eu/eli/dir/2022/2555/oj" target="_blank" rel="noopener">NIS2</a> non nomina esplicitamente l'"audit trail", ma lo richiede nella pratica: l'Art. 21 impone politiche per valutare l'efficacia delle misure di sicurezza, ed è impossibile valutare l'efficacia di un controllo senza un registro che dimostri se e come è stato applicato. Durante un controllo, l'<a href="https://www.acn.gov.it/" target="_blank" rel="noopener">Agenzia per la Cybersicurezza Nazionale</a> verifica proprio la capacità di un'organizzazione di ricostruire chi ha avuto accesso a sistemi e dati critici, un elemento che l'<a href="https://www.enisa.europa.eu/" target="_blank" rel="noopener">ENISA</a> indica tra le pratiche tecniche di base per la resilienza cyber a livello europeo.

Come si costruisce un audit trail per dati, codice e strumenti AI?

Si costruisce centralizzando l'accesso a dati, codice e strumenti AI in un numero ridotto di punti tracciati, invece di inseguire log sparsi su decine di strumenti diversi scelti autonomamente dai team.

Il primo passo pratico è unificare l'accesso agli strumenti AI: se ogni persona usa un account personale su un servizio diverso, non esiste un punto unico da cui estrarre un log coerente. Un gateway AI condiviso, con una virtual key per persona, rende invece ogni richiesta verso un modello tracciabile per utente, modello e timestamp fin dal primo giorno. Lo stesso principio vale per lo <a href="/it/blog/shadow-ai-cosa-e-come-governarlo">shadow AI e la sua governance</a>: senza un punto di accesso centralizzato, l'audit trail avrà sempre dei buchi corrispondenti agli strumenti non ufficiali in uso.

Sul fronte del codice, un catalogo DevTools centralizzato e versionato, con accesso assegnato per ruolo, produce naturalmente un log di chi ha eseguito quale pipeline, su quale repository, con quale strumento: le <a href="/it/capabilities">capacità della piattaforma DevKira</a> coprono esattamente questo perimetro, dal gateway LLM al catalogo DevTools. Per un audit trail che copra anche il resto del ciclo di vita del dato, dalla raccolta alla cancellazione, un <a href="/it/blog/data-governance-framework-aziendale">framework di data governance aziendale</a> strutturato resta il complemento naturale: l'audit trail dimostra cosa è successo, la data governance definisce cosa sarebbe dovuto succedere.

Audit trail: come tracciare accessi a dati e codice — illustrazione

Domande frequenti

Cos'è un audit trail?

Un audit trail è una sequenza cronologica di record che documenta chi ha fatto cosa, su quale dato o sistema e in quale momento, in modo attribuibile a un'identità specifica e non modificabile da chi lo genera. Serve come prova verificabile in caso di controllo di conformità o di indagine su un incidente.

Cosa deve registrare un audit trail per essere considerato completo?

Deve registrare quattro elementi per ogni voce: chi ha compiuto l'azione, su quali dati, con quale strumento e in quale momento esatto. Se manca sistematicamente anche uno solo di questi campi, l'audit trail non è in grado di rispondere alle domande base di un'ispezione.

L'audit trail è obbligatorio per l'AI Act?

Sì, per i sistemi ad alto rischio. L'Art. 12 dell'AI Act richiede che questi sistemi siano progettati per generare automaticamente log degli eventi durante il funzionamento, in misura sufficiente a garantire un livello di tracciabilità adeguato al rischio del sistema.

Che rapporto c'è tra audit trail e conformità NIS2?

La NIS2 non nomina esplicitamente l'audit trail, ma lo richiede nella pratica: l'Art. 21 impone di valutare l'efficacia delle misure di sicurezza adottate, e questo è verificabile solo con un registro che documenti se e come le misure sono state effettivamente applicate.

Quanto tempo devono essere conservati i log di un audit trail?

Non esiste un periodo unico valido per ogni caso: dipende dal settore, dal tipo di dato e dalla normativa applicabile. Come principio pratico, il periodo deve coprire il tempo tipico che intercorre tra un incidente e la sua scoperta, spesso più lungo di quanto le organizzazioni prevedano di default.

Che differenza c'è tra un log generico e un audit trail?

Un log generico registra eventi di sistema per finalità tecniche, spesso in forma anonima o temporanea. Un audit trail è attribuibile a un'identità specifica, non modificabile da chi lo genera e conservato per un periodo definito, così da avere valore probatorio in una verifica di conformità.

Prossimo passo

Un audit trail non si costruisce aggiungendo log a strumenti sparsi: si costruisce riducendo il numero di punti da cui i dati e i modelli AI vengono effettivamente usati.

<a href="/it/book-a-demo">Prenota una demo di DevKira</a> per vedere un audit trail generato automaticamente su accessi a dati, codice e modelli AI, oppure approfondisci come governare lo <a href="/it/blog/shadow-ai-cosa-e-come-governarlo">shadow AI in azienda</a> come primo passo per ridurre i punti ciechi del tuo audit trail.

Guarda DevKira sul tuo workflow

30 minuti sul prodotto live.

Prenota demo

Continua a leggere