Claude Fable 5 não funciona com ZDR: retenção de 30 dias é obrigatória

Se sua organização usa Claude sob um acordo de retenção zero de dados (ZDR), a primeira requisição ao claude-fable-5 não retornou uma resposta. Retornou 400 invalid_request_error. Não é uma indisponibilidade, mas uma regra da política. Fable 5 é o primeiro modelo Claude disponível de forma geral que não pode ser usado sem retenção de dados por 30 dias. A exigência acompanha o modelo em todas as plataformas: Claude API, AWS Bedrock, Google Vertex AI e Microsoft Foundry exigem adesão explícita à retenção.

Para equipes que tratavam “não retemos seus dados” como uma característica consolidada da stack de LLM, isso exige uma mudança de arquitetura. Este artigo explica o que diz a política, por que existe essa janela, como cada cloud a implementa e o que muda para produtos de consumo e setores que processam dados sensíveis.

TL;DR

• Claude Fable 5 não pode ser usado sem retenção de prompts e respostas por 30 dias. A exigência vale para Claude API, AWS Bedrock, Google Vertex AI e Microsoft Foundry (política em vigor desde 2026-06-09).
• Não há opt-out: organizações com acordos de retenção zero recebem 400 invalid_request_error, e os termos de ZDR existentes não se aplicam ao modelo.
• No Bedrock, Fable 5 exige data_retention_mode: provider_data_share; sem essa configuração, o modelo aparece como indisponível.
• Conteúdo sinalizado por violações da Política de Uso pode ser mantido por até 2 anos, independentemente da janela de 30 dias.

Os detalhes da política foram conferidos na documentação publicada por Anthropic, AWS, Google e Microsoft em 2026-06-12. Políticas mudam; consulte as fontes primárias indicadas e seus próprios contratos. Este texto é uma visão geral de engenharia, não uma orientação jurídica.

O que a política realmente diz

A Anthropic classifica Claude Fable 5 e Claude Mythos 5 como Modelos Abrangidos. Segundo a documentação de retenção de dados da API e o artigo sobre práticas de retenção dos modelos da classe Mythos (em vigor desde 2026-06-09):

• Prompts e respostas são retidos por 30 dias e depois excluídos automaticamente, salvo quando sinalizados em uma investigação de segurança ativa ou quando a retenção é exigida por lei.
• Não há opt-out. A retenção é uma condição para usar o modelo. Uma requisição feita por uma organização cuja configuração de retenção não atende à exigência retorna 400 invalid_request_error.
• O acesso é restrito por padrão. Sistemas automatizados de segurança analisam os dados. Somente um pequeno grupo de pessoas autorizadas pode revisar conversas sinalizadas; elas não podem exportar, copiar ou baixar o conteúdo, e todos os acessos são registrados em logs invioláveis.
• Os acordos de ZDR existentes não se aplicam ao tráfego dos Modelos Abrangidos, inclusive quando o acesso ocorre por plataformas de cloud.

Os planos para consumidores (Claude Free/Pro/Max) não são afetados, pois já operam sob seus próprios termos de retenção. A política se aplica à API comercial, justamente onde costumam existir as garantias de que “nunca retemos dados”.

Por que existe uma janela de 30 dias

A justificativa apresentada no artigo sobre Modelos Abrangidos é específica: esses modelos avançaram consideravelmente em engenharia de software, workflows agênticos e cibersegurança, e “algumas formas de uso indevido só podem ser detectadas em um conjunto de muitas requisições.” Os exemplos citados, jailbreaking best-of-N e espionagem patrocinada por Estados, são padrões de ataque em que cada prompt parece inofensivo isoladamente. Só a sequência revela o ataque. Não é possível detectar uma sequência que já foi excluída.

A janela não é:

• Uma fonte de dados de treinamento. A Anthropic afirma que os dados retidos nunca são usados para treinamento sem autorização expressa. A finalidade é exclusivamente detectar abuso.
• Um tipo novo de retenção; o que muda é a obrigatoriedade. Uma janela de aproximadamente 30 dias para monitoramento de abuso é o padrão do setor há anos: a OpenAI mantém logs de abuso da API por até 30 dias (ZDR mediante aprovação); o Azure OpenAI armazena prompts por até 30 dias, salvo quando o cliente é aprovado para monitoramento de abuso modificado. A mudança é que a janela passou a ser inegociável para uma classe de modelos. Antes, todos os provedores ofereciam uma alternativa com retenção zero.

Há uma ressalva anterior à nova política que costuma surpreender: mesmo sob ZDR, a Anthropic mantém os resultados dos classificadores de segurança, e conteúdos sinalizados por violação da Política de Uso podem ser retidos por até 2 anos. Retenção zero nunca significou ausência total de dados. Significa que o conteúdo não sinalizado não é mantido no fluxo normal.

A mesma exigência em três clouds, com três mecanismos

A retenção se aplica onde quer que o modelo seja executado, mas cada plataforma implementa a adesão de forma diferente. Essas diferenças determinam quem processa os dados e onde ficam os controles.

O AWS Bedrock oferece a implementação mais explícita. A retenção de dados é um modo configurável (default / provider_data_share / none), resolvido na ordem projeto → conta → padrão do modelo. Fable 5 declara allowed_modes: ["provider_data_share"]: prompts e respostas são compartilhados com a Anthropic e retidos por até 30 dias. Em qualquer outro modo:

{
  "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"]
  }
}

Nada mudou para os modelos anteriores ao Fable 5. Um SCP aplicado à condition key bedrock:DataRetentionMode pode impor a política em toda a organização, evitando que alguém altere silenciosamente a conta apenas para testar o novo modelo. Em inferência cross-region, a cópia retida fica na região de destino, o que importa para organizações com compromissos de residência de dados.

O Google Vertex AI exige uma configuração de compartilhamento de dados com a Anthropic no nível do projeto (setPublisherModelConfig com dataSharingEnabledProvider: "anthropic"), além do aceite dos termos no Model Garden, conforme a documentação do Fable 5 no Google. O tratamento geral dos dados segue a política de governança de dados do Vertex AI. Para workloads com requisitos de residência, os endpoints regionais e multirregionais do Vertex determinam onde ocorre a inferência e, agora, onde fica a cópia retida.

O Microsoft Foundry tem uma estrutura diferente. A documentação de dados e privacidade da Microsoft deixa claro que os modelos Claude são serviços de terceiros oferecidos no marketplace: os termos da Anthropic são aceitos no deployment, e a Anthropic, não a Microsoft, atua como operadora dos dados. Os programas de ZDR e monitoramento de abuso modificado do Azure OpenAI não se estendem aos deployments do Claude. Organizações que usam ZDR em outras partes da infraestrutura costumam isolar os Modelos Abrangidos em uma assinatura dedicada. Assim, a fronteira de retenção fica definida pela arquitetura, não apenas por procedimentos.

O padrão é o mesmo nas três plataformas: a classe de retenção passou a ser um atributo explícito do modelo, legível por máquina. É um modo, uma flag ou uma etapa de aceite de termos, não apenas um parágrafo contratual. Sua infraestrutura já pode impor a política de dados e deve fazer isso.

O que muda em deployments empresariais

Sem um acordo de ZDR, nada muda do ponto de vista operacional. Sua organização provavelmente já trabalhava com uma política semelhante à janela de 30 dias, mesmo sem perceber. O trabalho agora é documentá-la de forma explícita na avaliação do fornecedor.

Com um acordo de ZDR, há três opções:

1. Não usar Modelos Abrangidos. O ZDR permanece uniforme, mas você abre mão do modelo. É uma opção viável se os workloads não dependem dele. Veja nossa avaliação prática do Fable 5 para entender o custo e as diferenças.
2. Separar por workspace ou projeto. Todas as plataformas permitem adesão com escopo limitado: um workspace específico na Claude API (Console → Settings → Workspaces → Privacy controls), um projeto do Bedrock com provider_data_share, um projeto separado no Vertex ou uma assinatura separada no Azure. Somente workloads que toleram retenção devem ser roteados para esse ambiente.
3. Aceitar a retenção em toda a organização. É a opção mais simples de operar, mas reduz silenciosamente a garantia para todos os workloads, inclusive aqueles cuja sensibilidade justificou o ZDR. Essa decisão cabe ao responsável pela proteção de dados, não a quem altera a configuração.

Independentemente do provedor, seus próprios logs formam uma segunda superfície de retenção. Se o gateway ou a stack de observabilidade registra prompts completos, a janela sob seu controle pode ser maior que a do provedor. As garantias do provedor só valem até a camada que fica à frente dele. A mesma lógica de auditoria aplicada às garantias de cache também vale aqui.

O que muda para produtos voltados ao consumidor

Se seu produto atende consumidores e envia o conteúdo deles a um Modelo Abrangido, a mudança afeta suas próprias obrigações legais, com ou sem acordo de ZDR. Há três consequências concretas:

1. Seu aviso de privacidade provavelmente precisa ser atualizado. A maioria dos regimes exige informar não apenas a coleta, mas também a retenção: o Artigo 13(2)(a) do GDPR exige que o prazo de armazenamento, ou os critérios usados para defini-lo, seja informado no momento da coleta; o CPRA da Califórnia exige que o aviso de coleta indique o prazo de retenção de cada categoria de informação pessoal. Se o aviso afirma, ou dá a entender, que os dados das conversas não são armazenados em nenhum lugar, uma cópia retida por 30 dias por um operador torna essa informação incorreta. Atualize o aviso, os registros das operações de tratamento e o inventário de DPAs.

2. Você não pode oferecer aos usuários um opt-out que não existe. Não há nenhuma exceção à retenção. Portanto, não é possível criar um toggle que exclua os prompts de um usuário e ainda usar esse modelo. O mecanismo disponível é o roteamento: um gateway ciente do consentimento envia usuários que recusaram o compartilhamento de dados para modelos compatíveis com ZDR e todos os demais para o Modelo Abrangido. Uma restrição jurídica vira uma regra comum de roteamento. É muito melhor que exibir uma caixa de preferência sem efeito real.

3. As solicitações de exclusão precisam refletir o funcionamento real. As obrigações de eliminação (Art. 17 do GDPR, exclusão prevista no CPRA e equivalentes) também se estendem aos operadores. Uma janela limitada, com exclusão automática em até 30 dias, costuma ser uma prática defensável para um operador. Seu processo de DSAR deve informar isso, em vez de prometer uma exclusão imediata nos sistemas downstream que você não consegue executar.

A dimensão global amplia o problema: a mesma lógica de transparência e operadores aparece no UK GDPR, na LGPD brasileira e no conjunto crescente de leis estaduais de privacidade nos EUA. Para usuários na China, a PIPL impõe duas exigências adicionais: o fornecimento de informações pessoais a outro operador normalmente requer consentimento separado, e o envio de conteúdo de usuários chineses a um endpoint de LLM no exterior constitui transferência internacional, que exige um mecanismo reconhecido, como avaliação de segurança, contrato-padrão ou certificação. Um upgrade de modelo que altera quem retém quais dados, onde e por quanto tempo é exatamente o tipo de mudança que obriga a revisar a documentação nesses regimes.

Setores com dados sensíveis: onde os 30 dias mais pesam

Para a maioria dos produtos, a janela do provedor é um problema de documentação. Em setores onde os próprios dados são regulados, é um problema de arquitetura: a cópia retida é um dado regulado armazenado em repouso por um fornecedor, e as regras setoriais determinam como esse dado deve ser tratado.

Saúde (HIPAA)

A HIPAA não exige retenção zero. Ela exige que qualquer fornecedor que mantenha informações de saúde protegidas o faça sob um Business Associate Agreement (BAA) e com as salvaguardas adequadas. A cópia dos prompts mantida por 30 dias é PHI em repouso nas mãos de um business associate. A questão é se o BAA cobre essa retenção. Os dois principais fornecedores de API tratam o tema de formas diferentes, e essa diferença agora importa: o acesso à API da Anthropic preparado para HIPAA explicitamente não exige ZDR. Ele foi estruturado com retenção e salvaguardas, como criptografia, controles de acesso, logs de auditoria e restrições obrigatórias de recursos. O BAA da API da OpenAI cobre endpoints qualificados para retenção zero, e um BAA limitado a endpoints ZDR não pode, por definição, cobrir um modelo que exige retenção.

A classe de retenção do modelo agora determina sua elegibilidade para o BAA. Antes de enviar PHI, confirme por escrito que o BAA cobre o modelo específico. A cadeia também muda conforme a cloud: no Bedrock, a plataforma é seu business associate; no Foundry, a Anthropic processa os dados diretamente. Há ainda um risco específico: PHI nunca deve aparecer nas definições de JSON schema para structured outputs. Schemas em cache não recebem as mesmas proteções que o conteúdo das mensagens.

Produtos infantis (COPPA)

O momento é particularmente ruim: a regra COPPA alterada pela FTC entrou em vigor em 23 de junho de 2025, com prazo de adequação para a maioria das disposições em 22 de abril de 2026. O primeiro modelo com retenção obrigatória no provedor chegou justamente quando os operadores terminavam de implementar as novas obrigações. Duas delas afetam diretamente a janela de 30 dias: agora é obrigatória uma política de retenção de dados escrita e pública (§312.10), que informe quais dados infantis são coletados, por quê e quando serão excluídos; além disso, a retenção por prazo indeterminado é proibida, devendo se limitar ao período razoavelmente necessário para a finalidade da coleta.

Uma janela limitada a 30 dias, com exclusão automática, tem um formato compatível. Porém, o provedor retém os dados para sua própria finalidade de trust and safety, não para a finalidade pela qual você coletou os dados da criança. Seu aviso deve descrever corretamente essa relação com o operador. Para produtos dirigidos a crianças que adotaram ZDR especificamente para minimizar o rastro de dados, o roteamento é ainda mais importante: o tráfego infantil permanece em modelos compatíveis com ZDR, ou a janela do Modelo Abrangido deve ser incluída primeiro na política exigida pelo §312.10.

O mesmo padrão em outros setores

Depois de identificar a estrutura, dados regulados, cópia retida por um fornecedor e regra setorial aplicável à retenção, o mesmo padrão aparece em outros contextos:

• Biometria (Illinois BIPA): operadores precisam de um cronograma de retenção e diretrizes de destruição, por escrito e disponíveis publicamente, para dados biométricos. Uma cópia mantida por 30 dias pelo provedor de prompts que contenham identificadores biométricos deve fazer parte desse cronograma.
• Pagamentos (PCI DSS / GLBA): o PCI DSS proíbe armazenar dados confidenciais de autenticação após a autorização, em qualquer lugar. Dados de cartão colados em um prompt passam a ser dados de cartão retidos pelo provedor por 30 dias. A solução correta é remover esses dados antes do envio, não tentar corrigir o problema depois com documentação.
• Educação (FERPA): fornecedores que tratam registros de alunos pela exceção aplicável a funcionários da instituição devem permanecer sob o controle direto da escola. Uma cópia retida para segurança, que a escola não pode acessar nem excluir antecipadamente, é difícil de conciliar com esse requisito. É uma questão para o jurídico antes que o tráfego de EdTech chegue a um Modelo Abrangido.
• Serviços financeiros: a lógica se inverte (SEC/FINRA): corretoras devem reter comunicações comerciais segundo as regras de livros e registros. Nesse caso, a janela do provedor não é o problema. O desafio é manter uma cópia própria em conformidade. É a mesma questão de retenção, mas no sentido oposto.

O ponto em comum é que as regras setoriais regulam a retenção nas duas direções, e uma janela controlada pelo provedor precisa ser incorporada às exigências do seu setor, sejam elas de retenção mínima ou máxima.

Checklist para a decisão

• ✅ Faça um inventário dos modelos pelos quais seu tráfego realmente passa. A classe de retenção agora é um atributo de cada modelo, não de cada provedor.
• ✅ Se você usa ZDR, decida de forma explícita: não usar Modelos Abrangidos, separar por workspace/projeto/assinatura ou aceitar a retenção em toda a organização. Não deixe isso acontecer de forma implícita.
• ✅ Imponha a política na infraestrutura, com SCPs do Bedrock, controles de privacidade do workspace e projetos separados na cloud, não em uma página da wiki.
• ✅ Em produtos B2C, atualize os avisos de privacidade e os processos de DSAR; roteie usuários que não consentirem para modelos compatíveis com ZDR, em vez de criar opt-outs que não funcionam.
• ✅ Para dados regulados, confirme por escrito a cobertura de cada modelo: BAA para PHI, política conforme §312.10 para dados infantis e cronogramas de retenção para biometria, antes de rotear esses dados para um modelo que exige retenção.
• ✅ Audite seus próprios logs. A janela de 30 dias do provedor não importa se o gateway mantém prompts indefinidamente.

Conclusão

A janela de 30 dias do Fable 5 não é uma tentativa de coletar dados. É um mecanismo limitado e vinculado à finalidade de monitorar abuso, alinhado ao que a maior parte do setor já adota por padrão. Tornou-se obrigatório para uma classe de modelos porque não é possível detectar abuso distribuído por várias requisições quando os dados já foram excluídos. Para a maioria das equipes, o impacto de engenharia é nulo, e o impacto de governança se resume a um parágrafo na avaliação do fornecedor.

Para organizações cuja conformidade pressupunha retenção zero, como BAAs limitados a ZDR, avisos de privacidade que afirmam que nada persiste e produtos infantis baseados em minimização de dados, o Fable 5 marca o fim de uma garantia uniforme entre modelos. A solução não é evitar o modelo. É tratar a classe de retenção como uma entrada explícita por modelo nas decisões de roteamento, assim como preço e janela de contexto.

Perguntas frequentes

Posso usar Claude Fable 5 sob um acordo de retenção zero de dados? Não. Fable 5 e Mythos 5 são Modelos Abrangidos que exigem retenção por 30 dias. Organizações com ZDR recebem 400 invalid_request_error, a menos que ativem a retenção de 30 dias em um workspace e direcionem o tráfego do Fable 5 para ele.

Usar AWS Bedrock, Vertex AI ou Microsoft Foundry evita essa exigência? Não. Cada plataforma condiciona o acesso ao modelo à sua própria configuração de retenção: provider_data_share no Bedrock, compartilhamento de dados com a Anthropic e aceite dos termos do Model Garden no Vertex, e aceite dos termos da Anthropic no deployment do Foundry, onde a Anthropic, não a Microsoft, atua como operadora dos dados. Os acordos de ZDR existentes não se aplicam em nenhuma dessas plataformas.

Meus usuários finais podem recusar a retenção? Não. Não há mecanismo de opt-out. O controle disponível é o roteamento: envie os usuários que recusarem o compartilhamento de dados para modelos compatíveis com ZDR. Não disponibilize um toggle de preferência que não altere nada.

Os dados retidos são usados para treinar modelos? A Anthropic afirma que os dados retidos nunca são usados para treinamento sem autorização expressa. A finalidade é a revisão de trust and safety: análise automatizada, com conversas sinalizadas acessíveis apenas a pessoas autorizadas que não podem exportar os dados, e todos os acessos registrados em logs invioláveis.

A retenção de 30 dias muda o funcionamento do prompt cache? Não. As entradas de cache seguem seus próprios TTLs curtos (5 minutos ou 1 hora), e o contrato de cache do Fable 5 não mudou. Veja nossa avaliação prática. A janela de 30 dias é uma retenção separada e paralela para revisão de segurança.

Leitura relacionada: o guia completo de prompt cache explica os mecanismos de cache que interagem com as políticas de retenção, e a página de preços das plataformas lista o custo de cada modelo segundo o preço de tabela do provedor.

Fontes

• Anthropic — API e retenção de dados
• Anthropic — Modelos Abrangidos
• Anthropic — Práticas de retenção de dados para modelos da classe Mythos
• AWS — Retenção de dados no Amazon Bedrock
• Google Cloud — Claude Fable 5 (modelos de parceiros)
• Google Cloud — Governança de dados do Vertex AI
• Microsoft — Claude no Foundry: dados, privacidade e segurança
• OpenAI — Privacidade empresarial
• OpenAI — BAA para serviços de API
• FTC — Alterações à COPPA Rule (comunicado à imprensa)
• Federal Register — Regra de proteção à privacidade infantil online

Tudo foi verificado em 2026-06-12. Políticas mudam; consulte os documentos atuais e seus próprios contratos. Este texto não é uma orientação jurídica.

← Voltar ao blog