In sintesi
- La gestione del rischio di conformità è la pratica di condurre la gestione del rischio aziendale in modo accettato da ogni autorità che vigila sull’impresa, trasformando poi i risultati in evidenza per l’audit.
- Nel 2026 la disciplina è rimodellata da tre spostamenti: l’IA come nuovo vettore di rischio di conformità, l’IA come strumento operativo e un’ondata regolatoria che colloca la gestione del rischio al centro di ogni obbligo sui sistemi di IA ad alto rischio.
- Lo stack coerente del 2026 unisce ISO 31000 come tronco della gestione del rischio aziendale, ISO/IEC 42001 come ramo del sistema di gestione dell’IA, il NIST AI RMF come funzioni operative e l’articolo 9 del regolamento IA come obbligo giuridico vincolante.
- I ruoli di fornitore e deployer ai sensi del regolamento IA distribuiscono la titolarità del rischio di conformità: l’IA sviluppata internamente concentra tutto sull’organizzazione, l’IA di terzi sposta una parte sul rischio fornitore.
- Gli strumenti di nuova generazione passano dal GRC su foglio elettronico o workflow alla sorveglianza continua potenziata dall’IA, che trasforma il dato di rischio in segnale in tempo reale.
Che cosa è la gestione del rischio di conformità?
La gestione del rischio di conformità è la disciplina operativa che garantisce che ogni attività di trattamento del rischio dentro l’organizzazione rispetti le norme, gli standard e gli obblighi contrattuali applicabili. Vive al punto di incontro di due pratiche GRC che i motori di ricerca spesso confondono. La gestione del rischio in senso stretto consiste nell’identificare, valutare e trattare il rischio rispetto all’appetito definito. La gestione della conformità consiste nel soddisfare obblighi esterni. La gestione del rischio di conformità è il punto di sutura: condurre la gestione del rischio stessa in modo che un’autorità di vigilanza la riconosca, producendo la documentazione che lo dimostra. Il National Institute of Standards and Technology definisce la funzione Govern del proprio AI Risk Management Framework come la coltivazione di una cultura di gestione del rischio in ogni organizzazione che progetta, sviluppa, distribuisce o utilizza sistemi di IA. La formulazione è densa di conseguenze: la governance non è più un cantiere parallelo alle operazioni, ma la precondizione perché ogni altra attività di rischio conti come evidenza di conformità. Nel 2026 tre forze tirano la disciplina verso il piano di controllo dell’IA. Primo, ogni testo che atterra quest’anno sulla scrivania di un Chief Risk Officer, dal regolamento IA a DORA a NIS2, incorpora una clausola esplicita di gestione del rischio che richiede un trattamento continuo, documentato e per l’intero ciclo di vita. Secondo, il perimetro audit si è ampliato: dove due anni fa il registro dei rischi conteneva cyber, frode ed ESG, oggi deve contenere anche il rischio di modello, il rischio IA di terzi e la responsabilità sulle decisioni automatizzate. Terzo, gli strumenti cambiano: le piattaforme GRC potenziate dall’IA comprimono lo scarto tra dato di rischio e decisione di rischio, passando dal trimestre al tempo reale. La conseguenza pratica per i team che portano questo titolo è netta. La gestione del rischio di conformità non è più un’attestazione trimestrale costruita su campionamenti. È un regime di controllo continuo che deve reggere a una ispezione di martedì mattina.
Gestione del rischio di conformità e gestione della conformità del rischio: perché contano entrambe
I motori di ricerca trattano le due formulazioni come sinonimi. Non lo sono. Una disciplina che le confonde finisce per sovracontrollare un lato esponendo l’altro. La gestione del rischio di conformità chiede: le mie attività di gestione del rischio sono conformi alle norme che le inquadrano? L’esempio classico è una banca che fa girare un programma interno di validazione dei modelli. La validazione è gestione del rischio; sapere se il programma soddisfa le aspettative del supervisore secondo SR 11-7 o TRIM della BCE è gestione del rischio di conformità. La gestione del rischio di non conformità pone la domanda inversa: qual è il rischio che la mia organizzazione manchi agli obblighi che le si applicano, e come lo guido? L’oggetto di analisi è la postura di conformità dell’organizzazione. La voce sul registro dei rischi recita pressappoco: « mancato deposito dei report di post-market monitoring per sistemi di IA ad alto rischio entro i termini di legge, probabilità residua media, impatto potenziale 35 milioni di euro di sanzioni più danno reputazionale ». Il regolamento IA mette in scena entrambe le dimensioni allo stesso tempo. L’articolo 9 impone ai fornitori di sistemi di IA ad alto rischio di gestire un sistema di gestione dei rischi, che è a tutti gli effetti un’attività di gestione del rischio (dunque da condurre in modo conforme: gestione del rischio di conformità). Nello stesso istante l’articolo crea un nuovo obbligo di conformità; non rispettarlo è a sua volta un rischio di conformità che la seconda linea deve registrare e trattare (gestione del rischio di non conformità). Un modello operativo ben costruito tratta i due movimenti come distinti ma intrecciati, con tassonomia, registro e libreria di controlli condivisi. La ragione meccanica per cui entrambe contano: un’autorità che trova un lato rotto tratterà l’altro come compromesso per inferenza.
Lo stack 2026: ISO 31000, ISO 42001, NIST AI RMF e articolo 9 del regolamento IA
L’istinto sotto pressione regolatoria è aprire un programma per ogni acronimo nuovo. Quell’istinto produce silos: una squadra ISO 31000 per la gestione del rischio aziendale, una squadra ISO 42001 per l’IA, un gruppo NIST RMF e una task force regolamento IA che tengono quattro registri paralleli. La cura è un’architettura unica a stella, dove ciascun framework occupa una posizione definita. ISO 31000 è il tronco. Il framework internazionale di gestione del rischio aziendale, pubblicato per la prima volta nel 2009, fissa principi, framework e processo di gestione del rischio a livello di impresa. Non è specifico dell’IA. Fornisce il vocabolario (rischio, controllo, rischio residuo, appetito) e il ciclo di vita (stabilire il contesto, identificare, analizzare, valutare, trattare, monitorare, comunicare) che ogni programma a valle eredita. ISO/IEC 42001 è il ramo IA. Pubblicata a dicembre 2023, è la prima norma auditabile al mondo per un sistema di gestione dell’IA. Si innesta sul tronco ISO 31000 attraverso la struttura comune dei sistemi di gestione (l’High-Level Structure dell’Annex SL) e aggiunge controlli specifici per l’IA: qualità del dato, trasparenza, supervisione umana, gestione del ciclo di vita. Un’organizzazione già certificata ISO 27001 o ISO 9001 riconoscerà la forma e potrà estendere la governance all’IA senza ricostruire il sistema di gestione. Il NIST AI RMF è il protocollo operativo. Le sue quattro funzioni di base (Govern, Map, Measure, Manage) descrivono ciò che le squadre fanno tutti i giorni. Govern fissa le precondizioni culturali e di policy. Map raccoglie i casi d’uso di IA e il loro contesto. Measure quantifica il rischio rispetto alle caratteristiche di IA affidabile (valida, affidabile, sicura, protetta, responsabile, trasparente, spiegabile, rispettosa della privacy, equa). Manage alloca le risorse di trattamento. L’RMF si mappa con pulizia sui controlli ISO/IEC 42001, ragione per cui i due vengono evocati insieme sempre più spesso. L’articolo 9 del regolamento IA è l’obbligo vincolante. L’articolo 9, paragrafo 1 recita testualmente: « È istituito, attuato, documentato e mantenuto un sistema di gestione dei rischi in relazione ai sistemi di IA ad alto rischio ». L’articolo 9, paragrafo 2 definisce il processo iterativo continuo lungo il ciclo di vita del sistema di IA: identificare e analizzare i rischi noti e ragionevolmente prevedibili, stimarli sotto uso previsto e uso improprio ragionevolmente prevedibile, valutarli con i dati del post-market monitoring, adottare misure mirate. L’articolo 9, paragrafo 10 invita esplicitamente all’integrazione: i fornitori già soggetti ad altri requisiti di gestione del rischio dell’Unione possono fondere queste disposizioni con le procedure esistenti. Quella clausola è il via libera giuridico a tenere uno stack invece di quattro. A quel punto la mappatura diventa lineare. Un’attività ISO 31000 di identificazione del rischio, eseguita su un caso d’uso di IA catturato dalla funzione Map del NIST AI RMF, documentata secondo il controllo A.5.4 dell’Annex A di ISO/IEC 42001, soddisfa l’articolo 9, paragrafo 2, lettera a. Un’attività, un record, quattro caselle spuntate.
Processo in quattro tappe per la gestione del rischio di conformità nell’era IA
Il ciclo dell’articolo 9 dà la spina dorsale: identificare, stimare, valutare, gestire. Ogni tappa deve mantenere la sua sostanza tradizionale e aggiungere la dimensione che rende l’evidenza difendibile nel 2026. Tappa 1: identificare. La mossa tradizionale raccoglie input da titolari di processo, esiti di audit, scansioni di orizzonte normativo e log di incidente, riversandoli in un registro dei rischi. L’aggiunta IA enumera ogni caso d’uso di IA in produzione o in sviluppo, assegnando a ciascun caso una classificazione di rischio (proibito, alto rischio, rischio limitato, rischio minimo) ai sensi degli articoli 5 e 6 del regolamento IA. L’esito è un registro unificato dove i rischi IA convivono con le voci cyber, frode ed ESG, anziché in un foglio parallelo. Tappa 2: stimare. La stima tradizionale svolge un’analisi di probabilità e impatto, spesso su una scala 1-5, calibrata sui dati storici di perdita. L’aggiunta IA è doppia: stimare sia sotto uso previsto sia sotto uso improprio ragionevolmente prevedibile (formulazione presa testualmente dall’articolo 9, paragrafo 2, lettera b), e arricchire l’asse dell’impatto con le dimensioni di affidabilità (bias, allucinazione, drift, sicurezza, spiegabilità). Un sistema di IA di supporto decisionale clinico non può essere stimato sulla sola esposizione alle sanzioni; il vettore danno paziente deve entrare nel conto. Tappa 3: valutare. La valutazione tradizionale confronta il rischio stimato con l’appetito dell’organizzazione e classifica i trattamenti. L’aggiunta IA è l’inclusione esplicita dei dati di post-market monitoring, imposta dall’articolo 9, paragrafo 2, lettera c. Una volta in produzione, un sistema di IA non può essere valutato solo con la stima di progettazione. Drift reale, frequenza di incidenti, metriche di equità dal traffico live e reclami utente rientrano nel loop di valutazione. La funzione Measure del NIST AI RMF mette a disposizione una batteria di metriche operative pronte a essere portate dentro questa tappa. Tappa 4: gestire. Il trattamento tradizionale sceglie tra accettare, evitare, trasferire, mitigare. L’aggiunta IA è l’eliminazione per disegno: secondo l’articolo 9, paragrafo 3, i rischi devono essere trattati attraverso lo sviluppo o il design del sistema di IA stesso, non solo con controlli a valle. Dove un rischio fornitore sarebbe stato storicamente mitigato da una clausola di manleva, un rischio di sistema di IA va prima esaminato per eliminarlo a livello di dati di addestramento, architettura del modello o disegno del deployment. Solo il residuo viene trasferito o accettato. Un registro che cammina lungo queste quattro tappe per ogni caso d’uso di IA, con tracciabilità verso i record di misurazione NIST AI RMF e le attestazioni di controllo ISO/IEC 42001, serve simultaneamente la gestione del rischio aziendale e l’obbligo dell’articolo 9. Due movimenti, un unico flusso.
Fornitore o deployer: chi possiede quale rischio di conformità?
Il regolamento IA introduce una distinzione che i team di compliance addestrati all’analisi titolare-contro-responsabile del trattamento ereditata dal GDPR riconosceranno, ma non devono assumere identica. Un fornitore è l’entità che sviluppa un sistema di IA o lo fa sviluppare e lo immette sul mercato con il proprio nome. Un deployer è qualunque persona fisica o giuridica che utilizza un sistema di IA sotto la propria autorità. La stessa organizzazione può essere fornitore sul sistema A e deployer sul sistema B nella stessa settimana. Gli obblighi del fornitore sono densi. Gli articoli da 16 a 25 del regolamento IA assegnano al fornitore documentazione tecnica, sistema di gestione della qualità, gestione dei rischi (articolo 9), data governance, trasparenza, supervisione umana, post-market monitoring, registrazione e segnalazione degli incidenti gravi. Il registro dei rischi di conformità lato fornitore deve contenere una riga per ciascuno di questi obblighi, con titolare del controllo, riferimento di evidenza e punteggio di rischio residuo. Gli obblighi del deployer stanno nell’articolo 26. Comprendono l’uso dei sistemi ad alto rischio secondo le istruzioni del fornitore, l’assegnazione della supervisione umana a personale competente, il monitoraggio del funzionamento e l’informazione del fornitore in caso di rischi o incidenti gravi, il mantenimento della qualità dei dati di input e la conservazione dei log generati automaticamente. Il rischio di conformità lato deployer è strutturalmente diverso: meno design, più disciplina operativa e gestione fornitori. L’implicazione per la gestione del rischio di conformità è che il registro stesso deve portare un attributo di ruolo su ogni riga IA. Una banca che gestisce un sistema di IA antifrode sviluppato in casa porta gli obblighi del fornitore e deve registrare l’intero sistema di gestione dei rischi dell’articolo 9 come attività propria. La stessa banca che utilizza un modello generativo di terzi per il triage del servizio clienti porta gli obblighi del deployer e deve registrare al loro posto controlli di sorveglianza fornitore, aderenza alle istruzioni e segnalazione incidenti. La libreria di controlli che sostiene entrambi i lati è in parte condivisa (data governance, supervisione umana) e in parte divergente (post-market monitoring appartiene al fornitore, due diligence fornitore al deployer). Un programma che non traccia questa linea finisce per sovracontrollare il lato deployer o sotto-controllare il lato fornitore. Il controllo pratico è eseguire una breve classificazione interna a ogni ingresso di un nuovo sistema di IA nell’inventario: chi lo ha sviluppato, sotto il cui nome viene messo sul mercato, chi controlla il contesto di esercizio? La risposta determina quali controlli dell’articolo 26 o degli articoli 16-25 si attaccano.
Oltre il regolamento IA: convergenza con DORA, NIS2 e CSRD
Il regolamento IA non arriva nel vuoto. Tre altre norme hanno introdotto nei due anni scorsi le proprie esigenze di gestione del rischio, e un programma che le tratta come quattro movimenti separati passa il proprio tempo a copiare voci tra fogli invece di trattare il rischio. Il Digital Operational Resilience Act (DORA), in vigore dal gennaio 2025 per le entità finanziarie, richiede un framework completo di gestione del rischio ICT che copra identificazione, protezione, rilevamento, risposta, ripristino e apprendimento. Il suo perimetro si sovrappone all’articolo 9 del regolamento IA ovunque un sistema di IA sia anche un asset ICT: un modello antifrode è entrambe le cose. La direttiva Sicurezza delle reti e dei sistemi informativi 2 (NIS2) impone misure di gestione del rischio alle entità essenziali e importanti dei settori critici, con accento sulla cybersicurezza. I sistemi di IA che sostengono servizi sotto NIS2 ereditano quelle misure. La direttiva sulla rendicontazione di sostenibilità (CSRD) richiede alle imprese di rendicontare rischi e opportunità materiali in materia di sostenibilità, inclusa la governance degli impatti derivanti dalle scelte tecnologiche. Le decisioni guidate dall’IA che impattano lavoratori, consumatori e partner della catena del valore rientrano nel perimetro. Lo schema di convergenza è lo stesso nei quattro casi: identificare, valutare, trattare, monitorare, rendicontare. Una libreria di controlli unificata, in cui ogni controllo punta a tutte le norme che soddisfa, trasforma quattro programmi in un registro con quattro viste di uscita. Il Committee of Sponsoring Organizations of the Treadway Commission (COSO) ha aggiornato la propria guida nel 2024 per coprire insieme governance dell’IA, rischio cloud, cyber e gestione del rischio di conformità, segnalando la stessa direzione a livello di standard. Il costo della non convergenza è meccanico: un caso d’uso di IA che attiva articolo 9, rischio ICT DORA e obbligo cyber NIS2 produrrà tre voci di registro, tre dossier di evidenza, tre piste di audit. Un programma convergente produce una voce con tre etichette.
Tassonomia del rischio di conformità nel 2026
Le cinque famiglie classiche del rischio di conformità restano. La tassonomia ha bisogno di tre aggiunte per rimanere credibile nel 2026. Rischio regolatorio: rischio di sanzione, restrizione o ingiunzione di un’autorità statutaria. Esempio: una sanzione del regolamento IA fino al 7 per cento del fatturato annuo globale per immissione sul mercato di un sistema di IA proibito. Rischio operativo: rischio di interruzione delle operazioni a seguito di non conformità o della sua rimedio. Esempio: il ritiro forzato di un modello di sottoscrizione che fallisce un test di equità, con ritardi a catena lato pricing. Rischio reputazionale: rischio di danno al marchio. Esempio: un’inchiesta mediatica su discriminazione algoritmica che innesca un abbandono clienti ben superiore alla multa. Rischio finanziario: esposizione monetaria diretta oltre le sanzioni: costi di rimedio, indennizzo clienti, spese legali, impatto sul prezzo del titolo. Rischio penale: rischio di azione penale individuale contro amministratori e dirigenti. Esempio: violazione consapevole del GDPR o, in alcune giurisdizioni, colpa grave su obblighi di sicurezza IA. Tre aggiunte IA si stratificano sopra le cinque classiche. Rischio di modello: rischio che un modello di IA produca output errati, distorti o instabili in produzione. Include bias, allucinazione, drift distribuzionale e vulnerabilità avversaria. Esempio: un modello di credit scoring il cui rapporto di disparate impact supera la soglia di fair lending tre mesi dopo il deployment. Rischio IA di terzi: rischio ereditato da fornitori di modelli a monte, API di foundation model e strumenti di vendor potenziati dall’IA. Esempio: un chatbot di assistenza clienti costruito su un foundation model il cui fornitore modifica silenziosamente il system prompt, alterando il comportamento di output senza preavviso. Responsabilità da decisioni automatizzate: rischio derivante da decisioni basate unicamente su trattamento automatizzato, in particolare quando producono effetti giuridici o similmente rilevanti. Combina l’articolo 22 del GDPR e il diritto all’spiegazione dell’articolo 86 del regolamento IA. Esempio: un rifiuto di prestito automatizzato di cui il cliente chiede spiegazioni a entrambi i testi nello stesso istante. Una tassonomia che porta queste otto categorie, con esempi e proprietà chiara su prima, seconda e terza linea, rende il registro difendibile rispetto a un’ispezione che può arrivare senza preavviso.
Strumenti: dal GRC su foglio elettronico alla sorveglianza continua potenziata dall’IA
Lo strato strumenti della gestione del rischio di conformità ha attraversato tre generazioni. La prima è il registro su foglio elettronico: una cartella di lavoro, più schede, colonna titolare, colonna stato, ciclo di aggiornamento misurato in trimestri. Scala a poche decine di rischi prima di crollare sotto il peso dei propri metadati. La seconda è il GRC su workflow: un sistema appoggiato a una base dati, con librerie di controlli, deposito evidenze, instradamento delle attestazioni e cruscotti di reporting. Scala a migliaia di controlli e rende sopportabile il recupero di evidenze in audit, ma resta un sistema dello scritto: qualcuno deve aggiornare ciascuna riga e la freschezza di un campo dipende da qualcuno che si ricordi di rinfrescarlo. La terza, che prende forma nel 2026, è lo strato di sorveglianza continua potenziato dall’IA. Legge direttamente la telemetria operativa (log di performance dei modelli, rilevatori di drift, ticket di incidente, flussi di sicurezza fornitori, scansioni di orizzonte normativo) e fa emergere i cambiamenti al team di compliance come segnali invece che come ticket. Il registro dei rischi diventa una vista viva su un flusso sottostante di evidenza, anziché un documento statico aggiornato a cadenza. AI Sigil è costruita per questa terza generazione. La piattaforma collega l’obbligo dell’articolo 9 del regolamento IA, i record di misurazione del NIST AI RMF e le attestazioni di controllo ISO/IEC 42001 in un unico strato GRC, perché un team di compliance possa guidare la disciplina alla velocità a cui i sistemi sotto gestione effettivamente cambiano.
Domande frequenti
Che cosa è la conformità nella gestione del rischio? La conformità nella gestione del rischio è il requisito secondo cui ogni attività di trattamento del rischio (identificazione, valutazione, trattamento, monitoraggio) sia condotta in modo da soddisfare leggi, regolamenti, standard e obblighi contrattuali applicabili, conservando l’evidenza per l’audit. È la sutura tra due discipline GRC: fare il lavoro di gestione del rischio E renderlo verificabile. Quali sono i quattro tipi di gestione del rischio? I quattro tipi più citati sono enterprise risk management (ERM), gestione del rischio operativo, gestione del rischio finanziario e gestione del rischio di conformità. Nel 2026 la gestione del rischio IA viene sempre più nominata come quinto tipo, appoggiato sui quattro e che eredita da ciascuno. Il regolamento IA formalizza questo strato con l’articolo 9, un quadro settoriale di gestione del rischio per i sistemi di IA ad alto rischio. Che cosa è un quadro di gestione del rischio di conformità? Un quadro di gestione del rischio di conformità è l’insieme di principi, processi e controlli che un’organizzazione usa per condurre la gestione del rischio in modo riconosciuto dalle autorità. I punti di ancoraggio più ricorrenti nel 2026 sono ISO 31000 per lo strato aziendale, ISO/IEC 42001 per il sistema di gestione dell’IA, il NIST AI RMF per le funzioni operative e l’articolo 9 del regolamento IA per l’obbligo giuridico quando l’IA rientra nel perimetro. La maggior parte delle organizzazioni mature adotta un modello a stella in cui un quadro ancora e gli altri vi si mappano sopra. Quali sono esempi di rischio di conformità? Gli esempi classici includono carenze AML, violazioni GDPR, falle anticorruzione, lacune nel filtro sanzioni, infrazioni al diritto del lavoro. Gli esempi dell’era IA includono immissione sul mercato di un sistema di IA proibito, mancata registrazione di un sistema di IA ad alto rischio nel database UE, mancanza di obblighi di post-market monitoring, deployment di un modello le cui metriche di bias superano le soglie di fair lending e dipendenza da un fornitore di foundation model che non mantiene la documentazione tecnica di cui il deployer ha bisogno per adempiere ai propri obblighi. Serve una certificazione per lavorare in gestione del rischio di conformità? Nessuna certificazione è obbligatoria per legge, ma i datori di lavoro chiedono sempre più spesso almeno una tra: Certified in Risk and Information Systems Control (CRISC), Certified Compliance and Ethics Professional (CCEP), certificazioni compliance del Chartered Insurance Institute o equivalenti settoriali (FRM e PRM nei servizi finanziari). Sulla dimensione IA, percorsi di formazione sul NIST AI RMF e i percorsi lead-auditor o lead-implementer ISO/IEC 42001 stanno diventando la nuova base. In cosa cambia la gestione del rischio di conformità nel settore bancario? In banca la disciplina porta il carico regolatorio più pesante, stratificato su Basilea III/IV, linee guida di vigilanza sul rischio di modello (SR 11-7 negli Stati Uniti, TRIM nell’area euro), resilienza operativa DORA, AML, sanzioni, tutela dei consumatori e ora l’articolo 9 del regolamento IA per credit scoring e altri usi di IA ad alto rischio. La libreria di controlli è più densa, la cadenza più vicina al tempo reale, e la seconda linea è in genere più grande e indipendente che in altri settori. La gestione del rischio di conformità coincide con ISO 31000? No. ISO 31000 è il quadro di gestione del rischio aziendale che fornisce principi, framework e processo per ogni categoria di rischio. La gestione del rischio di conformità è un sottoinsieme che si concentra sul rischio di non conformità regolatoria. ISO 31000 dà il vocabolario e il ciclo di vita che la gestione del rischio di conformità prende in prestito; di per sé non soddisfa alcun obbligo di conformità specifico.
Conclusione
La gestione del rischio di conformità nel 2026 non è più la disciplina del 2020. L’arrivo del regolamento IA, di ISO/IEC 42001, del NIST AI RMF e l’onda parallela DORA, NIS2, CSRD hanno ridisegnato che cosa significa « condurre la gestione del rischio in modo conforme ». I team che fanno convergere i propri quadri in un’unica architettura a stella, che registrano i rischi IA accanto alle otto famiglie classiche, che classificano ogni sistema di IA come fornitore o deployer per assegnare il giusto set di controlli e che passano dal foglio elettronico statico alla sorveglianza continua potenziata dall’IA, passeranno meno tempo a ricopiare voci tra fogli e più tempo a guidare effettivamente il rischio. AI Sigil esiste per dare ai team di compliance questo strato operativo, con l’articolo 9 del regolamento IA, il NIST AI RMF e ISO/IEC 42001 cablati come un unico movimento.