La sicurezza dell'IA e la governance dell'IA non sono lo stesso problema.

La maggior parte delle organizzazioni sta risolvendo il problema sbagliato. Ecco come distinguerli e perché è importante prima della prossima implementazione dell'IA.

Perché la sicurezza dell'IA e la governance dell'IA non sono lo stesso problema

Nella maggior parte delle organizzazioni IT, la sicurezza e la governance dell'IA vengono considerate come un unico flusso di lavoro. Entrambi gli argomenti finiscono nella stessa riunione, vengono assegnati allo stesso team e seguono gli stessi framework. Ma si tratta di due problemi distinti. La sicurezza dell'IA impedisce l'ingresso delle minacce, mentre la governance controlla il comportamento interno dell'IA.

Ignorare questa differenza ha un costo. Si può superare un audit di sicurezza e fallire quello normativo. Si può segnalare zero violazioni e non avere comunque alcuna governance. Entrambe le cose possono essere vere nello stesso giorno.

La posta in gioco si alza man mano che gli agenti IA passano dal rispondere alle domande all'intervenire direttamente nei sistemi di produzione. Il team di sicurezza può proteggere un agente dagli attacchi, ma non avere comunque modo di dimostrare cosa quell'agente fosse autorizzato a fare. Questo articolo spiega come distinguere i due problemi, a chi spetta la responsabilità di ciascuno e cosa chiedere ai fornitori prima della prossima implementazione.

Che cos'è la sicurezza dell'IA?

La sicurezza dell'IA protegge il sistema di intelligenza artificiale e i dati che gestisce dalle minacce esterne. Risponde a una domanda fondamentale: è possibile che qualcuno si introduca nel sistema, lo manipoli o ne rubi i dati?

Si articola in tre aree:

• Il modello . Protegge il modello da input avversari, iniezioni di prompt e manipolazioni che lo spingono verso output dannosi.
• I dati. Impedisce l'esposizione o l'esfiltrazione non autorizzata dei dati sensibili a cui l'IA può accedere.
• L'infrastruttura. Rafforza i sistemi di calcolo, di rete e le integrazioni su cui si basa l'IA, impedendo agli aggressori di comprometterli.

La sicurezza basata sull'IA estende le misure di sicurezza già in atto. Mantieni gli stessi team e le stesse discipline, aggiungendo una nuova superficie di attacco. Un'organizzazione di sicurezza matura è ben attrezzata per affrontare questa sfida. Questa è un'ottima notizia, ma è anche il punto in cui inizia la confusione.
 

Che cos'è la governance dell'IA e perché è diversa?

La governance dell'IA controlla ciò che la tua IA fa quando funziona esattamente come progettato, senza alcun coinvolgimento di un attaccante. Risponde a una domanda diversa: cosa è autorizzata a fare la nostra IA e possiamo dimostrarlo?

La governance si basa su tre componenti:

• Autorizzazione. Questa definisce cosa può fare l'IA, a quali condizioni e con quale portata.
• Responsabilità. Questo stabilisce chi ha approvato ciascuna azione e se esiste una registrazione che collega l'azione a quella persona.
• Tracciabilità. Questo fattore determina se è possibile dimostrare a un ente regolatore cosa ha fatto l'IA, quando e perché, senza dover ricostruire gli eventi a partire da registri sparsi.

La sicurezza chiede: "Qualcuno può introdursi illegalmente?" La governance chiede: "Cosa è consentito fare alla mia IA e dove sono le prove?"

Un agente perfettamente protetto può comunque riavviare il processo sbagliato, leggere dati non necessari o agire senza l'approvazione di nessuno. Nessuno di questi casi viene registrato come incidente di sicurezza. Tutto emerge durante un audit.
 

Perché la sicurezza dell'IA e la governance dell'IA richiedono team e framework diversi?

Richiedono responsabili diversi perché i framework su cui si basano misurano aspetti differenti. Framework di sicurezza come SOC 2, ISO 27001 e il NIST Cybersecurity Framework si concentrano sulle minacce esterne e sulla protezione di sistemi e dati. Sono essenziali, ma non si occupano di questioni di governance.

I framework di governance guardano all'interno. Il framework NIST per la gestione del rischio dell'IA, l'AI Act dell'UE, le linee guida modello per la gestione del rischio dell'OCC e il Digital Operational Resilience Act (DORA) dell'UE indicano tutti le stesse aspettative: autorizzazione chiara, supervisione umana e decisioni tracciabili. Questi framework non valutano il perimetro.

Se affidate la governance al team di sicurezza e gli chiedete di utilizzare framework di sicurezza, otterrete esattamente ciò che quei framework producono: un audit di sicurezza. Non otterrete un'architettura di governance.

Il modello migliore prevede la suddivisione della proprietà:

• La sicurezza controlla il perimetro. Protegge il modello, i dati e l'infrastruttura.
• Conformità, rischio e operazioni IT condividono la governance. Questi team comprendono quali azioni comportano rischi aziendali e normativi.

Ciascuna parte gestisce le proprie riunioni, definisce i propri criteri di successo e pone le proprie domande ai fornitori. Per i team mainframe, il ruolo del personale IT addetto alle operazioni è fondamentale. Il personale operativo sa quali processi batch non possono essere riavviati alle 8 del mattino e quali sottosistemi dipendono l'uno dall'altro.
 

Quali questioni distinguono la sicurezza dell'IA dalla governance dell'IA?

Il modo più rapido per distinguerli è confrontare le domande che ciascuno pone a un fornitore. Utilizzate entrambi i set di domande in ogni valutazione dell'IA.

Domande di sicurezza da porsi:

• Come si protegge il modello da input avversari?
• Come si controlla e si registra l'accesso ai dati per il rilevamento delle violazioni?
• Qual è la procedura di risposta agli incidenti nel caso in cui un utente malintenzionato comprometta il modello?

Domande da porsi in merito alla governance:

• Quali sono le autorizzazioni necessarie all'agente di intelligenza artificiale e come si fa a garantirne il rispetto?
• Chi ha approvato ciascuna azione intrapresa dall'agente e dove si trova la relativa documentazione?
• È possibile produrre una traccia di controllo immutabile dell'attività dell'agente ai fini di una revisione normativa?

Un fornitore che risponde bene al primo punto ma ha difficoltà con il secondo non possiede un'architettura di governance. Tale fornitore offre un agente ben protetto di cui nessuno può rendere pienamente conto.

Cosa succede quando si considerano la sicurezza e la governance dell'IA come la stessa cosa?

Si finisce per avere fallimenti nella governance che i vostri strumenti di sicurezza non rilevano mai. Eccone tre che si verificano nelle operazioni reali.

L'interruzione non autorizzata. Un agente di intelligenza artificiale riavvia un processo batch di produzione durante l'orario di lavoro e i tempi di risposta crollano. Il team di sicurezza controlla i log e non rileva violazioni, intrusioni o anomalie. Ma nessuno sa chi abbia autorizzato il riavvio, perché non esisteva una procedura di approvazione. Si tratta di una falla nella governance.

Un audit che risponde alla domanda sbagliata. Un ente regolatore richiede un resoconto di ogni azione compiuta da un agente di intelligenza artificiale negli ultimi 90 giorni, specificando chi l'ha approvata. Il team di sicurezza produce un registro perimetrale impeccabile. Il registro dimostra che nessuno si è introdotto illegalmente, ma non dice nulla su cosa abbia fatto l'agente. Questo è un fallimento della governance.

L'agente con le chiavi di tutto. Un agente di intelligenza artificiale opera con le credenziali complete di un operatore senior. Non si è verificata alcuna violazione e nessuno ha ancora abusato di alcun dato. Ma nulla limita il raggio d'azione dell'agente, che può quindi leggere, modificare o eliminare qualsiasi informazione a cui l'operatore avrebbe accesso. Si tratta di una falla nella governance in attesa di essere innescata.

In ogni caso, la vostra strategia di sicurezza ha retto. La vostra strategia di governance non è mai esistita.

Come si costruiscono la sicurezza e la governance dell'IA senza confonderle?

Gestiscili come due flussi di lavoro paralleli con responsabili e criteri di valutazione separati. Non unirli in un unico programma. Continua a investire nella sicurezza, poi costruisci il livello di governance che la tua infrastruttura di sicurezza non è stata progettata per fornire.

Questo livello necessita di quattro funzionalità:

• Identità dell'agente: ciascun agente agisce con le proprie credenziali, distinte da quelle dell'operatore umano.
• Autorizzazione limitata: gli agenti accedono solo a ciò che è necessario per ciascuna attività.
• Fascicoli di approvazione umana: le azioni ad alto rischio vengono sospese fino a quando una persona non le autorizza.
• Traccia di controllo immutabile: ogni azione, la sua motivazione e chi l'ha approvata vengono registrate in un documento che nessuno può modificare a posteriori.

Rocket^® EVA^™ Rocket EVA è stato progettato secondo questo tipo di architettura di governance. Assegna a ciascun agente una credenziale di breve durata e con ambito limitato. Applica le regole operative tramite policy-as-code e riserva le azioni ad alto rischio all'approvazione umana. Registra inoltre ogni passaggio in una traccia di controllo immutabile, collegata sia all'agente che all'approvatore umano.

Rocket EVA si integra con la tua infrastruttura di sicurezza esistente, anziché sostituirla. Tale infrastruttura include strumenti di gestione delle identità e degli accessi, gestione dei servizi IT e strumenti di osservabilità. Il tuo team di sicurezza si occupa del perimetro di sicurezza. I team di conformità, gestione del rischio e operazioni ottengono un registro che possono difendere. I tuoi operatori dispongono di operazioni agentiche governate che velocizzano la diagnostica in ambienti mainframe, distribuiti e cloud, senza introdurre nuovi rischi.

Non devi scegliere tra la velocità e la responsabilità. Sviluppando entrambi i flussi di lavoro ora, la tua prossima implementazione di IA partirà da una base che le autorità di regolamentazione riconosceranno.

Scopri come l'architettura di Rocket EVA affronta la governance dell'IA, non solo la sicurezza.

Rocket è un marchio commerciale di Rocket Software, Inc. e delle sue affiliate.