Em 9 de junho, a AWS lançou o Claude Fable 5 no Amazon Bedrock e enterrou a verdadeira história para empresas em uma única frase: antes de invocá-lo, você precisa ativar provider_data_share; e, quando faz isso, seus dados saem da fronteira de dados e segurança da AWS (AWS).
Isso não é um pequeno botão de configuração. Isso muda o contrato que muitas equipes achavam que estavam comprando quando escolheram o Bedrock.
A proposta da Anthropic é clara o bastante. Fable 5 é a versão pública, com salvaguardas, do seu novo patamar de capacidade Mythos-class. Ele custa US$ 10 por milhão de tokens de entrada e US$ 50 por milhão de tokens de saída, o dobro do preço atual da API do Opus 4.8, e a Anthropic diz que o modelo foi feito para engenharia de software de longa duração, trabalho de conhecimento, visão e fluxos agentivos (Anthropic, documentação de preços do Claude). Mas o preço que mais importa para empresas sérias não é o preço por token. É o preço de governança.
Em 17 de junho, apareceu mais uma complicação: a Anthropic diz que o acesso ao Fable 5 e ao Mythos 5 foi suspenso em 12 de junho depois de uma diretriz de controle de exportação do governo dos EUA, enquanto todos os outros modelos Claude seguem sem impacto (Anthropic). Essa suspensão pode ser temporária, mas o padrão de governança não é. É assim que o acesso a modelos de fronteira funciona agora: mais capacidade, mais monitoramento, menos promessas simples de privacidade.
As Letras Miúdas Que Mudam a Arquitetura
O post de lançamento da AWS diz que o Claude Fable 5 está disponível no Bedrock em US East, Northern Virginia, e Europe, Stockholm. Ele também diz que não há interface no console para a nova configuração de retenção de dados no lançamento. Você precisa chamar a Data Retention API antes de invocar o modelo.
O post de lançamento mostra o formato da chave:
curl -X PUT https://bedrock.us-east-1.amazonaws.com/data-retention \
-H "Authorization: Bearer <your_bearer_token>" \
-H "Content-Type: application/json" \
-d '{ "mode": "provider_data_share" }'Depois, a AWS explicita o que esse modo significa: o Bedrock pode reter e compartilhar dados de inferência com provedores de modelo de acordo com os requisitos deles; para o Anthropic Fable 5, esses requisitos incluem retenção de entradas e saídas por 30 dias, além de possível revisão humana (AWS).
Isso quebra o modelo mental que muitas equipes de plataforma tinham:
| Rota | Expectativa padrão | Realidade do Fable 5 |
|---|---|---|
| Bedrock com a maioria dos modelos | Entradas/saídas não armazenadas por padrão | Não basta para o Fable 5 |
| Bedrock Fable 5 | Acesso hospedado na AWS ao modelo da Anthropic | É preciso aceitar compartilhamento de dados com o provedor |
| Claude API com ZDR | Sem retenção de prompt/saída para APIs elegíveis | Fable 5 e Mythos 5 não são elegíveis a ZDR |
| Modelos Claude mais antigos | Configurações de retenção existentes continuam | Não afetados pela política de Modelos Cobertos |
A própria documentação de detecção de abuso do Bedrock ainda diz que o Bedrock usa zero acesso de operadores e zero retenção de dados por padrão. Depois lista as exceções. Para Claude Fable 5, entradas e saídas são retidas por até 30 dias, e o uso exige aceitar o compartilhamento do tráfego retido com a Anthropic para detecção de abuso e possível revisão humana (documentação da AWS).
Essa “exceção” é o produto.
Por Que a Anthropic Quer os Dados
O argumento da Anthropic não é absurdo. Ela diz que modelos Mythos-class cruzam limites de capacidade em que o mau uso talvez só fique visível ao observar muitas requisições. Um prompt isolado pode parecer inofensivo. Um padrão de prompts pode parecer busca por jailbreak, destilação, atividade patrocinada por Estado ou extorsão de dados. A Anthropic cita especificamente ataques com múltiplas requisições, como Best-of-N jailbreaking, e diz que a retenção temporária permite que suas salvaguardas “deem zoom out” entre requisições (suporte da Anthropic).
A empresa também diz que os dados retidos não são usados para treinar novos modelos Claude, e que o acesso humano é limitado a casos sinalizados de dano grave ou a solicitações escritas de clientes. Segundo a Anthropic, revisores usam ferramentas que impedem exportação, cópia ou download, com acesso registrado em logs à prova de adulteração. Depois de 30 dias, os dados são apagados, a menos que estejam vinculados a uma investigação de segurança ou exigência legal (suporte da Anthropic).
Esse é um desenho de segurança coerente. Também é uma fronteira empresarial mais fraca do que “seus prompts e saídas não são retidos.”
As duas coisas podem ser verdade. Desenvolvedores costumam falar disso como se um lado necessariamente estivesse mentindo. Esse é o enquadramento errado. O enquadramento melhor é: o sistema de segurança da Anthropic precisa de observabilidade, e a governança empresarial muitas vezes trata observabilidade sobre prompts sensíveis como um novo processador, um novo armazenamento de retenção e uma nova superfície de revisão.
Se você roda um agente de código sobre uma base regulada, seu “prompt” não é uma mensagem de chat. Ele pode incluir arquivos-fonte, stack traces, segredos impressos por acidente em logs, registros de clientes embutidos em fixtures, relatórios de vulnerabilidade, esquemas de banco de dados, URLs internas, fragmentos de políticas IAM e saídas de ferramentas vindas de servidores MCP. Uma transcrição retida por 30 dias não é abstrata. É uma cópia temporária do seu ambiente de engenharia.
A Reação da Comunidade Era Previsível, e Em Grande Parte Correta
A thread no Hacker News foi direto ao ponto. O post destacou a frase da AWS de que aceitar a retenção significa que os dados saem da fronteira da AWS, e reuniu 426 pontos e 254 comentários em poucos dias (Hacker News). O debate não era “o Fable é inteligente?” Era “para que servia o Bedrock, se não para essa fronteira?”
Um comentarista do HN resumiu a dor central das empresas: esses modelos se tornam inutilizáveis em ambientes onde contratos limitam quem pode receber dados de clientes. Outro disse que há pouca razão para usar Bedrock se você não se importa com limites de compartilhamento de dados. Isso é um pouco exagerado; o Bedrock também oferece integração com IAM, cobrança, controles de serviço e operações nativas da AWS. Mas captura a motivação de compra de muitas equipes de plataforma de IA.
O mesmo tema apareceu no r/aws, onde o título do post foi direto: “AWS Bedrock to require sharing data with Anthropic for Mythos and future models.” Um comentarista disse que manter os dados dentro da fronteira de segurança era “a maior parte do sentido” do Bedrock para sua organização; outro disse que os modelos ficaram inutilizáveis para eles (Reddit r/aws).
Também houve uma segunda thread, mais desconfiada: se provedores retêm prompts por 30 dias, o que os impede de treinar com eles? A resposta factual é que a Anthropic diz que não usará esses dados para treinar novos modelos Claude nem para fins que não sejam de segurança (Anthropic). A resposta prática é que empresas reguladas não constroem controles em cima de vibes de fornecedor. Constroem em cima de termos exigíveis, direitos de auditoria, diagramas de fluxo de dados, cronogramas de retenção e procedimentos de incidente.
Essa é a peça que falta em muitos argumentos de fórum. “Eles dizem que não treinam” é relevante. Não é suficiente.
A Antiga Promessa do Bedrock Não Sumiu, Ela Virou Específica Por Modelo
O maior erro que uma equipe empresarial pode cometer agora é tratar “Bedrock” como uma única postura de privacidade.
Para modelos mais antigos e muitas rotas do Bedrock, a postura antiga ainda existe. A AWS diz que o Bedrock não armazena entradas ou saídas de modelo por padrão e usa zero acesso de operadores por padrão (documentação da AWS). A Anthropic diz que outros modelos Claude continuam sob os acordos existentes e as configurações de retenção definidas (suporte da Anthropic).
Fable 5 muda a unidade de governança de “provedor” ou “plataforma” para “classe de modelo.”
Isso significa que seu gateway de IA precisa entender IDs de modelo como objetos de política. global.anthropic.claude-fable-5 não deveria ficar no mesmo bucket de allowlist que Sonnet, Haiku ou Opus. Ele precisa de um rótulo de risco separado, regras de roteamento separadas, logs separados e provavelmente um caminho de aprovação separado.
Uma política empresarial sensata agora se parece com isto:
- Direcione desenvolvedores, por padrão, para modelos que não sejam Modelos Cobertos em tarefas comuns de código e suporte.
- Coloque modelos Fable/Mythos-class atrás de aprovação explícita por projeto.
- Bloqueie prompts que contenham dados regulados, segredos, identificadores de clientes, resultados financeiros não divulgados ou material sujeito a controle de exportação.
- Exija um repositório clean-room ou um conjunto de fixtures sintéticas para execuções de agentes de código com Fable.
- Registre cada invocação com ID do modelo, modo de retenção, classificação de dados, responsável de negócio e ticket.
- Adicione um kill switch que consiga desativar Modelos Cobertos na organização inteira sem esperar cada equipe atualizar código.
Isso é trabalho chato de governança. Também é o que permite às empresas usar modelos poderosos sem fingir que uma transcrição de código retida é inofensiva.
A Troca Real: Capacidade Agora, Fronteiras Limpas Depois
Minha posição: AWS e Anthropic acertaram ao deixar explícita a troca pela retenção, mas Fable 5 não deveria vir habilitado por padrão em ambientes sérios de engenharia.
A transparência é boa. O encaixe do produto é mais estreito do que o hype de lançamento sugere.
Se você está criando um protótipo, migrando uma base open-source, analisando documentos públicos ou rodando um sandbox aprovado por red team, a troca do Fable 5 pode ser razoável quando o acesso voltar. O modelo é caro, mas a pergunta relevante é se ele termina uma tarefa longa com menos ciclos humanos. A Anthropic afirma que Fable 5 se destaca mais em trabalhos longos e complexos, e relatos iniciais de clientes apontam para migrações ambiciosas e execuções agentivas de código (Anthropic).
Se você está trabalhando no motor de transações de um banco, em um pipeline de prontuários médicos, em um repositório de contratada do governo, em design de chip não lançado, em exportações de suporte ao cliente ou em um incidente de produção envolvendo segredos, a resposta padrão deveria ser não. Não “não para sempre.” Não até jurídico, segurança e o dono dos dados aceitarem o novo processador e o novo caminho de retenção.
É aqui que as equipes precisam parar de terceirizar julgamento para a confiança na marca da nuvem. Bedrock não é um envelope mágico de privacidade. É uma plataforma com exceções específicas por modelo. A exceção agora está anexada ao modelo de fronteira que todo mundo quer testar.
A suspensão de 12 de junho da Anthropic deixa isso ainda mais claro. O mesmo modelo que exigia retenção de segurança por 30 dias foi retirado porque o governo dos EUA alegou preocupações de segurança nacional em torno de um possível jailbreak, alegação que a Anthropic contesta (Anthropic). Essa sequência deveria esfriar qualquer reunião de roadmap. Modelos de fronteira já não são apenas dependências. São superfícies de política voláteis.
O Que Equipes de Desenvolvimento Devem Fazer Esta Semana
Comece pelo inventário. Procure IDs de modelo Fable e Mythos no seu código, notebooks, Terraform e documentação interna. Depois, aplique a política na camada de gateway em vez de confiar em cada callsite do SDK.
Se você usa Bedrock, verifique se provider_data_share foi habilitado e quem pode alterar essa configuração. Trate isso como um controle de egresso de dados em produção, não como uma preferência de modelo. Se sua organização tem compromissos contratuais de ZDR, presuma que o Fable 5 está fora do caminho aprovado até o jurídico dizer o contrário.
Para agentes de código, crie um workspace “seguro para fronteira”: sem segredos, sem dados de clientes, sem logs privados de incidente, sem datasets proprietários a menos que estejam explicitamente aprovados. Dê ao modelo um pacote de tarefa estreito, não seu monorepo inteiro mais export do Slack mais console do banco de dados.
Para compras, atualize o questionário. Faça estas perguntas a provedores de modelo e plataformas de nuvem por classe de modelo:
- Prompts e saídas são retidos? Por quanto tempo?
- Quem os armazena, o provedor de nuvem ou o provedor do modelo?
- Humanos podem revisá-los? Sob quais gatilhos?
- Eles são usados para treinamento, ajuste de segurança, avaliação de classificadores ou detecção de abuso?
- Quais logs de auditoria o cliente pode ver?
- O que acontece sob legal hold, investigação de segurança ou ordem governamental?
- O cliente consegue desativar o modelo na organização inteira?
O lançamento do Fable 5 não tornou o Bedrock ruim. Tornou obsoleta a governança preguiçosa de Bedrock.
Essa é a lição útil. O futuro terá mais modelos assim: muito capazes, caros, monitorados e embrulhados em termos especiais. Os vencedores não serão as equipes que banirem todos eles nem as que habilitarem todos às cegas. Os vencedores serão as equipes que rotearem trabalho por sensibilidade, comprovarem para onde os dados foram e reservarem capacidade de fronteira para tarefas que valham o custo de governança.
Leitores que quiserem testar o Claude Fable 5 por conta própria podem usá-lo via Claude Fable 5 on OneHop, um endpoint drop-in com preço cerca de 30% abaixo da tabela. Novas contas podem começar com US$ 10 grátis, sem precisar de cartão.
Leitura complementar: Começando com Claude Fable 5.
