Retention obbligatoria a 30 giorni sui modelli di frontiera: il nodo GDPR per le PMI

Immagina di aver configurato con cura la zero data retention sul tuo fornitore di AI, perché il tuo consulente GDPR ti aveva detto che era la garanzia giusta: i prompt che mandi al modello non vengono conservati, e questo ti permetteva di dormire sonni tranquilli anche quando in quei prompt finivano dati di clienti. Poi arriva il modello nuovo, quello più capace, e scopri che per usarlo devi accettare una retention obbligatoria di 30 giorni su prompt e output, che scavalca il tuo accordo di non conservazione. È esattamente quello che è successo con i modelli Mythos-class di Anthropic: dal 9 giugno 2026 una policy di retention a 30 giorni si applica a tutto il traffico verso questi modelli, e vale anche per le organizzazioni che avevano la zero data retention su Claude Console, su Claude Code Enterprise e perfino sui marketplace cloud di terze parti come AWS Bedrock, Google Cloud Agent Platform e Microsoft Foundry. Il controllo su cui contavi, per il modello migliore, non c'è più. Per una PMI italiana che processa dati personali sotto GDPR non è un dettaglio contrattuale: è un cambiamento del perimetro di rischio, e va affrontato con la testa del responsabile della protezione dei dati, non con quella dell'early adopter.

Cosa è cambiato esattamente, e perché conta

Mettiamo i fatti in ordine, perché su questo tema il rumore supera il segnale. La policy non dice che i tuoi dati vengono usati per addestrare il modello: non lo sono. Dice che prompt e output vengono conservati per 30 giorni per finalità di trust and safety, con accesso umano tracciato in modo a prova di manomissione e cancellazione dopo il periodo, salvo indagini o obblighi legali. La novità che pesa non è la conservazione in sé, è che si applica anche a chi aveva esplicitamente disattivato la conservazione per ragioni di compliance. La zero data retention era una leva contrattuale che molti consulenti, me incluso, raccomandavano come misura tecnica e organizzativa; per la classe di modelli più capace quella leva è stata subordinata alla policy di sicurezza del fornitore.

La lezione architetturale è netta: una garanzia contrattuale come la zero data retention vale finché il fornitore decide che vale. Se la tua compliance poggia su una clausola che il vendor può sospendere per accedere al suo modello migliore, la tua compliance ha una dipendenza che non controlli.

Va detto con onestà, ed è una dichiarazione che faccio sempre: io stesso uso modelli di frontiera nella mia pipeline di lavoro. Il punto di questo articolo non è demonizzare un fornitore, è leggere un fatto e trarne le conseguenze per chi ha obblighi normativi. La stessa dinamica può ripresentarsi con qualunque vendor, perché nasce dalla pressione regolatoria e di sicurezza sull'intero settore, non dalla cattiveria di uno.

Dove transitano davvero i tuoi dati, e perché la sovranità c'entra

Per ragionare da GDPR bisogna sempre rispondere a una domanda concreta: dove vanno fisicamente e giuridicamente i dati che mando al modello? Con la retention a 30 giorni, prompt e output vivono per quel periodo sull'infrastruttura del fornitore, che per i frontier model statunitensi significa, nella maggior parte dei casi, una giurisdizione extra-UE. Anche quando il routing tecnico passa per una region europea di un marketplace cloud, la casa madre resta soggetta a normative come il CLOUD Act, che possono imporre l'accesso ai dati indipendentemente da dove sono ospitati. Per un'azienda del settore servizi digitali con cui ho lavorato sull'adeguamento, questo è il punto che cambia la conversazione: non basta chiedersi "il dato è cifrato?", bisogna chiedersi "sotto quale legge cade chi può essere costretto a consegnarlo?".

La sovranità del dato, in questo quadro, smette di essere uno slogan e diventa un requisito di progettazione. Se un dato personale, per i suoi 30 giorni di conservazione, è raggiungibile da un'autorità di un paese terzo, devi poterlo giustificare nel tuo registro dei trattamenti e nella tua valutazione dei rischi, oppure devi evitare che ci finisca.

Se la tua azienda integra strumenti AI e ti stai accorgendo che la mappa dei trattamenti non è più allineata a come funzionano davvero, nel mio profilo professionale trovi l'esperienza concreta su compliance GDPR e NIS2 applicata a infrastrutture e applicazioni reali, non su modelli teorici.

Il nodo GDPR per una PMI che integra l'AI via API

Nel quadro dell'AI Act, una PMI che usa un modello via API è quasi sempre un deployer, non un provider, e i suoi obblighi correnti, secondo il Regolamento (UE) 2024/1689, sono l'alfabetizzazione AI, la trasparenza dell'articolo 50 verso gli utenti e, soprattutto, il GDPR. È qui che si gioca la partita. Mandare dati personali a un modello con retention significa che devi avere una base giuridica valida per quel trattamento (articolo 6), un accordo come responsabile del trattamento con il fornitore (articolo 28) che ora deve riflettere la conservazione a 30 giorni, e una valutazione d'impatto (articolo 35) quando il trattamento è su larga scala o tocca categorie particolari di dati. Il principio di minimizzazione diventa la difesa più pratica: se non mandi al modello il dato personale, la retention non è un tuo problema.

C'è poi un fattore che amplifica il rischio e che pochi mettono nel conto: la Shadow AI. La ricerca dell'Osservatorio Artificial Intelligence del Politecnico di Milano, presentata il 5 febbraio 2026, rileva che solo il 19% di chi usa strumenti AI in azienda dichiara di utilizzare esclusivamente strumenti forniti dall'organizzazione. Tradotto: nella maggior parte delle aziende i dipendenti incollano testi nei modelli pubblici con account personali, fuori da qualunque accordo aziendale e da qualunque configurazione di retention. Se a questo aggiungi che il modello migliore ora conserva comunque per 30 giorni, capisci che il problema non è solo contrattuale, è di governo dell'uso reale: puoi avere il DPA più curato del mondo, ma se i tuoi dipendenti usano l'AI per conto loro la retention te la ritrovi senza nemmeno saperlo. La prima misura, prima ancora della tecnica, è una policy d'uso chiara e una formazione che spieghi cosa si può e cosa non si può mandare a un modello.

Il contesto italiano rende la cosa concreta e attuale. Il Garante ha inserito l'AI tra le priorità del suo piano ispettivo 2026, e con il provvedimento n. 342 del 14 maggio 2026 ha già bloccato un sistema di monitoraggio dei lavoratori basato su AI, segno che l'attenzione dell'autorità sul tema non è teorica. Per chi vuole inquadrare le scadenze normative, ho raccolto il quadro nel pezzo sull'AI Act e la scadenza del 2 agosto 2026 per le PMI italiane, tenendo presente che dal 2 agosto 2026 scattano l'enforcement della Commissione sui provider GPAI e gli obblighi di trasparenza, mentre i tier high-risk seguono un binario separato. Il rischio di non compliance, su questi temi, l'ho già messo in fila parlando dei rischi concreti della non conformità a GDPR e NIS2.

Cosa documentare, in pratica, quando usi un modello con retention

La teoria diventa utile solo quando si traduce in carta che regge a un controllo. Concretamente, se la tua azienda manda dati personali a un modello con retention a 30 giorni, ci sono alcune cose che devono comparire nei tuoi documenti. Nel registro dei trattamenti va censito il trattamento "elaborazione tramite modello AI", con indicata la conservazione temporanea di 30 giorni e il fornitore come responsabile esterno. L'accordo come responsabile del trattamento (l'articolo 28) con il fornitore va riletto e, se necessario, aggiornato, perché la nuova retention modifica la durata della conservazione che il responsabile applica: un DPA che dichiara "nessuna conservazione" mentre la policy reale ne impone trenta giorni è una contraddizione che un ispettore nota subito.

Se il fornitore è extra-UE, serve un meccanismo di trasferimento valido, tipicamente le clausole contrattuali standard, accompagnato da una valutazione del rischio del trasferimento che tenga conto della giurisdizione del fornitore. E quando il trattamento è su larga scala o tocca categorie particolari di dati, la valutazione d'impatto (l'articolo 35) non è opzionale: va fatta prima, non dopo il primo incidente. Nessuno di questi documenti è esotico, sono il pane quotidiano della compliance GDPR; la novità è solo che ora devono includere correttamente una caratteristica del trattamento, la retention, che molti davano per disattivata. La mia esperienza è che la maggior parte delle PMI non ha questi documenti allineati a come usa davvero l'AI, e il gap tra l'uso reale e la carta è esattamente ciò che un controllo fa emergere.

C'è poi un intreccio che in Italia conta e che il marketing dei fornitori non racconta: per i soggetti rientranti in NIS2, la gestione dei fornitori e della catena di approvvigionamento del software è un obbligo, e un modello AI con retention è a tutti gli effetti un fornitore nella tua catena. L'autunno 2026 concentra due scadenze, l'enforcement sui provider GPAI dell'AI Act e le misure di base NIS2 entro fine ottobre, con la stessa autorità nazionale nel doppio ruolo: chi tratta l'adozione dell'AI come una scelta solo tecnologica, e non anche di governance del fornitore, si troverà a inseguire entrambe le scadenze nel momento peggiore.

Un accordo di zero data retention protegge ancora i dati che mando a un'AI?

La risposta onesta, dal 2026, è: non in modo assoluto, e non se vuoi il modello migliore. La zero data retention resta valida dove il fornitore la offre senza eccezioni, ma per le classi di modelli soggette a policy di sicurezza rafforzata può essere sospesa, e il caso Mythos-class lo dimostra. La conseguenza operativa è che non puoi più trattare la zero data retention come un controllo permanente: devi assumere, nella tua analisi dei rischi, che ciò che mandi a un frontier model possa essere conservato, e governare il trattamento di conseguenza. È un cambio di postura: dal "il fornitore non conserva, quindi sono a posto" al "io non mando ciò che non voglio sia conservato".

Questo non significa rinunciare all'AI, significa progettare il flusso dei dati perché il dato sensibile non incontri mai il modello con retention. Pseudonimizzazione, redazione dei dati personali prima dell'invio, separazione tra il contesto che serve al modello e l'identità del soggetto: sono le stesse tecniche che applico quando lavoro sulla protezione dei dati in un'applicazione, e che ho descritto parlando di pseudonimizzazione dei dati in Laravel e Symfony.

Le alternative concrete, in ordine di praticità

La buona notizia è che le alternative esistono e non sono drastiche. La prima, e la più semplice, è la minimizzazione spinta: per la maggior parte dei casi d'uso aziendali il modello non ha bisogno del nome, del codice fiscale o dei recapiti del cliente per fare il suo lavoro, e togliere quei campi prima dell'invio risolve gran parte del problema a costo quasi zero. La seconda è il model tiering: usare il frontier model con retention solo sui dati non sensibili, e tenere i dati personali su un modello a residenza europea o su inference self-hostata. Su questo asse i provider con datacenter in UE o in Italia (Aruba, OVHcloud con la sua region di Milano, o un fornitore italiano gestito) offrono garanzie di giurisdizione che un frontier model statunitense non dà, e l'inference su una GPU europea a pesi aperti elimina del tutto il transito verso terzi. La terza è documentare e accettare consapevolmente il rischio dove il beneficio lo giustifica e i dati non sono critici, mettendolo nero su bianco nel registro dei trattamenti invece di ignorarlo: un rischio accettato e documentato è una posizione difendibile davanti a un'autorità, un rischio ignorato non lo è mai.

Tirando le somme, la retention obbligatoria sui modelli di frontiera non è la fine dell'AI in azienda, è la fine dell'AI in azienda senza governance del dato. Il messaggio che porto a un titolare di PMI è sobrio: il modello più capace è anche quello con i vincoli più stringenti sul dato, e pretendere insieme la massima capacità e la massima riservatezza, gratis, non è realistico. La scelta matura è architetturale, decidere quali dati possono incontrare quale modello, minimizzare ciò che esce dal perimetro, e tenere una via europea o self-hostata per ciò che non può uscirne. È lo stesso lavoro di disaccoppiamento che facciamo da sempre con database e infrastrutture, spostato sul layer dei dati che mandiamo agli LLM. Se la tua azienda sta integrando l'AI e vuoi essere sicuro che la mappa dei trattamenti regga a un controllo del Garante, contattami per una consulenza diretta: di solito tra una diagnosi onesta e un piano applicabile passano giorni, non mesi.