Como criar um agente de IA para atendimento ao cliente

Para criar um agente de IA para atendimento ao cliente, comece com um problema restrito, organize uma base de conhecimento confiável, limite as ferramentas disponíveis e defina quando o atendimento deve passar para uma pessoa. Se ainda estiver escolhendo a tecnologia, compare primeiro agente de IA e chatbot. Depois, teste o sistema com casos reais anonimizados antes de permitir contato direto com clientes.

O primeiro agente não precisa resolver todo o atendimento. Um piloto mais seguro pode responder perguntas frequentes, consultar informações não sensíveis e preparar um resumo para a equipe. Ações como cancelar pedidos, conceder reembolsos, alterar cadastros ou assumir compromissos comerciais devem ser adicionadas apenas quando regras, permissões e validações estiverem maduras.

Este guia apresenta uma arquitetura simples e um passo a passo independente de fornecedor. A implementação técnica varia conforme a plataforma, mas os princípios de conteúdo, segurança e avaliação continuam os mesmos.

O que um agente de atendimento realmente faz?

Um agente de atendimento combina conversa com execução de tarefas. Ele interpreta a solicitação, consulta informações, decide o próximo passo e pode utilizar ferramentas autorizadas para concluir ou encaminhar o caso.

Imagine um cliente perguntando onde está o pedido. Um chatbot básico pode fornecer um link para rastreamento. Um agente pode solicitar o número do pedido, consultar o sistema, verificar o status, explicar a etapa atual e registrar a interação. Se detectar atraso fora do padrão, pode encaminhar o caso com contexto para uma pessoa.

Segundo o guia prático da OpenAI, um agente utiliza um modelo para conduzir o fluxo de trabalho e ferramentas para buscar dados ou executar ações. A Anthropic recomenda começar pela solução mais simples e aumentar a complexidade apenas quando o problema exigir decisões mais flexíveis.

Essa distinção é importante: nem todo atendimento precisa de um agente. Perguntas previsíveis podem ser resolvidas com FAQ, busca ou fluxo baseado em regras. O agente faz sentido quando a conversa exige contexto, escolha entre caminhos e acesso controlado a informações externas.

Arquitetura básica de um agente de atendimento

Um projeto funcional pode ser dividido em oito componentes.

1. Canal de entrada

É onde a conversa acontece: site, aplicativo, WhatsApp, e-mail ou voz. O canal deve preservar contexto suficiente e informar claramente quando o cliente está interagindo com um sistema automatizado.

2. Identificação e sessão

O sistema precisa saber o que pode ser respondido sem identificar a pessoa e quando é necessária autenticação. Informar prazo de entrega geral não exige os mesmos controles que mostrar dados de um pedido.

3. Instruções do agente

As instruções definem função, tom, fontes permitidas, ações disponíveis e limites. Elas também estabelecem como agir quando faltam informações ou quando o cliente pede algo fora do escopo.

4. Base de conhecimento

Contém políticas, manuais, perguntas frequentes, catálogo, horários e procedimentos aprovados. A arquitetura publicada pelo Google Cloud para suporte utiliza recuperação de informações relevantes antes da geração da resposta, um padrão conhecido como RAG.

5. Ferramentas

São funções que permitem consultar ou alterar sistemas. Uma ferramenta de leitura pode verificar status de pedido. Uma ferramenta de ação pode abrir chamado, atualizar CRM ou enviar mensagem. Ferramentas de ação exigem controles mais fortes.

6. Regras e proteções

Definem permissões, validações, proibições e confirmações. O agente não deve confiar apenas em uma instrução textual para impedir operações críticas; o próprio sistema precisa bloquear o que não é permitido.

7. Escalonamento humano

É a passagem organizada para uma pessoa, incluindo conversa, dados relevantes, tentativas realizadas e motivo do encaminhamento.

8. Registros e avaliações

Logs ajudam a entender quais fontes e ferramentas foram utilizadas. Avaliações medem respostas, decisões e resultados antes e depois da publicação.

Passo 1: defina um caso de uso pequeno

Evite começar com “atender qualquer pergunta”. Escolha uma tarefa com volume suficiente, regras claras e baixo impacto em caso de erro.

Bons pilotos incluem:

• responder dúvidas sobre horário, entrega e funcionamento;
• explicar uma política aprovada;
• consultar status sem alterar o pedido;
• coletar informações para orçamento;
• classificar o assunto e encaminhar;
• resumir a conversa para o atendente.

Descreva o resultado esperado em uma frase: “O agente deve responder dúvidas de entrega usando apenas a política publicada e encaminhar exceções”. Essa definição ajuda a rejeitar recursos que não pertencem ao primeiro ciclo.

Também registre o que fica fora: reembolso, alteração de endereço, disputa de cobrança, negociação, orientação jurídica, diagnóstico ou qualquer decisão que exija autoridade humana.

Passo 2: desenhe a conversa e as saídas

Mapeie como o atendimento funciona hoje. Para cada tipo de solicitação, anote:

1. informação necessária;
2. fonte consultada;
3. regra aplicada;
4. ação permitida;
5. condição de encerramento;
6. condição de escalonamento.

Esse mapa não precisa prever cada frase do cliente. Ele identifica estados importantes. Em um pedido de entrega, os estados podem ser: sem número do pedido, pedido encontrado, pedido em trânsito, atraso, endereço divergente e encaminhamento.

Defina respostas para ausência de informação. Se o agente não encontrar a política, deve dizer que não conseguiu confirmar e encaminhar — não completar a resposta com conhecimento geral.

Passo 3: prepare uma base de conhecimento confiável

O agente não deve aprender as regras da empresa a partir de páginas desatualizadas, conversas aleatórias ou documentos contraditórios. Antes da tecnologia, organize o conteúdo.

Para cada documento, registre:

• título e assunto;
• responsável;
• data de revisão;
• período de validade;
• público ou produto aplicável;
• versão atual;
• substituições e exceções.

Prefira textos diretos e modulares. Uma política de troca deve explicar prazo, condições, itens excluídos, procedimento e canal de ajuda. Se a regra depender do produto ou local, essa condição precisa estar explícita.

Durante a resposta, o agente deve recuperar trechos relevantes e trabalhar com eles. Quando possível, apresente ao atendente ou ao cliente a fonte utilizada. Isso facilita conferência e correção.

Passo 4: separe ferramentas de leitura e de ação

Nem toda integração tem o mesmo risco. Classifique as ferramentas antes de conectá-las.

Tipo	Exemplos	Controle recomendado
Leitura pública	horários, catálogo, políticas	acesso restrito à fonte aprovada
Leitura autenticada	pedido, assinatura, chamado	autenticação e acesso mínimo
Registro reversível	criar ticket, adicionar nota	validação dos campos e log
Comunicação externa	enviar e-mail ou mensagem	preview e confirmação
Alteração importante	cancelar, reembolsar, mudar cadastro	aprovação humana obrigatória
Ação crítica	pagamento, exclusão, acesso privilegiado	fora do piloto ou controle especializado

Comece com leitura e preparação de rascunhos. Quando uma ferramenta de ação for adicionada, valide entradas no código, não apenas na conversa. Um reembolso, por exemplo, deve respeitar limites e permissões mesmo que o modelo tente enviar outro valor.

Passo 5: escolha entre fluxo e agente

Um fluxo utiliza caminhos definidos previamente; um agente escolhe dinamicamente como avançar. A Anthropic diferencia essas arquiteturas e recomenda fluxos para tarefas previsíveis, reservando agentes para situações em que flexibilidade e decisão orientada pelo modelo agregam valor.

O atendimento pode combinar os dois:

• regras verificam identidade e permissão;
• o agente interpreta a solicitação;
• uma busca recupera a política;
• código valida os dados;
• uma pessoa aprova exceções.

Essa arquitetura híbrida é frequentemente mais segura que entregar todo o processo ao modelo.

Ao avaliar uma plataforma, confirme suporte a base de conhecimento, integrações, permissões, logs, testes, versionamento, transferência humana, privacidade e exportação de dados. Evite escolher apenas pela qualidade de uma demonstração preparada.

Passo 6: escreva instruções operacionais

Uma instrução útil precisa ser específica sobre função e limites. Um exemplo inicial:

> Você é o agente de suporte da Empresa Exemplo. Responda dúvidas sobre entrega usando somente as fontes recuperadas da base aprovada. Antes de consultar um pedido, solicite o identificador previsto no fluxo de autenticação. Não altere pedidos, não prometa prazos diferentes dos retornados pelo sistema e não invente informações ausentes. Encaminhe para uma pessoa quando houver atraso fora da política, risco de fraude, reclamação grave, solicitação financeira ou falta de fonte confiável. Ao encaminhar, produza um resumo com solicitação, dados já verificados, fontes consultadas e motivo.

Inclua exemplos de casos normais e exceções. Diga como responder quando duas fontes discordam. Defina o tom sem instruções vagas como “seja perfeito” ou “resolva tudo”.

As instruções não substituem controles técnicos. Elas orientam o comportamento; permissões e validações determinam o que o sistema realmente consegue fazer.

Passo 7: trate identidade, privacidade e LGPD

Dados pessoais devem ser usados conforme finalidade, necessidade e base legal aplicável. O regulamento da ANPD para agentes de pequeno porte não elimina obrigações de transparência, segurança e atendimento aos direitos dos titulares.

No projeto, responda:

• quais dados entram na conversa;
• quais são necessários para cada função;
• onde são armazenados;
• por quanto tempo permanecem;
• quais fornecedores os processam;
• quem pode acessar os registros;
• como o cliente exerce seus direitos;
• como incidentes serão tratados.

Não solicite CPF, documento, dados bancários ou informações sensíveis por hábito. Se a tarefa puder ser resolvida com número de pedido e validação adequada, não peça mais dados.

Avalie também como o fornecedor utiliza conversas para treinamento, quais controles empresariais oferece e se permite retenção compatível com a política da organização.

Passo 8: crie um escalonamento humano de verdade

Mostrar “fale com um atendente” sem transferir contexto cria frustração. O escalonamento deve informar disponibilidade, preservar o histórico necessário e explicar o próximo passo.

Encaminhe quando:

• o agente não encontra fonte confiável;
• o cliente repete a solicitação sem solução;
• existe reclamação grave ou linguagem de risco;
• a situação foge da política;
• há dados divergentes;
• a ação exige aprovação;
• o próprio cliente pede uma pessoa.

O resumo de transferência deve ser curto e verificável. Não inclua conclusões emocionais ou diagnósticos. Registre fatos, ferramentas consultadas e pontos pendentes.

Passo 9: teste respostas, ferramentas e falhas

Um agente não pode ser avaliado apenas com cinco perguntas fáceis. Ele opera em várias etapas, usa ferramentas e modifica estado. A Anthropic recomenda avaliações que cubram o caminho completo, incluindo reembolsos, cancelamentos e escalonamentos em cenários de suporte.

Monte um conjunto com:

• perguntas comuns formuladas de maneiras diferentes;
• dados ausentes;
• políticas parecidas;
• informação desatualizada;
• tentativa de obter dados de outra pessoa;
• pedido fora do escopo;
• falha ou lentidão de ferramenta;
• instrução maliciosa dentro de uma mensagem ou documento;
• cliente que exige atendimento humano;
• ação que requer confirmação.

Para cada caso, defina o comportamento esperado. Avalie se a resposta está apoiada na fonte, se a ferramenta correta foi usada, se os dados estão protegidos e se o encaminhamento aconteceu no momento certo.

Passo 10: faça um piloto assistido e meça

Antes de liberar autonomia, coloque o agente ao lado da equipe. Ele pode sugerir respostas e resumos enquanto uma pessoa decide o que enviar. Esse modo revela lacunas da base com risco menor.

Depois, libere um grupo pequeno de intenções. Acompanhe:

• precisão em amostras revisadas;
• porcentagem de casos encaminhados;
• motivos de escalonamento;
• tempo total até a solução;
• correções feitas pela equipe;
• falhas por ferramenta;
• reclamações e satisfação;
• tentativas bloqueadas por segurança;
• custo por atendimento concluído.

Não trate taxa alta de automação como objetivo isolado. Encaminhar corretamente um caso difícil pode ser melhor que encerrá-lo com uma resposta errada.

Checklist antes de publicar

• [ ] O caso de uso e o que está fora dele estão documentados.
• [ ] A base possui responsáveis e datas de revisão.
• [ ] As fontes conflitantes foram corrigidas.
• [ ] Ferramentas têm permissões mínimas.
• [ ] Ações importantes exigem confirmação.
• [ ] O agente sabe quando parar.
• [ ] O atendimento humano recebe contexto.
• [ ] Dados pessoais foram avaliados conforme a LGPD.
• [ ] Existem logs e processo de correção.
• [ ] Casos normais, exceções e ataques foram testados.
• [ ] Há responsável pelo acompanhamento depois do lançamento.

Perguntas frequentes

Preciso programar para criar um agente de atendimento?

Não necessariamente. Existem plataformas com configuração visual. Entretanto, integrações, autenticação, validação e ações importantes podem exigir suporte técnico. A ausência de código na interface não elimina a necessidade de arquitetura e testes.

Posso usar o conteúdo do meu site como base?

Sim, desde que esteja correto, atualizado e claramente organizado. Páginas promocionais nem sempre contêm detalhes suficientes para resolver casos de suporte. Políticas e procedimentos internos podem precisar de uma base separada.

O agente pode atender pelo WhatsApp?

Pode quando a plataforma e a integração utilizada respeitam as regras do canal. Também é necessário planejar identificação, consentimento, transferência humana e tratamento dos dados recebidos.

Como impedir respostas inventadas?

Use fontes recuperadas de uma base aprovada, instrua o agente a declarar ausência de informação, restrinja o escopo e teste. Nenhuma técnica elimina todos os erros; por isso, casos sensíveis precisam de revisão ou encaminhamento.

Quando liberar ações automáticas?

Depois que o comportamento em modo assistido estiver medido, as regras estiverem estáveis e a ação for reversível ou protegida por confirmação. Comece com operações de baixo impacto.

Um agente substitui a equipe de atendimento?

Ele pode assumir tarefas repetitivas e preparar contexto, mas pessoas continuam necessárias para exceções, decisões, empatia, melhoria da base e supervisão. O projeto deve melhorar o serviço, não apenas esconder o acesso ao atendimento humano.

Comece com respostas confiáveis e ações limitadas

O primeiro agente de atendimento deve ser pequeno o suficiente para ser compreendido. Uma base revisada, ferramentas de leitura e escalonamento claro produzem um piloto mais útil que uma promessa de resolver qualquer assunto.

Desenhe um único fluxo, selecione vinte ou trinta casos representativos e teste em modo interno. Quando a equipe souber explicar por que o agente respondeu, qual fonte utilizou e quando decidiu encaminhar, haverá uma base mais segura para ampliar o projeto.

Fontes consultadas

• OpenAI — A practical guide to building agents
• Anthropic — Building effective agents
• Anthropic — Demystifying evals for AI agents
• Google Cloud — Arquitetura de IA generativa para suporte ao cliente
• NIST — AI Risk Management Framework
• ANPD — Regulamento da LGPD para agentes de tratamento de pequeno porte
• ANPD — Guia de Segurança da Informação para agentes de pequeno porte