ISO 42001 spiegata: la prima norma certificabile per un sistema di gestione dell’IA

In sintesi

• ISO/IEC 42001:2023 è la prima norma internazionale certificabile dedicata a un Sistema di Gestione dell’Intelligenza Artificiale (AIMS), pubblicata congiuntamente da ISO e IEC nel dicembre 2023.
• A essere certificata è l’organizzazione, non il singolo sistema di IA. Il certificato attesta che l’azienda governa la propria IA attraverso un sistema gestito; non rilascia un nullaosta su uno specifico modello.
• La norma combina una colonna portante di gestione (clausole da 4 a 10) con un insieme di controlli specifici per l’IA in Allegato A, che spazia da politiche, ciclo di vita e dati a trasparenza e catena di fornitura.
• La certificazione segue un audit in due fasi e un ciclo triennale con audit di sorveglianza annuali. Una preparazione realistica richiede da 6 a 12 mesi per organizzazioni che partono da una base bassa o media.
• ISO 42001 è una impalcatura di governance, non una risposta completa al Regolamento IA. Da sola non fornisce valutazione di conformità, screening delle pratiche vietate, trasparenza verso l’utente finale né segnalazione degli incidenti gravi.

Che cosa è davvero ISO/IEC 42001

ISO/IEC 42001:2023 definisce i requisiti per « la costituzione, l’attuazione, il mantenimento e il miglioramento continuo di un sistema di gestione dell’IA all’interno delle organizzazioni ». L’enunciato ufficiale dell’oggetto è reperibile sulla scheda di catalogo ISO. Il testo è stato elaborato dal sottocomitato tecnico congiunto ISO/IEC SC 42, lo stesso organismo che produce le altre norme della famiglia IA su bias, robustezza, ciclo di vita e gestione del rischio. ISO 42001 è la prima della propria famiglia rispetto alla quale qualsiasi organizzazione può ottenere una certificazione da parte di un ente accreditato.

L’oggetto della certificazione è il Sistema di Gestione dell’IA (AIMS), non l’IA in sé. Un AIMS raccoglie politiche, ruoli, processi, controlli e registrazioni con cui un’organizzazione progetta, acquista, mette in opera e dismette i propri sistemi di IA. Il parallelo con ISO 9001 (qualità) e con ISO 27001 (sicurezza delle informazioni) è immediato: la norma certifica la disciplina dell’azienda, non il prodotto.

Il ciclo Plan-Do-Check-Act, presente in tutta la famiglia ISO a Struttura Armonizzata, viene riproposto e adattato alle specificità dell’IA. La fase « Do » comprende addestramento, distribuzione e monitoraggio del modello, con controlli di drift. La fase « Check » include obiettivi di equità, robustezza ed esplicabilità, non solo le tradizionali non conformità. La fase « Act » contempla gli innesti di riaddestramento e i percorsi di richiamo per i sistemi già in esercizio.

Due conseguenze pratiche discendono dal modo in cui la norma è scritta. Da una parte il certificato è rilasciato a un’organizzazione su un perimetro definito (unità di business, linea di prodotto, intera persona giuridica), per cui un « AIMS di uno » rimane un perimetro accettabile quando una piccola impresa opera un unico sistema di IA. Dall’altra la norma è volontaria: nessun regolatore la impone. Il suo peso deriva dagli appalti, dalla due diligence degli investitori e dal valore probatorio che porta con sé in regimi come il Regolamento IA.

A chi si rivolge la norma

ISO 42001 è neutra rispetto alla giurisdizione, ma parla naturalmente la lingua dei ruoli definiti agli articoli 3(3) e 3(4) del Regolamento IA. I fornitori progettano o fanno progettare un sistema di IA e lo immettono sul mercato con il proprio nome. I deployer utilizzano un sistema di IA sotto la propria autorità. Le clausole dell’AIMS si applicano in entrambi i casi, ma l’evidenza operativa differisce: i fornitori investono di più sulla tracciabilità dei dati di addestramento e sulla documentazione del modello; i deployer concentrano gli sforzi su dichiarazioni di uso previsto, istruzioni d’uso e formazione degli operatori.

Anche i fornitori di modelli IA per scopo generale (GPAI), compresi quelli che sviluppano grandi modelli di fondazione, possono certificarsi ISO 42001. La norma non dedica un allegato specifico al GPAI, ma le famiglie di controlli dell’Allegato A relative a dati, ciclo di vita, catena di fornitura e politiche si proiettano con pulizia sugli obblighi che i testi normativi pongono a valle in capo ai fornitori GPAI.

L’IA per uso interno segue le stesse regole dell’IA destinata al mercato. Una banca che utilizza un modello di scoring soltanto per la propria clientela rientra nel perimetro, perché l’AIMS copre qualsiasi sistema di IA che l’organizzazione progetta, opera o utilizza. Il certificato non dice nulla sulla commercializzazione; attesta la governance.

Corollario utile: l’« AIMS di uno », ossia una piccola organizzazione con un unico sistema di IA in produzione. Molti controlli di ISO 42001 scalano in modo naturale (una politica IA tenuta da una sola persona, una dichiarazione di applicabilità unica, una sola valutazione del rischio). I controlli dell’Allegato A restano gli stessi, ma l’evidenza d’audit si contrae di conseguenza. Gli auditor sono abituati a perimetri ridotti a un singolo sistema nominato e non penalizzano la sobrietà.

La struttura delle clausole: come la norma è costruita

Clausole da 4 a 10

Il corpo della norma segue la Struttura di Alto Livello (HLS) condivisa con ISO 9001, ISO 27001 e il resto della famiglia a Struttura Armonizzata. Le clausole da 1 a 3 fissano scopo, riferimenti normativi e termini; i requisiti operativi vivono nelle clausole da 4 a 10.

Clausola 4 (Contesto) chiede all’organizzazione di mappare il proprio contesto interno ed esterno per l’IA, identificare le parti interessate (regolatori, clienti, dipendenti, popolazioni coinvolte) e definire il perimetro dell’AIMS. Clausola 5 (Leadership) esige una responsabilità IA designata, una politica IA approvata al massimo livello e un impegno dimostrabile della direzione. Clausola 6 (Pianificazione) ospita la valutazione del rischio IA e la valutazione d’impatto IA, oltre alla Dichiarazione di Applicabilità che lega l’intero impianto ai controlli dell’Allegato A. Clausola 7 (Supporto) copre risorse, competenze, consapevolezza, comunicazione e informazioni documentate. Clausola 8 (Funzionamento) estende la pianificazione operativa all’intero ciclo di vita dell’IA (progettazione, dati, addestramento, valutazione, distribuzione, monitoraggio, ritiro). Clausola 9 (Valutazione delle prestazioni) impone monitoraggio, audit interno e riesame della direzione. Clausola 10 (Miglioramento) chiude il cerchio con non conformità, azioni correttive e miglioramento continuo.

Allegato A: i nove domini di controllo, in breve

L’Allegato A costituisce l’insieme di controlli specifici per l’IA. È modellato come l’Allegato A di ISO 27001 ma resta a un livello di astrazione superiore: obiettivi di controllo, non implementazioni prescritte. Nove domini, da A.2 ad A.10:

• A.2 Politiche per l’IA
• A.3 Organizzazione interna
• A.4 Risorse per i sistemi di IA
• A.5 Valutazione degli impatti dei sistemi di IA
• A.6 Ciclo di vita dei sistemi di IA
• A.7 Dati per i sistemi di IA
• A.8 Informazione delle parti interessate
• A.9 Utilizzo dei sistemi di IA
• A.10 Relazioni con terzi e clienti

Ciascun dominio porta un manipolo di obiettivi di controllo. La norma non indica come soddisfarli; l’organizzazione sceglie i propri controlli durante la pianificazione e ne motiva le scelte nella Dichiarazione di Applicabilità.

Allegati B, C e D

L’Allegato B è una guida implementativa informativa che associa ciascun obiettivo di controllo a pratiche suggerite. L’Allegato C enumera le fonti di rischio proprie dell’IA: bias dei dati di addestramento, bias di automazione, opacità, fragilità di robustezza, vulnerabilità di sicurezza, impronta ambientale. L’Allegato D percorre considerazioni settoriali (sanità, settore pubblico, occupazione, difesa). Questi tre allegati non sono requisiti, ma gli auditor li leggono; ogni scostamento dall’Allegato B andrebbe giustificato per iscritto.

L’Allegato A in termini operativi

La trappola più frequente con ISO 42001 consiste nel trattare l’Allegato A come una lista di politiche da spuntare. Gli auditor cercano artefatti che dimostrino come i controlli vivano nella quotidianità, non raccoglitori. Ecco ciascun dominio come un ritmo operativo, con un esempio concreto di artefatto che ottiene la spunta.

A.2 Politiche per l’IA

La politica IA e le relative sotto-politiche (uso accettabile, sviluppo dei modelli, IA di terze parti) sono riesaminate a cadenza definita. Artefatto operativo: il registro datato delle politiche con cronologia delle versioni e un verbale del consiglio che approva la versione vigente.

A.3 Organizzazione interna

Ruoli e responsabilità relativi all’IA sono documentati senza ambiguità. Artefatto operativo: una matrice RACI che nomina la responsabilità IA, i titolari di modello per sistema, il data steward e la funzione rischio di seconda linea, controfirmata dall’area Risorse Umane o dall’organizzazione.

A.4 Risorse per i sistemi di IA

L’organizzazione sa quali dati, quali strumenti, quale potenza di calcolo e quali profili professionali consumano i propri sistemi di IA. Artefatto operativo: una revisione di inventario mensile su feature store, registro dei prompt, registro dei modelli e spesa cloud, le cui varianze risalgono alla responsabilità IA.

A.5 Valutazione degli impatti dei sistemi di IA

Per ciascun sistema di IA una valutazione d’impatto coglie gli effetti su individui, gruppi e società. Artefatto operativo: una valutazione d’impatto IA per sistema, aggiornata a ogni cambiamento sostanziale o ogni dodici mesi, a seconda di quale evento si verifichi prima.

A.6 Ciclo di vita del sistema di IA

Il ciclo di vita, dall’ideazione al ritiro, è governato: revisione di progetto, revisione dei dati, revisione del modello, approvazione di distribuzione, monitoraggio, ritiro. Artefatto operativo: le registrazioni dei cancelli di ciclo di vita che mostrano chi ha approvato ciascuna transizione e su quale evidenza.

A.7 Dati per i sistemi di IA

I dati di addestramento e di inferenza sono documentati, idonei allo scopo e gestiti per la qualità. Artefatto operativo: una scheda dataset per ciascun insieme di addestramento, con provenienza, base giuridica, controlli di rappresentatività e lacune note.

A.8 Informazione delle parti interessate

Utenti, operatori e parti coinvolte ricevono informazioni adeguate sul sistema di IA. Artefatto operativo: la nota di trasparenza o la model card del sistema, oltre alle informative mostrate agli utenti in prodotto, con catture di schermo a supporto.

A.9 Utilizzo dei sistemi di IA

Uso previsto, limiti operativi e supervisione umana sono definiti e applicati. Artefatto operativo: un documento « uso previsto » per sistema, accompagnato da un briefing per gli operatori o da un attestato di formazione.

A.10 Relazioni con terzi e clienti

I fornitori (editori di modelli di fondazione, fornitori di dati, piattaforme MLOps) e i clienti (quando l’organizzazione assume il ruolo di fornitore) sono governati con contratto e tramite assurance. Artefatto operativo: un registro dei fornitori IA con il loro ruolo, le clausole contrattuali IA in vigore e l’ultima evidenza di assurance disponibile (rapporto di audit, attestazione, SBOM, model card).

Verifica rapida: in un martedì mattina, chiedetevi quale artefatto avete toccato oggi per quale controllo dell’Allegato A. Se la risposta è « nessuno da settimane », l’AIMS esiste solo sulla carta.

Valutazione del rischio, valutazione d’impatto e Dichiarazione di Applicabilità

Valutazione del rischio IA contro valutazione d’impatto IA

ISO 42001 separa due attività che il linguaggio comune tende a confondere. La valutazione del rischio IA (clausola 6.1.2) guarda all’organizzazione: cosa potrebbe andare storto con questo sistema di IA, per l’azienda, con quale probabilità e gravità? La valutazione d’impatto IA (clausola 6.1.4) guarda all’esterno: quali effetti produce questo sistema di IA sulle persone, sui gruppi o sulla società, diritti fondamentali compresi?

Comprimerle in un solo documento ne svuota il senso. La valutazione del rischio orienta la scelta dei controlli dell’Allegato A. La valutazione d’impatto orienta gli obblighi di trasparenza, i meccanismi di tutela e la decisione stessa di distribuire. Il blog AWS Security descrive l’approccio alla gestione del rischio lungo il ciclo di vita e mostra come entrambe alimentino la Dichiarazione di Applicabilità.

In che modo la Dichiarazione di Applicabilità differisce da quella di ISO 27001

Sotto ISO 27001 la Dichiarazione di Applicabilità (SoA) elenca ciascun controllo dell’Allegato A e ne dichiara l’applicabilità con motivazione. Sotto ISO 42001 la logica è identica, ma la SoA acquisisce un secondo asse: i casi d’uso di IA. Un controllo può essere applicabile in generale e tuttavia presentare implementazioni concrete diverse a seconda del caso d’uso (un assistente conversazionale, un modello di rilevamento delle frodi, un selezionatore di curricula). Le SoA più leggibili assumono la forma di una matrice: righe per i controlli, colonne per i casi d’uso, celle che rimandano all’implementazione concreta.

Quali prove gli auditor accettano

Gli auditor svalutano i PDF di politiche privi di traffico reale. Accettano le registrazioni che mostrano come la politica sia stata davvero usata: verbali di riesame, firme di approvazione, commenti sui ticket, registri di presenza dei corsi, catture di schermo delle informative in app, schede dataset, model card, cruscotti di drift, retrospettive d’incidente. Regola pratica: per ciascun controllo dell’Allegato A individuate un artefatto campionabile, una cadenza di aggiornamento e un proprietario nominato. Tre voci per controllo su nove domini: un backlog gestibile.

Il percorso di certificazione dal calcio d’avvio alla sorveglianza

Analisi degli scostamenti e perimetrazione dell’AIMS (mese 1 e 2)

Le prime sei o otto settimane fissano il perimetro di certificazione (quale persona giuridica, quale unità, quali sistemi di IA), conducono l’analisi degli scostamenti rispetto alle clausole 4-10 e all’Allegato A e producono il backlog iniziale di politiche, procedure e artefatti da costruire. La maggior parte delle organizzazioni utilizza questa fase anche per scegliere un ente di certificazione accreditato. I tempi di attesa per i primi audit nel 2025 oscillavano tra due e sei mesi; prenotare per tempo conviene.

Audit Stage 1

Lo Stage 1 è l’audit di documentazione e di prontezza. L’ente di certificazione passa in rassegna il perimetro dell’AIMS, la politica IA, le valutazioni di rischio e d’impatto, la SoA e i verbali di riesame della direzione. Secondo il percorso di certificazione illustrato da Cloud Security Alliance, lo Stage 1 si esaurisce in uno o due giorni per una piccola organizzazione. Ogni non conformità maggiore deve essere risolta prima dello Stage 2.

Audit Stage 2

Lo Stage 2 è l’audit di efficacia operativa. Gli auditor campionano le evidenze controllo per controllo dell’Allegato A, intervistano la responsabilità IA e i titolari di modello e verificano che l’AIMS funzioni come documentato. La durata scala con dimensione e complessità: di norma da una a tre settimane per un’organizzazione di taglia media con più sistemi di IA. L’esito, in caso di successo, è il certificato accompagnato da un elenco di non conformità minori e osservazioni.

Audit di sorveglianza e ricertificazione triennale

Il certificato è valido tre anni, con audit di sorveglianza annuali pari grossomodo a un terzo della durata dell’audit iniziale. Il quarto anno innesca un audit completo di ricertificazione. Le lezioni apprese sull’audit di Cloud Security Alliance rilevano che i riscontri più frequenti in sorveglianza riguardano valutazioni d’impatto obsolete e procedure di ritiro dei modelli non applicate.

Tempistiche realistiche

CSA e la maggior parte degli enti di certificazione convergono su 6-12 mesi di preparazione per un’organizzazione con base bassa o media, di più se il perimetro è ampio o se mancano altri sistemi di gestione (ISO 27001, ISO 9001). Le organizzazioni già certificate ISO 27001 dimezzano abitualmente lo sforzo di redazione delle politiche, dato che politiche, programma di audit interno e cadenza di riesame della direzione sono riutilizzabili.

ISO 42001 nella mappa regolamentare: cosa copre e cosa no

Dove ISO 42001 si sovrappone al Regolamento IA

La sovrapposizione tra le clausole di ISO 42001 e gli obblighi di fornitore e deployer del Regolamento IA è significativa, in particolare su gestione del rischio, governance dei dati, documentazione tecnica, sorveglianza post-mercato e supervisione umana. Cartografie indipendenti collocano la sovrapposizione attorno al 40-50% dei requisiti sostanziali del Regolamento. Le norme europee armonizzate in preparazione sotto il mandato M/593 (la famiglia prEN 18228 di CEN-CENELEC) costituiscono il ponte formale fra i requisiti essenziali del Regolamento e la presunzione di conformità; finché non saranno pubblicate, ISO 42001 resta l’impalcatura più matura.

I cinque scostamenti che contano

Un AIMS certificato, da solo, non fornisce:

1. La valutazione di conformità per i sistemi ad alto rischio prevista dall’articolo 43 (controllo interno o valutazione da parte di un organismo notificato a seconda del caso d’uso).
2. Lo screening delle pratiche vietate previsto dall’articolo 5 (social scoring, raccolta non mirata di immagini facciali, alcune forme di riconoscimento delle emozioni).
3. La trasparenza verso l’utente finale prevista dall’articolo 50 (informativa quando una persona interagisce con una IA o vede contenuti generati da IA).
4. La segnalazione degli incidenti gravi prevista dall’articolo 73 all’autorità di vigilanza del mercato competente, entro le scadenze stabilite.
5. La valutazione d’impatto sui diritti fondamentali prevista dall’articolo 27 per i deployer di sistemi ad alto rischio, quando si tratta di enti pubblici o di attori privati che erogano servizi di interesse generale.

Un’organizzazione può detenere un certificato ISO 42001 valido e nondimeno trovarsi in difetto rispetto al Regolamento su uno di questi assi. Il valore del certificato sta nel facilitare la dimostrazione del resto; non costituisce una difesa.

Mappatura con NIST AI RMF

Il NIST AI Risk Management Framework 1.0 e ISO 42001 sono progettati per interoperare. Le quattro funzioni cardine del NIST si proiettano in modo pulito: Govern si allinea alla clausola 5 e a parti della 6; Map si allinea alle clausole 4 e 6.1; Measure si allinea alle clausole 8 e 9; Manage si allinea alle clausole 8 e 10. Un’organizzazione che abbia lavorato seriamente con l’AI RMF recupera la maggior parte degli artefatti; ciò che di solito manca è l’enunciato formale del perimetro dell’AIMS, la SoA e la cadenza auditabile di riesame della direzione.

Perché il certificato non è una difesa

Le autorità di vigilanza del mercato istituite dal Regolamento IA non accettano « siamo certificati ISO 42001 » in sostituzione degli obblighi specifici del testo. Possono leggere il certificato come indizio di una postura di governance matura, ammorbidendo la sanzione in caso di non conformità minori, ma gli obblighi giuridici restano testabili uno per uno. Immagine da tenere a mente: ISO 42001 è un’impalcatura che semplifica tutto il resto; non una linea d’arrivo.

Domande frequenti

ISO 42001 è obbligatoria? No. ISO 42001 è una norma internazionale volontaria. Nessuna giurisdizione la rende obbligatoria allo stato attuale. La domanda nasce dagli acquisti (grandi clienti che la richiedono ai propri fornitori), dalla due diligence degli investitori e dal valore probatorio in regimi come il Regolamento IA. Alcuni settori (banche, sanità) potrebbero aggiungerla ai questionari fornitori nei prossimi 18 mesi, trasformandola di fatto in un requisito per i fornitori.

Quanto dura una certificazione ISO 42001? Una preparazione realistica si estende da 6 a 12 mesi per un’organizzazione che parte da una base bassa o media, meno se possedete già ISO 27001 e potete riutilizzare politiche, programma di audit interno e cadenza di riesame della direzione. L’audit vero e proprio si articola in Stage 1 (uno o due giorni) e Stage 2 (una-tre settimane a seconda della dimensione). Dal calcio d’avvio al certificato il percorso copre tipicamente da otto a quattordici mesi.

Le organizzazioni certificate ISO 27001 possono estendere il perimetro al SGIA? Sì, ed è il percorso d’ingresso più comune. Le due norme condividono la Struttura di Alto Livello; politiche, gestione documentale, audit interno e riesame della direzione si riutilizzano direttamente. Resta da aggiungere la valutazione del rischio e dell’impatto IA, l’insieme di controlli dell’Allegato A (in particolare A.5, A.6 e A.7) e i cancelli di ciclo di vita dei modelli. È normale ritrovare sistemi di gestione integrati che coprono ISO 27001 e ISO 42001 con un unico riesame della direzione.

ISO 42001 copre specificamente l’IA generativa? La norma è tecnologicamente neutra, ma l’Allegato C elenca esplicitamente rischi propri dell’IA generativa (allucinazione, vulnerabilità da prompt injection, provenienza dei dati di addestramento, questioni di proprietà intellettuale). L’Allegato D include casi d’uso generativi. Le organizzazioni che sviluppano o usano IA generativa devono attendersi un’attenzione particolare degli auditor su A.7 (dati) e A.8 (informazione delle parti interessate), dove gli obblighi di trasparenza dell’IA generativa pesano di più.

ISO 42001 basta per il Regolamento IA? No. ISO 42001 copre circa il 40-50% dei requisiti sostanziali del Regolamento e offre una solida impalcatura di governance, ma non fornisce valutazione di conformità, screening delle pratiche vietate, trasparenza per l’utente finale, segnalazione degli incidenti gravi né valutazione d’impatto sui diritti fondamentali. Le norme europee armonizzate in preparazione sotto il mandato M/593 saranno il ponte formale verso la conformità al Regolamento. Per ora trattate ISO 42001 come fondamento, il Regolamento come obbligo vincolante e le EN armonizzate come orizzonte di allineamento.

Chi può auditare e certificare un AIMS? Soltanto gli enti di certificazione accreditati ISO 42001 da un organismo di accreditamento nazionale riconosciuto (ACCREDIA in Italia, UKAS nel Regno Unito, ANAB negli Stati Uniti, COFRAC in Francia, DAkkS in Germania, ENAC in Spagna, IPAC in Portogallo). L’elenco degli enti accreditati è cresciuto rapidamente nel corso del 2025. Verificate che l’accreditamento dell’ente copra esplicitamente ISO/IEC 42001, e non soltanto ISO/IEC 27001; non tutti hanno ancora esteso il proprio ambito.

Conclusione

ISO 42001 è il primo mattone di infrastruttura di governance dell’IA su cui le organizzazioni possono davvero essere certificate, e si sta affermando rapidamente come la lingua comune dell’assurance sull’IA. Letta come impalcatura, ordina ogni altro obbligo IA: offre al Regolamento IA un punto d’attracco, assorbe senza tensioni il NIST AI RMF e impone all’azienda di chiamare per nome la propria IA. Letta come linea d’arrivo delude, perché il certificato non sostituisce mai il lavoro di conformità legale che resta da svolgere in parallelo.

Da AI Sigil trattiamo l’AIMS come un oggetto di esercizio: un sistema vivo che la piattaforma aiuta a far girare, non un raccoglitore che gli auditor visitano una volta l’anno. Per chi sta mappando la collocazione di ISO 42001 rispetto al Regolamento IA nello stack, l’articolo collegato ISO 42001 non copre l’AI Act: lo stack di norme che vi serve davvero percorre il ponte nel dettaglio. Per vedere come la piattaforma AI Sigil faccia operare l’AIMS nel quotidiano, il giro della piattaforma è il passo successivo.