Il rapporto CYGNVS Resilience Benchmark rivela lacune nella preparazione agli incidenti legati all’IA

Il Rapporto di riferimento sulla resilienza CYGNVS, realizzato da CYGNVS in collaborazione con Marsh Risk, rileva un divario crescente tra l’uso dell’IA da parte delle organizzazioni e la loro capacità di gestire gli incidenti che la riguardano. Sulla base di oltre 9.500 questionari autocompilati, il rapporto afferma che l’89% delle organizzazioni intervistate ha subito qualche tipo di incidente legato all’IA, mentre il 46% improvviserebbe la propria risposta a un episodio del genere.

Pubblicato il 13 ottobre 2026, il rapporto esamina un problema che assume un’importanza sempre maggiore man mano che l’IA passa dalla generazione di contenuti alla gestione dei flussi di lavoro aziendali. Consentire a un agente di accedere a documenti, e-mail e sistemi aziendali può renderlo utile. Ma rende anche più difficile contenere un’istruzione errata, una credenziale esposta o una sequenza incontrollata di azioni.

I risultati suggeriscono che l’adozione dell’IA e la preparazione a riprendersi dai suoi malfunzionamenti procedono a velocità diverse. Circa l’80% delle organizzazioni incluse nel campione utilizza l’IA generativa, ma solo una su tre sottopone i propri sistemi di IA a test contro gli attacchi. Avere un comitato per la governance dell’IA, come riferisce di avere tre quarti delle organizzazioni che la utilizzano, non si traduce necessariamente in difese operative messe alla prova.

Cosa considera il rapporto un incidente legato all’IA

Il dato principale va contestualizzato. Il rapporto adotta una definizione ampia di incidente legato all’IA, che comprende allucinazioni dannose, distorsioni, deriva del modello, fughe di dati, agenti che perseguono obiettivi non previsti, malfunzionamenti nelle interazioni tra agenti e misure di protezione inadeguate. Questi eventi possono avere cause e conseguenze molto diverse.

Una risposta imprecisa rivolta a un cliente e un agente che espone informazioni riservate rientrano entrambi in questa definizione più ampia, ma non sono eventi di sicurezza equivalenti. Il dato dell’89% va quindi letto come una segnalazione di esperienze con qualche forma di incidente legato all’IA, non come prova che quasi nove organizzazioni su dieci abbiano subito una violazione causata dall’IA. Il rapporto afferma inoltre che il 16% affronta un incidente legato all’IA almeno una volta alla settimana, senza stabilire che tutti questi incidenti abbiano la stessa gravità.

Questa distinzione è importante per pianificare la risposta. Un risultato dannoso del modello può richiedere la rimozione dei contenuti e una revisione delle decisioni interessate. Un agente che opera tramite strumenti collegati può rendere necessario revocare le autorizzazioni, conservare i registri delle attività e individuare le modifiche apportate in diversi sistemi. Un piano di risposta alle intrusioni tradizionale può coprire alcuni aspetti di entrambe le risposte, ma i team devono comunque sapere quali azioni specifiche per l’IA possono intraprendere e chi è autorizzato a farlo.

I piani sono diffusi. Quelli attuabili molto meno.

Il rapporto articola la preparazione in quattro fasi: preparare, esercitarsi, rispondere e rendicontare. In tutte, la debolezza ricorrente è la distanza tra disporre di procedure documentate e riuscire ad attuarle sotto pressione.

• Preparare: il 92% dispone di procedure documentate per la risposta agli incidenti, ma solo il 37% ha piani operativi specifici per gli attacchi ransomware e il 29% per gli incidenti causati da terze parti.
• Esercitarsi: il 17% non svolge esercitazioni da tavolo. Un altro 66% le organizza ogni anno o una volta ogni due anni.
• Rispondere: il 67% non ha individuato chiaramente i responsabili dei processi e delle dipendenze più critici.
• Rendicontare: il 69% riconosce lacune significative nella documentazione di chi ha fatto cosa e quando.

Nel frattempo, oltre sei organizzazioni su dieci affermano che il numero di incidenti è aumentato nei 12 mesi precedenti, e l’84% rivede i piani di risposta una volta all’anno o meno. Questi dati descrivono aspetti diversi della preparazione, ma nel loro insieme sollevano una questione pratica: quanto rapidamente diventa obsoleto un piano quando i sistemi, i fornitori e le autorizzazioni che descrive continuano a cambiare?

Nelle implementazioni dell’IA, i cambiamenti possono includere un nuovo modello, un’ulteriore fonte di dati o l’autorizzazione a eseguire un’attività prima svolta manualmente. Ognuno di questi elementi può modificare la risposta necessaria in caso di malfunzionamento. Un piano deve individuare il responsabile del sistema interessato, le misure di contenimento disponibili e le prove da preservare durante il contenimento.

Perché l’infrastruttura di risposta deve avere un perimetro separato

Solo il 33% delle organizzazioni intervistate dispone di un ambiente di comando dedicato e fuori banda, che l’IA oggetto dell’indagine non può osservare né influenzare. La questione architetturale è semplice: un team di risposta ha bisogno di un luogo affidabile in cui coordinarsi anche quando l’ambiente interessato non lo è più.

Si consideri un agente che può accedere a documenti condivisi e ai sistemi di messaggistica aziendale. Se chi interviene inserisce le note dell’indagine e i piani di contenimento negli stessi sistemi, le autorizzazioni dell’agente potrebbero consentirgli di accedere anche alle attività di risposta. Questo non significa che ogni agente malfunzionante cercherà di nascondere il proprio comportamento. Significa che l’architettura di risposta non dovrebbe dipendere dal corretto funzionamento del sistema interessato.

CYGNVS affronta il problema con una piattaforma che consente ai team di sicurezza, ai dirigenti aziendali e agli specialisti esterni di coordinarsi. Il suo Centro di comando per gli incidenti legati all’IA comprende piani operativi specifici per l’IA, scenari di esercitazione e indicazioni per la risposta. L’azienda afferma che l’ambiente funziona indipendentemente dal sistema aziendale di single sign-on, dalla posta elettronica e dall’infrastruttura dei clienti.

Le sue funzionalità fuori banda includono identità utente separate e una modalità Isolate Mode che limita lo spazio di lavoro dedicato all’incidente ai partecipanti autorizzati. L’azienda descrive inoltre istantanee storiche e certificazioni di accesso firmate digitalmente per documentare le attività di risposta. Si tratta di funzionalità di coordinamento e gestione delle prove; la loro efficacia dipende comunque da come le organizzazioni configurano gli accessi, assegnano le responsabilità e si esercitano a utilizzarle.

Le esercitazioni devono coinvolgere anche chi prende le decisioni

Solo il 15% delle organizzazioni incluse nel rapporto svolge esercitazioni pratiche da tavolo che coinvolgono pienamente diverse funzioni, tra cui l’ufficio legale, i dirigenti e il team comunicazione. Quasi la metà continua a considerare le esercitazioni principalmente attività per i team di sicurezza e IT, coinvolgendo le altre funzioni solo quando necessario.

Di conseguenza, decisioni importanti non vengono provate a sufficienza. Un team di sicurezza potrebbe essere in grado di disattivare un’integrazione, ma un responsabile aziendale potrebbe dover approvare l’interruzione di un servizio rivolto ai clienti. I team legale e comunicazione potrebbero dover valutare cosa si può dichiarare prima che l’indagine sia conclusa. Esercitarsi in questi passaggi di responsabilità aiuta a individuare autorità mancanti e presupposti in conflitto.

Anche i fornitori esterni rappresentano una dipendenza. Sebbene l’88% dichiari di disporre di piani di comunicazione in caso di crisi, più di quattro organizzazioni su dieci non hanno ancora garantito l’accesso alle competenze esterne su cui tali piani fanno affidamento. Gli elenchi di contatti e gli accordi contrattuali sono componenti operative della preparazione, soprattutto quando diverse organizzazioni potrebbero aver bisogno degli stessi specialisti durante un incidente su vasta scala.

Come interpretare il benchmark

La metodologia descrive oltre 9.500 questionari raccolti tra gennaio 2023 e settembre 2026 in 21 settori e in paesi asiatici, europei e nordamericani. Le risposte sono state fornite dagli stessi partecipanti, anonimizzate e analizzate nel loro insieme. Il set di dati comprende organizzazioni che hanno subito un incidente informatico o legato all’IA di gravità critica nei 24 mesi precedenti e organizzazioni che non ne hanno subito.

Si tratta di una raccolta pluriennale di risposte a questionari, non di un singolo nuovo sondaggio condotto su 9.500 aziende distinte. La metodologia pubblicata non definisce un campione probabilistico rappresentativo di tutte le organizzazioni né indica la dimensione del campione per ciascun risultato evidenziato. Le percentuali sono indicatori utili all’interno del set di dati, ma non vanno considerate stime precise della prevalenza degli incidenti in generale.

Il rapporto rileva che le organizzazioni che hanno subito di recente incidenti critici tendono a mostrare una maggiore preparazione sotto diversi aspetti. Questa associazione giustifica l’analisi dei cambiamenti introdotti da tali organizzazioni, ma non dimostra, di per sé, che l’esperienza degli incidenti abbia causato i miglioramenti. CYGNVS vende anche software per la gestione della risposta agli incidenti: questo interesse commerciale è quindi rilevante nel valutare le sue raccomandazioni.

Dai risultati ai cambiamenti operativi

Insieme al rapporto, CYGNVS presenta la funzionalità Resilience Benchmark, che, secondo l’azienda, consente ai clienti di confrontare il proprio livello di preparazione in base al settore, alle dimensioni e all’area geografica. Anche chi non è cliente può completare una valutazione gratuita e ricevere un rapporto personalizzato di confronto. Il rapporto e la valutazione sono disponibili tramite la risorsa di CYGNVS dedicata alla resilienza.

L’indicazione più utile è mettere alla prova azioni concrete: chi può sospendere un agente, dove possono comunicare i responsabili della risposta se i sistemi aziendali sono compromessi, quali registrazioni restano disponibili e se gli specialisti esterni possono intervenire senza dover improvvisare procedure di accesso d’emergenza. Misurare queste capacità offre ai consigli di amministrazione e ai responsabili della sicurezza un quadro della preparazione più chiaro della semplice esistenza di una policy.

Man mano che le organizzazioni ampliano i poteri dell’IA, anche la preparazione alla risposta deve crescere di pari passo. Il CYGNVS Resilience Benchmark Report rende evidente questo divario. Per colmarlo, i team devono trasformare le intenzioni scritte in decisioni e controlli già sperimentati.