Uma equipe de engenharia cortou a conta de inferência de IA em mais da metade em oito semanas de trabalho. O CFO mandou uma nota de agradecimento. O sprint foi apresentado no all-hands da empresa. Três meses depois, a satisfação dos clientes estava despencando, o churn subindo e a economia estava estruturalmente amarrada à perda de qualidade. Eles não tinham vencido — só transferiram o custo para um lugar que não estavam medindo.
Este é o padrão que Pratik K Rupareliya, cofundador da Intuz com mais de 18 anos implementando IA em produção, espera ver em implantações de IA nos próximos seis meses. Em um artigo publicado no Towards Data Science, ele descreve o que chama de “armadilha de Pareto” das camadas de roteamento — e apresenta uma alternativa arquiteturalmente honesta.
O consenso que está quebrando produtos
O manual de 2026 para economia em IA é simples: redirecione consultas simples para modelos baratos, mantenha as consultas complexas nos modelos capazes. Corte a conta, preserve a qualidade. Todo CFO viu a matemática. Toda equipe de engenharia está construindo ou já construiu essa camada.
O problema, segundo Rupareliya, é que essa arquitetura é estruturalmente frágil em produção — e ele tem três casos para provar.
O caso principal: agente de suporte com 4 milhões de usuários
A equipe operava um agente de IA para suporte ao cliente de um SaaS. A conta mensal de inferência havia chegado a seis dígitos. A solução foi uma camada de roteamento com um classificador treinado em 200 mil consultas históricas, que rotulava cada pergunta como “simples” ou “complexa”. Consultas simples iam para um modelo 75% mais barato. As complexas continuavam no modelo principal.
O classificador rodava em menos de 30 milissegundos. A divisão era de 65% simples e 35% complexas. O modelo barato teve equivalência de qualidade em 94% de um conjunto de 5 mil consultas de validação. A implantação foi gradual ao longo de seis semanas, com métricas verdes em cada etapa. Ao final, a conta caiu para 40% do valor anterior. Tudo parecia perfeito.
Três meses depois, a satisfação do cliente começou a cair. Levou mais um mês para atribuir corretamente o problema. Quatro meses de impacto no cliente até entender o que havia acontecido.
O que a arquitetura de medição não conseguia ver
A falha não estava no roteador. Estava na medição. A equipe usava três fontes de sinal de qualidade: revisão humana diária de 200 respostas, suíte de regressão offline com 12 mil consultas e feedback no produto (thumbs-up/down).
Mas a amostra de revisão humana agregava os dois modelos sem separar por tier — efetivamente uma média ponderada onde o modelo barato, que ia bem nos casos fáceis de alto volume, puxava o número para cima. Os problemas na borda da distribuição de consultas simples ficavam invisíveis.
A suíte de regressão era estática, construída seis meses antes, sem noção de roteamento. O modelo barato passava na suíte, mas degradava na borda viva da produção. O widget de feedback tinha sinal-ruído baixíssimo: 3 dislikes a cada 1.000 interações, insuficiente para detectar qualquer regressão que não fosse catastrófica.
O resultado: todos os dashboards estavam verdes enquanto a qualidade real desmoronava.
O mesmo padrão em três empresas diferentes
Rupareliya auditou outros dois casos. Uma empresa de SaaS média com assistente de sucesso do cliente: mesma arquitetura, economia de 50%, mas o tier barato tinha satisfação significativamente menor nas consultas de cauda longa. O impacto estimado no cliente era de 2,5 a 3 vezes a economia. Reverteram em um mês.
O terceiro caso foi em fintech, setor regulado. O roteamento era mais conservador — só 20% das consultas iam para o modelo barato. Mas consultas aparentemente informacionais (“qual é minha taxa de juros?”) às vezes tinham implicações regulatórias que o modelo barato não capturava com precisão. A equipe de compliance pegou antes de virar um problema regulatório, mas o susto levou à reversão total.
A alternativa: cascade baseado em incerteza
Em vez de pré-classificar consultas, o padrão proposto é um cascade roteado por incerteza. Toda consulta começa no modelo barato. Se o modelo tem alta confiança na resposta, ela vai direto ao usuário. Se a confiança está abaixo do threshold, a consulta é escalada para o modelo capaz.
Isso inverte o modo de falha: as consultas difíceis que o modelo barato responderia errado com confiança agora emergem como baixa confiança e disparam o escalation. O modelo caro lida com esses casos. A economia projetada fica na mesma faixa, mas com qualidade materialmente melhor na cauda longa.
Dois aprimoramentos se somam ao cascade: shadow scoring (rodar o modelo capaz em paralelo em uma amostra do tráfego para detectar drift) e quality-weighted routing (incorporar sinal de satisfação ao ajuste de thresholds ao longo do tempo).
As três medições que toda equipe precisa
Rupareliya propõe três adições concretas à stack de observabilidade antes de qualquer camada de roteamento ir ao ar:
1. Monitoramento de qualidade por tier. Todo sinal de qualidade deve ser dividido por tier de roteamento. Amostras de revisão humana estratificadas. Suítes de regressão separadas. Feedback unido ao log de decisão de roteamento. O número agregado é estruturalmente incapaz de revelar drift específico de tier.
2. Amostragem de satisfação na cauda longa. Sobreamostrar consultas onde o classificador tinha baixa confiança ou fora do centroide da distribuição de treino. O objetivo é dar peso às consultas onde a escolha do modelo realmente importa.
3. Monitoramento de drift de confiança do roteador. A distribuição de scores de confiança em produção deve ser rastreada contra a distribuição de treino. O sinal de drift precede o sinal de qualidade em semanas — é o lead time que a equipe precisa para corrigir rota.
A lição
A equipe original eventualmente chegou a uma arquitetura estável combinando cascade com observabilidade por tier. A economia mensal ficou em 35% (abaixo dos 60% iniciais), mas a satisfação do cliente voltou ao nível pré-experimento. O valor líquido do produto ficou significativamente positivo.
A lição não é que otimização de custos está errada. É que otimização de custos é uma escolha sobre qual camada do sistema você confia para fazer o tradeoff certo. Pré-roteamento confia em um classificador que não enxerga o que importa. Cascade confia no modelo para saber o que ele não sabe.
A otimização barata é a que quebra o produto silenciosamente. A otimização arquiteturalmente honesta é a que sobrevive à cauda longa. Em IA de produção, a diferença costuma ser um trimestre de satisfação do cliente.
