Il 19 agosto 2026 OpenAI ha fatto una cosa insolita: invece di annunciare un modello, ha annunciato una promessa sui dati. L’azienda ha confermato che continuerà a offrire lo zero data retention di OpenAI per le aziende anche sui modelli di frontiera, e ha presentato in anteprima Private Safety Processing, un sistema pensato per individuare abusi su più conversazioni collegate senza che nessuno in OpenAI legga il contenuto. La tempistica non è casuale: arriva poco più di due mesi dopo che Anthropic ha imposto trenta giorni di conservazione obbligatoria sui suoi modelli più capaci, azzerando gli accordi di non-ritenzione già firmati. Per chi in Italia sta valutando un rollout in farmaceutico, legale o finanza, è il momento in cui la scelta smette di essere teorica.
In questo articolo scoprirai:
- Cosa ha annunciato OpenAI e perché la mossa arriva proprio adesso
- Come funziona Private Safety Processing senza leggere i tuoi prompt
- Zero data retention: cosa copre davvero e cosa resta fuori
- Cosa cambia per farmaceutico, legale e finance in Italia
- Come scegliere il regime di ritenzione prima del rollout, invece di ereditarlo
Cosa ha annunciato OpenAI e perché la mossa arriva proprio adesso
L’annuncio ufficiale di OpenAI si regge su due gambe. La prima è una riconferma: lo ZDR resta disponibile anche sui frontier model, per i clienti enterprise e API idonei, non per chi usa i piani ChatGPT a pagamento in versione consumer. La seconda è la novità vera: Private Safety Processing, in preview, con white paper tecnico e rollout più ampio previsti per settembre 2026.
Zero data retention di OpenAI e la svolta di Anthropic sui Covered Models
Il contesto competitivo spiega il tempismo meglio di qualsiasi comunicato. Dal 9 giugno 2026 Anthropic conserva per trenta giorni prompt e output dei cosiddetti Covered Models, la classe Mythos e i modelli futuri con capacità simili, su ogni piattaforma in cui vengono offerti: workspace ZDR nella Console, Claude Code in Enterprise, AWS Bedrock, Google Cloud Agent Platform, Microsoft Azure Foundry. Anthropic circonda la conservazione di garanzie serie (nessun dipendente legge per default, accesso solo tramite un percorso controllato, log a prova di manomissione), ma il punto per un ufficio legale è un altro: i contratti di non-ritenzione già firmati non reggono più su quei modelli.
OpenAI ha scelto la strada opposta e lo ha detto esplicitamente, come hanno ricostruito TechCrunch e Axios, che legge la preview come il rovescio speculare della scelta di Anthropic: invece di chiedere i log per fare sicurezza, prova a fare sicurezza senza chiedere i log. È una scommessa architetturale, e vale la pena capire come funziona prima di trattarla come un argomento di vendita.
Come funziona Private Safety Processing senza leggere i tuoi prompt
Il problema che il sistema prova a risolvere è reale e nasce dagli agenti AI. Un modello che risponde a una domanda isolata si può controllare guardando quella singola domanda. Un agente che lavora per ore su un compito lungo, con decine di chiamate collegate, no: il segnale di abuso non sta nella singola richiesta, sta nella sequenza. TechCrunch riporta l’esempio usato da OpenAI: chi vuole farsi assemblare del malware distribuisce le richieste su più sessioni proprio per non essere intercettato. Ma se il fornitore non conserva nulla, non ha modo di vedere il disegno complessivo.
Private Safety Processing rompe questo dilemma spostando l’analisi. Sono sistemi automatizzati, non revisori umani, a valutare input e output di più conversazioni collegate. Quando individuano un pattern rilevante, non inviano a OpenAI il contenuto: inviano un narrowly defined signal, un segnale ristretto che indica il tipo di attività sospetta. Solo a quel punto OpenAI decide se serve un intervento e, se serve, contatta il cliente per avere contesto, ed è il cliente a scegliere, a propria discrezione, se condividere i dati.
Le due opzioni di deployment di Private Safety Processing
Le opzioni di deployment sono due, ed è qui che si gioca la credibilità della promessa. I dati possono restare sull’infrastruttura controllata dal cliente, oppure essere conservati da OpenAI ma cifrati con chiavi crittografiche in mano al cliente. Nel secondo caso la garanzia non è contrattuale, è matematica: senza la chiave, il testo non è leggibile nemmeno da chi ospita i byte. È la stessa logica del BYOK che i responsabili IT conoscono già dal cloud tradizionale, applicata all’inferenza. Il white paper di settembre dirà quanto tiene nei dettagli; oggi è una preview, e va trattata come tale.
Zero data retention: cosa copre davvero e cosa resta fuori
Qui serve precisione, perché la maggior parte degli equivoci nasce da un’aspettativa più larga di quello che il contratto dice. La documentazione ufficiale di OpenAI sui data control è esplicita: senza ZDR i log di abuse monitoring vivono fino a 30 giorni; con ZDR il contenuto del cliente ne viene escluso e il parametro store passa a false di default sulla Responses API.
Attenzione a non confondere due controlli distinti: dal 1° marzo 2023 i dati inviati via API non vengono usati per addestrare i modelli a meno di opt-in esplicito. Quello vale già per tutti. Lo ZDR è un’altra cosa: riguarda la conservazione, non l’addestramento. Chi chiede lo ZDR pensando di ottenere il no-training sta chiedendo qualcosa che ha già.
Gli endpoint esclusi dallo zero data retention
La copertura è per endpoint, non per account, e la documentazione ufficiale di OpenAI elenca il perimetro voce per voce. Rientrano chat completions, responses, embeddings, immagini, audio e moderations. Restano fuori Assistants, thread, vector store, conversazioni, fine-tuning e gestione file: se la vostra architettura poggia su quelli, lo ZDR non vi protegge dove pensate. Restano fuori anche le immagini e i file scansionati per contenuti CSAM, conservati per revisione manuale a prescindere. E il prompt caching mantiene tensori cifrati su GPU fino a 24 ore. Un dettaglio decisivo per l’Italia: le regioni non statunitensi richiedono un emendamento di Modified Retention oltre ai controlli approvati. Infine, l’accesso non è self-serve: serve approvazione preventiva di OpenAI, e come nota l’analisi di Teleskope, «la maggior parte delle organizzazioni non supera mai la soglia di approvazione», restando sulla finestra di ritenzione di default.
Cosa cambia per farmaceutico, legale e finance in Italia
I numeri italiani dicono che il problema non è l’adozione, è il governo dell’adozione. Secondo l’Osservatorio Artificial Intelligence del Politecnico di Milano, il mercato AI in Italia vale 1,8 miliardi di euro con una crescita del +50%, l’84% delle grandi imprese ha licenze di AI generativa, ma solo il 9% ha una governance strutturata dell’AI. È in quella forbice che si annidano le decisioni sui dati prese per omissione.
Zero data retention e conformità: cosa il contratto non copre
Per i settori regolamentati il punto pratico è che lo ZDR non è un lasciapassare di conformità. La guida di CASRAI lo mette in tabella senza sconti: per i dati sanitari serve comunque un Business Associate Agreement, documento separato e indipendente dallo stato ZDR; per i dati federali statunitensi serve un ambiente FedRAMP, che l’API diretta di OpenAI non è. Traducendo in categorie europee: lo ZDR incide sul principio di limitazione della conservazione dell’art. 5 GDPR, ma non sostituisce il DPA, l’analisi dei rischi né gli obblighi che l’AI Act impone ai sistemi ad alto rischio. Chi vuole il quadro completo lo trova nella nostra guida su sicurezza, GDPR e adozione conforme dell’AI.
C’è poi il rischio che nessuna policy di ritenzione copre: quello che entra nel prompt. La ritenzione governa cosa succede dopo che il dato è arrivato al fornitore, non impedisce che ci arrivi. Per questo un’architettura seria affianca ai controlli contrattuali quelli a monte, classificazione e redazione dei dati sensibili, e difese contro la prompt injection, che sugli agenti autonomi resta il vettore più sottovalutato. Vale anche per i server MCP e i servizi di terze parti collegati: operano sotto le loro policy di ritenzione, non sotto la vostra.
Come scegliere il regime di ritenzione prima del rollout, invece di ereditarlo
Lo studio comparativo di Gupta e Shrivastava su Zero Data Retention negli assistenti AI enterprise (arXiv, ottobre 2025) arriva a una conclusione che il confronto OpenAI, Anthropic di questi mesi conferma: lo ZDR non è uno standard universale ma un’implementazione specifica per fornitore, con variazioni reali di ambito e applicazione. Non esiste «il regime giusto»: esiste il regime giusto per i vostri dati, i vostri endpoint e il vostro settore.
Cinque verifiche sullo zero data retention prima di firmare
- Classificare i dati che entreranno nei prompt, per livello di sensibilità.
- Mappare quali endpoint userete davvero e controllare che siano tra quelli idonei.
- Distinguere per iscritto no-training e non-ritenzione, che sono due clausole diverse.
- Prevedere l’emendamento richiesto per le regioni non statunitensi e, per i dati sanitari, l’accordo dedicato.
- La lezione della vicenda Anthropic: inserire una clausola su cosa succede se il fornitore cambia policy sui modelli nuovi, perché quel cambio è già avvenuto una volta nel 2026.
È esattamente il lavoro che facciamo nell’onboarding dedicato di MIMIR: prima di accendere un agente si decide il regime di ritenzione, endpoint per endpoint, invece di ereditare il default del fornitore e scoprirlo dopo. Se avete un’esigenza aziendale su AI e agenti in un settore regolamentato, parlatene con noi: oltre al prodotto offriamo l’assistenza per configurarlo sui vostri vincoli reali.
Fonti:
- OpenAI — Offering zero data retention for frontier models
- OpenAI — Documentazione ufficiale sui data control dell’API
- TechCrunch — OpenAI seeks to one-up Anthropic with new customer privacy protections
- Axios — OpenAI previews zero-retention safety system as Anthropic requires data logs
- Anthropic — Data retention practices for Covered Models
- Gupta, Shrivastava — Zero Data Retention negli assistenti AI enterprise (arXiv, ottobre 2025)
- CASRAI — Guida allo zero data retention negli strumenti AI per la ricerca
- Teleskope — Analisi sulle soglie di approvazione dello zero data retention
- Osservatorio Artificial Intelligence, Politecnico di Milano — Il mercato AI in Italia
Domande frequenti
Che cos'è il zero data retention di OpenAI e chi può ottenerlo?
È un regime contrattuale per cui OpenAI non conserva il contenuto inviato dal cliente nei log di abuse monitoring, che senza ZDR vivono fino a 30 giorni. È riservato ai clienti enterprise e API idonei, non ai piani ChatGPT consumer a pagamento. L'accesso non è self-serve: serve un'approvazione preventiva di OpenAI, e le regioni non statunitensi richiedono anche un emendamento di Modified Retention.
Lo zero data retention impedisce a OpenAI di addestrare i modelli sui miei dati?
No, sono due controlli distinti. Dal 1° marzo 2023 i dati inviati via API non vengono usati per addestrare i modelli a meno di opt-in esplicito, e questo vale già per tutti i clienti API. Lo ZDR riguarda la conservazione, non l'addestramento: chi lo chiede pensando di ottenere il no-training sta chiedendo qualcosa che ha già.
Come fa Private Safety Processing a rilevare abusi senza leggere i prompt?
L'analisi di input e output su più conversazioni collegate è fatta da sistemi automatizzati, non da revisori umani. Quando individuano un pattern rilevante non trasmettono a OpenAI il contenuto ma un narrowly defined signal, cioè un segnale ristretto che indica il tipo di attività sospetta. I dati possono restare sull'infrastruttura del cliente o essere cifrati con chiavi che il cliente controlla. Il sistema è in preview, con white paper e rollout più ampio attesi per settembre 2026.
Lo zero data retention basta per essere conformi al GDPR?
No. Lo ZDR incide sul principio di limitazione della conservazione dell'art. 5 GDPR, ma non sostituisce il DPA, l'analisi dei rischi né gli obblighi che l'AI Act impone ai sistemi ad alto rischio. Per i dati sanitari serve comunque un accordo dedicato, indipendente dallo stato ZDR. E nessuna policy di ritenzione governa cosa entra nel prompt: quel rischio si affronta a monte, con classificazione dei dati e difese contro la prompt injection.



