# Fable 5.1 no Bedrock: retenção de dados virou decisão de arquitetura

Claude Fable 5.1 chegou ao Bedrock em 1º de setembro de 2026 com 1M de contexto e uma condição que nenhum modelo anterior da Anthropic tinha: você precisa autorizar explicitamente a retenção de prompts e saídas por até 30 dias dentro da AWS. Isso não é uma caixinha de consentimento, é uma configuração de conta com raio de alcance organizacional, que colide com o SCP de zero data retention que a maioria dos ambientes regulados já tem escrito.

- URL: https://fernando.moretes.com/blog/fable-5-1-no-bedrock-retencao-de-dados-virou-decisao-de-arquitetura-aws-weekly-r

- Markdown: https://fernando.moretes.com/blog/fable-5-1-no-bedrock-retencao-de-dados-virou-decisao-de-arquitetura-aws-weekly-r/article.md?lang=pt

- Published: 2026-09-08T10:16:18.030Z

- Category: IA & Agentes

- Tags: bedrock, anthropic, governance, data-residency, iam, scp, finops, llmops

- Reading time: 8 min

- Source: [AWS Weekly Roundup: Claude Fable 5.1 on AWS, Amazon Linux 2027 preview, AWS Certified AI Business Strategist, and more (September 7, 2026)](https://aws.amazon.com/blogs/aws/aws-weekly-roundup-claude-fable-5-1-on-aws-amazon-linux-2027-preview-aws-certified-ai-business-strategist-and-more-september-7-2026/)

---

O AWS Weekly Roundup de 7 de setembro tratou o Claude Fable 5.1 como mais um lançamento de modelo entre EC2 R9g e Amazon Linux 2027. Não é. Pela primeira vez num modelo de fronteira no Bedrock, a chave que libera o acesso não está no IAM nem no Marketplace, está numa configuração de retenção de dados no escopo da conta, que você precisa ligar via API porque não existe UI no console. Passei a semana lendo a documentação de `data-retention` e `abuse-detection` linha por linha e a conclusão é desconfortável para quem opera em ambiente regulado: habilitar o Fable 5.1 é uma decisão de landing zone, não de time de produto.

## O que mudou de fato, e o que não mudou

O Bedrock sempre se vendeu com dois modelos de segurança: **zero operator access** (nenhum operador do serviço lê entrada ou saída) e **zero data retention** por padrão. A documentação de abuse detection continua afirmando os dois. O que a Anthropic introduziu com a categoria **Covered Model** é uma exceção nomeada: para Claude Fable 5 e Fable 5.1, *todo* o tráfego é retido por até 30 dias para detecção automatizada de abuso offline, e o tráfego marcado por classificador fica sujeito a revisão humana feita pela AWS.

Duas coisas que não mudaram e que valem repetir porque a leitura apressada erra as duas. Primeiro: **seu conteúdo não vai para a Anthropic.** O modo `provider_data_share` é legado e a própria doc diz que compartilhamento com provedor de modelo não é suportado hoje, ele concede uma permissão que ninguém exerce. Segundo: **nada muda para os modelos Claude anteriores ao Fable 5.** A doc é explícita nisso, e o mecanismo é elegante: cada modelo declara seus `allowed_modes`, então uma conta em `aws_review` que também chama Opus 4.8 não passa a reter nada do Opus, o Opus permite `none`, e `none` vence para ele.

O ponto de atrito não é o que a AWS faz com o dado. É que a autorização para ela fazer isso mora num escopo que a maioria dos times não controla.

## Como o modo efetivo é resolvido e onde o modelo é bloqueado

A resolução é hierárquica: o primeiro escopo cujo valor não é `inherit` vence. Se o modo efetivo ficar abaixo do mínimo que o modelo exige, o modelo aparece como `status: "unavailable"` na listagem, não é erro de permissão, é o modelo sumindo do catálogo.

### 🔐 Governança, o que a organização permite

- SCP Deny em bedrock:DataRetentionMode (security)
- IAM PutAccountDataRetention · UpdateProject (security)

### 🟧 AWS, resolução do modo efetivo

- Projeto mais específico · pode ser inherit (compute)
- Conta PUT /v1/data_retention (compute)
- Padrão do modelo somente leitura (data)

### 🤖 Bedrock, a trava de disponibilidade

- allowed_modes none < default < aws_review < provider_data_share (ai)
- Claude Fable 5.1 exige aws_review ou superior (ai)
- status: unavailable status_reason explica o motivo (external)

### 📦 Fronteira de retenção: 30 dias dentro da AWS

- Prompts e saídas até 30 dias · região de destino do CRIS (storage)
- Detecção de abuso offline automatizada · todo o tráfego (security)
- Revisão humana pela AWS só tráfego marcado por classificador (security)
- Enterprise Frontier Safeguards ZDR até 31/12/2026 (security)

### Fluxos

- scp -> acct: limita quais modos podem ser escritos
- iam -> proj: quem pode alterar o escopo
- proj -> acct: se inherit, delega
- acct -> mdef: se inherit, delega
- acct -> gate: modo efetivo
- app -> gate: chamada de inferência
- gate -> fable: modo ≥ aws_review
- gate -> unavail: modo none ou default
- fable -> store: grava entrada e saída
- store -> auto: varre todo o volume
- auto -> human: escala o que o classificador marca
- efs -> store: suspende a retenção enquanto elegível

## Os quatro modos, e o que cada um custa em governança
| Modo | O que acontece com o dado | Fable 5.1 funciona? |
| --- | --- | --- |
| `none` | Zero retenção. Nada vai para armazenamento durável. Na Responses API, `store=true` é rejeitado. | Não, a requisição é bloqueada. |
| `default` | Vale a política do próprio modelo. Se antes era ZDR, continua ZDR. `store=false` não garante retenção zero. | Não, aparece como `unavailable`. |
| `aws_review` | Retenção por até 30 dias dentro da fronteira AWS; a AWS pode revisar. O provedor não recebe nada. | Sim, é o mínimo exigido. |
| `provider_data_share` (legado) | Tratamento idêntico ao `aws_review` na prática: compartilhamento com provedor não é suportado hoje. | Sim, está acima na ordenação e já satisfaz. |
| `inherit` | Sem opinião naquele escopo; delega para o escopo mais amplo. É o padrão de contas e projetos novos. | Depende do que estiver acima. |

## A conta virou o limite de isolamento, e o seu SCP já disse não

Se você trabalha com BACEN 4.893, PCI-DSS ou LGPD, há uma chance alta de já existir na sua organização um SCP negando qualquer coisa que grave prompt em armazenamento durável. A doc do Bedrock inclusive publica esse SCP como exemplo, negando `bedrock-mantle:PutAccountDataRetention` quando `bedrock-mantle:DataRetentionMode` for diferente de `none`. Esse SCP está certo, e ele torna o Fable 5.1 permanentemente indisponível na OU inteira.

O que me incomoda não é a trava; é a granularidade. O modo é resolvido em **projeto → conta → padrão do modelo**, e o único comando prático hoje é `aws bedrock put-account-data-retention --mode aws_review`, que vale para a conta toda. Ligar o Fable 5.1 na conta de produção compartilhada autoriza revisão humana da AWS sobre *toda* carga que rodar num modelo que exija revisão, para sempre, até alguém lembrar de desligar. O escopo de projeto existe justamente para evitar isso, e é a única razão pela qual eu consideraria habilitar sem criar conta nova.

A recomendação prática inverte o instinto: **não peça exceção no SCP, peça uma conta.** Uma conta dedicada, dentro de uma OU própria com SCP que permita `aws_review` e nada além disso, dá raio de alcance nomeado, fatura separada e uma resposta de auditoria de uma linha. Exceção em SCP de OU de produção é dívida que ninguém audita depois.

## Residência de dados: fora dos EUA, o perfil Global não é escolha

Esta é a parte que passou batido em toda cobertura que li, e é a mais séria para quem opera no Brasil ou na Europa. O model card do Fable 5.1 traz o endpoint `bedrock-runtime` com **In-Region não suportado em nenhuma região do mundo**. O perfil Geo (`us.anthropic.claude-fable-5-1`) existe só nos EUA, Canadá e GovCloud. Em `sa-east-1`, `eu-central-1`, `eu-west-1` e todo o resto, a única porta aberta é o perfil Global: `global.anthropic.claude-fable-5-1`, que roteia a inferência para qualquer lugar do mundo.

Agora junte com a frase da doc de abuse detection: se inferência cross-region está habilitada, entradas e saídas retidas são armazenadas **na região de destino**, isto é, onde o pedido foi processado. Some as duas e o resultado é direto: um banco em São Paulo que chame Fable 5.1 está autorizando a retenção de prompts por 30 dias numa região que ele não escolheu e não consegue prever por requisição. Isso não é um detalhe de latência, é uma afirmação de residência de dados que precisa entrar no RIPD antes de qualquer prova de conceito.

O caminho para quem tem restrição de residência é curto e nenhum é gratuito: rodar via Geo dos EUA e classificar o dado como transferido, negociar elegibilidade ao Enterprise Frontier Safeguards enquanto ele oferece ZDR, ou aceitar que o Fable 5.1 fica fora do escopo regulado e sobra para carga sem dado pessoal, geração de código sobre repositório interno, por exemplo.

## Playbook para amanhã de manhã

1. **Descubra em que modo suas contas já estão**: Antes de discutir qualquer coisa, rode `GET /v1/data_retention` em cada conta com Bedrock. Contas antigas configuradas em `provider_data_share` já estão acima de `aws_review` na ordenação, elas ganham acesso ao Fable 5.1 sem que ninguém tenha aprovado nada. Essa é a descoberta que costuma mudar a reunião.

2. **Escolha o escopo antes do modo**: Projeto vence conta, e conta vence o padrão do modelo. Se você precisa de um piloto, configure `data_retention` no projeto via `POST /v1/organization/projects/{project_id}` e deixe a conta em `inherit` ou `none`. Nunca comece pela conta.

3. **Escreva o SCP antes de ligar o modo**: A chave de condição `bedrock:DataRetentionMode` (e `bedrock-mantle:DataRetentionMode`) existe justamente para isso. Um SCP que permite `aws_review` e nega `provider_data_share` impede que alguém escale de volta para o modo legado por hábito.

4. **Fixe o perfil de inferência no código**: Não existe endpoint In-Region. Escolha explicitamente entre `us.anthropic.claude-fable-5-1` e `global.anthropic.claude-fable-5-1` e documente a razão junto do dado que trafega. Deixar isso para uma variável de ambiente sem dono é como o roteamento global entra em produção sem revisão.

5. **Ajuste os parâmetros de amostragem antes do primeiro deploy**: `temperature` deve ser 1.0 ou ausente, `top_p` 1.0 ou 0.99, os dois não podem vir juntos e `top_k` não é suportado. Um wrapper que copia os parâmetros do Sonnet quebra na primeira chamada, e quebra em produção, não no teste unitário que mocka o cliente.

6. **Trate `stop_reason: "refusal"` como caminho primário**: O modelo devolve HTTP 200 com `stop_reason: "refusal"` e um objeto `stop_details` com a categoria. A doc avisa que a taxa de recusa é materialmente maior que nos Claude anteriores. Código que só olha status HTTP vai entregar resposta vazia ao usuário sem registrar nada.

7. **Ponha 31/12/2026 no calendário**: Quem for elegível ao Enterprise Frontier Safeguards recebe ZDR **até 31 de dezembro de 2026**. Depois disso, todo o tráfego volta a ser retido por até 30 dias para detecção automatizada de abuso. Se a sua aprovação de compliance depende do ZDR, ela tem prazo de validade.

> **O checkpoint de cache que falha em silêncio:** O prompt caching do Fable 5.1 aceita no máximo 4 checkpoints por requisição, com TTL de 5 minutos ou 1 hora, nos campos `system`, `messages` e `tools`. O detalhe caro: o mínimo é **512 tokens por checkpoint**, e abaixo disso o cache é desabilitado sem erro nenhum, a resposta volta normal, com contadores de cache em zero. Num agente que roda por horas, isso é a diferença entre reaproveitar o prompt de sistema e pagar por ele a cada passo. Instrumente `cacheReadInputTokens` e `cacheWriteInputTokens` como métrica de primeira classe no CloudWatch, não como campo de log: sem alarme, um refactor que encurtou o system prompt em 40 tokens some no ruído e aparece só na fatura.

## O custo real: pensamento adaptativo, recusa faturada e um endpoint sem guardrails

O raciocínio adaptativo do Fable 5.1 está **sempre ligado e não pode ser desativado**; o que você controla é o nível de esforço: `low`, `medium`, `high`, `xhigh`, `max`, com padrão `high`. Um teste público via Converse com `{"output_config":{"effort":"max"}}` mostrou o salto: 410 thinking tokens contra zero na chamada padrão, e latência subindo de ~8,3s para ~13,7s. Thinking token é token de saída faturado. Um `effort` mal calibrado num loop de agente não aumenta a conta em 10%, aumenta em múltiplos, e a única evidência é o `usage` que ninguém agrega.

O segundo vazamento de custo é a recusa. Recusa em estágio de prompt, bloqueada antes de a inferência começar, não é faturada. Recusa no meio do stream, depois de saída parcial, **é faturada pelos tokens gerados até o bloqueio**. Com uma taxa de recusa materialmente maior por conta dos classificadores de cibersegurança e ciências da vida, um pipeline de análise de vulnerabilidade pode pagar por saída que nunca chegou ao usuário.

E há uma escolha de endpoint que muda a arquitetura inteira: no `bedrock-mantle`, o Fable 5.1 **não suporta Guardrails, Knowledge Bases, Agents nem a Converse API**: só streaming, prompt caching e contagem de tokens. Guardrails do Bedrock só existem pelo `bedrock-runtime`. Quem precisa de filtro de conteúdo próprio sobre o modelo não tem decisão a tomar aqui; `bedrock-runtime` é o único caminho, e é o que a própria doc recomenda para aplicação nova.

## Anti-padrões que já vi nascer nesta primeira semana

- **Ligar `aws_review` na conta de produção compartilhada**: o modo é de conta, não de requisição. Uma linha de CLI autoriza retenção e revisão sobre toda carga futura que rodar em modelo que exija revisão, inclusive as que ainda nem foram escritas.
- **Tratar `provider_data_share` legado como inofensivo porque nada é compartilhado**: ele é o modo *mais permissivo* da ordenação. Uma conta parada nele desde 2024 libera Covered Models sem que ninguém tenha revisado a decisão.
- **Assumir que `global.` é só otimização de latência**: fora dos EUA e do Canadá ele é a única opção, e ele decide em qual região seus prompts ficam retidos por 30 dias. Isso é decisão de residência disfarçada de prefixo de model ID.
- **Reaproveitar o cliente do Sonnet com `temperature: 0.2` e `top_k`**: o Fable 5.1 exige `temperature` 1.0 ou ausente e não suporta `top_k`. Determinismo por temperatura baixa não é uma alavanca disponível aqui; use estrutura de saída e validação.
- **Contar com Guardrails no endpoint `bedrock-mantle`**: não existe ali. Descobrir isso depois que o desenho de segurança foi aprovado custa um redesenho, não um patch.
- **Medir custo sem separar thinking tokens**: o raciocínio não pode ser desligado e o padrão é `high`. Sem `effort` e `usage` como dimensão da sua métrica de custo, você não consegue explicar a fatura nem no dia seguinte.

## Perguntas que apareceram na primeira semana

### Minha conta está em `provider_data_share`. Preciso migrar para usar o Fable 5.1?

Não. Como `provider_data_share` está acima de `aws_review` na ordenação, ele já satisfaz o requisito e nada quebra. Ainda assim vale migrar: `aws_review` descreve o comportamento que de fato acontece, e num relatório de auditoria a diferença entre "autorizamos compartilhamento com o provedor" e "autorizamos revisão pela AWS" é a diferença entre uma pergunta e uma reunião.

### Dá para usar Fable 5.1 mantendo zero data retention?

Só por exceção. O programa Enterprise Frontier Safeguards concede ZDR a clientes elegíveis até 31 de dezembro de 2026, e o roadmap fala em chave gerenciada pelo cliente e bucket próprio para o armazenamento da detecção de abuso. Fora dele, elegibilidade a ZDR para modelos Claude é avaliada por conta e por modelo, e quem decide é a Anthropic, fale com o representante deles, não só com a AWS.

### Onde configuro isso no console?

Em lugar nenhum. A doc diz explicitamente que no lançamento não há UI de console para retenção de dados, só API ou SDK. Na prática isso é bom: obriga a mudança a passar por infraestrutura como código e a deixar rastro no CloudTrail, em vez de virar clique de um engenheiro com acesso ao console.

### Ligar `aws_review` faz meus outros modelos passarem a reter dados?

Não. Cada modelo declara seus `allowed_modes`, e um modelo que aceita `none`: Opus 4.8, por exemplo, não retém nada por mais permissiva que seja a configuração da conta. O modo diz o que você *permite*, não o que acontece. Mesmo assim, prefira isolar por projeto: a auditoria vai perguntar sobre o que foi permitido, não sobre o que aconteceu.

> **O que eu faria na segunda-feira:** Eu não abriria exceção no SCP da OU de produção, abriria uma conta. Uma conta dedicada, OU própria, SCP que permite exatamente `aws_review` e nada acima, `global.anthropic.claude-fable-5-1` fixado no código com um comentário dizendo por quê, e nenhum dado de cliente atravessando. A lição dura por trás disso veio de outro contexto: toda exceção que eu abri em política de OU de produção sobreviveu ao projeto que a justificava e virou permissão órfã que ninguém conseguiu explicar dois anos depois. Conta é revogável, tem fatura própria e responde à auditoria em uma linha. E antes de qualquer piloto eu rodaria `GET /v1/data_retention` em todas as contas com Bedrock, aposto que pelo menos uma já está em `provider_data_share` desde sempre, com acesso a Covered Model que ninguém aprovou.

## Veredito

O Fable 5.1 entrega o que promete no eixo que importa para agente de longa duração: 1M de contexto, 128K de saída, corte de conhecimento em junho de 2026 e esforço de raciocínio configurável em cinco níveis. Se a sua carga é geração e revisão de código sobre repositório interno, sem dado pessoal, adote, numa conta dedicada, com projeto em `aws_review`, perfil de inferência fixado e `stop_reason: "refusal"` tratado como caminho normal. Se a sua carga toca dado de cliente sob LGPD ou BACEN e você está fora dos EUA, o veredito é o oposto e é uma condição, não uma opinião: o único perfil disponível é o Global, a retenção de 30 dias acontece na região onde a inferência cair, e isso precisa estar num relatório de impacto assinado antes da primeira chamada. Não é o modelo que está indisponível para ambiente regulado, é o modo de retenção que ainda não tem a granularidade que ambiente regulado exige. O Enterprise Frontier Safeguards é a ponte, e ela tem data de vencimento: 31 de dezembro de 2026.

**Rating:** Adote com escopo isolado, bloqueado por

## Referências

- [AWS Weekly Roundup: Claude Fable 5.1 on AWS, Amazon Linux 2027 preview, and more (Sept 7, 2026)](https://aws.amazon.com/blogs/aws/aws-weekly-roundup-claude-fable-5-1-on-aws-amazon-linux-2027-preview-aws-certified-ai-business-strategist-and-more-september-7-2026/)
- [Amazon Bedrock User Guide: Data retention (modes, ordering, SCP condition keys)](https://docs.aws.amazon.com/bedrock/latest/userguide/data-retention.html)
- [Amazon Bedrock User Guide: Claude Fable 5.1 model card (context, effort, regions, caching)](https://docs.aws.amazon.com/bedrock/latest/userguide/model-card-anthropic-claude-fable-5-1.html)
- [Amazon Bedrock User Guide: Abuse detection and Enterprise Frontier Safeguards ZDR window](https://docs.aws.amazon.com/bedrock/latest/userguide/abuse-detection.html)
- [Introducing Claude Fable 5.1 on AWS: AWS Artificial Intelligence Blog](https://aws.amazon.com/blogs/machine-learning/introducing-claude-fable-5-1-on-aws/)
- [What's New: Claude Fable 5.1 is now available on AWS](https://aws.amazon.com/about-aws/whats-new/2026/09/claude-fable-5-1-aws/)
- [Anthropic Claude Fable 5 on AWS: Mythos-class capabilities with built-in safeguards](https://aws.amazon.com/blogs/aws/anthropic-claude-fable-5-on-aws-mythos-class-capabilities-with-built-in-safeguards-now-available/)
- [DevelopersIO: Calling Claude Fable 5.1 from the Converse API (effort levels, caching gotchas)](https://dev.classmethod.jp/en/articles/bedrock-claude-fable-5-1-converse/)