Deployment del sistema di IA: guida pratica ISO 42001 con esempi
Come dimostrare un deployment controllato: gate di rilascio, autorizzazioni firmate, rollback testato e verifiche post-deploy, con gli esempi del chatbot e dello screening CV di Azienda Italiana S.p.A.
Cosa prevede il punto A.6.2.5
Questa guida pratica alla ISO 42001 spiega con esempi il controllo A.6.2.5, che richiede di pianificare e governare il deployment del sistema di IA: il passaggio in produzione deve seguire criteri definiti, ambienti separati, autorizzazioni tracciate e verifiche documentate prima e dopo il rilascio in esercizio.
Il controllo riguarda chi progetta, rilascia e mantiene sistemi di IA: sviluppatori, IT operations, data scientist e AIMS manager. In Azienda Italiana S.p.A. si applica sia al deployment del chatbot per l'assistenza clienti sia al rilascio del modello di screening dei CV, comprese le patch e gli aggiornamenti periodici del modello.
Il deployment si colloca a valle di verifica e validazione (A.6.2.4), che ne costituisce il gate di ingresso, e a monte di funzionamento e monitoraggio (A.6.2.6): senza un rilascio controllato, le evidenze prodotte in fase di test perdono valore e il monitoraggio parte da una configurazione non nota, non autorizzata e non riproducibile.
In sintesi, la norma vuole vedere:
- Procedura di deployment approvata
- Registro dei rilasci in produzione
- Autorizzazione pre-rilascio firmata
- Piano di rollback testato
- Evidenza delle verifiche post-deploy
Esempio di controllo tecnico per il punto A.6.2.5
Per il chatbot di assistenza clienti, Azienda Italiana S.p.A. esegue il deployment solo con un pacchetto di rilascio completo: versione del modello, dataset e prompt di riferimento, esiti di verifica e validazione, piano di rollback e approvazione firmata dall'AIMS manager. Ogni rilascio è annotato nel registro con data, ambiente, versione e responsabile, così da ricostruire in qualsiasi momento quale configurazione è in esercizio e chi l'ha autorizzata.
Controllo tecnico collegato: per il sistema di screening CV il deployment avviene tramite una pipeline automatizzata con ambienti di test, staging e produzione separati: il modello passa in esercizio solo se i controlli automatici su accuratezza, bias e soglie di qualità risultano superati; in caso contrario la pipeline si blocca, notifica il team e ripristina la versione precedente senza intervento manuale.
Mappa del controllo A.6.2.5
| Elemento | Come lo attua Azienda Italiana S.p.A. |
|---|---|
| Ambito | Deployment del sistema di IA in produzione |
| Requisito | Rilascio pianificato, autorizzato e tracciato |
| Evidenza chiave | Registro rilasci e moduli di autorizzazione firmati |
| Documento guida | DEP-AI-05 Procedura di deployment |
| Frequenza | A ogni rilascio, aggiornamento o rollback |
| Responsabile | AIMS manager con supporto di IT operations |
Nota: la matrice mostra come questa guida pratica traduce il deployment in evidenze dimostrabili in audit interno: ogni riga collega un requisito della norma a un documento consultabile dall'auditor senza interpretazioni.
Cosa scriverebbe "Azienda Italiana S.p.A." sul punto A.6.2.5
Estratto della procedura che governa il deployment in produzione dei sistemi di IA di Azienda Italiana S.p.A., redatta in forma telegrafica e usata come evidenza principale durante l'audit interno annuale sul Sistema di Gestione per l'Intelligenza Artificiale.
Procedura di deployment dei sistemi di IA
Metodo
Rilascio a stadi: test, staging, produzione. Nessun deployment senza autorizzazione formale, piano di rollback testato e verifica post-rilascio entro 48 ore. Le eccezioni richiedono approvazione scritta della Direzione Generale.
Estratto
| Fase | Ambiente | Gate di passaggio |
|---|---|---|
| Preparazione pacchetto | Test | Test unitari e integrazione superati |
| Validazione del modello | Staging | Esito positivo di A.6.2.4 registrato |
| Autorizzazione | Staging | Firma AIMS manager su MOD-AI-02 |
| Rilascio in esercizio | Produzione | Checklist operativa completa |
| Verifica post-deploy | Produzione | KPI entro soglia per 48 ore |
Ruoli e responsabilità
| Ruolo | Responsabilità |
|---|---|
| AIMS manager | Autorizza ogni rilascio e approva le eccezioni |
| IT operations | Esegue deploy e rollback sulla pipeline |
| Data scientist | Prepara pacchetto, versioni e note di rilascio |
| Direzione Generale | Approva la procedura e le soglie di rischio |
Checklist operativa
| Voce di controllo | Esito |
|---|---|
| Versione modello e dataset registrati | Sì, in DEP-AI-06 |
| Piano di rollback allegato e testato | Sì, DEP-AI-07 |
| Autorizzazione pre-rilascio firmata | Sì, MOD-AI-02 |
| Verifica post-deploy entro 48 ore | Sì, report KPI allegato |
Esito
Deploy riuscito: evidenze archiviate nel registro rilasci e monitoraggio attivato. Esito negativo: rollback automatico, riesame delle cause in riunione AIMS e azione correttiva con scadenza.
Le domande dell'audit interno sul punto A.6.2.5
Domande di audit interno su questo punto, con risposte coerenti ed evidenze.
I consigli del Dott. Valerio Bellini sul punto A.6.2.5
Dott. Valerio Bellini
«Il consiglio strategico è uno solo: trattate il deployment come un gate formale, non come un'operazione tecnica di routine. Se il rilascio resta un click informale, l'AIMS perde credibilità.»
«In audit interno chiedo il registro rilasci e incrocio date, versioni e firme: in audit interno, se manca l'autorizzazione pre-rilascio, è quasi certamente una non conformità.»
Gli errori più comuni che incontro:
- Deploy senza autorizzazione: Manca la firma pre-rilascio dell'AIMS manager
- Registro rilasci incompleto: Versioni in produzione non tracciate nel registro
- Rollback mai testato: Il piano di rollback esiste solo sulla carta
- Ambienti non separati: Test e produzione condividono dati e credenziali
- Nessuna verifica post-deploy: Dopo il rilascio nessuno controlla il sistema