Politica di Sicurezza dell’IA: Definizione, Ambito e Componenti Fondamentali

Una politica di sicurezza dell’IA stabilisce le regole per proteggere i sistemi di IA che un’organizzazione costruisce, acquista o consente ai dipendenti di utilizzare. Spiega quali strumenti sono approvati, quali dati possono essere utilizzati, come i modelli e le pipeline sono protetti, chi possiede la supervisione e come i team rispondono se un sistema di IA perde dati, viene manipolato o si comporta in modo imprevisto.

Che cos’è una Politica di Sicurezza dell’IA?

Alla base, una politica di sicurezza dell’IA trasforma una governance ampia dell’IA in una pratica di sicurezza quotidiana. I dipendenti sanno cosa possono utilizzare. I team tecnici sanno come i sistemi di IA devono essere protetti. I leader ottengono uno standard per approvare, monitorare e ritirare l’IA.

Una politica generale di IA stabilisce la posizione dell’organizzazione sull’IA responsabile. La politica di sicurezza è più ristretta e operativa: cosa potrebbe andare storto, chi possiede il rischio e quali controlli lo riducono?

Questo termine viene anche confuso con l’IA per la cybersecurity. Qui, il soggetto non utilizza l’IA per rilevare minacce. Si tratta di garantire la sicurezza dell’IA stessa: proteggere modelli, dati, richieste, output, integrazioni e utenti da uso improprio, compromissione, perdita, manipolazione e guasti.

In termini quotidiani, la politica risponde a quattro domande:

• Quali strumenti e sistemi di IA sono consentiti?
• Quali dati possono essere utilizzati con essi?
• Chi può approvare, accedere, monitorare e modificarli?
• Cosa succede quando un sistema di IA si comporta in modo imprevisto o viene attaccato?

Politica di Sicurezza dell’IA vs. Politica AI

La politica di sicurezza AI è più ristretta rispetto a una politica AI generale. La politica più ampia può coprire etica, trasparenza, equità, approvvigionamento, conformità e uso responsabile. La politica di sicurezza si concentra concretamente su minacce, controlli, proprietà, monitoraggio e risposta agli incidenti.

Dimensione	Politica di Sicurezza AI	Politica AI Generale	Politica di Cybersecurity
Focus principale	Proteggere i sistemi AI, i dati, i modelli e le pipeline da minacce e guasti.	Regolare l’uso dell’AI in relazione a etica, conformità, operazioni, equità, trasparenza e rischio.	Mettere in sicurezza l’ambiente IT più ampio: reti, endpoint, applicazioni, identità e dati.
Ambito	Ciclo di vita del modello, dati di addestramento, inferenza, strumenti AI, fornitori di AI e percorsi di attacco specifici per l’AI.	L’intero programma AI dell’organizzazione e il suo impatto su persone, operazioni e conformità.	L’intero patrimonio tecnologico, indipendentemente dal coinvolgimento dell’AI.
Proprietario tipico	CISO, team di sicurezza, responsabile della governance AI o gruppo di sicurezza/governance condiviso.	Chief AI officer, legale, conformità, rischio e team di governance esecutiva.	CISO e organizzazione di sicurezza delle informazioni.

Politica di Sicurezza dell’IA vs. Politica di Cybersecurity

Una politica standard di cybersecurity di solito presenta delle lacune. Può coprire bene sistemi, reti, endpoint e identità, ma l’IA introduce rischi che quei controlli non sono stati scritti per gestire.

Questi rischi includono dati di addestramento avvelenati, iniezione di prompt, inversione del modello, input avversari, furto di modelli e fuga di informazioni sensibili attraverso prompt o output. Una politica di sicurezza dell’IA estende il programma di cybersecurity nel ciclo di vita del modello e nei modi specifici in cui i sistemi di IA possono essere attaccati o abusati.

Perché le Politiche di Sicurezza dell’IA Rappresentano una Lacuna Critica

Il problema principale non è che le organizzazioni dubitino del valore della politica di sicurezza dell’IA. È che l’adozione dell’IA ha superato la governance dell’IA.

Nessun singolo sondaggio racconta l’intera storia, ma il modello è coerente: molte organizzazioni stanno già sperimentando o implementando l’IA, mentre le regole di sicurezza specifiche per l’IA rimangono disomogenee. IBM ha riportato che solo una minoranza di organizzazioni ha politiche formali di sicurezza dell’IA. Cisco ha scoperto che molte organizzazioni che sperimentano con l’IA generativa mancano ancora di politiche di sicurezza specifiche. Il World Economic Forum ha anche avvertito che molti consigli non hanno ancora discusso formalmente dei rischi di sicurezza specifici per l’IA.

Questa lacuna è importante perché gli incidenti legati all’IA non sono più ipotetici. Incidenti di privacy, vulnerabilità dei modelli, fuga di dati, abuso e fallimenti etici fanno ora parte dell’ambiente operativo. Una politica fornisce ai team un modo condiviso per decidere cosa è consentito, cosa necessita di revisione, cosa deve essere registrato e come rispondere quando qualcosa va storto.

Cosa Copre una Politica di Sicurezza dell’IA?

Una politica di sicurezza dell’IA utile è più di una dichiarazione di intenti di una pagina. Coprendo i luoghi in cui il rischio dell’IA appare realmente: utenti, dati, modelli, infrastrutture, fornitori, monitoraggio e risposta agli incidenti.

Regole di Uso Accettabile e Shadow IA

Inizia con gli strumenti e i casi d’uso. Una buona politica indica quali strumenti di intelligenza artificiale sono approvati, quali usi sono permessi e quali usi sono vietati. La redazione di documenti, l’assistenza alla programmazione o la ricerca interna possono essere consentite in specifiche condizioni; la profilazione discriminatoria, la generazione di contenuti ingannevoli o l’inserimento di dati regolamentati in strumenti pubblici possono essere limitati o vietati.

Questo è anche il luogo in cui appartiene l’AI ombra. L’AI ombra si verifica quando i dipendenti utilizzano strumenti di intelligenza artificiale non approvati al di fuori della visibilità dell’organizzazione. È rischioso perché bypassa l’approvvigionamento, la registrazione, i controlli di accesso, le regole di gestione dei dati e la revisione della sicurezza. Una chiara sezione sull’uso accettabile offre ai dipendenti un percorso più sicuro rispetto all’improvvisazione.

Classificazione e protezione dei dati

Questa sezione traccia il confine attorno ai dati. I dati riservati, regolamentati, dei clienti, dei dipendenti e proprietari di solito necessitano di regole più rigorose rispetto alle informazioni pubbliche o a basso rischio.

Ad esempio, la politica potrebbe vietare ai dipendenti di inserire dati riservati in strumenti di intelligenza artificiale generativa esterni a meno che lo strumento non sia stato approvato, il contratto consenta tale uso e i dati siano protetti attraverso controlli appropriati. La stessa sezione dovrebbe coprire i dati di addestramento, i prompt, le uscite, i registri, i dataset di fine-tuning e le storie delle conversazioni conservate.

Controllo degli accessi e identità

L’accesso all’AI appartiene alla normale gestione dell’identità e degli accessi. La politica definisce chi può accedere a modelli, API, dataset, prompt, uscite, console amministrative e pipeline di distribuzione.

Per i sistemi ad alto rischio, ciò può significare permessi basati sui ruoli, flussi di approvazione, controlli di accesso privilegiati, monitoraggio e revisioni periodiche degli accessi. L’obiettivo è semplice: le persone dovrebbero avere l’accesso di cui hanno bisogno, e non di più.

Sicurezza del ciclo di vita

La sicurezza deve seguire il ciclo di vita dell’AI dalla progettazione al ritiro. Ciò include la raccolta dei dati, la selezione del modello, l’addestramento o il fine-tuning, il testing, la distribuzione, il monitoraggio, la gestione delle modifiche e il dismissione.

Prima che un modello venga distribuito, i team potrebbero aver bisogno di modellazione delle minacce, revisione della sicurezza, test di red team, validazione dei dati di addestramento e approvazione da parte dei responsabili del rischio. Dopo la distribuzione, la politica necessita di monitoraggio per deriva, abuso, perdita, uscite insolite e cambiamenti nell’esposizione alle minacce. Quando un modello viene ritirato, l’organizzazione ha bisogno di regole per rimuovere l’accesso, preservare i registri richiesti e sanificare i dati dove appropriato.

Copertura delle minacce specifiche per l’IA

È qui che la politica diventa veramente specifica per l’IA. Identifica i rischi che l’organizzazione sta cercando di gestire e li collega ai controlli.

Le minacce comuni includono avvelenamento dei dati, furto di modelli, esempi avversariali, iniezione di prompt, inversione del modello, fuga di dati di addestramento e esfiltrazione di dati tramite prompt o output. La politica non deve trasformarsi in un manuale tecnico, ma deve essere sufficientemente chiara affinché i team di sicurezza, i team di dati e i proprietari aziendali sappiano quali rischi sono responsabili.

Rischio di terze parti e della catena di fornitura

La maggior parte delle organizzazioni utilizza IA che non hanno costruito loro stesse. Le API LLM pubbliche, i copiloti SaaS, le funzionalità AI integrate, i modelli open-source, i modelli pre-addestrati e i sistemi gestiti dai fornitori introducono tutti un rischio di terze parti.

Le regole per i fornitori coprono come vengono valutati i fornitori di IA, quali dati possono essere condivisi con loro, quali registrazioni sono richieste, se i dati dei clienti vengono utilizzati per l’addestramento, come vengono esaminati gli output e quali protezioni contrattuali devono essere in atto prima dell’uso.

Supervisione umana come controllo di sicurezza

La supervisione umana è spesso trattata come un requisito etico, ma è anche un controllo di sicurezza. Una persona che esamina l’output dell’IA può individuare risposte manipolate, istruzioni sospette, fatti allucinati, raccomandazioni non sicure o risposte eccessivamente sicure da un sistema compromesso o mal configurato.

La politica dovrebbe specificare quando è necessaria la revisione umana, chi è qualificato per eseguirla e quali decisioni supportate dall’IA non possono essere automatizzate senza approvazione.

Risposta agli incidenti e monitoraggio

Gli incidenti legati all’IA devono essere nominati nel piano di risposta agli incidenti. Esempi includono abuso del modello, iniezione di prompt, fuga di dati, accesso non autorizzato al modello, compromissione dell’integrità, output dannosi o un servizio AI di terze parti che si comporta in modo imprevisto.

Le regole di registrazione sono importanti qui. A seconda del sistema, l’organizzazione potrebbe aver bisogno di registri di prompt, output, azioni amministrative, modifiche al modello, accesso ai dati, utilizzo delle API e avvisi di sicurezza. Senza monitoraggio, i team potrebbero non sapere che un sistema IA viene abusato fino a dopo che il danno è stato fatto.

Normative e quadri regolatori pertinenti

La politica di sicurezza dell’IA non dovrebbe essere scritta in isolamento. Appartiene accanto agli standard e alle normative che già plasmano la governance dell’IA, la sicurezza e la gestione del rischio. Il mix esatto dipende dall’industria, dalla geografia e dal profilo di rischio dell’organizzazione.

Framework	Perché è importante per una politica di sicurezza dell’IA
ISO/IEC 42001	Fornisce un approccio al sistema di gestione per governare l’IA, inclusi controlli, responsabilità e miglioramento continuo.
NIST AI RMF	Fornisce alle organizzazioni una struttura di gestione del rischio per l’IA, inclusi affidabilità, robustezza, sicurezza e governance.
MITRE ATLAS	Mappa le tattiche e le tecniche avversarie contro i sistemi di IA e di apprendimento automatico.
Regolamento dell’UE sull’IA	Introduce obblighi basati sul rischio per i sistemi di IA, inclusi aspettative di sicurezza e robustezza per usi ad alto rischio.
Convenzione sull’IA del Consiglio d’Europa	Sottolinea le salvaguardie lungo il ciclo di vita dell’IA, inclusi sicurezza, responsabilità e controlli sui rischi.
ISO/IEC 27001	Ancorare i sistemi di IA all’interno di una gestione della sicurezza delle informazioni più ampia come beni informativi e sistemi aziendali.

Comuni malintesi sulla politica di sicurezza dell’IA

Malinteso 1: È solo una politica di cybersecurity con l’IA aggiunta al titolo.

Realtà: Una politica di cybersecurity è ancora necessaria, ma l’IA aggiunge rischi come l’iniezione di prompt, il avvelenamento dei dati, il furto di modelli, l’inversione dei modelli e la fuga di dati di addestramento. Quei rischi necessitano di proprietari nominati, percorsi di revisione e controlli.

Falso concetto 2: La sicurezza dell’IA significa utilizzare l’IA per svolgere lavori di sicurezza.

Realtà: In questo contesto, la sicurezza dell’IA significa proteggere i sistemi di IA stessi. La politica può coprire anche strumenti di sicurezza alimentati da IA, ma questo non è il suo scopo principale.

Falso concetto 3: Una volta che la politica è scritta, il lavoro è finito.

Realtà: I sistemi di IA, le normative e i metodi di attacco cambiano rapidamente. La politica necessita di revisioni programmate, oltre a aggiornamenti basati su eventi quando nuovi strumenti, incidenti, leggi o rischi si presentano.

Falso concetto 4: La politica si applica solo ai modelli che l’organizzazione costruisce internamente.

Realtà: Gli strumenti di IA di terze parti spesso creano il più grande divario di visibilità. I chatbot pubblici, le funzionalità di IA SaaS, i copiloti, le API esterne e i modelli open-source rientrano tutti nell’ambito della politica.

Falso concetto 5: È puramente un documento tecnico.

Realtà: I controlli tecnici sono importanti, ma anche le persone e i processi lo sono altrettanto. Formazione, approvazioni, responsabilità, revisione dei fornitori, supervisione umana e segnalazione degli incidenti devono rientrare nella politica.

Domande frequenti

Qual è la differenza tra una politica di sicurezza dell’IA e una politica di sicurezza dell’IA generativa?

Una politica di sicurezza dell’IA generativa è una versione più ristretta di una politica di sicurezza dell’IA. Si concentra su sistemi come modelli di linguaggio di grandi dimensioni, generatori di immagini, copiloti e chatbot. Le sue aree di rischio includono spesso l’iniezione di prompt, dati sensibili nei prompt, output allucinati, contenuti tossici o non sicuri, esposizione della proprietà intellettuale e perdita di dati attraverso risposte generate.

Che cos’è l’AI Shadow e perché una politica lo affronta?

L’AI Shadow è l’uso di strumenti di intelligenza artificiale senza approvazione o supervisione organizzativa. Un esempio comune è un dipendente che incolla informazioni riservate in un chatbot pubblico. Una politica affronta l’AI Shadow nominando strumenti approvati, stabilendo regole per la gestione dei dati e fornendo ai dipendenti un processo chiaro per un uso sicuro dell’AI.

Chi possiede e applica una politica di sicurezza dell’AI?

La proprietà spesso spetta al CISO, alla leadership della sicurezza o a un responsabile della governance dell’AI. L’applicazione di solito richiede diversi gruppi: sicurezza, legale, conformità, dati, IT, approvvigionamento e proprietari aziendali. La politica rende espliciti quei ruoli affinché la responsabilità non venga persa tra i team.

Una politica di sicurezza dell’AI copre strumenti come ChatGPT, Copilot e funzionalità AI SaaS?

Sì. Gli strumenti di AI di terze parti rientrano nell’ambito perché possono esporre dati, creare output non revisionati o spostare decisioni al di fuori dei sistemi approvati. Una buona politica indica chi può usarli, quali dati possono essere condivisi, come viene registrato l’uso e quali strumenti richiedono una revisione aggiuntiva.

Con quale frequenza dovrebbe essere rivista una politica di sicurezza dell’AI?

Non esiste un intervallo universale, ma la revisione annuale da sola di solito non è sufficiente. Molte organizzazioni combinano una revisione annuale o semestrale programmata con aggiornamenti attivati da nuovi strumenti di AI, nuove normative, incidenti di sicurezza, cambiamenti significativi nei fornitori o metodi di attacco emergenti.

Quali normative richiedono una politica di sicurezza dell’AI?

Una legge potrebbe non richiedere un documento con quel titolo esatto, ma diversi framework creano obblighi che una politica di sicurezza dell’AI aiuta a soddisfare. ISO/IEC 42001, il NIST AI RMF, il Regolamento sull’AI dell’UE, la Convenzione sull’AI del Consiglio d’Europa e ISO/IEC 27001 influenzano tutti come le organizzazioni governano, proteggono e monitorano i sistemi di AI. I requisiti variano in base alla giurisdizione, al settore e al caso d’uso.

Conclusioni

Una politica di sicurezza dell’AI fornisce a un’organizzazione regole pratiche per proteggere l’AI durante l’intero ciclo di vita: approvazione degli strumenti, gestione dei dati, sicurezza dei modelli, governance dell’AI di terze parti, mantenere gli esseri umani coinvolti e rispondere quando qualcosa va storto.

Non è un sostituto di una politica ampia sull’AI o di una politica di cybersecurity. Si colloca tra di loro, traducendo i rischi specifici dell’IA in regole che i team di sicurezza, i team di governance e i proprietari delle aziende possono effettivamente utilizzare. Man mano che l’IA si diffonde all’interno dell’organizzazione, quella chiarezza diventa meno un’opzione di governance e più un requisito operativo di base.