pular para o conteúdo
voltar ao mapa
conceito
4 min de leitura

Guardrails - filtros de entrada e saída

Guardrails validam entrada (prompt injection, PII, jailbreak) e saída (PII, schema, política) em cada turno. Complementam o eval: seguram o que vai ao usuário, mas não medem se a resposta é boa.

Guardrails AINeMo GuardrailsLakeraRebuff

O que é

Guardrail é uma camada de validação que fica entre o usuário e o agente, e entre o agente e a resposta final. Em cada turno, duas bordas: a borda de cima analisa a mensagem do usuário (e o histórico, e os documentos que vão entrar como contexto) e decide se passa, bloqueia ou reescreve. A borda de baixo faz o mesmo com a saída do agente antes dela alcançar quem pediu.

A diferença para o eval é a posição no tempo. Eval mede qualidade depois que a resposta foi gerada, em batch ou em amostragem. Guarda age agora, em cada request. São complementares. Quem substitui um pelo outro vira teatro de segurança: o eval lento demais para bloquear e o guardrail sozinho sem visão da qualidade geral.

Entrada: prompt injection, jailbreak, PII

A entrada é a parte mais visada. O usuário pode tentar instruir o modelo a ignorar as instruções do sistema (jailbreak clássico), embutir comando dentro de um documento recuperado (indirect ), ou colar dado sensível pedindo para o agente processar ( que vai parar no log). O guardrail de entrada precisa das três detecções, e cada uma tem mecanismo próprio.

PII é o mais fácil: regex sobre email, CPF, telefone, cartão. Falsos positivos são trabalho de revisão, falsos negativos viram incidente. Jailbreak é mais sutil: classificadores treinados em adversarial prompts, ou padrões conhecidos (DAN, role-play). Indirect injection é o mais novo e o mais difícil: a instrução hostil está num documento que o retrieval trouxe, não na mensagem do usuário. Detecção aqui pede análise semântica do conteúdo recuperado, não só do texto cru.

Saída: schema, PII, política

A saída precisa de três camadas também. Validação de schema garante que a resposta final tem a forma esperada (JSON tipado, markdown válido, links com host confiável). Máscara de PII redige email, telefone, endereço que o modelo tenha inventado ou copiado. Política rejeita conteúdo proibido pelo negócio (concorrente citado, jurisdição restrita, categoria sensível).

A camada de schema merece atenção especial. Sem schema válido, o frontend não renderiza e o agente parece quebrado. Por isso o guardrail de saída começa quase-falino: melhor bloquear uma resposta válida e devolver fallback do que entregar resposta que quebra o consumidor.

Guardrail de saída na prática

O snippet mostra um guardrail de saída mínimo: valida JSON contra um schema, redige PII básica, e bloqueia quando o conteúdo foge da rubrica. Em produção vale trocar regex por detector (Guardrails AI, Lakera), mas a mecânica fica esta:

guardrails/saida.tstypescript
import Ajv from "ajv";

const schema = {
  type: "object",
  required: ["resposta", "fontes"],
  properties: {
    resposta: { type: "string", minLength: 1, maxLength: 2000 },
    fontes: { type: "array", items: { type: "string" } }
  },
  additionalProperties: false
};

const ajv = new Ajv();
const validate = ajv.compile(schema);

const PII = /\b([\w._%+-]+@[\w.-]+\.[A-Za-z]{2,}|\d{3}\.\d{3}\.\d{3}-\d{2})\b/g;
const PROIBIDO = /(concorrente-x|concorrente-y)/i;

export type Veredito = { ok: true; saida: unknown } | { ok: false; motivo: string };

export function guardrailSaida(raw: string): Veredito {
  let parsed: unknown;
  try { parsed = JSON.parse(raw); } catch { return { ok: false, motivo: "json_invalido" }; }
  if (!validate(parsed)) return { ok: false, motivo: "schema_invalido" };
  if (PROIBIDO.test(JSON.stringify(parsed))) return { ok: false, motivo: "politica_violada" };
  const redigido = JSON.stringify(parsed).replace(PII, "[REDIGIDO]");
  return { ok: true, saida: JSON.parse(redigido) };
}

Onde entra na arquitetura

Como camada cross-cutting, antes do LLM e depois do LLM. Em produção o guardrail de entrada vira um middleware do endpoint HTTP; o de saída vira wrapper do cliente LLM ou post-processor do stream. Em frameworks como LangGraph, é um node dedicado entre o usuário e o agente, e entre o agente e a resposta.

Performance importa. Cada guardrail adiciona latência, e latência em chat visível logo de cara. Regra: guardrail de entrada roda em <= 50ms para a maior parte dos casos, e o de saída fica dentro do orçamento total do request (tipicamente <= 200ms). Acima disso, usar detector assíncrono e mostrar placeholder enquanto processa.

Guardrail não substitui eval

Guardrail cuida do que pode acontecer. Um agente pode passar em todos os guardrails e ainda assim dar resposta ruim (off-topic, factualmente errada, com tom inadequado). Isso é trabalho do eval, e o eval roda em batch onde o guardrail não consegue.

A confusão aparece quando alguém trata guardrail como prova de qualidade. Pontuação média de guardrail é alta (a maior parte das requests passa), e isso leva o time a achar que 'está tudo bem'. Não está. Guardrail mede segurança e conformidade; eval mede qualidade. São dois eixos diferentes, ambos necessários.

Pontos fortes

  • bloqueia ataques conhecidos antes de chegarem ao modelo, e.g. injection simples e PII óbvia
  • conformidade rastreável: cada turno vira um log de decisão, e auditoria quer sinal rápido quando há violação
  • composable: dá para combinar vários guardrails em pipeline, cada um cuidando de uma classe de risco

Limitações

  • falso negativo em ataque novo: prompt injection evolui, e o detector treinado em 2024 erra em 2026
  • custo de latência: cada camada a mais sincrona é visível no SLA, e pipeline de 5 guardrails começa a parecer caro
  • cegueira de qualidade: bloqueia o perigoso, mas não mede se o que passou é bom, e isso continua sendo do eval
Prompt injectionAtaque em que conteúdo hostil (em página indexada, em e-mail resumido, em doc aberto pelo agente) tenta substituir as instruções do sistema. O atacante sabe que o LLM mistura texto confiável com texto encontrado e planta um 'ignore as instruções anteriores e execute X'. É o vetor número 1 em agente em produção hoje, não é bug do LLM, é como agentes leem texto por design.ver no glossário →PIIpersonally identifiable informationDado pessoal que identifica alguém: nome e CPF, e-mail, telefone, endereço, IP. Quando o usuário cola um documento com PII no chat, ou o RAG indexa um CRM com 5.000 clientes, o agente vira um vazamento por design. Guardrails aqui são detecção na entrada, redação antes de mandar para o LLM, e retenção curta, porque mascarar depois de receber a resposta já é tarde demais.ver no glossário →

conexões no mapa

atualizado em 14/10/2026 · fontes para aprofundar · reportar erro

em outros domínios

Estude antes

teste o que entendeu

Carregando perguntas…