L’Agentic AI, ovvero i sistemi di intelligenza artificiale capaci di pianificare, agire e orchestrare attività in autonomia (tramite tool, API e workflow aziendali) sta spostando il baricentro della sicurezza dati. Si passa, infatti, dal perimetro classico (endpoint, rete, applicazioni) a un perimetro “dinamico”, fatto di decisioni automatiche, catene di dipendenze e accessi indiretti ai dati.
Un bagno di realtà: il rischio non nasce solo dal “modello” in sé, ma dall’insieme modello + dati + strumenti + identità + terze parti.
Indice degli argomenti
Si può parlare di AI sicura?
Nel 2025 Data Breach Investigations Report di Verizon emerge un segnale operativo molto concreto: il 15% dei dipendenti accede regolarmente a piattaforme di GenAI da dispositivi aziendali e, tra questi, una quota significativa usa e-mail non aziendali (72%) o e-mail aziendali senza sistemi di autenticazione integrata (17%), aumentando la probabilità di “shadow AI” e di leak non governati verso servizi esterni.
Se l’AI diventa “agente”, e quindi si muove tra repository, ticketing, knowledge base, documenti e codice, la domanda chiave per CIO, CISO e CDO non è più “l’AI è sicura?”, ma: quali dati può raggiungere, in quali condizioni, con quali controlli e quali tracce?
L’urgenza della sicurezza dei dati nell’era dell’agentic AI
Da questa premessa discende un punto spesso sottovalutato: l’Agentic AI non introduce solo un nuovo layer applicativo, ma un “operatore digitale” che collega processi e sistemi già frammentati.
In molte aziende, il mito della piattaforma unica è tramontato e la vera partita è l’integrazione; quando un agente attraversa più applicazioni, la sicurezza dati smette di essere un tema confinabile al singolo dominio tecnico e diventa un requisito di orchestrazione.
Il DBIR 2025 fotografa un contesto in cui l’attacco parte sempre più spesso da elementi difficili da governare a posteriori.
Lo sfruttamento di vulnerabilità come vettore iniziale di accesso arriva al 20% e cresce del 34% rispetto all’anno precedente; nel dettaglio, edge device e VPN rappresentano il 22% dei target nelle azioni di exploitation e registrano una crescita quasi di otto volte rispetto al 3% dell’anno precedente.
Anche quando le organizzazioni reagiscono, la finestra di rischio resta ampia: nel report, solo circa il 54% delle remediation risulta completato e il tempo mediano indicato è di 32 giorni.
La pressione regolatoria
Alla pressione tecnologica si somma quella regolatoria. La Commissione europea ricorda che l’AI Act è entrato in vigore il 1° agosto 2024 e sarà pienamente applicabile dal 2 agosto 2026, con tappe già operative come divieti e obblighi di alfabetizzazione dal 2 febbraio 2025 e obblighi per i modelli GPAI dal 2 agosto 2025.
In altre parole, la governance dei dati per l’AI non è un progetto “a valle”: sta diventando un tema di accountability, prima ancora che di innovazione. Per inquadrare cosa cambia quando l’AI passa da assistente a orchestratore dei workflow, è utile anche l’approccio che descrive tre elementi pratici da considerare nei processi aziendali, perché è lì che si materializza il perimetro reale della sicurezza dati.
Sicurezza dei dati e proprietà intellettuale: cosa cambia con l’AI
Se l’urgenza è chiara, il passaggio successivo è capire perché la proprietà intellettuale AI oggi sia più esposta anche senza un “furto di file” in senso classico.
Un agente lavora trasformando documenti, codice, procedure e knowledge base in output riutilizzabili, spesso in forma di sintesi e decisioni operative. Questo aumenta l’efficienza, ma riduce l’attrito che prima proteggeva implicitamente la conoscenza aziendale: silos, formati eterogenei, accessi non federati.
La conseguenza è un cambio di prospettiva: la protezione dell’IP (Intellectual Property) non riguarda solo la confidenzialità “statica” di un repository, ma la possibilità che un sistema ricomponga e renda “interrogabile” ciò che prima era disperso.
In parallelo, la spinta a sperimentare rapidamente con agenti (spesso in modalità prudente e su casi d’uso mirati) può comprimere tempi e controlli: proprio lì, di solito, si annidano gli scivolamenti più comuni sulla sicurezza dati.
Triade C-I-A e impatto sulla protezione dell’IP
Il modo più concreto per leggere il rischio è tornare alla triade C-I-A (Confidentiality, Integrity, Availability) e ricalibrarla su sistemi agentici, dove l’output può innescare azioni su sistemi downstream.
| Pilastro | Come si rompe con Agentic AI | Effetto tipico sulla proprietà intellettuale |
| Confidenzialità | Prompt Injection, disclosure in output, permessi eccessivi su connettori e repository | Esposizione di specifiche, codice, piani, report interni e segreti industriali |
| Integrità | Data Poisoning su dataset o knowledge base, supply chain compromessa, output non validato | Decisioni errate e contaminazione della conoscenza operativa che guida R&D e delivery |
| Disponibilità | Saturazione dei modelli e dei servizi, escalation dei costi, ransomware nella catena applicativa | Interruzioni di processo, ritardi nella produzione di insight e blocchi operativi |
Un riferimento di mercato utile per classificare queste vulnerabilità in modo standard è l’OWASP Top 10 for LLM Applications, che elenca tra i rischi chiave Prompt Injection, Training Data Poisoning, Sensitive Information Disclosure ed Excessive Agency. Il messaggio è netto: più autonomia si concede a un agente, più bisogna trattarlo come un soggetto operativo con policy, controlli e logging, non come un semplice componente software.
Differenza tra sicurezza dei dati e privacy dei dati
La lettura C-I-A aiuta anche a non confondere due piani che, con l’AI, tendono a sovrapporsi: sicurezza dati e privacy.
La prima riguarda l’accesso non autorizzato, la manipolazione e la perdita di disponibilità dei dati, incluse informazioni non personali ma strategiche come l’IP. La seconda riguarda le regole e le basi giuridiche del trattamento dei dati personali, con obblighi specifici di trasparenza, minimizzazione e tutela dei diritti.
Nel mondo agentico, i dataset sono spesso “misti”: log, ticket, e-mail, documentazione tecnica e anagrafiche possono convivere nello stesso perimetro, soprattutto quando l’obiettivo è migliorare la produttività o ridurre il carico sul supporto.
Il bagno di realtà è che un progetto può essere formalmente privacy compliant e, allo stesso tempo, rischiare leakage di IP perché l’agente correla e risintetizza informazioni oltre lo scopo previsto. Viceversa, bloccare tutto per paura della privacy può spingere gli utenti verso canali non governati, amplificando la shadow AI che il DBIR 2025 segnala con evidenze quantitative.
Rischi specifici dati sensibili nei set di addestramento AI
Chiariti i concetti di base, il punto delicato è dove finisce il dato quando alimenta modelli e agenti. Nei progetti enterprise l’addestramento, il fine-tuning o la semplice connessione a una knowledge base diventano un acceleratore di valore solo se i dati sono curati, di qualità e ben classificati. È la stessa logica che emerge quando si sottolinea che gli agenti funzionano davvero soltanto con processi ben progettati e un contesto chiaro, mentre l’hype tende a vendere scorciatoie.
I rischi tipici si concentrano su due dinamiche: il Data Leaking AI (divulgazione involontaria attraverso input e output) e il Data Poisoning (alterazione malevola di ciò che il modello “impara” o consulta).
Rischi di leaking e memorization nei modelli AI
Nel ciclo di vita dei modelli, il leaking non coincide sempre con un’esfiltrazione tradizionale. Il DBIR 2025 lo rende tangibile descrivendo l’uso di piattaforme GenAI da parte dei dipendenti e la frequenza di account non integrati con l’autenticazione aziendale: è sufficiente un copia/incolla di codice, un riassunto di un report o un estratto di contratto per spostare fuori perimetro informazioni che, di fatto, rappresentano la proprietà intellettuale.
In contesti agentici, il rischio si amplifica perché il sistema non si limita a “rispondere”: raccoglie, collega, sintetizza. Ed è qui che entrano in gioco fenomeni come la memorization, cioè la capacità del modello di riprodurre porzioni di dati già visti, e la ricostruzione indiretta, cioè l’output che aggrega conoscenza interna fino a renderla trasferibile.
OWASP classifica esplicitamente la Sensitive Information Disclosure comeuna delle vulnerabilità più critiche: un segnale utile per i team che devono tradurre il rischio in requisiti di progetto, soprattutto quando gli agenti sono collegati a repository e sistemi di ticketing.
Data Poisoning e vulnerabilità correlate
Se il leaking colpisce la confidenzialità, il Data Poisoning colpisce l’integrità e quindi l’affidabilità delle decisioni. OWASP lo include tra i principali rischi per le applicazioni LLM, insieme alle Supply Chain Vulnerability, un binomio che diventa operativo quando dataset, plugin e connettori arrivano da terze parti o da repository non sufficientemente verificati.
Memory Poisoning: una minaccia persistente
Una delle minacce più insidiose è il Memory Poisoning (avvelenamento della memoria). In questo attacco, un avversario impianta informazioni false o malevole nella memoria a lungo termine di un agente. A differenza di una normale iniezione di prompt che termina con la sessione, la memoria avvelenata persiste. L’agente “impara” l’istruzione malevola e la richiama in sessioni future, spesso giorni o settimane dopo. Questo crea uno scenario di “agente dormiente”, in cui la compromissione è latente finché non viene attivata da condizioni specifiche, rendendola quasi impossibile da rilevare con i metodi tradizionali.
Il DBIR 2025 dedica un’attenzione particolare al tema delle dipendenze: il coinvolgimento di terze parti nelle violazioni raddoppia dal 15% al 30%. Lo stesso report riporta che, in incidenti con riuso di credenziali in ambienti di terze parti, il tempo mediano per rimediare a segreti trapelati e individuati in un repository GitHub è di 94 giorni. In una catena agentica, questa latenza non è un dettaglio: significa mantenere attivi per mesi i presupposti tecnici di una contaminazione o di un’escalation dei privilegi, mentre l’agente continua a operare 24/7.
Come evitare che i dati aziendali finiscano nei set di training pubblici
Arrivati ai rischi, la prevenzione va riportata su un terreno operativo. La risposta, in pratica, non è un divieto generalizzato. Funziona più spesso un approccio di governo del flusso, che parte da una domanda semplice e scomoda: quali dati possono entrare in un prompt o in una pipeline di training senza trasformarsi in un incidente? L’esperienza suggerisce che policy scritte ma non applicate spostano solo il problema. Al contrario, controlli chiari riducono la tentazione di scorciatoie e migliorano anche l’esperienza digitale delle persone, perché non costringono i team a lavorare “contro” l’IT.
In questa logica, una governance dei dati orientata all’AI si sta consolidando anche come offerta di mercato in piattaforme che uniscono Data Management, sicurezza e automazione. Un esempio è l’impostazione descritta nell’approfondimento su governance dei dati, sicurezza e automazione a servizio del business, dove il dato viene trattato come asset continuo e non come semplice storicizzazione.
Principi di contenimento del rischio
Per limitare le conseguenze di un eventuale malfunzionamento o compromissione di un agente AI, è fondamentale adottare strategie preventive:
Isolamento e sandboxing: Un agente che non ha ancora guadagnato piena fiducia può essere fatto operare in un ambiente di esecuzione isolato (firewalled). In questa “stanza sigillata”, il codice può essere eseguito, ma l’agente non può interagire con sistemi o dati critici.
Principio del privilegio minimo (Least Privilege): Ai moduli software, inclusi gli agenti, vengono concesse solo le autorizzazioni e i controlli di accesso minimi necessari per svolgere i compiti loro assegnati. Questo non si applica solo in termini di “spazio” (a quali dati può accedere), ma anche di “tempo”.
Provisioning Just-in-Time: Invece di avere permessi costanti, le credenziali vengono fornite dinamicamente solo per il tempo strettamente necessario all’autenticazione e all’esecuzione di un’attività specifica.
Tecniche di Data Masking e tokenizzazione
Tra le misure più utilizzate per abbassare il rischio di leakage, Data Masking e tokenizzazione hanno un vantaggio: spostano la protezione “a monte”, prima che il dato arrivi a modelli, agenti o ambienti di test. Il masking oscura o sostituisce parti sensibili, per esempio rendendo non riconoscibili riferimenti a clienti, fornitori, codici prodotto o parametri tecnici che, nel loro insieme, costituiscono l’IP.
La tokenizzazione, invece, sostituisce un valore con un token che può mantenere coerenza tra record senza esporre la semantica originale, utile quando servono correlazioni ma non è necessario vedere il dato in chiaro. In entrambi i casi, l’obiettivo è mantenere utilità per l’analisi e ridurre la probabilità che un agente restituisca o ricostruisca contenuti riservati.
Validazione e auditing dei dataset per l’AI
Le tecniche sul dato non bastano senza un processo ripetibile di controllo.
La validazione dei dataset per l’AI riguarda provenienza, trasformazioni e integrità: sapere da dove arrivano i dati, come sono stati trattati e chi ha modificato cosa.
L’auditing, invece, è la disciplina che rende questa catena verificabile nel tempo, evitando che un progetto pilota, nato per un caso d’uso limitato, si trasformi in una pipeline che ingloba progressivamente contenuti non previsti.
La tracciabilità della Data Lineage è cruciale: permette di seguire il percorso dei dati usati per addestrare o alimentare i modelli AI, monitorare i pattern di utilizzo e segnalare anomalie nel consumo che potrebbero indicare una compromissione. Questo diventa fondamentale per supportare la spiegabilità e la trasparenza dei modelli.
Un bagno di realtà emerso in più contesti è che l’Agentic AI, per essere efficace, richiede competenze interne e controllo sui dati. In percorsi di evoluzione verso architetture agentiche, l’investimento sulle capability interne viene indicato come leva per ridurre incertezza e muoversi più rapidamente. Ma “muoversi rapidamente” non può significare saltare i controlli: auditing e classificazione documentale sono ciò che permette di dare permessi selettivi, includendo anche la scelta esplicita di non consentire accesso a specifiche categorie di dati.
Governare la sicurezza dei dati
Una volta impostate le barriere “a monte”, la sicurezza dati va governata come parte del modello operativo. Qui è facile sbagliare: trattarla come un capitolo del progetto AI. Nella pratica accade il contrario: senza una base di controllo, i PoC si moltiplicano e poi vengono abbandonati perché il valore non è chiaro, i costi crescono e i rischi organizzativi diventano ingestibili.
Nel racconto di chi governa l’IT in aziende manifatturiere, il cloud ha spostato i budget verso OPEX e ha accelerato l’erogazione di servizi, ma ha anche aperto un universo di servizi da conoscere, governare e integrare.
Sul fronte AI, l’incognita riguarda proprio i costi legati ai token e agli agenti che fanno chiamate iterative: variabili e non sempre prevedibili. La sicurezza dati, in questo scenario, è anche un tema di sostenibilità economica, perché attacchi come il Denial of Service o un abuso di agency possono trasformarsi in spesa incontrollata oltre che in rischio cyber.
Un approccio pratico alla governance dell’AI
Invece di un programma pluriennale, è possibile implementare le basi della governance AI in 90 giorni attraverso un approccio graduale:
Fase 1: Discover (Scoperta): inventariare i casi d’uso dell’AI, mappare i flussi di dati e identificare le applicazioni ad alto rischio che trattano dati sensibili o sono collegate ad azioni automatizzate critiche.
Fase 2: Design (Progettazione): attivare la classificazione automatica e il tracciamento della lineage per i dati che alimentano i principali casi d’uso. Creare un registro dei modelli e degli agenti per monitorarne proprietari, scopo e ciclo di vita.
Fase 3: Enforce (Applicazione): implementare controlli di accesso, filtri su prompt e contenuti, e flussi di approvazione per le azioni ad alto rischio. Mappare i controlli ai principali framework di settore (NIST AI RMF, ISO/IEC 42001, EU AI Act).
Fase 4: Improve (Miglioramento): stabilire una cadenza per attività di red teaming e processi di rilascio controllati. Monitorare continuamente metriche di qualità, bias e sicurezza.
Metriche di sicurezza e rischi da monitorare
Per evitare che la sicurezza resti “opinione”, servono misure. Alcune metriche emergono in modo naturale dalle evidenze del DBIR e dalle categorie OWASP, perché collegano rischio e osservabilità.
| Area | Metrica utile | Perché conta |
| Shadow AI | Percentuale di accessi a GenAI con account non aziendali o senza autenticazione integrata | Riprende il pattern del DBIR 2025 (72% e 17%) e misura l’uscita dal perimetro di controllo |
| Vulnerabilità | Tempo di remediation e copertura patch su edge/VPN | DBIR: 54% remediation completate e mediana 32 giorni, con exploitation al 20% |
| Terze parti | Percentuale di workflow agentici con connettori verificati e logging attivo | Terze parti coinvolte nel 30% delle violazioni; serve visibilità sulle dipendenze |
| Data leakage | Tasso di output con indicatori di dati sensibili rilevati | Trasforma “Sensitive Information Disclosure” in controllo continuo |
A queste misure si può affiancare un indicatore di qualità operativa, coerente con una regola semplice: l’IT non dovrebbe scoprire un problema dai suoi utenti. Monitorare uptime dei servizi e gestione dei ticket, come KPI di “igiene organizzativa”, resta un modo pragmatico per capire se l’AI sta migliorando la vita delle persone o aggiungendo complessità non governata.
Il ruolo dei CISO e dei CDO
Se i KPI definiscono cosa osservare, la domanda successiva è chi possiede le decisioni. Nei modelli di governance descritti per l’AI agentica, la collaborazione tra CIO e CISO viene indicata come elemento strutturale, insieme al Risk Management e a percorsi di certificazione come ISO 42001 per i sistemi AI. La governance dell’AI funziona quando diventa una responsabilità condivisa.
L’importanza di un approccio multidisciplinare
Molte organizzazioni stanno creando comitati di governance interfunzionali che includono rappresentanti di sicurezza, data & engineering, prodotto, operation, affari legali e privacy. Questo gruppo definisce le policy, concorda le soglie di rischio e possiede le metriche di successo, garantendo chiarezza sui ruoli e un approccio unificato.
In una divisione di responsabilità efficace, il CISO guida Threat Model, controlli di accesso, test su Prompt Injection e resilienza dell’infrastruttura.
Il CDO governa tassonomia, qualità e classificazione dei dati, rendendo possibile un approccio per Data Product che superi i silos e aumenti l’affidabilità dell’AI aziendale.
La governance dati AI diventa quindi un tema di integrazione organizzativa prima ancora che tecnologica: senza un lessico comune, si finisce o in una sicurezza “che blocca”, o in un’innovazione “che scarica il rischio” su chi opera tutti i giorni.
Casi reali e lezioni apprese: quando l’esposizione ai ha compromesso dati sensibili
Portare la discussione su casi e numeri aiuta a evitare l’astrazione. Il DBIR 2025 parte da un dataset ampio, con 22.052 incidenti analizzati e 12.195 data breach confermati in 139 Paesi. Al suo interno, l’elemento umano resta presente in circa il 60% delle violazioni, ma il salto più rilevante riguarda l’ecosistema: terze parti e vulnerabilità crescono, cioè proprio le aree dove un agente può amplificare l’impatto perché “lavora” con identità e accessi distribuiti.
Il report quantifica anche la dinamica ransomware, presente nel 44% dei breach esaminati, con una crescita del 37% rispetto all’anno precedente. Il dato sul pagamento medio indicato è 115.000 dollari (in calo dai 150.000 dello scorso anno), mentre la quota di organizzazioni che non paga sale al 64%.
Sono numeri che, pur non essendo specifici dell’AI, descrivono un contesto in cui la disponibilità dei sistemi e dei dati è sotto pressione costante; in un’architettura agentica, questo si traduce in necessità di piani di continuità e segmentazione più rigorosi.
Le lezioni operative
Accanto alla fotografia globale, emergono lezioni operative da chi sta sperimentando agenti in modo mirato. In Italia, l’adozione viene descritta spesso come selettiva su casi d’uso specifici, per esempio task in amministrazione e supporto tecnico.
In un percorso di evoluzione da piattaforma di GenAI ad architettura ad agenti, la verticalizzazione e la specializzazione degli agenti vengono indicate come fattori abilitanti, insieme alla cura dei dati e alla progettazione del processo.
La stessa impostazione ricorre in scenari CRM dove gli agenti guidano utenti e distributori dentro una knowledge base e, solo se necessario, aprono un ticket per passare a un supporto umano: un modello ibrido che, oltre a migliorare produttività, riduce l’esposizione della conoscenza a canali non controllati.
Per un inquadramento europeo del contesto di minaccia, l’ENISA Threat Landscape 2025 resta un riferimento per collegare incidenti, trend e tecniche su un periodo definito.
Trasformare la sicurezza dei dati in vantaggio competitivo
Dopo aver messo in fila numeri e rischi, la domanda che resta sul tavolo è pratica: come si fa a non trasformare la sicurezza dati in un freno?
La verità è che l’Agentic AI non è una bacchetta magica e, come avvertono gli analisti, una parte dei progetti verrà cancellata se non dimostra valore e sostenibilità. Ma proprio per questo la sicurezza dati può diventare un acceleratore competitivo: separa le iniziative industrializzabili dai PoC estemporanei.
Tre effetti sono immediati.
Primo, permette di sperimentare con velocità senza scaricare il rischio su utenti e operation, riducendo la tentazione di usare strumenti fuori policy.
Secondo, migliora la qualità dell’esperienza digitale delle persone: un agente che funziona bene è quello inserito in processi chiari, con permessi minimi e output verificabili, non quello che “fa tutto” ma costringe a controlli manuali continui.
Terzo, mette l’organizzazione in una posizione migliore rispetto alle scadenze dell’AI Act, perché tracciabilità, qualità dei dataset e controllo dei rischi sono già parte del modo di lavorare.
In questo scenario, si intreccia anche il tema della sovranità tecnologica, sempre più presente nelle scelte dei CIO. Diversificare i fornitori, combinare cloud locali e globali e adottare tecnologie open source e interoperabili vengono citate come leve per aumentare resilienza. Non è solo geopolitica: è anche una scelta di governance dati AI, perché il controllo del dato e delle dipendenze determina quanto un agente può essere introdotto in processi critici senza trasformarsi in un moltiplicatore di rischio.
