La retention di 30 giorni di Claude Fable 5: ZDR, HIPAA, COPPA

Se la tua organizzazione usa Claude sotto un accordo di zero data retention (ZDR), la prima richiesta a claude-fable-5 non ha restituito un completion. Ha restituito 400 invalid_request_error. Non è un disservizio, è una policy. Fable 5 è il primo modello Claude in disponibilità generale che non può essere usato senza retention dei dati di 30 giorni, e il requisito segue il modello su ogni piattaforma: la Claude API, AWS Bedrock, Google Vertex AI e Microsoft Foundry lo bloccano tutte dietro un opt-in esplicito alla retention.

Per i team che davano per scontato il “non conserviamo i tuoi dati” come una proprietà consolidata del loro stack LLM, questo è un evento architetturale. Questo post copre cosa dice la policy, perché esiste questa finestra, come ogni cloud la implementa e cosa cambia per i prodotti consumer e i settori che trattano dati sensibili.

TL;DR

• Claude Fable 5 non può essere utilizzato senza la conservazione per 30 giorni di prompt e completamenti; il requisito si applica su Claude API, AWS Bedrock, Google Vertex AI e Microsoft Foundry (policy in vigore dal 2026-06-09).
• Non è previsto alcun opt-out: le organizzazioni con accordi di zero-data-retention ricevono 400 invalid_request_error e i termini ZDR esistenti non vengono trasferiti.
• Su Bedrock, Fable 5 richiede data_retention_mode: provider_data_share; senza di esso il modello risulta non disponibile.
• I contenuti segnalati per violazioni della Usage Policy possono essere conservati fino a 2 anni, indipendentemente dalla finestra di 30 giorni.

I dettagli della policy sono stati verificati sulla documentazione pubblicata da Anthropic, AWS, Google e Microsoft in data 2026-06-12. Le policy cambiano; verifica sulle fonti primarie linkate e sui tuoi contratti. Questa è una panoramica ingegneristica, non un parere legale.

Cosa dice davvero la policy

Anthropic designa Claude Fable 5 e Claude Mythos 5 come Covered Models. Secondo la documentazione sulla retention dei dati API e l’articolo sulle pratiche di retention per i modelli Mythos-class (in vigore dal 2026-06-09):

• Prompt e completion sono conservati per 30 giorni, poi cancellati automaticamente, a meno che non vengano segnalati per un’indagine di sicurezza attiva o richiesti per legge.
• Non c’è opt-out. La retention è una condizione per usare il modello. Una richiesta da un’organizzazione la cui configurazione di retention non soddisfa il requisito restituisce 400 invalid_request_error.
• L’accesso è ristretto per design. Sistemi di sicurezza automatici filtrano i dati; solo un piccolo gruppo di persone autorizzate può esaminare le conversazioni segnalate, non può esportarle, copiarle o scaricarle, e ogni accesso finisce in log a prova di manomissione.
• Gli accordi ZDR esistenti non si applicano al traffico verso i Covered Model, nemmeno attraverso le piattaforme cloud.

I piani consumer (Claude Free/Pro/Max) non sono interessati: operano già sotto i propri termini di retention. Questa policy riguarda la superficie API commerciale, proprio dove vivono le promesse del tipo “non conserviamo mai nulla”.

Perché esiste una finestra di 30 giorni

Nell’articolo sui Covered Models la motivazione è precisa: questi modelli hanno capacità molto avanzate in ambito software engineering, workflow agentici e cybersecurity, e “alcune forme di abuso diventano rilevabili solo osservando molte richieste.” Gli esempi citati — jailbreaking best-of-N, spionaggio sponsorizzato da stati — sono pattern di attacco in cui ogni singolo prompt sembra innocuo e solo la sequenza rivela l’intento. Non puoi rilevare una sequenza che hai cancellato.

Due cose che la finestra non è:

• Non sono dati di training. Anthropic dichiara che i dati conservati non vengono mai usati per il training senza permesso esplicito. Lo scopo è la rilevazione degli abusi, punto.
• Non è una novità di tipo, ma di applicabilità. Una finestra di monitoraggio abusi di ~30 giorni è lo standard del settore da anni: OpenAI conserva i log di abuso delle API fino a 30 giorni (ZDR previa approvazione); Azure OpenAI conserva i prompt fino a 30 giorni salvo approvazione per il monitoraggio abusi modificato. La novità è che la finestra è diventata non negoziabile per una classe di modelli — prima ogni provider offriva una via d’uscita a retention zero.

Un dettaglio preesistente che sorprende: anche in modalità ZDR, Anthropic conserva i risultati dei classificatori di sicurezza, e i contenuti segnalati per violazioni della Usage Policy possono essere trattenuti fino a 2 anni. Zero data retention non ha mai significato zero dati — significa zero retention dei contenuti non segnalati nel percorso normale.

Stesso requisito, tre cloud, tre meccanismi

La retention si applica ovunque giri il modello, ma ogni piattaforma implementa l’opt-in in modo diverso — e sono queste differenze a decidere chi elabora i tuoi dati e dove risiedono i tuoi controlli.

AWS Bedrock è il più esplicito. La retention dei dati è una modalità configurabile (default / provider_data_share / none), risolta nell’ordine progetto → account → default del modello. Fable 5 dichiara allowed_modes: ["provider_data_share"]: prompt e completion vengono condivisi con Anthropic e conservati fino a 30 giorni. Con qualsiasi altra modalità:

{
  "id": "anthropic.claude-fable-5",
  "status": "unavailable",
  "status_reason": "This model is not available under data retention mode 'default'.",
  "data_retention": {
    "mode": "default",
    "source": "account",
    "allowed_modes": ["provider_data_share"]
  }
}

Per i modelli precedenti a Fable 5 non cambia nulla, e una SCP sulla condition key bedrock:DataRetentionMode può imporre la tua policy a livello di intera organizzazione — nessuno cambia di nascosto l’account per provare il nuovo modello. Nota: con l’inferenza cross-region la copia conservata risiede nella regione di destinazione, il che conta se hai vincoli di residenza dei dati.

Google Vertex AI blocca il modello dietro un’impostazione di data sharing Anthropic a livello di progetto (setPublisherModelConfig con dataSharingEnabledProvider: "anthropic") più l’accettazione dei termini in Model Garden, come da documentazione Google su Fable 5. La gestione generale dei dati segue la policy di data governance di Vertex AI; per i carichi sensibili alla residenza, gli endpoint regionali e multi-region di Vertex controllano dove gira l’inferenza — e ora questo include dove risiede la copia conservata.

Microsoft Foundry è strutturalmente diverso. La documentazione Microsoft su dati e privacy chiarisce che i modelli Claude sono servizi di marketplace di terze parti: accetti i termini Anthropic al momento del deployment e il data processor è Anthropic, non Microsoft. I programmi ZDR e di monitoraggio modificato degli abusi di Azure OpenAI non si estendono ai deployment di Claude. Le organizzazioni che applicano policy ZDR altrove di solito isolano l’uso dei Covered Model in una subscription dedicata, rendendo il confine della retention strutturale anziché procedurale.

Lo schema comune ai tre casi: la classe di retention è diventata un attributo del modello di prima classe e leggibile dalle macchine — una modalità, un flag, un gate sui termini — invece di un paragrafo in un contratto. Ora la tua infrastruttura può imporre la tua policy sui dati, e dovrebbe farlo.

Cosa significa per i deployment enterprise

Senza un accordo ZDR non cambia niente a livello meccanico: eri già in una postura tipo 30 giorni, forse senza saperlo. Il lavoro consiste nel renderlo esplicito nella documentazione dei tuoi fornitori.

Con un accordo ZDR hai tre opzioni:

1. Escludere i Covered Model. Lo ZDR resta uniforme, ma rinunci al modello. Praticabile se i tuoi workload non ne hanno bisogno: guarda la nostra valutazione misurata di Fable 5 per capire quanto costa e dove differisce.
2. Separare per workspace o progetto. Ogni piattaforma supporta un opt-in circoscritto: un workspace dedicato dell’API Claude (Console → Settings → Workspaces → Privacy controls), un progetto Bedrock con provider_data_share, un progetto Vertex separato o una subscription Azure a parte. Instrada lì solo i workload che tollerano la retention.
3. Accettare la retention a livello di intera organizzazione. È l’opzione più semplice da gestire, ma abbassa in silenzio la garanzia per tutti i workload, inclusi quelli la cui sensibilità giustificava lo ZDR. È una decisione che spetta al responsabile della protezione dei dati, non una modifica di configurazione.

A prescindere dal provider: il tuo logging è una seconda superficie di retention. Se il gateway o lo stack di observability logga i prompt completi, stai tenendo una finestra più lunga di quella del provider, e sotto il tuo tetto. Le garanzie del provider valgono solo quanto il layer che gli sta davanti: la stessa logica di audit che abbiamo applicato alle affermazioni sulla cache vale anche qui.

Cosa significa per i prodotti rivolti ai consumatori

Se servi consumatori e instradi i loro contenuti attraverso un Covered Model, il cambiamento si propaga alla tua superficie legale, che tu abbia un accordo ZDR o no. Tre conseguenze concrete:

1. La tua informativa sulla privacy va probabilmente aggiornata. La maggior parte degli ordinamenti impone di dichiarare la retention, non solo la raccolta: l’articolo 13(2)(a) del GDPR richiede il periodo di conservazione (o i criteri) al momento della raccolta; il CPRA californiano richiede che l’informativa al momento della raccolta indichi la retention per categoria di dati personali. Se la tua informativa dice — o lascia intendere — che i dati delle conversazioni non vengono conservati da nessuna parte, un responsabile del trattamento che ne detiene una copia per 30 giorni la rende falsa. Aggiorna l’informativa, il registro dei trattamenti e l’inventario dei DPA.

2. Non puoi offrire agli utenti un opt-out che non hai. La retention non prevede alcun meccanismo di eccezione, quindi non c’è nessun toggle che tu possa costruire per escludere i prompt di un utente continuando a usare quel modello. La leva che hai davvero in mano è il routing: un gateway consapevole del consenso manda gli utenti che rifiutano la condivisione dei dati verso modelli idonei allo ZDR e tutti gli altri verso il Covered Model. Un vincolo legale trasformato in una normale regola di routing. Molto meglio di una checkbox di preferenze che non fa niente.

3. Le richieste di cancellazione richiedono un’infrastruttura corretta. Gli obblighi di cancellazione (art. 17 GDPR, cancellazione CPRA e loro equivalenti) si estendono ai responsabili del trattamento. Una finestra limitata che cancella automaticamente entro 30 giorni è in genere una postura difendibile per un responsabile del trattamento, ma il tuo playbook per le DSAR deve dire proprio questo, non promettere una cancellazione a valle immediata che non puoi eseguire.

La dimensione globale complica ulteriormente le cose: la stessa logica di disclosure e responsabile del trattamento compare nel GDPR del Regno Unito, nell’LGPD brasiliano e nella crescente famiglia di leggi sulla privacy dei singoli stati USA. Per gli utenti in Cina, la PIPL aggiunge due complicazioni più nette: fornire dati personali a un altro responsabile del trattamento richiede in genere un consenso separato, e instradare i contenuti di utenti cinesi verso un endpoint LLM all’estero è un trasferimento transfrontaliero che necessita di un meccanismo riconosciuto (valutazione di sicurezza, contratto standard o certificazione). Un upgrade di modello che cambia chi conserva cosa, dove e per quanto tempo è esattamente il tipo di cambiamento per cui questi framework si aspettano che tu rifaccia le carte.

Settori con dati sensibili: dove i 30 giorni fanno più male

Per la maggior parte dei prodotti la finestra di retention del provider è un problema di documentazione. Per i settori i cui dati sono a loro volta regolamentati, diventa un problema di architettura: la copia trattenuta è dato regolamentato a riposo presso un fornitore, ed è proprio questo che le norme di settore disciplinano.

Sanità (HIPAA)

HIPAA non impone retention zero: impone che qualsiasi fornitore che detiene dati sanitari protetti lo faccia nell’ambito di un Business Associate Agreement (BAA) con misure di protezione adeguate. La copia dei tuoi prompt trattenuta per 30 giorni è PHI a riposo presso un business associate; la domanda è se il tuo BAA la copra. I due principali vendor API strutturano la cosa in modo diverso, e ora la differenza conta: l’accesso API HIPAA-ready di Anthropic non richiede ZDR — si basa su retention-con-misure-di-protezione (cifratura, controlli d’accesso, audit logging, restrizioni funzionali imposte). Il BAA API di OpenAI copre gli endpoint idonei alla zero data retention — e un BAA circoscritto agli endpoint ZDR strutturalmente non può coprire un modello che impone la retention.

La classe di retention di un modello è ormai una questione di idoneità al BAA. Prima di instradare PHI verso un modello, fatti confermare per iscritto che il tuo BAA lo copra, e ricorda che sul cloud la catena cambia: su Bedrock il business associate è la piattaforma; su Foundry i dati li elabora direttamente Anthropic. Un punto spinoso: il PHI non deve mai comparire nelle definizioni di schema JSON per gli structured output — gli schemi in cache non ricevono le stesse protezioni del contenuto dei messaggi.

Prodotti per bambini (COPPA)

I tempi sono scomodi: la COPPA Rule modificata della FTC è entrata in vigore il 23 giugno 2025, con la conformità alla maggior parte delle disposizioni prevista per il 22 aprile 2026 — il primo modello con retention obbligatoria lato provider è arrivato proprio quando gli operatori finivano di implementare i nuovi obblighi di retention. Due di questi si intrecciano direttamente con la finestra dei 30 giorni: è ora obbligatoria una politica di data retention scritta e pubblica (§312.10) — quali dati dei minori vengono raccolti, perché e quando vengono cancellati — ed è vietata la retention a tempo indeterminato, con la conservazione limitata a quanto ragionevolmente necessario allo scopo per cui i dati sono stati raccolti.

Una finestra di 30 giorni limitata con cancellazione automatica è la forma compatibile — ma il provider trattiene i dati per le proprie finalità di trust-and-safety, non per lo scopo per cui hai raccolto i dati del minore, e la tua informativa deve descrivere accuratamente il rapporto di processing. Per i prodotti rivolti ai minori che hanno adottato ZDR proprio per ridurre al minimo la traccia dei dati, la risposta sull’instradamento vale con poste in gioco più alte: il traffico dei minori resta sui modelli idonei a ZDR, oppure la finestra del Covered Model finisce prima nella tua politica §312.10.

Lo stesso schema, altri settori

Una volta capita la struttura — dati regolamentati, copia trattenuta presso un fornitore, regola di settore che disciplina la conservazione — la ritrovi ovunque:

• Dati biometrici (Illinois BIPA): gli operatori devono avere una policy di conservazione scritta e pubblicamente accessibile, con linee guida per la distruzione dei dati biometrici. La copia a 30 giorni che il provider tiene dei prompt contenenti identificatori biometrici rientra in quella policy.
• Pagamenti (PCI DSS / GLBA): PCI DSS vieta di conservare i dati sensibili di autenticazione dopo l’autorizzazione — ovunque essi si trovino. I dati di una carta incollati in un prompt diventano dati di carta conservati presso un provider per 30 giorni. La soluzione pulita è la redazione a monte, non la burocrazia a valle.
• Istruzione (FERPA): i fornitori che gestiscono dati degli studenti sotto l’eccezione del “school official” devono restare sotto il controllo diretto della scuola. Una copia di sicurezza che la scuola non può consultare né cancellare in anticipo si concilia male con questo standard — una questione da porre ai legali prima che il traffico EdTech raggiunga un Covered Model.
• Servizi finanziari — il caso opposto (SEC/FINRA): i broker-dealer devono conservare le comunicazioni di lavoro secondo le regole sui libri e registri. Per loro la finestra del provider non è il problema; il problema è catturare una propria copia conforme. Stessa questione di conservazione, segno opposto.

Il filo comune: le regole di settore disciplinano la conservazione in entrambe le direzioni, e una finestra lato provider che non controlli va mappata verso qualsiasi direzione indichi il tuo settore.

Una checklist decisionale

• ✅ Fai l’inventario dei modelli che il tuo traffico tocca davvero. La classe di conservazione ora è un attributo per modello, non per provider.
• ✅ Se hai ZDR: decidi in modo consapevole — evita i Covered Models, separa per workspace/progetto/abbonamento, oppure accetta la conservazione a livello di intera organizzazione. Non lasciare che accada per default.
• ✅ Applica la scelta nell’infrastruttura — SCP di Bedrock, controlli di privacy del workspace, progetti cloud separati — non in una pagina wiki.
• ✅ B2C: aggiorna le privacy notice e i playbook per le DSAR; indirizza gli utenti che non prestano il consenso verso modelli idonei a ZDR, invece di costruire opt-out che non possono funzionare.
• ✅ Dati regolamentati: conferma la copertura per singolo modello, per iscritto — BAA per i PHI, policy §312.10 per i dati dei minori, policy di conservazione per i dati biometrici — prima di indirizzare quei dati verso un modello che richiede la conservazione.
• ✅ Verifica il tuo logging. La finestra a 30 giorni di un provider è irrilevante se il tuo gateway registra i prompt a tempo indeterminato.

In sintesi

La finestra a 30 giorni associata a Fable 5 non è una raccolta forzata di dati: è un monitoraggio degli abusi limitato e con finalità precise, in linea con ciò che gran parte del settore già fa per default, reso obbligatorio per una classe di modelli perché il rilevamento di abusi tra richieste diverse non funziona sui dati cancellati. Per la maggior parte dei team l’impatto ingegneristico è nullo e quello sulla governance è un paragrafo in una review del fornitore.

Ma per le organizzazioni la cui posizione di compliance presupponeva zero conservazione — BAA con clausole ZDR, privacy notice che dichiarano che nulla viene mantenuto, prodotti per minori costruiti sulla minimizzazione dei dati — Fable 5 è il momento in cui quel presupposto ha smesso di valere in modo uniforme per tutti i modelli. La soluzione non è evitare il modello, ma trasformare la classe di conservazione in un parametro esplicito, per singolo modello, delle decisioni di routing, esattamente come già tratti il prezzo e la finestra di contesto.

FAQ

Posso usare Claude Fable 5 con un accordo di zero-data-retention? No. Fable 5 e Mythos 5 sono Covered Model e richiedono una retention di 30 giorni. Le organizzazioni ZDR ricevono un 400 invalid_request_error, a meno che non abilitino la retention di 30 giorni per un workspace e instradino il traffico di Fable 5 attraverso di esso.

Passare per AWS Bedrock, Vertex AI o Microsoft Foundry evita il requisito? No. Ogni piattaforma vincola il modello a un proprio opt-in per la retention: provider_data_share su Bedrock, condivisione dati Anthropic più i termini di Model Garden su Vertex, i termini di Anthropic al momento del deployment su Foundry (dove il data processor è Anthropic, non Microsoft). Su nessuna di queste gli accordi ZDR esistenti vengono ereditati.

I miei utenti finali possono rinunciare alla retention? No: non esiste un meccanismo di opt-out. La leva a tua disposizione è il routing: manda gli utenti che rifiutano la condivisione dei dati verso modelli idonei allo ZDR. Non mettere in produzione un toggle di preferenza che non cambia nulla.

I dati conservati vengono usati per addestrare i modelli? Anthropic dichiara che i dati conservati non vengono mai usati per il training senza permesso esplicito. Lo scopo è la revisione trust-and-safety: screening automatico, con le conversazioni segnalate revisionabili solo da personale autorizzato che non può esportare i dati, sotto log di accesso a prova di manomissione.

La retention di 30 giorni cambia il funzionamento del prompt caching? No. Le voci di cache seguono i propri TTL brevi (5 minuti o 1 ora) e il contratto di caching su Fable 5 resta invariato — vedi la nostra valutazione con misurazioni. La finestra di 30 giorni è una retention separata e parallela, dedicata alla revisione di sicurezza.

Fonti

• Anthropic — API and data retention
• Anthropic — Covered Models
• Anthropic — Data retention practices for Mythos-class models
• AWS — Amazon Bedrock data retention
• Google Cloud — Claude Fable 5 (partner models)
• Google Cloud — Vertex AI data governance
• Microsoft — Claude in Foundry: data, privacy, and security
• OpenAI — Enterprise privacy
• OpenAI — BAA for API services
• FTC — COPPA Rule amendments (press release)
• Federal Register — Children’s Online Privacy Protection Rule

Tutto verificato il 2026-06-12. Le policy cambiano: verifica sui documenti attuali e sui tuoi contratti. Non è una consulenza legale.

← Torna al blog