C’è un modo molto diffuso di adottare l’AI in area business: si compra “un po’ di intelligenza”, la si collega ai documenti aziendali, e si spera che la compliance sia un accessorio tipo cintura di sicurezza, utile ma non indispensabile finché non arriva l’impatto. Il problema è che, con l’AI, l’impatto non è sempre un incidente visibile. A volte è un lento scivolamento di dati, responsabilità e potere decisionale fuori dal perimetro dell’organizzazione. E quando ci si accorge che il perimetro era importante, spesso è già diventato un ricordo nostalgico.
La tesi di questo articolo è semplice e poco comoda: adottare un LLM non è solo una scelta tecnologica, è una scelta di governance dei dati e di sovranità operativa. Non basta chiedersi “quanto è bravo il modello?”, bisogna chiedersi “che cosa succede ai nostri dati nel loro ciclo di vita, sotto quali leggi, e con quale possibilità di controllo e prova?”.
Se questa domanda resta senza risposta, non si sta “adottando AI”. Si sta subappaltando una parte del proprio sistema nervoso a terzi, sperando che non intraprendano iniziative.
AI Act, Europa, compliance
Nel contesto europeo la discussione non è più teorica. L’AI Act è entrato in vigore il 1 agosto 2024 e la Commissione continua a pubblicare aggiornamenti e materiali operativi; ciò significa che l’adozione in azienda va letta in una traiettoria di obblighi che si avvicinano, e non in una bolla di sperimentazione eterna. (European Commission) Il GDPR resta il riferimento principale per i dati personali e i principi cardine, ma oggi dialoga con un ecosistema regolatorio in cui, per un’organizzazione, “fare le cose bene” coincide sempre più con “sapere dimostrare come le stai facendo”.
Da qui nasce una domanda pratica, che vale più di qualunque confronto tra demo: che tipo di dati “muove” davvero un LLM quando lo usi internamente per email, traduzioni e produzione documentazione, oppure quando lo metti davanti a clienti e utenti nel customer service? E, se l’elaborazione avviene lato provider, come vengono gestiti i dati nel dettaglio, e dove lo trovi scritto in modo verificabile negli agreement e nella documentazione?
Cinque famiglie di dati
Quando diciamo che un LLM “muove dati”, non stiamo parlando solo di quello che l’utente incolla nel prompt. Stiamo parlando di una filiera composta da contenuti, contesto recuperato, metadati, dati derivati e tracce operative. È utile pensare a cinque famiglie di dati, perché questa mappa aiuta a fare domande corrette ai fornitori e a non farsi ipnotizzare dal nome del modello.
La prima famiglia è la più ovvia e, proprio per questo, spesso trattata con eccessiva superficialità: i dati che l’utente inserisce direttamente. Prompt testuali, allegati, porzioni di contratti, estratti di email, ticket, log applicativi, presentazioni, richieste HR, note di riunione. In azienda, questo significa quasi inevitabilmente dati personali e informazioni confidenziali che, nel mondo reale, convivono nella stessa frase. Un dipendente non scrive “dato personale” in rosso e “segreto industriale” in blu. Scrive una richiesta che li mescola, come la vita.
La seconda famiglia è spesso la più rilevante e anche la meno percepita: i dati richiamati automaticamente dal sistema per dare contesto, cioè i contenuti recuperati da repository aziendali quando l’assistente fa grounding o retrieval. È la differenza tra un chatbot che risponde “in generale” e un assistente che ti trova il paragrafo giusto nel documento giusto, o ti riassume una catena di email senza che tu debba incollarla. È anche il punto in cui l’AI diventa davvero utile e, nello stesso gesto, più rischiosa, perché inizia ad aggregare e ricomporre informazioni. La documentazione di Microsoft descrive esplicitamente che, in certe esperienze di Copilot, vengono memorizzati prompt e risposte dell’utente come “Copilot activity history”, e che le risposte possono includere citazioni alle informazioni usate per “grounding”. Questo dettaglio, già da solo, sposta la conversazione dagli slogan al ciclo di vita.
La terza famiglia è composta da metadati e identificatori di contesto. Anche se l’utente scrive un prompt “pulito”, la piattaforma sa chi è, a quale tenant appartiene, quali autorizzazioni ha, da quale interfaccia proviene la richiesta, quali strumenti vengono chiamati, quali policy sono attive. Inoltre, quasi sempre, esistono dati di rete, diagnostica e performance che entrano nel perimetro della telemetria.
La privacy policy di DeepSeek, per esempio, esplicita la raccolta di dati relativi al dispositivo e alla rete, come indirizzi IP, identificatori del dispositivo, log diagnostici e metriche di prestazione. Non serve trasformare questo in un verdetto universale su un brand. Serve ricordare che i metadati sono parte del “dato mosso” e che, in certi contesti, valgono quanto il contenuto.
La quarta famiglia è costituita dai dati derivati. Qui entrano embedding, indici semantici, segnali di classificazione per sicurezza e abuso, riepiloghi, prompt riscritti o “arricchiti”, e in generale tutto ciò che viene prodotto per far funzionare il servizio in modo scalabile e sicuro. È un terreno scivoloso perché spesso non è testo in chiaro, quindi viene percepito come “meno rischio”. Ma i dati derivati possono rivelare informazioni per inferenza, e soprattutto diventano oggetti a sé in retention, audit, eDiscovery e incident response.
La quinta famiglia è quella che molti scoprono solo quando un audit la illumina: le tracce operative, cioè ciò che resta per il monitoraggio degli abusi, della sicurezza e della compliance. Qui il punto non è accusare il provider di curiosità, ma riconoscere un fatto tecnico: i sistemi su larga scala hanno bisogno di logging, e quel logging può contenere informazioni importanti.
La documentazione della piattaforma API di OpenAI è molto chiara su questo aspetto: gli “abuse monitoring logs” possono contenere customer content come prompt e risposte, oltre a metadati derivati, e sono trattenuti di default fino a 30 giorni salvo obblighi legali diversi. In altre parole, anche quando un vendor afferma “non usiamo i tuoi dati per training”, può comunque conservarne tracce per sicurezza e prevenzione abusi. La distinzione tra training e retention operativa è una delle fonti più comuni di fraintendimenti in azienda.
Cosa si rischia veramente
A questo punto la domanda diventa ancora più concreta: nei casi d’uso interni, quali dati tendono a muoversi davvero? Con email, traduzioni e produzione documentazione, il rischio non nasce tanto da un output “sbagliato”, quanto dal modo naturale in cui le persone lavorano. Un’email contiene nomi, ruoli, contatti, contesto commerciale e, spesso, dettagli su problemi operativi. Una traduzione, proprio perché sembra un’operazione meccanica, induce a tradurre tutto, inclusi contratti, policy, log, ticket e documenti regolatori. La documentazione, poi, è il paradiso della densità informativa: procedure, architetture, incident report, piani di remediation, note legali.
Se l’utente alimenta l’LLM con corpus interi per “ottenere coerenza”, sta facendo un trattamento sistematico, non un uso occasionale. E se quel corpus finisce dentro history, log o sistemi di osservabilità, la superficie aumenta senza che nessuno abbia deliberato davvero di aumentarla.
Nel customer service, invece, il mix cambia ma non si semplifica. Qui i dati sono spesso più regolati e più “sensibili per contesto”: account, pagamenti, contestazioni, abitudini di consumo, e in certi settori anche informazioni su salute o situazioni personali. Inoltre, in customer service privacy e sicurezza diventano inseparabili, perché un bot è un bersaglio naturale per tentativi di esfiltrazione e manipolazione. Se il chatbot è connesso a backend, l’accesso agli strumenti va governato come se fosse un utente privilegiato che parla in linguaggio naturale. E quando si attivano log anti abuso, bisogna sapere cosa contengono e dove stanno, perché potrebbero includere conversazioni con dati personali del cliente, proprio nel momento in cui il cliente sta chiedendo aiuto e non sta firmando un contratto di data sharing.
Arriviamo al punto che spesso viene liquidato con una frase: “tanto l’analisi è lato provider”. È vero che molte inferenze avvengono su infrastrutture del provider o di un cloud partner. Ma “lato provider” non è un luogo, è un insieme di confini. E la protezione dipende dal confine, non dal nome del modello. Il mercato oggi offre versioni consumer, versioni enterprise e versioni API, e ciascuna può avere regole di retention, logging, uso dati e controlli differenti. Per questo “Copilot”, “Claude”, “ChatGPT”, “Gemini” sono parole che iniziano una conversazione, non che la chiudono.
Un esempio operativo è la documentazione di Google per l’uso di Gemini in Google Workspace: viene dichiarato che i prompt inseriti dagli utenti non sono usati per training di modelli generativi fuori dal dominio senza permesso, restando nel perimetro di fiducia dell’organizzazione. È un impegno rilevante, ma va sempre letto insieme alle condizioni specifiche del prodotto e alle configurazioni amministrative effettivamente attive, perché la realtà aziendale vive di impostazioni e di default, non di intenzioni.
Un altro esempio, ancora più “da governance”, è l’ecosistema di Microsoft 365 Copilot, dove la documentazione afferma che le interazioni vengono memorizzate come activity history e possono ricadere in meccanismi di audit e compliance di Microsoft, e dove esistono articoli dedicati all’audit logging di Copilot e applicazioni AI. Questo è un bene e un rischio allo stesso tempo, perché significa tracciabilità e controllo, ma significa anche che prompt e output diventano oggetti governabili con retention, eDiscovery, e policy interne. Non sono più “chat effimere”. Sono dati aziendali e, come tali, vanno trattati.
A complicare, o a rendere più realistico, c’è la supply chain dell’AI. Un’organizzazione può pensare di avere “un” fornitore, e invece ne ha diversi, perché il fornitore principale utilizza subprocessor o modelli di terze parti. In questo senso è significativo che la documentazione di Microsoft indichi che dal 7 gennaio 2026 Anthropic diventa subprocessor per specifiche esperienze di Copilot, con conseguenze di governance e necessità di scelta amministrativa, inclusi default diversi per alcune regioni.
Questo non è uno scandalo. È la normalità di un mercato multi modello. Ma è la normalità che un’azienda deve saper leggere, perché la sovranità non si perde solo “verso l’esterno”. Si perde anche per opacità interna della filiera.
Una domanda sugli agreement è quindi centrale: tracce e regole ci sono, ma spesso non stanno tutte nello stesso posto e raramente sono scritte con la chiarezza che la procurement vorrebbe. La gestione dei dati LLM si trova in genere nel DPA o addendum privacy, nella documentazione “privacy/data/security” del prodotto, nei documenti “your data” per le piattaforme API, e nelle liste dei subprocessor. A volte, il pezzo più importante è nella documentazione tecnica e non nel contratto principale, e viceversa. Il lavoro serio è farli parlare fra loro, perché la frase “non usiamo i tuoi dati per training” può coesistere con “conserviamo log per sicurezza”, e queste due frasi non si contraddicono. Semplicemente descrivono due rischi diversi.
Normativa, giurisdizione, sovranità
Dal punto di vista della sovranità e dei trasferimenti, inoltre, esiste un tema che torna sempre, anche quando tutti fanno finta che sia solo una questione per grandi multinazionali: la giurisdizione. Il Cloud Act statunitense, nella sua formulazione più citata, stabilisce che un provider debba preservare o divulgare contenuti e record nel proprio possesso, custodia o controllo, indipendentemente dalla localizzazione dei dati.
Questo non significa che “gli Stati Uniti leggono tutto sempre”, né che ogni richiesta sia automatica. Significa che, se un fornitore è sotto una certa giurisdizione, esiste un meccanismo legale che può imporre obblighi extraterritoriali. Ed è proprio per questo che, in Europa, dopo Schrems II, i trasferimenti non possono essere trattati come un dettaglio.
Il comunicato della Corte di Giustizia sul caso Schrems II chiarisce l’invalidazione del Privacy Shield e il mantenimento delle SCC, con l’accento sulla necessità di garantire un livello di protezione sostanzialmente equivalente. La risposta pratica a questa esigenza, nel mondo GDPR, è stata tradotta dall’EDPB nelle Recommendations 01/2020 sulle misure supplementari per i trasferimenti.
Accanto a questo, esiste lo strumento di adeguatezza per i trasferimenti UE-USA legato al Data Privacy Framework, formalizzato con la decisione di esecuzione 2023/1795. E nel 2025 il Tribunale UE ha respinto un’azione di annullamento, confermando che, alla data di adozione della decisione, gli USA garantivano un livello adeguato per i trasferimenti verso organizzazioni incluse nel framework, pur in un contesto dove il dibattito resta vivo.
Per un’azienda la postura utile è duplice: usare strumenti validi quando applicabili, ma non trattarli come amuleti che annullano la necessità di valutare il caso d’uso e la configurazione tecnica. Un assistente che riceve dati minimizzati è un carico leggero; un sistema connesso a email, repository e ticketing, con logging e telemetria estesi, è un carico molto diverso.
Il tema “memoria” e “modello” merita poi una considerazione a parte. Negli ultimi anni, l’Europa ha iniziato a trattare in modo meno ingenuo la domanda: un modello può incorporare dati personali o renderli inferibili? L’Opinion 28/2024 dell’EDPB affronta proprio aspetti come anonimizzazione del modello, basi giuridiche e conseguenze dell’eventuale illiceità nella fase di sviluppo sul trattamento successivo. Per un’azienda questo significa che non basta dire “non conserviamo i prompt” se, per il caso d’uso, esistono meccanismi di fine tuning, feedback o log che possono creare persistenze. Significa anche che la governance deve prevedere evidenze e procedure, non solo policy scritte.
Sul piano operativo, le autorità stanno producendo materiale che può essere usato come base pragmatica, non come letteratura. La CNIL, ad esempio, ha pubblicato raccomandazioni per uno sviluppo di sistemi AI conforme al GDPR con un approccio a passi, includendo scelte su finalità, responsabilità, basi giuridiche e DPIA. Questo è utile anche quando l’azienda non “sviluppa” un LLM, perché integra e riusa sistemi AI, e integrare è un modo sofisticato di assumersi responsabilità.
Il caso italiano resta un riferimento perché dimostra che la teoria può diventare operatività in tempi rapidi. Il provvedimento del Garante per la protezione dei dati personali del 31 marzo 2023 su ChatGPT ha imposto una limitazione provvisoria sul trattamento e ha acceso l’attenzione su base giuridica, trasparenza e tutela dei minori. Nel 2024 l’Autorità ha comunicato la chiusura della fase istruttoria con prescrizioni e misure informative, e fonti internazionali hanno riportato l’applicazione di una sanzione significativa e l’obbligo di una campagna informativa. Il valore per le imprese è capire che, quando un servizio AI tocca dati personali e utenti, la trasparenza e la governance non sono accessori. Sono requisiti che possono diventare blocchi, correttivi, costi e reputazione.
Impostare un progetto in sei gesti
A questo punto, dopo aver guardato il “dato mosso” e i confini contrattuali, serve una conclusione che sia utile per l’adozione e non solo per l’analisi. Se un’azienda vuole adottare LLM per uso interno e customer service senza farsi risucchiare da rischi e lock in, deve impostare una disciplina che assomiglia più a un progetto di data governance che a un acquisto di software.
Il primo gesto maturo è classificare i casi d’uso per rischio e per tipo di dato che possono muovere, non per entusiasmo. Un assistente di scrittura con prompt minimizzati non è paragonabile a un bot che interagisce con account cliente, e nessuno dei due è paragonabile a un sistema che influenza decisioni su persone. Quando la criticità cresce, devono crescere controllo, auditabilità e limiti.
Il secondo gesto è mappare il ciclo di vita dei dati in modo completo. Prompt, output, contesto recuperato, embedding e indici, log di sicurezza e abuso, telemetria, supporto tecnico, audit. Bisogna sapere cosa viene conservato, per quanto, dove, e con quali strumenti interni si governa la retention. Qui la documentazione tecnica è fondamentale, perché spesso è l’unico posto dove la retention operativa viene descritta in modo esplicito, come nel caso dei log di abuso sulle API.
Il terzo gesto è decidere una strategia di minimizzazione e filtraggio “prima del prompt”. È una misura di igiene. Redazione automatica di identificativi, masking, policy che impediscano l’incolla di documenti interi, formazione e guardrail, e, quando serve, strumenti DLP specifici per i canali AI. L’obiettivo è impedire che l’uso spontaneo diventi una pipeline di leakage.
Il quarto gesto è trattare la supply chain come parte integrante della scelta. Subprocessor, connettori, agent, modelli alternativi abilitati per default, e differenze di confine tra consumer ed enterprise. L’esempio del subprocessing di Anthropic in Copilot rende bene l’idea: anche se il fornitore principale resta lo stesso, il perimetro reale si espande e cambia.
Il quinto gesto è fare contratti che parlino la lingua dell’AI, e non solo la lingua del cloud di ieri. Serve chiarezza su uso dati per training e miglioramento, retention di prompt e output, logging per abuso, subprocessor, audit, incident response, richieste governative, e opzioni come configurazioni a maggiore isolamento. Se un vendor non accetta trasparenza su queste aree, l’azienda deve prendere atto che sta acquistando anche opacità, e l’opacità è un rischio, non una feature.
Il sesto gesto è mantenere sovranità economica oltre che giuridica e tecnica. Il lock in non arriva solo dai formati, arriva dall’abitudine. Se tutta la produttività, la ricerca documentale e i processi di customer service si appoggiano a una sola piattaforma senza strategia di uscita, la capacità di cambiare diventa teorica. E quando la capacità di cambiare diventa teorica, la sovranità diventa retorica.
In conclusione, usare LLM in azienda senza perdere protezione dei dati e sovranità è possibile, ma richiede una scelta adulta: smettere di parlare solo di modelli e iniziare a parlare di flussi. Il “dato mosso” è la realtà, non il dettaglio. I confini contrattuali e tecnici sono la differenza tra un progetto governato e un esperimento permanente. E la differenza più importante, alla fine, non è tra AI USA, AI Cina o AI Europa. È tra ciò che puoi dimostrare e ciò che speri.
Antonio Ieranò
Sono un cybersecurity strategist, scrittore e “professionista del disturbo”, con oltre vent’anni trascorsi nelle trincee fra tecnologia, diritto e quel raro animale mitologico chiamato buon senso.
Tra le varie cose, Ex Security Evangelist in Cisco, Huawei e Proofpoint, mi diverto a tradurre complessità in qualcosa che gli esseri umani possano usare davvero: trasformo acronimi in storie, e storie in decisioni un po’ meno sbagliate.
Scrivo di cybersecurity, regolazione e dell’assurdità dell’era digitale con umorismo, ironia e una fastidiosa precisione tecnica. Il tono può strappare un sorriso, ma il messaggio tende a lasciare il segno.
Quando non scrivo, non parlo o non discuto (quasi sempre) educatamente con le normative, di solito suono la chitarra abbastanza forte da interferire con il Wi-Fi. 🎸
