GPT-5 vs Claude vs Nova no Bedrock: Bake-off de Governança para Produção

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.

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.

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.

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.