Wavestone AI Cyber Benchmark 2026 rileva una governance più avanzata della sicurezza operativa
Wavestone ha pubblicato un benchmark 2026 che evidenzia un netto contrasto: le organizzazioni governano l'IA molto meglio di quanto la proteggano dopo la distribuzione. Il Wavestone AI Cyber Benchmark 2026 ha rilevato meccanismi di governance nell'88% del suo panel. Tuttavia, solo l'8% collega i log delle applicazioni IA al monitoraggio dei security operations center.
Questo divario conta perché le organizzazioni si stanno assumendo maggiori responsabilità per i propri sistemi di IA. La metà delle organizzazioni valutate ora progetta sistemi con framework esistenti o modelli preaddestrati, rispetto al 35% del 2025. Un ulteriore 40% gestisce l'intera catena di sviluppo.
Il benchmark misura quindi più dei semplici progressi nella redazione delle policy. Rileva un trasferimento del rischio operativo dai fornitori tecnologici verso i team aziendali di engineering, sicurezza, dati e business. Questi team possiedono ora sistemi in grado di recuperare informazioni sensibili, chiamare strumenti e compiere azioni.
La conclusione centrale di Wavestone è scomoda. La governance può autorizzare un sistema di IA, ma l'autorizzazione non rende quel sistema osservabile, ripristinabile o sicuro durante un incidente. Le organizzazioni che avanzano più rapidamente verso modelli personalizzati e flussi di lavoro agentici affrontano la versione più ampia di questo problema.
Il Wavestone AI Cyber Benchmark 2026 espone un ampio divario nei controlli
Le organizzazioni hanno istituito la governance dell'IA più rapidamente dei controlli operativi necessari per contenere i guasti, indagare sugli incidenti e ripristinare sistemi affidabili.
Wavestone ha pubblicato il benchmark il 14 settembre 2026. Il suo panel comprende 30 grandi organizzazioni pubbliche e private. La valutazione incorpora inoltre osservazioni maturate dal lavoro di consulenza dell'azienda sulla sicurezza dell'IA nei tre anni precedenti.
Il framework utilizza cinque funzioni adattate dal NIST Cybersecurity Framework. Ogni funzione contiene oltre 30 domande di valutazione, misurate su una scala di maturità da zero al 100%.
I risultati diminuiscono man mano che le funzioni si avvicinano alle operazioni di sicurezza in produzione:
Govern ha ottenuto il 54%.
Identify ha ottenuto il 55%.
Protect ha ottenuto il 48%.
Detect ha ottenuto il 40%.
Respond ha ottenuto il 29%.
Il punteggio più alto riguarda l'identificazione del rischio, mentre quello più basso riguarda la risposta quando il rischio diventa un evento reale. Questa distribuzione supporta la conclusione del partner di Wavestone Gérôme Billois: le organizzazioni sono più preparate a governare l'IA che a gestirla in sicurezza in produzione.
I risultati dettagliati rendono il contrasto ancora più netto. Secondo il benchmark 2026, l'88% del panel aveva implementato meccanismi di governance dell'IA. Tuttavia, solo il 32% disponeva di attività, stakeholder e modelli di responsabilità chiaramente definiti.
Questa distinzione separa una policy da un modello operativo. Una policy può richiedere revisioni di sicurezza senza identificare chi monitora un sistema approvato. Può imporre l'escalation senza stabilire chi indaga su una knowledge base compromessa.
Anche il quadro delle competenze rimane disomogeneo. Solo il 44% delle organizzazioni ha identificato esperti dedicati alla sicurezza dell'IA in grado di supportare i team tecnici e business durante l'intero ciclo di vita del sistema.
Le organizzazioni hanno compiuto maggiori progressi nei test. Due terzi svolgono penetration test dedicati alla sicurezza dell'IA, mentre la metà conduce valutazioni avanzate focalizzate sull'IA. Il cinquanta per cento include valutazioni dell'IA nei programmi ricorrenti di audit e penetration testing.
Tuttavia, un test fotografa un sistema in un momento specifico. Modelli, fonti di retrieval, autorizzazioni, integrazioni e comportamento degli utenti cambiano dopo la distribuzione. Una valutazione superata non può sostituire la visibilità continua su tali cambiamenti.
Anche la metodologia del benchmark richiede prudenza. Le sue percentuali descrivono 30 organizzazioni valutate, non l'intero mercato globale. Wavestone avverte esplicitamente di non interpretare il panel come una stima rappresentativa del mercato.
Anche con questa limitazione, il modello interno è significativo. I controlli associati all'approvazione e alla valutazione sono molto più comuni di quelli associati al rilevamento, all'indagine e al ripristino. Questa è la vera notizia del benchmark.
Le aziende stanno passando dal consumo alla proprietà dell'IA
Il divario di sicurezza diventa più rilevante man mano che le imprese costruiscono una parte maggiore dello stack IA e assumono responsabilità precedentemente gestite dai fornitori.
Nel 2025, il 30% del panel di Wavestone utilizzava soltanto funzionalità IA fornite tramite prodotti esistenti. Questa quota è scesa al 10% nel 2026. Il cambiamento segnala un passaggio deciso oltre il consumo passivo.
La metà del panel del 2026 progetta internamente sistemi di IA utilizzando framework esistenti o modelli preaddestrati. Questa proporzione è aumentata dal 35% dell'anno precedente. Le organizzazioni che gestiscono l'intera catena di sviluppo sono passate dal 35% al 40%.
Queste categorie comportano obblighi di sicurezza differenti. Un'azienda che consuma una funzionalità IA gestisce principalmente l'esposizione dei dati, l'accesso degli utenti, la configurazione e il rischio del fornitore. Un'organizzazione che costruisce un sistema di retrieval deve inoltre proteggere la pipeline dati, il database vettoriale, le connessioni ai modelli e la logica applicativa.
Un database vettoriale archivia rappresentazioni matematiche utilizzate per recuperare informazioni pertinenti a una risposta dell'IA. Se gli aggressori manipolano tale archivio, il sistema può recuperare materiale avvelenato senza compromettere il modello sottostante.
Il problema della proprietà si estende ai repository di conoscenza. Le organizzazioni spesso trattano i documenti interni come informazioni aziendali governate, ma non come componenti attivi di una superficie d'attacco dell'IA. Il retrieval cambia questa ipotesi, perché le informazioni archiviate possono influenzare direttamente il comportamento del sistema.
Wavestone ha rilevato che il 72% del panel aveva iniziato a implementare misure di privacy per l'addestramento dell'IA. Il sessantacinque per cento eseguiva controlli sulla qualità dei dataset. Solo il 9% valutava sistematicamente sia la qualità sia la sicurezza dei dataset prima della produzione.
I controlli di qualità verificano se i dati sono accurati, completi e adatti a un compito. I controlli di sicurezza verificano se i dati sono stati manipolati, esposti o ottenuti attraverso un percorso non autorizzato. Un processo non può sostituire l'altro.
I controlli dei fornitori offrono un altro esempio. Le piattaforme cloud e di modelli forniscono autenticazione, logging, filtri e protezioni di configurazione. Tuttavia, tali protezioni coprono solo le responsabilità mantenute dal fornitore.
Solo l'11% del panel di Wavestone aveva iniziato a valutare o implementare protezioni oltre i controlli nativi del fornitore. Ciò diventa una preoccupazione maggiore quando i team effettuano fine-tuning dei modelli, ospitano autonomamente componenti o collegano agenti a strumenti interni.
Il benchmark non sostiene che le organizzazioni debbano evitare lo sviluppo interno. Costruire sistemi può migliorare il controllo su architettura, ubicazione dei dati e dipendenze. Rende inoltre l'organizzazione responsabile della protezione di ogni componente aggiunto.
Le conclusioni del 2025 di Wavestone indicavano già questo problema. Distinguevano gli utenti di IA dalle organizzazioni che orchestrano modelli di terze parti e dai costruttori avanzati che creano sistemi proprietari.
I risultati del 2026 mostrano che un numero maggiore di organizzazioni è entrato nelle categorie più impegnative. I loro programmi di sicurezza non sono avanzati in modo uniforme con questa transizione.
Ecco perché la sicurezza operativa dell'IA ora crea pressione su diversi team. L'engineering deve produrre telemetria utilizzabile. Le security operations devono interpretarla. I team di identità devono limitare le autorizzazioni, mentre i responsabili business devono decidere cosa gli agenti possono fare.
Anche la documentazione e la conoscenza operativa ricercabile diventano importanti durante questa transizione. I team necessitano di registri aggiornati di ownership, dipendenze di sistema, decisioni e procedure di risposta. Una knowledge base ricercabile ben mantenuta può supportare questo lavoro, anche se non può sostituire i controlli di sicurezza.
La governance della sicurezza dell'IA non equivale al controllo in produzione
La sfida principale è tra governance documentata e controllo applicato in modo continuo, non tra organizzazioni con o senza policy sull'IA.
La governance crea confini necessari. Può definire gli usi accettabili, classificare la criticità del sistema, assegnare requisiti di revisione e stabilire percorsi di escalation. Queste basi sono preziose, ma non gestiscono automaticamente il sistema.
Il controllo operativo pone domande diverse. L'organizzazione può rilevare comportamenti sospetti? Può isolare un agente? Gli investigatori possono ricostruire ciò che è accaduto? I team possono ripristinare un modello, un dataset o un repository di conoscenza affidabile?
Il Wavestone AI Cyber Benchmark 2026 ha rilevato che l'88% delle organizzazioni raccoglie i log delle applicazioni IA. Solo l'8% inoltra tali log al monitoraggio dei security operations center.
Non si tratta principalmente di un fallimento nella raccolta dei dati. È un fallimento di integrazione tra le operazioni IA e le operazioni di sicurezza.
I team delle applicazioni IA monitorano comunemente latenza, costi, qualità dell'output, richieste non riuscite e prestazioni del modello. I team di sicurezza cercano identità compromesse, accessi anomali, input malevoli, estrazione di dati e modifiche non autorizzate.
Lo stesso evento può apparire diverso a ciascun gruppo. Un picco nelle chiamate agli strumenti potrebbe indicare un flusso di lavoro popolare, un ciclo difettoso dell'agente o un attacco. Un rilevamento efficace richiede contesto sia dall'applicazione sia dall'ambiente di sicurezza.
Anche il logging necessita di uno scopo definito. Raccogliere prompt senza eventi di accesso, invocazioni di strumenti, versioni dei modelli, fonti di retrieval o decisioni di autorizzazione può lasciare agli investigatori un quadro incompleto.
Il AI RMF Core del NIST considera il monitoraggio post-distribuzione, la risposta agli incidenti, il ripristino e la gestione del cambiamento come risultati interconnessi. Richiede inoltre processi documentati per tracciare e ripristinare incidenti ed errori.
Questo approccio basato sul ciclo di vita contrasta con l'approvazione una tantum. Un sistema di IA può cambiare senza una tradizionale release software. Un fornitore può aggiornare un modello, un team può sostituire una fonte di retrieval oppure gli amministratori possono ampliare le autorizzazioni di un agente.
Questi cambiamenti possono invalidare ipotesi precedenti. Una revisione che ha approvato il retrieval di documenti in sola lettura dice poco su un flusso di lavoro successivo in grado di modificare record o inviare messaggi.
Lo stesso problema riguarda i test. Due terzi del panel di Wavestone conducono penetration test dedicati alla sicurezza dell'IA. Tuttavia, il benchmark sostiene che le organizzazioni mature debbano rendere i test ricorrenti anziché eccezionali.
I test ricorrenti dovrebbero seguire cambiamenti sostanziali. Tali cambiamenti includono nuovi modelli, strumenti, dataset, fine-tuning, ambiti di accesso e passaggi autonomi. Il programma di test deve inoltre coprire l'intero portafoglio IA dell'organizzazione.
La scansione automatizzata può individuare componenti vulnerabili ed errori di configurazione. Non può riprodurre pienamente interazioni avversarie che coinvolgono istruzioni ambigue, contesto avvelenato o diversi strumenti connessi.
Il red teaming dell'IA affronta queste interazioni attraverso test avversari strutturati. Tuttavia, anche il red teaming fornisce evidenze sulle condizioni testate, non una garanzia permanente. Monitoraggio e risposta devono gestire i comportamenti che i test non rilevano.
Il divario tra governance e operazioni riflette quindi attività diverse. La governance decide ciò che dovrebbe accadere. La sicurezza operativa rileva quando la realtà si discosta da quella decisione e offre ai team un modo per intervenire.
L'IA agentica trasforma controlli di identità deboli in rischio aziendale
Un agente IA con accesso eccessivo può trasformare un input fuorviante o un errore del modello in un'azione aziendale non autorizzata.
L'AI agentica si riferisce a sistemi che pianificano attività, chiamano strumenti e compiono azioni con una supervisione umana limitata. Questa capacità sposta l'obiettivo della sicurezza dal controllo del testo generato al controllo dei comportamenti autorizzati.
Il trentatré per cento del panel di Wavestone aveva incorporato il rischio dell'AI agentica nei framework di governance. Solo il 17% includeva l'accesso sicuro a funzioni e strumenti AI negli standard di sviluppo.
Il tasso di implementazione cala ulteriormente per i controlli dell'identità. Appena il 15% disponeva di salvaguardie dedicate alla gestione delle identità e degli accessi per sistemi e agenti AI.
Questo divario conta perché gli agenti collegano decisioni probabilistiche dei modelli a sistemi aziendali deterministici. Un modello può selezionare un'azione da un contesto incerto, ma il database o workflow a valle esegue concretamente tale azione.
Il rischio non richiede un modello malevolo. Un documento manipolato, un'iniezione indiretta di prompt, una richiesta ambigua o un passaggio di pianificazione difettoso possono reindirizzare un agente altrimenti legittimo.
OWASP descrive l'eccessiva agentività come un comportamento dannoso reso possibile da funzionalità, autorizzazioni o autonomia eccessive. Le sue linee guida raccomandano strumenti circoscritti, privilegi minimi, autorizzazione a valle e monitoraggio delle attività.
Questi controlli collocano l'applicazione delle regole al di fuori del modello. Questa scelta progettuale è importante perché chiedere a un modello di controllare le proprie autorizzazioni crea una dipendenza circolare.
Si consideri un agente interno di ricerca che legge file e prepara sintesi. Ha bisogno di accedere a repository approvati, ma probabilmente non necessita di diritti di eliminazione. Il suo connettore per i file dovrebbe esporre solo le operazioni necessarie.
Un agente per il servizio clienti presenta un rischio diverso. Potrebbe leggere informazioni sugli account, emettere crediti e modificare impostazioni del servizio. Ogni azione necessita di un limite definito, di un controllo di autorizzazione e di una registrazione di audit.
Un agente software può interagire con codice sorgente, sistemi di tracciamento dei problemi, sistemi di distribuzione e infrastruttura cloud. L'uso di un'unica identità privilegiata tra questi sistemi rende difficile l'attribuzione e aumenta il potenziale impatto di un singolo errore.
Il principio del privilegio minimo limita ogni agente al più piccolo insieme necessario di risorse e azioni. Credenziali di breve durata riducono il tempo di esposizione. Identità per singolo agente rendono le attività più facili da tracciare.
Le azioni ad alto impatto possono inoltre richiedere l'approvazione umana. Il controllo dovrebbe essere applicato prima dell'esecuzione, non dopo che il modello ha già modificato un sistema critico.
Wavestone sottolinea che le azioni degli agenti dovrebbero restare delimitate, tracciabili e interrompibili. L'interruzione richiede più di un pulsante di arresto nell'interfaccia utente. I team di sicurezza necessitano di un modo affidabile per revocare le credenziali e bloccare l'accesso a valle.
La AI Controls Matrix offre un framework di controllo più ampio per i sistemi AI basati sul cloud. La sua edizione 2026 include 247 obiettivi in 18 domini di sicurezza.
La disponibilità di framework non è tuttavia il principale vincolo. Il benchmark mostra che le organizzazioni riconoscono già molti rischi a livello di governance. L'implementazione nell'architettura applicativa e nelle operazioni di sicurezza resta il compito più difficile.
L'AI agentica rende urgente questa implementazione. Un chatbot con controlli deboli può divulgare informazioni o produrre una risposta dannosa. Un agente con controlli deboli può anche agire in base a quella risposta.
La risposta agli incidenti e il ripristino restano gli anelli più deboli
Le organizzazioni non possono affermare di avere resilienza operativa quando la maggioranza non dispone di indagini specifiche per l'AI, piani di risposta e pratiche di ripristino standardizzate.
Il benchmark di Wavestone assegna a Respond il punteggio di maturità più basso, pari al 29%. Le relative misure di supporto spiegano il perché.
Solo l'8% delle organizzazioni valutate era in grado di svolgere indagini forensi sulle piattaforme AI. La forensica AI implica la ricostruzione di prompt pertinenti, contenuti recuperati, attività degli strumenti, versioni dei modelli, autorizzazioni e modifiche di sistema.
Metà del panel utilizzava ancora misure correttive ad hoc senza un processo di risposta strutturato. Solo il 13% disponeva di piani documentati di risposta agli incidenti specifici per l'AI, e Wavestone afferma che tali piani non venivano applicati con costanza.
Anche il ripristino era limitato. Il ventidue per cento eseguiva backup di asset correlati all'AI, con pratiche in larga misura non standardizzate.
Un backup di un'applicazione tradizionale può preservare codice e database. Un servizio AI può dipendere da asset aggiuntivi, tra cui configurazioni dei modelli, dati di fine-tuning, embedding, policy di sicurezza, prompt e fonti di conoscenza esterne.
Ripristinare la disponibilità non ristabilisce la fiducia. Un repository di conoscenza recuperato può ancora contenere documenti avvelenati. Un agente ripristinato può conservare credenziali compromesse o autorizzazioni non sicure.
La prima sfida della risposta è la classificazione. I team devono distinguere gli eventi di sicurezza dai guasti di affidabilità, dalle violazioni delle policy, dagli errori dei modelli e dai normali errori degli utenti. Alcuni incidenti attraversano più categorie.
Un'azione non autorizzata di un agente potrebbe iniziare con un'iniezione di prompt, esporre dati e creare record errati. I responsabili della risposta potrebbero aver bisogno di competenze in sicurezza, privacy, aspetti legali, ingegneria, rischio dei modelli e business.
La seconda sfida è l'evidenza. Gli investigatori necessitano di registrazioni sincronizzate tra servizi di modello, sistemi di identità, componenti di retrieval, gateway degli strumenti e applicazioni di destinazione. Il contesto mancante può impedire la ricostruzione.
La percentuale dell'88% relativa al logging indicata da Wavestone può quindi apparire più rassicurante di quanto sia. Il logging aiuta la risposta solo quando i team conservano gli eventi giusti, li correlano e li rendono disponibili agli investigatori.
La terza sfida è il contenimento. Le organizzazioni devono sapere come disabilitare un agente, revocare le sue credenziali, mettere in quarantena un dataset, cambiare modello o sospendere uno strumento connesso senza causare interruzioni più ampie.
La quarta sfida è il ripristino. I team necessitano di uno stato noto e affidabile e di un test di integrità prima di rimettere il sistema in servizio. Altrimenti, il ripristino può reintegrare la stessa vulnerabilità o informazioni compromesse.
Questa complessità operativa spiega perché la maturità della risposta sia indietro rispetto alla governance. Le policy possono spesso estendere le strutture esistenti di gestione del rischio. La risposta agli incidenti AI richiede nuove evidenze tecniche, procedure tra team diversi ed esercitazioni.
Il piccolo panel del benchmark rimane un limite importante. Queste percentuali non dovrebbero trasformarsi in affermazioni su ogni grande impresa. Anche le organizzazioni che si sono offerte volontariamente per valutazioni dettagliate possono differire dal mercato più ampio.
Anche la misurazione è cambiata. Wavestone ha ampliato la propria valutazione del 2026 includendo sicurezza degli agenti, protezioni specializzate, monitoraggio e risposta. I confronti diretti anno su anno dovrebbero quindi concentrarsi su misure chiaramente corrispondenti.
Tuttavia, il modello è coerente con linee guida consolidate sul rischio. Il profilo sull'AI generativa del NIST sottolinea la documentazione degli incidenti, il logging, la segnalazione e la condivisione di informazioni lungo il ciclo di vita.
L'interpretazione scettica non è che la governance abbia fallito. È che la maturità della governance può creare una falsa fiducia quando le evidenze operative restano scarse.
Una policy può soddisfare un traguardo interno. Non dimostra che un team di sicurezza sia in grado di rilevare un retrieval compromesso, tracciare le azioni di un agente o ripristinare un sistema affidabile.
Tre segnali mostreranno se le operazioni recuperano terreno
La prossima fase della maturità della sicurezza AI sarà misurata attraverso telemetria connessa, autorizzazioni degli agenti applicabili e ripristino testato.
Il primo segnale è la percentuale di organizzazioni che alimentano gli eventi AI nel monitoraggio attivo della sicurezza. Wavestone ha rilevato un divario di 80 punti tra la raccolta dei log delle applicazioni e la loro integrazione nel monitoraggio SOC.
Colmare questo divario richiede casi di rilevamento definiti, non il semplice inoltro di ogni record. I team dovrebbero identificare gli eventi che indicano retrieval sospetto, escalation dei privilegi, uso insolito di strumenti o tentativi di estrazione dei dati.
Le prove di miglioramento includerebbero avvisi testati, playbook di indagine e responsabilità condivisa tra team AI e SOC. Un altro documento di policy non risolverebbe il divario operativo.
Il secondo segnale è l'adozione di controlli di identità dedicati agli agenti. L'attuale risultato del 15% mostra che il riconoscimento a livello di governance ha preceduto l'applicazione tecnica.
I progressi dovrebbero manifestarsi attraverso identità distinte per gli agenti, accessi strettamente circoscritti, credenziali di breve durata e autorizzazioni all'interno dei servizi a valle. Le azioni ad alto impatto dovrebbero avere requisiti espliciti di approvazione.
Questo segnale diventerà più importante man mano che le organizzazioni introdurranno agenti nella finanza, nelle operazioni con i clienti, nella distribuzione del software e nei workflow di conoscenza interna. Ogni strumento aggiuntivo amplia le conseguenze di un accesso eccessivo.
Il terzo segnale è se le organizzazioni esercitano il ripristino dagli incidenti specifico per l'AI. Un piano scritto è utile, ma i team devono testare contenimento, indagine, ripristino e convalida dell'integrità.
Le esercitazioni dovrebbero coprire dataset compromessi, fonti di conoscenza avvelenate, credenziali divulgate, modifiche non sicure dei modelli e azioni non autorizzate degli agenti. Dovrebbero inoltre verificare se l'organizzazione può continuare il lavoro critico durante il contenimento.
Questi segnali rafforzeranno o indeboliranno il giudizio centrale di Wavestone. Una maggiore integrazione del monitoraggio dimostrerebbe che la governance si sta trasferendo nelle operazioni. Controlli dell'identità migliori dimostrerebbero che le policy sugli agenti stanno diventando applicabili.
Esercitazioni di ripristino riuscite fornirebbero l'evidenza più solida. Dimostrerebbero che le organizzazioni possono mantenere il controllo quando la prevenzione fallisce, anziché presumere che ogni salvaguardia funzionerà.
Il Wavestone AI Cyber Benchmark 2026 presenta un compromesso che i leader aziendali non possono risolvere soltanto rallentando l'adozione. Un maggiore sviluppo interno può migliorare l'autonomia e il controllo architetturale, ma trasferisce anche la responsabilità verso l'interno.
I responsabili della sicurezza dovrebbero chiedere prove a sostegno di ogni traguardo di governance. Quali sistemi inviano eventi utilizzabili al SOC? Quali autorizzazioni degli agenti possono essere revocate immediatamente? Quali asset AI dispongono di procedure di ripristino testate?
I responsabili di ingegneria e business dovrebbero porsi domande parallele. Chi possiede ciascun sistema distribuito dopo l'approvazione? Quali modifiche attivano una rivalutazione? Quale persona può fermare un'azione autonoma prima che raggiunga un'applicazione critica?
La domanda decisiva non è più se un'organizzazione abbia una policy AI. È se tale organizzazione sia in grado di rilevare, contenere, indagare e ripristinare quando un sistema AI si comporta al di fuori delle aspettative.
