Verifica e validazione IA: guida pratica ISO 42001 con esempi
Come dimostrare che un sistema di IA fa davvero ciò per cui è stato progettato: criteri di accettazione, piani di test e validazione documentata, spiegati con il caso di Azienda Italiana S.p.A.
Cosa prevede il punto A.6.2.4
Questa guida pratica alla ISO 42001 spiega con esempi il controllo A.6.2.4: come pianificare, eseguire e documentare la verifica e validazione del sistema di IA prima del rilascio, con criteri di accettazione misurabili e il caso concreto di Azienda Italiana S.p.A.
Il controllo si applica a ogni organizzazione che sviluppa o integra sistemi di IA: la verifica controlla che il sistema sia costruito secondo specifiche e requisiti, la validazione che risponda davvero all'uso previsto nel contesto reale. Entrambe vanno pianificate, eseguite con criteri di accettazione approvati e registrate in modo tracciabile.
Vedremo come il controllo si collega alla documentazione di progettazione (A.6.2.3) e al deployment (A.6.2.5), due esempi sul chatbot clienti e sullo screening CV, un estratto di procedura, sei domande tipiche dell'auditor e gli errori più frequenti. Una guida pratica per chi deve attuare il controllo, non solo leggerlo.
In sintesi, la norma vuole vedere:
- Criteri di accettazione definiti e approvati
- Piano di test eseguito prima del rilascio
- Evidenze di validazione con dati reali
- Risultati registrati e tracciati
- Difetti gestiti fino alla chiusura
Esempio di controllo tecnico per il punto A.6.2.4
Per il chatbot di assistenza clienti, Azienda Italiana S.p.A. ha definito un piano di verifica e validazione con soglie esplicite: accuratezza delle risposte almeno al 92% su un dataset di riferimento di 500 conversazioni annotate, tasso di escalation all'operatore sotto il 15% e zero risposte fuori perimetro nei test di sicurezza. Ogni rilascio è bloccato finché i test automatici e il collaudo del servizio clienti non superano tutte le soglie: il verbale di collaudo firmato è l'evidenza che questa guida pratica consiglia di conservare.
Controllo tecnico collegato: per lo screening dei CV, la validazione include un test di equità su un campione stratificato per genere ed età: lo scarto dei tassi di errore tra gruppi non può superare il 5% e ogni versione del modello viene congelata con l'hash del dataset di test, così i risultati restano riproducibili in qualsiasi audit.
Matrice di verifica e validazione dei sistemi di IA
| Attività | Sistema | Criterio di accettazione | Evidenza |
|---|---|---|---|
| Test di accuratezza | Chatbot clienti | Accuratezza ≥ 92% | Report VER-AI-03 |
| Test di sicurezza | Chatbot clienti | Zero risposte fuori perimetro | Esito test automatici |
| Test di equità | Screening CV | Scarto errori tra gruppi ≤ 5% | Report VER-AI-03 |
| Collaudo utente | Entrambi | Approvazione del referente di processo | Verbale VER-AI-04 |
| Riproducibilità | Entrambi | Dataset e modello versionati con hash | Registro VER-AI-02 |
Ogni attività è collegata a un criterio misurabile e a un'evidenza datata: un test senza criterio approvato vale quanto un test mai eseguito.
Cosa scriverebbe "Azienda Italiana S.p.A." sul punto A.6.2.4
Estratto della procedura che disciplina verifica e validazione dei sistemi di IA in Azienda Italiana S.p.A.: metodo, soglie di accettazione e ruoli, gli stessi citati in questa guida pratica.
Procedura di verifica e validazione dei sistemi di IA
Metodo
Nessun rilascio senza piano di test approvato. Test automatici su dataset di riferimento versionato. Collaudo utente obbligatorio prima della messa in produzione. Risultati registrati con esito puntuale per ogni criterio. Difetti bloccanti chiusi prima del rilascio.
Estratto
| Ambito | Regola operativa |
|---|---|
| Piano di test | Approvato prima dell'esecuzione, con criteri e soglie per ogni requisito |
| Chatbot clienti | Accuratezza ≥ 92% su 500 casi annotati, escalation ≤ 15% |
| Screening CV | Test di equità su campione stratificato, scarto errori ≤ 5% |
| Collaudo | Verbale firmato dal referente di processo prima del deployment |
| Difetti | Classificati per gravità: i bloccanti vietano il rilascio |
Ruoli e responsabilità
| Ruolo | Responsabilità |
|---|---|
| Direzione Generale | Approva criteri di accettazione e deroghe al rilascio |
| AI Compliance Officer | Definisce il piano di test e registra i risultati |
| Team di sviluppo | Esegue i test tecnici e corregge i difetti rilevati |
| Referente di processo | Esegue il collaudo utente e firma il verbale |
Checklist operativa
| Verifica | Esito atteso |
|---|---|
| Il piano di test è approvato prima dell'esecuzione? | Sì, con criteri e soglie |
| Ogni criterio ha un risultato registrato? | Sì, esito puntuale datato |
| Il dataset di test è versionato? | Sì, con hash nel registro |
| I difetti bloccanti sono tutti chiusi? | Sì, con retest superato |
Esito
Sistemi rilasciati solo dopo verifica e validazione superate. Risultati tracciati per versione. Collaudi firmati e difetti chiusi con retest documentato.
Le domande dell'audit interno sul punto A.6.2.4
Domande di audit interno su questo punto, con risposte coerenti ed evidenze.
I consigli del Dott. Valerio Bellini sul punto A.6.2.4
Dott. Valerio Bellini
«Consiglio strategico: fissate i criteri di accettazione prima di scrivere i test, mai dopo. Se la soglia nasce dal risultato ottenuto, la verifica e validazione diventa una formalità e l'auditor se ne accorge.»
«In audit interno, se manca il verbale di collaudo firmato prima del rilascio, è quasi certamente una non conformità. Chiedo sempre: piano approvato, risultati per criterio e retest dei difetti.»
Gli errori più comuni che incontro:
- Test senza criteri di accettazione: Test eseguiti senza soglie approvate in anticipo.
- Collaudo dopo il rilascio: Sistema in produzione prima della validazione utente.
- Risultati non registrati: Test eseguiti ma senza report datato e tracciato.
- Dataset di test non versionato: Risultati di validazione non riproducibili in audit.
- Difetti bloccanti ignorati: Rilascio autorizzato con test critici falliti.