Come funziona l’audit di un agente AI
Un percorso di audit deve chiarire chi prepara le prove, chi le verifica e quale risultato permette di passare alla fase successiva. Ecco la struttura proposta: quattro fasi, con ruoli e risultati chiari.
Dall’inventario alla decisione
All’inizio si definisce una configurazione di riferimento. Le prove e i rilievi rimangono legati a quella configurazione; una modifica rilevante durante l’esame richiede di aggiornare il perimetro e ripetere le verifiche interessate.
| Fase | Responsabilità del richiedente | Attività di revisione | Risultato |
|---|---|---|---|
| Perimetro | Dichiara uso, versioni, dati, strumenti e autorizzazioni. | Verifica confini, esclusioni e azioni rilevanti. | Perimetro concordato e piano delle prove. |
| Evidenze | Fornisce policy, configurazioni e campioni condivisibili. | Controlla provenienza, sufficienza e riferimenti. | Indice delle evidenze e lacune iniziali. |
| Test e correzioni | Autorizza l’ambiente e corregge i rilievi. | Esegue verifiche ripetibili e controlla i rimedi. | Esiti dei test e registro dei rilievi. |
| Decisione | Dichiara responsabilità operative e cambiamenti. | Un revisore indipendente esamina prove e limiti. | Decisione motivata o richiesta di ulteriori evidenze. |
Che cosa serve prima delle prove
Il piano deve individuare casi ordinari, casi limite e possibili abusi legati all’uso dichiarato. Per un agente vocale, ad esempio, contano le lingue supportate e le situazioni che richiedono una persona; per un’automazione, conta cosa succede con tentativi ripetuti, attese troppo lunghe e approvazioni scadute.
Prima dei test si concorda per iscritto l’ambiente, i dati utilizzabili, gli strumenti raggiungibili e quando fermarsi. Nessuna prova invasiva su sistemi di terzi senza autorizzazione.
- Inventario versionato ed elenco delle azioni: autonome, da approvare, vietate.
- Flussi dei dati, località di trattamento e destinatari dichiarati.
- Casi con esito atteso, tracce pertinenti e responsabili dei controlli.
- Incidenti noti, procedure di arresto e modifiche recenti.
Come si chiude un rilievo
Una correzione va verificata sul comportamento, non sulla carta: aggiornare una regola scritta o un prompt non dimostra da solo che un’azione non autorizzata ora sia bloccata. Il riesame ripete il caso che aveva fallito e controlla che nulla si sia rotto altrove (regressioni).
Il registro conserva la descrizione del problema, l’evidenza della correzione e la motivazione dell’esito. Se mancano prove sufficienti, la questione resta aperta: non viene trasformata in un controllo superato.
Dopo il riesame
La bozza propone un riesame trimestrale delle evidenze e una rivalutazione anticipata dopo cambiamenti rilevanti o incidenti. L’aggiunta di un tool con capacità di invio, un ampliamento dei dati accessibili o una modifica delle approvazioni possono richiedere nuove prove prima dell’intervallo ordinario.
Competenze dei valutatori, gestione dei conflitti, ricorsi e condizioni contrattuali saranno definiti prima dell’avvio dello schema operativo. Non promettiamo una durata standard valida per ogni sistema: dipende da perimetro ed evidenze.
Domande frequenti
Posso iniziare senza avere tutta la documentazione?
Puoi descrivere il caso d’uso e le evidenze già disponibili. L’assenza di documenti deve emergere nella definizione del perimetro; non si presuppone che un controllo esista finché non è dimostrato.
Chi corregge i problemi rilevati?
Tu o il tuo fornitore correggete; noi verifichiamo la correzione. La decisione finale resta a un revisore indipendente da chi ha costruito il sistema.
Ogni aggiornamento richiede di ripetere tutto?
Dipende dall’impatto sul perimetro. La modifica viene registrata, si individuano i controlli coinvolti e si giustifica l’estensione delle nuove prove; un cambiamento rilevante non può essere ignorato.