Um agente de atendimento pode ter a plataforma certa, o fluxo bem desenhado e a integração perfeita com o CRM. Mesmo assim, pode falhar todos os dias na mesma coisa: entender o pedido errado, inventar uma informação, custar mais do que deveria.
A causa, na maioria das vezes, não está na plataforma nem no fluxo. Está no modelo de linguagem que decide, a cada turno, o que responder e quando acionar uma ferramenta.
Este artigo explica como escolher o modelo de IA certo para o seu agente de atendimento, com os critérios técnicos que realmente separam um modelo confiável de um modelo que parece bom na demonstração e falha em produção.
Montar um agente de atendimento normalmente passa por duas escolhas visíveis: em que plataforma ele vai rodar e como o fluxo de conversa vai ser desenhado. Essas duas decisões recebem toda a atenção do projeto.
O modelo de linguagem por trás do agente, o componente que interpreta cada mensagem e decide como agir, costuma ser tratado como detalhe de configuração. Troca-se um modelo por outro seguindo o lançamento mais recente do provedor, sem processo de validação.
Essa é a decisão que mais impacta custo, velocidade e segurança do atendimento.
Provedores de IA lançam famílias de modelos novas com frequência e descontinuam as anteriores em prazos curtos. Um modelo em uso há dois anos, com margem de custo já validada, pode ter data de desligamento anunciada com poucos meses de antecedência.
Como exemplo, em junho de 2026, a própria OpenAI notificou desenvolvedores que usavam versões mais antigas dos modelos GPT-5 e o3 sobre a descontinuação dessas versões na API, com remoção definitiva marcada para seis meses depois. Quem tinha uma operação construída sobre esses modelos precisou migrar dentro desse prazo, quisesse ou não.
Migrar para o substituto recomendado pelo próprio provedor não garante a mesma performance, o mesmo custo por sessão ou a mesma taxa de conclusão de tarefas. Cada família de modelo tem comportamento próprio, mesmo quando o resto do agente permanece idêntico.
Por isso, escolher um modelo de IA não é uma decisão que se toma uma vez. É um processo que se repete toda vez que o mercado força uma substituição.
Comparações de modelo de IA costumam parar em benchmarks públicos genéricos ou em quem "escreve melhor". Para um agente de atendimento em produção, três critérios pesam mais do que qualquer benchmark de propósito geral.
Um modelo pode escrever bem e ainda assim falhar no que importa: seguir o fluxo até o fim, acionar a ferramenta certa no momento certo, fechar o atendimento sem abandonar o processo pela metade.
Em um estudo que conduzimos testando 8 modelos candidatos sob as mesmas condições de um atendimento real, o padrão de falha mais comum não foi falta de fluência. Foi o modelo escolher uma ferramenta plausível, mas errada, para aquele passo específico do atendimento.
Custo por token processado é a métrica mais fácil de medir e a mais fácil de interpretar errado. O que importa para o orçamento é o custo de uma sessão completa, somando todos os ciclos de raciocínio e execução de ferramentas até o atendimento terminar.
No mesmo estudo, um modelo com a melhor nota de custo normalizada teve, na prática, o maior custo por sessão entre os oito candidatos avaliados. A causa não estava no volume de tokens processados. Estava no preço de tabela do provedor por token de saída, quase quatro vezes mais caro que o de um modelo da mesma família.
Alucinação não deveria ser tratada como um detalhe a mais na média de qualidade. Deveria ser um filtro à parte, aplicado depois de qualquer outra nota.
No nosso estudo, três modelos tinham pontuação de qualidade competitiva, acima de 79%, e ainda assim foram reprovados. O motivo foi exceder o limite de alucinação definido para o projeto, não a qualidade da resposta. Um modelo pode ter a melhor nota do teste e ainda ser inseguro para produção.
Na T4H, testamos cada modelo candidato reexecutando conversas reais já resolvidas, sob as mesmas condições do atendimento em produção. O processo segue uma lógica simples:
Esse processo garante que qualquer diferença de resultado seja atribuível ao modelo, não ao ambiente de teste.
Testamos 8 modelos candidatos, de famílias diferentes, incluindo opções de peso aberto, em centenas de execuções cobrindo múltiplos cenários de atendimento. Apenas 3 foram aprovados.
O achado mais relevante desse estudo é o motivo pelo qual outros cinco modelos, com qualidade competitiva, ficaram de fora: na maioria dos casos, o fator decisivo foi a taxa de alucinação, não a capacidade de resolver a tarefa. Gemini 2.5 Flash, GPT-4.1 nano e GPT-5 mini tinham pontuação de qualidade acima de 79%, patamar competitivo o suficiente para aprovação em qualquer critério que considerasse só qualidade, custo e latência. Ainda assim, foram reprovados.
Entre os três aprovados, cada um teve uma leitura diferente. O GPT-5.4 mini se destacou pela melhor taxa de sucesso do estudo, sem nenhuma ressalva identificada. O GPT-5.4 nano teve o menor custo e a menor latência, mas com margem de segurança mais estreita na taxa de alucinação. O Kimi-K2.5 foi o único com zero alucinações em toda a amostra, mas esbarrou em limitação de capacidade do provedor em parte relevante das sessões, o que compromete sua prontidão para atendimento em tempo real.
O estudo também revelou um ponto que costuma passar despercebido: ordenar os modelos só pela nota de qualidade não corresponde a ordenar por aprovação. O GPT-4.1 nano aparece em terceiro lugar no ranking por pontuação, à frente do próprio Kimi-K2.5, que foi aprovado. A posição no ranking e a decisão final de aprovação respondem a perguntas diferentes.
Esse resultado sustenta um princípio simples: nota de qualidade alta não é sinônimo de modelo seguro para produção. Os dois critérios precisam ser avaliados separadamente.
Publicamos a metodologia completa e os resultados dos 8 modelos testados, incluindo o ranking por pontuação e por veredito final.
Acesse o estudo completo por aqui.
E acesse, em primeira mão, nossos principais conteúdos diretamente do seu e-mail.
