Documentazione progettazione: guida pratica ISO 42001 con esempi
Come documentare progettazione e sviluppo di un sistema di IA in modo verificabile: deliverable, versionamento ed evidenze pronte per l'audit interno, con l'esempio del chatbot di Azienda Italiana S.p.A.
Cosa prevede il punto A.6.2.3
Questa guida pratica alla ISO 42001 spiega con esempi il controllo A.6.2.3, che richiede di documentare in modo strutturato e mantenuto la progettazione e lo sviluppo del sistema di IA: architettura, dati utilizzati, modelli scelti, decisioni tecniche e versioni rilasciate devono restare tracciati e ricostruibili lungo tutto il ciclo di vita.
Il controllo si applica a chiunque sviluppi, integri o mantenga sistemi di IA: team di data science, IT, fornitori esterni e funzioni di governo. Per Azienda Italiana S.p.A. riguarda sia il chatbot di assistenza clienti sia il modulo di screening dei CV, ciascuno con un proprio dossier tecnico di progetto aggiornato e approvato.
La documentazione progettazione si collega direttamente ai requisiti e alle specifiche definiti con A.6.2.2, alimenta le attività di verifica e validazione di A.6.2.4 e fornisce evidenze alla gestione dei dati, alla valutazione d'impatto e all'inventario dei sistemi di IA dell'organizzazione.
In sintesi, la norma vuole vedere:
- Dossier di progetto approvato e versionato
- Decisioni tecniche motivate e tracciate
- Architettura, dati e modelli documentati
- Storico modifiche coerente con i rilasci
- Evidenze collegate a requisiti e test
Esempio di controllo tecnico per il punto A.6.2.3
Per il chatbot di assistenza clienti, Azienda Italiana S.p.A. mantiene un dossier di progettazione che raccoglie l'architettura RAG adottata, le fonti dati autorizzate, i prompt di sistema, i criteri di scelta del modello linguistico e le motivazioni delle soglie di escalation verso l'operatore umano. Ogni rilascio aggiorna il dossier con numero di versione, autore, data e sintesi delle modifiche, in modo che un revisore possa ricostruire perché il sistema risponde in un certo modo e con quali limiti.
Controllo tecnico collegato: il versionamento di codice, modelli e dataset in repository con tag firmati, integrato nella pipeline CI/CD, registra automaticamente commit, configurazioni e parametri di addestramento. Il collegamento bidirezionale tra commit, versione del modello e voce del dossier trasforma la documentazione progettazione in evidenza tecnica verificabile, e non in una semplice descrizione redatta a posteriori.
Cosa deve contenere la documentazione progettazione
| Elemento del progetto | Evidenza documentale attesa |
|---|---|
| Architettura del sistema | Componenti, flussi dati, integrazioni e dipendenze esterne |
| Dati di addestramento e test | Origine, qualità, trasformazioni applicate e basi giuridiche |
| Modello di IA | Tipo, parametri, criteri di scelta e alternative valutate |
| Prompt, regole e guardrail | Versioni, proprietari e criteri di approvazione delle modifiche |
| Decisioni tecniche rilevanti | Motivazioni, trade-off accettati e impatti sul livello di rischio |
La documentazione progettazione è un artefatto vivo: va aggiornata a ogni modifica sostanziale, riesaminata periodicamente e resa disponibile alle attività di audit interno del ciclo AIMS.
Cosa scriverebbe "Azienda Italiana S.p.A." sul punto A.6.2.3
Estratto semplificato della procedura con cui Azienda Italiana S.p.A. governa la documentazione progettazione dei suoi sistemi di IA: una guida pratica replicabile in qualsiasi AIMS.
Procedura di documentazione di progettazione e sviluppo IA
Metodo
Ogni progetto IA apre un dossier tecnico entro la fase di concept; il dossier segue l'intero ciclo di vita, è conservato in repository documentale con versionamento e viene riesaminato obbligatoriamente a ogni rilascio in produzione.
Estratto
| Sezione del dossier | Contenuto minimo richiesto |
|---|---|
| Architettura | Componenti, integrazioni e flussi dati |
| Dati | Origine, profilatura qualità e limiti d'uso |
| Modello | Scelta, parametri e metriche target |
| Interfaccia e prompt | Versioni, guardrail e regole di escalation |
| Sicurezza | Minacce, controlli applicati e residui accettati |
Ruoli e responsabilità
| Ruolo | Responsabilità |
|---|---|
| Responsabile Sviluppo IA | Redige e aggiorna il dossier di progetto |
| Data Protection Officer | Verifica sezioni dati e valutazione d'impatto |
| Responsabile Qualità | Controlla completezza, formato e versionamento |
| Direzione Generale | Approva le revisioni maggiori del dossier |
Checklist operativa
| Passo | Verifica |
|---|---|
| Apertura dossier | Entro l'avvio formale dello sviluppo |
| Aggiornamento rilascio | Prima di ogni go-live in produzione |
| Riesame periodico | Almeno annuale o a modifica sostanziale |
| Archiviazione versioni | Storico completo e consultabile nel tempo |
Esito
Dossier allineato allo stato reale del sistema: ogni comportamento osservabile in produzione è ricondotto a una decisione progettuale documentata, motivata e approvata dai ruoli competenti.
Le domande dell'audit interno sul punto A.6.2.3
Domande di audit interno su questo punto, con risposte coerenti ed evidenze.
I consigli del Dott. Valerio Bellini sul punto A.6.2.3
Dott. Valerio Bellini
«Consiglio strategico: trattate il dossier di progettazione come asset di governance e guida pratica per ogni modifica futura, non come adempimento. Aggiornato davvero, dimezza verifica e validazione.»
«In audit interno confronto dossier e sistema in produzione: in audit interno, se manca il dossier di progettazione aggiornato, è quasi certamente una non conformità.»
Gli errori più comuni che incontro:
- Dossier scritto a progetto finito: Redatto dopo il go-live: non ricostruisce le decisioni.
- Versioni non allineate ai rilasci: Il dossier descrive una versione diversa dalla produzione.
- Decisioni tecniche senza motivazione: Scelte su modello e dati registrate senza perché.
- Documenti dispersi tra strumenti: Wiki, repository e cartelle condivise non riconciliati.
- Nessun riesame periodico pianificato: Nessuna data di revisione né owner del dossier.