Framework di Governance AI: Come Costruirne Uno Funzionale

L'IA raggiunge la maggior parte delle organizzazioni attraverso più porte contemporaneamente. Un assistente con licenza qui, una funzione di IA attivata all'interno di uno strumento SaaS esistente là, e una manciata di strumenti per cui nessuno ha aperto un ticket.

Il framework di governance che dovrebbe coprire tutto di solito arriva più tardi, se arriva. In The Netwrix 2026 Data and Identity Security Report, il 41% delle organizzazioni già utilizza AI agentica in produzione per conto degli esseri umani, mentre l'11% ha operazionalizzato la governance AI tramite revisioni continue, proattive e obbligatorie.

La fiducia evidenzia questa lacuna, e non è un bello spettacolo. Solo il 18% delle organizzazioni con un fatturato tra 100 milioni e 1 miliardo di dollari si sente molto sicuro di superare un audit indipendente sulla governance e i controlli dell'IA, secondo Grant Thornton.

Nel frattempo, il 42% dei responsabili IT del mercato medio intervistati in The Netrio’s Mid-Market AI Readiness Report ha segnalato un incidente o un’esposizione alla sicurezza correlata all’IA confermata nell’ultimo anno. Il framework che colma questa distanza collega ogni regola scritta a un controllo che qualcuno può testare e a un record che qualcuno può estrarre.

Cos'è un framework di governance dell'IA?

Un framework di governance dell'IA è un insieme strutturato di politiche, ruoli, processi e controlli che regolano come un'organizzazione progetta, implementa e utilizza i sistemi di IA. Questo include assistenti con licenza, strumenti pubblici accessibili dal personale tramite browser, funzionalità di IA integrate nelle applicazioni SaaS e modelli interni.

ISO/IEC 42001 si riferisce a un sistema di gestione dell'IA, che enfatizza la struttura operativa. Un framework di gestione del rischio IA si concentra sull'identificazione e il trattamento del rischio.

Questi tre documenti spesso si confondono, e la distinzione determina chi è responsabile. Un framework definisce la responsabilità e il processo attraverso le fasi del ciclo di vita. Una policy stabilisce la regola, e una assessment verifica quanto bene ciascuno funziona in una data specifica.

Perché un framework di governance dell'IA è importante

Il framework si guadagna il suo posto trasformando decisioni sparse in qualcosa che un consiglio, un regolatore o un revisore possono ispezionare:

• Approvazione basata su prove: La sicurezza può approvare un rollout di IA con un elenco nominativo di cosa raggiunge ogni strumento e sotto quali identità, invece di una garanzia da chi l'ha costruito.
• Una traccia di controllo difendibile: Valutazioni del rischio, report di accesso, cronologia della configurazione e verbali del comitato sono tutti in un unico posto quando qualcuno li richiede.
• Raggio d’azione contenuto: La definizione dell’ambito e i limiti di accesso determinano quanti dati può raggiungere una sessione di AI compromessa o configurata in modo errato.
• Approvazioni più veloci, non più lente: Un percorso di accoglienza permanente e livelli di rischio consentono ai casi a basso rischio di passare rapidamente e indirizzano il resto a una revisione reale.
• Un programma invece di due: Il rischio AI arriva nei registri, nelle librerie di controllo e nei gate di revisione già attivi, quindi nulla viene mantenuto due volte.

Ognuno di questi dipende dalla stessa cosa fondamentale: sapere cosa può attualmente realizzare l'IA in un ambiente live.

Perché i programmi di governance esistenti restano indietro rispetto all'IA

Tre forze colpiscono il team di sicurezza quasi contemporaneamente. Ognuna allarga la distanza tra ciò che la policy dichiara e ciò che l’ambiente può dimostrare.

L'IA arriva più velocemente di quanto venga approvata

L'uso supera la politica, e i numeri non sono vicini. Il 2026 AI Pulse Poll di ISACA ha rilevato che il 90% dei professionisti della fiducia digitale ritiene che i dipendenti utilizzino l'IA nella loro organizzazione, mentre solo il 38% di tali organizzazioni ha una politica formale e completa sull'IA.

La sequenza spiega la maggior parte della carenza. Il rapporto dell’indagine RSM AI ha rilevato che circa un terzo delle organizzazioni di mercato medio passa a piloti o produzione prima che siano in atto controlli di governance, con il 16% che raggiunge la governance solo dopo che qualcosa va storto. Ciò che si accumula è una pila di approvazioni una tantum ed eccezioni non documentate. Regge finché qualcuno non chiede prove.

Le scadenze di conformità hanno iniziato a passare

Gli standard sono arrivati per primi e hanno stabilito l'aspettativa di struttura. ISO ha pubblicato ISO/IEC 42001 il 18 dicembre 2023 come standard internazionale per sistemi di gestione dell'IA, e la maggior parte dei team lo abbina al NIST AI RMF come compagno volontario.

Poi la timeline dell’UE è cambiata, e non nella direzione prevista dalla maggior parte dei team. Il Digital Omnibus on AI, adottato come Regolamento (UE) 2026/1744 l’8 luglio 2026, ha spostato la maggior parte degli obblighi ad alto rischio al 2 dicembre 2027 per i sistemi autonomi dell’Allegato III e al 2 agosto 2028 per i sistemi dell’Allegato I integrati nei prodotti.

Due date non sono cambiate e sono entrambe passate. Gli obblighi di trasparenza dell'articolo 50 e i poteri di applicazione della Commissione sui modelli di IA a uso generale sono in vigore dal 2 agosto 2026, secondo il AI Act enforcement timeline. I sistemi generativi già sul mercato prima di quella data hanno tempo fino al 2 dicembre 2026 per rispettare l'obbligo di marcatura dell'articolo 50(2), che è la prossima scadenza reale per la maggior parte dei team.

L'IA amplifica il debito di permessi che hai già

Uno strumento di IA utilizza l'accesso già esistente. La guida di Microsoft sull'eccessiva condivisione è chiara a riguardo: Copilot eredita i permessi e le protezioni esistenti di Microsoft 365, quindi siti con permessi eccessivi, accessi ereditati e etichette di sensibilità mancanti devono essere corretti prima del deployment.

Anni di condivisione ad hoc che nessuno notava diventano ricercabili nel momento in cui un prompt può raggiungerli. Sistemare prima quel livello è anche dove si vede il vantaggio, poiché le organizzazioni con identità unificata e governance dei dati hanno quasi cinque volte più probabilità di dichiarare piena preparazione all'IA.

I sei pilastri di un framework di governance dell'IA funzionante

La maggior parte dei framework pubblicati nasconde la visibilità dell'accesso ai dati all'interno di domini più ampi come la privacy o la governance dei dati. Ha un pilastro dedicato perché la certificazione e l'audit ne dipendono, e le procedure di audit AI di ISACA richiedono specificamente i log di accesso, i processi di gestione delle modifiche e le politiche basate sui ruoli.

1. Ambito e inventario

L'ambito definisce a cosa si applicano tutti gli altri controlli. Nomina i sistemi di AI e i casi d'uso coinvolti, insieme agli obiettivi aziendali, alla propensione al rischio e agli obblighi normativi associati a ciascuno.

La clausola 4.3 di ISO/IEC 42001 richiede che l’ambito sia disponibile come informazione documentata. Una dichiarazione di ambito senza alcun inventario di supporto fallisce al primo campione.

2. Percorsi di proprietà e approvazione

La responsabilità ricade su individui nominati. Un sponsor esecutivo, un responsabile della governance, la sicurezza, la protezione dei dati e i proprietari delle unità di business detengono ciascuno un diritto decisionale specifico.

Il controllo A.3.2 della ISO/IEC 42001 lo afferma chiaramente, richiedendo che "i ruoli e le responsabilità per AI siano definiti e assegnati in base alle esigenze dell'organizzazione." Il test pratico è se qualcuno può dire chi approva un nuovo caso d'uso e chi può disattivarlo.

3. Policy mappata ai controlli

La politica copre l’uso accettabile, i tipi di dati vietati, i requisiti di intervento umano, le aspettative di trasparenza e la gestione degli incidenti. Una politica funziona quando ogni riga nomina il controllo che la applica.

Questi controlli sono restrizioni di accesso, data classification, una delle soluzioni DLP già implementate, accesso condizionale e registrazione. Una regola senza controllo dietro è una sentenza, non una salvaguardia.

4. Visibilità dei dati e dell’identità

Questo pilastro risponde a due domande su qualsiasi interazione con l'IA. Quali dati potrebbe raggiungere lo strumento e quale identità umana, macchina o non umana l'ha invocato?

È anche il pilastro che la maggior parte dei programmi non riesce a dimostrare. Il rapporto quantifica il motivo, rilevando che il 74% delle organizzazioni non dispone di una vista unica e unificata dei dati sensibili e delle identità che vi possono accedere. L'accesso concesso e l'accesso effettivo sono liste diverse, e divergono rapidamente in qualsiasi ambiente con una storia.

5. Gestione del ciclo di vita

Il ciclo di vita va dai dati allo sviluppo del modello, al deployment, alla revisione e al ritiro, con una porta decisionale a ogni transizione. Il ritiro è la porta che quasi nessuno raggiunge ed è quella di cui chiedono gli auditor.

Gestione del ciclo di vita di Identity gestisce già chi entra, si sposta e lascia per le persone, e gli agenti AI appartengono alla stessa disciplina. La sottocategoria MANAGE 2.4 del NIST AI RMF richiede meccanismi e responsabilità assegnate per sostituire, disconnettere o disattivare sistemi AI che operano in modo incoerente con l'uso previsto.

6. Misurazione e miglioramento

La misurazione fornisce al comitato di governance elementi su cui decidere. Le misure che meritano il loro posto sono il conteggio degli incidenti di AI, le eccezioni alle policy, la copertura della valutazione del rischio e l'efficacia del controllo.

Le clausole 9 e 10 di ISO/IEC 42001 riguardano il monitoraggio, l’audit interno, la revisione della direzione e l’azione correttiva. Qualsiasi cosa che non modifica una decisione non vale la pena tracciarla.

Come costruire il framework in cinque passaggi

I pilastri descrivono cosa contiene il framework finito. La costruzione segue un ordine diverso, iniziando dall'AI già presente nell'ambiente piuttosto che dalla policy che qualcuno vuole scrivere. Segui questi cinque passaggi in sequenza.

1. Inventariare l'IA già in esecuzione

Preleva da tre fonti, perché nessun sistema singolo sa tutto. Le app con licenza e i service principals provengono dal tuo identity provider, le funzionalità AI integrate provengono dalle note di rilascio del vendor e dai centri di amministrazione, e gli strumenti non autorizzati provengono dai log di uscita.

Aspettatevi che la lista sanzionata sottostimi notevolmente. Un sondaggio PagerDuty del 2026 ha rilevato che il 66% dei professionisti d’ufficio ha utilizzato l’IA al lavoro nonostante credesse che le loro politiche non lo consentissero, e solo il 20% delle organizzazioni monitora o governa completamente la shadow AI.

Quindi ordina ciò che hai trovato in livelli di rischio. La produttività interna, i servizi rivolti ai clienti e l’uso di dati regolamentati richiedono diversi livelli di controllo, e il livello determina quanto lavoro residuo riceve un sistema.

2. Assegna i proprietari e crea il percorso di approvazione

Assegna a ogni sistema di IA un proprietario nominato in IT, sicurezza, protezione dei dati o nella linea di business che lo utilizza. Team, comitati e liste di distribuzione non contano.

Quindi mappa il percorso della richiesta, dalla valutazione del rischio alla progettazione del controllo, alla firma e alla data di revisione. Annota chi concede eccezioni e chi può sospendere un sistema quando il suo rischio cambia.

Mantieni la trasparenza con la access certification ricorrente, che conferma che amministratori, account di servizio, applicazioni e agenti AI detengono solo ciò che serve per il loro lavoro attuale. Active Directory service accounts sono solitamente il luogo dove si nascondono i diritti obsoleti.

3. Mappa ogni regola a un controllo che puoi testare

Prendi la policy riga per riga e scrivi il controllo che la applica accanto. Se non riesci a nominarne uno, la regola non è ancora applicabile e va inserita nella lista delle lacune.

Dichiara le linee rosse in modo chiaro e senza esitazioni. Nessun accesso di IA generativa a informazioni personali identificabili (PII) non classificate, con eccezioni nominate per dati legali e delle risorse umane.

L'accesso privilegiato deve essere gestito secondo le sue regole. Gli amministratori che configurano i servizi AI necessitano di elevazione, quindi emettere credenziali just-in-time (JIT) a breve termine per ogni sessione approvata e applicare zero standing privilege agli account che integrano tali servizi.

4. Integra l’IA nei processi che già esegui

Aggiungi categorie di rischio AI ai registri di rischio esistenti, alle librerie di controllo e ai tracker di problemi, quindi instrada i casi d'uso AI attraverso le porte di accettazione, gestione delle modifiche e revisione della sicurezza già in atto. Le linee guida ISACA raccomandano esattamente questo, con la gestione del rischio AI che integra i programmi consolidati di cyber, rischio e privacy.

Tratta l'IA di terze parti e integrata allo stesso modo, registrando il fornitore, i flussi di dati, il metodo di integrazione, i termini di conservazione, il proprietario e il piano di uscita. Dove le revisioni degli accessi richiedono strumenti, confronta gli IGA tools con i sistemi già inclusi nell'ambito.

5. Imposta il ritmo, poi dimostra che funziona

Definisci la cadenza delle revisioni prima della prima scadenza e integra queste misure nei cicli esistenti di IT risk assessment. Verifica quali strumenti di conformità già implementati possono generare report prima di acquistare qualcosa di nuovo.

Quindi testa il framework come farebbe un revisore. Scegli un sistema AI, recupera il suo proprietario, livello di rischio, set di controlli, rapporto di accesso e data dell’ultima revisione, e verifica quanto puoi produrre in un’ora.

Allineare il framework con NIST AI RMF e ISO/IEC 42001

Un framework costruito in questo modo finisce per essere scritto nel tuo vocabolario. Auditor, clienti e regolatori non lo richiederanno così. Chiedono a quale standard ti allinei, e il mapping ti permette di rispondere senza ricostruire nulla.

La clausola 5 di ISO/IEC 42001 riguarda la proprietà e la politica sull’IA, le clausole 6 e 8 riguardano la valutazione del rischio e dell’impatto, e le clausole 9 e 10 riguardano la misurazione e il miglioramento. Quattro dei sei pilastri sopra sono stati rinominati.

Quale dei due mappi per primo non è una questione di fortuna, e il motivo si perde perché entrambi vengono nominati insieme. ISO/IEC 42001 è verificabile e certificabile. Il NIST AI RMF non lo è. Questa differenza decide cosa puoi affermare e dove devono arrivare le tue prove.

Cosa che l'AI RMF può e non può fare per un programma incentrato sui dati

Il nucleo di AI RMF organizza la gestione del rischio attraverso Govern, Map, Measure e Manage, e le sue sottocategorie sono dichiarazioni di risultati, non requisiti. NIST non pubblica schemi di valutazione della conformità, criteri di accreditamento o requisiti per organismi di certificazione. Puoi dire che il tuo programma è allineato con AI RMF o che i controlli corrispondono alle sue sottocategorie. Non puoi dire "certificato NIST AI RMF."AI RMF Core organizes risk management across Govern, Map, Measure, and Manage, and its subcategories are outcome statements, not requirements. NIST publishes no conformity assessment schemes, accreditation criteria, or certification body requirements. You can say your program aligns with the AI RMF or that controls map to its subcategories. You can't say "NIST AI RMF certified."

C'è una seconda limitazione da conoscere prima di mappare qualsiasi cosa. Tra tutte le 72 sottocategorie, nessuna nomina access control, identity, authentication, permissions o data provenance. Quindi sapere quali identities possono accedere a quali dati, ciò che un pacchetto di prove attiva realmente, si mappa all'AI RMF per interpretazione e non per aggancio testuale.

Tre famiglie di sottocategorie sostengono questo peso nella pratica. Il set di terze parti è il più forte, con GOVERN 6.1 che copre le politiche per il rischio AI di terze parti, MANAGE 3.1 che richiede che "i rischi e i benefici dell'AI da risorse di terze parti siano regolarmente monitorati", e MAP 4.2 che copre i controlli interni del rischio per componenti di terze parti. MEASURE 2.7 e 2.10 sono dove si trovano le prove di valutazione di sicurezza e privacy. Per la de-provisioning, abbina MANAGE 2.4 con GOVERN 1.7.

Perché il crosswalk NIST deve essere tradotto prima di un audit

NIST pubblica un crosswalk dalle sottocategorie AI RMF a ISO/IEC 42001, e fa risparmiare lavoro reale. Ha anche una caratteristica che inganna i team. Ognuno dei suoi 202 riferimenti di controllo punta all'Allegato B, e non cita alcun controllo dell'Allegato A.

Questa distinzione determina se la tua mappatura supera un audit. L'Allegato A è normativo, i suoi controlli recitano "shall" e la Dichiarazione di Applicabilità è basata su di esso. L'Allegato B è una guida all'implementazione; i suoi controlli recitano "should" e afferma chiaramente che le organizzazioni non devono giustificare l'inclusione o l'esclusione di tale guida nella Dichiarazione di Applicabilità. Una riga di crosswalk che invia MANAGE 2.4 a "B.9.4 Intended use of the AI system" indica un consiglio, non un controllo verificabile.

La traduzione è meccanica perché 42001 numerano i due allegati in parallelo, quindi B.9.4 è la guida per A.9.4. Saltarlo è l'errore comune. Un'altra cosa da sapere: il crosswalk si riferisce a ISO/IEC FDIS 42001, la bozza finale, e non allo standard pubblicato.

La clausola che la maggior parte dei programmi manca

La valutazione del rischio e la valutazione dell'impatto sono obblighi separati in 42001, e confonderli è la lacuna più comune in una Dichiarazione di Applicabilità per la prima volta. La clausola 6.1.2 valuta il rischio per i propri obiettivi di IA, con probabilità, livelli di rischio e criteri di rischio. La clausola 6.1.4 valuta l'impatto esterno su individui, gruppi di individui e società, senza alcun meccanismo di probabilità.

La relazione è unidirezionale. La clausola 6.1.4 richiede che i risultati della valutazione dell’impatto siano considerati nella valutazione del rischio, mentre la nota 6.1.2 afferma che un’organizzazione può utilizzare una valutazione dell’impatto per valutare le conseguenze. Ognuna comporta un proprio obbligo di documentazione; l’Appendice A.5 controlla l’aspetto dell’impatto, e la clausola 8.4 richiede di eseguire entrambe a intervalli pianificati o in caso di cambiamenti significativi e di conservare i risultati. ISO/IEC 42005 fornisce il metodo, anche se è una guida e non può essere certificato.

La visibilità di dati e identità si basa sui controlli piuttosto che sulle clausole. Dei 38 Annex A controls in nove categorie, A.7.5 Data provenance è quello che un programma incentrato sui dati desidera, poiché richiede un processo documentato per registrare la provenienza dei dati AI.

Ciò che la certificazione richiede realmente

La certificazione si svolge in due fasi secondo ISO/IEC 17021-1, con la competenza dell'ente di certificazione stabilita da ISO/IEC 42006, pubblicata a luglio 2025. La fase 2 è quella per cui si pianifica, poiché valuta l'implementazione e l'efficacia in loco rispetto ad artefatti come valutazioni del rischio completate e registri degli eventi del sistema AI.

La Fase 1 è quella che sorprende le persone. Valuta la preparazione per la Fase 2, incluso se le revisioni interne e la revisione della direzione sono state effettivamente eseguite e non solo programmate. Deve esserci stato un ciclo completo di audit interno, il che di solito sposta la data reale di certificazione di un trimestre rispetto a quanto presumono i team.

Checklist del framework di governance AI

Sei domande evidenziano lacune che diventano risultati di audit. Rispondi a ciascuna in base all'ambiente che hai, non a quello della politica:

• Il programma nomina i responsabili e stabilisce cicli di revisione con date reali?
• Hai individuato tutti i sistemi di IA in uso e li hai mappati ai dati e alle identità a cui accedono?
• Le vostre politiche di IA si riferiscono a controlli tecnici specifici, coprendo restrizioni di accesso, DLP, accesso condizionale e logging?
• Il framework è allineato a NIST AI RMF, ISO/IEC 42001 o a entrambi, in modo che la copertura possa essere valutata?
• Puoi produrre valutazioni del rischio, registri di configurazione, report di accesso e verbali di commissione su richiesta?
• Hai un piano per aggiornare il framework man mano che strumenti, regolamenti e rischi cambiano?

Qualsiasi cosa a cui non puoi rispondere è una lacuna che necessita di un responsabile, un piano di rimedio e una data di convalida.

Come Netwrix colma il divario di prove nella governance dell'IA

Il quarto pilastro è dove l'intento di governance incontra la realtà ambientale, e si basa su dati che gli strumenti nativi mantengono in forma sintetica o distribuiscono attraverso portali. Netwrix fornisce questo livello tramite capacità di AI governance, ed è importante essere precisi su cosa fa ciascun prodotto.

Segnalare ciò che l'IA può raggiungere

Netwrix 1Secure risponde alla domanda pre-lancio mentre la decisione è ancora reversibile, segnalando i dati sensibili a cui Copilot può accedere prima che qualcuno lo abiliti. Dopo il go-live, riferisce sull'attività di Copilot, elencando utenti, timestamp e risorse referenziate, e segnalando risposte che espongono dati sensibili. Tiene anche traccia di ruoli, permessi e modifiche in Microsoft Entra ID.

Netwrix Access Analyzer gestisce la parte più complessa della questione. Risolve l'appartenenza a gruppi nidificati per calcolare l'accesso effettivo per gli utenti di Active Directory e Microsoft Entra ID, siti SharePoint e sistemi di file, evidenziando accessi aperti e ereditarietà interrotta. Questo trasforma il quarto pilastro da un'affermazione a un rapporto per identità che puoi consegnare.

Conservazione delle prove oltre la finestra del registro

I framework vengono controllati mesi dopo che le decisioni sono state prese, il che rende questo un problema di conservazione prima che di reportistica. Netwrix Auditor registra chi ha cambiato cosa e quando con valori prima e dopo, e crea report di stato nel tempo da snapshot giornaliere della configurazione.

Due clienti regolamentati mostrano la differenza al momento dell'esame. First National Bank and Trust of Beloit mantiene la conformità continua OCC per 300 utenti in 17 sedi, sostituendo una settimana intera di lavoro manuale con liste di controllo con un'ora di preparazione.

Credissimo dimostra la conformità a GDPR e ISO/IEC 27001 nelle sue operazioni di finanziamento al consumo, generando report di audit l’85% più velocemente, in un giorno anziché in una settimana.

Netwrix copre il livello di accesso ai dati, identità e reportistica di audit di cui ha bisogno il pilastro quattro e che le piattaforme più ampie di governance AI presumono tu abbia già. Queste piattaforme gestiscono il flusso di lavoro più ampio; il fornitore di AI mantiene il controllo del comportamento del modello; e il framework, il comitato e le decisioni restano a te.

Verifica il framework su un sistema prima

La leadership si fida di un framework quando i dati attuali di accesso, configurazione e attività informano le sue decisioni. Questo sconsiglia di lanciare l’intero programma in una volta. Scegli un sistema ad alto impatto, quindi misura l’esposizione dei dati sensibili, l’ampiezza dei permessi, il volume delle eccezioni e la completezza del pacchetto di prove.

Un assistente con licenza che gira sul tuo tenant esistente è il miglior prototipo, perché il suo modello di permessi si basa sulle decisioni di accesso già in atto e gli strumenti di visibilità esistono oggi. Applica i sei pilastri a quel sistema, verifica cosa dimostrano le prove e porta il modello al resto dell'inventario AI da lì.

Richiedi una demo per scoprire cosa possono fare i tuoi strumenti di IA, mappare le identità dietro di essi e conservare la cronologia delle modifiche richiesta dalla tua prossima verifica.