Como testar uma IA de atendimento antes de colocar no ar

Quase toda automação de atendimento que chega até nós com problema já tinha sido testada antes de ir ao ar. O teste foi o dono da empresa conversando com a IA por vinte minutos, achando as respostas boas e liberando.

Teste de dono é gentil por natureza. Ele pergunta do jeito de quem já sabe que a informação existe, na ordem certa, com a palavra certa. O cliente pergunta do jeito dele, no meio de outro assunto, com áudio transcrito errado e com uma exceção que ninguém escreveu em lugar nenhum. A conversa que aprova a automação não se parece com nenhuma conversa que ela vai enfrentar depois.

O roteiro abaixo é o que a Cordexo usa antes de ligar qualquer IA em canal de cliente. Ele leva de duas a quatro horas na primeira vez e reduz muito a chance de o primeiro erro público ser um erro caro.

Passo 1: escrever o banco de casos antes de abrir a conversa

A regra é simples: nenhuma pergunta de teste pode ser inventada na hora, olhando para a tela. Se você improvisa, você improvisa dentro do que a IA já respondeu bem.

Abra o histórico do canal e separe de 30 a 50 perguntas reais, copiadas com os erros de digitação originais. Ao lado de cada uma, escreva a resposta certa antes de ver o que a IA responde. Isso é o banco de casos, e ele vale mais que a automação em si: é o único documento que diz, por escrito, o que a empresa considera resposta correta.

Numa gráfica rápida que atende pedido por WhatsApp, o banco fica parecido com isto: "quanto sai 500 cartão", "vcs fazem banner de 2x1?", "o arquivo tem que ser em que formato", "consigo retirar hoje ainda", "pode parcelar". Cinco perguntas, cinco respostas oficiais escritas antes do teste.

Passo 2: cobrir os cinco tipos de caso

Um banco só com pergunta fácil aprova qualquer coisa. Os cinco tipos precisam estar representados:

Pergunta repetida e direta. O que aparece todo dia. Aqui a IA tem que acertar sempre, e o resultado costuma ser bom.

Pergunta torta. Mal escrita, sem contexto, com abreviação, transcrita de áudio. "qnt custa aquele papel mais grosso". É o tipo que separa IA de fluxo de botão.

Caso de borda com exceção. O pedido que tem uma regra diferente. Na gráfica: tiragem acima de dois mil, que muda a tabela de preço e o prazo. A automação precisa reconhecer que aquilo saiu do padrão.

Informação que a IA não tem. Pergunte deliberadamente algo que não está na base. O comportamento esperado não é acertar por sorte: é dizer que não tem essa informação e passar para uma pessoa. Se a IA responde com confiança, você encontrou o defeito mais perigoso do sistema antes do cliente.

Tentativa de empurrar a IA para fora do escopo. Pedido de desconto, promessa de prazo apertado, reclamação com tom agressivo, pergunta sobre concorrente. Modelos de linguagem tendem a agradar, e agradar aqui significa prometer o que a operação não cumpre.

Passo 3: definir o critério de aprovação antes de contar os acertos

Exigir 100% de acerto trava o projeto para sempre. Aceitar qualquer coisa coloca o problema no colo do cliente. A saída é separar os erros em duas caixas.

Erro tolerável é a resposta incompleta que termina em transferência, a resposta correta mas fria, a informação certa dita de um jeito confuso. Custa pouco e se corrige na base depois.

Erro inaceitável é informação errada dita com confiança, preço ou prazo prometido fora da tabela, resposta que fecha um assunto que precisava de gente, vazamento de dado de outro cliente. Um único caso desses reprova a rodada inteira.

O critério que usamos: zero erros inaceitáveis no banco completo e pelo menos 80% dos casos resolvidos sem transferência entre as perguntas do tipo repetida e direta. Se um dos dois falha, corrige e roda tudo de novo.

Passo 4: definir quem assina

A pessoa que aprova o teste não é o fornecedor nem quem cuida de tecnologia. É quem é dono da resposta oficial: na gráfica, quem define preço e prazo de produção.

Isso muda o resultado por um motivo prático. O técnico avalia se a automação funcionou. O dono da resposta avalia se a resposta está certa. São perguntas diferentes, e só a segunda evita que a empresa comece a distribuir informação errada em escala.

Passo 5: guardar o banco e rodar de novo a cada mudança

O banco de casos não morre no dia da entrega. Ele vira o teste de regressão da automação.

Rode o banco inteiro sempre que uma dessas quatro coisas mudar: a instrução da IA, a base de conhecimento, uma integração com o sistema, ou o modelo de linguagem por trás. As três primeiras são mudanças suas. A quarta chega sem aviso, quando o fornecedor atualiza a versão. Com o banco guardado, conferir custa vinte minutos. Sem ele, você descobre pelo cliente.

O piloto silencioso

Aprovado no banco, ainda não é hora de deixar a IA responder sozinha.

Ligue em modo sombra por alguns dias: a IA gera a resposta, uma pessoa lê antes de enviar e corrige o que for preciso. As correções feitas nesse período são a matéria-prima mais honesta que existe para ajustar a base, porque vêm de conversa real e não de simulação. Numa operação de volume médio, uma semana de sombra costuma render mais aprendizado que trinta casos de teste.

Depois disso, a automação vai ao ar com um banco de casos escrito, um critério de aprovação registrado, um responsável de nome e um histórico de correções reais. É bem diferente de subir porque a conversa de vinte minutos pareceu boa.