# GPT-5 vs Claude vs Nova no Bedrock: Bake-off de Governança para Produção Com GPT-5.5 e Codex chegando ao Amazon Bedrock, equipes de plataforma agora enfrentam uma escolha real entre três famílias de modelos frontier dentro do mesmo plano de controle. Esta análise compara GPT-5.5, Claude 3.7 Sonnet e Amazon Nova Pro sob a ótica de quem precisa colocar IA em produção em ambientes regulados. - URL: https://fernando.moretes.com/blog/bedrock-2026-governanca-modelos-frontier - Markdown: https://fernando.moretes.com/blog/bedrock-2026-governanca-modelos-frontier/article.md?lang=pt - Published: 2026-05-23T09:12:00.000Z - Category: IA & Agentes - Tags: bedrock, gpt-5, claude, nova, ai-governance, llm-ops, financial-grade, aws - Reading time: 7 min - Source: [OpenAI GPT-5.5, GPT-5.4 and Codex on Amazon Bedrock](https://aws.amazon.com/blogs/aws/) --- A chegada do GPT-5.5, GPT-5.4 e Codex ao Amazon Bedrock não é apenas um evento de produto — é um sinal de que o Bedrock está se consolidando como o plano de controle unificado para modelos frontier em ambientes enterprise. Para quem opera em setores regulados, a pergunta deixou de ser 'qual modelo usar?' e passou a ser 'como governar múltiplos modelos frontier com os mesmos controles de segurança, rastreabilidade e custo que já aplicamos ao resto da nossa infraestrutura AWS?' Esta análise faz exatamente esse bake-off: GPT-5.5 vs Claude 3.7 Sonnet vs Amazon Nova Pro, com foco em produção, não em benchmarks. ## O que mudou com o GPT-5 no Bedrock Antes da chegada dos modelos OpenAI ao Bedrock, a decisão de usar GPT-4 ou GPT-4o implicava sair do perímetro AWS: chamadas diretas à API da OpenAI, segredos gerenciados fora do Secrets Manager, logs que não passavam pelo CloudTrail, e dados que potencialmente saíam da sua região de residência. Para equipes que precisam de conformidade com LGPD, PCI-DSS ou SOC 2, esse era um custo de governança real, não teórico. Com GPT-5.5 e Codex disponíveis via `bedrock:InvokeModel` e `bedrock:InvokeModelWithResponseStream`, o modelo passa a ser mais um recurso ARN. Isso significa que as políticas IAM que você já tem — incluindo condições como `aws:RequestedRegion`, `bedrock:modelId` e `aws:PrincipalTag` — se aplicam diretamente. O CloudTrail registra cada invocação. O Amazon Bedrock Guardrails, com seus filtros de conteúdo, PII detection e grounding checks, cobre GPT-5.5 da mesma forma que cobre Claude ou Nova. O que isso não resolve: latência de rede para regiões onde o modelo ainda é servido via endpoint cross-region, e o fato de que os pesos do GPT-5.5 não residem na sua conta — você está consumindo um modelo hospedado, não um modelo implantado. Para casos de uso que exigem isolamento total de inferência, como análise de documentos com dados de clientes classificados, isso ainda é um ponto de atenção que precisa ser documentado no seu modelo de ameaças. ## A dimensão que benchmarks não capturam: comportamento operacional Benchmarks acadêmicos medem capacidade em condições controladas. Em produção financeira, o que importa é comportamento sob carga, consistência de latência no percentil 99, e o custo real de uma resposta — não o custo médio, mas o custo de um prompt de 8k tokens com 2k de output em horário de pico. O Claude 3.7 Sonnet tem uma característica que importa muito para workflows agenticos: o modo de 'pensamento estendido' (extended thinking) produz raciocínio encadeado que é auditável. Em contextos de compliance, poder mostrar o raciocínio intermediário de uma decisão de crédito ou de triagem de fraude tem valor regulatório direto. O GPT-5.5 também suporta chain-of-thought, mas o nível de controle sobre a verbosidade do raciocínio e a separação entre scratchpad e output final ainda é menos granular via API do Bedrock do que o que a Anthropic expõe nativamente. O Amazon Nova Pro, por outro lado, é o único dos três onde você tem visibilidade total sobre o ciclo de vida do modelo dentro da AWS. Ele suporta fine-tuning via Bedrock Custom Model Jobs, o que significa que você pode adaptar o modelo a vocabulário de domínio específico — terminologia de derivativos, por exemplo — sem depender de engenharia de prompt. O custo por token do Nova Pro é significativamente menor, o que importa quando você está processando milhões de documentos em batch com Bedrock Batch Inference. A falha de modo mais comum que vejo em produção não é o modelo errar — é o sistema não ter observabilidade suficiente para saber quando o modelo errou. Isso nos leva diretamente à questão de instrumentação. ## Plano de Controle Unificado: Governança de Modelos no Bedrock Fluxo de uma requisição de inferência passando por camadas de governança no Bedrock, mostrando como GPT-5.5, Claude e Nova compartilham os mesmos controles de segurança e observabilidade ### 🔐 AWS — Segurança e Identidade - IAM Policy bedrock:modelId condition (security) - KMS Encrypt at rest / in transit (security) ### 🟧 Amazon Bedrock — Plano de Controle - Bedrock Guardrails PII, content, grounding (security) - Bedrock API Gateway InvokeModel / Stream (compute) - Model Invocation Logging S3 + CloudTrail (data) ### 🤖 Modelos Frontier - GPT-5.5 / Codex OpenAI via Bedrock (ai) - Claude 3.7 Sonnet Extended Thinking (ai) - Amazon Nova Pro Fine-tune + Batch (ai) ### 📊 Observabilidade - CloudWatch Latency P99 / Tokens (data) - OpenTelemetry Trace ID por invocação (data) ### Fluxos - client -> iam: autenticação - iam -> guardrails: política aplicada - guardrails -> gateway: prompt filtrado - gateway -> gpt5: InvokeModel - gateway -> claude: InvokeModel - gateway -> nova: InvokeModel - gateway -> logging: log assíncrono - kms -> logging: criptografia - logging -> cw: métricas - gateway -> otel: trace span ## Instrumentação: onde a maioria das equipes erra O Bedrock emite métricas nativas para o CloudWatch: `InvocationLatency`, `InputTokenCount`, `OutputTokenCount`, `InvocationClientErrors`, `InvocationThrottles`. Mas essas métricas sozinhas não são suficientes para operar um sistema de IA em produção financeira. O que falta é correlação entre a invocação do modelo e o contexto de negócio — qual usuário, qual produto, qual decisão foi influenciada por aquela resposta. A abordagem que funciona é instrumentar com OpenTelemetry no nível da aplicação, propagando um trace ID que atravessa a chamada ao Bedrock e é incluído no payload de logging do Model Invocation Logging. Quando você habilita o Model Invocation Logging com destino S3 + CloudWatch Logs, cada registro inclui o `requestId` do Bedrock. Se você injeta esse `requestId` como atributo no seu span OTel, você consegue correlacionar uma reclamação de cliente com o exato prompt e resposta que gerou aquela decisão — isso é auditabilidade real. Para o GPT-5.5 especificamente, um ponto de atenção: o modelo suporta `response_format: json_object` e structured outputs, mas a validação de schema acontece no lado do modelo, não no Guardrails. Se você precisa garantir que a resposta respeita um schema específico antes de persistir em DynamoDB, adicione uma etapa de validação no Lambda que processa a resposta — não assuma que o modelo sempre retornará JSON válido sob carga ou com prompts adversariais. O Claude 3.7 com extended thinking expõe o bloco de raciocínio como um campo separado na resposta. Armazene esse campo no S3 com política de retenção de 7 anos se você estiver em ambiente regulado — ele é evidência de processo decisório, não apenas log técnico. ## Custo real: além do preço por token A comparação de custo entre modelos frontier frequentemente para no preço por token de input/output. Esse é o menor componente do custo total em sistemas de produção. Os componentes que dominam o custo são: (1) tokens desperdiçados por prompts mal estruturados, (2) retentativas por throttling, e (3) custo de operação do sistema ao redor do modelo. O GPT-5.5 tem um preço por token mais alto do que Claude 3.7 Sonnet e significativamente mais alto do que Nova Pro. Para um workload de análise de documentos processando 10 milhões de páginas por mês com contexto médio de 4k tokens por página, a diferença de custo entre GPT-5.5 e Nova Pro pode ser da ordem de 5-8x. Isso não é argumento para não usar GPT-5.5 — é argumento para usá-lo seletivamente, nos casos onde sua capacidade de raciocínio diferenciada justifica o custo. O Bedrock Batch Inference muda o cálculo para workloads assíncronos. Com batch, você obtém desconto de até 50% no preço por token para Claude e Nova. O GPT-5.5 no Bedrock ainda não suporta batch inference no momento desta análise — o que significa que para processamento em larga escala, você precisa gerenciar sua própria fila (SQS + Lambda com concurrency reservada) e lidar com os limites de TPM (tokens por minuto) da conta. O limite de TPM do Bedrock para modelos de terceiros como GPT-5.5 é gerenciado por service quota, e aumentos precisam ser solicitados via AWS Support. Em ambientes multi-tenant, onde múltiplos produtos compartilham a mesma conta AWS, isso pode se tornar um gargalo. A solução é usar AWS Organizations com contas separadas por produto e quotas independentes — não compartilhar limites de TPM entre workloads críticos e experimentais. ## GPT-5.5 vs Claude 3.7 Sonnet vs Amazon Nova Pro — Comparação Técnica | Critério | Dimensão | GPT-5.5 (OpenAI via Bedrock) | Claude 3.7 Sonnet (Anthropic) | Amazon Nova Pro | | --- | --- | --- | --- | --- | | Custo relativo por token (input) | Alto (baseline ~$3/MTok) | Médio (~$3/MTok) | Baixo (~$0.8/MTok) | — | | Suporte a Batch Inference (Bedrock) | Não (na data desta análise) | Sim — até 50% de desconto | Sim — até 50% de desconto | — | | Fine-tuning via Bedrock | Não disponível | Não disponível | Sim — Custom Model Jobs | — | | Raciocínio auditável (CoT estruturado) | Parcial — via structured outputs | Sim — extended thinking block separado | Parcial — via prompt engineering | — | | Cobertura do Bedrock Guardrails | Sim — mesmos controles | Sim — mesmos controles | Sim — mesmos controles | — | | Latência P50 (prompt 2k tokens) | ~1.8s (estimativa; varia por região) | ~1.5s (sem extended thinking) | ~1.2s | — | | Residência de pesos na conta AWS | Não — hospedado pela OpenAI | Não — hospedado pela Anthropic | Sim — Amazon-native | — | | Codex / geração de código especializada | Sim — Codex disponível no Bedrock | Forte — Claude 3.7 é top em código | Competente — melhor com fine-tune | — | ## Matriz de Decisão: Qual Modelo para Qual Workload? ### GPT-5.5 via Bedrock **Pros** - Capacidade de raciocínio de ponta para tarefas complexas e ambíguas - Codex para geração de código em pipelines de DevOps assistido por IA - Governança unificada via IAM, CloudTrail e Guardrails — sem saída do perímetro AWS - Structured outputs com JSON schema para integração direta com sistemas downstream **Cons** - Custo por token mais alto; sem suporte a batch inference no Bedrock - Pesos não residem na conta AWS — implicações para modelos de ameaça de dados sensíveis - Limites de TPM gerenciados por service quota; aumentos requerem suporte AWS - Sem fine-tuning disponível via Bedrock **Verdict:** Melhor para: tarefas de raciocínio de alta complexidade (análise jurídica, due diligence), geração de código em pipelines CI/CD, e casos onde a qualidade da resposta justifica o custo premium. ### Claude 3.7 Sonnet **Pros** - Extended thinking com bloco de raciocínio separado e auditável — valor regulatório direto - Suporte a batch inference com até 50% de desconto para workloads assíncronos - Excelente em código e análise técnica; consistente em contextos longos - Preço competitivo com GPT-5.5 para qualidade comparável em muitas tarefas **Cons** - Extended thinking aumenta latência significativamente — não adequado para inferência em tempo real - Sem fine-tuning via Bedrock; adaptação depende de prompt engineering e RAG - Pesos também não residem na conta AWS **Verdict:** Melhor para: workflows agenticos que precisam de raciocínio auditável, análise de documentos regulatórios, triagem de fraude com explicabilidade, e processamento em batch de alta qualidade. ### Amazon Nova Pro **Pros** - Menor custo por token — 5-8x mais barato que GPT-5.5 para workloads de alto volume - Fine-tuning via Bedrock Custom Model Jobs — adaptação a domínio sem prompt engineering - Pesos Amazon-native; melhor posição para modelos de ameaça de dados ultra-sensíveis - Suporte a batch inference; menor latência P50 entre os três **Cons** - Capacidade de raciocínio abaixo de GPT-5.5 e Claude 3.7 em tarefas de alta complexidade - Fine-tuning requer dataset de qualidade e pipeline de MLOps — overhead operacional - Ecossistema de ferramentas e integrações de terceiros menor **Verdict:** Melhor para: processamento em escala (milhões de documentos), tarefas de classificação e extração onde fine-tuning compensa, e ambientes com requisitos de soberania de dados mais estritos. > **O padrão de roteamento que resolve o dilema:** A resposta para 'qual modelo usar?' em sistemas de produção maduros não é uma escolha única — é um roteador. Implemente um AI Gateway em Lambda ou ECS que classifica cada requisição por complexidade, sensibilidade de dados e requisito de latência, e roteia para o modelo adequado. Requisições de baixa complexidade e alto volume vão para Nova Pro. Análises que precisam de raciocínio auditável vão para Claude 3.7 com extended thinking. Geração de código em pipelines CI/CD vai para Codex. O mesmo Guardrails, o mesmo CloudTrail, o mesmo trace ID — governança unificada com custo otimizado por workload. Esse padrão reduz custo total em 40-60% comparado a usar GPT-5.5 para tudo, sem abrir mão de qualidade onde ela importa. ## Números que guiam a decisão de roteamento - **5-8x** — Diferença de custo por token: GPT-5.5 vs Nova Pro. Para workloads de alto volume, o roteamento inteligente é a maior alavanca de custo disponível no Bedrock - **50%** — Desconto máximo com Batch Inference (Claude e Nova). Workloads assíncronos — análise de documentos, enriquecimento de dados — devem usar batch por padrão - **7 anos** — Retenção recomendada para logs de reasoning em ambientes regulados. O bloco de extended thinking do Claude 3.7 é evidência de processo decisório para auditorias regulatórias ## Anti-padrões que encontro em produção - Usar GPT-5.5 para todos os workloads por ser 'o mais capaz' — ignora que 70% das tarefas não precisam de raciocínio frontier e paga 5-8x mais por isso - Não habilitar Model Invocation Logging — sem logs de prompt/resposta, auditoria regulatória é impossível e debugging de regressões de qualidade é cego - Assumir que Bedrock Guardrails substitui validação de schema no código — Guardrails filtra conteúdo, não valida estrutura de dados; JSON inválido ainda passa - Compartilhar limites de TPM entre workloads críticos e experimentais na mesma conta AWS — um experimento com burst de tokens pode throttle uma feature de produção - Não propagar trace IDs nas chamadas ao Bedrock — perde a correlação entre decisão de negócio e invocação de modelo, tornando investigações de incidentes muito mais lentas > **Minha nota de curadoria:** Na prática, o que eu faria: começaria com Claude 3.7 Sonnet como modelo padrão para qualquer novo workload em ambiente financeiro — o extended thinking auditável vale mais do que a diferença de custo em relação ao Nova Pro quando você está em um setor regulado. Introduziria GPT-5.5 e Codex especificamente para o pipeline de AI-assisted DevOps, onde a qualidade de geração de código justifica o custo premium. Nova Pro entraria como destino de roteamento para classificação e extração em escala, com fine-tuning treinado no vocabulário do domínio. A lição que aprendi da forma difícil: o maior risco não é escolher o modelo errado — é não ter observabilidade suficiente para saber quando qualquer modelo está errado. Invista em trace IDs, Model Invocation Logging e alertas de drift de qualidade antes de otimizar qual modelo usar. ## Recomendação: não escolha um modelo, construa um roteador A chegada do GPT-5.5 e Codex ao Bedrock não torna Claude ou Nova obsoletos — ela completa o portfólio. A recomendação é clara: implemente um AI Gateway que roteia por workload, não por preferência de modelo. Use Claude 3.7 Sonnet como padrão para tarefas que precisam de raciocínio auditável em ambientes regulados. Use GPT-5.5 e Codex para geração de código e tarefas de raciocínio de alta complexidade onde o custo premium é justificado pelo valor. Use Nova Pro para processamento em escala e casos onde fine-tuning de domínio é viável. Em todos os casos: habilite Model Invocation Logging no dia um, propague trace IDs, e trate os limites de TPM como uma quota de infraestrutura que precisa de planejamento de capacidade — não como um detalhe de configuração. Governança unificada no Bedrock é o ativo real aqui; os modelos são commodities que vão evoluir. Construa sua plataforma em torno dos controles, não em torno de um modelo específico. ## Referências - [Amazon Bedrock Model Invocation Logging](https://docs.aws.amazon.com/bedrock/latest/userguide/model-invocation-logging.html) - [Amazon Bedrock Guardrails](https://docs.aws.amazon.com/bedrock/latest/userguide/guardrails.html) - [Amazon Bedrock Batch Inference](https://docs.aws.amazon.com/bedrock/latest/userguide/batch-inference.html) - [Amazon Bedrock Custom Model Fine-tuning](https://docs.aws.amazon.com/bedrock/latest/userguide/custom-models.html) - [AWS Well-Architected — Machine Learning Lens](https://docs.aws.amazon.com/wellarchitected/latest/machine-learning-lens/welcome.html) - [Amazon Bedrock Service Quotas](https://docs.aws.amazon.com/bedrock/latest/userguide/quotas.html) - [OpenTelemetry for AWS Lambda and Bedrock](https://aws-otel.github.io/docs/getting-started/lambda) - [AWS News Blog — Amazon Bedrock](https://aws.amazon.com/blogs/aws/)