Registrazione degli eventi: guida pratica ISO 42001 con esempi
Il controllo A.6.2.8 chiede che il sistema di IA registri automaticamente gli eventi rilevanti del suo funzionamento. Come progettare log completi, integri e consultabili, pronti per l'audit interno.
Cosa prevede il punto A.6.2.8
Questa guida pratica alla ISO 42001 spiega con esempi il controllo A.6.2.8, che richiede la registrazione degli eventi generati dal sistema di IA durante il funzionamento: richieste ricevute, risposte prodotte, versione del modello, errori e interventi umani. L'obiettivo è poter ricostruire, in qualsiasi momento, cosa ha fatto il sistema e perché.
Il controllo si applica a ogni organizzazione che opera sistemi di IA in produzione. In Azienda Italiana S.p.A. riguarda il chatbot di assistenza clienti e il tool di screening CV: ogni interazione, punteggio e override manuale finisce in un log centralizzato, protetto da modifiche e consultabile in pochi minuti quando serve un'indagine.
La registrazione eventi non vive da sola: alimenta il monitoraggio del comportamento del sistema, la gestione degli incidenti e la documentazione tecnica del controllo A.6.2.7. In questa guida pratica trovi il testo parafrasato del controllo, una scheda operativa, l'estratto della procedura LOG-AI-08, sei domande tipiche d'audit e gli errori più frequenti.
In sintesi, la norma vuole vedere:
- Log automatici attivi su ogni sistema IA
- Eventi completi: input, output, versione
- Log centralizzati e protetti da modifiche
- Conservazione e accessi definiti per ruolo
- Evidenze di analisi periodica dei log
Esempio di controllo tecnico per il punto A.6.2.8
Primo esempio: il chatbot di Azienda Italiana S.p.A. scrive un record per ogni conversazione — identificativo di sessione, data e ora, domanda dell'utente, risposta generata, versione del modello, punteggio di confidenza ed eventuale passaggio all'operatore umano. Quando un cliente contesta una risposta, il supporto ricostruisce l'intero scambio in pochi minuti e capisce se l'errore è nato dal modello, dai dati o da una configurazione.
Controllo tecnico collegato: i log dello screening CV e del chatbot confluiscono in una piattaforma centralizzata con firma hash a catena: ogni riga è collegata alla precedente, quindi una manomissione risulta subito evidente. L'accesso è limitato a Security e Responsabile AIMS, la conservazione è di 24 mesi e scatta un alert automatico se il flusso di registrazione eventi si interrompe.
Cosa deve registrare il sistema di IA
| Tipo di evento | Cosa contiene | Perché serve |
|---|---|---|
| Richiesta in ingresso | Input, timestamp, id sessione | Ricostruire il contesto |
| Risposta del modello | Output, versione, confidenza | Dimostrare il comportamento |
| Errore o anomalia | Codice, componente, impatto | Indagare gli incidenti |
| Intervento umano | Chi, quando, motivazione | Tracciare l'override |
| Accesso ai log | Utente, ruolo, operazione | Garantire l'integrità |
Nota: la registrazione eventi è la materia prima di monitoraggio, gestione incidenti e audit interno: senza log affidabili, ogni altra verifica sul comportamento del sistema resta un'opinione.
Cosa scriverebbe "Azienda Italiana S.p.A." sul punto A.6.2.8
Estratto semplificato della procedura con cui Azienda Italiana S.p.A. raccoglie, protegge e analizza i log del chatbot di assistenza clienti e dello screening CV.
Procedura di registrazione degli eventi dei sistemi di IA
Metodo
Ogni sistema di IA produce log in formato strutturato e li invia in tempo reale alla piattaforma centralizzata. I record sono firmati a catena, conservati 24 mesi e accessibili solo ai ruoli autorizzati. Il Security Officer analizza i log ogni settimana; il Responsabile AIMS riceve un riepilogo mensile con anomalie, override e disponibilità della registrazione eventi.
Estratto
| Evento | Campi obbligatori | Conservazione |
|---|---|---|
| Conversazione chatbot | Sessione, input, output, modello, confidenza | 24 mesi |
| Punteggio screening CV | Id candidatura, score, criteri, versione | 24 mesi |
| Override umano | Operatore, motivazione, esito | 36 mesi |
| Errore di sistema | Codice, componente, impatto utente | 36 mesi |
| Accesso ai log | Utente, ruolo, operazione | 36 mesi |
Ruoli e responsabilità
| Ruolo | Responsabilità |
|---|---|
| Security Officer | Gestisce la piattaforma log e l'analisi settimanale |
| ML Engineer | Mantiene la strumentazione di logging nei rilasci |
| Responsabile AIMS | Riesamina riepiloghi mensili e anomalie |
| Internal Auditor | Verifica completezza e integrità dei log |
Checklist operativa
| Verifica | Frequenza |
|---|---|
| Flusso log attivo su entrambi i sistemi | Giornaliera, con alert automatico |
| Integrità della catena hash | Settimanale |
| Campione di eventi ricostruito end-to-end | Mensile |
| Revisione accessi alla piattaforma log | Trimestrale |
Esito
Registrazione eventi completa, integra e dimostrabile. In caso di incidente o reclamo, la ricostruzione avviene entro 4 ore. Ogni interruzione del flusso apre una non conformità nel registro REG-AI-09 con ripristino prioritario.
Le domande dell'audit interno sul punto A.6.2.8
Domande di audit interno su questo punto, con risposte coerenti ed evidenze.
I consigli del Dott. Valerio Bellini sul punto A.6.2.8
Dott. Valerio Bellini
«Il consiglio strategico è semplice: progettate i log prima del modello. Chi aggiunge la registrazione eventi a sistema già in produzione scopre buchi che non si possono più chiudere.»
«In audit interno, se manca un log completo e integro di un evento contestato, è quasi certamente una non conformità. Per questo chiedo sempre di ricostruire un episodio reale, non un report.»
Gli errori più comuni che incontro:
- Log solo in caso di errore: Eventi normali non registrati: ricostruzione impossibile
- Log dispersi nei server: Nessuna piattaforma centralizzata né consultazione rapida
- Integrità non protetta: Log modificabili da chi amministra il sistema
- Conservazione non definita: Cancellazioni automatiche prima del tempo utile
- Nessuno legge i log: Raccolta attiva ma mai analizzata né riesaminata