--- title: "La documentazione minima di un AIMS: cosa chiede davvero ISO/IEC 42001" url: https://zerofive.ai/blog/compliance/documentazione-minima-aims-iso-42001 canonical: https://zerofive.ai/blog/compliance/documentazione-minima-aims-iso-42001 language: it published: 2026-09-01 updated: 2026-09-18 author: "ZeroFive.AI" tags: ISO IEC 42001, AIMS, documentazione AI, AI Management System, compliance AI abstract: "I documenti minimi richiesti da ISO/IEC 42001 per un AI Management System: cosa serve davvero, cosa no, e in che ordine costruirli." --- # La documentazione minima di un AIMS: cosa chiede davvero ISO/IEC 42001 Nelle valutazioni di maturità AI che facciamo, la scena si ripete quasi sempre uguale: una cartella condivisa piena di PDF, una policy scritta un anno fa e mai più aperta, qualche slide di presentazione spacciata per procedura. L'azienda pensa di avere già la documentazione per un sistema di gestione dell'intelligenza artificiale. Ne ha, in realtà, solo i frammenti sparsi. ## Il malinteso di partenza Il primo equivoco su [ISO/IEC 42001](/blog/compliance/iso-42001-ai-management-system) riguarda cosa un audit va davvero a cercare: la quantità di pagine prodotte pesa meno di quanto si creda, quello che un auditor verifica è se quei documenti vengono usati per decidere. Un registro dei rischi aggiornato l'ultima volta prima del lancio del progetto non serve a nessuno, tantomeno a chi chiede di vedere l'ultima revisione e la relativa data. La documentazione, in un AI Management System, funziona più come infrastruttura decisionale che come prova di conformità: permette a un'organizzazione di scegliere con basi solide, e di rendere conto di una decisione quando qualcuno la mette in discussione, perché quel modello è stato scelto, chi ha valutato il rischio, cosa succede se il sistema smette di comportarsi come previsto. ## I documenti che la norma chiede davvero Tolto il rumore, il nucleo minimo si riduce a poche famiglie di documenti, collegate tra loro più che elencate una per una. - **Policy AI e obiettivi**, il punto di partenza che fissa cosa l'organizzazione intende per uso responsabile dell'AI e con quali obiettivi misurabili - **Ruoli e responsabilità**, chi possiede ogni sistema AI, chi ne risponde, chi approva le eccezioni - **Valutazione e trattamento del rischio**, la procedura con cui ogni sistema viene classificato prima di entrare in produzione - **Registro dei rischi AI**, vivo, non un documento chiuso alla firma del progetto - **Inventario dei sistemi AI**, l'elenco aggiornato di cosa l'organizzazione usa, sviluppa o acquista, con lo stato nel ciclo di vita - **Procedure operative**, come si monitora un sistema in produzione, come si gestisce un incidente, come si aggiorna un modello - **Piano di formazione**, terreno che merita un pezzo a sé, perché la competenza delle persone è essa stessa un requisito verificabile in audit - **Verbali di riesame di direzione**, la prova che il sistema viene rivisto periodicamente da chi ha potere di decidere, non solo mantenuto da chi lo ha scritto Otto famiglie di documenti, collegate tra loro, non ottanta file sparsi in una cartella condivisa. ## Il trattato che non serve Molte aziende partono convinte di dover scrivere un trattato, e si bloccano prima di iniziare. Serve un sistema proporzionato alla scala e al rischio reale dei sistemi AI in uso, non un manuale enciclopedico pensato per una multinazionale con cento use case in produzione quando gli use case reali sono tre. Chi ha già un sistema di gestione certificato, ISO 27001 sulla sicurezza delle informazioni o ISO 9001 sulla qualità, parte in vantaggio. La struttura armonizzata che ISO/IEC 42001 condivide con questi standard permette di riusare l'analisi del contesto, la gestione documentale, il riesame di direzione, senza duplicare da zero. Il registro dei rischi può diventare un'estensione di quello già esistente, non un sistema parallelo che nessuno guarda più dopo il primo mese. ## L'ordine conta più del contenuto L'errore più comune riguarda la sequenza più che la tecnica: si scrivono procedure prima di aver definito il contesto e gli obiettivi, oppure si costruisce l'inventario dei sistemi AI quando sono già in produzione da mesi, documentando a posteriori quello che si sarebbe dovuto decidere prima di cominciare. Un AIMS assemblato così somiglia a una giustificazione scritta dopo i fatti, e un audit lo smonta con poche domande mirate. L'ordine corretto parte dal contesto, chi sono le parti interessate e cosa si aspettano da come l'organizzazione usa l'AI, per poi passare alla policy, alla valutazione dei rischi, all'inventario e infine ai controlli operativi. Ogni passaggio si appoggia al precedente. Saltarne uno per arrivare prima al certificato produce un sistema fragile, che tiene sulla carta e cede alla prima verifica sul campo. ## Prima di cominciare Chi si trova a mettere ordine da questo punto di partenza fa bene a fermarsi prima di scrivere il primo documento, e a chiedersi cosa l'organizzazione sa già di sé: quanti sistemi AI ha davvero, con quale rischio, con quale maturità. È lo stesso terreno che copriamo con l'AI Assessment, mappare prima di formalizzare, perché un documento scritto senza quella mappa resta carta con una data sopra, non un sistema di gestione ai sensi della ISO/IEC 42001. La domanda su cui torneremo nel prossimo pezzo di questa serie riguarda l'inventario dei sistemi AI: come si costruisce, cosa deve contenere davvero, e perché quasi nessuna azienda ce l'ha aggiornato quando dice di averlo.