Kiteworks avverte: l'80% delle organizzazioni ha affrontato incidenti di sicurezza o IA mentre la governance restava indietro

Kiteworks è approdata su Google News con un'affermazione netta: l'80% delle organizzazioni ha subito un incidente di sicurezza o legato all'IA, mentre la preparazione sul fronte della governance restava criticamente bassa. Il dato attira l'attenzione, ma il conflitto più profondo riguarda la distanza tra politiche scritte e controlli che funzionano durante l'uso effettivo dell'IA.

Il titolo, pubblicato da Cybersecurity Insiders, arriva mentre le aziende concedono ai sistemi di IA accesso a documenti privati, applicazioni aziendali e flussi di lavoro interni. Queste connessioni ampliano le conseguenze di autorizzazioni deboli, registri incompleti e movimenti di dati sconosciuti.

Kiteworks ha un interesse commerciale in questa discussione perché vende tecnologie per la sicurezza e la governance dei dati privati. Le sue conclusioni meritano quindi esame, non accettazione automatica. Tuttavia, diversi dati di supporto rivelano un problema di governance che va oltre l'impostazione di un singolo fornitore.

Cosa cambia davvero il rapporto Kiteworks

Il rapporto trasforma la governance dell'IA da dibattito sulle policy a problema di risposta agli incidenti.

La notizia su Google News presenta il dato dell'80% come risultato centrale. Tuttavia, il solo titolo non chiarisce se questa percentuale combini violazioni confermate, eventi sospetti, violazioni delle policy o guasti specifici dell'IA.

La distinzione è importante. Una violazione convenzionale dei dati, un dipendente che carica testo riservato su un chatbot non approvato e un agente autonomo che compie un'azione non intenzionale sono eventi diversi. Richiedono controlli diversi e producono livelli di danno differenti.

I lettori dovrebbero pertanto considerare la percentuale del titolo come un risultato di un sondaggio riportato dal fornitore. Non è una misura di violazioni verificate in modo indipendente nell'intera economia. Il materiale Kiteworks disponibile pubblicamente sostiene la più ampia preoccupazione sulla governance, ma non rende tutte le categorie di incidente intercambiabili.

La precedente ricerca globale di Kiteworks ha coinvolto 461 organizzazioni in Nord America, Europa, Asia-Pacifico e Medio Oriente. La copertura di quella ricerca ha rilevato che solo il 17% aveva implementato pienamente framework tecnici di governance dell'IA.

Questa è la base di riferimento più utile. La governance tecnica dell'IA implica controlli applicabili che coprono accesso ai dati, uso dei modelli, monitoraggio, conservazione e gestione degli incidenti. Un documento di policy privo di tali controlli non può impedire a un dipendente, a un'applicazione o a un agente di esporre informazioni protette.

La stessa ricerca ha collegato una visibilità limitata a risultati più deboli. Secondo un rapporto indipendente, il 46% delle organizzazioni che non conosceva il proprio numero di terze parti non riusciva nemmeno a identificare la frequenza delle proprie violazioni.

Tra le organizzazioni incerte sulle violazioni, il 42% era anche incerto sui tempi di rilevamento. Un ulteriore 48% non riusciva a quantificare i costi del contenzioso, secondo la copertura.

Queste relazioni non dimostrano che una scarsa visibilità abbia causato ogni violazione. Mostrano però che le organizzazioni incapaci di inventariare sistemi e partner faticano anche a misurarne le conseguenze.

L'analisi di Kiteworks sul settore tecnologico del 2026 offre un'altra prospettiva. Ha coinvolto 225 responsabili di sicurezza, IT, compliance e rischio in 10 settori e otto regioni. Trentadue rispondenti rappresentavano organizzazioni tecnologiche, mentre il 97% di tutti i partecipanti lavorava in organizzazioni con almeno 1.000 dipendenti.

Il campione è rilevante per il rischio delle grandi imprese, ma non rappresenta ogni azienda. Il sottoinsieme tecnologico è particolarmente ridotto. Le differenze percentuali all'interno di quelle 32 risposte dovrebbero essere interpretate come indicazioni di tendenza, non come stime precise del settore.

Anche con questi limiti, il rapporto identifica un problema coerente. Le organizzazioni hanno investito in pratiche di governance visibili, ma i controlli fondamentali restano incompleti.

Questo è ciò che è cambiato. Gli incidenti di sicurezza dell'IA non sono più casi limite ipotetici associati a futuri sistemi autonomi. Le aziende segnalano incidenti mentre capacità essenziali di inventario, provenienza e applicazione dei controlli restano incomplete.

Perché Google News sta evidenziando ora il divario di governance

L'adozione dell'IA è passata da sessioni di chat isolate a sistemi in grado di recuperare dati, richiamare strumenti e agire nei processi aziendali.

Un chatbot che risponde a una domanda generale ha un accesso limitato. Un agente IA collegato a email, archiviazione cloud, registri clienti, codice sorgente o sistemi finanziari opera su una superficie d'attacco molto più ampia.

Per IA agentica si intende un software in grado di pianificare ed eseguire più azioni verso un obiettivo. Il suo rischio dipende meno dalla fluidità conversazionale e più da identità, autorizzazioni, strumenti disponibili e dati a cui può accedere.

Ciò crea diverse vie verso un incidente. Un agente può ricevere privilegi eccessivi, seguire istruzioni dannose incorporate in un documento, divulgare informazioni recuperate o attivare un'azione al di fuori del proprio scopo previsto.

I dipendenti creano inoltre esposizione attraverso la shadow AI, ovvero strumenti di IA utilizzati senza approvazione o monitoraggio formali. Il rischio aumenta quando tali strumenti conservano i prompt, addestrano sui contenuti inviati o si collegano ad account dell'organizzazione.

I programmi di sicurezza tradizionali gestiscono già identità, endpoint, applicazioni e traffico di rete. L'IA aggiunge un livello di ragionamento capace di combinare informazioni e avviare azioni alla velocità delle macchine.

Questo non rende imprevedibile ogni sistema di IA. Significa però che un'approvazione statica al momento dell'implementazione non può sostituire l'osservazione continua dopo l'implementazione.

La tempistica riflette anche la pressione normativa. L'AI Act dell'Unione europea è entrato in vigore nel 2024 e i suoi obblighi seguono un calendario graduale. I requisiti di governance per i modelli di IA per finalità generali hanno iniziato ad applicarsi nell'agosto 2025.

La cronologia di attuazione della Commissione europea mostra che diverse disposizioni e scadenze transitorie si applicano in momenti differenti. Le organizzazioni devono identificare quali sistemi, ruoli dei fornitori e casi d'uso rientrino in ciascun obbligo.

Questo calendario in evoluzione complica la pianificazione della conformità, ma non elimina la necessità di un inventario. Un'azienda non può classificare un sistema di IA, documentarne i rischi o applicare i controlli corretti se nessuno sa che esiste.

La regolamentazione è solo una fonte di pressione. I clienti chiedono sempre più spesso ai fornitori come l'IA elabori informazioni riservate. Anche assicuratori, revisori, consigli di amministrazione e team di approvvigionamento vogliono prove che i controlli operino come descritto.

Il requisito probatorio cambia il significato della preparazione. Un'azienda non è pronta perché i dirigenti hanno approvato una policy sull'IA. È pronta quando i team possono dimostrare chi ha avuto accesso ai dati, quale modello li ha ricevuti, cosa ha fatto il sistema e come ha risposto l'organizzazione.

Ecco perché le conclusioni di Kiteworks sulla governance dell'IA risuonano oltre la base clienti del fornitore. Descrivono un divario operativo già visibile nelle revisioni di sicurezza e negli acquisti aziendali.

Google News sta amplificando la statistica sugli incidenti in un momento in cui i dirigenti riconoscono il problema, ma non dispongono di prove coerenti. Il titolo cattura l'attenzione perché l'adozione ha superato i sistemi necessari per osservarla.

Le promesse di governance superano il controllo tecnico

Il conflitto principale non è tra adozione dell'IA e cautela; è tra governance promessa sulla carta e governance applicata in produzione.

Il rapporto di Kiteworks sul settore tecnologico illustra questa divisione. Le organizzazioni tecnologiche hanno guidato il campione globale in diverse capacità formali di governance.

Il settore ha segnalato tecniche di tutela della privacy al 56%, rispetto a un risultato globale del 33%. Le tassonomie degli incidenti IA e i playbook hanno raggiunto il 50%, rispetto al 27% a livello globale.

I rispondenti del settore tecnologico hanno inoltre segnalato valutazioni d'impatto dell'IA al 53%, audit sui bias al 47% e documentazione sulla spiegabilità dei modelli al 41%. Ogni risultato ha superato la corrispondente cifra globale.

Si tratta di investimenti significativi. Le valutazioni d'impatto possono identificare gruppi interessati e danni prevedibili. I playbook per gli incidenti assegnano ai team responsabilità predefinite quando un modello si comporta in modo inatteso.

Tuttavia, lo stesso rapporto sul settore tecnologico ha riscontrato risultati più deboli nelle infrastrutture meno visibili.

Solo il 22% dei rispondenti tecnologici ha segnalato ambienti di addestramento isolati, rispetto al 26% globale. L'isolamento separa le risorse di sviluppo, addestramento e produzione, affinché i dati non possano spostarsi tra esse senza controllo.

Solo il 19% ha segnalato capacità di provenienza e tracciabilità, rispetto a una cifra globale del 23%. La provenienza dei dati registra da dove hanno avuto origine le informazioni, come sono cambiate e quali modelli o processi le hanno utilizzate.

Ciò crea una contraddizione pratica. Un'azienda può rilevare un comportamento insolito e disporre di un documento di risposta, ma restare incapace di ricondurre l'output interessato ai dati di origine.

Può anche mantenere controlli di accesso in produzione lasciando al contempo gli ambienti di sviluppo dei modelli connessi in modo troppo ampio. Questa lacuna aumenta il rischio di accessi non autorizzati, materiale di addestramento contaminato o movimenti involontari di dati.

I rispondenti del settore tecnologico hanno ottenuto risultati migliori su tracce di audit immutabili, monitoraggio della deriva e playbook per gli incidenti. Questi controlli aiutano i team a vedere che qualcosa è cambiato.

Una tracciabilità debole rende più difficile spiegare perché sia cambiato. Può ritardare l'analisi della causa radice e rendere più difficile prevenire le recidive.

Il rapporto ha inoltre rilevato che il 53% dei rispondenti tecnologici ha dichiarato che i consigli di amministrazione davano priorità alla governance dell'IA. Tuttavia, solo il 47% ha segnalato attenzione del consiglio alla postura complessiva di rischio informatico, sette punti percentuali sotto la cifra globale.

Questo risultato non dimostra che i consigli di amministrazione abbiano abbandonato la cybersecurity. Suggerisce che l'attenzione della leadership possa spostarsi verso iniziative IA visibili, mentre la sicurezza fondamentale compete per lo stesso tempo e budget.

La governance dell'IA non può affiancarsi alla cybersecurity come progetto isolato di conformità. Dipende dalla gestione delle identità, dalla crittografia, dalla classificazione dei dati, dalla sicurezza software, dalla supervisione delle terze parti e dalla risposta agli incidenti.

Il National Institute of Standards and Technology degli Stati Uniti riflette questo approccio basato sul ciclo di vita. Il suo volontario framework sui rischi dell'IA organizza il lavoro attorno a quattro funzioni: Govern, Map, Measure e Manage.

La governance stabilisce responsabilità e policy. La mappatura identifica il contesto e le parti interessate. La misurazione valuta il rischio, mentre la gestione lo prioritizza e lo affronta.

Un'azienda che si ferma alla governance ha completato solo una parte di quel ciclo. Le policy devono collegarsi a osservazioni tecniche, risultati dei test e decisioni di risposta.

Questo è il capovolgimento centrale dietro il titolo. Le organizzazioni possono apparire preparate perché hanno comitati, standard e strumenti approvati. Gli incidenti di sicurezza dell'IA rivelano se tali preparativi raggiungano i sistemi che gestiscono dati reali.

Gli incidenti di sicurezza dell'IA espongono il problema dell'inventario

Le organizzazioni non possono controllare flussi di dati IA che non riescono a identificare, classificare e ricostruire.

L'inventario può sembrare un aspetto basilare, ma l'AI lo rende complesso. Un singolo processo aziendale può coinvolgere un dipendente, un'applicazione software, un fornitore esterno di modelli, un'infrastruttura di retrieval e diversi repository di dati.

L'azienda potrebbe possedere solo una parte di questa catena. Una piattaforma di assistenza clienti può aggiungere funzionalità generative tramite un modello di terze parti. Uno sviluppatore può collegare un assistente di coding a repository privati.

Un altro team può sviluppare un agente interno che recupera documenti dall'archiviazione condivisa. Ogni distribuzione può creare condizioni diverse per conservazione, autorizzazioni e logging.

Un inventario utile deve quindi registrare più dei soli nomi dei prodotti. Dovrebbe identificare i responsabili dei sistemi, le finalità previste, i fornitori dei modelli, i dati connessi, gli strumenti disponibili, i gruppi di utenti e le località geografiche di elaborazione.

Deve inoltre rilevare se il sistema può compiere azioni. Un assistente che redige un'e-mail presenta un livello di rischio. Un agente autorizzato a inviare quell'e-mail o modificare un account ne presenta un altro.

Le conclusioni di Kiteworks sulla visibilità delle terze parti si inseriscono in questo problema. Fornitori e integrazioni sconosciuti possono nascondere i percorsi attraverso cui si spostano dati privati.

L'organizzazione potrebbe aver approvato l'applicazione visibile senza comprendere ogni elaboratore sottostante. Questo diventa importante quando cambia un fornitore di modelli, un plug-in o un servizio dati.

Lo stesso problema emerge nella sovranità dei dati. La ricerca di Kiteworks del 2026 ha rilevato che circa quattro intervistati su cinque si descrivevano come ben informati sui requisiti di sovranità. Tuttavia, approssimativamente un terzo ha segnalato un incidente legato alla sovranità nell'anno precedente.

La sovranità dei dati riguarda il controllo legale e operativo su dove risiedono le informazioni e quale giurisdizione le disciplina. L'AI complica questo aspetto quando prompt, embedding, log e output dei modelli attraversano confini regionali.

Il rapporto sulla sovranità inquadra il divario come una distanza tra consapevolezza e controllo dimostrabile. Le organizzazioni possono comprendere le regole pur non disponendo di applicazione automatizzata o prove pronte per un audit.

Questo contrasto è più difendibile che trattare ogni evento segnalato come lo stesso tipo di incidente AI. Indica anche un test concreto.

Dopo un evento legato all'AI, l'organizzazione riesce a identificare i dati interessati, il modello coinvolto, l'identità che ha avviato l'azione, le azioni eseguite e i destinatari a valle? In caso contrario, la governance resta incompleta indipendentemente dalla qualità delle policy.

I knowledge worker hanno un ruolo in questo sistema. Decidono quali file inserire nei prompt, di quali risposte generate fidarsi e quali strumenti AI entrano a far parte del lavoro quotidiano.

Le organizzazioni possono ridurre l'esposizione accidentale offrendo ai dipendenti modalità approvate per cercare e sintetizzare le proprie informazioni. Una base di conoscenza AI privata può limitare la copia non necessaria tra servizi non correlati, quando i suoi confini sono chiaramente definiti.

Questo approccio richiede comunque governance. L'archiviazione locale o privata non risolve automaticamente accessi eccessivi, output imprecisi, autenticazione debole o obblighi di conservazione.

L'obiettivo non è vietare flussi di lavoro utili. È offrire agli utenti un percorso approvato, il cui movimento dei dati possa essere compreso e riesaminato.

L'inventario necessita anche di gestione del cambiamento. Un'applicazione nata come assistente di scrittura può acquisire funzionalità di retrieval, automazione o agente tramite un aggiornamento.

I team di sicurezza dovrebbero riesaminare le nuove capacità in base agli accessi e alle azioni modificati, non solo al nome familiare del prodotto. Uno strumento in precedenza a basso rischio può diventare sostanzialmente diverso dopo aver ricevuto nuove autorizzazioni.

È qui che gli incidenti di sicurezza AI diventano segnali preziosi. Ogni evento dovrebbe aggiornare l'inventario, il modello di minaccia, la progettazione dei controlli e le indicazioni per i dipendenti.

Il solo conteggio degli incidenti non può mostrare se le organizzazioni hanno imparato da tali eventi. La qualità del processo correttivo conta più del dato da titolo.

Cosa non dimostra la cifra dell'80%

Il dato in evidenza segnala un'esposizione diffusa, ma non stabilisce un tasso universale di violazioni né prova che l'AI abbia causato ogni incidente segnalato.

I sondaggi dei fornitori possono rivelare schemi utili, soprattutto quando pubblicano dimensione del campione e metodologia. Portano con sé anche limiti inevitabili.

Gli intervistati possono interpretare in modo diverso il termine “incidente”. I responsabili della sicurezza possono includere sotto la stessa etichetta attacchi tentati, violazioni confermate, violazioni delle policy, eventi di privacy e guasti operativi.

I risultati auto-segnalati dipendono anche dalla visibilità. Un'organizzazione matura con un monitoraggio esteso può segnalare più incidenti perché rileva più eventi.

Un'organizzazione meno preparata può apparire più sicura semplicemente perché non riesce a vedere i fallimenti. La stessa ricerca di Kiteworks avverte di questo effetto di visibilità.

Anche le popolazioni dei sondaggi sono rilevanti. Il brief tecnologico di Kiteworks rappresenta in modo schiacciante grandi organizzazioni, con il 97% degli intervistati impiegato in aziende con almeno 1.000 dipendenti.

Le grandi aziende dispongono di più sistemi, utenti, fornitori e obblighi normativi. La loro esperienza non dovrebbe essere proiettata direttamente sulle piccole imprese.

L'analisi tecnologica ha incluso solo 32 intervistati del settore. Una differenza di alcune risposte può modificare materialmente una percentuale all'interno di quel sottogruppo.

L'affermazione dell'80% necessita pertanto di dettagli di supporto prima che i lettori possano confrontarla con un altro studio sugli incidenti. I dettagli necessari includono la formulazione della domanda, le opzioni di risposta, il periodo di osservazione e il trattamento degli eventi sospetti.

Sarebbe inoltre utile separare gli incidenti cyber tradizionali dagli eventi originati dall'AI. Un attaccante che usa l'AI per migliorare il phishing è diverso da un modello aziendale che espone dati recuperati.

Una terza categoria comprende gli attacchi convenzionali contro l'infrastruttura AI, come il furto di credenziali o software vulnerabile. Definire tutti e tre “incidenti AI” oscura chi controllava il sistema che ha fallito.

Kiteworks vende anche prodotti progettati per affrontare la governance dei dati privati. Questa posizione commerciale non invalida i suoi dati, ma crea un incentivo a enfatizzare i rischi affrontati dalla sua piattaforma.

Una riproduzione indipendente rafforzerebbe l'affermazione in evidenza. Lo farebbe anche la pubblicazione di suddivisioni anonimizzate per tipo di incidente, dimensione dell'organizzazione, regione e maturità della governance.

La lezione più credibile del rapporto non richiede di accettare un tasso universale dell'80%. Diversi studi di Kiteworks mostrano che preparazione formale e applicazione operativa spesso divergono.

Il brief tecnologico identifica lacune nell'isolamento dell'addestramento e nella provenienza. Il sondaggio precedente ha rilevato un'implementazione limitata della governance tecnica. La ricerca sulla sovranità mostra un'elevata consapevolezza accanto a incidenti continui.

Nel loro insieme, questi risultati sostengono una conclusione più circoscritta. Molte grandi organizzazioni hanno avviato la governance dell'AI, ma relativamente poche possono dimostrare un controllo tecnico completo sull'intero ciclo di vita dei dati.

È un dato serio senza essere sensazionalistico. Offre inoltre agli acquirenti un quadro migliore per valutare i prodotti di governance.

Un fornitore dovrebbe spiegare quali flussi di dati osserva, quali policy applica e quali azioni può bloccare. Dovrebbe anche dichiarare limiti e dipendenze dalle integrazioni.

Gli acquirenti dovrebbero essere cauti quando un prodotto tratta la governance come un semplice dashboard. La visibilità è necessaria, ma applicazione, test, risposta e ripristino completano il ciclo operativo.

Dovrebbero inoltre evitare di presumere che un solo gateway controlli ogni percorso. Dipendenti, funzionalità AI integrate, interfacce di programmazione delle applicazioni dirette e agenti autonomi possono creare rotte separate.

Il titolo di Google News merita attenzione perché il rischio sottostante è reale. La sua percentuale esatta dovrebbe restare attribuita al rapporto finché la metodologia completa non chiarirà cosa include il numero.

Tre segnali che metteranno alla prova l'avvertimento di Kiteworks

Le prossime evidenze dovrebbero mostrare se le aziende stanno costruendo una governance applicabile o si limitano ad aggiungere un altro livello di documentazione.

Il primo segnale è una migliore divulgazione degli incidenti. Le ricerche future dovrebbero separare violazioni confermate, eventi sospetti, violazioni delle policy e azioni AI non intenzionali.

Dovrebbero inoltre distinguere gli incidenti causati dall'AI dagli attacchi che prendono di mira sistemi AI. Questa tassonomia renderebbe più significativi i confronti anno su anno.

Una divulgazione dettagliata potrebbe rafforzare l'avvertimento di Kiteworks se tassi elevati persistessero in categorie chiaramente definite. Potrebbe indebolire il dato in evidenza se la cifra dell'80% combinasse molti eventi a bassa gravità o solo vagamente correlati.

Il secondo segnale è un progresso misurabile nei controlli tecnici. Il brief tecnologico del 2026 fornisce parametri di riferimento per ambienti di addestramento isolati, provenienza, playbook di incident response e supervisione del consiglio di amministrazione.

Un sondaggio di follow-up dovrebbe utilizzare le stesse domande e lo stesso approccio di campionamento. Un'adozione crescente della lineage e dell'isolamento degli ambienti dimostrerebbe che le organizzazioni stanno colmando il divario di applicazione.

Risultati stabili o in calo sosterrebbero la preoccupazione centrale del rapporto. Indicherebbero che la spesa resta concentrata su valutazioni e policy anziché su controlli fondamentali.

Il terzo segnale sono le evidenze normative. L'applicazione europea delle norme, gli audit e le linee guida di implementazione dovrebbero rivelare quali fallimenti di governance creano la maggiore esposizione pratica.

Occorre osservare casi che coinvolgono documentazione mancante, monitoraggio inadeguato, interazione AI non dichiarata o movimento dei dati scarsamente controllato. Questi esempi aiuteranno le organizzazioni a dare priorità agli investimenti.

L'azione normativa potrebbe rafforzare la tesi del rapporto se le autorità riscontrassero ripetutamente divari tra le policy dichiarate e il comportamento dei sistemi. Una conformità chiara con pochi fallimenti operativi ne indebolirebbe l'urgenza.

Gli acquirenti aziendali non devono attendere questi segnali prima di agire. Possono testare la preparazione con un esercizio diretto incentrato su un flusso di lavoro AI di produzione.

Si inizi con un sistema che accede a informazioni sensibili. Si chieda al responsabile di identificare ogni fonte di dati, fornitore di modelli, strumento connesso, autorizzazione, regola di conservazione e decisore responsabile.

Poi si simuli un account compromesso, un documento dannoso o un'azione non intenzionale. Si determini se l'organizzazione riesce a fermare il sistema, tracciarne l'attività, identificare le informazioni esposte e preservare le prove.

L'esercizio dovrebbe includere i team legale, sicurezza, privacy, IT e business che utilizza il sistema. La governance dell'AI fallisce quando la responsabilità scompare tra questi gruppi.

I team dovrebbero conservare decisioni e lezioni sugli incidenti in un sistema ricercabile, invece di disperderle tra riunioni e documenti. Un flusso di lavoro della conoscenza strutturato può aiutare i responsabili a mantenere le evidenze man mano che i sistemi cambiano.

La documentazione non può comunque sostituire l'applicazione. Il suo valore risiede nel collegare responsabili nominati, comportamento osservato, eccezioni approvate e azioni correttive.

La cifra dell'80% degli incidenti riportata da Kiteworks va letta soprattutto come un avvertimento che merita verifica. La ricerca più ampia dell'azienda mostra già prove sufficienti di visibilità debole, governance tecnica limitata e provenienza incompleta.

La vera domanda non è più se un'organizzazione disponga di una policy AI. È se quell'organizzazione riesca a ricostruire le azioni di un sistema AI dopo che qualcosa è andato storto.

Google News può amplificare una percentuale eclatante, ma i responsabili della sicurezza hanno bisogno dei controlli che vi stanno sotto. Dovrebbero inventariare un flusso di lavoro AI attivo, testarne il percorso di fallimento e documentare ciò che resta invisibile.