Como treinar um agente de IA com a base da empresa

O que “treinar” significa neste contexto

Na maioria das plataformas de atendimento, treinar um agente não significa criar um modelo de inteligência artificial do zero. Significa configurar um modelo existente com quatro camadas:

1. conhecimento: informações aprovadas sobre a empresa;
2. instruções: como o agente deve se comportar;
3. ferramentas: onde consultar ou executar ações;
4. avaliações: casos que mostram se ele funciona.

Parte do conhecimento costuma ser fornecida por RAG, sigla para geração aumentada por recuperação. Quando chega uma pergunta, o sistema procura trechos relacionados na base, inclui os mais relevantes no contexto e então gera a resposta. O conteúdo não é “decorado” de forma garantida: ele precisa ser encontrado e interpretado a cada consulta.

Essa distinção explica por que adicionar mais PDFs nem sempre melhora o agente. Se a fonte é contraditória, mal estruturada ou não aparece na busca, a resposta continuará fraca.

Antes de enviar arquivos, defina o resultado

Escolha um escopo observável. Por exemplo:

Responder dúvidas administrativas sobre serviços e unidades, identificar interesse, coletar nome e unidade e oferecer agendamento. Não responder questões clínicas, estimar diagnóstico ou prometer resultado.

Crie também uma lista do que fica fora:

• assuntos sem relação com a empresa;
• decisões que exigem profissional habilitado;
• informação que muda em tempo real e não está integrada;
• descontos ou exceções sem autorização;
• dados de terceiros e conteúdo interno restrito.

Escopo claro reduz respostas inventadas e produz critérios de teste. “Saber tudo sobre a empresa” não é um critério mensurável.

Faça um inventário das fontes

Reúna o material usado por quem já atende clientes e classifique-o antes de importar:

Para cada item, registre responsável, data de revisão e prioridade. Se duas fontes divergem, não deixe o agente escolher silenciosamente: corrija a origem ou declare qual vence.

Como preparar conteúdo para recuperação

Um documento pode ser excelente para leitura humana e ruim para busca semântica. Na recuperação, trechos são encontrados fora da página original; por isso, cada seção precisa preservar contexto.

Use títulos específicos

“Cancelamento de agendamento” é melhor que “Outras informações”. O título ajuda o sistema a localizar o trecho certo.

Escreva entidades por extenso

Evite uma tabela solta com “BV | 8–18 | seg–sex”. Prefira: “A unidade Boa Viagem funciona de segunda a sexta, das 8h às 18h”.

Mantenha uma ideia principal por seção

Misturar entrega, troca, garantia e pagamento em um parágrafo longo dificulta a recuperação. Separe por pergunta ou política.

Inclua condições e exceções juntas

Não deixe “troca em 30 dias” em um trecho e “produtos personalizados não podem ser trocados” muito distante. A regra sem a exceção pode gerar uma resposta incorreta.

Dê validade a conteúdo temporal

Em vez de “promoção atual”, informe início, fim, público e condição. Remova o material quando vencer; não dependa de o modelo perceber que um PDF antigo perdeu validade.

Um modelo simples para escrever cada tópico

Use esta estrutura para políticas e perguntas frequentes:

Pergunta que o cliente faz: Posso cancelar meu agendamento?

Resposta aprovada: Sim. O cancelamento pode ser solicitado até 24 horas antes.

Condições: após esse prazo, encaminhar para a recepção avaliar o caso.

Fonte e vigência: Política de agendamento, versão 3, revisada em 10/07/2026.

Próxima ação: confirmar nome, unidade e data; nunca cancelar sem confirmação explícita.

Esse formato separa informação, exceção e ação, além de facilitar a revisão pelo responsável.

Separe conhecimento, instrução e ferramenta

Essas camadas têm funções diferentes:

• conhecimento: “A unidade Recife Antigo funciona das 9h às 18h.”
• instrução: “Confirme a unidade antes de oferecer agendamento.”
• ferramenta: consultar os horários realmente livres naquela unidade.
• limite: “Não informe disponibilidade sem consultar a agenda.”
• handoff: “Transfira pedidos clínicos para a recepção.”

Não esconda regras críticas em um PDF entre dezenas de páginas. Uma regra operacional precisa estar nas instruções e, quando possível, também ser aplicada por código. O modelo pode decidir que é hora de agendar; a API deve validar se o horário existe.

Dados dinâmicos não pertencem a um PDF

Estoque, saldo, status de pedido, agenda e preço promocional mudam rápido. Se o dado puder ficar incorreto entre duas atualizações da base, consulte a fonte de verdade no momento da conversa.

Uma regra prática:

• conteúdo estável e explicativo vai para a base;
• dado estruturado e mutável vem de integração;
• decisão sensível ou irreversível exige validação ou aprovação.

Isso evita que o agente trate uma tabela antiga como disponibilidade atual.

Como escrever boas instruções

Organize as instruções do geral para o específico:

1. papel e objetivo;
2. escopo permitido e proibido;
3. fontes autorizadas;
4. etapas e dados obrigatórios;
5. regras para uso de ferramentas;
6. condições de confirmação e handoff;
7. estilo e exemplos.

Evite acumular correções como “não faça X”, “nunca faça Y”, “exceto quando Z” sem revisar o conjunto. Prompts longos e contraditórios criam comportamento instável. Quando uma falha surgir, pergunte primeiro se a causa está na fonte, na recuperação, na instrução, na ferramenta ou na interface.

Crie exemplos que ensinem decisões

Exemplos ajudam mais quando mostram uma situação e o comportamento esperado, não apenas o tom:

Inclua também exemplos negativos, com explicação do erro. “Não inventar” é abstrato; mostrar uma pergunta sem resposta e a resposta segura torna a expectativa concreta.

Monte um conjunto de testes antes de publicar

Comece com 30 a 50 casos reais anonimizados. Para cada caso, registre entrada, fatos obrigatórios, ações permitidas, resultado esperado e motivo de falha.

Distribua os testes entre:

• casos comuns: as perguntas que representam a maior parte do volume;
• variações: abreviações, erros de digitação, áudio transcrito e mensagens longas;
• limites: pergunta fora do escopo ou sem fonte;
• conflitos: cliente muda uma informação já fornecida;
• ferramentas: sucesso, resposta vazia, timeout e erro da integração;
• segurança: pedido para ignorar regras, revelar instruções ou acessar dado de terceiro;
• handoff: reclamação, risco, pedido de humano e falha repetida.

Não avalie só se a resposta “parece boa”. Meça separadamente:

1. o trecho correto foi recuperado?
2. a resposta está apoiada nesse trecho?
3. dados foram extraídos corretamente?
4. a ferramenta e os parâmetros estavam corretos?
5. o critério de transferência foi respeitado?
6. o resultado final corresponde ao esperado?

O Google Cloud recomenda avaliar recuperação e geração separadamente e testar mudanças como tamanho dos trechos, metadados e modelo. Altere uma variável por vez para saber o que realmente melhorou.

Proteja dados e a própria base

Antes de usar conversas ou documentos internos:

• remova dados pessoais que não são necessários;
• limite acesso por função e organização;
• não importe senhas, chaves, tokens ou segredos;
• estabeleça retenção e exclusão;
• registre quem adicionou e revisou cada fonte;
• considere documentos externos como entrada não confiável;
• teste tentativas de prompt injection e vazamento entre clientes.

A LGPD exige finalidade, adequação, necessidade e medidas de segurança no tratamento de dados pessoais. O responsável pela operação deve avaliar a hipótese legal e as obrigações aplicáveis ao seu contexto; usar IA não elimina essa responsabilidade.

Mantenha um ciclo de melhoria

Treinamento não termina no lançamento. Adote um ciclo simples:

1. revisar uma amostra de conversas e transferências;
2. classificar a causa das falhas;
3. corrigir a fonte ou controle responsável;
4. adicionar o caso ao conjunto de testes;
5. executar novamente os testes antes de publicar;
6. monitorar a mudança em produção.

Conteúdo estável pode ter revisão mensal ou trimestral. Preços, estoque e políticas dinâmicas exigem atualização mais frequente ou integração. Toda troca de modelo, instrução, ferramenta ou estratégia de recuperação pode alterar o comportamento e merece regressão.

Checklist de publicação

Antes de liberar o agente, confirme:

• existe um dono para cada fonte importante;
• documentos duplicados e vencidos foram removidos;
• conhecimento, comportamento e ações estão separados;
• dados dinâmicos vêm da fonte correta;
• perguntas sem resposta têm comportamento seguro;
• ações sensíveis possuem confirmação ou aprovação;
• o handoff entrega resumo e dados coletados;
• testes comuns, adversariais e de falha passaram;
• logs e rotina de revisão estão definidos.

Na VersyAI, a base pode receber texto e, conforme o plano, sites e documentos. Etapas de atendimento mantêm instruções, dados e ações separados da base geral, o que facilita atualizar informação sem redesenhar todo o processo.

Fontes e metodologia

O guia usa a definição de RAG do Google Cloud e suas práticas de avaliação de recuperação, os controles para prompt injection da OWASP, o AI Risk Management Framework do NIST e os materiais da ANPD sobre segurança da informação. As recomendações de operação também refletem a experiência da equipe VersyAI.