Guardrail não é uma camada única

Tem muita gente falando sobre guardrails como se fosse uma coisa só. Um portão. Uma verificação. Um prompt de sistema que fala "não responda perguntas inadequadas" e o assunto está resolvido. Não está.

Um sistema de IA em produção tem pelo menos quatro pontos onde você pode e, dependendo do caso, deve interceptar o fluxo. Cada ponto tem uma responsabilidade diferente. Confundir essas responsabilidades é o que faz sistemas que parecem seguros em demo quebrarem na primeira semana com usuário real.

O que o mercado chama de guardrail

A confusão começa porque o termo é usado para cobrir coisas muito distintas. Às vezes guardrail é o filtro de entrada que bloqueia mensagens maliciosas. Às vezes é o prompt de sistema que orienta o comportamento do modelo. Às vezes é o revisor que avalia a saída antes de chegar no usuário. Na prática, todos esses existem ao mesmo tempo num sistema bem construído, e cada um é responsável por uma camada diferente de falha.

O problema de tratar isso como uma coisa só é que você acaba colocando peso demais em uma única camada. O modelo vira o guardião de tudo. E modelo erra, mesmo com contexto bom.

A camada de entrada: determinístico primeiro, LLM por último

O primeiro ponto de interceptação é antes da mensagem chegar no modelo. Aqui você quer ser rápido e barato. Regras determinísticas funcionam bem: lista de palavras bloqueadas, padrões de injeção de prompt conhecidos, formatos que não deveriam aparecer.

Se entrar uma mensagem que claramente não deve ser processada, você não precisa nem acionar a LLM. Manda direto pro final com a resposta de rejeição. É mais econômico, mais rápido e cria uma separação clara entre o que é decisão de regra de negócio e o que é decisão do modelo.

No Athena, o sistema que integra com o TOTVS Protheus para gerar queries SQL sob demanda, eu precisei pensar nisso cedo. A plataforma atende múltiplas empresas, cada uma com dados de RH, financeiro e logística. Antes de qualquer informação de usuário chegar no modelo, eu sanitizo o que pode conter dados pessoais. E-mail, CPF, número de telefone, qualquer coisa que identifique um colaborador especificamente não entra no contexto do modelo sem tratamento. Isso não é feito pelo modelo. É feito por regra, antes do modelo.

A interceptação de chamada de ferramenta: o ponto mais subestimado

Entre o modelo e a ferramenta existe uma aresta. Essa aresta é invisível na maioria das implementações que eu vejo. O modelo decide chamar uma ferramenta, a ferramenta executa, o resultado entra no contexto. Simples, exceto quando a ferramenta devolve algo que não deveria entrar no contexto.

Se o seu agente faz busca na internet, o resultado dessa busca vai direto pro contexto. Se a página devolvida tem conteúdo que você não quer que o modelo use como referência para a resposta, já era. O dano está feito.

Interceptar a chamada de ferramenta significa validar o que o resultado da ferramenta contém antes de deixar entrar no fluxo do agente. Isso é especialmente importante quando você usa ferramentas que você não controla.

A saída com LLM como juiz

Depois que o modelo responde, antes de entregar para o usuário, você pode acionar um segundo modelo para avaliar a resposta. Isso é o que tecnicamente se chama de LLM as judge.

A lógica é simples: o modelo principal processou, gerou uma resposta. Um segundo modelo, geralmente mais leve e barato, avalia se essa resposta contém algo que não deveria estar lá. Informação confidencial que vazou, alucinação verificável, conteúdo fora do escopo da solução.

Quando eu estava ajustando o fluxo de geração de relatórios no Nexus ZDT, a plataforma de automação de RH no Protheus, a camada de validação de saída foi o que evitou que dados de um cliente aparecessem no relatório de outro. O pipeline processava dados de múltiplas empresas e o contexto às vezes continha informação de mais de uma fonte. Um revisor de saída capturava isso antes de qualquer dado chegar no frontend.

Humano no loop: não é sinal de fraqueza

O quarto ponto é a aprovação humana antes de ações irreversíveis. Agentes tomam decisões. Algumas dessas decisões têm consequências que você não consegue desfazer facilmente. Mandar um e-mail para 500 pessoas. Publicar um comunicado num canal interno. Executar uma query que vai alterar registros.

No GITFLOW, a plataforma de BPM que substituiu o TOTVS Fluig na Guaraves, o design inteiro gira em torno disso. A IA executa as etapas que são de baixo risco de forma autônoma. Quando a decisão tem impacto real, ela para, apresenta o contexto e o raciocínio que chegou até ali, e espera aprovação do responsável. Isso não é um guardrail fraco. É o guardrail certo para o tipo de decisão que não deve ser delegada completamente para o modelo.

O que eu percebo nos sistemas que falham

A maioria dos sistemas que quebra em produção não tem falta de guardrail. Tem guardrail no lugar errado. O modelo tenta verificar sua própria saída no mesmo prompt que gerou a resposta. A camada de entrada é muito ampla ou muito restrita. A chamada de ferramenta não tem nenhuma verificação.

Guardrail não é sobre desconfiar do modelo. É sobre saber onde o modelo é bom e onde ele não é. O modelo é bom em raciocinar, sintetizar e responder em linguagem natural. Ele não é bom em aplicar regras determinísticas de forma consistente sob todas as condições de entrada. Separar essas responsabilidades é o trabalho de quem constrói o sistema.

Qual das quatro camadas você deixaria de fora num sistema que vai para produção com usuários reais?