# 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
| Critério | 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/)