Claude Fable 5 non funziona con ZDR: la conservazione per 30 giorni è obbligatoria

Se la tua organizzazione usa Claude con un accordo zero-data-retention (ZDR), la prima richiesta a claude-fable-5 non ha restituito una completion, ma un errore 400 invalid_request_error. Non è un disservizio: è una policy. Fable 5 è il primo modello Claude disponibile in generale che non può essere usato senza conservare i dati per 30 giorni. Il requisito vale su tutte le piattaforme: Claude API, AWS Bedrock, Google Vertex AI e Microsoft Foundry richiedono ciascuna un consenso esplicito alla conservazione.

Per i team che consideravano «non conserviamo i tuoi dati» una caratteristica ormai acquisita del proprio stack LLM, si tratta di un cambiamento architetturale. Questo articolo spiega cosa prevede la policy, perché esiste la finestra di conservazione, come viene implementata sui diversi cloud e quali conseguenze comporta per i prodotti consumer e i settori che trattano dati sensibili.

TL;DR

• Claude Fable 5 non può essere usato senza conservare prompt e completion per 30 giorni; il requisito vale su Claude API, AWS Bedrock, Google Vertex AI e Microsoft Foundry (policy in vigore dal 2026-06-09).
• Non è possibile rinunciare: le organizzazioni soggette ad accordi zero-data-retention ricevono 400 invalid_request_error e le condizioni ZDR esistenti non si applicano automaticamente.
• Su Bedrock, Fable 5 richiede data_retention_mode: provider_data_share; senza questa impostazione, 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 il 2026-06-12 sulla documentazione pubblicata da Anthropic, AWS, Google e Microsoft. Le policy cambiano: consulta le fonti primarie collegate e i tuoi contratti. Questa è una panoramica tecnica, non una consulenza legale.

Cosa prevede esattamente la policy

Anthropic classifica Claude Fable 5 e Claude Mythos 5 come Modelli coperti. Secondo la documentazione sulla conservazione dei dati API e l’articolo sulle pratiche di conservazione per i modelli della classe Mythos (in vigore dal 2026-06-09):

• Prompt e completion vengono conservati per 30 giorni e poi eliminati automaticamente, salvo che siano stati segnalati nell’ambito di un’indagine di sicurezza attiva o che la legge ne imponga la conservazione.
• Non è possibile rinunciare. La conservazione è una condizione per usare il modello. Le richieste provenienti da organizzazioni la cui configurazione non soddisfa il requisito restituiscono 400 invalid_request_error.
• L’accesso è volutamente limitato. Sistemi di sicurezza automatizzati analizzano i dati. Solo un ristretto gruppo di personale autorizzato può esaminare le conversazioni segnalate, senza poterle esportare, copiare o scaricare. Ogni accesso viene registrato in log antimanomissione.
• Gli accordi ZDR esistenti non si applicano automaticamente al traffico dei Modelli coperti, neppure quando passa attraverso piattaforme cloud.

I piani consumer (Claude Free/Pro/Max) non sono interessati: seguono già le proprie condizioni di conservazione. La policy riguarda l’API commerciale, proprio dove si concentrano le promesse del tipo «non conserviamo mai i dati».

Perché esiste una finestra di 30 giorni

La motivazione indicata nell’articolo sui Modelli coperti è precisa: questi modelli hanno capacità molto più avanzate nello sviluppo software, nei workflow agentici e nella cybersecurity, e «alcune forme di abuso diventano rilevabili solo analizzando molte richieste». Gli esempi citati, jailbreaking best-of-N e spionaggio sponsorizzato da Stati, sono schemi di attacco in cui ogni singolo prompt può sembrare innocuo e solo la sequenza rivela l’abuso. Una sequenza eliminata non può essere rilevata.

Due cose che questa finestra non è:

• Non è un modo per raccogliere dati di training. Anthropic dichiara che i dati conservati non vengono mai usati per il training senza autorizzazione esplicita. Servono esclusivamente a rilevare gli abusi.
• Non è una novità in sé: cambia il fatto che sia obbligatoria. Da anni una finestra di circa 30 giorni per il monitoraggio degli abusi è lo standard di settore: OpenAI conserva i log API relativi agli abusi fino a 30 giorni (ZDR previa approvazione); Azure OpenAI conserva i prompt fino a 30 giorni, salvo approvazione per il monitoraggio degli abusi modificato. La novità è che la finestra è diventata non negoziabile per una classe di modelli. In precedenza, tutti i provider offrivano un’opzione zero-retention.

C’è anche una condizione preesistente che spesso sorprende: persino con ZDR, Anthropic conserva i risultati dei classificatori di sicurezza e può mantenere per un massimo di 2 anni i contenuti segnalati per violazioni della Usage Policy. Zero data retention non ha mai significato zero dati: significa non conservare i contenuti non segnalati nel flusso normale.

Stesso requisito, tre cloud, tre meccanismi

La conservazione si applica ovunque venga eseguito il modello, ma ogni piattaforma gestisce il consenso in modo diverso. Queste differenze determinano chi tratta i dati e dove si applicano i controlli.

AWS Bedrock è la piattaforma più esplicita. La conservazione dei dati è una modalità configurabile (default / provider_data_share / none), determinata in quest’ordine: progetto → account → valore predefinito 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. Un SCP sulla condition key bedrock:DataRetentionMode può imporre la policy a tutta l’organizzazione, impedendo che qualcuno modifichi di nascosto l’account per provare il nuovo modello. Attenzione: con l’inferenza cross-region, la copia conservata si trova nella regione di destinazione. È un dettaglio rilevante se hai obblighi di residenza dei dati.

Google Vertex AI rende disponibile il modello solo dopo aver attivato a livello di progetto la condivisione dei dati con Anthropic (setPublisherModelConfig con dataSharingEnabledProvider: "anthropic") e aver accettato le condizioni in Model Garden, come indicato nella documentazione di Google su Fable 5. Il trattamento generale dei dati segue la policy di data governance di Vertex AI. Per i workload soggetti a vincoli di residenza, gli endpoint regionali e multiregionali di Vertex determinano dove viene eseguita l’inferenza e, ora, anche dove risiede la copia conservata.

Microsoft Foundry ha un’architettura diversa. La documentazione Microsoft su dati e privacy chiarisce che i modelli Claude sono servizi marketplace di terze parti: al deployment si accettano le condizioni di Anthropic e il responsabile del trattamento è Anthropic, non Microsoft. I programmi ZDR e di monitoraggio degli abusi modificato di Azure OpenAI non si estendono ai deployment Claude. In genere, le organizzazioni che adottano ZDR altrove isolano l’uso dei Modelli coperti in una sottoscrizione dedicata. In questo modo, il confine di conservazione è strutturale anziché procedurale.

Lo schema è lo stesso su tutte e tre le piattaforme: la classe di conservazione è diventata un attributo del modello di prima classe e leggibile dalle macchine. Può essere una modalità, un flag o un vincolo contrattuale, non più solo un paragrafo in un contratto. L’infrastruttura può applicare automaticamente la tua policy sui dati, e dovrebbe farlo.

Conseguenze per i deployment enterprise

Se non hai un accordo ZDR, dal punto di vista operativo non cambia nulla: probabilmente eri già soggetto a una policy simile ai 30 giorni, magari senza saperlo. Devi però renderlo esplicito nella documentazione relativa ai fornitori.

Se hai un accordo ZDR, hai tre possibilità:

1. Non usare i Modelli coperti. ZDR resta uniforme, ma rinunci al modello. È una scelta praticabile se i workload non ne richiedono le capacità. Consulta la nostra valutazione di Fable 5 basata su misurazioni per costi e differenze.
2. Separare per workspace o progetto. Tutte le piattaforme consentono un consenso circoscritto: un workspace Claude API dedicato (Console → Settings → Workspaces → Privacy controls), un progetto Bedrock con provider_data_share, un progetto Vertex o una sottoscrizione Azure separati. Instrada lì solo i workload compatibili con la conservazione.
3. Accettare la conservazione per tutta l’organizzazione. È la soluzione più semplice da gestire, ma riduce implicitamente le garanzie per ogni workload, compresi quelli la cui sensibilità aveva motivato ZDR. Non è una semplice modifica di configurazione: deve deciderla il responsabile della protezione dei dati.

Indipendentemente dal provider, anche i tuoi log costituiscono una superficie di conservazione. Se il gateway o lo stack di osservabilità registrano i prompt completi, potresti conservarli più a lungo del provider nella tua infrastruttura. Le garanzie del provider valgono quanto il layer che lo precede. La stessa logica di audit applicata alle dichiarazioni sulla cache vale anche qui.

Conseguenze per i prodotti consumer

Se servi consumatori e instradi i loro contenuti attraverso un Modello coperto, il cambiamento si riflette sui tuoi obblighi legali, anche senza un accordo ZDR. Le conseguenze concrete sono tre:

1. Probabilmente devi aggiornare l’informativa sulla privacy. Nella maggior parte degli ordinamenti devi dichiarare non solo la raccolta, ma anche la conservazione: l’Articolo 13(2)(a) del GDPR richiede di indicare al momento della raccolta il periodo di conservazione o i criteri usati per determinarlo; il CPRA californiano impone che l’informativa al momento della raccolta specifichi la durata per ogni categoria di informazioni personali. Se l’informativa afferma, o lascia intendere, che i dati delle conversazioni non vengono conservati da nessuna parte, la copia mantenuta per 30 giorni da un responsabile del trattamento rende tale dichiarazione errata. 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 conservazione non prevede eccezioni, quindi non puoi creare un controllo che escluda i prompt di un utente continuando a usare lo stesso modello. L’unico strumento a tua disposizione è il routing: un gateway che tiene conto del consenso invia gli utenti che rifiutano la condivisione dei dati verso modelli compatibili con ZDR e tutti gli altri verso il Modello coperto. Un vincolo legale diventa così una normale regola di routing. È molto meglio di una preferenza che non produce alcun effetto.

3. La gestione delle richieste di cancellazione deve riflettere il comportamento reale. Gli obblighi di cancellazione (Art. 17 GDPR, cancellazione prevista dal CPRA e norme equivalenti) si estendono ai responsabili del trattamento. Una finestra limitata con eliminazione automatica entro 30 giorni è in genere una posizione difendibile per un responsabile del trattamento. La procedura DSAR deve però dichiararlo chiaramente, senza promettere una cancellazione downstream immediata che non puoi eseguire.

A livello globale si aggiungono ulteriori complessità: gli stessi requisiti di trasparenza e gestione dei responsabili del trattamento compaiono nel GDPR britannico, nella LGPD brasiliana e nelle sempre più numerose leggi statali statunitensi sulla privacy. Per gli utenti in Cina, la PIPL introduce due vincoli ulteriori: la comunicazione di informazioni personali a un altro responsabile richiede in genere un consenso separato, mentre l’invio dei contenuti degli utenti cinesi a un endpoint LLM estero costituisce un trasferimento transfrontaliero e richiede un meccanismo riconosciuto, come una valutazione di sicurezza, un contratto standard o una certificazione. Un upgrade del modello che modifica chi conserva quali dati, dove e per quanto tempo è esattamente il tipo di cambiamento per cui questi quadri normativi richiedono di aggiornare la documentazione.

Settori con dati sensibili: dove i 30 giorni pesano di più

Per la maggior parte dei prodotti, la finestra del provider è un problema di documentazione. Nei settori in cui i dati sono soggetti a regolamentazione, diventa un problema architetturale: la copia conservata è un dato regolamentato a riposo presso un fornitore, e le norme di settore ne disciplinano direttamente il trattamento.

Sanità (HIPAA)

HIPAA non richiede zero retention. Richiede che qualsiasi fornitore in possesso di protected health information operi in base a un Business Associate Agreement (BAA) e adotti misure di sicurezza adeguate. La copia dei prompt conservata per 30 giorni è PHI a riposo presso un business associate. La domanda è se il tuo BAA la copra. I due principali fornitori API adottano approcci diversi, e ora questa differenza conta: l’accesso HIPAA-ready alle API di Anthropic esplicitamente non richiede ZDR. Si basa sulla conservazione con misure di sicurezza quali cifratura, controlli di accesso, audit logging e limitazioni obbligatorie delle funzionalità. Il BAA di OpenAI per le API copre gli endpoint idonei per zero data retention, e un BAA circoscritto agli endpoint ZDR non può, per definizione, coprire un modello che impone la conservazione.

La classe di conservazione di un modello è ora un requisito per l’idoneità al BAA. Prima di inviare PHI, fatti confermare per iscritto che il BAA copra quel modello specifico. Ricorda inoltre che sui cloud cambia la catena dei soggetti coinvolti: su Bedrock la piattaforma è il tuo business associate; su Foundry i dati vengono trattati direttamente da Anthropic. Un dettaglio critico: i PHI non devono mai comparire nelle definizioni JSON schema degli output strutturati, perché gli schema memorizzati nella cache non ricevono le stesse protezioni dei contenuti dei messaggi.

Prodotti per bambini (COPPA)

La tempistica è problematica: la COPPA Rule modificata della FTC è entrata in vigore il June 23, 2025, con l’obbligo di adeguarsi alla maggior parte delle disposizioni entro il April 22, 2026. Il primo modello con conservazione obbligatoria lato provider è arrivato proprio mentre gli operatori terminavano di implementare i nuovi obblighi di conservazione. Due di questi interagiscono direttamente con la finestra di 30 giorni: ora è obbligatoria una policy scritta e pubblica sulla conservazione dei dati (§312.10), che indichi quali dati dei minori vengono raccolti, perché e quando sono eliminati; inoltre, la conservazione a tempo indeterminato è vietata e i dati possono essere mantenuti solo per il tempo ragionevolmente necessario allo scopo per cui sono stati raccolti.

Una finestra limitata di 30 giorni con eliminazione automatica ha una struttura compatibile. Il provider, però, conserva i dati per le proprie finalità di trust and safety, non per lo scopo per cui tu hai raccolto i dati del minore. L’informativa deve descrivere con precisione il rapporto con il responsabile del trattamento. Per i prodotti rivolti ai minori che avevano scelto ZDR proprio per ridurre al minimo le tracce di dati, il routing diventa ancora più importante: il traffico dei minori deve restare su modelli compatibili con ZDR, oppure la finestra del Modello coperto va prima inserita nella policy prevista dal §312.10.

Lo stesso schema negli altri settori

Una volta riconosciuta la struttura, cioè dati regolamentati, una copia conservata presso un fornitore e una norma di settore che disciplina la conservazione, lo stesso problema ricorre altrove:

• Dati biometrici (BIPA dell’Illinois): gli operatori devono pubblicare un programma scritto di conservazione e linee guida per la distruzione dei dati biometrici. La copia conservata per 30 giorni dal provider, se contiene identificatori biometrici, deve rientrare in quel programma.
• Pagamenti (PCI DSS / GLBA): PCI DSS vieta di conservare dati sensibili di autenticazione dopo l’autorizzazione, ovunque si trovino. I dati di una carta incollati in un prompt diventano dati di pagamento conservati dal provider per 30 giorni. La soluzione corretta è la redazione upstream, non la documentazione downstream.
• Istruzione (FERPA): i fornitori che gestiscono dati degli studenti in base alla school-official exception devono restare sotto il controllo diretto della scuola. Una copia conservata per motivi di sicurezza, che la scuola non può consultare né cancellare in anticipo, si concilia male con questo requisito. Prima di inviare traffico EdTech a un Modello coperto, serve una valutazione legale.
• Servizi finanziari: il problema opposto (SEC/FINRA): i broker-dealer devono conservare le comunicazioni aziendali in base alle regole sui libri e registri. Per loro la finestra del provider non è il problema; il punto è acquisire una propria copia conforme. La domanda sulla conservazione è la stessa, ma la risposta va nella direzione opposta.

Il principio comune è che le norme di settore regolano la conservazione in entrambe le direzioni. Una finestra lato provider che non controlli deve essere allineata alla direzione imposta dal tuo settore.

Checklist decisionale

• ✅ Fai l’inventario dei modelli effettivamente attraversati dal traffico. La classe di conservazione è ormai un attributo del singolo modello, non del provider.
• ✅ Se hai ZDR, scegli consapevolmente: evita i Modelli coperti, separa per workspace/progetto/sottoscrizione oppure accetta la conservazione per tutta l’organizzazione. Non lasciare che avvenga implicitamente.
• ✅ Applica la policy nell’infrastruttura, tramite SCP Bedrock, controlli Privacy del workspace e progetti cloud separati, non in una pagina wiki.
• ✅ Per il B2C, aggiorna informative sulla privacy e procedure DSAR; instrada gli utenti che non acconsentono verso modelli compatibili con ZDR, invece di creare opt-out che non possono funzionare.
• ✅ Per i dati regolamentati, ottieni conferma scritta della copertura per ogni modello: BAA per PHI, policy §312.10 per i dati dei minori, programmi di conservazione per i dati biometrici. Fallo prima di instradare questi dati verso un modello che impone la conservazione.
• ✅ Verifica i tuoi log. La finestra di 30 giorni del provider è irrilevante se il gateway conserva i prompt a tempo indeterminato.

In sintesi

La finestra di 30 giorni associata a Fable 5 non serve a raccogliere dati indiscriminatamente. È un meccanismo limitato nel tempo e nello scopo per monitorare gli abusi, coerente con ciò che gran parte del settore applica già per impostazione predefinita. Diventa obbligatorio per una classe di modelli perché il rilevamento degli abusi distribuiti su più richieste non funziona se i dati vengono eliminati. Per la maggior parte dei team, l’impatto tecnico è nullo e quello di governance si riduce a un paragrafo nella valutazione del fornitore.

Per le organizzazioni la cui compliance presupponeva zero retention, come BAA circoscritti a ZDR, informative che dichiarano che nulla viene conservato o prodotti per minori basati sulla minimizzazione dei dati, Fable 5 segna la fine di un presupposto uniforme tra modelli. La soluzione non è evitare il modello. Bisogna trattare la classe di conservazione come un input esplicito, modello per modello, nelle decisioni di routing, esattamente come prezzo e finestra di contesto.

FAQ

Posso usare Claude Fable 5 con un accordo zero-data-retention? No. Fable 5 e Mythos 5 sono Modelli coperti che richiedono la conservazione per 30 giorni. Le organizzazioni ZDR ricevono 400 invalid_request_error, a meno che non abilitino la conservazione per 30 giorni in un workspace e instradino lì il traffico Fable 5.

Passare da AWS Bedrock, Vertex AI o Microsoft Foundry evita il requisito? No. Ogni piattaforma rende disponibile il modello solo dopo uno specifico consenso alla conservazione: provider_data_share su Bedrock, condivisione dei dati con Anthropic e condizioni di Model Garden su Vertex, condizioni di Anthropic al deployment su Foundry, dove il responsabile del trattamento è Anthropic e non Microsoft. Gli accordi ZDR esistenti non si applicano automaticamente su nessuna di queste piattaforme.

I miei utenti finali possono rifiutare la conservazione? No, non esiste un meccanismo di opt-out. Puoi intervenire solo sul routing: gli utenti che rifiutano la condivisione dei dati devono essere inviati a modelli compatibili con ZDR. Non pubblicare un controllo delle preferenze 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 autorizzazione esplicita. Servono alle verifiche di trust and safety: uno screening automatizzato segnala le conversazioni, che possono essere esaminate solo da personale autorizzato senza possibilità di esportare i dati. Gli accessi vengono registrati in log antimanomissione.

La conservazione per 30 giorni modifica il funzionamento del prompt caching? No. Le entry della cache seguono i propri TTL brevi (5 minuti o 1 ora) e il contratto di caching di Fable 5 non cambia. Consulta la nostra valutazione basata su misurazioni. La finestra di 30 giorni è una conservazione separata e parallela, destinata alle verifiche di sicurezza.

Letture correlate: la guida completa al prompt caching descrive i meccanismi della cache su cui incidono le policy di conservazione, mentre i prezzi della piattaforma riportano il costo di ogni modello al prezzo di listino del provider.

Fonti

• Anthropic, API e conservazione dei dati
• Anthropic, Modelli coperti
• Anthropic, Pratiche di conservazione dei dati per i modelli della classe Mythos
• AWS, Conservazione dei dati in Amazon Bedrock
• Google Cloud, Claude Fable 5 (modelli partner)
• Google Cloud, Data governance di Vertex AI
• Microsoft, Claude in Foundry: dati, privacy e sicurezza
• OpenAI, Privacy enterprise
• OpenAI, BAA per i servizi API
• FTC, Modifiche alla COPPA Rule (comunicato stampa)
• Federal Register, Children’s Online Privacy Protection Rule

Documenti verificati il 2026-06-12. Le policy cambiano: consulta i documenti aggiornati e i tuoi contratti. Questa non è una consulenza legale.

← Torna al blog