ISO 42001, NIST AI RMF e AI Act: collegare i ruoli

La governance dell'IA può combinare un sistema di gestione, un framework di rischio e obblighi di legge. La sfida tecnica è collegarli senza fingere che siano intercambiabili. Una policy, un report di valutazione e una decisione di classificazione giuridica possono riguardare lo stesso servizio di IA, ma ciascuno risponde a una domanda diversa.

La ISO/IEC 42001 stabilisce come un'organizzazione gestisce l'IA. L'AI Risk Management Framework del NIST aiuta i team a indagare e gestire i rischi nel loro contesto. L'AI Act dell'UE, il regolamento europeo sull'intelligenza artificiale, stabilisce obblighi giuridici in funzione del sistema, della sua finalità prevista e del ruolo di operatore dell'organizzazione.

Per un CTO, il risultato utile è un'unica catena di governance revisionabile: un caso d'uso definito, responsabili individuati, misure di salvaguardia implementate, evidenze dei test, decisioni di rilascio e monitoraggio. Le mappature tra framework dovrebbero puntare a questa catena, preservando i requisiti che richiedono ancora un lavoro tecnico, giuridico o legato alla valutazione della conformità.

Capire che cosa stabilisce ciascuno strumento

ISO 42001: rendere ripetibile la governance

La ISO/IEC 42001 specifica i requisiti per stabilire, attuare, mantenere e migliorare continuamente un AIMS. I suoi requisiti di sistema di gestione riguardano contesto dell'organizzazione, leadership, pianificazione, supporto, attività operative, valutazione delle prestazioni e miglioramento.

Questa struttura conta quando più team sviluppano o acquistano IA. Offre una base per decidere chi autorizza il deployment, come si svolgono le valutazioni d'impatto e di rischio, come si gestiscono le dipendenze dai fornitori e come i guasti portano ad azioni correttive.

La norma include anche controlli di riferimento nell'Allegato A e una guida all'implementazione. La selezione dei controlli è basata sul rischio e richiede una giustificazione documentata; copiare l'allegato in una checklist non dimostra che il sistema di gestione funzioni.

Un organismo di certificazione indipendente può valutare l'AIMS nel suo perimetro. L'ISO stessa non certifica le organizzazioni. La certificazione fornisce garanzie su quel sistema di gestione entro il confine dichiarato, non un'affermazione illimitata che ogni modello o output sia sicuro.

NIST AI RMF: indagare il rischio effettivo

Il NIST AI RMF organizza il lavoro sul rischio attorno a Govern, Map, Measure e Manage. Govern è trasversale: le funzioni non sono semplicemente quattro fasi di progetto in sequenza.

Le sue caratteristiche di affidabilità comprendono validità e attendibilità, sicurezza, protezione e resilienza, responsabilità e trasparenza, spiegabilità e interpretabilità, tutela della privacy ed equità con gestione dei bias dannosi. Queste caratteristiche possono comportare compromessi. Spiegazioni più dettagliate, ad esempio, possono rivelare informazioni che richiedono protezione della privacy.

Le indicazioni del NIST aiutano i team a tradurre obiettivi generali in domande e valutazioni specifiche per il caso d'uso. Affrontano anche il tema della responsabilità: la governance non è prerogativa esclusiva della ISO 42001. Non esiste uno schema di certificazione NIST AI RMF paragonabile alla certificazione ISO dei sistemi di gestione. Una valutazione esterna può contribuire all'assurance, ma il suo perimetro e la sua metodologia vanno dichiarati.

L'AI Act: determinare gli obblighi, non solo i rischi

L'AI Act dell'UE disciplina determinate pratiche, i sistemi di IA e i modelli di IA per finalità generali attraverso disposizioni diverse. L'applicabilità giuridica non è determinata soltanto da un punteggio di rischio tecnico. Contano la finalità prevista, l'ambito territoriale, il ruolo di operatore e le specifiche regole di classificazione.

Gli obblighi di un fornitore differiscono da quelli di un deployer. Un modello non è la stessa cosa dell'applicazione che lo incorpora, e chiamare un software "agente" non ne stabilisce il ruolo giuridico né la classificazione.

Partire dal perimetro e dall'applicabilità giuridica

Mantenete un inventario dell'IA a livello di casi d'uso operativi, non solo di nomi dei fornitori. Uno stesso modello sottostante può supportare sia un assistente interno alla redazione sia uno strumento di selezione del personale. Questi deployment hanno persone interessate, conseguenze, controlli e potenziali obblighi diversi.

Per ogni caso d'uso, registrate:

• Finalità prevista, decisioni supportate, usi vietati e luoghi di deployment.
• Responsabile del sistema, responsabile tecnico, utenti e persone interessate.
• Fornitori del modello e dell'applicazione, modalità di hosting e dipendenze.
• Fonti dei dati, output, integrazioni e azioni consentite.
• Il ruolo di operatore dell'organizzazione e la motivazione che lo sostiene.
• Classificazione, obblighi applicabili, data di revisione e questioni aperte.

Un'organizzazione al di fuori dell'UE può comunque rientrare, in determinate circostanze, nell'ambito di applicazione del regolamento. Al contrario, avere clienti nell'UE non giustifica l'attribuzione di ogni possibile obbligo a ogni prodotto. Esaminate le effettive condizioni territoriali e di ruolo.

Distinguete pratiche vietate, requisiti per i sistemi ad alto rischio, specifici obblighi di trasparenza e obblighi per i modelli di IA per finalità generali. Non si tratta di livelli intercambiabili di un'unica scala di gravità tecnica. Un chatbot apparentemente a basso impatto può avere obblighi di trasparenza; un caso d'uso ad alto impatto richiede una valutazione giuridica più approfondita.

Usare il calendario di attuazione aggiornato

La panoramica dell'AI Act della Commissione europea, nella versione verificata al 7 ottobre 2026, indica il seguente calendario:

Valutate separatamente le disposizioni modificate, i regimi transitori e il sistema specifico. Non rinviate obblighi già applicabili solo perché esiste una data successiva per l'alto rischio. Mantenete datata la valutazione giuridica e usate la nostra guida alla preparazione all'AI Act per il contesto su calendario e valutazione dei ruoli.

Costruire un'unica catena di evidenze, non tre biblioteche di documenti

Una catena di governance pratica parte dal caso d'uso e termina con una decisione revisionata:

Finalità → impatti e rischi → requisiti → misure di salvaguardia → valutazioni → approvazione → monitoraggio.

Ogni collegamento richiede un livello di dettaglio sufficiente perché una persona esterna al team di implementazione possa esaminarlo. "Supervisione umana implementata" non basta se il revisore non può stabilire chi può intervenire, che cosa vede e se l'intervento funziona.

Utilizzate una registrazione dei requisiti che distingua il requisito di origine dalla sua implementazione. Uno schema minimo utile comprende fonte e versione, perimetro, testo o riferimento del requisito, interpretazione interna, responsabile del controllo, evidenze collegate, revisore, stato e lacuna residua.

Considerate questa tabella uno strumento di supporto all'implementazione, non una mappa di equivalenze autorevole. Le relazioni sono molti-a-molti: una valutazione può supportare diversi requisiti, mentre un requisito può richiedere più controlli e registrazioni.

Prima di riutilizzare un'evidenza, verificatene perimetro, data, versione del sistema e conclusione. Un test su una configurazione del modello non può supportare automaticamente un'altra configurazione. Una policy aziendale dimostra che esiste una regola documentata; per dimostrarne l'applicazione servono registrazioni operative.

Usare le funzioni del NIST per definire il lavoro tecnico

Le funzioni del NIST offrono un modo utile per organizzare le domande di implementazione all'interno dell'AIMS. Dovrebbero produrre artefatti concreti, non soltanto campi di questionario compilati.

Govern: stabilire l'autorità decisionale

Definite chi è responsabile del sistema, chi revisiona in modo indipendente i rischi significativi e chi può approvare eccezioni o bloccare il deployment. Specificate i requisiti di competenza e i percorsi di escalation. Collegate queste responsabilità ai processi esistenti di sicurezza, privacy, acquisti e gestione degli incidenti.

Un deliverable utile è una procedura di rilascio che indichi i revisori e le evidenze richiesti. L'accettazione del rischio dovrebbe indicare chi decide, la motivazione, le condizioni e l'evento che fa scattare la revisione, anziché limitarsi a registrare "accettato".

Map: descrivere contesto e conseguenze

Documentate il workflow prima di scegliere le metriche. Individuate dove l'IA influenza le decisioni, chi ne subisce le conseguenze e che cosa accade quando gli output sono sbagliati, non disponibili o usati in modo improprio.

Includete gli usi impropri prevedibili e i guasti delle dipendenze. Per un agente in grado di eseguire azioni, mappate strumenti, credenziali, dati accessibili, limiti di approvazione e percorsi di ripristino. Per l'IA di terze parti, registrate che cosa controlla il fornitore e che cosa resta sotto la vostra responsabilità.

Measure: testare le affermazioni che contano

Scegliete valutazioni legate ai rischi individuati. A seconda del caso d'uso, possono includere accuratezza del compito, prestazioni per sottogruppi, robustezza, fuga di dati personali, prompt injection, azioni non autorizzate e comprensione da parte degli operatori.

Documentate provenienza e rappresentatività dei dataset, condizioni di test, metriche, limitazioni e soglie di accettazione. Misurate, ove possibile, l'applicazione completa: recupero delle informazioni, prompt, autorizzazioni, interfacce e workflow umano possono cambiare i risultati anche quando il modello sottostante resta invariato.

Manage: attuare il trattamento e il follow-up

Traducete i risultati in misure di salvaguardia, restrizioni, remediation o nella decisione di non procedere al deployment. Tra gli esempi: ridurre le autorizzazioni degli strumenti, richiedere un'approvazione per le azioni con conseguenze, escludere gli usi non supportati o prevedere un'alternativa affidabile senza IA.

Fissate soglie di monitoraggio e procedure di risposta. Una metrica senza responsabile né regola di risposta è solo telemetria. Registrate quali eventi fanno scattare una nuova valutazione, compresi aggiornamenti del fornitore, fonti di dati modificate, ampliamenti degli usi e incidenti.

Rendere verificabile la ISO 42001 tramite registrazioni operative

Se la certificazione è un obiettivo, definite il confine dell'AIMS prima di prepararvi a un audit esterno. Il perimetro può riguardare un prodotto specifico, una business unit o un insieme di attività del ciclo di vita, ma deve descrivere chiaramente le attività e le interfacce incluse. Un perimetro ristretto non deve essere presentato come una garanzia valida per l'intera organizzazione.

Svolgete una gap assessment rispetto ai requisiti del sistema di gestione e ai controlli applicabili. Definite policy, obiettivi, metodi di valutazione dei rischi e degli impatti, applicabilità documentata dei controlli, responsabilità e procedure operative. Poi generate evidenze che questi processi funzionano davvero.

Tra le registrazioni utili rientrano valutazioni completate, revisioni dei fornitori, registrazioni della formazione, approvazioni di rilascio, revisioni del monitoraggio, azioni correttive, rilievi dell'audit interno e decisioni del riesame della direzione. Audit interno e riesame della direzione sono attività distinte: il primo valuta conformità ed efficacia, il secondo supporta la valutazione e l'indirizzo del sistema di gestione da parte della leadership.

Un processo di certificazione indipendente comprende di solito fasi di valutazione della prontezza e dell'implementazione. Concordate il perimetro e le modalità di audit con l'organismo di certificazione anziché trattare la certificazione come la consegna di un fascicolo. Continuate monitoraggio, revisione interna e miglioramento anche dopo la certificazione.

Né un certificato né una valutazione secondo l'RMF sostituiscono una valutazione della conformità ai sensi dell'AI Act, ove applicabile. Il percorso di valutazione della conformità dipende dal sistema e dalle disposizioni pertinenti; non tutti i sistemi ad alto rischio richiedono lo stesso percorso con terza parte. Anche i requisiti di dichiarazione, registrazione, marcatura e notifica vanno verificati per il ruolo e il sistema pertinenti.

Esempio pratico: un deployment di IA legato alle assunzioni

Ipotesi illustrative: un datore di lavoro dell'UE acquista un'applicazione che classifica i candidati per la revisione in vista dei colloqui. Il vendor fornisce l'applicazione, mentre il datore di lavoro configura i criteri per le posizioni e utilizza le classifiche. Le decisioni finali di assunzione spettano ai recruiter. Supponiamo che la revisione giuridica individui un uso ad alto rischio in ambito occupazionale ai sensi dell'Allegato III e qualifichi inizialmente il datore di lavoro come deployer.

La questione non si risolve dicendo che "la decisione finale la prende una persona". La classifica può influenzare in modo sostanziale chi viene preso in considerazione. La valutazione deve esaminare il workflow reale, compreso se i recruiter ignorano abitualmente i candidati al di sotto di una soglia.

Stabilire la registrazione specifica del sistema

Il responsabile tecnico registra i campi di input, le informazioni sulla logica di classificazione disponibili dal fornitore, la versione dell'applicazione, la configurazione, gli utenti e le destinazioni delle esportazioni. L'ufficio acquisti richiede al fornitore istruzioni, limitazioni, evidenze di valutazione pertinenti, notifiche delle modifiche e supporto per gli obblighi dell'organizzazione.

La revisione giuridica documenta le ipotesi su classificazione e ruolo, compresa la possibilità che future modifiche o un rebranding possano cambiare il ruolo. La revisione privacy valuta separatamente il trattamento dei dati dei candidati. La governance dell'IA non sostituisce l'analisi in materia di protezione dei dati.

Testare e implementare le misure di salvaguardia

Utilizzando le funzioni Map e Measure del NIST, il team valuta scenari di selezione rappresentativi, il comportamento in caso di dati mancanti e le differenze di prestazione tra i gruppi pertinenti, ove lecito e fattibile. Documenta l'incertezza e i limiti del campione anziché presentare una metrica di equità come prova che ogni bias dannoso sia scomparso.

La supervisione umana comprende la formazione dei recruiter, limitazioni ben visibili, un percorso per riesaminare le candidature escluse e la possibilità di sospendere la classificazione. Il team verifica se i revisori comprendono gli output e possono ignorarli senza ostacoli operativi.

I controlli di sicurezza limitano l'accesso ai dati dei candidati e impediscono esportazioni non approvate. Il change control richiede una nuova valutazione quando cambiano i criteri di classificazione, i modelli o le modalità di trattamento del fornitore.

Mantenere separate le tre conclusioni

La registrazione dell'AIMS dimostra come hanno funzionato valutazioni, responsabilità, revisione del fornitore e processi di approvazione. La registrazione secondo l'RMF spiega i rischi nel contesto, i test, il trattamento e l'incertezza residua. La registrazione giuridica individua gli obblighi applicabili al deployer, le tempistiche e il lavoro ancora da svolgere.

Supponiamo che il fornitore non abbia fornito istruzioni sufficienti per una supervisione affidabile. La registrazione del rilascio dovrebbe mostrare quella lacuna, il suo responsabile e la decisione di rinviare o limitare il deployment, non uno stato verde ereditato dal certificato ISO del datore di lavoro.

Scegliere le priorità e mantenere le evidenze dopo il rilascio

Date la precedenza agli obblighi giuridici applicabili e ai rischi operativi inaccettabili. La certificazione ISO può procedere in parallelo alla remediation, ma un obiettivo di audit non dovrebbe scalzare i controlli urgenti.

Se i team non hanno responsabilità e processi di revisione coerenti, costruite le fondamenta dell'AIMS. Se la governance esiste ma le valutazioni dei sistemi sono deboli, usate l'RMF per migliorare l'analisi del contesto e i test. Se un cliente richiede la certificazione, confermate il perimetro atteso prima di definire il budget.

Evitate ipotesi universali su costi o durata. L'impegno dipende dal numero di sistemi, dalla governance esistente, dalle esigenze di valutazione, dalla visibilità sui fornitori e dalla remediation. L'RMF è disponibile gratuitamente, ma la sua implementazione richiede comunque tempo del personale; la certificazione ISO aggiunge considerazioni sull'accesso alla norma e sulla valutazione esterna.

Dopo il rilascio, associate agli artefatti gli eventi che ne fanno scattare la revisione. Un aggiornamento del modello del fornitore può invalidare i risultati della valutazione; una nuova autorizzazione ad agire può cambiare il modello delle minacce; un nuovo mercato può richiedere una nuova valutazione giuridica. Conservate le versioni e le decisioni precedenti, così che i revisori possano ricostruire che cosa era stato approvato in quel momento.

Tra gli errori più comuni: trattare le mappature come conformità, raccogliere policy senza evidenze operative, accettare le dichiarazioni dei fornitori senza un'analisi specifica del deployment e registrare il rischio residuo senza un responsabile della decisione. Un altro è misurare la qualità del modello ignorando le autorizzazioni dell'applicazione e il comportamento umano.

Secani può supportare il workflow delle evidenze collegando requisiti, controlli, materiale di origine, responsabili, attività e decisioni revisionate. Iniziate con un perimetro definito, collegate ogni evidenza a ciò che supporta e trasformate il materiale mancante o obsoleto in lavoro assegnato. Trattate i suggerimenti assistiti dall'IA come bozze: una persona dovrebbe revisionare mappature e conclusioni, conservando fonti e motivazioni dell'approvazione. In questo modo la base della governance resta verificabile senza sostituire il giudizio tecnico o giuridico.

Domande che incidono sull'implementazione

I controlli di sicurezza esistenti possono essere riutilizzati?

Sì, quando la loro implementazione e le relative evidenze coprono il deployment di IA. Controllo degli accessi, risposta agli incidenti e gestione dei fornitori contribuiscono spesso. Da soli, però, non rispondono alle domande su bias dannosi, finalità prevista o efficacia della supervisione umana.

E se un fornitore non rivela il funzionamento interno del modello?

Registrate il limite di visibilità. Cercate evidenze proporzionate al caso d'uso, valutate l'applicazione distribuita e stabilite se siano necessarie garanzie contrattuali, restrizioni o fornitori alternativi. La mancanza di visibilità non è automaticamente accettabile solo perché il servizio è disponibile sul mercato.

Che cosa dovrebbe fare per prima cosa il team?

Scegliete un caso d'uso con conseguenze rilevanti e riunitene responsabile, finalità, valutazione del ruolo, registrazione del rischio, misure di salvaguardia, test e approvazione. Esaminate le lacune rispetto a tutti e tre gli strumenti. Questo esercizio circoscritto rivela se l'organizzazione ha bisogno di una governance migliore, di evidenze tecniche migliori o di risolvere questioni giuridiche aperte prima di espandersi.