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

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.

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.

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.

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.