Come scrivere una politica di governance dell'IA (+ cosa includere)

Solo l'11% delle organizzazioni è completamente pronta per la sicurezza dell'IA, secondo The Netwrix 2026 Data and Identity Security Report.

L'adozione dell'IA nella maggior parte delle organizzazioni è avvenuta tramite scelte individuali di strumenti prima che le revisioni di sicurezza si aggiornassero: i dipendenti hanno collegato Microsoft Copilot, ChatGPT e dozzine di funzionalità AI integrate al loro lavoro quotidiano prima che qualcuno scrivesse regole di accesso che regolassero cosa potevano accedere quegli strumenti.

Quel rischio persiste perché l’accesso AI segue un modello di revisione diverso rispetto alle normali richieste degli utenti. Questi strumenti e le identità degli agenti dietro di essi possono ereditare permessi, interrogare contenuti sensibili e creare nuove domande di audit più rapidamente di quanto la revisione manuale possa catalogarle.

I team di sicurezza hanno bisogno di visibilità sugli strumenti esistenti, quali dati possono accedere, chi li ha approvati e come i team gestiscono le eccezioni. Una politica scritta colma questa lacuna definendo cosa può toccare l’AI prima che un incidente ponga la domanda, rafforzando la resilienza informatica e mantenendo responsabile l’adozione dell’AI.

Cos'è una politica di governance dell'IA?

Una politica di governance dell'IA è il documento che definisce le regole su come i dipendenti, i collaboratori e i fornitori di un'organizzazione possono utilizzare gli strumenti di IA: quali dati possono accedere tali strumenti, quali strumenti l'organizzazione approva e come i team gestiscono le violazioni.

I team spesso usano "governance dell'IA" e "politica dell'IA" in modo intercambiabile, ma descrivono livelli diversi dello stesso problema, e la distinzione determina chi è responsabile di cosa.

Un framework di governance dell'IA è il programma più ampio e continuo all'interno del quale opera la policy: i ruoli, i cicli di revisione e gli strumenti che mantengono la policy aggiornata. Framework di riferimento esterni, come il NIST AI Risk Management Framework (AI RMF) e ISO/IEC 42001, forniscono la struttura del framework, mentre la policy traduce quella struttura in regole che il tuo team può seguire.

Quali sono esempi di politiche di governance dell'IA?

I principi astratti sono facili da condividere e difficili da implementare. Le politiche di riferimento di software aziendale, sanità, servizi finanziari e appalti per la difesa mostrano come i requisiti cambino in base al tipo di dati e alla normativa.

Policy di accesso ai dati per Enterprise Copilot e modelli di linguaggio di grandi dimensioni (LLM)

Questi sono gli analoghi più vicini a ciò che la maggior parte dei team di sicurezza di mercato medio deve scrivere, a parte eventuali regolamenti specifici del settore da seguire. Si concentrano su regole di accesso ai dati legate a una categoria di strumenti specifica già in uso, come Microsoft 365 Copilot o ChatGPT, che mantiene l'applicazione ancorata a flussi di lavoro reali. Queste politiche spesso abbinano etichette di sensibilità con un modello operativo che separa la proprietà della tassonomia dall'applicazione tecnica.

Politiche di governance dell'IA sanitaria

Le organizzazioni sanitarie costruiscono queste politiche intorno all'Health Insurance Portability and Accountability Act (HIPAA), separando l'uso clinico dell'IA (strumenti diagnostici o rivolti ai pazienti, soggetti alle regole più severe di accesso e audit) dall'uso amministrativo dell'IA (programmazione, fatturazione, documentazione interna), poiché i due comportano livelli di rischio differenti sotto la stessa regolamentazione. Una clausola definitoria in una politica modello: le organizzazioni possono inserire informazioni sanitarie protette (PHI) in uno strumento di IA solo quando il fornitore ha eseguito un Business Associate Agreement.

Politiche di governance dell'IA per servizi finanziari e appaltatori della difesa

Questi si basano sui framework specifici che li guidano: i servizi finanziari includono Service Organization Control 2 (SOC 2), il Regolamento Generale sulla Protezione dei Dati (GDPR) e il Digital Operational Resilience Act (DORA), mentre gli appalti per la difesa includono la Cybersecurity Maturity Model Certification (CMMC). Entrambi collegano i livelli di rischio direttamente al fatto che uno strumento di IA tocchi dati finanziari dei clienti o informazioni non classificate controllate (CUI).

Le politiche di difesa vanno oltre: secondo le linee guida dell'Information Security Oversight Office (ISOO), i contraenti non possono inserire CUI in strumenti di IA pubblici o consumer, e qualsiasi strumento di IA che elabori CUI deve essere incluso nel Piano di Sicurezza del Sistema del contraente.

Usa questi esempi per ancorare la tua politica negli strumenti, tipi di dati e obblighi di conformità che la tua organizzazione ha effettivamente.

Perché una politica di governance dell'IA è importante

Una politica scritta fornisce all’adozione dell’IA un modello di governance che i team di sicurezza possono misurare, applicare e migliorare. Trasforma inoltre l’approvazione degli strumenti, l’accesso ai dati, il monitoraggio e l’escalation in prove verificabili.

L’adozione dell’IA espande la superficie di attacco più rapidamente di quanto la sicurezza possa valutarla

Ogni nuova funzione di Copilot, ChatGPT o IA integrata necessita di accesso ai dati organizzativi, e ciascuna crea un nuovo percorso di accesso da governare. Il Netwrix 2026 Data and Identity Security Report ha rilevato che il 76% non governa o monitora completamente le identità non umane nei propri ambienti, quindi la maggior parte dell'adozione degli strumenti di IA avviene senza visibilità continua.

I quadri normativi stanno passando da linee guida volontarie all’applicazione

Gli obblighi di valutazione della conformità del EU AI Act per i sistemi ad alto rischio si applicano generalmente dal 2 agosto 2026, con i sistemi ad alto rischio coperti dalla legislazione sui prodotti dell'Allegato I a partire dal 2 agosto 2027. Una politica documentata aiuta a dimostrare che l'organizzazione ha seguito il requisito prima che diventasse obbligatorio. Aspettare che un regolamento diventi vincolante prima di scrivere qualcosa non lascia prove di un impegno in buona fede.

Auditor e consigli ora si aspettano una politica documentata

Quando la leadership chiede, "Siamo sicuri con AI?", una politica scritta è la prova che la risposta è più di un'opinione. Una garanzia verbale crolla durante un audit o una revisione degli incidenti. La politica traduce una postura di sicurezza in qualcosa che un auditor può leggere e a cui un consiglio può fare riferimento, in linea con l'aspettativa formalizzata in ISO/IEC 42001.

Il principio del minimo privilegio si applica agli strumenti di IA solo quando una policy definisce il loro accesso

I team di sicurezza hanno passato anni a limitare l'accesso umano in base al ruolo. I team spesso esentano gli strumenti di IA da questa stessa disciplina per impostazione predefinita, trattandoli come estensioni dell'umano che li ha implementati o come account di servizio generici. Identity guidance scoraggia entrambi gli approcci perché least privilege richiede accesso limitato e responsabile. Una policy definisce gli strumenti di IA come una propria classe di account, soggetta a limiti di accesso reali.

Le organizzazioni senza uno lo stanno già pagando

Il Report sulla Sicurezza dei Dati e dell'Identity 2026 di Netwrix ha rilevato che il 72% delle organizzazioni afferma che il rischio legato all'identity per i dati sensibili è aumentato negli ultimi due anni a causa di AI e automazione. Il divario nelle policy è già evidente nei dati di rischio, e le organizzazioni che lo segnalano sono quelle che adottano l'AI più rapidamente.

Cosa includere in una politica di governance dell'IA

Una policy utilizzabile necessita di clausole che sicurezza, legale, IT e proprietari dei dati possano tradurre in decisioni su approvazione e accesso. Ogni clausola dovrebbe collegare una dichiarazione di policy al proprietario, strumento, categoria di dati o controllo che la rende applicabile.

• Ambito e applicabilità: Definisce chi copre la policy e a cosa si applica, inclusi dipendenti, appaltatori, fornitori e strumenti shadow AI già in uso. Senza un ambito esplicito, la policy regola solo gli strumenti già noti, lasciando il resto non regolamentato.
• Ruoli di governance e comitato direttivo: Nomi di chi possiede la policy e a chi rivolgersi quando qualcosa esce da essa. Senza un proprietario nominato, "l'applicazione della policy" spetta a chi nota il problema per primo.
• Classificazione del rischio: Classifica i casi d’uso dell’IA in basso, medio e alto rischio in base ai dati o alle decisioni coinvolte. Senza livelli, ogni caso d’uso dell’IA riceve lo stesso livello di controllo, quindi quelli ad alto rischio sono poco esaminati e quelli a basso rischio creano attriti inutili.
• Regole di accesso e utilizzo dei dati: Specifica quali dati ogni livello di rischio dello strumento AI può e non può accedere. È la clausola che trasforma una dichiarazione di valori in un controllo applicabile. Senza di essa, "uso responsabile dell'AI" non ha significato tecnico.
• Processo di revisione degli strumenti e dei fornitori approvati: Definisce come i responsabili della sicurezza, legali e dei dati valutano e approvano un nuovo strumento di IA prima che venga collegato ai dati aziendali. Senza questo, l’adozione dello strumento avviene da chi lo ha trovato per primo, anziché tramite una revisione di sicurezza.
• Requisiti di monitoraggio e audit: Definisce come l'organizzazione verifica che i team seguano la politica nella pratica. Una politica che nessuno verifica nella realtà esiste solo sulla carta.
• Risposta e escalation degli incidenti: Definisce cosa accade quando uno strumento di IA causa o rivela un problema di sicurezza o conformità. Senza questo, i team gestiscono un incidente legato all’IA in modo ad hoc, con il playbook sbagliato o troppo tardi.
• Allineamento normativo: Mappa la policy ai framework applicabili, inclusi NIST AI RMF, ISO/IEC 42001 e il EU AI Act. Ciò consente a una singola policy di soddisfare più obblighi di conformità invece di richiedere un documento separato per ogni regolamento.
• Rivedi e aggiorna la cadenza: Impegnati a riesaminare la policy secondo un calendario prestabilito e dopo eventi importanti, come nuove categorie di strumenti, cambiamenti normativi o incidenti. Gli strumenti di IA cambiano più rapidamente rispetto alla maggior parte dei cicli di revisione delle policy, quindi una policy senza cadenza diventa obsoleta in pochi mesi.

Come scrivere una politica di governance dell'IA che bilanci adozione e responsabilità

La leadership vuole che l’adozione dell’IA proceda rapidamente; la sicurezza si assume le conseguenze se si agisce con superficialità. Scrivi la policy nell’ordine in cui i team di sicurezza necessitano delle prove: prima i proprietari, poi gli strumenti e i flussi di dati, quindi i livelli di rischio, le regole di accesso, la mappatura normativa e la cadenza delle revisioni. Le regole di accesso scritte prima dell’inventario di solito non considerano gli strumenti che già creano esposizione.

1. Forma un team di governance trasversale prima di scrivere una parola

Inizia nominando i ruoli effettivi: un responsabile della sicurezza delle informazioni o di Identity and Access Management (IAM) per gestire l’applicazione, legale e conformità per il linguaggio normativo, un proprietario IT o dei dati che conosca dove risiedono i dati sensibili, un rappresentante dell’unità aziendale che utilizza strumenti di IA quotidianamente e uno sponsor esecutivo che può approvare le eccezioni.

Scegli il presidente in base al ruolo che ha già l'autorità per vincolare le unità di business al di fuori della sicurezza, non solo al suo interno. Nelle organizzazioni guidate dalla sicurezza, questo è il CISO. Nelle organizzazioni orientate al rischio, è invece un dirigente senior del rischio, perché le unità di business rispondono già a quel ruolo per il rischio aziendale, e la governance dell'IA necessita della stessa autorità o quelle unità la considereranno opzionale.

Limitalo a una persona per ruolo, con un secondo solo quando il carico di lavoro lo richiede. Se la sicurezza scrive la policy da sola, sembra un documento di sicurezza e potrebbe mancare dell’autorità per governare le unità di business che generano il rischio.

2. Fai l'inventario degli strumenti di IA e dei flussi di dati che hai già, inclusa la shadow AI

Crea l'inventario da quattro fonti contemporaneamente: spesa SaaS, registri di approvvigionamento, estensione del browser, audit delle concessioni Open Authorization (OAuth) e un sondaggio diretto alle unità aziendali.

Confronta tutti e quattro, perché i dipendenti omettono abitualmente strumenti che considerano "solo un assistente di scrittura" e i registri degli acquisti non includono spese individuali. Le sottoscrizioni individuali possono sfuggire alle soglie di approvazione e le revisioni delle spese possono non rilevare i livelli di IA inclusi nei contratti SaaS esistenti.

Per Microsoft 365, elenca le applicazioni aziendali e i service principal in Entra ID e segnala quelli che hanno permessi delegati o applicativi di Microsoft Graph, poiché ogni concessione è un percorso di accesso che gli strumenti di IA possono utilizzare.

Le verifiche delle concessioni di consenso OAuth e i passaggi di risoluzione di Microsoft per concessioni di consenso illecite aiutano a individuare e ripulire autorizzazioni rischiose. Registra lo scopo di ogni strumento, il proprietario aziendale e i dati coinvolti in un inventario dei sistemi AI mentre procedi.

3. Classifica i casi d'uso dell'IA per livello di rischio

Classifica ogni caso d'uso su due criteri insieme:

1. Quali dati tocca lo strumento (pubblici, interni, regolamentati o informazioni personali identificabili (PII)).
2. Cosa fa con quei dati (li riassume e li visualizza, informa una decisione aziendale o agisce autonomamente).

Uno strumento che riscrive solo i testi pubblici di marketing è a basso rischio, indipendentemente dalla sua sofisticazione. Uno strumento che estrae i dati dei clienti per rispondere ai ticket di supporto è ad alto rischio anche se il suo output sembra routine.

Uno strumento autonomo che esegue transazioni o modifica la produzione si trova al livello più alto e richiede l'approvazione umana obbligatoria. Se operi nell'UE, sovrapponi questi livelli interni alle categorie del EU AI Act in modo che entrambi gli schemi rimangano visibili.

4. Definisci quali dati ogni livello di rischio può e non può accedere

Scrivi ogni regola di accesso come una mappatura diretta dal livello di rischio alla categoria di dati. Gli strumenti a basso rischio accedono a contenuti non sensibili già pubblici. Gli strumenti a rischio medio sono limitati ad accedere a set di dati specifici già classificati. Gli strumenti ad alto rischio richiedono approvazione scritta esplicita, registrazione degli accessi e un revisore umano nominato prima del deployment.

Per i dati regolamentati, indica esplicitamente la condizione: PHI richiede un Accordo di Collaborazione commerciale firmato e CUI non può essere inserito in alcuno strumento al di fuori di un ambiente accreditato.

5. Definisci l'escalation e la risposta agli incidenti prima di pubblicare

Definisci cosa succede quando uno strumento di IA causa o rivela un problema di sicurezza o conformità: chi viene notificato, con quale rapidità e quale processo di risposta agli incidenti esistente interviene. Collega il percorso di escalation ai ruoli di governance nominati nel passaggio 1, così che il problema abbia un responsabile specifico invece di affidarsi a chi lo nota per primo.

Senza questo passaggio scritto, i team finiscono per gestire un incidente legato all’IA in modo improvvisato, con il playbook sbagliato o troppo tardi, proprio il gap che una policy dovrebbe colmare prima che un incidente ponga la questione.

6. Mappa la tua policy ai framework normativi applicabili

Una matrice di controllo può servire a tutti i framework che utilizzi. Allinea le quattro funzioni di AI RMF (Govern, Map, Measure, and Manage) alle clausole del sistema di gestione ISO/IEC 42001 e ai livelli di rischio dell'AI Act, quindi scrivi una sola volta il linguaggio della policy per quella matrice combinata.

I due standard si completano a vicenda: il NIST AI RMF fornisce le azioni di gestione del rischio operativo, mentre ISO/IEC 42001 fornisce l'architettura di governance e la traccia di audit. Usare lo stesso linguaggio di controllo in questi framework riduce la documentazione duplicata per ogni obbligo che hai.

7. Imposta una cadenza di revisione prima di pubblicare

Impegnarsi a un intervallo specifico, almeno annuale, più trigger nominati che obbligano a una revisione fuori ciclo: adozione di una nuova categoria di strumenti AI, un cambiamento normativo, un incidente o un’acquisizione o riorganizzazione, inclusi cambiamenti importanti nei processi aziendali e nei requisiti di dati correlati.

Adatta la cadenza al rischio, con i team che revisionano i sistemi a rischio più elevato più spesso e il comitato di governance che si riunisce con una cadenza ricorrente comunque. Scrivi la cadenza, i trigger e il responsabile nel documento stesso. Un programma di revisione che esiste solo nella mente di qualcuno decade non appena quella persona cambia ruolo.

Come applicare una policy di governance dell'IA nella pratica

Le clausole della policy necessitano di controlli tecnici che la sicurezza possa verificare. “La policy dice no” conta solo quando visibilità, revisione degli accessi, avvisi e revoca rendono vera quella risposta.

Ottieni piena visibilità su ciò a cui i tuoi strumenti di AI possono effettivamente accedere

L'applicazione inizia con una mappa live delle connessioni tra strumenti AI e dati: concessioni OAuth, Microsoft 365 e Microsoft Entra ID autorizzazioni, estensioni del browser e qualsiasi funzione AI integrata nelle piattaforme SaaS esistenti.

Chiudere la porta principale allo stesso tempo: disabilitare il consenso dell’utente per le applicazioni non verificate e indirizzare le nuove richieste tramite il flusso di lavoro del consenso amministrativo, in modo che le nuove integrazioni AI entrino di default nel processo di revisione.

I team di sicurezza di solito possono rispondere "chi ha accesso a cosa" per gli account umani; questo passaggio costruisce la risposta equivalente per strumenti e agenti AI, inclusi permessi effettivi che derivano da gruppi nidificati e accessi ereditati.

Gli strumenti nativi di Microsoft aiutano qui, anche se Purview DSPM for AI esegue la sua valutazione automatica del rischio solo sui primi 100 siti SharePoint, quindi una vista più ampia della data security posture aiuta a convalidare l'immagine nativa e identificare le lacune.

Per Copilot in particolare, abbina le etichette di sensibilità con le restrizioni di accesso al sito SharePoint e Restricted Content Discovery in modo che la condivisione eccessiva non raggiunga mai i dati di base da cui Copilot attinge.

Applica il principio del minimo privilegio per l'IA allo stesso modo in cui lo fai per le persone

Tratta le identità degli strumenti AI e identità degli agenti come una propria classe di account, soggette alla stessa revisione degli accessi e al flusso di lavoro di attestazione già utilizzato per gli account umani. Richiedi accesso limitato e a scadenza invece di permessi ampi e permanenti ed esegui il processo di ingresso, spostamento e uscita che regola anche il offboarding umano rispetto alla dismissione degli strumenti AI.

Zero Standing Privilege modella questa disciplina utilizzando account effimeri con ambito di attività, ephemeral accounts invece di credenziali elevate persistenti.

Scuole della Contea di Eastern Carver hanno applicato esattamente questa disciplina: invece di lasciare account amministrativi attivi sui dati degli studenti, il distretto ha limitato l'accesso privilegiato solo quando necessario utilizzando Netwrix Privilege Secure, e il rollout ha richiesto giorni anziché un progetto di un trimestre.

Ancorare ogni identità agente a un human sponsor affinché ogni account mantenga un proprietario responsabile quando il proprietario umano se ne va. Le attuali linee guida sull'identità raccomandano cadenze di revisione più brevi per gli agenti rispetto alle persone, almeno trimestralmente e mensilmente per agenti con privilegi elevati, perché l'accesso degli agenti cambia più rapidamente rispetto alle certificazioni annuali.

Monitora l'esposizione dei dati guidata dall'IA in modo continuo

Il monitoraggio deve essere continuo, perché una revisione dell’accesso una tantum diventa obsoleta non appena appare un nuovo strumento o integrazione AI. Traccia quali dati gli strumenti AI effettivamente interrogano e recuperano, andando oltre i permessi registrati, e segnala modelli di volume o sensibilità che esulano dall’uso approvato.

In Microsoft 365, le interazioni di Copilot vengono registrate nel registro unificato delle verifiche, quindi conferma che la conservazione delle verifiche corrisponda alla finestra di evidenza a cui la policy si impegna prima che un revisore chieda i record dello scorso anno. Questo fornisce ai team di sicurezza prove che le regole di accesso della policy sono in linea con il comportamento effettivo dell'IA.

Netwrix AI Governance, fornito tramite Netwrix 1Secure™, aggiunge il tracciamento e la reportistica delle interazioni con Copilot che i team di sicurezza possono conservare come prova di audit.

Automatizza avvisi ed escalation quando uno strumento di IA supera il proprio confine di accesso

La rilevazione ha valore solo se attiva il percorso di escalation già definito dalla policy. Inoltra automaticamente i risultati al incident response process indicato nella sezione di governance della policy e registra ogni allerta come prova di audit. Il percorso di escalation deve collegarsi a un processo di revoca funzionante con chiara proprietà e tempistiche.

Trasforma la tua politica di governance dell'IA in un controllo applicabile

Una politica scritta riduce il rischio quando ogni clausola corrisponde a un controllo tecnico: visibilità su cosa possono accedere gli strumenti AI, minimo privilegio per le identità AI e monitoraggio continuo.

Molti rischi legati all'IA seguono lo stesso percorso di accesso degli incidenti di identità: gli attaccanti usano credenziali legittime per raggiungere i dati, e uno strumento di IA con accesso permanente troppo ampio diventa un'altra identità con permessi eccessivi nell'ambiente.

La sicurezza dei dati e la sicurezza dell’identità sono lo stesso problema visto da due angolazioni, e la politica riduce il rischio solo quando entrambi sono applicati insieme.

Richiedi una demo per vedere come 1Secure mappa l'accesso agli strumenti AI, traccia le interazioni di Copilot e trasforma le regole di accesso della tua policy in prove di audit.