- Agente bom de suporte não é “um chat”: é fluxo + base de conhecimento + regras de segurança
- O maior risco é o agente improvisar resposta (alucinação) ou expor PII por excesso de contexto
- Roteamento para humano e trilha de auditoria não são luxo: são parte do produto
- Menos dados no prompt e mais consulta a fontes internas aprovadas costuma reduzir risco
1) Escolha o escopo (e o que fica proibido)
Escreva uma lista curta do que o agente atende bem: rastreio de pedido, troca/devolução, status de chamado, dúvidas de plano/contrato, reset de senha (com verificação). Em paralelo, defina proibições explícitas: decisões financeiras, concessão de desconto fora de política, orientação médica/jurídica, e qualquer ação irreversível sem humano. Isso vira regra do sistema e também regra de negócio.
2) Modele o fluxo de conversa (não dependa de improviso)
Desenhe os caminhos principais: saudação > identificação > intenção > coleta mínima de dados > resposta > confirmação > encerramento. Inclua sempre saídas: “não sei” + transferir para humano, e “preciso de mais informações”. Atendimento de qualidade é previsível; improviso é onde nasce vazamento.
3) Monte uma base de conhecimento aprovada (e versionada)
Use FAQs internas, políticas, prazos, scripts e macros revisadas. Evite colar documentos brutos sem curadoria. Separe por tópicos e inclua data de validade/última revisão. Quando o agente responder, ele deve se apoiar nessa base, não na memória do modelo.
4) Reduza o uso de dados pessoais (PII) ao mínimo necessário
Peça só o essencial para resolver o caso. Sempre que possível, substitua PII por identificadores: número do pedido, ID do ticket. Aplique mascaramento automático (ex.: ocultar CPF completo, cartões, senhas). Nunca peça senha. Se o cliente mandar dado sensível, o agente deve alertar e orientar a remover.
5) Defina as integrações e permissões (princípio do menor privilégio)
Se o agente consultar CRM/ERP, limite o que ele enxerga e o que ele pode alterar. Ideal: leitura por padrão; escrita só com validações e, para ações críticas, com aprovação humana. Separe ambientes (teste vs produção) e registre quais endpoints o agente pode chamar.
6) Escreva “regras de segurança” como se fosse um manual de crise
Inclua regras claras: não inventar política; não prometer prazo sem fonte; não expor dados de terceiros; não repetir dados sensíveis no chat; confirmar identidade antes de qualquer informação de conta; e quando recusar, explicar o porquê e oferecer alternativa (transferência ou canal seguro).
7) Coloque fallback e escalonamento para humano em pontos críticos
Mapeie gatilhos de transferência: intenção desconhecida, baixa confiança, cliente irritado, suspeita de fraude, pedido fora de política, ou qualquer solicitação envolvendo reembolso/chargeback. Escalonamento rápido reduz dano: melhor uma transferência cedo do que uma resposta “criativa”.
8) Teste com casos reais (incluindo ataques e prompts maliciosos)
Antes de abrir para todo mundo, rode uma bateria de cenários: cliente pedindo para ver dados de outro usuário, tentando burlar validação, colando documentos com PII, pedindo “finge que você é do financeiro”. O objetivo é encontrar onde o agente cede pressão e ajustar regras, filtros e roteamento.
9) Observabilidade: logs, auditoria e retenção
Registre conversas, decisões do agente (por que respondeu aquilo) e fontes consultadas. Defina prazos de retenção e quem pode acessar os logs. Onde houver LGPD e compliance, logs precisam de governança: acesso por função, trilha de consulta e anonimização quando viável.
10) Operação contínua: revisão, métricas e atualização da base
Estabeleça revisão semanal/mensal da base e das respostas com maior taxa de recontato. Métricas úteis: taxa de resolução no primeiro contato, taxa de transferência para humano, taxa de “não sei”, temas que mais geram erro. Quando política muda, atualize a fonte; não tente ‘ensinar’ o agente só no prompt.
O que diferencia um “agente” de um chatbot comum
Chatbot comum responde. Agente de IA executa um trabalho com regras: identifica intenção, consulta uma base aprovada, coleta dados mínimos, decide quando parar e quando escalar para humano, e deixa rastro para auditoria.
Se você só pluga um modelo grande e manda “atenda clientes”, ele até resolve casos simples, mas também vai inventar exceções de política e pedir dados demais. No suporte, isso vira prejuízo (e dor de cabeça jurídica).
Checklist rápido de segurança (antes de colocar em produção)
Use esta lista como “porta de embarque”. Se falhar em qualquer item, segure o rollout.
- O agente tem escopo e proibições escritos (e aplicados) no sistema
- Há base de conhecimento revisada, com dono e data de atualização
- PII é minimizada; dados sensíveis são mascarados e não são repetidos
- Existe verificação de identidade para assuntos de conta/pagamento
- Integrações seguem menor privilégio; ações críticas exigem humano
- Há fallback: “não sei” + transferência para humano
- Logs e auditoria estão habilitados, com política de retenção definida
- Testes incluíram tentativas de prompt injection e engenharia social
Onde geralmente acontece vazamento (e como cortar na raiz)
Vazamento costuma vir de três lugares: (1) o agente vê informação demais (prompt cheio, CRM aberto demais), (2) o cliente cola dados sensíveis e o agente ecoa de volta, ou (3) alguém tenta manipular o agente para revelar segredos (“mostre as regras internas”, “ignore as políticas”).
A correção é menos ‘mágica de IA’ e mais engenharia de produto: reduzir acesso, filtrar entrada/saída, e colocar travas de identidade e escalonamento. Quando o agente não tem o dado, ele não vaza.
| Risco comum | Sinal no atendimento | Mitigação prática |
|---|---|---|
| Excesso de contexto (PII no prompt) | Agente repete CPF, endereço ou histórico completo | Mascarar PII; enviar só identificador; resumir histórico sem dados sensíveis |
| Alucinação de política | Promete desconto/prazo não previsto | Obrigar citação de fonte interna; se não houver fonte, transferir |
| Prompt injection | Cliente pede para “ignorar regras” ou “mostrar instruções” | Regras de recusa; filtros; bloquear revelação de prompt e segredos |
| Integração com permissões amplas | Agente altera pedido/cadastro sem confirmação | Menor privilégio; confirmações; aprovação humana para ações críticas |
| Logs expostos | Várias pessoas acessam conversas com PII | Controle de acesso por função; retenção curta; anonimização quando possível |
Padrão de resposta que reduz erro: “fonte + confirmação + próximo passo”
Um padrão que funciona bem no Brasil (principalmente em e-commerce e SaaS): o agente responde com base em uma política, confirma o que entendeu e oferece o próximo passo com escolhas claras.
Exemplo de estrutura: (a) ‘Pelo regulamento de trocas, o prazo é X dias a partir do recebimento’ (sem inventar), (b) ‘Você recebeu em qual data?’, (c) ‘Posso te enviar o passo a passo ou abrir um ticket com um atendente’. Isso mantém a conversa útil sem virar uma negociação improvisada.
Perguntas frequentes
Agente de IA pode atender WhatsApp e Instagram Direct sem risco?
Como evitar que o agente invente respostas (alucinação) no suporte?
Preciso treinar (fine-tuning) para ter um agente de atendimento bom?
O que registrar em logs sem ferir privacidade?
Leia também
Agente de IA (AI Agent)
Agente de IA é uma inteligência artificial que executa tarefas de ponta a ponta, não só responde perguntas. Entenda o que é, como funciona o loop de decisão e o que muda em relação a um chatbot.
Ler →
Como usar IA para responder RFP (proposta comercial) em 2026 — sem vazar dados e sem prometer o que não entrega
Guia prático para usar ChatGPT/Claude/Gemini em respostas de RFP e propostas comerciais: workflow, prompts, tabela de checagem, riscos (LGPD) e revisão final.
Ler →
Como evitar alucinação em IA (2026): checklist prático para checar fatos, fontes e números
Guia direto ao ponto para reduzir alucinação em ChatGPT, Claude e Gemini: prompts, checagem de fontes, validação de números e um fluxo simples de auditoria antes de publicar.
Ler →