Under the Hood:
cosa succede ai dati forniti a un modello linguistico
Un’analisi del funzionamento tecnico dei modelli generativi e delle sue conseguenze, anche in relazione al GDPR.
Il dibattito sull’uso dell’AI con dati aziendali tende a polarizzarsi su due posizioni: chi considera i modelli generativi software ordinari, utilizzabili senza cautele particolari, e chi considera qualsiasi inserimento di dati in un servizio come ChatGPT una violazione, da vietare. Entrambe le posizioni trascurano il funzionamento effettivo della tecnologia. È da questo che conviene partire: la maggior parte delle domande sull’uso dei dati trova risposta sul piano tecnico, e da quella risposta discendono le valutazioni giuridiche.
Un modello linguistico non è un archivio. Non contiene record o file da cui estrarre le risposte: è una funzione di grandi dimensioni che, dato un testo in ingresso, calcola la probabilità di ciascun possibile frammento di testo (token) successivo, ne sceglie uno e ripete il processo iterativamente.
Ne derivano due conseguenze.
La prima: l’addestramento e la valutazione dei modelli premiano il tentativo di risposta più dell’ammissione di incertezza. In assenza dell’informazione il modello produce comunque un output, con lo stesso grado di apparente sicurezza. Le cosiddette allucinazioni si possono ridurre, ma non eliminare con un aggiornamento: derivano dalla stessa proprietà che rende il modello utile, e il modello non segnala quando sta generando contenuti privi di fondamento. Nessun fornitore garantisce l’accuratezza: i termini d’uso specificano che l’output può essere falso, incompleto o fuorviante.
La seconda: il modello non è in grado di spiegare le ragioni di una risposta. Può produrre una giustificazione plausibile, ma si tratta di un’ulteriore generazione, non di una descrizione dei suoi meccanismi interni. Su questo punto la tecnica incontra il diritto: quando una decisione basata unicamente su un trattamento automatizzato produce effetti giuridici o analogamente significativi su una persona, il GDPR (art. 22, in combinato con gli artt. 13-15) le riconosce il diritto a informazioni significative sulla logica utilizzata.
Sul piano operativo ne consegue che la supervisione umana resta necessaria: il modello può essere il primo revisore, mai l’ultimo.
Esistono tre modalità di utilizzo di un LLM, con implicazioni molto diverse.
Per un utente europeo le questioni rilevanti sono tre.
La prima riguarda la localizzazione dei dati. Il trasferimento di dati personali fuori dall’Unione non è vietato, ma richiede uno degli strumenti previsti dal GDPR per i trasferimenti, come una decisione di adeguatezza o le clausole contrattuali standard; la soluzione più semplice e solida è la data residency UE, cioè l’elaborazione e la conservazione dei dati su server situati nell’Unione. Quando un fornitore tratta dati personali per conto dell’utente è inoltre necessario un DPA (Data Processing Addendum). La versione a pagamento di un servizio non è necessariamente quella che conserva i dati in Europa, e non tutti i principali fornitori offrono una residency UE diretta.
La seconda riguarda l’uso dei dati per l’addestramento. Nelle versioni consumer, gratuite o con abbonamento individuale, la maggior parte dei principali fornitori utilizza oggi i dati per l’addestramento come impostazione predefinita: OpenAI, Google, Mistral e, dall’autunno 2025, anche Anthropic (che ha chiesto a ogni utente di scegliere, con l’opzione di addestramento preimpostata come attiva). È previsto un opt-out, che deve essere attivato dall’utente. Nelle versioni business, Enterprise e API a pagamento l’addestramento è invece escluso per impostazione predefinita, e l’esclusione è prevista contrattualmente; i livelli API gratuiti possono invece prevederlo, salvo eccezioni regionali (Google, ad esempio, applica agli utenti europei le condizioni a pagamento anche sul livello gratuito). Le condizioni cambiano e vanno verificate periodicamente nella documentazione dei fornitori.
La terza riguarda l’accesso ai log. Possono accedervi, anzitutto, i team interni del fornitore. Nel caso di fornitori statunitensi, anche le autorità USA: il CLOUD Act obbliga i fornitori soggetti alla giurisdizione americana a consegnare, su ordine delle autorità, i dati sotto il loro controllo anche quando sono conservati fuori dagli Stati Uniti. Un server a Francoforte non offre quindi le stesse garanzie se il fornitore è americano. Per i fornitori cinesi, come DeepSeek o Qwen, la legge sull’intelligence del 2017 impone la collaborazione con i servizi nazionali: per i dati sensibili, le loro versioni cloud sono da evitare.
A questo si aggiunge il rischio di estrazione da parte di terzi: attraverso il prompt injection è possibile indurre un modello a rivelare informazioni riservate, e nessun fornitore ne è immune.
Salvo modalità specifiche, come le chat temporanee o i contratti di zero data retention, la conversazione viene conservata nello storico. Questa è la condizione di partenza, non lo scenario peggiore.
Cancellare una conversazione è semplice. Rimuovere un’informazione acquisita durante l’addestramento non lo è: non risiede in un record specifico, ma è distribuita nei pesi del modello. Si può verificare che il modello non la riproduca a determinate richieste, ma esistono tecniche note per farla emergere con richieste diverse. La cancellazione elimina i log, non ciò che il modello ha appreso.
Il diritto alla cancellazione incontra quindi un limite che dipende dall’architettura del sistema, non dalla volontà del fornitore. Secondo il Comitato europeo per la protezione dei dati (parere 28/2024), un modello addestrato su dati personali non è anonimo per definizione: se i dati sono estraibili, il GDPR continua ad applicarsi.
Il GDPR riguarda anche l’azienda utilizzatrice, che è titolare del trattamento dei dati di clienti e dipendenti. Il fornitore agisce di norma come responsabile, sulla base del DPA, e diventa titolare se usa quei dati per addestrare i propri modelli. In assenza di dati personali il GDPR non si applica, ma restano le tutele del segreto industriale.
La responsabilità dell’output non si trasferisce allo strumento. Se una proposta inviata a un cliente contiene un dato inventato, o un dato riservato di un altro cliente, non ne risponde il produttore del modello, ma chi l’ha inviata o l’azienda per cui lavora. Lo stesso vale per un output diffamatorio o discriminatorio: la responsabilità ricade su chi lo pubblica o lo commissiona. Il quadro è però in evoluzione: per i prodotti immessi sul mercato dopo il 9 dicembre 2026, termine di recepimento negli Stati membri, la nuova direttiva europea sulla responsabilità da prodotto (2024/2853) include software e sistemi di AI tra i prodotti, con responsabilità oggettiva del produttore per i danni alle persone fisiche.
La normativa europea fissa i principi, ma da sola non basta: va integrata con linee guida aziendali che stabiliscano quali strumenti utilizzare e con quali dati. Per iniziare non è necessaria una policy estesa. Il cloud consumer è adeguato per bozze, riscritture, brainstorming e automazioni semplici, non per dati personali o segreti industriali. Per documenti riservati servono una versione Enterprise, preferibilmente con data residency UE, oppure una soluzione self-hosted.
Prima di inserire un dato, cinque verifiche:
L’ultima domanda è sufficiente, da sola, a risolvere la maggior parte dei casi. Il nome di un lead e l’oggetto di una mail non sono equivalenti all’export completo del CRM con dieci anni di trattative: trattarli allo stesso modo, in senso restrittivo o permissivo, è l’errore principale.
L’AI generativa non è né pericolosa né innocua. È una tecnologia con un funzionamento preciso, e quel funzionamento determina quali dati è opportuno affidarle.
Alan Perotti
