Por que o controle de retenção de dados no Bedrock ficou mais crítico
Com a chegada de modelos que exigem compartilhamento de dados com provedores terceiros — como o Claude Fable 5 — a AWS reforçou os mecanismos disponíveis para que organizações controlem com precisão o que acontece com seus prompts e respostas após cada chamada de inferência. O Amazon Bedrock já oferecia controle sobre retenção de dados, mas agora a necessidade de aplicar essas políticas de forma centralizada e auditável ficou ainda mais evidente.
Este artigo explica como os modos de retenção funcionam, quais ferramentas estão disponíveis para gerenciá-los e como verificar que as configurações estão funcionando corretamente — informações essenciais para times de segurança e engenharia que operam no Bedrock.
Entendendo os modos de retenção de dados
O Bedrock oferece quatro modos de retenção que determinam o que acontece com os dados após cada requisição de inferência. Consulte a documentação oficial do Amazon Bedrock para verificar quais modelos exigem retenção ou compartilhamento de dados.
- none: Retenção zero. Prompts e respostas são processados e descartados imediatamente. Nenhum dado é compartilhado com o provedor do modelo.
- default: Sem configuração explícita de compartilhamento. Alguns modelos podem reter dados por até 30 dias para verificações de segurança e confiança. Permite APIs que exigem retenção por natureza (como a Batch API e a Responses API com
store=true). Modelos que suportam retenção zero continuam operando sem retenção. - inherit: Sem configuração explícita — herda o modo do escopo superior (projeto herda da conta, conta herda do padrão do serviço). Este é o padrão para novas contas.
- provider_data_share: Dados são compartilhados com o provedor do modelo e retidos por até 30 dias para fins de segurança e confiança.
Nota importante: Para combater a disseminação de material de abuso sexual infantil (CSAM), o Amazon Bedrock usa mecanismos automatizados de identificação nesse tipo de conteúdo nas entradas e saídas dos modelos. Conteúdos sinalizados podem ser armazenados e revisados mesmo quando o modo está configurado como none.
O modo como teto, não como piso
Um conceito fundamental: o modo configurado é o limite máximo de retenção que você aceita, não o que toda requisição vai usar. Configurar uma conta como provider_data_share não significa que todas as requisições passarão a reter e compartilhar dados.
Modelos que suportam retenção zero continuarão operando com retenção zero, independentemente do modo da conta. Pense nisso como um teto de permissões:
- Conta em
provider_data_share+ modelo Claude Sonnet (suportanone) → retenção zero, o Sonnet não exige compartilhamento - Conta em
provider_data_share+ Claude Fable 5 (exigeprovider_data_share) → dados retidos por até 30 dias e possivelmente compartilhados - Conta em
none+ Claude Sonnet → retenção zero - Conta em
none+ Claude Fable 5 → bloqueado; o teto da conta está abaixo do que o modelo exige
Além disso, provider_data_share não é herdado de um modelo — é um opt-in explícito configurado no nível da conta ou do projeto. Se a conta estiver em inherit ou default, nenhum modelo acionará o compartilhamento de dados com o provedor.
Ferramentas disponíveis para gerenciar retenção
A AWS disponibiliza múltiplas camadas de controle que podem ser usadas de forma independente ou combinadas para uma defesa em profundidade:
- Console do Amazon Bedrock: configuração por conta e por região, com visibilidade imediata do modo atual.
- Amazon Bedrock Projects: isolamento de cargas de trabalho com necessidades diferentes de retenção dentro da mesma conta, para modelos compatíveis.
- Políticas de Controle de Serviço (SCPs): aplicação em toda a organização, impedindo qualquer conta de habilitar o compartilhamento de dados.
- Políticas do IAM: controle granular por conta ou por principal, incluindo a conta de gerenciamento (que SCPs não cobrem).
Usando o Amazon Bedrock Projects para controle granular
Nem toda carga de trabalho dentro de uma conta tem os mesmos requisitos de retenção. Com o Amazon Bedrock Projects — disponível no endpoint bedrock-mantle — é possível isolar o tráfego que pode aceitar retenção daquele que não pode, mesmo dentro da mesma conta.
Por exemplo, uma organização pode ter:
- Um projeto de pesquisa onde a equipe precisa de acesso aos modelos mais recentes (incluindo os que exigem
provider_data_share) para experimentação. - Um projeto de produção que lida com dados de clientes onde retenção zero é obrigatória.
Com o Bedrock Projects, é possível configurar provider_data_share no projeto de pesquisa e manter o projeto de produção bloqueado em none. Cada projeto aplica seu próprio teto de retenção de forma independente.
A lógica de resolução do modo efetivo segue a hierarquia: projeto → conta → padrão do serviço. O primeiro valor não-inherit encontrado nessa cadeia é o modo aplicado.
Importante: O Bedrock Projects só está disponível no endpoint bedrock-mantle, com modelos acessados via APIs compatíveis com OpenAI (Responses, Chat Completions) e a API Anthropic Messages no endpoint mantle. Verifique a disponibilidade por modelo e endpoint antes de planejar sua arquitetura.
Isolamento no endpoint bedrock-runtime
Se você usa o endpoint bedrock-runtime (APIs Invoke e Converse), o controle por projeto não está disponível — o modo de retenção da conta se aplica a todas as requisições. Para alcançar isolamento nesse endpoint, a recomendação da AWS é usar contas AWS separadas, organizadas em Unidades Organizacionais (OUs) do AWS Organizations com SCPs aplicadas seletivamente.
Organization Root
├── OU: Zero-Retention (SCP attached — blocks provider_data_share)
│ ├── Account: Production-App-A
│ └── Account: Production-App-B
└── OU: Research (no SCP — allows provider_data_share)
└── Account: ML-ExperimentationUsando SCPs para aplicação em toda a organização
Para organizações que precisam de uma garantia absoluta de que nenhuma conta pode habilitar o compartilhamento de dados — independentemente de quem tem acesso administrativo — as SCPs oferecem o mecanismo de aplicação mais forte.
Uma SCP é uma barreira definida no nível organizacional. Ela se sobrepõe a todos os principais da organização, incluindo administradores de conta e usuários root. Mesmo com permissões de administrador completo, um deny de SCP não pode ser sobrescrito por uma política do AWS Identity and Access Management (IAM).
As SCPs cobrem tanto o plano de controle do Amazon Bedrock (bedrock:PutAccountDataRetention) quanto o endpoint mantle (bedrock-mantle:PutAccountDataRetention, bedrock-mantle:CreateProject, bedrock-mantle:UpdateProject).
A política SCP para retenção zero
Atenção: Novas contas têm o modo padrão inherit, não none. Antes de anexar a SCP, é necessário configurar explicitamente cada conta para none:
aws bedrock put-account-data-retention --region us-east-1 --mode nonePara centenas ou milhares de contas, consulte o artigo do AWS re:Post Automate Bedrock Zero Data Retention Across All Accounts in Your Organization para aprender como escalar esse processo.
A política SCP que restringe a retenção somente ao modo none:
{
"Version": "2012-10-17",
"Statement": [
{
"Sid": "RESTRICTBEDROCKDATARETENTION",
"Effect": "Deny",
"Action": [
"bedrock:PutAccountDataRetention"
],
"Resource": "*",
"Condition": {
"StringNotEquals": {
"bedrock:DataRetentionMode": "none"
}
}
}
]
}O bloco Condition usa StringNotEquals, o que significa que o deny é acionado para qualquer valor diferente de none. Com essa política em vigor: ninguém pode habilitar o compartilhamento de dados com provedores de modelos; modelos que exigem provider_data_share (como Claude Fable 5 e Claude Mythos 5) ficam permanentemente indisponíveis; todos os outros modelos continuam funcionando normalmente.
Bloqueando também as configurações por projeto
O endpoint bedrock-mantle suporta configurações de retenção por projeto. Sem cobertura adicional na SCP, alguém poderia criar ou atualizar um projeto com provider_data_share, contornando a restrição no nível da conta. Para evitar isso, estenda a SCP:
{
"Version": "2012-10-17",
"Statement": [
{
"Sid": "RESTRICTBEDROCKDATARETENTION",
"Effect": "Deny",
"Action": [
"bedrock:PutAccountDataRetention",
"bedrock-mantle:PutAccountDataRetention",
"bedrock-mantle:CreateProject",
"bedrock-mantle:UpdateProject"
],
"Resource": "*",
"Condition": {
"StringNotEquals": {
"bedrock:DataRetentionMode": "none"
}
}
}
]
}O endpoint bedrock-runtime não precisa dos bloqueios de projeto porque projetos não existem nesse endpoint — apenas a ação bedrock:PutAccountDataRetention já é suficiente para cobri-lo.
Retenção de dados e inferência entre regiões
Ao usar perfis de inferência entre regiões (cross-Region inference profiles), o modo de retenção é avaliado na região de origem da requisição — a região onde a chamada de API é feita. Não é necessário configurar o modo em cada região de destino.
Porém, há um ponto de atenção: embora a verificação do modo ocorra na região de origem, os dados podem ser retidos na região de destino onde a inferência é processada. Isso é relevante para organizações que monitoram onde os dados retidos residem geograficamente.
Uma vantagem importante das SCPs nesse contexto: uma única SCP anexada à OU raiz bloqueia provider_data_share em todas as regiões automaticamente, sem necessidade de configuração por região.
Verificando suas configurações
A AWS oferece três formas de verificar as configurações de retenção: o console do Amazon Bedrock, a Interface de Linha de Comando da AWS (AWS CLI) (versão 2.35+) e a API bedrock-mantle.
Verificar o modo atual da conta
Via AWS CLI:
aws bedrock get-account-data-retention --region us-east-1Resposta esperada:
{
"mode": "none",
"updatedAt": "2026-07-01T01:58:34.684Z"
}Via API bedrock-mantle (usando uma chave de API do Bedrock):
curl https://bedrock-mantle.us-east-1.api.aws/v1/data_retention \
-H "x-api-key: $BEDROCK_API_KEY"Verificar o modo efetivo de um modelo específico
curl https://bedrock-mantle.us-east-1.api.aws/v1/models/anthropic.claude-fable-5 \
-H "x-api-key: $BEDROCK_API_KEY"Resposta:
{
"id": "anthropic.claude-fable-5",
"status": "available",
"data_retention": {
"mode": "provider_data_share",
"source": "account",
"allowed_modes": ["provider_data_share"]
}
}Se o modelo aparecer com "status": "unavailable", o campo status_reason explicará o conflito de modo de retenção.
Confirmar que a SCP está funcionando
Tente definir o modo como provider_data_share:
aws bedrock put-account-data-retention \
--region us-east-1 \
--mode provider_data_shareSe a SCP estiver funcionando, você receberá um erro de acesso negado:
An error occurred (AccessDeniedException) when calling the PutAccountDataRetention operation: User: arn:aws:iam::123456789012:user/admin is not authorized to perform: bedrock:PutAccountDataRetention with an explicit deny in a service control policySe a requisição for bem-sucedida, a SCP não está funcionando. Reverta imediatamente com --mode none e verifique: se a SCP está anexada à OU raiz (não a uma OU filha), a sintaxe da política e as condition keys, e lembre-se de que a conta de gerenciamento do AWS Organizations é isenta de SCPs — use uma política IAM para cobri-la.
Gerenciando retenção no nível do projeto
O gerenciamento de retenção por projeto é feito exclusivamente via API bedrock-mantle — não há comando AWS CLI para configurações no nível do projeto.
# Definir um projeto como provider_data_share
curl -X POST https://bedrock-mantle.us-east-1.api.aws/v1/organization/projects/proj_abc123 \
-H "x-api-key: $BEDROCK_API_KEY" \
-H "Content-Type: application/json" \
-d '{ "data_retention": { "mode": "provider_data_share" } }'
# Definir um projeto como none (retenção zero)
curl -X POST https://bedrock-mantle.us-east-1.api.aws/v1/organization/projects/proj_abc123 \
-H "x-api-key: $BEDROCK_API_KEY" \
-H "Content-Type: application/json" \
-d '{ "data_retention": { "mode": "none" } }'
# Verificar a configuração atual de um projeto
curl -X POST https://bedrock-mantle.us-east-1.api.aws/v1/organization/projects/proj_abc123 \
-H "x-api-key: $BEDROCK_API_KEY"Recursos adicionais
- Documentação de retenção de dados do Amazon Bedrock — documentação completa sobre modos de retenção, configuração e aplicação via IAM
- Perfis de inferência entre regiões — como a inferência é roteada entre regiões AWS
- Detecção de abuso no Amazon Bedrock — quais dados são retidos para fins de segurança
- Crédito de fallback para requisições recusadas — como funciona o faturamento quando o Fable 5 faz fallback para o Opus 4.8
- Anúncio do Claude Fable 5 e Mythos 5 — explicação da Anthropic sobre a nova política de retenção de dados
- Adendo de Processamento de Dados da Anthropic — termos legais que regem os dados compartilhados com a Anthropic
- Políticas de Controle de Serviço (SCPs) — documentação do AWS Organizations
Fonte
Enforce zero data retention on Amazon Bedrock with Bedrock Projects and service control policies (https://aws.amazon.com/blogs/security/enforce-zero-data-retention-on-amazon-bedrock-with-bedrock-projects-and-service-control-policies/)
