La fiducia dichiarata è quasi assoluta, ma le pratiche operative raccontano una realtà più esposta. Il 98% dei decisori aziendali ritiene che la propria organizzazione sia in grado di proteggere i dati sensibili impiegati nei processi di intelligenza artificiale e machine learning. Eppure, l’84% concede eccezioni alle regole di conformità e il 51% teme le verifiche degli auditor. Lo scarto tra percezione e comportamento può così lasciare crescere rischi difficili da vedere e correggere.
I numeri emergono dal Perforce Delphix 2026 State of AI and Data Privacy Report, realizzato raccogliendo le risposte di 518 dirigenti appartenenti a organizzazioni di diversi settori. Il quadro coincide con una trasformazione nel modo in cui viene sviluppato il software: le strategie di protezione consolidate negli anni erano pensate per processi scanditi da passaggi manuali, approvazioni e consegne controllate dei dati. Lo sviluppo agentico, invece, si muove a una velocità incompatibile con molti di questi meccanismi.
Nel modello tradizionale, un gruppo mascherava le informazioni sensibili presenti in una copia dei dati di produzione, ne autorizzava l’utilizzo e la trasferiva agli sviluppatori. Gli agenti autonomi non attendono che le informazioni superino checkpoint successivi. Per Mayank Ahluwalia, product manager per dati sintetici e conformità AI presso Perforce Delphix, la compliance non può più funzionare come un semplice cancello: deve essere applicata ogni volta che avviene un passaggio di dati.
La contraddizione tra sicurezza percepita ed eccezioni frequenti dipende anche dal tipo di fiducia. Quella presunta nasce quando l’esistenza di una policy viene considerata sufficiente; quella guadagnata richiede invece prove che la policy sia stata effettivamente applicata. La differenza si concretizza in un audit trail capace di documentare come ogni copia dei dati sia stata protetta. Senza questa evidenza, le deroghe occasionali possono accumularsi mentre i team cercano di far viaggiare i dati alla stessa velocità dei flussi AI.
Nel lavoro agentico, anche eccezioni apparentemente innocue possono combinarsi. Un codice postale non mascherato in un dataset e un’età visibile in un altro potrebbero, insieme, permettere di individuare una persona. Gli agenti ampliano il perimetro perché operano autonomamente, interrogano sistemi diversi e richiamano altri strumenti. Possono quindi scoprire una correlazione rischiosa che un essere umano non avrebbe considerato, oppure memorizzarla e riprodurla a valle, aumentando l’impatto di una singola deroga alla protezione dei dati.
Anche il tradizionale data masking mostra i suoi limiti. Sostituire valori reali con dati falsi dello stesso formato permette di testare il software senza esporre informazioni sensibili. I modelli AI, però, devono apprendere schemi e relazioni statistiche: rimpiazzare un’età con un numero casuale ma plausibile può far superare un test applicativo, alterando però le proprietà del dataset e producendo comportamenti predittivi errati. Proteggere la struttura non basta se non vengono preservati realismo e correlazioni.
Per questo i partecipanti indicano la tutela dei dati non strutturati come principale ostacolo all’adozione di AI e ML, mentre l’integrità referenziale figura tra le preoccupazioni centrali. Dati protetti ma privati delle relazioni corrette tra sistemi possono diventare inutili, o persino pericolosi, per addestramento, test e sviluppo applicativo. La preparazione effettiva richiede inoltre di sapere dove risiedono le informazioni sensibili nell’intera infrastruttura: i dati di training arrivano dai sistemi sorgente e non nascono nella pipeline AI.
Mettere in sicurezza soltanto la pipeline equivale, nell’immagine proposta da Ahluwalia, a riparare la porta lasciando aperta una finestra sul retro. La risposta parte dalla scoperta dei dati e dei loro flussi, prosegue con protezione automatica, mascheramento o generazione di dati sintetici realistici, distribuzione rapida tramite virtualizzazione e conservazione delle prove necessarie agli audit. La fiducia diventa così verificabile: non una conseguenza del documento di policy, ma il risultato di controlli applicati lungo ogni passaggio delle informazioni.