ADR: Refinamento Automático de Políticas no Bedrock Guardrails

Desde que comecei a trabalhar com Automated Reasoning checks no Bedrock Guardrails em ambientes de serviços financeiros, o padrão que observo é sempre o mesmo: a equipe de compliance define uma política em linguagem natural, o engenheiro tenta traduzi-la para o modelo formal de variáveis e regras do AR, e o ciclo de revisão entre as duas equipes consome semanas. O problema não é a capacidade técnica — é a distância semântica entre "linguagem de negócio" e "lógica formal verificável".

O Automated Reasoning checks funciona traduzindo sua política (escrita em linguagem natural estruturada) para lógica formal, e então aplicando verificação matemática sobre as respostas do modelo. A qualidade dessa verificação depende diretamente da precisão da política traduzida. Variáveis mal definidas, tipos ambíguos e regras que cobrem casos de borda de forma incompleta resultam em "ambiguous translation" — o sistema não consegue determinar com confiança se a resposta viola ou não a política. Em produção, isso se manifesta como falsos negativos silenciosos: respostas incorretas que passam pela guardrail porque a política não era precisa o suficiente para capturá-las.

As forças que tornam isso crítico em ambientes financeiros são três. Primeiro, reguladores como o Banco Central do Brasil (BACEN) e a SEC exigem trilhas de auditoria determinísticas — "o modelo achou que estava correto" não é uma defesa aceitável. Segundo, o ciclo de vida de produtos financeiros muda: taxas, elegibilidade, regras de compliance evoluem, e a política formal precisa acompanhar. Terceiro, a equipe que entende as regras de negócio raramente é a mesma que sabe escrever lógica formal, criando um gargalo humano que limita a velocidade de adoção.

O anúncio de 23 de junho de 2026 introduz dois workflows distintos, e é importante não os conflatar — eles atacam problemas diferentes na cadeia de qualidade de políticas.

O workflow de melhoria iterativa de políticas opera sobre testes em linguagem natural que você já criou para uma política. Você fornece casos de teste — pares de (resposta de IA, resultado esperado: válido/inválido) — e o sistema deduz automaticamente as modificações necessárias na política para que ela passe nesses testes. Isso é fundamentalmente diferente de simplesmente reescrever a política do zero: o sistema preserva a intenção original e cirurgia apenas as partes que causam falhas nos testes. Para equipes que já mantêm suítes de testes de validação (o que eu considero obrigatório em produção), isso fecha o loop de feedback de forma automatizada.

O workflow de redução de ambiguidade ataca um problema diferente: descrições de variáveis e definições de tipo que são suficientemente vagas para que o motor de tradução produza resultados ambíguos com frequência. Quando você executa esse workflow, o sistema refina automaticamente essas descrições e definições para reduzir a frequência de traduções ambíguas. É essencialmente um processo de desambiguação semântica guiado pelo histórico de falhas de tradução da sua política específica.

Ambos os workflows estão disponíveis via API do Bedrock e no console, através do botão "Refine policy" na página da política. A disponibilidade é global nas regiões onde o AR checks já está disponível. O que o anúncio não especifica — e que é arquiteturalmente relevante — é o comportamento de versionamento: toda refinamento deve ser tratado como uma nova versão da política, com as implicações de ciclo de vida que isso traz.

A decisão que tomei em projetos financeiros é tratar cada execução de workflow de refinamento como um evento de ciclo de vida de política, com as mesmas garantias de rastreabilidade que aplicamos a mudanças de infraestrutura. Isso significa que o refinamento nunca acontece diretamente em produção pelo console — ele acontece em um ambiente de desenvolvimento, produz um artefato de política versionado, e esse artefato percorre um pipeline de promoção com aprovação humana.

A implementação concreta usa a API UpdateGuardrail do Bedrock para capturar o estado da política refinada como JSON, que é então commitado em um repositório Git com uma mensagem de commit estruturada contendo: o tipo de workflow executado (iterativo ou redução de ambiguidade), o número de testes que passaram antes e depois, e o hash do artefato de política anterior. O Step Functions orquestra o pipeline: (1) executa o workflow de refinamento via API, (2) captura o diff da política, (3) executa a suíte de testes de regressão contra a nova política em um ambiente de staging, (4) cria um pull request com o diff para aprovação do time de compliance, e (5) após aprovação, promove via UpdateGuardrail para produção com o guardrailVersion explicitamente fixado.

O ponto crítico aqui é o guardrailVersion: o Bedrock Guardrails mantém versões imutáveis de guardrails. Quando você refina uma política e a promove, você está criando uma nova versão — e suas aplicações devem referenciar versões explícitas, nunca DRAFT. Em incidentes, a capacidade de fazer rollback para a versão anterior em segundos (via UpdateGuardrail apontando para a versão anterior) é o que separa um sistema operável de um sistema que você não consegue consertar sob pressão.

Quando integro o ApplyGuardrail com AR checks em sistemas financeiros, três configurações específicas determinam se o sistema é operável ou problemático em produção.

Threshold de confiança e tratamento de ambiguidade. O AR checks retorna findings com níveis de confiança. Em políticas financeiras, eu configuro o threshold de confiança para HIGH e trato resultados AMBIGUOUS como falhas — não como passes. Isso é contra-intuitivo para equipes que querem maximizar disponibilidade, mas em contextos de compliance (ex: elegibilidade de crédito, divulgação de riscos), um resultado ambíguo é um resultado não verificado, e um resultado não verificado não pode ser apresentado ao cliente como fato verificado. A redução de ambiguidade do novo workflow ataca diretamente essa taxa de resultados ambíguos.

IAM conditions para o pipeline de refinamento. O papel IAM que executa os workflows de refinamento deve ter uma condition explícita restringindo bedrock:UpdateGuardrail ao guardrailId específico e ao ambiente de desenvolvimento — nunca ao ARN de produção. A separação de ambientes via IAM boundary é o controle que impede que um workflow de refinamento acidental sobrescreva a política de produção. A condition relevante é aws:ResourceTag/Environment com valor development.

Observabilidade dos findings. Cada chamada ApplyGuardrail retorna um objeto findings estruturado com as regras que foram violadas ou não puderam ser verificadas. Em produção, eu publico esses findings como métricas customizadas no CloudWatch com dimensões PolicyVersion, FindingType (PASS/FAIL/AMBIGUOUS) e RuleId. Um alarme em AMBIGUOUS_RATE > 5% por PolicyVersion é o sinal de que aquela versão de política precisa passar pelo workflow de redução de ambiguidade. Sem essa observabilidade, você não sabe que tem um problema até que alguém reclama de uma resposta incorreta.

Adotar os workflows de refinamento automatizado muda o perfil de risco do sistema de formas que precisam ser explicitamente endereçadas no design.

Deriva de política por testes inadequados. O workflow iterativo é tão bom quanto os testes que você fornece. Se sua suíte de testes cobre apenas os casos felizes e ignora edge cases regulatórios (ex: produtos com condições especiais, clientes em jurisdições específicas), o sistema vai refinar a política para passar nos testes que você tem — e potencialmente quebrar cobertura em casos que você não testou. O padrão que adoto é exigir que a suíte de testes inclua pelo menos 30% de casos negativos (respostas que devem ser rejeitadas) e casos de borda documentados pelo time de compliance, não apenas pelos engenheiros.

Latência adicional do ApplyGuardrail. Em sistemas de alta frequência (ex: chatbots de atendimento ao cliente em bancos com SLO de P99 < 2s), a chamada ApplyGuardrail com AR checks adiciona latência não trivial. Políticas mais complexas e precisas — resultado direto do refinamento — tendem a ter mais regras e variáveis, o que pode aumentar o tempo de verificação. O padrão é medir a latência de ApplyGuardrail por PolicyVersion e incluir esse delta como parte dos critérios de aprovação no pipeline de promoção. Uma política que reduz ambiguidade mas aumenta P99 em 400ms pode não ser aceitável dependendo do SLO.

Custo de refinamento como operação não determinística. Os workflows de refinamento consomem tokens de modelo internamente para deduzir mudanças de política. Isso tem custo. Em ambientes com muitas políticas (ex: um banco com dezenas de produtos, cada um com sua política de AR), o custo acumulado de execuções frequentes de refinamento pode ser significativo. A mitigação é tratar o refinamento como uma operação planejada e orçada — não como algo que qualquer engenheiro pode disparar a qualquer momento pelo console.