Il rapporto IBM sulle violazioni del 2026 segnala un divario del 92% nei controlli di accesso all’AI
Il rapporto IBM sulle violazioni del 2026 è arrivato su Google News con un dato allarmante: secondo quanto riportato, il 92% delle organizzazioni colpite tramite sistemi AI non disponeva di adeguati controlli di accesso.
Il dato è rilevante perché le aziende non usano più l’AI soltanto per redigere testi o riassumere documenti. Modelli e agenti si connettono sempre più spesso a dati aziendali, servizi cloud, strumenti software e flussi di lavoro di produzione. Errori negli accessi possono quindi esporre informazioni o autorizzare azioni in diversi sistemi.
Il titolo riflette anche un più ampio paradosso dell’AI aziendale. Le aziende hanno adottato l’AI per aumentare la produttività e rafforzare la sicurezza, ma molte l’hanno implementata senza le protezioni di identità richieste di routine per dipendenti e applicazioni convenzionali. I risultati di IBM suggeriscono che gli aggressori abbiano notato questa lacuna.
Il titolo di IBM su Google News segnala un cambiamento più ampio nella sicurezza dell’AI
La statistica sui controlli di accesso è allarmante, ma i risultati più ampi di IBM mostrano che l’AI ora influenza entrambi i lati di una violazione dei dati.
IBM ha pubblicato il suo Cost of a Data Breach Report 2026 il 29 luglio. La ricerca è stata condotta dal Ponemon Institute, quindi sponsorizzata e analizzata da IBM. Ha esaminato le violazioni subite da 602 organizzazioni in 17 settori tra marzo 2025 e febbraio 2026.
Il dato riportato del 92% riguarda organizzazioni che hanno subito attacchi che coinvolgevano i loro modelli o applicazioni AI. In termini pratici, tali organizzazioni non disponevano di controlli in grado di limitare in modo affidabile chi o cosa potesse accedere ai sistemi AI interessati.
Il controllo degli accessi determina se una persona, un’applicazione o un’identità macchina possa raggiungere una risorsa. Definisce inoltre quali azioni quell’identità possa eseguire. Per un agente AI, tali autorizzazioni potrebbero includere la lettura di record dei clienti, la chiamata a un’interfaccia di programmazione delle applicazioni, la modifica di un ticket o l’attivazione di un flusso di lavoro automatizzato.
La statistica non dovrebbe essere interpretata come prova che il 92% di tutte le aziende non disponga di controlli di accesso per l’AI. IBM ha studiato organizzazioni che avevano subito violazioni, e il dato si applica a un gruppo più ristretto con incidenti correlati all’AI. Questa distinzione è importante per valutare la diffusione del problema.
Anche all’interno di quel gruppo più ristretto, il risultato descrive un grave fallimento dei controlli. Oltre il 20% delle organizzazioni del campione IBM ha segnalato una violazione che prendeva di mira modelli o applicazioni AI. API, applicazioni o plug-in compromessi hanno rappresentato il 27% delle cause citate. Le configurazioni errate del cloud che interessavano i carichi di lavoro AI hanno rappresentato un altro 27%.
Questi risultati spostano l’attenzione da scenari drammatici in cui un modello aggira spontaneamente la sicurezza. Le debolezze più immediate si trovano spesso attorno al modello. Gli aggressori possono sfruttare interfacce esposte, account di servizio con privilegi eccessivi, plug-in vulnerabili e risorse cloud configurate in modo errato.
Il rapporto sulle violazioni del 2026 di IBM colloca inoltre in prospettiva la posta finanziaria. Il costo medio globale di una violazione ha raggiunto 4,99 milioni di dollari, con un aumento annuo del 12%. IBM ha descritto tale cifra come un record storico.
Gli incidenti correlati all’AI hanno ulteriormente modificato l’economia del fenomeno. IBM ha riferito che una violazione dolosa su quattro era abilitata dall’AI, con un aumento del 56% rispetto all’anno precedente. Questi incidenti sono costati alle organizzazioni in media 6 milioni di dollari, circa 1 milione in più della media globale.
Ciò non significa che ogni attacco abilitato dall’AI prendesse direttamente di mira un modello AI. IBM usa la categoria per includere gli attacchi in cui gli attori delle minacce hanno impiegato l’AI, comprese l’impersonificazione tramite deepfake e il malware assistito dall’AI. La distinzione separa gli attacchi che usano l’AI da quelli contro i sistemi AI.
Insieme, le categorie descrivono un rischio su due fronti. Gli aggressori possono usare l’AI per aumentare la velocità o la scala di tattiche consolidate. Possono anche prendere di mira i modelli, gli agenti, gli archivi dati e le interfacce che le aziende stanno rapidamente aggiungendo alla propria infrastruttura.
Per questo il taglio di Google News non dovrebbe essere ridotto a una sola percentuale sensazionalistica. L’evento sottostante è un cambiamento della superficie d’attacco aziendale, con l’AI che diventa sia uno strumento dell’aggressore sia un bersaglio.
Il vero punto debole si trova attorno al modello
I numeri di IBM indicano che i consueti fallimenti relativi a identità, API e cloud restano centrali nelle violazioni AI apparentemente nuove.
Le discussioni sulla sicurezza dell’AI si concentrano spesso sul comportamento dei modelli, come allucinazioni, output dannosi o prompt injection. Questi rischi restano rilevanti, ma i dati di IBM indicano un problema meno esotico. Le organizzazioni stanno collegando l’AI a risorse di valore senza applicare con coerenza controlli di sicurezza consolidati.
Un modello da solo di norma non può accedere a un database clienti o distribuire software. Ottiene tale capacità attraverso componenti circostanti. Questi includono plug-in, credenziali API, sistemi di recupero, ruoli cloud, account di servizio e livelli di orchestrazione degli agenti.
Ogni connessione amplia il numero di decisioni che un’organizzazione deve governare. Quali documenti può recuperare il sistema? Può vedere i record appartenenti a ogni cliente? Può chiamare un servizio esterno? Può scrivere dati o solo leggerli? Il suo accesso scade al termine di un’attività?
Un’identità agentica è l’identità digitale assegnata a un agente AI che agisce tra sistemi connessi. I programmi tradizionali di gestione delle identità si concentrano di solito su dipendenti, collaboratori esterni, dispositivi e carichi di lavoro software. Gli agenti introducono un’altra categoria in grado di prendere decisioni e invocare strumenti con un coinvolgimento umano limitato.
IBM raccomanda controlli dinamici basati sull’identità per questi agenti. Invita inoltre a usare autorizzazioni strettamente delimitate, applicazione in fase di esecuzione, attribuzione umana e attività verificabile. L’applicazione in fase di esecuzione significa verificare le autorizzazioni mentre un agente opera, anziché approvare un accesso ampio una sola volta durante la distribuzione.
Questo approccio affronta una discrepanza fondamentale. Un dipendente in genere si autentica tramite un account noto, mentre un agente può agire attraverso diverse credenziali condivise. Se i log registrano soltanto l’account di servizio condiviso, gli investigatori potrebbero avere difficoltà a identificare quale agente abbia avviato un’azione o quale dipendente l’abbia richiesta.
Il risultato è un divario di responsabilità. Un’azienda potrebbe sapere che un token API ha avuto accesso a dati sensibili senza sapere quale modello, flusso di lavoro o utente abbia causato la richiesta. Ciò rende più difficile fermare attività inappropriate e ricostruire una violazione successiva.
Il principio del privilegio minimo offre una risposta nota. Tale principio assegna a ciascuna identità solo l’accesso necessario per un compito definito. Applicarlo all’AI può però essere difficile, perché gli agenti svolgono spesso attività variabili e composte da più passaggi.
Autorizzazioni ampie rendono un agente più utile in un maggior numero di situazioni. Aumentano però anche il potenziale danno causato da un prompt manipolato, una credenziale rubata, una decisione errata o un’integrazione compromessa. Lo stesso accesso che abilita l’automazione può ampliare il raggio d’impatto della violazione.
Si consideri un assistente di ricerca interno collegato a documenti, e-mail, record dei clienti e sistemi di progetto. Una configurazione restrittiva potrebbe consentirgli di recuperare file approvati per un singolo team. Una configurazione ampia potrebbe esporre informazioni nei repository di area legale, finanza, ingegneria e vendite.
La differenza di sicurezza non è nella capacità di scrittura del modello. È nella qualità del confine di identità che circonda i suoi dati e strumenti.
Anche l’accesso alla conoscenza merita particolare attenzione. Le organizzazioni vogliono che gli assistenti trovino il contesto pertinente senza esporre ogni fonte a ogni utente. Una base di conoscenza AI progettata con cura dovrebbe preservare le autorizzazioni sulle fonti invece di creare un nuovo percorso per aggirarle.
Lo stesso problema emerge nei flussi di lavoro autonomi. Un agente che gestisce richieste di assistenza potrebbe dover leggere il profilo di un cliente e proporre una risposta. Non necessita automaticamente dell’autorizzazione per esportare il database clienti, modificare i dati di fatturazione o disattivare le impostazioni di sicurezza.
L’AI può rendere sfumati questi confini perché il contesto utile viene spesso trattato come un unico bacino. Quando le autorizzazioni scompaiono durante l’indicizzazione, il recupero o l’esecuzione dell’agente, il sistema può rivelare informazioni a cui l’utente richiedente non potrebbe accedere direttamente.
L’avvelenamento del contesto crea un altro rischio. Si verifica quando informazioni fuorvianti o dannose entrano nel materiale che un’AI usa per prendere decisioni. Un aggressore potrebbe inserire istruzioni all’interno di un documento che un agente recupera in seguito.
Il tradizionale filtraggio degli output non affronta completamente questo scenario. L’organizzazione deve controllare quali fonti l’agente ritiene affidabili, quali strumenti può invocare e se le azioni sensibili richiedano approvazione. I log devono inoltre conservare abbastanza contesto da spiegare la decisione.
Le protezioni di un modello e i controlli di accesso di un’azienda servono a scopi diversi. Le protezioni possono influenzare il contenuto prodotto da un modello. I controlli di accesso decidono se esso possa raggiungere un sistema retributivo, un repository di codice sorgente o una console di produzione.
Confondere i due aspetti può creare una falsa fiducia. Un modello ben comportato con autorizzazioni eccessive resta pericoloso se le sue credenziali vengono rubate o i suoi input manipolati. Al contrario, un accesso strettamente delimitato può limitare i danni anche quando un modello si comporta in modo inatteso.
Il rapporto IBM mette quindi in discussione l’idea che la sicurezza dell’AI richieda un universo di sicurezza del tutto separato. Molti fallimenti riguardano ancora l’inventario delle risorse, la gestione delle credenziali, la configurazione cloud, il monitoraggio e la risposta agli incidenti. La nuova difficoltà consiste nell’applicare questi controlli a sistemi che agiscono con maggiore autonomia.
L’adozione dell’AI prometteva velocità, ma i team di sicurezza hanno ereditato il rischio
Il conflitto principale è tra la rapida distribuzione dell’AI e il lavoro più lento di definire identità, autorizzazioni, responsabilità ed evidenze.
I team aziendali hanno forti incentivi a distribuire rapidamente l’AI. I dipendenti usano già assistenti per consumatori, estensioni del browser, servizi di trascrizione e funzionalità AI integrate nel software aziendale. Le unità operative possono spesso attivare questi servizi prima che i team di sicurezza li abbiano inventariati.
Questo comportamento produce shadow AI, ossia strumenti o modelli AI utilizzati senza approvazione formale o governance. Assomiglia allo shadow IT, ma l’esposizione può andare oltre l’archiviazione o l’acquisto di software. Un modello non autorizzato può elaborare dati sensibili, conservare prompt, chiamare strumenti o influenzare decisioni aziendali.
La ricerca IBM del 2025 ha stabilito un’importante base di riferimento. All’epoca, il 13% delle organizzazioni studiate ha segnalato violazioni che coinvolgevano modelli o applicazioni AI. Tra tali organizzazioni, il 97% ha dichiarato di non disporre di adeguati controlli di accesso all’AI.
I risultati del 2025 hanno anche rilevato che il 63% delle organizzazioni violate non disponeva di una policy di governance dell’AI o ne stava ancora sviluppando una. Solo il 34% delle organizzazioni con una policy effettuava audit regolari per individuare AI non autorizzata.
Un’organizzazione su cinque in quello studio ha segnalato una violazione che coinvolgeva shadow AI. Le organizzazioni con un uso elevato di shadow AI hanno registrato costi medi delle violazioni superiori di 670.000 dollari rispetto a quelle con un uso basso o nullo di shadow AI.
Il passaggio dal 97% nel sottogruppo colpito da violazioni del 2025 al 92% riportato nel 2026 suggerisce un miglioramento limitato, non un problema risolto. I campioni e le definizioni precise degli incidenti possono differire, quindi le percentuali non dovrebbero essere trattate come una misurazione pulita anno su anno.
Tuttavia, entrambi i dati indicano la stessa direzione. Quasi tutte le organizzazioni interessate nei gruppi pertinenti non disponevano di controlli adeguati sull’accesso all’AI. Questa coerenza è più significativa della differenza di cinque punti.
I team di sicurezza subiscono pressioni da più direzioni contemporaneamente. Devono individuare l’uso autorizzato e non autorizzato dell’AI, assegnare responsabili, classificare i dati connessi, governare le identità non umane, ispezionare i plug-in e monitorare le azioni in fase di esecuzione.
Nel frattempo, i team di prodotto stanno ampliando ciò che gli agenti possono fare. Un assistente che si limita a redigere testi dispone di un’autorità operativa limitata. Un agente che aggiorna le schede dei clienti, integra codice, pianifica pagamenti o modifica risorse cloud entra in una categoria di rischio diversa.
Questo crea un ritardo nella governance. Il procurement potrebbe approvare il software, mentre i team responsabili delle identità restano ignari dei suoi account di servizio. Uno sviluppatore potrebbe connettere un agente ai dati di produzione prima che il team privacy valuti il flusso.
L’organizzazione può ritrovarsi con diverse visioni incomplete. La sicurezza vede il traffico API, l’IT vede le licenze, il settore legale vede i contratti con i fornitori e i team aziendali vedono la produttività. Nessuno dispone di un inventario completo dell’agente, dei suoi dati, delle sue credenziali e delle azioni che gli sono consentite.
Le sole policy non possono colmare questa lacuna. Un documento potrebbe vietare ai dipendenti di caricare informazioni riservate su modelli pubblici. Non può fermare l’attività, tuttavia, a meno che l’azienda non sia in grado di rilevare lo strumento, classificare i dati e applicare la restrizione.
Anche i soli controlli tecnici non sono sufficienti senza una responsabilità chiara. Una piattaforma di sicurezza può segnalare accessi insoliti, ma qualcuno deve decidere quale sia l’attività normale per ciascun agente. Il responsabile deve sapere quali strumenti gli servono e quali azioni dovrebbero richiedere l’approvazione di una persona.
La tensione aumenta quando i dirigenti chiedono un’adozione dell’AI misurabile. I team possono considerare come progresso il numero di licenze abilitate, attività automatizzate o dipendenti che utilizzano il sistema. Queste metriche premiano ampiezza e velocità, mentre le revisioni delle autorizzazioni e la preparazione agli audit sembrano rallentare la distribuzione.
La ricerca di IBM suggerisce che il costo nascosto emerga dopo la distribuzione. La mancanza di una responsabilità definita rende gli incidenti più difficili da contenere. Le credenziali condivise rendono le azioni più difficili da attribuire. Gli accessi eccessivi consentono a un singolo componente compromesso di raggiungere più dati.
Le organizzazioni sottoposte alla maggiore pressione includono i servizi finanziari e le aziende energetiche. IBM ha rilevato che i settori delle infrastrutture critiche rappresentavano il 62% degli attacchi guidati dall’AI segnalati. Le violazioni nei servizi finanziari hanno registrato una media di 6,3 milioni di dollari, mentre quelle nel settore energetico hanno raggiunto in media 5,2 milioni di dollari.
Questi settori gestiscono sistemi interconnessi in cui un’interruzione può colpire clienti, catene di fornitura o servizi essenziali. Detengono inoltre dati finanziari, di identità, operativi e di proprietà intellettuale di grande valore. Le integrazioni AI possono creare nuove vie di accesso a questi ambienti.
Anche gli sviluppatori ereditano conseguenze pratiche. Le revisioni di sicurezza richiedono sempre più spesso diagrammi dell’architettura, inventari dei flussi di dati, documentazione sui modelli, titolarità delle credenziali e prove di test. Un team che non sa spiegare gli accessi di un agente avrà difficoltà a dimostrare che la distribuzione è contenuta.
Gli acquirenti aziendali dovrebbero quindi guardare oltre il fatto che un prodotto offra il single sign-on. Devono sapere se preserva le autorizzazioni a livello di origine, supporta ruoli granulari, separa i tenant, registra le chiamate agli strumenti e consente la rapida revoca delle credenziali.
Una casella di controllo nel procurement può confermare l’esistenza di un controllo. Non può stabilire che ogni agente utilizzi correttamente quel controllo. Il vero test è verificare se un’organizzazione possa tracciare una singola azione sensibile dalla persona richiedente, attraverso il modello, fino al sistema di destinazione.
L’AI sta aumentando e riducendo i costi delle violazioni
Il ribaltamento centrale di IBM è che l’AI amplifica gli attacchi, mentre l’automazione della sicurezza può ridurre in modo sostanziale i costi risultanti.
Il rapporto del 2026 non presenta l’AI come uniformemente dannosa. Le organizzazioni che hanno usato ampiamente AI e automazione nelle operazioni di sicurezza hanno risparmiato in media 1,93 milioni di dollari rispetto alle organizzazioni che non ne usavano affatto.
Questa conclusione crea il trade-off più importante del rapporto. Rifiutarsi di usare l’AI non elimina gli aggressori assistiti dall’AI né i servizi di terze parti vulnerabili. Distribuirla con superficialità, tuttavia, può aggiungere identità e percorsi dati non gestiti.
IBM afferma che gli attacchi abilitati dall’AI sono aumentati del 56% su base annua. L’impersonificazione tramite deepfake ha rappresentato la categoria più comune nella reportistica secondaria, citata dal 45% degli intervistati. Anche malware e phishing abilitati dall’AI hanno contribuito all’aumento.
Questi strumenti riducono il costo della produzione di messaggi personalizzati, dell’impersonificazione di persone fidate e della modifica di codice malevolo. Non eliminano la necessità di un punto di ingresso. Credenziali rubate, servizi esposti, software vulnerabile e inganno umano restano elementi essenziali di molti attacchi.
L’AI può anche aiutare i difensori a ordinare gli avvisi, rilevare comportamenti insoliti, correlare gli eventi e contenere gli incidenti. L’automazione è importante perché i costi delle violazioni aumentano quando le organizzazioni impiegano più tempo a individuare e risanare i sistemi compromessi.
La dirigente della sicurezza IBM Suja Viswesan ha descritto il problema come uno squilibrio economico. Gli aggressori possono avviare operazioni più rapidamente e a costi inferiori, mentre le vittime spendono milioni per individuare, contenere e riprendersi da una violazione.
La sua raccomandazione si concentra sulla riduzione del ritardo tra individuazione e risanamento. Ciò include l’integrazione delle correzioni nei flussi di lavoro di sviluppo, la protezione delle identità durante l’operatività e la risoluzione delle debolezze alla velocità con cui gli aggressori le sfruttano.
L’adozione rimane disomogenea. Una organizzazione su quattro nello studio IBM non aveva introdotto AI e automazione nelle operazioni di sicurezza. Più della metà utilizzava agenti per il rilevamento e il contenimento delle minacce, ma solo il 18% li applicava alla gestione delle vulnerabilità.
Questa lacuna è importante perché il rilevamento avviene dopo la comparsa di attività sospette. La gestione delle vulnerabilità affronta le debolezze note prima che un aggressore le sfrutti. Un rilevamento rapido non può compensare sistemi esposti che restano senza patch o configurati in modo errato.
Lo studio IBM ha inoltre rilevato che l’85% degli intervistati nella ricerca successiva prevedeva di aumentare la spesa per la sicurezza dopo aver appreso delle capacità avanzate dei modelli di frontiera. Solo il 64% aveva pianificato un aumento della spesa dopo aver subito una violazione nella ricerca iniziale.
Questo risultato suggerisce che le organizzazioni stiano iniziando a reagire alle capacità previste, non solo agli incidenti già completati. Tuttavia, l’intenzione di spesa non dimostra che gli investimenti miglioreranno i controlli delle identità o aggiungeranno semplicemente altri prodotti di rilevamento.
Anche la metodologia del rapporto merita attenzione. IBM e Ponemon hanno studiato organizzazioni che hanno subito violazioni, non un campione rappresentativo di tutte le aziende. Le stime dei costi combinano diverse categorie, tra cui rilevamento, escalation, attività perse, notifica e risposta post-violazione.
Il rapporto può identificare modelli all’interno del proprio campione. Non può dimostrare che l’aggiunta di un singolo prodotto di sicurezza produrrà i risparmi medi citati in ogni organizzazione. Le grandi imprese, i settori regolamentati e gli incidenti complessi possono avere strutture di costo molto diverse.
Anche gli incentivi dei fornitori dovrebbero restare visibili. IBM vende software e servizi di sicurezza relativi a identità, protezione dei dati, gestione cloud e risposta agli incidenti. Il suo rapporto può contenere ricerche di valore, sostenendo al tempo stesso una narrazione commerciale.
Questo non invalida i dati. Significa che i lettori dovrebbero separare i risultati misurati dalle affermazioni prescrittive. Il campione mostra associazioni tra un’ampia automazione della sicurezza e costi medi inferiori, ma la maturità organizzativa può contribuire a entrambi gli aspetti.
Un programma di sicurezza maturo è più propenso ad adottare efficacemente l’automazione. Può anche disporre di inventari migliori, personale formato, piani di risposta testati e supporto dei dirigenti. Questi fattori possono ridurre i costi delle violazioni indipendentemente dagli strumenti.
Anche il dato del 92% sui controlli degli accessi richiede analoga cautela. La percentuale non dimostra che i controlli mancanti abbiano causato ogni incidente. Dimostra una forte sovrapposizione tra violazioni correlate all’AI e controlli inadeguati nel gruppo interessato.
API compromesse e configurazioni cloud errate forniscono un meccanismo plausibile che collega controlli deboli e incidenti. Tuttavia, la causalità può variare. Un aggressore potrebbe sfruttare una vulnerabilità software anche in presenza di policy di identità, oppure rubare una credenziale legittimamente privilegiata.
La copertura indipendente ha evidenziato la stessa duplice minaccia. Un’analisi di settore ha osservato che i criminali stanno sia prendendo di mira i sistemi AI sia usando l’AI per accelerare attacchi già consolidati. Questa impostazione riflette meglio il rapporto rispetto alla semplice affermazione che i modelli stiano causando violazioni.
La conclusione pratica non è scegliere tra AI e sicurezza. Le imprese devono governare le distribuzioni dell’AI, utilizzando al contempo l’automazione dove migliora la difesa. Il risultato dipende dal fatto che le organizzazioni colleghino le capacità a un’autorità definita in modo rigoroso.
Cosa non dimostra il dato del 92%
Il titolo identifica una crisi dei controlli, ma non rivela la qualità dei controlli di ciascuna organizzazione né stabilisce un tasso di incidenti universale.
Le percentuali possono circolare su Google News più rapidamente delle loro definizioni. I lettori possono imbattersi nel dato del 92% senza vedere i confini del campione, il periodo di ricerca o la distinzione tra attacchi abilitati dall’AI e attacchi che prendono di mira l’AI.
La prima incertezza riguarda la terminologia. I “controlli di accesso AI adeguati” possono comprendere diverse pratiche, tra cui autenticazione, progettazione dei ruoli, rotazione delle credenziali, autorizzazioni sulle fonti, policy in fase di esecuzione e registrazione degli audit. Una misura binaria può nascondere grandi differenze di maturità.
Un’organizzazione potrebbe non avere controlli dedicati. Un’altra potrebbe utilizzare sistemi di identità consolidati, ma non applicarli a un plug-in. Entrambe potrebbero comparire nella stessa categoria di controlli inadeguati, anche se la loro postura di sicurezza è diversa.
La seconda incertezza riguarda il rilevamento. Le organizzazioni non possono segnalare incidenti che non scoprono mai. Le aziende con un monitoraggio più solido potrebbero identificare più attività correlate all’AI rispetto alle organizzazioni con visibilità limitata, creando un aumento apparente che riflette in parte una migliore osservazione.
L’otto per cento delle organizzazioni nello studio IBM del 2025 ha dichiarato di non sapere se modelli o applicazioni AI fossero stati compromessi. Questa incertezza illustra il problema dell’inventario. Un’azienda non può valutare un modello della cui esistenza non è a conoscenza.
La terza incertezza riguarda il significato di una violazione correlata all’AI. Un aggressore potrebbe prendere di mira un endpoint di modello, rubare dati di addestramento, sfruttare un’API associata o usare phishing generato dall’AI contro un dipendente. Questi eventi hanno meccanismi diversi e richiedono difese diverse.
L’inversione del modello, per esempio, tenta di dedurre informazioni sensibili dagli output di un modello. IBM ha riportato un costo medio globale di 6 milioni di dollari per violazioni che coinvolgono questo tipo di attacco. Questo scenario differisce da un bucket di archiviazione cloud esposto tramite un’applicazione AI configurata in modo errato.
L’impersonificazione tramite deepfake differisce ancora. Usa media sintetici per imitare una persona fidata, spesso per manipolare un dipendente o un processo aziendale. I controlli degli accessi possono limitare il danno conseguente, ma contano anche la verifica dell’identità e i controlli di processo.
La quarta incertezza riguarda i confronti delle tendenze. Il rapporto IBM del 2025 ha studiato 600 organizzazioni con violazioni avvenute da marzo 2024 a febbraio 2025. Il rapporto del 2026 ha studiato 602 organizzazioni nei 12 mesi successivi.
Questi campioni di dimensioni simili supportano un confronto generale, ma le organizzazioni partecipanti e il mix di incidenti possono cambiare. I lettori non dovrebbero considerare ogni variazione come una misura precisa del tasso globale di violazioni.
La quinta incertezza riguarda le medie dei costi. Un numero ristretto di incidenti costosi può aumentare una media. Settore, dimensioni dell’azienda, regolamentazione, interruzione operativa e tempi di recupero influenzano tutti l’importo finale.
La media globale di IBM è salita da 4,44 milioni di dollari nel 2025 a 4,99 milioni di dollari nel 2026. L’aumento è significativo, ma non significa che ogni azienda debba aspettarsi che un incidente costi esattamente quella cifra.
Un approccio più utile è interpretare i risultati come indicazioni di tendenza. I sistemi di IA stanno diventando componenti sostanziali dell’infrastruttura aziendale. Gli attaccanti interagiscono con questi sistemi e molte organizzazioni colpite non hanno esteso ad essi i controlli di base.
I responsabili della sicurezza dovrebbero verificare se il dato principale corrisponde al proprio ambiente. Riescono a elencare ogni modello e agente? Riescono a identificarne il responsabile? Possono vedere a quali fonti di dati accede ciascun sistema? Possono revocarne le credenziali senza disabilitare un’intera piattaforma?
Dovrebbero anche chiedersi se i log preservano l’attribuzione umana. Se un dipendente istruisce un agente ad aggiornare una scheda cliente, la traccia di audit dovrebbe collegare il dipendente, l’agente, la credenziale, la chiamata allo strumento e la modifica finale.
Il monitoraggio continuo è importante perché il comportamento di un agente può cambiare in base al suo contesto. Nuovi strumenti, prompt, fonti di dati e versioni del modello possono modificare ciò che fa, anche quando le sue autorizzazioni formali restano invariate.
Analisi esterne sulla sicurezza degli agenti hanno sottolineato l’importanza delle identità, di accessi rigidamente controllati, di azioni verificabili, di percorsi di escalation e di kill switch. Queste misure trattano l’autonomia come un rischio operativo, non semplicemente come un problema di qualità del modello.
Un kill switch è un meccanismo che arresta un agente o ne revoca la capacità di agire. Dovrebbe funzionare in modo rapido e prevedibile, soprattutto quando un agente può accedere a sistemi finanziari, di produzione o rivolti ai clienti.
L’approvazione umana resta utile anche per le azioni ad alto impatto. Un agente può preparare un pagamento, una modifica al codice o una modifica a un account senza ricevere l’autorità per finalizzarla. Questa separazione preserva l’automazione limitando al contempo gli esiti irreversibili.
I controlli dovrebbero essere proporzionati al rischio. Un assistente che riassume documenti pubblici necessita di meno restrizioni rispetto a un agente che accede a informazioni sui pazienti o a infrastrutture di produzione. Applicare la stessa politica a entrambi può generare attriti eccessivi o una protezione inadeguata.
Il valore del dato principale sta quindi nello stimolare domande concrete. Il suo limite è che non può rispondere a tali domande per ogni organizzazione.
Tre segnali da osservare dopo il rapporto IBM del 2026
Il prossimo banco di prova sarà capire se le imprese trasformeranno la preoccupazione in controlli delle identità misurabili, correzione delle vulnerabilità e risultati verificabili in modo indipendente.
Il primo segnale è l’adozione di controlli delle identità specifici per gli agenti. Le organizzazioni dovrebbero andare oltre le chiavi API condivise e assegnare identità distinte ad agenti, workload e workflow.
Tra le prove di progresso rientrerebbero credenziali a breve durata, autorizzazioni a livello di attività, attribuzione umana e log che coprano ogni chiamata agli strumenti. I fornitori di sicurezza probabilmente amplieranno i prodotti in quest’area, ma le metriche di adozione contano più degli annunci di funzionalità.
Se le organizzazioni saranno in grado di inventariare le identità agentiche e revocarle singolarmente, l’avvertimento centrale di IBM inizierà a perdere forza. Se gli agenti continueranno a ereditare account di servizio con privilegi estesi, il dato del 92% resterà rilevante.
Il secondo segnale riguarda l’applicazione dell’automazione alla gestione delle vulnerabilità da parte dei team di sicurezza. IBM ha rilevato che oltre la metà delle organizzazioni utilizzava agenti per il rilevamento e il contenimento delle minacce, mentre solo il 18% li utilizzava per la gestione delle vulnerabilità.
Questo squilibrio favorisce la reazione rispetto alla prevenzione. Il progresso significherebbe collegare inventari degli asset, dati sull’esposizione, proprietà del codice e flussi di lavoro per la correzione, affinché le debolezze note raggiungano rapidamente il team responsabile.
La metrica da osservare non è il numero di avvisi dell’IA. È il tempo che intercorre tra la scoperta di una debolezza sfruttabile e il rilascio di una correzione verificata. Tempi di correzione più brevi sosterrebbero l’argomentazione di IBM secondo cui i difensori possono contrastare attacchi più rapidi con l’automazione.
Il terzo segnale è costituito da prove indipendenti sulla frequenza e sui costi delle violazioni. Il rapporto annuale di IBM fornisce un riferimento ampiamente citato, ma gli acquirenti dovrebbero confrontarlo con informative normative, dati assicurativi, risultati delle attività di risposta agli incidenti e ricerche sottoposte a revisione paritaria.
Risultati coerenti tra queste fonti rafforzerebbero la conclusione secondo cui controlli deboli sugli accessi all’IA stanno causando perdite sostanziali. Grandi discrepanze suggerirebbero invece che definizioni, campionamento o pratiche di rilevamento spiegano parte della tendenza.
Le aziende dovrebbero anche osservare come cambierà il dato riportato del 92% nel prossimo studio di IBM. Un calo significativo, accompagnato da risultati più solidi in termini di inventario e audit, indicherebbe che la governance sta recuperando terreno.
Una percentuale più bassa da sola non sarebbe sufficiente. Le organizzazioni potrebbero semplicemente rilevare meno incidenti o ridefinire ciò che viene qualificato come sistema di IA. Un miglioramento credibile richiede prove che i controlli siano distribuiti, testati e applicati durante l’operatività.
La questione più ampia è se l’IA aziendale possa maturare dalla sperimentazione a un’infrastruttura responsabile. Modelli e agenti ora interagiscono con documenti, dati dei clienti, codice, comunicazioni e processi aziendali. La sicurezza deve seguire queste connessioni.
Google News può amplificare la statistica, ma consigli di amministrazione e team tecnici devono tradurla in domande a livello di sistema. Quali identità esistono, a cosa possono accedere e chi resta responsabile quando agisce un agente?
I risultati di IBM offrono un avvertimento, non un verdetto definitivo. I prossimi tre mesi dovrebbero mostrare se le imprese tratteranno l’accesso all’IA come un problema centrale di identità o come un altro documento di policy in attesa di attuazione.
Esaminate ogni agente di IA che può raggiungere dati sensibili o attivare un’azione esterna. Assegnategli un responsabile nominato, un’identità distinta, autorizzazioni strettamente circoscritte e un percorso verificabile fino alla persona che ha effettuato la richiesta. Poi verificate se l’organizzazione è in grado di fermarlo rapidamente.
Questo lavoro è meno spettacolare di un titolo su Google News. È anche il punto in cui sarà più probabilmente prevenuto il prossimo costoso incidente legato all’IA.
