Retenção de 30 Dias do Claude Fable 5: ZDR, HIPAA, COPPA

Se a sua organização executa o Claude sob um acordo de retenção zero de dados (ZDR), sua primeira requisição ao claude-fable-5 não retornou uma resposta. Retornou 400 invalid_request_error. Isso não é uma falha — é política. O Fable 5 é o primeiro modelo Claude geralmente disponível que não pode ser usado sem retenção de dados de 30 dias, e o requisito acompanha o modelo em todas as plataformas: a API do Claude, AWS Bedrock, Google Vertex AI e Microsoft Foundry exigem, cada uma, uma aceitação explícita de retenção.

Para equipes que tratavam “não retemos seus dados” como uma propriedade consolidada de sua stack de LLM, isso é um evento arquitetural. Este post aborda o que a política diz, por que a janela existe, como cada nuvem a implementa e o que ela muda para produtos de consumo e setores com dados sensíveis.

Os detalhes da política foram verificados na documentação publicada pela Anthropic, AWS, Google e Microsoft em 12/06/2026. As políticas mudam; verifique nas fontes primárias vinculadas e em seus próprios contratos. Este é um panorama de engenharia, não um aconselhamento jurídico.

O que a política realmente diz

A Anthropic designa o Claude Fable 5 e o Claude Mythos 5 como Modelos Cobertos. De acordo com a documentação de retenção de dados da API e o artigo sobre práticas de retenção para modelos da classe Mythos (vigente a partir de 09/06/2026):

• Prompts e respostas são retidos por 30 dias, depois excluídos automaticamente — salvo se sinalizados para uma investigação de segurança ativa ou exigidos por lei.
• Não há opção de exclusão. A retenção é uma condição de uso do modelo. Uma requisição de uma organização cuja configuração de retenção não atende ao requisito retorna 400 invalid_request_error.
• O acesso é restrito por design. Sistemas automatizados de segurança examinam os dados; apenas um pequeno grupo de pessoal aprovado pode revisar conversas sinalizadas, sem poder exportar, copiar ou baixá-las, e cada acesso fica registrado em logs à prova de adulteração.
• Acordos ZDR existentes não se estendem ao tráfego de Modelos Cobertos — inclusive por meio de plataformas de nuvem.

Os planos de consumo (Claude Free/Pro/Max) não são afetados — eles já operam sob seus próprios termos de retenção. Esta política tem como alvo a superfície da API comercial, exatamente onde as promessas de “nunca retemos” costumam existir.

Por que existe uma janela de 30 dias

A justificativa no artigo sobre Modelos Cobertos é específica: esses modelos possuem capacidades substancialmente avançadas em engenharia de software, fluxos de trabalho agênticos e cibersegurança, e “algumas formas de uso indevido só se tornam detectáveis ao longo de muitas requisições.” Os exemplos citados — jailbreaking best-of-N, espionagem patrocinada por estados — são padrões de ataque em que cada prompt parece benigno e apenas a sequência é diagnóstica. Não é possível detectar uma sequência que foi excluída.

Duas coisas que a janela não é:

• Não são dados de treinamento. A Anthropic declara que os dados retidos nunca são usados para treinamento sem permissão expressa. O propósito é a detecção de abusos, ponto final.
• Não é nova em natureza — é nova em obrigatoriedade. Uma janela de monitoramento de abusos de ~30 dias tem sido 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 aprovação para monitoramento de abusos modificado. O que mudou é que a janela se tornou não negociável para uma classe de modelo — anteriormente, todos os provedores ofereciam uma saída de retenção zero.

Uma ressalva pré-existente que surpreende as pessoas: mesmo sob ZDR, a Anthropic retém os resultados dos classificadores de segurança, e conteúdo sinalizado por violações da Política de Uso pode ser mantido por até 2 anos. Retenção zero de dados nunca significou zero dados — significa zero retenção de conteúdo não sinalizado no caminho normal.

Mesmo requisito, três nuvens, três mecanismos

A retenção se aplica onde quer que o modelo seja executado, mas cada plataforma implementa o opt-in de forma diferente — e essas diferenças determinam quem processa seus dados e onde ficam seus controles.

AWS Bedrock é o mais explícito. A retenção de dados é um modo configurável (default / provider_data_share / none), resolvido na ordem projeto → conta → padrão do modelo. O Fable 5 declara allowed_modes: ["provider_data_share"]: prompts e completions 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 modelos anteriores ao Fable 5, e um SCP na chave de condição bedrock:DataRetentionMode pode impor sua postura em toda a organização — ninguém altera silenciosamente a conta para experimentar o novo modelo. Observação: com inferência entre regiões, a cópia retida fica na região de destino, o que importa se você possui compromissos de residência de dados.

Google Vertex AI condiciona o modelo a uma configuração de compartilhamento de dados com a Anthropic no nível do projeto (setPublisherModelConfig com dataSharingEnabledProvider: "anthropic") mais a aceitação dos termos no Model Garden, conforme a documentação do Fable 5 do Google. O tratamento geral de dados segue a política de governança de dados do Vertex AI; para cargas de trabalho sensíveis à residência, os endpoints regionais e multirregionais do Vertex controlam onde a inferência é executada — o que agora inclui onde a cópia retida fica armazenada.

Microsoft Foundry é estruturalmente diferente. A documentação de dados e privacidade da Microsoft é explícita ao afirmar que os modelos Claude são serviços de marketplace de terceiros: você aceita os termos da Anthropic na implantação, e a Anthropic — não a Microsoft — é a processadora de dados. Os programas ZDR e de monitoramento de uso modificado do Azure OpenAI não se estendem às implantações do Claude. Organizações com posturas ZDR em outros serviços geralmente isolam o uso de Covered Models em uma assinatura dedicada, tornando o limite de retenção estrutural em vez de procedural.

O padrão em todas as três plataformas: a classe de retenção tornou-se um atributo de modelo de primeira classe e legível por máquina — um modo, um sinalizador, uma barreira de termos — em vez de um parágrafo em um contrato. Sua infraestrutura agora pode impor sua postura de dados, e deveria fazê-lo.

O que isso significa para implantações empresariais

Sem um acordo ZDR, nada muda mecanicamente — você já estava em uma postura de estilo de 30 dias, possivelmente sem perceber. O trabalho consiste em tornar isso explícito na documentação do seu fornecedor.

Com um acordo ZDR, você tem três opções:

1. Ignorar os Covered Models. O ZDR permanece uniforme; você abre mão do modelo. Viável se suas cargas de trabalho não precisarem dele — consulte nossa avaliação detalhada do Fable 5 para entender o que isso custa e onde ele se diferencia.
2. Dividir por workspace ou projeto. Todas as plataformas suportam um opt-in com escopo definido: um workspace dedicado na Claude API (Console → Settings → Workspaces → Privacy controls), um projeto no Bedrock com provider_data_share, um projeto separado no Vertex ou uma assinatura dedicada no Azure. Direcione apenas cargas de trabalho tolerantes à retenção para esse escopo.
3. Aceitar a retenção em toda a organização. A opção mais simples de operar, mas que silenciosamente rebaixa a garantia para todas as cargas de trabalho — incluindo aquelas cuja sensibilidade justificou o ZDR. Essa é uma decisão para o responsável pela proteção de dados, não uma simples mudança de configuração.

Independentemente do provedor: seus próprios logs são uma segunda superfície de retenção. Se seu gateway ou stack de observabilidade registra prompts completos, você está operando uma janela mais longa do que a do seu provedor, sob sua própria responsabilidade. As garantias do provedor só são tão significativas quanto a camada à frente delas — a mesma lógica de auditoria que aplicamos às afirmações de cache se aplica aqui.

O que isso significa para produtos voltados ao consumidor

Se você atende consumidores e roteia o conteúdo deles por meio de um Modelo Coberto, a mudança se propaga para a sua própria superfície jurídica — com ou sem acordo ZDR. Três consequências concretas:

1. Seu aviso de privacidade provavelmente precisa de atualização. A maioria dos regimes exige a divulgação da retenção, não apenas da coleta: o Artigo 13(2)(a) do GDPR exige o período de armazenamento (ou os critérios) no momento da coleta; a CPRA da Califórnia exige que o aviso no momento da coleta informe a retenção por categoria de informação pessoal. Se o seu aviso afirma — ou implica — que os dados de conversas não são retidos em lugar algum, uma cópia mantida por um processador por 30 dias o torna incorreto. Atualize o aviso, os registros de tratamento e o inventário de DPA.

2. Você não pode oferecer aos usuários uma opção de recusa que você não possui. A retenção não tem mecanismo de exceção, portanto não há nenhum controle que você possa criar para isentar os prompts de um usuário enquanto ainda usa esse modelo. A alavanca que você realmente possui é o roteamento: um gateway com consciência de consentimento envia os usuários que recusam o compartilhamento de dados para modelos elegíveis ao ZDR e todos os demais para o Modelo Coberto — uma restrição legal transformada em uma regra de roteamento comum. Muito melhor do que uma caixa de preferência que não faz nada.

3. As solicitações de exclusão precisam de uma infraestrutura precisa. As obrigações de apagamento (Art. 17 do GDPR, exclusão pela CPRA e equivalentes) se estendem aos processadores. Uma janela delimitada com exclusão automática em 30 dias é geralmente uma postura defensável para um processador — mas o seu manual de DSAR deve declarar isso, e não prometer exclusão imediata downstream que você não consegue executar.

A dimensão global agrava a situação: a mesma lógica de divulgação e processador aparece no UK GDPR, na LGPD do Brasil e na crescente família de leis estaduais de privacidade dos EUA. Para usuários na China, a PIPL acrescenta duas arestas mais afiadas — fornecer informações pessoais a outro processador geralmente requer consentimento separado, e rotear o conteúdo de usuários chineses para um endpoint de LLM no exterior constitui uma transferência transfronteiriça que exige um mecanismo reconhecido (avaliação de segurança, contrato padrão ou certificação). Uma atualização de modelo que altera quem retém o quê, onde e por quanto tempo é exatamente o tipo de mudança que esses frameworks esperam que você refaça a documentação.

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

Para a maioria dos produtos, a janela do provedor é um problema de documentação. Para setores cujos dados são em si regulamentados, é um problema de arquitetura: a cópia retida é dado regulamentado em repouso em um fornecedor, e as regras setoriais regem exatamente isso.

Saúde (HIPAA)

O HIPAA não exige retenção zero — exige que qualquer fornecedor que detenha informações de saúde protegidas o faça sob um Acordo de Associado de Negócios (BAA) com salvaguardas adequadas. A cópia de 30 dias dos seus prompts é PHI em repouso em um associado de negócios; a questão é se o seu BAA a cobre. Os dois principais fornecedores de API estruturam isso de forma diferente, e a diferença agora importa: o acesso à API com conformidade HIPAA da Anthropic explicitamente não exige ZDR — é construído sobre retenção com salvaguardas (criptografia, controles de acesso, registro de auditoria, restrições de funcionalidades aplicadas). O BAA da API da OpenAI cobre endpoints elegíveis para retenção zero de dados — e um BAA com escopo para endpoints ZDR estruturalmente não pode cobrir um modelo que exige retenção.

A classe de retenção de um modelo é agora uma questão de elegibilidade para BAA. Confirme por escrito que o seu BAA cobre o modelo específico antes de rotear PHI para ele — e lembre-se de que a cadeia muda nas nuvens: no Bedrock, a plataforma é o seu associado de negócios; no Foundry, a Anthropic processa os dados diretamente. Um ponto crítico: PHI nunca deve aparecer em definições de esquema JSON para saídas estruturadas — esquemas em cache não recebem as mesmas proteções que o conteúdo das mensagens.

Produtos para crianças (COPPA)

O momento é delicado: a Regra COPPA emendada da FTC entrou em vigor em 23 de junho de 2025, com conformidade na maioria das disposições prevista para 22 de abril de 2026 — o primeiro modelo com retenção obrigatória pelo provedor chegou exatamente quando os operadores terminavam de implementar as novas obrigações de retenção. Duas delas interagem diretamente com a janela de 30 dias: uma política de retenção de dados escrita e pública é agora obrigatória (§312.10) — quais dados de crianças são coletados, por quê e quando são excluídos — e a retenção indefinida é proibida, com retenção limitada ao que for razoavelmente necessário para a finalidade de coleta.

Uma janela delimitada de 30 dias com exclusão automática tem a forma compatível — mas o provedor retém para sua finalidade de confiança e segurança, não para a finalidade pela qual você coletou os dados da criança, e o seu aviso deve descrever com precisão o relacionamento com o processador. Para produtos direcionados a crianças que adotaram ZDR especificamente para minimizar o rastro de dados, a resposta de roteamento se aplica com stakes mais altos: o tráfego de crianças permanece em modelos elegíveis para ZDR, ou a janela do Covered Model entra primeiro na sua política §312.10.

O mesmo padrão em outros setores

Uma vez que você enxerga a estrutura — dado regulamentado, cópia retida em um fornecedor, regra setorial governando a retenção — ela se repete:

• Biometria (Illinois BIPA): os operadores precisam de um cronograma de retenção escrito e publicamente disponível, além de diretrizes de destruição para dados biométricos. A cópia de 30 dias de prompts contendo identificadores biométricos pertence a esse cronograma.
• Pagamentos (PCI DSS / GLBA): o PCI DSS proíbe o armazenamento de dados de autenticação sensíveis após a autorização — em qualquer lugar. Dados de cartão colados em um prompt tornam-se dados de cartão retidos em um provedor por 30 dias. A resposta limpa é a redação upstream, não a burocracia downstream.
• Educação (FERPA): fornecedores que lidam com registros de estudantes sob a exceção de funcionário escolar devem permanecer sob o controle direto da escola. Uma cópia de retenção de segurança que a escola não pode acessar nem excluir antecipadamente se encaixa mal nesse padrão — uma questão para assessoria jurídica antes que o tráfego de EdTech chegue a um Covered Model.
• Serviços financeiros — a inversão (SEC/FINRA): corretoras devem reter comunicações comerciais sob as regras de livros e registros. Para elas, a janela do provedor não é o problema; capturar sua própria cópia em conformidade é. A mesma questão de retenção, com sinal oposto.

O fio condutor: as regras setoriais regulamentam a retenção em ambas as direções, e uma janela no lado do provedor que você não controla deve ser mapeada para qualquer direção que o seu setor aponte.

Uma lista de verificação para decisões

• ✅ Faça um inventário de quais modelos o seu tráfego realmente toca. A classe de retenção é agora um atributo por modelo, não por provedor.
• ✅ Se você tem ZDR: decida deliberadamente — ignore os Covered Models, divida por workspace/projeto/assinatura, ou aceite a retenção em toda a organização. Não deixe isso acontecer implicitamente.
• ✅ Aplique a postura na infraestrutura — SCPs do Bedrock, controles de privacidade de workspace, projetos de nuvem separados — não em uma página de wiki.
• ✅ B2C: atualize os avisos de privacidade e os playbooks de DSAR; roteie usuários que não consentiram para modelos elegíveis para ZDR em vez de construir opt-outs que não podem funcionar.
• ✅ Dados regulamentados: confirme a cobertura por modelo, por escrito — BAA para PHI, política §312.10 para dados de crianças, cronogramas de retenção para biometria — antes de rotear esses dados para um modelo com retenção obrigatória.
• ✅ Audite seus próprios logs. A janela de 30 dias de um provedor é irrelevante se o seu gateway registra prompts indefinidamente.

Conclusão

A janela de 30 dias vinculada ao Fable 5 não é uma coleta de dados — é um monitoramento de uso indevido com escopo limitado e finalidade específica, consistente com o que a maior parte do setor já faz por padrão, tornada obrigatória para uma classe de modelos porque a detecção de uso indevido entre requisições não funciona com dados excluídos. Para a maioria das equipes, o impacto de engenharia é zero e o impacto de governança é um parágrafo em uma revisão de fornecedor.

Mas para organizações cuja posição de conformidade pressupunha retenção zero — BAAs com escopo ZDR, avisos de privacidade que afirmam que nada persiste, produtos infantis construídos sobre minimização de dados — o Fable 5 é o momento em que essa premissa deixou de ser uniforme entre os modelos. A solução não é evitar o modelo. É tornar a classe de retenção um insumo explícito e por modelo nas decisões de roteamento, da mesma forma que você já trata preço e janela de contexto.

Perguntas Frequentes

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

Usar AWS Bedrock, Vertex AI ou Microsoft Foundry evita o requisito? Não. Cada plataforma condiciona o acesso ao modelo à aceitação de sua própria política de retenção: provider_data_share no Bedrock, compartilhamento de dados com a Anthropic mais os termos do Model Garden no Vertex, e os termos da Anthropic no momento da implantação no Foundry (onde a Anthropic, e não a Microsoft, é a processadora de dados). Acordos ZDR existentes não são transferidos em nenhuma delas.

Meus usuários finais podem recusar a retenção? Não — não existe mecanismo de recusa. O controle que você possui é o roteamento: envie usuários que recusem o compartilhamento de dados para modelos elegíveis ao ZDR. Não implemente um botão de preferência que não muda nada.

Os dados retidos são usados para treinar modelos? A Anthropic declara que os dados retidos nunca são usados para treinamento sem permissão expressa. A finalidade é a revisão de confiança e segurança: triagem automatizada, com conversas sinalizadas revisáveis apenas por pessoal aprovado que não pode exportar os dados, sob registros de acesso à prova de adulteração.

A retenção de 30 dias altera o funcionamento do cache de prompts? Não. As entradas de cache seguem seus próprios TTLs curtos (5 minutos ou 1 hora) e o contrato de cache no Fable 5 permanece inalterado — veja nossa avaliação detalhada. A janela de 30 dias é uma retenção separada e paralela para revisão de segurança.

Fontes

• 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

Todos verificados em 2026-06-12. As políticas mudam — verifique os documentos atuais e seus próprios contratos. Não constitui aconselhamento jurídico.

← Voltar ao blog