Registro delle decisioni sull’IA: come documentare rischi, controlli e prove

Che cos’è un registro delle decisioni e a cosa serve

Un registro delle decisioni sull’IA è una cronologia strutturata delle decisioni rilevanti relative alla progettazione, alla configurazione, alla convalida, alla messa in esercizio e alle modifiche di un sistema. La sua utilità non consiste nell’accumulare documenti, ma nel permettere di ricostruire che cosa è stato deciso, perché, chi ha assunto la decisione, quale controllo è stato attuato e quali prove dimostrano che quel controllo è stato verificato. Può comprendere decisioni tecniche e organizzative, dalla scelta di una soglia alla definizione di chi esamina i risultati del sistema.

Il registro aiuta a illustrare il processo ai team interni, agli auditor o alle autorità, ma da solo non dimostra la conformità. Inoltre, non sostituisce la documentazione tecnica, i registri operativi, la valutazione dei rischi né gli obblighi di legge applicabili a una specifica organizzazione o a un determinato sistema. La guida dell’Agenzia spagnola per la supervisione dell’intelligenza artificiale sui registri tratta gli obblighi di conservazione previsti per alcuni soggetti responsabili di sistemi ad alto rischio: non si devono estendere automaticamente a qualsiasi strumento di IA.

È opportuno definire fin dall’inizio l’ambito del registro. Indica a quale sistema e versione si riferisce, quali usi previsti comprende, chi lo mantiene e quali tipi di decisione devono essere annotati. Una modifica che non incida sul comportamento o sull’uso può essere documentata in forma sintetica; una variazione dei dati, delle soglie, della popolazione di utenti o della supervisione umana può richiedere una valutazione più approfondita. La scelta di registrare una decisione e il livello di dettaglio dovrebbero essere proporzionati all’impatto e al contesto, senza presentarli come una regola di legge universale.

Campi pratici per documentare ogni decisione

Non esiste un insieme di campi che si possa definire minimo e sufficiente per tutti i sistemi, gli usi e gli obblighi. Come base operativa, una voce dovrebbe permettere di identificare il sistema e la sua versione, la data, la persona responsabile, la decisione presa, il rischio o l’esigenza che l’ha motivata, il controllo associato, le prove disponibili e l’esito della verifica. Aggiungere lo stato, i limiti e una data o una condizione per la revisione facilita la manutenzione successiva.

Una voce chiara distingue rischio, controllo e prova. Il rischio descrive un possibile danno in uno specifico contesto; il controllo è una misura concreta destinata a prevenirlo, ridurlo o rilevarlo; la prova mostra che cosa è stato verificato e con quale esito. Per esempio, «errori di classificazione» è troppo generico se non si specificano la popolazione e l’uso. «Mantenere la revisione umana nei casi di bassa affidabilità» descrive una misura, ma non chiarisce ancora come si individua un caso di bassa affidabilità né come si dimostra che la revisione sia avvenuta.

Registra riferimenti stabili agli artefatti, non soltanto nomi generici. Un riferimento utile può includere un identificativo, la versione, la data, la posizione in un archivio interno autorizzato e il responsabile della custodia. Proteggi i dati personali e riservati con controlli di accesso adeguati ed evita di copiare nel registro contenuti sensibili non necessari. Se una prova non è più disponibile, annota il problema e le azioni previste per recuperarla o ripetere la verifica.

Collegare rischi, controlli e verifiche

Costruisci una catena tracciabile: rischio specifico, obiettivo di mitigazione, controllo attuato, metodo di verifica ed esito. Ogni collegamento dovrebbe poter essere seguito tramite identificativi coerenti. Se un controllo mitiga più rischi, registra ciascuna relazione; se un rischio richiede più misure, documenta ogni controllo e le dipendenze tra di essi. In questo modo si evita che un elenco di rischi resti separato dalle attività di ingegneria o dalle decisioni operative.

Le prove devono riferirsi alla configurazione e all’uso oggetto della valutazione. Un rapporto di test su una versione precedente può essere utile come riferimento, ma non dimostra automaticamente l’efficacia dopo una modifica. Specifica l’ambiente, i dati o gli scenari utilizzati, i criteri di accettazione, l’esito e i limiti. Se un test non copre tutte le condizioni reali, registra la lacuna e indica quale supervisione o misura aggiuntiva viene applicata.

Le prove quantitative non sono sempre sufficienti. Per una misura organizzativa, come la revisione umana, può essere utile conservare le procedure in vigore, campioni di casi esaminati, registri delle escalation e verifiche che il personale abbia ricevuto istruzioni. Il livello di prova dipende dal rischio e da ciò che si intende dimostrare. Un audit algoritmico può aiutare a strutturare la revisione delle misure di mitigazione e dei controlli, ma una raccomandazione generale non dimostra, da sola, che una misura specifica sia stata applicata o sia efficace.

Processo di creazione e manutenzione

Inizia con un inventario dei sistemi e delle versioni e definisci chi ha l’autorità di approvare le decisioni e chi mantiene le prove. Concorda convenzioni comuni per identificare rischi, controlli e artefatti. Ogni voce dovrebbe avere un responsabile: indicare genericamente un team o una casella di posta senza assegnare una funzione rende più difficile seguire le attività. Stabilisci anche chi può accedere al registro e come gestire le modifiche e le correzioni.

Annota le decisioni quando vengono prese o quando le prove sono convalidate, non mesi dopo, in occasione di un audit. Collega ogni modifica rilevante alla versione interessata e conserva una cronologia che permetta di capire quando il registro è stato aggiornato. Durante la revisione di una voce, verifica se il rischio è ancora attuale, se il controllo è tuttora applicato, se le prove riguardano la versione corrente e se i limiti o le azioni in sospeso sono ancora aperti.

Non esiste un’unica frequenza di revisione che possa essere prescritta in generale per tutti i sistemi. Definisci revisioni periodiche proporzionate al contesto e aggiungi revisioni attivate da eventi: una nuova versione, modifiche ai dati o al fornitore, un cambiamento dell’uso previsto, incidenti, risultati di monitoraggio diversi da quelli attesi o modifiche normative applicabili. Se non ci sono stati cambiamenti, registra la revisione e la relativa conclusione, affinché la mancanza di annotazioni non sembri un’omissione.

Criteri di verificabilità e errori frequenti

Un registro verificabile si comprende senza dipendere dalla memoria di chi lo ha creato. Ogni voce dovrebbe essere leggibile, datata, attribuibile e collegata ad artefatti accessibili a chi è autorizzato. Completezza non significa includere tutto: significa che le informazioni necessarie a ricostruire la decisione sono presenti, che le lacune sono segnalate e che le affermazioni non vanno oltre ciò che le prove consentono di concludere.

Evita di descrivere i controlli con verbi vaghi, come «monitorare» o «migliorare», se non spieghi chi li esegue, quando e come se ne verifica l’attuazione. Evita anche di presentare una politica, una valutazione d’impatto o una casella di approvazione come prova di efficacia. Questi documenti possono essere pertinenti, ma dimostrano aspetti diversi. La guida dell’Agenzia spagnola per la protezione dei dati sugli audit dei trattamenti che includono IA fornisce un contesto istituzionale per esaminare i trattamenti, ma non trasforma un modello di registro in una garanzia automatica di conformità.

Prima di un audit, seleziona alcune decisioni e ricostruiscile in entrambe le direzioni: da ciascun rischio al controllo e alle prove, e da un test alla decisione che ne utilizza i risultati. Verifica che i collegamenti siano ancora disponibili, che le versioni corrispondano, che i responsabili siano identificati e che le eccezioni siano motivate. Se emerge una lacuna, registrala come rilievo con un responsabile e un’attività di seguito; non nasconderla sostituendo retroattivamente una prova incompleta.

Criteri pratici per iniziare

Comincia con un modello breve e prova a utilizzarlo per una decisione reale prima di trasformarlo in un modulo lungo. Se un campo non aiuta a identificare, spiegare, verificare o mantenere una decisione, valuta se debba comparire nel registro o in un altro artefatto collegato. La struttura dovrebbe consentire di seguire la catena tra rischio, misura e prova senza duplicare inutilmente la documentazione tecnica o i registri operativi.

Adegua conservazione, permessi di accesso e livello di dettaglio agli obblighi applicabili, al tipo di dati e alle esigenze di audit. Per il caso specifico, consulta la normativa e le istruzioni istituzionali vigenti: gli obblighi possono dipendere dal ruolo dell’organizzazione, dal tipo di sistema e dal suo uso. Il registro aiuta a organizzare e illustrare le prove; non sostituisce l’analisi giuridica né dimostra, da solo, che il sistema sia conforme.

In definitiva, considera completa una voce quando un’altra persona autorizzata può ricostruire, usando il registro, che cosa è stato deciso, quale rischio è stato affrontato, quale controllo è stato applicato, quali prove sono state esaminate, quali limiti sussistono e quando occorre una nuova revisione. Se manca uno di questi elementi, esplicita l’incertezza e assegna un’attività. Documentare con trasparenza una lacuna è più utile che affermare un’efficacia priva di riscontri verificabili.

Continua a esplorare

Correzioni e trasparenza

Se trovi un dato errato o non aggiornato, inviaci la pagina e la fonte da verificare.