Creare un agente AI per la GRC con Microsoft Purview, Power Automate e Copilot Studio: report di conformità automatici

Governance, rischio e conformità (GRC) consumano più caffè di tutti gli audit messi insieme. In molte organizzazioni c'è ancora un analista che copia i log di audit in Excel cella per cella, tra filtri, tabelle pivot e grafici che dopo una settimana non corrispondono più ai dati. Il risultato è una documentazione molto curata, ma non un'analisi.

Esiste un'alternativa: un agente GRC basato su regole, costruito interamente con strumenti Microsoft. Microsoft Purview fornisce i dati, Power Automate orchestra il processo e Copilot Studio trasforma i risultati in report leggibili. In questo articolo vediamo come funziona, dalla pipeline di dati alla pubblicazione automatica dei report di conformità.

Perché il reporting GRC manuale non regge

Il report manuale nasce da un equivoco: scambiare la documentazione per l'analisi. Si estraggono i dati da Microsoft Purview, si esportano, si distribuiscono su fogli di calcolo e si chiama il risultato «governance». Alla prima nuova attività i dati cambiano e i grafici diventano obsoleti. Le tracce di audit, che dovrebbero rafforzare la responsabilità, finiscono per produrre burnout.

Il problema di fondo è che molte aziende usano Purview come una cassaforte da aprire solo prima di un audit. Eppure i suoi log registrano in silenzio chi ha fatto cosa, dove e quando. I dati sono utili, ma poco leggibili: ogni voce contiene un blocco JSON così fitto da risultare quasi impenetrabile. L'abbondanza di dati si accompagna a una leggibilità vicina a zero.

Che cos'è davvero un agente GRC

Lasciamo da parte il fascino dell'intelligenza artificiale. L'agente GRC è un'automazione strutturata, costruita sullo stack Microsoft, che produce sintesi comprensibili. Non è un copilota magico che indovina le risposte, ma un sistema deterministico: logica, frequenza, ambito e perfino il tono del linguaggio li definisci tu. Si compone di tre parti.

• Microsoft Purview è la memoria grezza: log di audit, dati di classificazione ed eventi di conformità. Ogni azione utente in Microsoft 365, dalla condivisione di un documento alla creazione di una policy, viene registrata.
• Power Automate è il sistema nervoso: raccoglie i segnali, filtra il rumore e garantisce che il processo rispetti la pianificazione.
• Copilot Studio è la voce: traduce il gergo tecnico dei log in sintesi leggibili dalle persone.

Il punto di forza è il riconoscimento di schemi. Gran parte del lavoro di conformità non richiede giudizio ma individuazione di pattern, e questo l'automazione lo fa meglio di una persona che scorre colonne di tipi di attività e stati. A differenza di una dashboard, che mostra ma non spiega, l'agente scrive: traduce gli schemi in frasi e riduce il divario interpretativo che nelle revisioni di conformità può far sfuggire problemi importanti.

Costruire la pipeline di dati da Microsoft Purview

Prima di pensare, l'agente deve vedere. Serve quindi una pipeline che gli dia accesso alle giuste porzioni dei log di audit, né più né meno. Senza questa visibilità si automatizza la cecità.

Connessione e ambito

Si può partire dal connettore integrato di Purview oppure da un'azione HTTP che richiama direttamente l'API dei log di audit. Entrambe le strade danno lo stesso risultato: un flusso di eventi che comprende condivisioni di file, modifiche ai permessi, violazioni di accesso e accessi degli amministratori. L'approccio più disciplinato è limitare l'ambito fin dall'inizio. Estrarre l'intero feed di audit sarebbe come fare il backup di tutto internet perché si è perso un PDF. Definisci quindi gli eventi rilevanti per la conformità.

Permessi e autenticazione

Power Automate agisce solo entro i permessi che riceve. Il service account del flusso deve avere il ruolo di lettore dei log di audit in Purview e deve potersi autenticare senza interruzioni dovute a MFA, perché l'automazione non cliccherà per confermare l'accesso né risponderà a un prompt alle due di notte. Conserva le credenziali con cura nei riferimenti di connessione: così resti conforme e l'automazione resta attiva.

Filtrare ciò che conta

A nessun revisore serve ogni accesso ai file della cartella della mensa. Filtra invece per indicatori di rischio reale:

• accesso utente da una nuova posizione;
• modifica dell'assegnazione di ruolo;
• condivisione esterna attivata;
• modifica di una policy di etichettatura.

Puoi filtrare già nella query, con i parametri dell'API, oppure dentro Power Automate con la logica condizionale. In entrambi i casi non stai accumulando dati, ma selezionando.

Dal JSON alle colonne strutturate

Qui si separa l'automazione vera dal semplice copia e incolla. Con l'azione Parse JSON e uno schema ricavato da un evento di esempio di Purview, ogni proprietà (ID utente, operazione, carico di lavoro, stato del risultato, IP del client) diventa una variabile. Stai insegnando all'agente il vocabolario prima che inizi a parlare.

I formati dati di Microsoft riservano qualche sorpresa: certi campi compaiono come array anche con un solo valore, altri nascondono i risultati sotto tre livelli di nidificazione. Power Automate gestisce questo caos con le espressioni, ma un piccolo errore di battitura produce assurdità in seguito. Per questo conviene testare ogni estrazione con piccole esecuzioni di prova.

Archivio e pianificazione

I dati puliti possono essere conservati in SharePoint, Dataverse o in un database SQL, a seconda del peso dei report. L'archivio funge da memoria a breve termine e permette confronti storici senza interrogare Purview ogni volta. Dataverse si integra meglio con Power Automate quando servono funzionalità colonnari o relazioni tra insiemi di dati; SharePoint è più semplice, ma diventa macchinoso oltre qualche migliaio di righe.

Per la cadenza si usa il trigger di ricorrenza: riepiloghi giornalieri per ambienti dinamici, settimanali per sistemi più tranquilli. Imposta il tuo fuso orario e non UTC, a meno che tu non voglia chiederti perché i report arrivano alle 3 del mattino.

Il livello logico: far decidere il flusso con Power Automate

Power Automate non sogna e non allucina rischi di conformità: obbedisce. Questa rigidità prevedibile è esattamente ciò che serve all'autonomia. La catena parte dal trigger di ricorrenza, seguito da un blocco di inizializzazione con variabili di ambiente, contatori e array. Variabili come totale eventi, conteggio dei rischi elevati e data del report diventano la memoria di lavoro dell'agente.

Dopo la chiamata al connettore dei log di audit o all'API HTTP, i dati grezzi vanno ripuliti:

1. un'azione Filtra matrice elimina il rumore, per esempio i record in cui l'utente è un'entità di servizio, conservando solo le operazioni legate alla governance dei dati o ai cambi di policy;
2. i duplicati, frequenti nei flussi di log, si rimuovono con un'espressione di unione;
3. i record rimanenti vengono raggruppati per utente e operazione, e i conteggi si sommano con cicli Applica a ciascuno.

Alla fine l'agente ha un'istantanea: chi ha fatto cosa, quanto spesso e se sono stati raggiunti i limiti di rischio predefiniti.

Soglie e livelli di rischio

Il segreto dell'autonomia è lasciare che il sistema deduca il livello di rischio dalle soglie che definisci tu. Ad esempio: con tre escalation di privilegi il rischio è alto; con una condivisione esterna è medio; altrimenti è normale. La logica non inventa significato, lo applica. Con le azioni condizionali gli utenti ad alto rischio finiscono in una matrice dedicata e quelli a rischio medio possono essere messi in coda per una revisione. Se non emerge nulla di insolito, il flusso registra un messaggio di «nessun risultato» invece di restare in silenzio: nella conformità la differenza tra dati mancanti e assenza di dati è fondamentale.

Gestione degli errori e tracciabilità

Le chiamate HTTP vanno racchiuse in un contenitore di ambito con policy di ripetizione, ad esempio tre tentativi con backoff esponenziale. Nel ramo di errore si registrano messaggio, timestamp e ID di esecuzione in una lista SharePoint o in una tabella Dataverse, per esempio chiamata «stato automazione». Se il limite di richieste di Purview viene superato, puoi anche inviare un messaggio su Teams. L'errore va trattato come dato, non come dramma: i revisori non penalizzano gli errori, penalizzano la mancanza di documentazione su di essi.

Ogni esecuzione dovrebbe lasciare una prova: totale degli eventi elaborati, utente a maggior rischio, durata. Aggiungendo ID di esecuzione e versione del file, i revisori potranno sempre ricostruire quale logica ha prodotto quale risultato, anche dopo un cambio di soglie.

Copilot Studio: insegnare all'agente a scrivere

Finora l'agente è efficiente ma muto. Copilot Studio gli dà voce: riceve il riepilogo strutturato prodotto da Power Automate (azioni degli utenti, conteggi di rischio, registro degli eventi) e lo trasforma in paragrafi adatti ai dirigenti e precisi per i revisori. Non inventa nulla: segue le regole incorporate nel prompt che hai progettato.

Tre tipi di comunicazione

Conviene definire in anticipo che cosa produrre. Di solito ci sono tre output, ciascuno per un diverso livello di competenza:

• un riepilogo esecutivo, perché il management vuole un solo paragrafo;
• un'appendice tecnica, con ogni evento ad alto rischio in formato tabella, per revisori e personale IT;
• le raccomandazioni, con un rimedio suggerito per ogni rilievo.

Si crea un'unica esperienza in Copilot Studio con più prompt, ciascuno con il proprio tono, formato e livello di dettaglio. Un esempio: riassumere i rischi principali in linguaggio semplice, al massimo cinque punti elenco, con un rimedio per ciascuno.

Collegare il flusso al Copilot

Il collegamento avviene con un'azione HTTP nel flusso, che invia il payload JSON strutturato all'URL dell'endpoint del Copilot. La chiamata viene autenticata tramite Azure AD, così solo il tuo flusso può accedervi. Il testo restituito è il report. Il risultato assomiglia a un promemoria d'analista: quali utenti hanno mostrato comportamenti a rischio, quale soglia è stata superata, quale azione si raccomanda e qual è la tendenza generale.

Prompt con paletti precisi

Un prompt ben progettato specifica le intestazioni esatte da usare, per esempio Panoramica, Risultati chiave e Raccomandazioni. Include direttive come tono professionale e neutro, nessun linguaggio speculativo, metriche quantificabili. Senza indicazioni, Copilot tende a impressionare con stile narrativo o emoji, e un report di audit pieno di emoji difficilmente convince un revisore. Più le istruzioni sono precise, più l'output è riproducibile, e la conformità si basa sulla riproducibilità, non sulla personalità.

Le variabili di contesto permettono inoltre di inserire nel testo dati dinamici come la data del report o il numero di eventi analizzati. Questi metadati soddisfano i revisori più di qualunque abbellimento grafico.

Distribuzione e validazione

Nessuno dovrebbe accedere a Dataverse per cercare i report. Il flusso si divide quindi in due rami: uno pubblica il riepilogo in un canale Teams, l'altro salva una versione HTML completa su SharePoint. Il management legge il messaggio, i revisori consultano l'archivio, entrambi con timestamp automatico e formulazione identica.

Come ultimo controllo, una condizione verifica che la risposta di Copilot non sia vuota; in caso contrario l'errore finisce nel registro. Il flusso completo diventa: estrai, analizza, riassumi, esponi, pubblica. Infine, versiona il prompt di sistema (V1, 1.1 e così via) e registra quale versione ha generato quale report: le revisioni future potranno così verificare anche come era istruito il modello narrativo in quel momento.

Errori comuni e insidie da evitare

• Permessi mancanti. Durante il primo test l'agente aveva segnalato con orgoglio zero problemi, una conformità apparentemente perfetta. In realtà all'account di servizio mancava il ruolo di lettore dei log di audit: l'agente non era pigro, era obbedientemente cieco.
• Estrazione senza ambito. Prelevare tutto il feed di audit sovraccarica il flusso e le tue risorse. Definisci prima gli eventi che contano.
• Autenticazione interattiva. MFA o richieste manuali bloccano un'automazione che non può rispondere.
• Errori di schema e di espressione. Array e nidificazioni nel JSON causano risultati assurdi se non si testa ogni estrazione.
• Fuso orario sbagliato. Un trigger impostato su UTC può generare report in orari poco sensati.
• Silenzio al posto del «nessun risultato». Non distinguere tra assenza di dati e dati mancanti compromette l'affidabilità del report.
• Prompt troppo liberi. Senza intestazioni e vincoli di tono, l'output varia e perde valore di audit.
• Errori non documentati. Un fallimento tracciato è accettabile, uno nascosto no.

Punti chiave e conclusione

• Usa Purview come fonte di verità, Power Automate come orchestratore e Copilot Studio come strato linguistico.
• Limita l'ambito degli eventi e filtra per indicatori di rischio reali.
• Assegna al service account il ruolo di lettore dei log di audit e assicurati che possa autenticarsi senza interazione.
• Converti il JSON in campi strutturati con Parse JSON e testa ogni estrazione.
• Archivia i dati in SharePoint, Dataverse o SQL per avere un confronto storico.
• Pianifica con il trigger di ricorrenza nel fuso orario corretto.
• Definisci soglie esplicite per i livelli di rischio e gestisci anche il caso «nessun risultato».
• Prevedi policy di ripetizione, log degli errori e notifiche su Teams.
• Vincola i prompt di Copilot con intestazioni, tono e metriche, e versionali.
• Pubblica su Teams e SharePoint, convalidando che la risposta non sia vuota.

Un agente GRC costruito con Microsoft Purview, Power Automate e Copilot Studio trasforma la conformità da sprint pre-audit a battito continuo. Purview raccoglie, Power Automate interpreta, Copilot riassume. Il vantaggio principale non è la velocità ma la standardizzazione: ogni report ha lo stesso tono, usa le stesse soglie e registra gli stessi metadati, così i revisori possono concentrarsi sulla sostanza invece di verificare il formato. Il passo successivo naturale è estendere la stessa logica all'applicazione della privacy dei dati.