Conformità e governance: il sistema operativo dell’era IA

In sintesi

• Conformità e governance non sono due ambiti paralleli, ma due facce di un unico modello operativo che traduce l’intenzione strategica in evidenze auditabili.
• La governance fissa la direzione e l’autorità; la conformità dimostra che l’organizzazione è rimasta dentro i confini che si è data.
• L’OCEG GRC Capability Model 3.5, il NIST Cybersecurity Framework 2.0 e il NIST AI Risk Management Framework condividono la stessa architettura: governare prima, poi declinare fino ai controlli.
• L’introduzione nel 2024 della funzione GOVERN nel NIST CSF 2.0 e la pubblicazione parallela di ISO/IEC 42001 e del Regolamento europeo sull'IA segnano il momento in cui conformità e governance si sono fuse in un unico workflow accountable.
• Un sistema di conformità e governance che funziona si misura con una prova sola: riesce a tracciare un obbligo esterno, riga per riga, fino a un controllo, a un responsabile e a un documento che gli ispettori potrebbero auditare domani mattina.

Cosa significano davvero conformità e governance

La maggior parte delle pagine che dominano Google parte da un diagramma di Venn rassicurante e si ferma lì. La lezione utile, nascosta sotto lo schema, è un’altra: governance e conformità sono funzioni sequenziali dello stesso modello operativo, non discipline separate.

Governance: fissare la rotta

Il NIST raggruppa governance, rischio e conformità in un’unica disciplina perché condividono lo stesso scopo: allineare ciò che l’organizzazione fa con ciò che la sua leadership ha deciso debba fare. La governance è la metà a monte di questo lavoro. Decide chi può prendere quali decisioni, su quali evidenze e dentro quali confini. In un’impresa tipica, la governance si materializza in statuti, deleghe di poteri, comitati di sorveglianza, politiche e nel calendario delle decisioni che quei comitati devono affrontare nell’anno. Il tratto distintivo della governance è che fissa la rotta. Non verifica che sia stata seguita. Quello è il compito della seconda metà del modello.

Conformità: dimostrare che la rotta è stata tenuta

La conformità è la metà a valle. Accetta la direzione fissata dal livello di governance e produce le evidenze che l’organizzazione è rimasta dentro quella direzione. Le evidenze sono ciò che consumano auditor, autorità e controparti. In un ambiente regolato, la conformità ha due pubblici. L’internal audit guarda le evidenze per confermare che i controlli abbiano funzionato come previsto. I regolatori esterni guardano le stesse evidenze per confermare che l’obbligo legale sia stato rispettato. I due ispezionano spesso gli stessi artefatti; solo l’etichetta cambia, perché cambia l’uditorio.

Il diagramma di Venn dove si ferma la top 10

La maggior parte delle pagine disegna governance e conformità come cerchi che si sovrappongono, con il rischio a ponte. L’immagine non è sbagliata, ma nasconde l’essenziale. Le due funzioni non sono solo adiacenti: sono progettate per alimentarsi a vicenda. La governance produce obblighi e regole; la conformità produce le evidenze che quegli obblighi siano stati onorati; quelle evidenze rifluiscono nella governance e informano il ciclo decisionale successivo. Quando il loop si rompe, si finisce con politiche che nessuno opera e controlli che nessuno riconduce a una politica. È esattamente la modalità di fallimento che ogni framework moderno, dall’OCEG GRC 3.5 al NIST CSF 2.0 fino a ISO/IEC 42001, cerca di evitare.

Come si è arrivati alla GRC: un arco di vent’anni

L’acronimo GRC è stato coniato nel 2002 dall’Open Compliance and Ethics Group (OCEG), e il primo OCEG Red Book che descriveva il capability model è uscito nel 2004. Il driver immediato fu il Sarbanes-Oxley Act statunitense del 2002, che obbligò le società quotate a produrre evidenze auditabili che i loro controlli interni sul reporting finanziario funzionassero davvero. Le aziende che già avevano governance, gestione del rischio e conformità scoprirono che gestirle a silos rendeva quasi impossibile mettere insieme la catena di evidenze SOX. Il contributo di OCEG fu nominare una capability unificata e poi pubblicare un modello open source di cosa significhi farla bene. Il Red Book ha posto la Principled Performance come obiettivo: raggiungere gli obiettivi in modo affidabile, gestire l’incertezza e agire con integrità. Ogni capability descritta da OCEG è uno strumento per quel risultato unico. Due decenni dopo l’architettura è adottata pressoché ovunque. L’inflessione successiva è arrivata a febbraio 2024, con la pubblicazione di NIST CSF 2.0. Il cambiamento riguardava meno la cybersecurity che la governance: NIST ha aggiunto GOVERN come sesta funzione di base, accanto a Identify, Protect, Detect, Respond e Recover. Nello stesso anno l’ISO ha pubblicato ISO/IEC 42001, il primo standard internazionale di management system dedicato all’intelligenza artificiale. I due eventi hanno ratificato la stessa idea da angolazioni diverse: governare prima, poi declinare fino ai controlli. La conformità è la pista di audit di questa traduzione.

Il modello operativo integrato: uno stack, tre framework

I tre framework che i team GRC enterprise cuciono più spesso insieme appaiono superficialmente diversi. Condividono lo stesso scheletro.

OCEG GRC Capability Model 3.5

Il modello OCEG corrente organizza le capability in quattro componenti: LEARN il contesto, la cultura e gli stakeholder che devono dare forma agli obiettivi; ALIGN la strategia agli obiettivi e le azioni alla strategia; PERFORM azioni che favoriscono i risultati desiderati e prevengono quelli indesiderati; REVIEW per rilevare cosa ha funzionato e alimentare il ciclo successivo. Ogni componente si scompone in capability, ogni capability in pratiche, ogni pratica in artefatti che un’organizzazione reale può produrre. Il modello è volutamente scope-neutral e può ospitare qualunque obbligo, dal reporting finanziario alla sicurezza delle informazioni fino all’IA.

Le sei funzioni di NIST CSF 2.0

Il NIST CSF 2.0 organizza il proprio lavoro attorno a sei funzioni: Govern, Identify, Protect, Detect, Respond e Recover. La funzione GOVERN, aggiunta nel 2024, sta al centro. È la funzione che articola la strategia di rischio cyber, le aspettative e la politica dell’organizzazione, e fa in modo che compaiano nelle altre cinque. La scelta è deliberata: senza un livello di governance, i controlli cyber producono attività, non assurance.

Le quattro funzioni del NIST AI Risk Management Framework

Il NIST AI Risk Management Framework porta con sé quattro funzioni: GOVERN, MAP, MEASURE e MANAGE. GOVERN viene per prima per costruzione. Definisce la responsabilità, fissa il rischio tollerabile e assegna le risorse di cui le altre tre funzioni hanno bisogno. MAP cataloga contesto e impatto. MEASURE quantifica. MANAGE applica i trattamenti scelti. La forma è volutamente familiare a qualsiasi organizzazione che pratichi già CSF o COBIT: governare prima, declinare poi.

Uno scheletro, tre perimetri

Questi tre modelli non sono in concorrenza. Sono lo stesso sistema operativo applicato a perimetri diversi: rischio d’impresa, rischio cyber, rischio IA. Il lavoro di un team moderno di conformità e governance è riconoscere l’architettura comune e smettere di mantenere tre librerie di controlli parallele quando una sola libreria ben strutturata basterebbe.

L’architettura dei controlli: dall’obbligo all’evidenza

La parte che quasi nessuna pagina in cima alle SERP tratta in profondità su questa parola chiave è anche la parte che decide se un programma di conformità e governance è reale o decorativo: la catena a quattro anelli che va da un obbligo esterno a un’evidenza.

Obbligo, controllo, evidenza, assurance

Un obbligo è la dichiarazione vincolante con cui un’autorità esterna rende l’organizzazione responsabile. Può essere una clausola di un regolamento, un impegno contrattuale, uno standard che l’organizzazione ha scelto di certificare o una politica imposta dal consiglio di amministrazione. La formulazione è raramente operativa. L’articolo 9(2)(a) del Regolamento europeo sull'IA afferma che i fornitori di sistemi di IA ad alto rischio istituiscono, attuano, documentano e mantengono un sistema di gestione del rischio. È una frase vincolante, non implementabile. Un controllo è la riscrittura operativa dell’obbligo. Nomina un comportamento che l’organizzazione esegue, spesso con una cadenza ricorrente, indica chi lo esegue e quale artefatto produce. Per l’articolo 9 il controllo potrebbe essere: il Comitato Rischi IA esamina trimestralmente il registro dei rischi modello, firma la classificazione del rischio residuo e aggiorna il piano di trattamento entro cinque giorni lavorativi. L’evidenza è l’artefatto che il controllo produce: il modulo firmato, il registro datato, il piano di trattamento aggiornato, la mail di chiusura del presidente. L’evidenza ha una provenienza, un timestamp e un depositario. L’assurance è la verifica indipendente che i controlli abbiano funzionato come progettati e che l’evidenza sia ciò che dichiara di essere. L’internal audit produce assurance per il consiglio; un certificatore esterno produce assurance per un mercato.

Esempio svolto: articolo 9 del Regolamento europeo sull’IA da capo a fondo

Portiamo lo stesso obbligo lungo la catena. L’obbligo: l’articolo 9(2) del Regolamento europeo sull'IA chiede ai fornitori di sistemi di IA ad alto rischio di mantenere un processo continuo di gestione del rischio lungo l’intero ciclo di vita. Il controllo: ogni modello nell’inventario ad alto rischio ha un risk owner nominato, una cadenza trimestrale di revisione ancorata nella charter del Comitato Rischi e un piano di trattamento documentato che fa riferimento alla matrice impatto-severità approvata dal livello di governance. L’evidenza: il verbale del Comitato Rischi, la riga d’inventario con la data dell’ultima revisione, il piano di trattamento con la sua storia di versioni, la mail di conferma del risk owner. L’assurance: un campione di internal audit di tre modelli al trimestre, più la valutazione annuale dell’organismo notificato che conferma il funzionamento della clausola QMS dell’articolo 17. Costruita la catena per un obbligo, la stessa forma si riusa per tutti gli altri. Quel riuso è il senso dell’esercizio.

Dove si fermano la maggior parte degli strumenti GRC, e cosa aggiunge una piattaforma di governance IA

La maggior parte degli strumenti GRC generalisti tratta in modo ragionevole i primi due anelli: permettono di archiviare gli obblighi e mapparli ai controlli. Il terzo e il quarto anello, evidenza e assurance, vengono di solito demandati a sistemi di ticketing e drive condivisi. Quella configurazione funzionava finché un obbligo puntava a un controllo statico. Si rompe quando l’asset sotto governance è un modello di machine learning il cui comportamento cambia a ogni ciclo di retraining. Una piattaforma di governance specifica per l’IA chiude il loop legando la catena di evidenze direttamente al ciclo di vita del modello: il fatto che un modello sia stato riaddestrato di martedì innesca automaticamente la revisione trimestrale del control owner di mercoledì. Esattamente questo accoppiamento è ciò che la piattaforma di governance IA di AI Sigil è stata progettata per offrire al di sopra di uno stack GRC esistente.

Ruoli, responsabilità e modello delle tre linee

La maggior parte delle grandi organizzazioni opera la governance attraverso il modello delle tre linee: la prima linea possiede e gestisce i controlli; la seconda linea sovrintende alle funzioni di rischio e conformità e mette in discussione la prima; la terza linea, l’internal audit, fornisce assurance indipendente al consiglio. Il modello esiste da abbastanza tempo da non essere più controverso. Ciò che cambia è il cast. Il Chief Compliance Officer rimane responsabile dell’inventario regolatorio. Il Chief Risk Officer continua a presidiare la dichiarazione di propensione al rischio. Il comitato di audit del consiglio consuma comunque l’assurance. Due ruoli sono saliti di importanza nell’era IA: il Chief Information Security Officer eredita sempre più i controlli che proteggono i dati di addestramento e i pesi dei modelli; e un Head of AI Governance, che spesso riporta congiuntamente a CCO e CTO, diventa il proprietario naturale della libreria di controlli specifica per l’IA. Dove questo ruolo non esiste ancora, il segnale pratico è che nessuno sa rispondere alla domanda: chi approva l’ultima model card prima del deployment. Il modello si adatta senza fatica quando l’asset sotto governance è un sistema di IA. La prima linea include responsabili di modello, data scientist e ingegneri MLOps; la seconda linea aggiunge una funzione di rischio IA accanto al rischio operativo; la terza linea audita l’inventario dei rischi modello come prima auditava il registro degli accantonamenti su crediti.

L’inflessione dell’era IA: perché la GRC viene ricostruita attorno ai workload di IA

Per vent’anni i programmi GRC hanno assorbito nuove regole estendendo la libreria di controlli esistente. L’onda IA impone un reset strutturale, perché i workload IA rompono due ipotesi su cui poggia l’architettura GRC storica: l’asset è statico tra un audit e l’altro, e la supply chain è limitata dall’ufficio acquisti.

Calendario del Regolamento europeo sull’IA

Il Regolamento europeo sull’IA è entrato in vigore il 1° agosto 2024, con date di applicabilità scaglionate che vincolano già i budget operativi. I divieti sulle pratiche a rischio inaccettabile e gli obblighi di AI literacy si applicano dal 2 febbraio 2025. Le regole su modelli di IA per finalità generali, organismi notificati, governance, riservatezza e sanzioni si applicano dal 2 agosto 2025. Gli obblighi dell’Allegato III per i sistemi ad alto rischio sono stati rinviati dal 2 agosto 2026 al 2 dicembre 2027 con il Digital Omnibus on AI concordato a maggio 2026. Il rinvio sposta la scadenza, non il lavoro.

ISO/IEC 42001 come strato operativo

ISO/IEC 42001, pubblicato a dicembre 2023, è il primo standard di management system dedicato all’IA. Lo standard risponde alla domanda che il Regolamento europeo sull’IA lascia aperta: il come. Secondo la mappatura ISACA del 2025, lo standard si aggancia direttamente a sette articoli centrali del regolamento: gestione del rischio (9), dati e data governance (10), documentazione tecnica (11), conservazione delle registrazioni (12), trasparenza (13), supervisione umana (14) e sistemi di gestione della qualità (17). La sovrapposizione copre una stima del quaranta-cinquanta per cento dei requisiti di alto livello, il che significa che le evidenze prodotte per un regime accelerano il lavoro per l’altro.

La funzione GOVERN del NIST AI RMF nel dettaglio

La funzione GOVERN del NIST AI RMF è il ponte tra la cultura di rischio d’impresa esistente e la nuova libreria di controlli dedicata all’IA. Definisce le condizioni culturali, strutturali e procedurali in cui le altre tre funzioni possono operare. Riconosce esplicitamente anche che il rischio IA è socio-tecnico: il framework chiede alle organizzazioni di valutare non solo se un modello si comporta come progettato, ma se il suo deployment è compatibile con i valori e gli obblighi del contesto d’uso.

Perché l’IA espone i limiti degli strumenti GRC generici

Tre proprietà dei sistemi di IA mettono in crisi gli strumenti GRC generici. Primo, l’asset cambia tra un audit e l’altro: un modello riaddestrato non è più il modello descritto dalle precedenti evidenze di controllo. Secondo, le supply chain sono più ampie: un singolo sistema in produzione può dipendere da un modello di fondazione, da un dataset di fine-tuning, da una piattaforma di inferenza, da un feature store e da un loop di feedback, ciascuno in mano a una parte diversa. Terzo, lo spazio delle conseguenze è più grande: i fallimenti vanno dagli output distorti ad azioni autonome che nessuno ha richiesto. Un programma di conformità e governance costruito per servizi IT statici ha bisogno di uno strato di estensione progettato per queste proprietà.

Implementare conformità e governance: un blueprint di avvio a 90 giorni

I programmi maturi si sono costruiti per incrementi. I primi novanta giorni servono a fissare l’architettura prima che l’inventario cresca.

Giorni 0-30: mappare l’attuale e inventariare gli obblighi

Costruire prima l’inventario degli obblighi. Elencare regolamenti, impegni contrattuali, certificazioni e politiche del consiglio che vincolano l’organizzazione. Catturare il testo vincolante, il regolatore o la controparte, la data di entrata in vigore e il dirigente responsabile nominato. Elencare poi i controlli che già esistono, indipendentemente da dove siano oggi archiviati. L’output è un registro a due colonne: obblighi e controlli esistenti, con le lacune e gli orfani visibili.

Giorni 31-60: istanziare l’architettura di controllo per due obblighi pilota

Scegliere due obblighi che contano. Uno su terreno familiare (una clausola SOX, GDPR o ISO 27001); uno specifico per l’IA (un articolo del Regolamento europeo sull'IA o una clausola di ISO/IEC 42001). Costruire la catena completa a quattro anelli per ciascuno: obbligo, controllo, evidenza, assurance. Cronometrare il lavoro. La prima catena richiede di norma una settimana; la seconda due giorni. Quel rapporto è il proof of concept su cui il resto del programma costruisce.

Giorni 61-90: definire la cadenza delle evidenze e il loop di assurance

Decidere con che frequenza ciascun controllo produce le proprie evidenze, chi le rivede e cosa innesca un’eccezione. Inserire la cadenza nel calendario del team responsabile e definire il percorso che un’eccezione segue prima di finire nell’ordine del giorno del Comitato Rischi. Avviare il primo campione di internal audit sui due controlli pilota entro il giorno 90. Al termine del campione l’organizzazione avrà attraversato un ciclo completo di conformità e governance per due obblighi e disporrà delle evidenze per scalare il modello.

Conformità e governance in pratica: una PMI e un grande gruppo

Il modello operativo scala verso il basso e verso l’alto.

PMI con un obbligo ISO 27001 e un obbligo Regolamento europeo sull’IA

Una fintech da 200 persone con un singolo modello di IA per la rilevazione di frodi può portare avanti un programma credibile con una decina di controlli. La lista di obblighi è breve: ISO 27001 per la sicurezza delle informazioni, gli articoli pertinenti del Regolamento europeo sull'IA per il sistema di IA, le regole sull’outsourcing dell’autorità locale. La libreria di controlli eredita le evidenze SOC 2 che l’azienda già produce e aggiunge tre controlli specifici per l’IA: registro dei rischi modello, validazione del retraining, revisione delle soglie di monitoraggio post-deployment.

Multinazionale che mappa SOX, GDPR, Regolamento europeo sull’IA e regole settoriali

Una banca globale opera su un’altra scala. Le evidenze SOX sostengono la pubblicazione trimestrale dei risultati. I controlli GDPR proteggono i dati dei clienti in trenta giurisdizioni. I controlli Regolamento europeo sull'IA coprono il modello di credit scoring ad alto rischio e il filtro sulle pratiche vietate dello stack marketing. Regole settoriali, come le linee guida EBA sul model risk, si sovrappongono a tutto questo. La libreria di controlli conta migliaia di elementi. L’architettura è la stessa della fintech: obbligo, controllo, evidenza, assurance. Cambia solo il volume.

Domande frequenti

Cosa si intende per conformità e governance? La governance fissa la direzione che l’organizzazione si impegna a seguire, attraverso statuti, politiche e deleghe di potere. La conformità produce le evidenze che l’organizzazione è rimasta dentro quella direzione. Insieme formano il modello operativo che traduce gli obblighi esterni in controlli auditabili e nei documenti che quei controlli producono. Quali sono le 4 P della governance? Le 4 P più citate nella letteratura sulla governance pubblica e d’impresa sono People (chi detiene autorità e responsabilità), Purpose (la missione o gli obiettivi a cui l’organizzazione si impegna), Process (come si prendono e si rivedono le decisioni) e Performance (come si misurano e si rendicontano i risultati). La lista esatta varia per fonte; la sostanza no. I framework di governance funzionano quando rendono le quattro espliciti e le loro relazioni auditabili. Quali sono le 4 fasi della conformità? Un ciclo di conformità attraversa di norma quattro fasi: Identificare l’obbligo e l’ambito a cui si applica; Implementare i controlli che soddisfano l’obbligo; Monitorare i controlli per cogliere presto le deviazioni; Rendicontare le evidenze al pubblico interno ed esterno. Ogni fase produce artefatti di cui la successiva vive. I programmi che saltano monitoraggio e rendicontazione producono politiche, non assurance. Quali sono le tre C della conformità? Le tre C più citate sono Cultura, Comunicazione e Controlli. La cultura plasma le decisioni quotidiane quando nessuno guarda. La comunicazione mantiene visibili gli obblighi per le persone il cui lavoro li tocca. I controlli sono i comportamenti e gli artefatti che traducono la politica in evidenza. Le tre si rinforzano a vicenda; un’organizzazione che investe solo nei Controlli senza Cultura e Comunicazione ricostruirà le stesse lacune ad ogni audit. GRC è uguale a conformità e governance? Quasi. GRC è un sovra-insieme che aggiunge la gestione del rischio come terzo pilastro. Conformità e governance descrivono la metà che fissa la direzione e quella che produce le evidenze; la gestione del rischio è la funzione che decide quali obblighi e controlli meritino la maggior attenzione. I framework moderni li trattano come inseparabili, ed è per questo che OCEG, NIST e ISO 42001 li cablano insieme. ISO 42001 è obbligatoria ai sensi del Regolamento europeo sull’IA? No. La certificazione ISO/IEC 42001 non è richiesta dalla legge ai sensi del Regolamento europeo sull'IA. I due sono progettati per completarsi. Il regolamento dice alle organizzazioni regolate cosa devono raggiungere; lo standard descrive come far funzionare, evidenziare e migliorare con continuità un programma di governance dell’IA in un modo che soddisfi regolatori, certificatori e consiglio. Certificare 42001 non prova da solo la conformità al regolamento, e la conformità al regolamento non richiede la certificazione 42001. La maggior parte delle organizzazioni perseguono entrambe le strade perché il lavoro sottostante si sovrappone per circa metà. AI Sigil sostituisce il nostro strumento GRC esistente? No. AI Sigil è progettato per stare sopra uno stack GRC esistente come strato operativo dedicato ai sistemi di IA. Usa la stessa catena obbligo, controllo, evidenza, assurance, e collega poi il lato evidenza direttamente al ciclo di vita del modello IA, così un evento di retraining innesca automaticamente le revisioni di controllo pertinenti. Lo strumento GRC esistente mantiene la libreria di controlli d’impresa; AI Sigil tiene l’estensione specifica per l’IA e restituisce le evidenze.

Conclusione

Conformità e governance sono un modello operativo, non due ambiti. I framework che le SERP continuano a riproporre come definizioni affiancate stanno in realtà ripetendo la stessa architettura: governare prima, poi declinare fino ai controlli, alle evidenze e all’assurance. La funzione GOVERN del NIST CSF 2.0, l’ISO/IEC 42001 e il Regolamento europeo sull'IA non hanno inventato questa architettura; l’hanno ratificata per l’era IA. Il lavoro dei responsabili della governance oggi è riconoscere questa forma unificata e smettere di mantenere programmi paralleli che producono evidenze in doppio e decisioni in contraddizione. La strada più breve tra il punto in cui si trovano la maggior parte delle organizzazioni e ciò che ora regolatori e consigli si aspettano passa dal costruire una sola catena a quattro anelli, dimostrarla su due obblighi e poi scalare l’architettura al resto dell’inventario. Per vedere come quello strato operativo si presenta specificamente per i sistemi di IA, la piattaforma AI Sigil è stata costruita per innestarsi sopra lo stack GRC che già usate.