Audit di Governance AI per i Team di Sicurezza e IT

La direzione approva Microsoft 365 Copilot, e due giorni dopo il reparto legale vuole sapere quali file sensibili può leggere. Nel sondaggio dietro il Netwrix 2026 Data and Identity Security Report, il 71% dei responsabili della sicurezza e IT ha dichiarato di non poter determinare immediatamente quali identità hanno accesso a un dato sensibile specifico.

L'assistente stesso è raramente il problema. La documentazione di Microsoft afferma che Copilot rende visibili i dati organizzativi a cui gli utenti individuali hanno almeno i permessi di visualizzazione, quindi ogni appartenenza a gruppi obsoleti e sito condiviso eccessivamente diventa un possibile risultato del prompt. La lacuna di controllo risiede nel livello di permessi sottostante, dove anni di condivisione ad hoc si accumulano senza revisione.

Testare l’identità di primo livello e un file alla volta è ciò che produce una risposta che nessuno deve accettare sulla fiducia.

Cos'è l'audit della governance dell'IA?

L'audit della governance dell'IA verifica se i controlli che regolano l'accesso dell'IA a dati, identità e flussi di lavoro funzionano come previsto. Le prove includono registri, risultati dei test, rapporti sui permessi e revisioni datate.Le linee guida di audit di PwC inquadrano il compito come testare il design e l'efficacia dei controlli relativi all'IA. Ciò significa documentare come ogni controllo è progettato, come funziona e come la direzione lo testa.

Un audit di governance termina con l’efficacia del controllo. Il test delle prestazioni del modello è una disciplina separata che copre bias, deriva, accuratezza e spiegabilità.

L'ambito copre governance e policy, rischi tecnici e di modello, e controlli di accesso ai dati e di identità. Il IIA's AI Auditing Framework assegna questo lavoro per responsabilità, mappandolo al Modello delle Tre Linee affinché gli organi di governance, la direzione e l'audit interno abbiano ciascuno una quota definita. L'identità è esplicitamente inclusa nell'ambito, e il ISACA AAIA outline richiede agli auditor di valutare il programma specifico di gestione di identità e accesso AI di un'organizzazione.

Perché l’audit della governance dell’IA è più importante del documento di policy

Una policy esprime un’intenzione. Un audit produce gli artefatti che dimostrano che quell’intenzione è sopravvissuta al contatto con un tenant attivo. Questo divario separa un programma di governance da una slide di governance, e si traduce in quattro benefici specifici.

Approvare l'adozione dell'IA basata su prove

I team di sicurezza devono approvare le implementazioni di IA in una tempistica stabilita da altri. Un audit completato consente loro di firmare con un elenco nominativo degli strumenti di IA che accedono a quali dati e con quali identità. L'approvazione si basa su un confine effettivamente testato, non solo descritto.

Trasformare la policy in un record di misurazione

L'aspettativa del NIST AI RMF per la misurazione continua si trova in MEASURE 2.4. Afferma che la funzionalità e il comportamento del sistema AI e dei suoi componenti, identificati nella funzione MAP, sono "monitorati quando in produzione." Un audit trasforma una politica scritta in un record che soddisfa tale aspettativa, costruito da log, report di permessi, risultati di test firmati e revisioni con date e nomi allegati.

Individuare l'esposizione prima che diventi un incidente

I siti condivisi eccessivamente e i permessi obsoleti emergono secondo il calendario di qualcun altro, di solito durante un'indagine. Il Netwrix 2026 Data and Identity Security Report ha rilevato che il 75% delle esposizioni di dati sensibili inizia con identità compromesse o permessi configurati in modo errato. Questo rende lo strato dei permessi il luogo più redditizio da esaminare.

Un audit programmato trasforma quelle condizioni in riscontri con ticket e responsabili nominati, mesi prima di una revisione delle violazioni.

Un audit programmato trasforma quelle condizioni in riscontri con ticket e responsabili nominati mesi prima di una revisione delle violazioni.

Fornire alla leadership un numero che si muove

I consigli finanziano il lavoro che possono monitorare, e un audit completato fornisce un conteggio delle lacune aperte, insieme ai responsabili e alle date obiettivo. I team ricavano quel conteggio da test di controllo falliti e risultati non risolti, quindi i progressi si leggono come una linea di tendenza, proprio come la conformità alle patch o i tassi di fallimento del phishing.

Come verificare i controlli di governance dell'IA

Un auditabile difendibile risponde a cinque domande, in ordine. Copre quali sistemi di IA sono in uso, quali dati sensibili ciascuno può accedere, sotto quali identità operano, quali controlli si applicano e quali prove dimostrano che tali controlli funzionano. Segui i sei passaggi seguenti in sequenza e completa ciascuno con l'artefatto indicato alla fine.

1. Crea e verifica l'inventario degli asset AI e degli accessi ai dati

Estrai l'inventario da tre fonti, perché nessun sistema conosce tutto. Prendi le app AI con licenza e i service principals da Microsoft Entra ID. Aggiungi le funzionalità AI integrate dalle note di rilascio e dal centro di amministrazione di ogni fornitore SaaS, oltre agli strumenti non autorizzati dai log di uscita o dal tuo CASB. Per ogni voce, registra il proprietario, lo scopo aziendale, l'ambiente e i repository che lo strumento può leggere.

Quindi riconcilia le tre liste e considera ogni differenza come un riscontro. Assegna a ogni strumento non registrato un proprietario nominato e una data di decisione, decidi se mantenerlo o bloccarlo e registra il risultato. L’uso non autorizzato appare raramente nei registri degli acquisti, motivo per cui shadow AI security deve essere incluso nella prima fase insieme agli strumenti autorizzati.

Applica la stessa attenzione agli strumenti che hai già approvato, poiché approvazione e sicurezza sono questioni separate. Se Copilot è sicuro in un determinato tenant dipende da ciò a cui le sue identità autorizzate possono accedere, e questo inventario risponde a questo.

Considera il passaggio completato quando ogni strumento di IA nell'ambiente appare in un'unica lista, con un proprietario e una mappatura della fonte dati. NIST AI RMF GOVERN 1.6 richiede meccanismi per inventariare i sistemi di IA e assegnare risorse in base alle priorità di rischio organizzativo. Questa lista soddisfa tale requisito. L'artefatto è un inventario convalidato con un elenco allegato di risultati.

2. Testa ogni policy di IA rispetto al ruolo che la applica

Leggi ogni politica di utilizzo dell'IA in base a quattro domande prima di esaminare qualsiasi controllo. Stabilisci quale uso è accettabile, quali tipi di dati sono vietati, dove è richiesta la presenza umana e per quanto tempo vengono conservati i risultati. Scrivi la risposta a ciascuna e segnala ogni domanda lasciata aperta dalla politica.

Quindi crea una mappa a due colonne che posizioni ogni dichiarazione di politica accanto al ruolo nominato responsabile della sua applicazione. Nomina l'individuo, poiché un nome di team non fornisce all'auditor nessuno da intervistare su chi approva un nuovo caso d'uso di AI e chi rivede i risultati nei flussi di lavoro ad alto rischio. Qualsiasi dichiarazione senza un nome allegato è la constatazione.

Estendi la governance che già gestisci invece di scrivere un set parallelo di regole AI. Una IAM risk assessment documenta già i percorsi di approvazione, e un programma consolidato di identity governance and administration definisce già la proprietà dei ruoli. Conferma che si estendono all’uso dell’IA e registra dove finiscono.

GOVERN 2.1 richiede che ruoli, responsabilità e linee di comunicazione per mappare, misurare e gestire il rischio AI siano documentati e chiari per individui e team in tutta l'organizzazione. L'artefatto è quella mappa politica-ruolo, con le dichiarazioni non assegnate elencate come lacune.

3. Mappare l'accesso effettivo per ogni fonte di dati raggiungibile dall'IA

Esegui questo passaggio in quattro fasi, procedendo dalla licenza al file. Per prima cosa, elenca gli utenti e i gruppi che possiedono licenze Copilot. Secondo, risolvi ogni gruppo nella sua reale composizione, inclusi i gruppi nidificati. Terzo, elenca i siti SharePoint, Teams e le cassette postali che contengono dati sensibili e a cui la composizione risolta può accedere.

Il quarto passaggio copre le identità che le persone dimenticano, iniziando dagli ospiti. Gli account ospiti ampliano la mappa più velocemente di qualsiasi altra cosa, quindi verifica Teams guest access contro gli stessi siti sensibili. Poi ripeti l'intero esercizio per le identità non umane, poiché Active Directory service accounts e le registrazioni delle app spesso hanno accessi più ampi di qualsiasi persona in organico.

Inizia la mappatura con il report nativo, quindi verifica cosa è stato tralasciato. Il report di Microsoft "Site permissions for users" elenca i siti SharePoint o OneDrive a cui un utente specificato può accedere, direttamente o tramite gruppi, ed è la vista nativa più vicina per identità.

Prima di considerare quell'output completo, verifica tre limiti nel tuo ambiente. Il report dipende dal organization-wide permissions report, che mostra solo i primi 100 siti per numero di utenti autorizzati ed esclude siti archiviati e siti in stato di blocco NoAccess. I dati possono avere un ritardo fino a 48 ore e ogni tenant è limitato a cinque report aggiornati ogni 30 giorni.

Copri il resto con strumenti che risolvono l'annidamento in tutta l'infrastruttura in un unico passaggio. Questo è il compito di una capacità di data access governance e della categoria più ampia di strumenti di data access governance che esistono per colmare esattamente questa lacuna. Il risultato è un insieme di risultati di accesso per identità con valutazioni del rischio.

4. Dimostrare che il registro può ricostruire un'interazione con l'IA

Verifica il tracciamento scegliendo una recente interazione di Copilot e cercando di ricostruirla solo dai log. Recupera l'accesso, l'evento del prompt, i file modificati e qualsiasi modifica amministrativa alle impostazioni AI, quindi controlla se file access monitoring copre i repository coinvolti. Qualsiasi elemento che non riesci a recuperare va direttamente nella lista dei risultati come una lacuna di copertura.

Conosci il tipo di record che contiene cosa prima di concludere che manca qualcosa. I CopilotInteraction audit records di Purview CopilotInteraction audit records acquisiscono i metadati delle interazioni e i riferimenti ai file che Copilot ha usato per rispondere a una richiesta. Tuttavia, i contenuti di prompt e risposta risiedono nella casella di posta dell'utente e richiedono eDiscovery per essere raccolti.

Next, measure your retention window against the investigation window you'd actually need. Under Microsoft's audit retention policies, Audit (Standard) retains records for 180 days, and Audit (Premium) extends that period to 1 year for Microsoft Entra ID, Exchange, OneDrive, and SharePoint activity generated by users with E5 or equivalent licensing. Anything longer than a year requires the 10-Year Audit Log Retention add-on in addition to E5.

Concludi la fase verificando se i record si collegano effettivamente tra i sistemi. Conferma che il team possa associare un evento AI a un’identità e poi a un record di accesso ai file senza correlazione manuale, e annota eventuali lacune negli strumenti dove la catena si interrompe. L’artefatto è una valutazione della copertura e della conservazione dei log che indica la finestra per carico di lavoro.

5. Eseguire test di controllo da un’identità autorizzata e una non autorizzata

Definisci il test prima di eseguirlo, perché un risultato atteso scritto dopo non ha valore. Scegli un file con un'etichetta di sensibilità nota, un'identità che dovrebbe accedervi e una che dovrebbe essere rifiutata, poi annota il risultato che ti aspetti da ciascuna.

Emetti la stessa richiesta di recupero da entrambe le identità e confronta le due risposte. L'identità autorizzata dovrebbe restituire il contenuto, mentre l'identità limitata dovrebbe rifiutare o restituire un risultato vuoto. Controlla il registro di audit per entrambi i tentativi, perché un fallimento silenzioso che non lascia traccia è una scoperta a sé stante.

Applica a DLP lo stesso trattamento superficie per superficie sullo stesso file di prova. Esegui le policy in modalità simulazione prima di applicarle, e applica le best practice delle policy DLP adatte al tenant. Ripeti ogni caso in chat, in Word e nel riepilogo email, perché una policy valida in uno può comportarsi diversamente in un altro.

Registra l'ambito, l'esito previsto, l'esito effettivo e la correzione per ogni caso, quindi firma i documenti di lavoro e allega gli screenshot e le esportazioni dei log. L'artefatto è un registro di test firmato in cui ogni caso fallito ha un responsabile e una data di retest.

6. Scrivi il rapporto in modo che i risultati si traducano in rimedio

Struttura il report come qualsiasi altro IT risk assessment consegnabile, coprendo ambito, metodologia, risultati, valutazioni del rischio e rimedi. Ordina i risultati per importanza, così il lettore incontra prima la lacuna più grave.

Per ogni osservazione, includere i cinque elementi che un revisore cerca prima di firmare. Il kit di strumenti per la stesura di rapporti dell'IIA raccomanda una valutazione della criticità e una dichiarazione dei fatti che copre condizione, criteri, causa ed effetto, oltre a un piano di azione gestionale che indica l'azione concordata, il personale responsabile e una data di scadenza.

Imposta la prossima data di audit prima di diffondere il rapporto, mentre l’ambito è ancora fresco. Programma l’audit a intervalli pianificati e aggiungi trigger di modifica per nuove funzionalità AI, modifiche ai permessi, revisioni delle policy e modifiche ai log. L’artefatto è quel rapporto, con una data di retest già nel calendario.

Come verificare i controlli di accesso di Microsoft 365 Copilot

Microsoft Copilot ottiene il proprio pass perché le sue barriere di protezione si trovano in superfici amministrative nominate a cui un metodo generico non può fare riferimento, e perché uno di questi controlli viene ritirato. La guida al deployment di Microsoft organizza un rollout in scoprire, classificare, controllare, proteggere, monitorare e governare, con ogni verbo corrispondente a un test con un risultato registrato.

1. Leggi prima la valutazione del rischio dati di Purview

Apri Microsoft Purview Data Security Posture Management (DSPM), vai su Discover e poi su Data risk assessments, e leggi la valutazione predefinita prima di eseguire qualsiasi personalizzazione. Viene eseguito settimanalmente sui primi 100 siti SharePoint per utilizzo, e i primi risultati impiegano circa 4 giorni per apparire in un nuovo tenant.

Considera il risultato come una lista ristretta che necessita ancora di ampliamento, poiché le classifiche di utilizzo e sensibilità vanno in direzioni diverse. Trasferisci tutto ciò che segnala la valutazione nella mappatura per identità del passaggio 3 e mantieni i siti non classificati nel campo di applicazione.

2. Estrai i report di governance degli accessi ai dati di SharePoint

Genera i report di Data Access Governance e analizza i link di condivisione rischiosi, lo stato delle autorizzazioni e l’esposizione Everyone Except External Users (EEEU). Ogni concessione EEEU su un sito che contiene dati regolamentati è una segnalazione, e i link di condivisione anonimi sono quelli da revocare più rapidamente.

Controlla il tuo livello di licenza prima di fidarti della copertura fornita da quei report. Solo E5 offre report sulle attività, limitati a 10.000 siti con 28 giorni di dati. I report snapshot e le azioni di rimedio richiedono SharePoint Advanced Management, che include una licenza Copilot, l’add-on Plan 1 o Microsoft 365 E7.

3. Sostituire la ricerca SharePoint limitata con un controllo supportato

Verifica se il tenant si affida ancora a Restricted SharePoint Search (RSS) per bloccare Copilot, e registra un riscontro di migrazione ovunque lo faccia. Microsoft ha annunciato il ritiro tramite il centro messaggi di Microsoft 365, bloccando la nuova abilitazione di RSS dal 31 luglio 2026 e ritirando completamente la funzione il 31 gennaio 2027.

Pianifica la sostituzione finché c’è ancora tempo, poiché le configurazioni RSS esistenti non verranno migrate automaticamente a Restricted Content Discovery. Fai l’inventario dei siti attualmente protetti da RSS e associa ciascuno a una correzione dei permessi o a una voce di Restricted Content Discovery.

4. Testa le etichette e DLP su ogni superficie di Copilot

Verifica etichette di sensibilità prima sui file di prova, quindi verifica la configurazione Purview DLP in Microsoft 365 Copilot e Copilot Chat. Esegui lo stesso caso in Copilot Chat, in Word e nel riepilogo email, e registra ogni superficie separatamente.

Confronta il risultato con ciò che l'azione della policy effettivamente esegue. L'azione DLP impedisce a Copilot di elaborare contenuti sensibili ma lascia intatto l'accesso dell'utente al file, quindi un utente che apre comunque il documento ha superato il test. Per ogni caso, registra l'identità, il file, il risultato previsto, il risultato effettivo, l'etichetta o la regola DLP applicabile e il timestamp.

5. Esporta le prove e programma la nuova verifica

Esporta i record di audit Purview dell’attività di Copilot per la finestra di test e imposta la conservazione dei log di audit in base al periodo di indagine effettivamente necessario al team. Pianifica Microsoft Entra access reviews per le appartenenze ai gruppi che controllano l’accesso a Teams e al sito, quindi assegna un responsabile a ogni test non superato e programma la data del nuovo test.

Valuta la verifica di Copilot rispetto a un singolo standard concreto anziché a una checklist di impostazioni esaminate. Il team la supera quando può nominare un file, dimostrare che Copilot non lo riassumerà sotto un'identità limitata, spiegare quale permesso, etichetta o regola DLP lo ha bloccato e produrre il record Purview che prova che il test è avvenuto.

Elenco di controllo per prove e preparazione per un audit di governance AI

Un audit di accesso ai dati AI si basa su artefatti che un revisore può ispezionare. Quattro categorie hanno il peso maggiore:

• Prova di inventario: L'elenco dei sistemi e degli strumenti AI con proprietari e ambienti, più la documentazione delle fonti dati raggiungibili da ciascun sistema
• Prove di policy e controllo: Politiche d’uso con registri delle modifiche, definizioni dei ruoli e una matrice responsible, accountable, consulted e informed (RACI) per la governance dell’IA, e una valutazione del rischio per ogni caso d’uso IA
• Prove di Identity, accesso e monitoraggio: Rapporti di accesso per identità, registri delle attività AI e registrazioni di eventi di controllo come attivazioni DLP, decisioni di Conditional Access e risultati delle revisioni degli accessi
• Prove di revisione e supervisione: Verbali o ticket che documentano le decisioni di governance dell'IA, una traccia di audit delle azioni correttive dopo valutazioni precedenti e metriche che monitorano le prestazioni della governance nel tempo

Se ne manca anche solo uno dei quattro, quello è il punto debole che un revisore trova per primo. Le domande di preparazione qui sotto testano lo stesso ambito da un’altra prospettiva, e ogni domanda senza risposta rappresenta una lacuna che necessita di un responsabile, un piano di rimedio e una data per un nuovo test.

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

Quattro dei passaggi sopra si basano su dati che gli strumenti nativi trattengono brevemente o distribuiscono tra i portali, coprendo permessi effettivi, registri delle attività AI, applicazione a livello di prompt e cronologia delle modifiche.

Netwrix raggruppa quelli sotto AI governance come una capacità di piattaforma nominata per ambienti Microsoft ibridi, e un prodotto diverso gestisce ogni compito.

Reportare ciò che Copilot può raggiungere, prima e dopo il rollout

Netwrix 1Secure fornisce report sui dati sensibili a cui Copilot può accedere prima che un tenant lo abiliti, rispondendo così alla domanda sulla preparazione mentre il rollout è ancora reversibile. Dopo il go-live, elenca utenti, timestamp e risorse referenziate per ogni interazione, e segnala le risposte di Copilot che espongono dati sensibili.

La copertura include SharePoint Online, server di file Windows, Active Directory, Microsoft Entra ID e Exchange Online, quindi la traccia di log richiesta al passaggio 4 proviene da un'unica console.

Calcolo delle autorizzazioni effettive dietro ogni identità

Netwrix Access Analyzer risolve l’appartenenza annidata ai gruppi AD e l’eredità interrotta di SharePoint per calcolare a cosa può effettivamente accedere ogni identità, evidenziando accessi aperti e diritti obsoleti che i report per sito appiattiscono. Questo trasforma la mappatura a quattro passaggi del passo 3 in un report da consegnare a un revisore.

La valutazione di Microsoft 365 Copilot readiness esegue la stessa analisi prima della distribuzione, così i contenuti con permessi eccessivi vengono corretti prima che un utente riceva una notifica.

Blocco dei dati sensibili nei prompt AI all'endpoint

Netwrix Endpoint Protector esamina il contenuto del prompt sull'endpoint e blocca i dati sensibili prima che raggiungano ChatGPT, Microsoft Copilot, Google Gemini, Claude o DeepSeek. Ogni evento bloccato è collegato all'identità dietro di esso, trasformando una regola scritta sui dati proibiti in qualcosa che il passo 5 può testare.

Conservare le prove delle modifiche oltre la finestra di registro nativa

Netwrix Auditor registra ogni configurazione e modifica della directory di AD e Entra ID con valori prima e dopo in una traccia ricercabile. Conserva questi valori in un Archivio a Lungo Termine che ha un valore predefinito di 120 mesi, ben oltre la finestra standard di 180 giorni di Purview.

Due clienti regolamentati mostrano il valore di quella traccia conservata durante un esame. First National Bank e Trust of Beloit mantengono la conformità continua OCC per 300 utenti in 17 sedi con Netwrix Auditor, sostituendo il lavoro manuale delle checklist che una volta richiedeva una settimana intera con un’ora di preparazione. Flagler Bank identifica e mitiga il rischio IT su tutta la rete con un reparto IT di una sola persona, chiudendo le indagini in 10 minuti che la ricerca manuale dei log allungava per ore.

Netwrix segnala l'accesso ai dati AI e lo blocca all'endpoint. Lo strato di applicazione di Microsoft determina ancora cosa può fare un'identità all'interno di Microsoft 365 tramite etichette di sensibilità, Purview DLP e Accesso Condizionale. La verifica controlla tali controlli e il comportamento del modello rimane con i team di data science e rischio modello.

Richiedi una demo per mappare quali identità può raggiungere Copilot, monitorare cosa emerge dopo il rollout e conservare le prove delle modifiche richieste dall’esaminatore.