Dati sensibili e AI: come evitare leakage senza fermare l’adozione

Quando porti l’AI dentro un processo, stai facendo una scelta operativa: stai trasformando testo in azione. Il problema è che i processi reali non girano su “testo pulito”: girano su email, PDF, chat, contratti, note, allegati. E lì dentro ci sono sempre dati sensibili.

Il leakage raramente arriva con un alert “ho rubato dati”. Arriva come output che sembra legittimo: un riassunto che include PII inutile, un memo che “cita” un dettaglio confidenziale, un ticket che finisce nel canale sbagliato. Il punto non è vietare l’AI. Il punto è progettare confini che abilitano senza far scappare dati.

1) Leakage: non è un “bug”, è un fallimento di design

Quando un’azienda scopre un leakage, spesso reagisce con la mossa peggiore: bloccare tutto. Ma la radice è quasi sempre la stessa: l’AI è stata introdotta come “tool”, senza un perimetro. E un perimetro, in pratica, significa tre cose: quali dati entrano, quali fonti può usare, quali azioni può compiere.

Se non definisci questi tre confini, il sistema si comporta come un assistente che “fa del suo meglio”. In produzione, “fare del suo meglio” è un rischio: perché massimizza completezza, non minimizza esposizione.

2) La regola dei 3 livelli: cosa può entrare (e cosa no)

La governance che funziona non è un manuale da 80 pagine. È una regola semplice che tutti capiscono. Io uso una classificazione a tre livelli: è abbastanza precisa da proteggere, abbastanza semplice da essere adottata.

• Pubblico: dati e contenuti che puoi mettere in una slide o su un sito (zero problemi).
• Interno: informazioni operative (procedure, KPI, cataloghi) — ok per workflow interni, ma con tracciabilità.
• Riservato: PII, segreti, credenziali, contratti, HR, M&A — entrano solo con controlli (masking, accessi, evidenze) e spesso con human final click.

Questa regola non “rallenta”. Al contrario: riduce discussioni infinite. Se vuoi rendere la regola operativa, collegala subito a un controllo pratico: Compliance Mapper per mappare obblighi/owner/evidenze, e Reference Architecture per vedere dove mettere guardrail e logging.

3) I 5 punti dove “scappa” (anche senza cattiveria)

Il leakage non richiede un attaccante sofisticato. Basta una frizione sbagliata nel percorso ufficiale. Questi sono i punti dove lo vedo succedere più spesso:

1. Copy/paste: qualcuno incolla un contratto o un dataset in un tool non approvato perché è più veloce.
2. RAG senza ACL: la retrieval pesca contenuti “troppo larghi” o di altri team/cliente.
3. Output senza vincoli: il modello ottimizza per completezza e mette dettagli non necessari.
4. Log e tracing: prompt e output finiscono in log con retention infinita (e diventano un nuovo data lake).
5. Tool che agiscono: email inviate, ticket aperti, record aggiornati: l’azione amplifica l’errore.

Se ti suona familiare, è normale: è esattamente quello che succede quando porti un sistema “testuale” dentro workflow reali. La risposta non è vietare: è progettare il percorso approvato in modo che sia più semplice della scorciatoia.

4) I controlli che riducono leakage senza uccidere l’UX

Se aggiungi “sicurezza” come step extra, perdi adozione. Se invece la sicurezza è integrata nel workflow, ottieni l’effetto opposto: meno Shadow AI e più controllo. Questi sono i controlli che applico per dati sensibili:

1. Input policy + UI: spiega in chiaro cosa si può incollare e cosa no (regola a 3 livelli).
2. Masking automatico: PII e segreti redatti prima di entrare nel prompt (evidence + log).
3. RAG “safe”: fonti approvate, ownership, versioning e ACL (non “cerca ovunque”).
4. Tool allowlist + least privilege: pochi tool, scope stretto, default deny.
5. Output constraints: template, campi obbligatori, limiti (niente free‑form dove serve precisione).
6. Redazione in uscita: post‑processing che rimuove PII/segni distintivi non necessari.
7. Human final click: per output esterni o irreversibili (email a clienti, pagamenti, modifiche critiche).
8. Retention e audit trail: log minimi ma completi, cifrati, con retention definita e accessi tracciati.

Se vuoi collegare questi controlli a requisiti “da firma” (procurement, audit, AI Act), guarda anche AI Act e l’articolo su prompt injection: leakage e injection sono spesso due facce della stessa architettura.

5) KPI: misurare rischio e frizione (insieme)

Se misuri solo “incidenti”, ti accorgi tardi. Se misuri solo “frizione”, fai sicurezza cosmetica. Io misuro entrambi: rischio e usabilità.

• Redaction rate: quante richieste richiedono masking (ti dice dove sei davvero esposto).
• Unauthorized retrieval attempts: quante retrieval vengono negate da ACL/policy.
• Leakage incidents: output con dati non autorizzati (target: zero, sempre).
• Human-review rate: quante richieste passano a revisione (e perché).
• False-positive friction: quante richieste legittime vengono bloccate (va ridotto con tuning e template).
• Time-to-detect: quanto tempo ci metti a capire che qualcosa sta andando storto.

Questa metrica “doppia” (rischio + frizione) è ciò che rende sostenibile l’adozione. Quando la sicurezza migliora l’esperienza, le persone smettono di cercare scorciatoie.

6) Piano 30 giorni: porta un workflow “sensibile” in produzione

Il modo migliore per ridurre leakage è non fare “big bang”. Si parte da un workflow, si definiscono confini, si misura, poi si scala. Questo è un piano che uso spesso per portare l’AI in produzione in modo procurement‑ready.

Giorni 1–7 — Perimetro + policy + owner

• Scegli 1 workflow con alto valore e alta sensibilità (es. email clienti, ticket, contratti).
• Classifica dati con la regola a 3 livelli; definisci cosa può entrare e cosa no.
• Nomina owner, escalation e regola di stop (quando l’AI deve fermarsi).

Giorni 8–14 — Guardrail: masking + ACL + template

• Masking automatico per PII/segreti + redazione in uscita.
• RAG con fonti approvate e ACL (least privilege).
• Template di output e human final click per azioni esterne.

Giorni 15–30 — Osservabilità + test + rollout controllato

• Logging per audit trail (input/fonti/output/decisione) con retention definita.
• Dashboard KPI (redaction, deny, review, incidenti, time-to-detect).
• Test set “leakage” + regressioni a ogni release; rollout progressivo con fallback.

Alla fine non hai “un bot”: hai un processo più veloce e più difendibile. E soprattutto hai un modello operativo replicabile su altri workflow.

Conclusione: l’AI vince quando la sicurezza è invisibile

Il leakage non si risolve con una policy scritta bene. Si risolve rendendo il percorso approvato più semplice della scorciatoia: guardrail integrati, evidenze, e un modello che sa quando fermarsi.

Se vuoi portare un workflow con dati sensibili in produzione (senza incidenti e senza attrito inutile), scrivimi: in assessment definiamo perimetro, controlli, KPI e roadmap eseguibile.