Retention dati e ZDR negli LLM: chi può leggere i prompt
Indice
Il prompt non arriva semplicemente “all’azienda di AI”. In uno stack agentico attraversa una catena di soggetti che lo gestiscono in chiaro. Quali siano dipende dallo stack: la telemetria dell’agent framework, una piattaforma di tracing, un memory store, uno strumento di analytics, un AI gateway e uno dei tre tipi di inference provider. Ciascuno ha le proprie policy su retention, regione di storage e uso per il training. In genere, chi conserva più a lungo i prompt si trova dalla tua parte dell’API: i vendor dei modelli eliminano i log standard in circa 30 giorni, mentre tracing e memory store mantengono i dati finché non li elimini. La zero data retention (ZDR) è un accordo concreto e utile, ma vincola un solo soggetto e un solo asse dei tre in gioco. Questo articolo ricostruisce l’intera catena: chi conserva cosa, per quanto tempo e cosa copre davvero la ZDR.
TL;DR
- Ogni passaggio in chiaro può raccogliere dati. Il tracing lato agent e i memory store conservano i prompt molto più a lungo di qualsiasi model provider.
- La retention dei provider dipende dalla funzionalità: nella Claude API, il caching è compatibile con la ZDR, i batch job restano memorizzati per 29 giorni e Fable 5 richiede 30 giorni.
- La geografia segue il server: l’API ufficiale di DeepSeek archivia i dati nella RPC, senza alternative.
- Gli endpoint gratuiti sono il punto più critico: in genere, i diritti di training sono il prezzo della capacità gratuita.
- La ZDR ha retto in tribunale: l’ordine di conservazione del NYT esentava solo i clienti API con zero retention.
Chi può leggere il prompt in uno stack agentico?
Tutti i soggetti lungo il percorso, che è più lungo di quanto rappresentato nei diagrammi della maggior parte dei team:
Seguiamo il percorso da sinistra a destra. L’agent layer è tuo, ma raramente è composto solo da sistemi tuoi: i framework includono telemetria, le piattaforme di tracing e observability esistono proprio per archiviare prompt e risposte completi, le funzionalità di memoria scrivono le conversazioni in vector store che non scadono automaticamente e uno script di session replay nella UI web acquisisce il prompt mentre l’utente lo digita, prima ancora che raggiunga il backend. Il gateway coinvolge un solo soggetto se lo gestisci direttamente, due se è un SaaS. I gateway SaaS si dividono in due categorie. La prima è l’aggregatore multi-provider: una sola API instrada le richieste tra i provider integrati, quindi la gestione dei dati è sempre la somma di due policy, quella del gateway e quella dell’host che ha elaborato la singola richiesta. La seconda categoria è offerta dai vendor di sicurezza: gateway DLP (data loss prevention) e guardrail il cui prodotto consiste nell’ispezionare i payload, oscurare dati e applicare policy. Leggere ogni prompt è quindi parte della funzionalità e, per progettazione, i prompt segnalati vengono normalmente conservati come eventi di sicurezza.
Dietro il gateway ci sono tre tipi di inference provider: l’API del vendor del modello, un cloud provider che ospita il modello nel tuo cloud tenant e GPU host che servono open weights applicando le proprie policy di logging. Il ramo diretto, con inferenza self-hosted su un tenant dedicato o sulle tue GPU, è l’unico percorso in cui nessuna terza parte gestisce dati in chiaro. Più avanti vedremo il limite di questa soluzione.
La regola alla base di tutto il resto è semplice: vedere e conservare sono due questioni distinte. Ogni componente può tecnicamente raccogliere dati. Che lo faccia davvero dipende da impostazioni predefinite, configurazione e contratti, con differenze enormi lungo la catena.
Chi conserva davvero i prompt?
Di solito è il tuo stesso tooling, e lo fa più a lungo di chiunque altro. Le finestre di retention dei provider su cui si concentrano i questionari di sicurezza durano giorni. Gli archivi lato agent, che nessuno include nei questionari, durano per sempre.
L’agent layer conserva i dati per progettazione. Il prodotto di una piattaforma di tracing è un database dei tuoi prompt e output. La retention è un’impostazione del progetto, non una conseguenza accidentale della policy. I default variano da uno strumento all’altro e vanno conosciuti: l’integrazione OpenTelemetry di GitHub Copilot esporta struttura degli span, timing e conteggio dei token, ma non il contenuto dei prompt, a meno che non ne abiliti esplicitamente l’acquisizione. È un’impostazione predefinita orientata alla privacy che altri strumenti agentici dovrebbero adottare. La modalità privacy di Cursor esiste perché la modalità predefinita condivide dati relativi al codice. Qualunque cosa il model provider elimini dopo 30 giorni, al giorno 300 è ancora presente nel tuo trace store.
Il gateway conserva ciò che decide di conservare. Non può evitare i dati di utilizzo, perché la fatturazione richiede conteggio dei token, modelli e timestamp per ogni richiesta. Può però evitare del tutto di archiviare i payload: i corpi di prompt e risposte possono transitare in memoria senza essere mai scritti su storage persistente. Due funzionalità comuni dei gateway superano però facilmente questo confine. Una console di ispezione delle richieste o observability archivia payload per definizione, esattamente come un tracing SaaS nel passaggio precedente. Anche il caching lato gateway memorizza il contenuto del prompt in quel punto della catena: una semantic cache conserva l’embedding del prompt e l’intera risposta in cache, mentre una response cache conserva entrambi i contenuti alla lettera, sul disco usato dal gateway. Quando valuti un gateway, SaaS o self-hosted, devi separare tre domande: cosa contiene il record della richiesta, cosa conserva la vista di observability e cosa scrive la cache?
La retention dei provider dipende dalla funzionalità, non dall’azienda. Il modello mentale più utile viene direttamente dalla documentazione Anthropic sulla retention delle API, che indica l’idoneità di ogni funzionalità: il prompt caching è compatibile con la ZDR perché lo stato della cache resta solo in memoria, il batch processing conserva i job per 29 giorni perché i job asincroni richiedono storage, i container di code execution restano fino a 30 giorni e i file caricati rimangono finché non li elimini. La pagina lo dice senza ambiguità: usare una funzionalità stateful “significa scegliere di uscire dall’accordo ZDR per quei dati specifici”. Per OpenAI, la documentazione sui controlli dei dati elenca gli endpoint compatibili con la ZDR, prevede per default fino a 30 giorni per i log di monitoraggio degli abusi e specifica che i prompt in cache vengono conservati come tensori chiave-valore cifrati sullo storage locale delle GPU, con TTL limitato. La cancellazione commerciale standard nella Claude API avviene entro 30 giorni.
Dove risiedono fisicamente i dati?
Sull’infrastruttura che esegue l’inferenza, con risposte diverse in base al tipo di provider. Un modello ospitato nel cloud offre le garanzie più solide: su Amazon Bedrock, il cloud provider è il responsabile del trattamento e l’inferenza resta nella regione selezionata. Per questo gli acquirenti soggetti a vincoli normativi scelgono prima questa opzione. L’API diretta di un model vendor opera nelle regioni in cui opera il vendor: OpenAI offre elaborazione regionale negli Stati Uniti e nell’UE per la maggior parte degli endpoint, mentre i vendor più piccoli spesso non pubblicano nulla. Il caso più netto è DeepSeek, la cui privacy policy dichiara che i dati personali vengono raccolti, elaborati e archiviati nella Repubblica Popolare Cinese, senza opzioni negli Stati Uniti o nell’UE per l’API ufficiale. Gli stessi open weights serviti da un GPU host statunitense non hanno questa collocazione geografica. È la dimostrazione più chiara che la destinazione dei dati dipende da chi serve il modello, non dal modello stesso.
Oltre alla copia primaria ci sono altri due livelli. Cache e file batch restano nella regione di serving per la rispettiva durata, indipendentemente dal log delle richieste. Ogni provider si appoggia inoltre a sub-responsabili, cioè ai propri fornitori downstream, e a sistemi di backup. Gli impegni di cancellazione sono generalmente formulati come eliminazione dai sistemi attivi, seguita da tempi ulteriori per la propagazione ai backup. Se il diagramma del flusso dati termina sul logo del vendor dell’API, mancano almeno questi due elementi.
Chi impone la retention e chi usa i prompt per il training?
Tre forze diverse mantengono i dati oltre i tempi predefiniti. Solo una compare nel marketing del provider.
Requisiti di policy. Alcuni modelli impongono la retention come condizione di sicurezza. Claude Fable 5 e Mythos 5 richiedono 30 giorni di retention anche per i clienti ZDR. L’applicazione del requisito è esplicita: una richiesta proveniente da un’organizzazione con una configurazione di retention non conforme viene rifiutata con un errore 400, anziché essere accettata silenziosamente. Un’altra eccezione riguarda l’escalation per abusi: i contenuti segnalati per violazioni delle usage policy seguono tempi di conservazione completamente diversi. La policy consumer di Anthropic indica fino a 2 anni per input e output segnalati e fino a 7 anni per i punteggi dei classificatori.
Legal hold. La causa NYT v. OpenAI ha fornito il caso più chiaro per verificare gli impegni sulla retention. Un ordine di conservazione del maggio 2025 imponeva a OpenAI di preservare log degli output che altrimenti avrebbe eliminato, comprese le chat cancellate dagli utenti, per tutti i tier consumer. L’ordine è stato ridimensionato nel settembre successivo e in seguito un tribunale ha ordinato la produzione di 20 milioni di log delle chat durante la discovery. Per chi acquista API, il dettaglio rilevante è l’esclusione dei clienti enterprise e zero data retention, perché non esistevano dati conservati da preservare. Una policy di cancellazione può essere sospesa da un litigation hold. Un’architettura che non ha mai archiviato i dati, invece, non può esserlo.
Intermediari che raccolgono dati. Nella parte centrale della catena esistono casi documentati di monetizzazione dei dati in chiaro. Il più rilevante riguardava il componente più vicino all’utente. Nel dicembre 2025, alcuni ricercatori di sicurezza hanno documentato che un’estensione browser VPN presentata come strumento di “privacy”, con milioni di installazioni, iniettava script nelle pagine delle chat AI. Intercettava ogni prompt e risposta su ChatGPT, Claude, Gemini e altri cinque assistenti, quindi inviava le conversazioni a una società affiliata che operava come data broker. La raccolta avveniva anche quando la VPN era disattivata e interessava circa 8 milioni di utenti delle estensioni dello stesso publisher. In questo caso l’intermediario agiva lato client e non era un API gateway, ma la conclusione vale per ogni componente del diagramma: qualunque intermediario che gestisca dati in chiaro può raccoglierli, il suo incentivo può essere monetizzarli e l’intercettazione resta invisibile a entrambe le estremità. Fidarsi di un intermediario significa fidarsi del suo modello di business, non dell’elenco delle sue funzionalità.
Clausole di training. Per default, le API business dei principali vendor non usano i dati dei clienti per il training. I prodotti consumer lo fanno sempre più spesso, a meno che l’utente non effettui l’opt-out. Anche per questo il traffico degli agent dovrebbe usare API key e non account consumer. Un numero crescente di prodotti affida il consenso al training a un’impostazione che l’utente deve trovare da solo: piani consumer con training attivo per default e opt-out nascosto nelle impostazioni, developer tool in cui l’opzione di telemetria o condivisione del codice vale anche come consenso al training, programmi dei vendor che offrono sconti o quota gratuita in cambio dell’opt-in alla condivisione dei dati e dashboard degli aggregatori con switch distinti per il training nei tier a pagamento e gratuiti. Ogni impostazione vale per account, a volte per workspace, e il default può cambiare con un aggiornamento dei termini. Non basta aver controllato una volta: verificare periodicamente questi switch deve rientrare nella stessa checklist della rotazione delle chiavi.
Modelli gratuiti, trattati a parte per un motivo. Tutti i rischi descritti si concentrano in un solo punto: il tier gratuito. Il lancio di un modello gratuito è solitamente sovvenzionato dal soggetto che trae vantaggio dal traffico, nella maggior parte dei casi il vendor del modello. I prompt inviati alla variante gratuita arrivano quindi a quel soggetto e ricadono sotto la sua policy. Spesso l’accordo include i diritti di training e i dati vengono elaborati nelle regioni in cui opera il vendor, che per i vendor cinesi significa la Cina. Gli aggregator gateway pubblicano policy sui dati per ciascun endpoint e offrono uno switch per escludere i provider che usano i dati per il training proprio perché queste clausole sono frequenti nelle route gratuite. La regola pratica è netta: considera un endpoint gratuito come un invio di dati, non come una chiamata API. L’inferenza gratuita ha comunque un costo, e di solito viene pagato con i prompt.
Cosa significa davvero ZDR?
La ZDR vincola un solo asse su tre, per un solo soggetto della catena e soltanto per le funzionalità idonee. Non è un limite della ZDR, è la sua definizione. Conoscerne i confini permette di usarla correttamente.
- I tre assi. Uso per il training, durata della retention e accesso umano sono indipendenti. Le API business già non usano i dati per il training. La ZDR azzera la retention dei payload. L’accesso umano è regolato separatamente dalle procedure per gli abusi. Confondere questi aspetti porta a presentare la ZDR come qualcosa di più ampio di ciò che è.
- Cosa resta con la ZDR. Metadati di utilizzo e record di fatturazione, output dei classificatori di sicurezza e stato delle funzionalità stateful a cui aderisci. Entrambi i principali vendor gestiscono ormai l’eccezione del monitoraggio degli abusi senza conservare i payload: da una parte segnali di sicurezza privi di payload, dall’altra retention limitata ai risultati dei classificatori.
- Cosa non copre la ZDR. Tutto ciò che precede il provider: trace store, log del gateway e memoria vettoriale. Un accordo ZDR con un model vendor, mentre un tracing SaaS conserva indefinitamente ogni prompt, è la configurazione di retention più comune che osserviamo, nonché la meno coerente.
- Il limite del self-hosting. Eseguire open weights sulle proprie GPU elimina tutte le terze parti, ma trasferisce il problema all’infrastruttura interna: log delle richieste dell’inference server, access log e file di trace. Il self-hosting sposta la superficie di retention. Solo una gestione deliberata dei log può ridurla.
Come lo gestisce Synthorai
Il passaggio sul gateway è sotto la nostra responsabilità, quindi gli impegni sono precisi. In modalità zero retention, i corpi di richieste e risposte transitano in memoria e non vengono scritti su storage persistente. Rimane soltanto il record di utilizzo necessario alla fatturazione: timestamp, modello, conteggio dei token e un hash del contenuto che permette di collegare una richiesta in caso di contestazione senza conservare ciò che è stato scritto. A monte, i provider vengono filtrati prima ancora del routing: Synthorai accetta solo provider che si impegnano ad applicare la zero data retention al nostro traffico, con una sola eccezione documentata, Claude Fable 5. La sua retention di 30 giorni è imposta dal vendor del modello e non può essere eliminata contrattualmente. Scegliere il provider significa scegliere la retention. Il gateway deve rendere esplicita questa proprietà per ogni route, invece di nasconderla in una policy PDF: una route Fable 5 include il requisito di retention nei metadati documentati, senza sorprese.
FAQ
Per default, i provider di LLM usano i dati API per il training?
No. Per default, le API business dei principali vendor non usano i dati dei clienti per il training. Questo impegno compare nella documentazione sui controlli dei dati di ogni provider. Le eccezioni si concentrano nella coda lunga: prodotti consumer con opt-out anziché opt-in, alcuni GPU host che servono open weights ed endpoint gratuiti in cui i diritti di training fanno parte del prezzo.
ZDR significa che il provider non archivia assolutamente nulla?
No. ZDR significa che i payload di prompt e risposte non vengono conservati per le funzionalità idonee. Metadati di utilizzo, record di fatturazione e output dei classificatori di sicurezza restano archiviati. Funzionalità stateful come batch job o upload di file memorizzano dati per loro natura e ricadono fuori dal perimetro della ZDR. Va letta la tabella di idoneità delle funzionalità, non il titolo.
È sicuro inviare dati di produzione a modelli gratuiti?
Considera un endpoint gratuito come un invio di dati, non come una chiamata API. La capacità gratuita è sovvenzionata dal soggetto che beneficia del traffico, i diritti di training fanno spesso parte dell’accordo e i dati vengono elaborati nelle regioni in cui opera tale soggetto. Per esperimenti usa e getta può essere uno scambio accettabile. Per dati dei clienti, codice o credenziali, raramente lo è.
Il self-hosting è automaticamente l’opzione più riservata?
Elimina tutte le terze parti dal percorso in chiaro, e questo è un vantaggio concreto. Non elimina la retention: inference server, reverse proxy e tracing generano log per default. Uno stack self-hosted con il logging predefinito può quindi conservare più dati dei prompt rispetto a un’API con accordo ZDR. La privacy dipende dalla configurazione del logging, non dal modello di hosting.
Fonti verificate il 2026-08-29: ogni affermazione sui provider rimanda alla documentazione del vendor o agli atti giudiziari originali. Le policy in questo ambito sono cambiate due volte nel mese precedente alla pubblicazione, quindi i link vanno considerati la fonte aggiornata. Questa è un’analisi tecnica, non una consulenza legale.
Articoli correlati: Il requisito di retention di 30 giorni di Fable 5, come funziona il prompt caching, confronto delle cache dei provider.