Design Doc: Governança de Modelos Frontier no Bedrock com GPT, Claude e Nova

Durante os últimos 18 meses, cada equipe de produto passou a consumir LLMs de forma independente. Uma squad usa Claude 3.5 Sonnet diretamente via SDK da Anthropic. Outra chama GPT-4o via Azure OpenAI. Uma terceira experimentou Amazon Titan e agora quer migrar para Nova Pro. O resultado é previsível: nenhuma visibilidade centralizada de custo, nenhuma auditoria consolidada de prompts, nenhuma política de fallback quando um provedor sofre degradação, e, o mais crítico em ambientes regulados, nenhuma garantia de que dados sensíveis não estão cruzando fronteiras de jurisdição que violam LGPD, GDPR ou requisitos de residência de dados contratuais.

O Amazon Bedrock endereça parte desse problema ao consolidar múltiplos provedores sob uma única API e infraestrutura AWS. Com o anúncio recente de modelos OpenAI disponíveis no Bedrock (GPT-4.5, GPT-4.1 e variantes), a plataforma passa a ser um ponto de agregação legítimo para a maioria dos casos de uso enterprise. Mas o Bedrock por si só não resolve governança: ele oferece os primitivos (Guardrails, Model Invocation Logging, IAM, VPC endpoints), mas a responsabilidade de compor esses primitivos em uma arquitetura coerente é do arquiteto.

O problema central que este documento endereça é: como construir um plano de controle unificado sobre múltiplos modelos frontier dentro do Bedrock, que seja auditável, seguro por design, consciente de custo e operacionalmente sustentável? A resposta não é um produto, é uma arquitetura.

A arquitetura central é um AI Gateway: uma camada de serviço que fica entre os consumidores (aplicações, agentes, pipelines) e os modelos no Bedrock. Não é um proxy burro: ele executa lógica de negócio de governança antes, durante e depois de cada chamada de inferência.

Camada de Entrada e Autenticação

Todo tráfego entra via Amazon API Gateway com autenticação por JWT (Cognito) ou API Key vinculada a um tenant_id. O primeiro passo é a resolução do contexto do tenant: o Gateway Lambda consulta o DynamoDB (tenant-config table) para obter o perfil do tenant, quais modelos estão habilitados, qual é o token budget mensal, qual região de dados é permitida, e qual é a política de fallback configurada. Isso elimina lógica de autorização espalhada pelas aplicações.

Prompt Registry e Versionamento

Prompts não são strings inline no código da aplicação. Eles são artefatos versionados armazenados no S3 com metadados no DynamoDB: prompt_id, version, model_affinity (quais modelos foram testados com esse prompt), eval_score, author, approved_at. O Gateway resolve o prompt pelo ID e versão antes de montar o payload de inferência. Isso garante que o log de auditoria sempre referencia prompt_id:version, não o texto raw, o que é crítico para investigações pós-incidente e para demonstrar controle em auditorias.

Guardrails em Duas Fases

O Bedrock Guardrails é invocado em duas fases: pré-inferência (validação do input: PII detection, topic blocking, prompt injection patterns) e pós-inferência (validação do output, grounding check, toxicidade, leakage de dados internos). A configuração de guardrails é por guardrail_profile associado ao use case, não ao tenant, porque o mesmo tenant pode ter use cases com tolerâncias diferentes (um chatbot público tem guardrails mais restritivos que uma ferramenta interna de análise de código). Guardrails que bloqueiam retornam um evento estruturado para o EventBridge, que aciona alertas e, em casos de violação grave, suspende o use case automaticamente.

Roteamento e Fallback

A política de roteamento é declarativa, armazenada por use case no DynamoDB: modelo primário, modelo de fallback, critério de fallback (latência > X ms, erro 5xx, ou custo por token acima de threshold). O Gateway implementa um circuit breaker simples: após N falhas consecutivas no modelo primário, ele abre o circuito e roteia para o fallback pelo período de cooldown configurado. O log registra qual modelo efetivamente serviu cada request, crítico para debugging e para análise de custo real vs. planejado.

Token Budget e Cost Control

Cada tenant tem um budget mensal de tokens (configurável por model tier, tokens de Nova Micro custam menos que tokens de GPT-4.5). O Gateway mantém um contador incremental no DynamoDB com TTL mensal. Quando o uso atinge 80% do budget, um evento é publicado no EventBridge para notificação. A 100%, o Gateway retorna 429 com header X-Budget-Exhausted: true. Hard stops são não-negociáveis, não existe override sem aprovação explícita registrada no audit log.

Logging de Inferência

O Bedrock Model Invocation Logging está habilitado no nível da conta, com logs entregues ao S3 e indexados no CloudWatch Logs Insights. O Gateway enriquece esses logs com metadados que o Bedrock não captura nativamente: tenant_id, use_case_id, prompt_id:version, guardrail_result, routing_decision (primary vs. fallback), e budget_remaining. O schema é fixo e versionado, mudanças no schema de log passam por revisão porque quebrar queries de auditoria é um risco operacional real.

Este é o aspecto mais frequentemente subestimado em arquiteturas de AI Gateway. Quando um cliente tem dados classificados como PII brasileiro sob LGPD, ou dados de saúde sob regulação setorial, a garantia de que esses dados não saem da região sa-east-1 não pode ser uma promessa verbal, precisa ser arquitetural e auditável.

Estratégia de Residência por Tenant

O perfil do tenant no DynamoDB inclui um campo allowed_regions: ["sa-east-1"] e allowed_models que é a intersecção dos modelos disponíveis nessa região com os modelos habilitados para o tenant. O Gateway rejeita requests que tentariam rotear dados de um tenant restrito para uma região não aprovada, e esse reject é logado como evento de violação de política, não como erro silencioso.

O Amazon Bedrock hoje disponibiliza modelos em múltiplas regiões, mas o portfólio varia. Nova Pro e Claude 3.5 Haiku estão disponíveis em sa-east-1. GPT-4.5 via Bedrock está disponível inicialmente em us-east-1. Isso significa que tenants com restrição de residência brasileira não podem usar GPT-4.5 neste momento: e o Gateway deve enforçar isso automaticamente, não depender de disciplina do desenvolvedor.

Isolamento de Credenciais

Cada tenant tem uma IAM Role dedicada com política de acesso restrita aos modelos permitidos. O Gateway assume essa role via STS AssumeRole antes de invocar o Bedrock, garantindo que o log de CloudTrail registre a role do tenant, não a role genérica do Gateway. Isso é essencial para auditoria: em uma investigação, você precisa saber exatamente qual tenant invocou qual modelo, não apenas que o Gateway fez uma chamada.

Secrets Manager armazena as configurações de role ARN por tenant. Rotação de credenciais é automática. O acesso ao Bedrock é exclusivamente via VPC Endpoint, não existe caminho de dados que atravesse a internet pública, independente do modelo.

Evals e Qualidade

O Prompt Registry inclui scores de avaliação por modelo: antes de promover uma versão de prompt para produção, ela passa por um pipeline de evals automatizado que testa contra um conjunto de casos de referência e registra métricas de qualidade (accuracy, hallucination rate, latência p95) por modelo. Isso permite decisões de roteamento baseadas em evidência, não em preferência de fornecedor. Se Claude 3.7 tem eval score superior para o use case de extração de cláusulas contratuais, ele é o primário para esse use case, independente de custo por token.