Prove It, Parte 3: Um guia passo a passo para a implementação do raciocínio automatizado

Neste guia, você aprenderá como criar uma política de raciocínio automatizado a partir de um documento de negócios existente, implantá-la por meio do Amazon Bedrock Guardrails, validar respostas de LLM com o ApplyGuardrail, criar uma trilha de auditoria e proteger agentes de IA com a Política no AgentCore. Com esse processo, as equipes podem passar da fase de documentação de conformidade para a verificação em produção em apenas 30 minutos.

Na Parte 1 (“Por que ‘provavelmente correto’ não é suficiente”), abordamos por que as startups precisam de verificação determinística. Na Parte 2 (“Lógica formal, políticas Cedar e a economia da verificação”), explicamos o fluxo de trabalho de verificação e a matemática por detrás dele. Agora é hora de colocar tudo em prática.

Do que você precisa antes de começar?

Antes de começar, certifique-se de ter o seguinte:

• Uma conta da AWS com acesso ao Amazon Bedrock. Se você faz parte do AWS Activate, já tem créditos para isso.
• Python 3.9+ com boto3.Se você enviou um MVP, você já tem isso.
• Um documento de política (PDF, Markdown ou texto sem formatação) descrevendo suas regras de negócios. Se você passou por qualquer revisão de conformidade ou diligência prévia de investidores, você já tem isso.

Etapa 1: crie sua política de AR

O caminho mais rápido é por meio do Console da AWS. Não é necessário escrever lógica formal, pois o Bedrock converte seu documento de origem em regras lógicas formais automaticamente.

1. Abra o console Bedrock e navegue até Raciocínio automatizado na barra lateral esquerda.
2. Crie uma nova política. Dê a ela um nome descritivo (por exemplo, política de elegibilidade para hipoteca).
3. Faça upload do seu documento de origem. Esse é o arquivo PDF, documento do Word ou texto sem formatação que descreve suas regras de negócios. Para uma startup de fintech, pode ser seu documento de critérios de empréstimo. Para a área da saúde, pode ser seus protocolos clínicos.
4. Forneça instruções. Escreva uma breve intenção descrevendo o que a política valida e inclua de 2 a 3 exemplos de pares de perguntas e respostas. Isso ajuda o sistema a entender como os usuários interagirão com a política.

Para equipes que preferem não usar o console, há também uma interface conversacional para criação de políticas que orienta você na formalização em linguagem natural. Ele tem alguns pré-requisitos (incluindo o Kiro-CLI), mas remove totalmente o console do fluxo de trabalho.

Exemplo de intenção:

Essa política verifica as condições de elegibilidade para hipotecas. Os usuários consultam se os clientes se qualificam para tipos específicos de hipotecas com base em seus dados financeiros.

Exemplo de perguntas e respostas:

P: Um cliente deseja comprar uma casa no valor de USD 350.000 com um adiantamento de USD 30.000. Ele se qualifica para um financiamento imobiliário convencional?

R: Não. As hipotecas convencionais exigem um pagamento inicial mínimo de 20% (USD 70.000 para uma compra de USD 350.000).

Analise o relatório de fidelidade:

Depois que o sistema processa seu documento, ele gera um relatório de fidelidade com duas pontuações:

• Pontuação de cobertura (0,0 a 1,0): qual a proporção do seu documento de origem que está representada na política
• Pontuação de precisão (0,0 a 1,0): com que fidelidade as regras extraídas correspondem à intenção do seu documento

O relatório também mostra as variáveis e regras específicas extraídas, com base nas declarações exatas no seu documento de origem. É aqui que você verifica se o sistema entendeu suas regras corretamente.

Refine suas descrições de variáveis usando exemplos reais da sua aplicação. Teste perguntas representativas, inspecione como o sistema as traduz e melhore as descrições sempre que as traduções errarem. Essa é a maior alavanca de precisão. Inclua unidades, sinônimos, regras de conversão e terminologia específica do domínio sempre que possível. Uma descrição como “O pagamento inicial do mutuário como uma porcentagem do preço de compra; quando os usuários mencionam valores em dólares, converta usando (downPayment/PurchasePrice) * 100" supera “Quanto o mutuário está investindo.”

Isso não é um projeto de engenharia que envolve várias etapas. Leva apenas 30 minutos para transformar seu documento de conformidade atual em uma política de AR que funcione. Faça ajustes nas descrições das variáveis e teste com perguntas de exemplo até que os índices de fidelidade e os resultados dos testes correspondam às suas expectativas.

Para saber mais sobre o caminho da API (útil para pipelines de CI/CD), confira a referência da API CreateAutomatedReasoningPolicy. A API aceita um nome, uma descrição opcional e uma policyDefinition que contém regras, variáveis e tipos personalizados.

Etapa 2: implantar em uma barreira de proteção

Depois que sua política for bem testada, implante-a para uso em produção.

Salve uma versão imutável. No console, escolha “Salvar como nova versão”. Isso cria um snapshot numerado e imutável (versão 1, 2, 3...) para que sua barreira de proteção em produção não seja afetada quando você continuar editando o RASCUNHO. É assim que as startups lançam com segurança e rapidez: sua equipe de conformidade analisa a versão 1 em produção enquanto sua equipe de engenharia faz iterações na versão 2 no rascunho. Sem congelamentos de implantação, sem aquele “por favor, não mexa na política até a gente lançar”.

Depois de publicar uma versão da sua política, anexe-a a uma barreira de proteção para que ela possa ser usada durante a validação do runtime:

Detalhes importantes:

• policies usa uma matriz de strings de ARN de políticas (máximo 2), não objetos
• confidenceThreshold (opcional, 0,0 a 1,0) controla o nível mínimo de concordância para que as traduções sejam consideradas confiáveis. Valores mais baixos (0,3) revelam mais descobertas mais cedo; valores mais altos (1,0) otimizam estritamente a solidez. Comece devagar durante o desenvolvimento, aperte para produção
• crossRegionConfig é necessário para verificações de AR; isso habilita a inferência entre regiões para a avaliação da barreira de proteção. Use o perfil da sua região (por exemplo, us.guardrail.v1:0 para os EUA, eu.guardrail.v1:0 para a UE)
• blockedInputMessaging e blockedOutputsMessaging são necessários; essas são as mensagens de fallback exibidas quando outros componentes da barreira de proteção (que não sejam o AR) bloqueiam o conteúdo
• Use uma versão numerada (:1) no ARN para produção. Reserve DRAFT apenas para desenvolvimento

Etapa 3: Validar as respostas do LLM com ApplyGuardRail

O padrão de integração recomendado é a API independente do ApplyGuardrail. Isso te dá controle total sobre qual conteúdo é validado e quando, e é a abordagem que a documentação da AWS recomenda explicitamente para verificações de AR.

Aqui está um exemplo de integração mínima adicionado ao seu pipeline de inferência existente:

Chame isso depois que seu LLM gerar uma resposta, antes de entregá-la ao usuário:

Importante: as verificações de AR operam no modo de detecção. Eles retornam descobertas e feedback. Eles não bloqueiam nem reescrevem a resposta automaticamente. Sua aplicação inspeciona as descobertas e decide o que fazer.

Etapa 4: lidar com as descobertas

Cada descoberta é um tipo de união com exatamente uma chave presente. Veja como analisá-los e agir:

O padrão de remediação padrão é um ciclo de validação e reescrita: valide a resposta, devolva todas as violações ao modelo, regenere a resposta e revalide. Repita até que a resposta seja válida ou um limite de novas tentativas seja atingido.

Seu usuário nunca vê o ciclo de reescrita. Eles veem a resposta correta na primeira tentativa. A iteração acontece em milissegundos nos bastidores.

Etapa 5: criar uma trilha de auditoria

Cada iteração de verificação deve ser registrada. Quando seu cliente corporativo pedir comprovantes do SOC 2, ou quando o órgão regulador perguntar como você verificou uma decisão específica, basta acessar o log em JSON. Cada verificação tem data e hora registradas e é rastreável.

Esse log se torna o seu documento de conformidade. Ele mostra o que o usuário solicitou, o que o LLM gerou, o que o AR encontrou e qual ação sua aplicação realizou. Para startups que buscam a certificação SOC 2, a conformidade com a HIPAA ou vendas corporativas, essa trilha de auditoria não é opcional. É a prova de que seu sistema funciona conforme documentado.

Etapa 6: Proteja seus agentes com a política AgentCore

Se sua startup passou dos chatbots para fluxos de trabalho agentes (sua IA marca compromissos, processa reembolsos, consulta bancos de dados ou envia e-mails), você precisa de limites sobre o que seu agente pode fazer, não apenas o que ele diz.

No Amazon Bedrock AgentCore, o Cedar é usado para definir esses limites. Por exemplo, um agente de agendamento de consultas médicas precisa de políticas que restrinjam quais registros de pacientes ele pode acessar, limitem as ações de agendamento ao horário comercial e impeçam que ele processe reembolsos acima de um limite sem a aprovação do gerente. Comece no modo LOG_ONLY para observar o que seu agente está fazendo sem bloquear nada. Quando você confiar nas políticas, mude para o modo ENFORCE para a produção.

O Gateway é a camada de aplicação de regras entre o seu agente e suas ferramentas. Toda chamada de ferramenta passa pelo Gateway, onde as políticas do Cedar são avaliadas antes que a solicitação chegue ao destino. É isso que torna a aplicação de regras determinística e independente do raciocínio do agente: o agente não pode contornar, ignorar ou convencer o Gateway a deixá-lo passar.

Configure um gateway e um mecanismo de políticas usando a CLI do AgentCore:

Escreva uma política Cedar e anexe-a ao mecanismo de políticas. O exemplo a seguir mostra políticas ilustrativas para um agente de consultas de saúde. Na prática, seus nomes de ação são gerados automaticamente a partir do alvo do gateway e do esquema da ferramenta (por exemplo, HealthTarget__get_patient_record), e o recurso deve fazer referência ao ARN específico do gateway:

O Cedar opera com a política de “negação por padrão”: toda interação entre o agente e uma ferramenta é bloqueada, a menos que uma política de permissão explícita a permita. Suas políticas de permissão definem quais ferramentas o agente pode chamar e em que condições. As políticas de proibição abaixo estabelecem exceções, bloqueando cenários específicos mesmo quando uma permissão mais ampla, de outra forma, os permitiria.

Salve isso como healthcare_policy.cedar e anexe-o ao mecanismo de políticas:

Como alternativa, você pode descrever suas regras em linguagem natural e deixar o sistema gerar o Cedar para você (requer que o gateway seja implantado primeiro):

O raciocínio automatizado valida as políticas no momento da criação, identificando regras excessivamente permissivas, excessivamente restritivas ou ineficazes antes da implantação.

As principais propriedades que importam para startups regulamentadas:

• Negação padrão: se nenhuma política permitir explicitamente uma ação, ela será bloqueada
• Proibir sempre vence: regras rígidas não podem ser substituídas por outras políticas
• Aplicação determinística: opera no limite do gateway, fora do raciocínio do seu agente. Não pode ser contornado por injeção imediata, alucinação ou insetos

Comece no modo LOG_ONLY para ver o que seu agente está fazendo sem prejudicar seu produto. Os logs mostram qual política foi aplicada em cada solicitação ao gateway, o resultado da decisão da política (permitir ou negar) e revelam políticas incompatíveis quando ocorre desvio da ferramenta. Dê uma olhada neles. Ajuste as políticas. Quando estiver confiante, mude para o modo ENFORCE. É assim que você passa do protótipo para a produção sem atrapalhar seus usuários.

Para exemplos completos, incluindo scripts de implantação e equipamentos de teste, consulte os exemplos do Amazon Bedrock AgentCore no GitHub.

O que acontece depois de implantar o raciocínio automatizado?

Depois de executar as verificações de AR e o AgentCore Policy, você desbloqueia algo mais valioso do que a prevenção de erros: uma única fonte de verdade.

Sua política de AR são suas regras de negócios codificadas como lógica formal. Quando essas regras mudam (e elas sempre mudam: novas regulamentações, critérios de empréstimo atualizados, protocolos clínicos revisados), você atualiza o documento de origem, regenera a política e imediatamente todos os sistemas de IA em sua pilha estão em conformidade com as novas regras. Nenhuma engenharia imediata para atualizar. Sem reciclagem de modelos. Não espero que alguém tenha se lembrado de alterar o prompt do sistema.

Isso elimina toda uma classe de insetos de deriva. Sua documentação e seu comportamento de IA estão matematicamente vinculados. Eles não podem ficar fora de sincronia.

Como as grades de proteção são independentes do modelo, sua camada de verificação permanece a mesma quando você troca os modelos básicos. A mesma política de AR que verificou as respostas de Claude verifica as da Amazon Nova. As regras dependem da sua lógica de negócios, não do modelo.

A integração se estende por todo o ecossistema Bedrock: as políticas de AR funcionam com bases de conhecimento para geração aumentada de recuperação, com agentes AgentCore para fluxos de trabalho de várias etapas e com toda a gama de modelos básicos. Você está construindo em uma plataforma, não em uma solução pontual.

Saiba mais

• O raciocínio automatizado verifica a documentação
• Conceitos de AR (variáveis, regras, descobertas)
• Guia de integração (aplique os padrões do Guardrail)
• Documentação da política do AgentCore
• Exemplos do AgentCore no GitHub
• Visão geral do AWS Provable Security
• O que é o raciocínio automatizado?
• Linguagem Cedar (CNCF)

Esse é o fim da nossa série AR para startups

Em toda a série Prove It, nossa tese foi a mesma: startups baseadas em IA precisam de verificação matemática determinística, não apenas de salvaguardas probabilísticas.

Na Parte 1, abordamos por que o problema de confiança é existencial para startups e como as décadas de trabalho da AWS em métodos formais levaram à Bedrock Guardrails e à AgentCore Policy.

Na Parte 2, examinamos os bastidores da lógica formal, do pipeline de verificação e da economia. Neste post, você viu o caminho completo de implementação, desde os documentos de conformidade existentes até a IA verificada e pronta para produção.

As startups que vencerem na era da IA não apenas construirão sistemas inteligentes; elas construirão sistemas que possam provar que estão corretos. O raciocínio automatizado e a Política AgentCore tornam isso possível hoje, usando as políticas e os documentos de conformidade que a maioria das empresas já possui. A única pergunta que resta é: você vai começar agora ou depois que o primeiro incidente forçar sua mão?