Seu agente de IA está pronto para produção? Faça 30 testes antes do primeiro cliente

Uma demonstração costuma mostrar o caminho feliz: a pergunta vem completa, o cadastro está correto, o sistema responde e a IA encontra a informação esperada. A operação real faz o contrário. O cliente manda áudio incompleto, mistura dois pedidos, responde dias depois, usa outro CPF, pede uma exceção e escreve enquanto o ERP está indisponível.

Se o teste foi apenas “conversei dez minutos e pareceu bom”, a empresa não sabe se tem um agente pronto ou uma boa demonstração. Testar um agente de IA é verificar se ele produz o resultado certo, usa a fonte correta, executa apenas a ação permitida e transfere a exceção com contexto.

Este artigo entrega uma matriz de 30 casos que cabe numa planilha. Ela serve para atendimento, comercial, cobrança, agenda, obras, agro, imobiliárias e rotinas internas. Não depende de uma plataforma específica: começa no processo que o agente deverá operar.

O benchmark do modelo não testa a sua empresa

Em novembro de 2025, a OpenAI publicou um guia de avaliações para negócios com uma distinção importante: testes gerais ajudam a avaliar modelos, mas não capturam todas as nuances de um fluxo específico. A recomendação é transformar “bom atendimento” ou “follow-up útil” em exemplos e critérios próprios, construídos por pessoas que conhecem o processo e o domínio.

Um estudo com 306 profissionais e 20 estudos de caso em 26 domínios, realizado entre abril e novembro de 2025, encontrou a confiabilidade como principal desafio de desenvolvimento. Entre os agentes implantados analisados, 74% dependiam principalmente de avaliação humana. Isso não prova que revisão manual seja suficiente; mostra que o conhecimento de quem executa a rotina continua central mesmo em operações tecnicamente maduras.

Portanto, o primeiro conjunto de testes não deveria vir de uma lista genérica da internet. Ele deve nascer de pedidos reais, erros já ocorridos, regras da empresa e situações nas quais um colaborador experiente decide parar, perguntar ou escalar.

Antes dos casos, escreva o contrato de aceite

Escolha um resultado estreito, como “confirmar consultas e preencher o status da agenda” ou “classificar leads e criar a próxima tarefa no CRM”. Depois preencha seis campos:

1. entrada: quais dados podem chegar, por quais canais e em quais formatos;
2. estado final: o que precisa existir no sistema quando a tarefa termina;
3. fonte válida: qual cadastro, documento ou regra prevalece quando há conflito;
4. ação permitida: o que o agente pode consultar, sugerir, registrar ou enviar;
5. ponto de transferência: quando deve parar e para quem deve encaminhar;
6. evidência: qual log, protocolo, registro ou justificativa comprova o que aconteceu.

“Responder o cliente” não é um estado final. “Identificar a intenção, responder pela base aprovada, registrar categoria e resumo no CRM ou transferir com motivo” pode ser testado. O contrato também impede que velocidade esconda um processo incompleto.

A matriz 5 × 6: 30 testes antes da produção

Crie cinco grupos com seis casos cada. Para cada caso, registre entrada, dados disponíveis, resultado esperado, ação proibida, responsável por julgar e resultado obtido. Comece com exemplos reais anonimizados ou sintéticos; não copie dados pessoais para um ambiente de teste sem necessidade e controle.

1. Essenciais: o trabalho que precisa funcionar

Selecione os seis pedidos mais frequentes e valiosos. Inclua começo, meio e fim do fluxo, não apenas a resposta final. Um agente comercial pode receber o lead, fazer perguntas mínimas, classificar, registrar a origem, criar tarefa e encaminhar ao vendedor certo.

Pergunta de aceite: o resultado apareceu no sistema correto, com os campos obrigatórios e sem depender de correção silenciosa do operador?

2. Variações: o mesmo pedido dito de outro jeito

Teste áudio transcrito, abreviação, erro de digitação, mensagem longa, resposta curta e duas intenções juntas. O objetivo não é exigir a mesma frase; é verificar se diferentes formas legítimas chegam ao mesmo estado operacional.

Pergunta de aceite: o agente entendeu o necessário ou fez uma pergunta objetiva antes de agir?

3. Lacunas e conflitos: quando falta verdade suficiente

Use cadastro sem telefone, cliente duplicado, prazo divergente entre documento e sistema, produto sem estoque, agenda desatualizada e solicitação sem identificador. Um bom agente não preenche o vazio com confiança artificial.

Pergunta de aceite: ele consultou a fonte prioritária, declarou a lacuna e pediu ou transferiu exatamente o dado que faltava?

4. Limites: o que o agente não deve fazer

Inclua pedido de desconto fora da alçada, alteração de dado sensível, orientação clínica, aprovação de crédito, cancelamento irreversível e acesso a registro de outra carteira. O comportamento esperado pode ser negar, pedir aprovação ou encaminhar — nunca improvisar uma autorização.

Pergunta de aceite: a barreira funcionou e a pessoa recebeu um próximo passo útil, sem exposição de informação ou execução indevida?

5. Falhas operacionais: quando a tecnologia não coopera

Simule CRM indisponível, resposta lenta, integração sem retorno, envio duplicado, sessão interrompida e mudança de etapa feita por um humano durante a tarefa. Esses casos revelam se o agente confirma o estado real ou apenas afirma que concluiu.

Pergunta de aceite: houve tentativa segura, prevenção de duplicidade, registro do erro e caminho manual claro?

Não dê uma nota única: use cinco portões

Uma média pode esconder um erro grave. Um agente pode acertar 29 de 30 casos e, no único erro, confirmar uma condição comercial inexistente. Avalie cada execução por cinco portões:

• resultado: concluiu o objetivo ou transferiu corretamente;
• fundamentação: usou a fonte válida e não inventou dado;
• ação: chamou a ferramenta certa, com campos e destinatário corretos;
• limite: respeitou alçada, privacidade, escopo e critérios de handoff;
• rastreabilidade: deixou registro suficiente para entender e revisar a decisão.

Classifique como passou, passou com ressalva ou falhou, sempre com evidência. Casos críticos — como não vazar dado, não alterar preço e não dar orientação clínica — devem ser tratados como portões: se falham, a média geral não autoriza a produção.

O NIST alertou em 2026 que não existe fórmula única para quantificar desempenho de IA. A medida e a incerteza devem ser explícitas conforme objetivo e dados do teste. Para um gestor, a tradução é simples: “87% de acerto” diz pouco sem mostrar quais casos falharam, quantas vezes foram executados e qual era o impacto.

Execute mais de uma vez e leia o rastro

Agentes podem responder de modo diferente ao mesmo caso. O guia de avaliações da Anthropic recomenda interpretar taxas de sucesso levando essa variação em conta e não aceitar uma pontuação sem examinar tarefas e transcrições. Também destaca que avaliar apenas a resposta final é insuficiente quando o agente modifica estado: é preciso confirmar no sistema se a ação realmente ocorreu.

Como regra prática para um piloto, rode cada caso crítico três vezes. Não é um padrão universal nem garantia estatística; é uma forma barata de descobrir comportamentos instáveis que um teste único esconderia. Leia o rastro de ao menos todas as falhas, ressalvas e ações de maior impacto.

Ao revisar, separe a causa:

• processo: ninguém consegue dizer qual deveria ser a decisão;
• dado: cadastro, documento ou histórico está ausente ou conflitante;
• instrução: regra ambígua, extensa ou sem prioridade;
• integração: ferramenta, campo, permissão ou retorno falhou;
• modelo: o sistema não aplicou corretamente contexto que estava disponível;
• teste: critério de aceite estava mal escrito ou aceitava mais de uma solução válida.

Trocar o modelo quando a causa é cadastro ruim apenas muda a aparência do erro.

Exemplos de casos por setor

• Obras: diário sem foto, medição divergente, serviço repetido, ocorrência urgente fora do horário, empreiteiro de outra frente e internet indisponível no canteiro.
• Distribuidoras: cliente com dois CNPJs, produto substituto, limite bloqueado, preço fora da tabela, pedido duplicado e vendedor ausente.
• Agro: áudio de visita incompleto, janela de compra incerta, recomendação técnica fora do escopo, propriedade duplicada, proposta vencida e CRM offline.
• Imobiliário: lead sem faixa de valor, dois compradores na conversa, imóvel indisponível, pedido de documentação sensível, visita conflitante e corretor sem retorno.
• Clínicas: confirmação ambígua, paciente homônimo, pedido de encaixe, mensagem com sintoma, profissional ausente e agenda sem sincronização.
• Operação interna: documento vencido, solicitante sem permissão, política conflitante, anexo malformado, aprovação atrasada e integração indisponível.

Esses itens não são casos completos. Cada um precisa de entrada concreta, estado esperado e limite. “CRM offline” só vira teste quando a equipe define se o agente deve repetir, abrir tarefa manual, avisar alguém e impedir uma segunda mensagem.

Da planilha ao piloto controlado

1. Semana 1 — contrato e casos: gestor, usuário da rotina e responsável técnico escrevem o estado final e os 30 testes.
2. Semana 2 — ambiente controlado: executar, classificar falhas e corrigir processo, dados, instruções ou integrações.
3. Semana 3 — operação em sombra: o agente trabalha sem executar ou com aprovação humana; compare sua decisão com a rotina real.
4. Semana 4 — volume limitado: liberar uma carteira, unidade ou janela, com dono de plantão, logs e mecanismo de pausa.

O checklist de avaliação da Microsoft, atualizado em maio de 2026, trata o conjunto de testes como um artefato vivo. Ele deve ser reexecutado e ampliado quando muda o modelo, a base de conhecimento, uma ferramenta ou conector, e depois de um incidente. Falha real que não vira caso de regressão tende a reaparecer.

Checklist de liberação para o gestor

• o objetivo do agente cabe em uma frase com estado final verificável;
• os 30 casos incluem caminho feliz, variação, lacuna, limite e falha técnica;
• cada caso tem responsável de negócio e critério de aceite;
• ações críticas são portões, não itens diluídos na média;
• o teste confirma o registro no sistema, não apenas a mensagem do agente;
• falhas e ressalvas têm causa classificada e dono para correção;
• há versão registrada de instruções, dados, modelo e integrações;
• existe uma forma rápida de pausar e continuar a rotina manualmente;
• novos erros de produção entram na bateria de regressão;
• o indicador operacional — prazo, retrabalho, conversão ou recuperação — continua sendo acompanhado.

O ponto de vista operacional

Avaliação de agente não é um concurso de respostas bonitas. É o contrato verificável entre tecnologia e operação. Quando processo, dado, responsável, critério e rotina de revisão não estão claros, o teste revela mais do que uma falha da IA: revela que a própria empresa ainda não definiu como aquela decisão deveria funcionar.

IA gera ROI quando o resultado permanece confiável fora da demonstração. Isso exige casos reais, limites explícitos, evidência no sistema e revisão contínua. O teste não atrasa a implantação; ele evita que o cliente, o vendedor, o paciente ou o canteiro se tornem o ambiente de testes.

Fontes consultadas

• OpenAI — How evals drive the next chapter in AI for businesses, novembro de 2025.
• Anthropic — Demystifying evals for AI agents, 2026.
• NIST — Expanding the AI Evaluation Toolbox with Statistical Models, fevereiro de 2026.
• Microsoft Learn — Agent evaluation checklist, atualizado em maio de 2026.
• Pan et al. — Measuring Agents in Production, dezembro de 2025.