Como implementar guardrails em AI Agents para evitar e-mail com impacto legal

O insight central é simples e meio assustador: um “AI Agent” pode agir como se fosse você — e, quando a ação vira declaração contratual, você perde tempo e controle. Segundo o Sapo.pt, o cenário é hipotético: a IA enviou um e-mail e ninguém clicou em “Enviar”. Mas tecnicamente isso já é plausível hoje: agente recebe um gatilho, consulta contexto, decide e dispara uma ação com consequências legais. E no fim, a pergunta “quem responde?” vai parar no colo de jurídico, TI e produto.

O que são AI Agents e por que eles mudaram o jogo no e-mail

Eu não penso mais em “chatbots”. Na prática, um AI Agent é um sistema que combina:

Modelo de linguagem (para interpretar linguagem e formular respostas)
Ferramentas/integrações (CRM, ERP, base de contratos, calendário, e-mail)
Orquestração (regras, políticas, sequenciamento de passos)
Memória/estado (o que foi discutido antes, qual etapa do fluxo estamos)

Quando esses agentes entram no correio eletrónico de uma empresa, o risco deixa de ser “texto errado”. Vira “declaração feita”. É como trocar um estagiário por um autômato com acesso a uma fila de envio e poderes de decisão.

“Ninguém carregou em Enviar”: o problema não é o clique, é o controle

O ponto jurídico (e também técnico) raramente vai para o botão “Enviar”. O que importa é:

Quem autorizou aquele agente a enviar a mensagem?
Como a decisão foi tomada (automática? com validação? com limites?)
O que o sistema sabia naquele instante (condições ainda em discussão?)
Se houve rastreabilidade (logs, evidências, versões)

Do lado da engenharia, isso vira uma corrida por governance, auditoria e “human-in-the-loop” (quando fizer sentido).

Implicações legais na engenharia: contratos, consentimento e prova

Eu já vi times tratando “compliance” como checklist no final. Com agentes de e-mail, essa abordagem quebra. Porque você precisa provar:

Intenção: a resposta foi enviada como aceitação/confirmação?
Autoridade: o agente tinha permissão para concluir/confirmar?
Conhecimento: as informações usadas estavam atualizadas e refletiam o estado real da negociação?
Rastreio: existe log do evento, do contexto e da política aplicada?

Mesmo sem entrar em legislação específica (varia por país e contrato), o desenho técnico que você escolhe vai virar evidência. E evidência ruim quase sempre pesa contra você.

O que a arquitetura precisa garantir para não transformar IA em “aceitação automática”

Na minha experiência, dá para reduzir bastante esse risco com três pilares: limites, verificação e auditoria.

1) Limites: o agente não pode “inventar” autoridade

Se o agente tiver acesso ao e-mail, ele precisa operar dentro de um domínio. Algumas estratégias reais:

Escopo por tipo de mensagem: ele pode responder dúvidas, mas não pode “fechar acordo”.
Guards por etapa do funil: só dispara mensagens de aceitação quando o CRM indicar status “Acordo concluído”.
Campos vinculados a dados: em vez de “confirmar condições”, ele deve preencher frases com base em valores vindos do contrato final (ou do draft aprovado).

2) Verificação: “human-in-the-loop” no ponto crítico

Uma armadilha comum é colocar approval em tudo. Você perde velocidade e o time “desliga” o processo. O que funciona melhor é aprovar apenas ações irreversíveis, como:

Enviar e-mail que contenha linguagem de “aceitação”, “confirmamos o acordo”, “contrato fechado”
Acionar mudanças em sistemas financeiros ou de faturação
Registrar compromisso em CRMs/ERPs como “concluído”

Na prática: o agente prepara o rascunho, mas você exige validação antes do disparo quando detecta termos de compromisso.

3) Auditoria: logs que respondem “por quê” e “com quê”

Se der ruim, você vai precisar responder: “quem autorizou” e “com base no quê”. Isso significa log estruturado:

Identificador do agente e versão do prompt/workflow
Timestamp do gatilho
Fontes consultadas (e snapshots)
Decisão tomada + score de confiança (mesmo que heurístico)
Políticas aplicadas (ex.: guardrails de etapa do funil)

Sem isso, “foi a IA” vira frase vazia. E vazia é exatamente o que não ajuda em disputa.

Comparação direta: alternativas reais quando você quer reduzir risco

Quando o objetivo é automatizar atendimento sem criar risco contratual, existem caminhos:

Abordagem A: apenas rascunho (sem envio automático)

Eu prefiro começar por aqui. O agente escreve o e-mail e o humano revisa e clica. O risco cai, mas você perde automação total.

Prós: segurança imediata; fácil de auditar
Contras: fluxo operacional mais lento

Abordagem B: envio automático, mas com classificação de intenção

O agente pode enviar automaticamente apenas mensagens classificadas como “resposta informativa”. Se a intenção for “aceitação/fechamento”, ele para e pede aprovação.

Prós: automação onde dá
Contras: precisa de boa detecção e de dados de estado

Abordagem C: “contrato final vindo do sistema”, não do texto do modelo

Ao invés do LLM “decidir o que foi acordado”, você muda a regra: o conteúdo legal é montado a partir de campos aprovados. O modelo só formata e adapta linguagem, mas não altera valores.

Prós: reduz alucinação e discrepância
Contras: mais trabalho de modelagem de dados

Na Prática: um workflow seguro para agente de e-mail

Vou mostrar um exemplo simples (mas funcional) de como eu desenho o guardrail: bloquear envio automático quando a mensagem contém linguagem de aceitação, salvo se o contrato estiver no status final no CRM.

Passo a passo

O agente recebe o e-mail do cliente.
Ele consulta o estado do contrato no CRM (ex.: draft, revisão, final).
Ele gera um rascunho com base em políticas e no contexto.
Ele detecta intenção: é “aceitação/fechamento” ou “informação/dúvida”?
Se for crítico (aceitação) e o status não estiver “FINAL”, ele pede aprovação humana.
Se estiver FINAL, ele pode enviar (ainda com logs).

Código exemplo (Node.js) com regra de bloqueio

import fetch from "node-fetch";

function detectAcceptanceLanguage(text) {
  const patterns = [
    /consideramos\s+o\s+acordo/i,
    /acordo\s+celebrado/i,
    /contrato\s+aceito/i,
    /está\s+aprovado/i,
    /aceitamos/i,
    /fechado/i,
  ];
  return patterns.some(r => r.test(text));
}

async function getContractStatus(contractId) {
  const res = await fetch(`https://crm-api.exemplo.com/contracts/${contractId}`, {
    headers: { "Authorization": `Bearer ${process.env.CRM_TOKEN}` }
  });
  if (!res.ok) throw new Error("Falha ao consultar CRM");
  const data = await res.json();
  return data.status; // "DRAFT" | "REVIEW" | "FINAL"
}

async function decideAndSend({ contractId, emailReplyText, draftHtml, sendFn }) {
  const contractStatus = await getContractStatus(contractId);
  const isAcceptance = detectAcceptanceLanguage(emailReplyText);

  // Regra crítica: linguagem de aceitação só pode ser confirmada quando o status é FINAL
  if (isAcceptance && contractStatus !== "FINAL") {
    return { action: "HUMAN_APPROVAL_REQUIRED", contractStatus };
  }

  // Caso não seja crítico, pode enviar automaticamente (exemplo simplificado)
  await sendFn({
    to: "cliente@dominio.com",
    subject: "Re: Acordo e condições",
    html: draftHtml
  });

  return { action: "SENT", contractStatus };
}

// Exemplo de uso
const sendFn = async (payload) => {
  // Aqui você chamaria sua integração real do e-mail (SMTP/Gmail API/Graph API)
  console.log("Enviando e-mail:", payload.subject);
};

const result = await decideAndSend({
  contractId: "CNT-123",
  emailReplyText: "Perfeito. Consideramos o acordo celebrado.",
  draftHtml: "<p>Obrigado. Estamos revisando os detalhes finais.</p>",
  sendFn
});

console.log(result);

Por que isso é importante? Porque a regra não depende apenas do que o LLM “acha”. Ela amarra intenção (heurística) + estado do contrato (fonte de verdade). E quando diverge, você interrompe o fluxo antes de enviar.

Erros Comuns (e por que devs fazem isso)

1) Deixar o agente enviar sem uma etapa de validação para mensagens críticas

Eu vejo muito: “vamos automatizar 100% do e-mail”. Funciona até o dia em que aparece uma frase ambígua do cliente e o agente entende “aceitação” como “confirmado”. O custo operacional supera a economia.

2) Confiar no texto gerado sem amarrar em dados aprovados

Se você deixa o LLM “recontar o acordo” com base em contexto incompleto, você cria divergência. E divergência vira briga. Sempre que houver impacto legal, o conteúdo precisa vir de um estado aprovado (CRM/contrato final).

3) Não armazenar logs e snapshots

Sem logs, você não consegue reconstruir a sequência. E sem snapshots das fontes consultadas, você não prova “o que a IA sabia naquele momento”. Eu já ajustei pipelines assim depois de incidentes. Dá trabalho, mas é o tipo de trabalho que evita que você pague com tempo e dinheiro.

4) Guardrails apenas no prompt

Prompt não é segurança. Prompt é sugestão. Segurança de verdade é validação antes da ação (policy engine) e checagem pós-geração (conteúdo e intenção). Se alguém trocar o prompt ou ajustar temperatura, o risco muda.

5) Falhar em tratar “conteúdo ambíguo” do cliente

Resposta curta como “perfeito” pode ser aprovação, mas também pode ser empolgação. A detecção tem que considerar contexto: etapa do funil, histórico de negociação e status de assinatura. Heurística sozinha não resolve.

Como eu definiria o “contrato de confiança” entre agente e sistemas

Quando eu coloco AI Agent em produção, eu trato como integração de segurança. Eu definio:

Quais ações são permitidas (ex.: responder, marcar reunião, gerar rascunho)
Quais ações exigem aprovação (ex.: envio confirmatório com linguagem de aceitação)
Fontes de verdade (ex.: CRM para status, repositório de contrato final para cláusulas)
Como falha (fallback para “rascunho” e não para “enviar”)

Isso reduz o efeito “bola de neve” que acontece quando o agente tem autonomia demais.

FAQ

Quem responde quando um AI Agent envia um e-mail “por conta própria”?

Em geral, a responsabilidade tende a envolver a empresa operadora do sistema (por falha de controle/gestão) e eventuais fornecedores, dependendo do contrato e do grau de automação. Tecnicamente, a chave é provar políticas, logs e autorização para aquela ação.

Como impedir que a IA responda com linguagem de “aceitação” quando a negociação não terminou?

Eu uso uma combinação de: (1) checagem do status no CRM (ex.: só “FINAL” permite), (2) detecção de intenção/termos no texto e (3) bloqueio do envio automático com “HUMAN_APPROVAL_REQUIRED”.

Vale a pena automatizar envio de e-mail 100%?

Na minha experiência, não para mensagens com potencial contratual. Automatize rascunho, responda dúvidas e faça triagem. Para “fechamento”, exija aprovação humana ou gere confirmação apenas com dados do contrato final.

Guardrails no prompt são suficientes?

Não. Prompt reduz erros, mas não garante segurança. Você precisa de políticas executadas no código antes de disparar ações externas e de validações com fontes de verdade.

Como posso auditar o que a IA fez?

Registre: versão do workflow/prompt, timestamp do gatilho, dados consultados (com snapshot), decisão do agente e justificativa (por exemplo: status do contrato e intenção detectada). Isso transforma “foi a IA” em evidência.

Se tem uma lição que eu reforço: autonomia sem governança vira risco. O cenário do Sapo.pt é hipotético, mas a engenharia por trás dele já está ao alcance de qualquer time que conecte um agente ao e-mail. Quem ganha não é a IA mais “esperta”. É a arquitetura que sabe quando a IA deve parar.

Gostou? Me segue no GitHub e deixa um comentário se tiver dúvida ou quiser aprofundar algum ponto.