7 errori sulla privacy dei dati degli agenti AI che fanno trapelare in silenzio i dati della tua azienda (e come evitarli)

La maggior parte delle fughe di dati degli agenti AI non deriva dal modello che memorizza segretamente la tua azienda. Deriva da errori di configurazione e architettura che puoi identificare e correggere. I principali: operare su un account di livello consumer le cui impostazioni predefinite si addestrano sui tuoi input, lasciare che un agente erediti i permessi ampi di una persona, collegare un agente rivolto al pubblico ai sistemi interni e lasciare intatta la "trifecta letale" (dati privati, contenuti non affidabili e un canale di invio esterno) così che una singola prompt injection possa leggere i tuoi dati e spedirli fuori. Proprio quest'ultimo schema è il modo in cui EchoLeak (CVE-2025-32711) ha esposto dati sensibili attraverso Microsoft 365 Copilot a partire da un'email costruita ad arte, senza alcun clic dell'utente. Le soluzioni non sono esotiche, e quasi tutte sono decisioni prese prima che l'agente venga lanciato, non una checklist consegnata dopo che qualcosa è trapelato.

Questa è la lista che affrontiamo prima di mettere un agente che abbiamo costruito dentro lo stack di un'altra azienda, scritta in modo che un titolare non tecnico possa individuare gli stessi errori nella propria configurazione o in quella di un fornitore. Se preferisci che siamo noi a tenere questa linea dove deve stare per te, scopri come gestiamo la governance e il rischio dell'AI responsabile. Tutto ciò che segue è comunque tuo da usare.

Prima, una distinzione che quasi ogni articolo su questo tema confonde, perché sbagliarla è l'errore zero. Ci sono due modi completamente diversi in cui i dati escono attraverso un agente, e hanno soluzioni completamente diverse:

• Gestione dei dati da parte del fornitore. Il fornitore del modello conserva o si addestra sui tuoi input? Questo è un contratto che firmi e un livello di account che scegli. Si risolve con condizioni contrattuali e configurazione.
• Esfiltrazione a runtime. L'agente può essere ingannato, nel momento in cui viene eseguito, e indotto a inviare i tuoi dati dove non dovrebbero andare? Questo si risolve con l'architettura, non con un contratto.

I numeri dei sondaggi dicono che gli acquirenti lo percepiscono anche quando non riescono a nominarlo. Nella ricerca di Cloudera su quasi 1.500 senior IT leader in 14 paesi, il 96% prevede di ampliare l'uso degli agenti AI nel prossimo anno, eppure il 53% (più della metà) indica la privacy dei dati come principale ostacolo all'adozione. I sette errori qui sotto sono il punto in cui quella paura diventa una fuga reale, e dove vive la soluzione.

Errore 1: eseguire agenti di produzione su account di livello consumer

Questo è l'errore più economico da commettere e il più facile da correggere. Qualcuno collega un flusso di lavoro a un account ChatGPT personale o Gemini consumer perché è già lì, e ora i dati della tua azienda sono regolati da condizioni consumer che non erano mai state pensate per loro.

Il divario tra i livelli consumer ed enterprise è netto. Sul lato enterprise, lo schema è coerente tra i fornitori: nessun addestramento sui tuoi dati per impostazione predefinita, una finestra di conservazione breve per il monitoraggio degli abusi e opzioni più forti su richiesta. L'API di OpenAI conserva i dati per 30 giorni per il monitoraggio degli abusi e poi li cancella, e non vi si addestra per impostazione predefinita. A partire dal 14 settembre 2025, Anthropic ha ridotto la conservazione dei log dell'API da 30 giorni a 7 giorni, e gli input e gli output dell'API non vengono mai usati per l'addestramento. Vertex AI di Google (il livello enterprise) è configurabile senza utilizzo per l'addestramento. Sul lato consumer le impostazioni predefinite si capovolgono: ChatGPT consumer conserva le conversazioni a tempo indeterminato a meno che tu non le cancelli, e la conservazione di Gemini consumer arriva fino a 36 mesi e può essere usata per migliorare i prodotti.

La soluzione: metti ogni agente di produzione su un'API enterprise o un account business, mai un login personale. La tecnologia è identica. Le condizioni no, e le condizioni sono l'intera differenza tra dati che restano governati e dati che diventano in silenzio materiale di addestramento.

Errore 2: permessi troppo ampi che l'agente eredita

La fuga a runtime più comune non è ingegnosa. A un agente viene dato l'accesso di un dipendente, o peggio una chiave di amministratore, così che tecnicamente possa vedere tutto ciò che quella persona può vedere. Poi gli viene posta una domanda, o viene indotto con l'inganno a porsene una, che va ben oltre il suo compito.

Il Cloud Adoption Framework di Microsoft enuncia la regola chiaramente: "Concedi agli agenti l'accesso solo alle fonti di dati specifiche richieste dalla loro funzione. Non fornire un accesso ampio a tutti i dati organizzativi." Un agente di assistenza non ha bisogno del tuo sistema delle buste paga. Un agente di pianificazione non ha bisogno del database dei clienti. Quando un agente agisce per conto di una persona, dovrebbe ereditare i permessi di quella persona trasmettendone in modo sicuro l'identità, così che un agente di helpdesk mostri a un dipendente solo il proprio fascicolo delle risorse umane, non quello di tutti.

La soluzione: dai a ogni agente la sua identità, con ambito a privilegio minimo, e fai in modo che erediti i permessi dell'utente che agisce invece di portare con sé un sovrainsieme permanente. Il test è semplice. Se l'agente viene ingannato domani, il danno è limitato all'insieme ristretto che gli era stato concesso, non a tutto ciò che un singolo account con permessi eccessivi potrebbe raggiungere.

Errore 3: agenti rivolti al pubblico collegati ai dati interni

Un chatbot sul tuo sito web e un agente che redige report interni sono due mondi di sicurezza diversi, e la fuga avviene nel momento in cui qualcuno permette loro di condividere un backend. Un agente pubblico riceve input da chiunque su internet. Se quello stesso agente può anche interrogare i dati aziendali interni, hai costruito una porta che va dal web pubblico direttamente ai tuoi sistemi privati.

Il framework di Microsoft traccia qui la linea più dura: "Gli agenti rivolti al pubblico non devono accedere ai dati aziendali interni." Mantieni i dati riservati e quelli pubblici separati da un confine fisico o logico (il loro esempio usa gruppi di gestione separati "corp" e "online"). Il punto è che il confine è strutturale, non la speranza che il prompt tenga.

La soluzione: metti un confine reale tra gli agenti che ricevono input pubblici non affidabili e gli agenti che toccano dati riservati. Se un singolo agente deve davvero fare entrambe le cose, quello è il design a più alto rischio che puoi scegliere, e ha bisogno dei controlli che spezzano la trifecta descritti nei prossimi errori, non solo di un prompt di sistema accurato.

Errore 4: ignorare la trifecta letale

Questo è l'errore che trasforma i primi tre in un'esfiltrazione vera e propria. Simon Willison, l'esperto indipendente che ha coniato il termine "prompt injection", ha definito la "trifecta letale" per gli agenti AI: tre condizioni che, quando combinate, permettono a una singola istruzione iniettata di rubare i tuoi dati.

Quando tutte e tre sono presenti, un aggressore nasconde un'istruzione all'interno del contenuto non affidabile. Il modello, nelle parole di Willison, "seguirà volentieri qualsiasi istruzione che arrivi al modello, che provenga dal suo operatore o da qualche altra fonte." Legge i tuoi dati privati e li invia all'esterno, e nulla nel prompt gli ha detto di non fidarsi dell'email.

La parte cruda, e il motivo per cui questa è architettura e non un problema di prompt engineering: "non sappiamo ancora come prevenire questo fenomeno in modo affidabile al 100%." Exploit documentati hanno colpito Microsoft 365 Copilot, il server MCP di GitHub e GitLab Duo. In una settimana di gennaio 2026, sono state divulgate vulnerabilità di prompt injection indiretta in quattro strumenti di produttività AI, tutte con lo stesso schema della trifecta.

La soluzione: spezza una gamba. Nega il canale di invio esterno così che i dati rubati non abbiano dove andare, oppure non lasciare mai che un agente che legge contenuti non affidabili detenga anche l'accesso a dati privati nello stesso contesto. Non devi vincere la battaglia impossibile di intercettare ogni injection. Devi assicurarti che anche un'injection riuscita non abbia alcuna via d'uscita.

Errore 5: trattare EchoLeak come un problema di qualcun altro

Vale la pena nominare un incidente reale, perché "la trifecta letale" suona astratta finché non la vedi messa in atto. EchoLeak (CVE-2025-32711) è stato un attacco zero-click su Microsoft 365 Copilot. Un aggressore ha inviato un'email costruita ad arte. Copilot, svolgendo il suo normale lavoro, ha elaborato quell'email (contenuto non affidabile), aveva accesso ai dati interni dell'utente (dati privati) e aveva un modo per inviare informazioni all'esterno (comunicazione esterna). L'istruzione nascosta ha portato a termine l'esposizione di dati sensibili senza alcuna interazione da parte dell'utente. Nessuno ha cliccato nulla.

L'errore qui è presumere che una fuga richieda un dipendente distratto. EchoLeak non ne ha richiesto nessuno. La difesa che contava non era "formare il personale a riconoscere il phishing", perché non c'era nulla che un essere umano potesse riconoscere. La difesa era architetturale: un agente che non può sia leggere contenuti controllati da un aggressore sia esfiltrare non può essere rivolto contro di te in questo modo.

La soluzione: assumi che lo zero-click sia il modello di minaccia, non l'eccezione. Se il tuo agente legge qualsiasi cosa che un esterno possa influenzare (email, contenuti web, file caricati, ticket) e può anche inviare dati all'esterno, hai un buco a forma di EchoLeak finché non chiudi una di quelle due capacità o non blindi rigidamente il canale di invio.

Errore 6: nessun confine di residenza o conservazione dei dati

Alcune fughe non sono esfiltrazioni drammatiche, sono una deriva lenta. I dati finiscono per essere conservati in una regione che non hai mai accettato, o restano nei log più a lungo di quanto la tua policy consenta, semplicemente perché nessuno ha impostato il confine. Il framework di Microsoft elenca questo come governance fondamentale: identifica la posizione di ogni fonte di dati, runtime dell'agente e archivio di output, mantieni i dati in regioni o on-prem conformi alla tua policy di residenza e mantienili crittografati a riposo.

La notizia rassicurante, che quasi nessun articolo afferma chiaramente, è quanto puoi fissare con precisione. Lo schema enterprise tra i fornitori è nessun addestramento per impostazione predefinita, più una finestra di conservazione breve, più garanzie più forti su richiesta. Anthropic offre alle imprese idonee un accordo di Zero Data Retention (ZDR), in base al quale input e output non vengono conservati oltre quanto necessario per controllare gli abusi. OpenAI offre ZDR tramite un accordo negoziato e la residenza dei dati. Entrambi ti permettono di scegliere dove risiedono i dati. Ospitare in proprio un modello open (ad esempio con Ollama) mantiene i dati completamente locali con zero conservazione da parte di terzi.

La soluzione: decidi e documenta il confine prima del lancio. Quale regione conserva i dati, quanto a lungo vivono i log, se ti serve lo ZDR, e se il recupero di dati sensibili debba avvenire nella tua VPC o on-prem. Lo ZDR è di solito limitato all'API e negoziato, e non copre automaticamente ogni prodotto a meno che tu non lo aggiunga, quindi il dettaglio conta.

Errore 7: trattare la privacy come una checklist da consegnare

L'ultimo errore è strutturale. La maggior parte delle linee guida, incluso l'eccellente framework di Microsoft, presuppone che sarai tu a costruire e governare l'agente, quindi ti consegna una pila da 3.000 parole di identità Entra, etichette Purview e gruppi di gestione. Questa è la risposta giusta per un grande team IT. Per la maggior parte delle aziende è una checklist che nessuno ha il tempo o la competenza specialistica per implementare completamente, quindi viene rilasciata a metà, e i vuoti sono esattamente il punto in cui i dati trapelano.

L'errore è trattare i controlli come documentazione invece che come un'architettura di cui qualcuno è responsabile dall'inizio alla fine. Una checklist che elenca "isola i dati riservati" e "limita le integrazioni esterne a server MCP affidabili" vale solo quanto la persona che la collega, che convalida ogni comunicazione esterna e che predispone il piano di incidente per disabilitare rapidamente un agente quando qualcosa va storto.

La soluzione: assicurati che una parte sia effettivamente responsabile del confine, non solo del documento. O costruisci la capacità interna di implementare e mantenere l'intero stack, oppure hai un operatore che progetta l'eliminazione di queste modalità di guasto e le gestisce, con un confine pubblicato a cui puoi fare riferimento. La via di mezzo sbagliata è un elenco di controlli e nessuno responsabile della loro tenuta.

Come si allineano i sette errori e le soluzioni

Eccoli tutti e sette in un unico posto, ordinati a seconda che la soluzione sia un contratto che firmi o un'architettura che costruisci. Questa suddivisione è il modo più rapido per sapere quale team è responsabile di ciascuno.

Nota che solo due dei sette si risolvono con un contratto. Gli altri cinque sono architettura e responsabilità, che è la parte che un PDF di best practice non può fare per te. È anche il motivo onesto per cui le fonti autorevoli lasciano un vuoto: ti dicono cosa costruire, non chi lo costruirà correttamente all'interno dei tuoi sistemi specifici.

Cosa non esce davvero mai, quando il confine è costruito bene

È facile leggere sette errori e concludere che gli agenti AI siano un campo minato per la privacy. Non lo sono, quando la linea è tracciata in modo deliberato. Con condizioni enterprise, i tuoi input non sono dati di addestramento, e la conservazione è di giorni, non per sempre (7 per l'API di Anthropic, 30 per OpenAI, poi cancellati). Con lo ZDR, non vengono conservati oltre il controllo degli abusi. Con la residenza dei dati fissata, restano nella tua regione. Con il recupero tramite VPC o on-prem, i dati sensibili non lasciano mai il tuo perimetro. Con l'oscuramento al confine, i campi che non dovrebbero mai viaggiare vengono rimossi prima che qualcosa venga inviato. Con un ambito a privilegio minimo che eredita i permessi dell'utente, l'agente può raggiungere solo ciò che la persona che agisce poteva già raggiungere.

Questo è un confine specifico e difendibile, ed essere in grado di enunciarlo chiaramente è il punto centrale. Il pericolo non è mai stato il modello che assorbe in silenzio la tua azienda. Sono i sette errori di configurazione e architettura qui sopra, ognuno dei quali è prevenibile prima che il primo agente entri in funzione.

Questo è il lavoro che facciamo dentro gli stack di altre aziende: scegliere le condizioni, definire l'ambito delle identità, isolare il pubblico dal riservato, spezzare la trifecta e farsi carico del confine così che tenga. Se vuoi che questi errori vengano eliminati dall'architettura dei tuoi agenti prima che tocchino qualcosa di reale, prenota una consulenza gratuita qui sotto e mapperemo insieme il tuo confine.