Guardrails para agentes de IA: entrada, saída e ação na prática

Guardrails para agentes de IA: entrada, saída e ação na prática

Guardrails para agentes de IA são controles colocados fora do modelo que verificam o que entra, o que sai e o que o agente pode fazer. Os de entrada filtram e delimitam o contexto, os de saída validam a resposta antes de ela chegar ao cliente ou ao sistema, e os de ação limitam ferramentas, permissões e volume. Quanto maior o dano possível, mais o controle deve ser código determinístico, e não uma instrução escrita no prompt.

Principais pontos

• Guardrail é um mecanismo que continua funcionando quando o modelo erra. Uma instrução no prompt é um pedido, não um controle.
• Há três famílias: entrada (o que o agente recebe), saída (o que ele responde ou grava) e ação (o que ele consegue executar).
• Os guardrails de ação são os mais importantes, porque limitam o estrago mesmo quando os outros falham.
• Cada guardrail tem um lugar certo de implementação: canal, orquestração, camada de ferramentas, sistema de destino ou pessoa.
• Comece com poucas regras ligadas a riscos reais do fluxo, registre tudo e ajuste com base nas falhas observadas.

Por que instruir o modelo no prompt não basta?

Um modelo de linguagem segue instruções de forma probabilística. Dizer no prompt que ele nunca deve oferecer desconto reduz a chance de isso acontecer, mas não a elimina. Se o agente tem acesso a uma ferramenta que aplica desconto, existe um caminho técnico para o erro, e ele pode ser aberto por um engano do modelo ou por uma mensagem maliciosa do usuário.

Por isso a distinção prática é entre orientação e controle. Orientação é o que você escreve no prompt, e ela ajuda no comportamento médio. Controle é uma checagem em código, uma permissão negada ou uma aprovação humana, e ela vale para o pior caso.

A Anthropic, em seu texto sobre como construir agentes eficazes, destaca testes extensivos em ambiente isolado e guardrails apropriados como parte do desenho. A lista OWASP Top 10 para aplicações com LLM trata de riscos como injeção de prompt e agência excessiva, que são exatamente os problemas que os guardrails de entrada e de ação tentam conter. Os dois links estão na seção de fontes.

Guardrails de entrada: o que o agente pode receber?

Entrada é tudo que chega ao modelo, e isso vai além da mensagem do cliente. Inclui o texto de um PDF anexado, o resultado de uma busca na base de conhecimento, o conteúdo de um e-mail e a resposta de outra ferramenta. Qualquer um desses pode carregar instruções que o modelo trate como ordens.

Os controles de entrada mais úteis em empresas costumam ser:

• Identificação do remetente: saber se o número de WhatsApp é de um cliente cadastrado antes de liberar consulta a dados pessoais.
• Limites de tamanho, tipo de arquivo e frequência de mensagens, para evitar abuso e custo inesperado.
• Separação entre instrução e dado: o conteúdo externo entra marcado como material a ser analisado, nunca como comando.
• Roteamento por intenção: assuntos fora do escopo (jurídico, reclamação grave, saúde) seguem direto para uma pessoa.
• Minimização de dados: o que não é necessário para a tarefa não entra no contexto, o que também ajuda na conformidade com a LGPD.

O guia da OWASP sobre prevenção de injeção de prompt trabalha com defesa em camadas, justamente porque nenhum filtro de entrada é completo. Tratar o filtro como primeira barreira, e não como única, é a postura correta. Se o seu fluxo roda no WhatsApp, vale ler também o material sobre LGPD no WhatsApp com IA: consentimento, base legal e registro, que cobre o que pode entrar no contexto e o que deve ser registrado.

Guardrails de saída: como validar o que o agente produz?

Saída é qualquer coisa que o agente gera: a resposta ao cliente, um campo preenchido num sistema, um resumo enviado à equipe. A pergunta de projeto é a mesma em todos os casos: o que precisa ser verdade antes de isso sair?

A validação funciona melhor em camadas, das mais baratas e previsíveis para as mais flexíveis:

• Formato: a saída segue o esquema esperado (campos obrigatórios, tipos, valores permitidos). Se não segue, é rejeitada em código.
• Existência: o número do pedido, o produto ou o horário citados realmente existem no sistema. Isso evita respostas plausíveis, porém inventadas.
• Política: a resposta não promete prazo, desconto, diagnóstico ou condição que a empresa não autorizou. Listas de termos e regras simples resolvem boa parte disso.
• Dados sensíveis: a resposta não repete documento, endereço ou dado de outra pessoa.
• Avaliação por segundo modelo: para o que regra não cobre, como tom e aderência ao contexto. Esse revisor também erra, então não deve ser a única barreira para algo crítico.

O ponto mais negligenciado é o que fazer quando a validação falha. Opções razoáveis são tentar de novo um número limitado de vezes, responder com uma mensagem padrão ou transferir para uma pessoa. Repetir indefinidamente consome recurso e pode acabar entregando uma saída pior.

Guardrails de ação: como limitar o que o agente executa?

Quando o agente deixa de apenas conversar e passa a chamar ferramentas, o risco muda de natureza. Uma resposta ruim é corrigível, mas um reembolso emitido, um e-mail enviado ou um registro apagado podem não ser. Os guardrails de ação existem para que o erro do modelo tenha um teto de impacto.

Os princípios vêm da segurança de aplicações em geral. A folha de referência de autorização da OWASP defende negar por padrão e conceder o menor privilégio necessário. Aplicado a agentes, isso se traduz em práticas concretas:

• Ferramentas mínimas: o agente só enxerga as ferramentas que o fluxo exige, e cada uma faz uma coisa.
• Leitura antes de escrita: comece com consultas e só depois libere gravações, com limites claros.
• Credenciais com escopo: o agente usa uma conta de serviço restrita, nunca um acesso administrativo.
• Validação de parâmetros na ferramenta: valor máximo, lista de destinos permitidos, status que podem ser alterados.
• Tetos de volume: quantidade de ações por hora ou por conversa, para conter laços e abuso.
• Idempotência: repetir a mesma chamada não duplica o efeito, o que protege contra tentativas repetidas.
• Aprovação humana para ações irreversíveis ou de alto valor, conforme descrito em Política de Aprovação para Agentes de IA: Template Prático.
• Interruptor de emergência: uma forma simples de desligar o agente ou uma ferramenta específica sem mexer no restante.

Em agentes de código, parte desses controles pode ser imposta por regras automáticas antes e depois de cada ação. O artigo sobre Claude Code hooks: como impor regras antes e depois de agir mostra esse mecanismo aplicado a equipes de desenvolvimento.

Onde cada guardrail é implementado?

A confusão mais comum é achar que guardrail é uma caixa única colocada ao redor do modelo. Na prática, cada controle mora em uma camada diferente, e a escolha da camada define se ele pode ser contornado. Este guia ajuda a decidir:

• Canal ou gateway (webhook do WhatsApp, API de entrada): autenticação do remetente, limite de frequência, tamanho e tipo de anexo. Se o controle não depende de interpretar texto, coloque-o aqui.
• Orquestração (o código que conduz o agente): roteamento por intenção, validação de esquema da saída, número máximo de tentativas, tetos por conversa. É a casa da maioria dos guardrails de saída.
• Prompt e contexto: delimitação de conteúdo externo, papel e tom do agente. Trate como apoio, não como barreira de segurança.
• Camada de ferramentas (API interna, servidor MCP, funções): permissões, validação de parâmetros, idempotência, lista de destinos permitidos. É a casa dos guardrails de ação.
• Sistema de destino (ERP, CRM, banco de dados): a conta usada pelo agente só tem as permissões que o fluxo exige. Se tudo acima falhar, este é o último limite.
• Pessoas: aprovação de ações sensíveis e atendimento de exceções. O fluxo de passagem deve estar definido, como no Transbordo Humano em Agentes de IA no WhatsApp: Playbook de Produção.
• Observabilidade: registro de entradas, decisões, chamadas de ferramentas e bloqueios, com alertas para padrões fora do normal. Sem isso, não há como saber se os guardrails funcionam.

Uma regra de bolso: se o controle precisa valer mesmo quando o modelo é enganado, ele deve ficar numa camada que o modelo não consegue alterar.

Cenário ilustrativo: agente de pedidos e trocas no WhatsApp

Imagine uma loja que usa um agente no WhatsApp para consultar pedidos e abrir solicitações de troca. Este é um cenário ilustrativo, sem relação com nenhum caso real.

Na entrada, o gateway só aceita mensagens de números que correspondem a um cliente com pedido e limita a frequência de mensagens por conversa. Anexos de imagem passam por verificação de tipo, e o texto extraído é tratado como dado, não como instrução. Uma mensagem que pede para ignorar as regras da loja continua sendo apenas uma mensagem, porque as regras estão no código e nas permissões.

Na saída, a resposta precisa seguir um esquema que traz o número do pedido consultado. O código confere se esse pedido pertence àquele cliente antes de enviar. Se o texto mencionar reembolso, prazo de entrega fora da regra ou valor, a resposta é bloqueada e a conversa vai para um atendente.

Na ação, o agente tem uma ferramenta de consulta de pedido e outra que abre solicitação de troca. Não existe ferramenta de reembolso. A abertura de troca só aceita pedidos dentro do prazo de política, e repetir a chamada não cria uma segunda solicitação. Cada chamada fica registrada com a conversa de origem.

O resultado é um agente útil para o fluxo comum e incapaz, por construção, de fazer o que a loja não autorizou. Para detalhes do domínio, veja o conteúdo sobre IA para atendimento de e-commerce em pedidos, trocas e rastreio, que trata do tipo de fluxo usado neste exemplo.

Como começar: plano passo a passo

Um programa de guardrails não precisa começar grande. Esta sequência funciona para o primeiro fluxo:

• Passo um: descreva o fluxo atual e o que o agente fará, incluindo os dados que ele toca e as ações que consegue executar.
• Passo dois: liste o pior resultado plausível de cada ação (valor errado, mensagem para a pessoa errada, dado exposto) e classifique por gravidade.
• Passo três: para cada risco, escolha o guardrail na camada mais baixa possível, priorizando controles de ação e validações em código.
• Passo quatro: defina o que acontece quando um guardrail bloqueia: nova tentativa limitada, mensagem padrão ou transferência para pessoa.
• Passo cinco: comece só com leitura e rascunhos, e libere gravações aos poucos, com aprovação humana nas ações irreversíveis.
• Passo seis: registre entradas, saídas, bloqueios e ações, com identificador de conversa, e revise os bloqueios e os quase-erros em uma rotina fixa.
• Passo sete: monte um conjunto de casos de teste com mensagens normais, ambíguas e hostis, e rode-o a cada mudança de prompt, modelo ou ferramenta.
• Passo oito: defina antes do piloto o critério de sucesso e quem decide expandir, ajustar ou parar.

O método aplicado no trabalho de consultoria segue a mesma lógica: mapear o processo e o ponto de partida, limitar dados e ações, pilotar um fluxo real com registros e uma métrica combinada, e então transferir a operação e decidir se expande, ajusta ou encerra. Os guardrails entram principalmente na etapa de limitar e são verificados durante o piloto, a partir dos logs.

O NIST AI Risk Management Framework é uma referência útil para organizar essa gestão de risco de forma mais ampla, caso a empresa precise de um vocabulário comum entre áreas.

Perguntas frequentes

Guardrails deixam o agente de IA mais lento ou menos útil? Validações em código custam pouco tempo, e as que envolvem um segundo modelo adicionam alguma latência, que deve ser avaliada no fluxo. O ganho de utilidade costuma vir do escopo bem definido, pois um agente que sabe quando transferir erra menos e gera menos retrabalho. O excesso de bloqueios, por outro lado, frustra o usuário, por isso vale revisar os bloqueios indevidos nos registros.

Preciso de uma ferramenta pronta de guardrails ou posso implementar por conta própria? Muitos controles são código comum: validação de esquema, permissões, limites e registros. Bibliotecas e serviços de moderação podem ajudar em pontos específicos, como detecção de conteúdo, mas não substituem o desenho de permissões e aprovações do seu processo. Avalie qualquer ferramenta pelo que ela realmente impede e pelo que registra.

Guardrails eliminam o risco de injeção de prompt? Não eliminam. Eles reduzem a chance de o ataque funcionar e, principalmente, limitam o que o ataque consegue causar. Por isso os guardrails de ação, como menor privilégio e aprovação humana, são a parte mais importante da defesa.

Como saber se meus guardrails estão funcionando? Pelos registros e pelos testes. Acompanhe quantas respostas e ações foram bloqueadas, por qual regra e se o bloqueio estava certo, e rode casos de teste hostis a cada mudança no agente. Se não houver bloqueio nenhum durante o piloto, desconfie: ou o fluxo é muito simples, ou os controles não estão sendo exercitados.

Fontes

• OWASP: LLM Prompt Injection Prevention Cheat Sheet
• OWASP Top 10 for LLM Applications
• OWASP: Authorization Cheat Sheet
• Anthropic: Building effective agents