Como avaliar o custo real de operar AI em produção

Operações com AI costumam medir só o custo de inferência. Os custos que pesam de verdade aparecem tarde: revisão humana que não some, contexto que cresce a cada chamada, manutenção do que parecia estável.

Quando o custo cresce mais rápido que o resultado, o problema raramente está no preço do modelo. Está em como a adoção foi estruturada: sem baseline medido, sem dono claro do resultado.

Nesta edição de 6 Perguntas, conversamos com Carlos Silva, Arquiteto de Soluções na RD Station. Ele compartilha quais custos as operações descobrem tarde demais, o que orienta a decisão de onde AI entra primeiro e que métricas separam ganho real de aparência de ganho.

Quase sempre revela que a adoção começou pela tecnologia, não pelo problema. Alguém decidiu “usar IA” antes de definir qual unidade de valor a IA precisava mover e aí você acaba pagando por chamada de um sistema cujo resultado nunca foi amarrado a uma métrica de negócio.

O custo escala de forma linear (mais uso, mais token, mais contexto), mas o valor não acompanha, porque o valor não compõe: cada interação resolve, na melhor das hipóteses, uma tarefa isolada.

Os projetos onde isso não acontece têm três coisas desde o começo: um baseline medido antes de ligar a IA, um dono claro do resultado (alguém que responde pelo ganhos ou perdas daquele caso de uso, não só pela entrega técnica) e uma arquitetura pensada para custo; Roteamento entre modelos por complexidade, cache, controle de contexto. Quando o custo dispara, normalmente falta um desses três.

É menos um problema de modelo caro e mais um sintoma de que a operação nunca definiu com clareza o que estava comprando.

O custo de inferência é o que todo mundo olha e quase nunca é o que dói. Os que aparecem tarde são outros:

• O “último quilômetro” de confiança. A IA entrega 85% do caso bem, mas alguém precisa revisar os 15% e esse humano no loop não some. Se você não mediu quanto tempo ele gasta corrigindo, achou que automatizou quando na verdade só realocou o trabalho.

• O contexto que cresce. Conforme você joga mais dados no prompt ou no RAG para melhorar a resposta, o custo por chamada sobe silenciosamente. Ninguém percebe até a fatura.

• A manutenção. Um modelo é depreciado, a API muda um comportamento, um provedor ajusta o formato de saída e o que estava estável quebra. Já passei por isso mais de uma vez em integrações que dependiam de um formato específico de retorno.

• O dado sujo. Se a base tem duplicidade, campo inconsistente e histórico bagunçado, a IA vai processar (e cobrar por) lixo e ainda erra mais por causa dele.

O que precisa estar instrumentado desde o dia zero é menos sofisticado do que parece: custo por transação resolvida (não por token), taxa de escalada para humano, latência no p95, uma medida real de erro e o mais esquecido, um baseline de como a operação performava antes. Sem baseline você nunca consegue provar ganho nem perda. E tag por caso de uso, senão tudo vira uma fatura única impossível de atribuir.

Não trato isso como board contra dado, trato como sequenciamento.

O board costuma apontar para o que é visível e estratégico; o fluxo aponta para o gargalo real, que muitas vezes é menos glamouroso. Minha primeira pergunta não é “onde é mais importante”, é “onde eu consigo provar valor rápido com risco contido”. Isso mora no cruzamento de quatro coisas: volume alto, tarefa repetitiva, tolerância razoável a erro e dado disponível e limpo para sustentar.

O primeiro caso quase nunca é o mais estratégico e sim o mais ”instrumentável”. Porque a barreira real da adoção de IA numa operação raramente é técnica; é confiança. Uma vitória pequena, medida e defensável compra o capital político para atacar o alvo que o board quer, que geralmente é mais arriscado e demora mais para dar retorno.

O erro que vejo é começar pelo caso mais estratégico e mais frágil ao mesmo tempo: se ele falha, você não perde só o projeto, perde a permissão de tentar de novo.

Então eu concordo com o board no destino e discordo na ordem e por isso traduzo cada vitória do fluxo para a linguagem de negócio, senão ela não conta para quem decide orçamento.

O sinal mais claro é quando a IA tecnicamente “funciona” e mesmo assim ninguém usa o resultado, ou todo mundo cria um contorno em volta dela. Outros sinais: um volume de exceções que não cabe (se 40% dos casos são “exceção”, você não tem exceção, tem um processo mal definido); um prompt que virou um monstro de dezenas de regras tentando cobrir situações que nunca foram documentadas em lugar nenhum; e gente discutindo o que a IA “deveria” fazer sem conseguir descrever como o trabalho era feito antes.

Para separar limite da tecnologia de problema de fluxo eu uso dois testes simples.

O primeiro: desenho o processo no papel sem nenhuma IA. Se, escrito passo a passo, ele já é ambíguo, tem decisão sem dono ou regra que muda dependendo de quem executa ai o problema é fluxo, e nenhum modelo vai resolver.

O segundo é o “teste do humano”: dou a mesma tarefa, com exatamente as mesmas instruções que dei para a IA, a uma pessoa competente. Se ela também erra, hesita ou me pergunta “mas e se...”, o gargalo não é o modelo, é a definição do trabalho.

IA amplifica o processo que já existe. Se o processo é bom, ela escala o bom; se é confuso, ela escala a confusão e mais rápido. Vivi isso de forma bem literal reescrevendo automações: um fluxo que tinha virado um emaranhado de centenas de nós virou pouco mais de dez quando o problema real, que era o desenho e não a ferramenta, foi resolvido primeiro. A tecnologia raramente é o teto que as pessoas imaginam.

A pergunta que faço para qualquer métrica é: esse ganho aparece no financeiro ou no tempo do cliente, ou só no dashboard da IA?

As que sustentam ganho de verdade olham o processo inteiro, não só a etapa que a IA tocou:

• Custo por unidade de trabalho concluída (por atendimento resolvido, por pedido processado), medido antes e depois.

• Tempo de ciclo ponta a ponta — não o tempo da etapa automatizada, o tempo que o cliente ou a operação de fato sente.

• Taxa de resolução sem intervenção humana — contenção real, não interação.

• Retrabalho e reabertura — a qualidade lá na frente. É aqui que muito “ganho” evapora.

• Adoção real pelos operadores. Se o time contorna a ferramenta, o ganho no papel é ficção.

As que criam só aparência de ganho são quase sempre métricas de atividade, não de resultado: número de interações da IA, percentual de tarefas “tocadas” por IA, satisfação medida numa demo controlada, tokens processados e o clássico “horas economizadas” calculado em teoria — headcount que você imaginou que ia economizar e nunca economizou de fato.

O caso que mais engana é a taxa de “deflexão” em atendimento. Um chatbot pode defletir 60% dos tickets e parecer um sucesso, porém quando parte desses clientes só desistiu de ser atendido e volta como rechamada, churn ou reclamação num canal mais caro. Você otimizou a métrica e piorou a operação.

Por isso nunca olho a métrica da IA isolada; olho o efeito dela no indicador que já existia antes de ela chegar.

Mais importante que a lista é a montagem. Eu tento equilibrar quatro camadas e evitar afogamento: uma de varredura diária, uma de síntese semanal, uma de fonte primária e uma de leitura de negócio/estratégia. E por cima disso, a fonte que quase ninguém cita é a mais confiável: colocar a mão e testar você mesmo.

Na prática, o que eu recomendaria para uma liderança de Produto e Engenharia:

• Varredura diária: TLDR AI, para triar em cinco minutos o que aconteceu e decidir o que merece leitura profunda.

• Síntese semanal: The Batch, do Andrew Ng (DeepLearning.AI), que faz a ponte entre o que saiu da pesquisa e o que aquilo significa para o negócio.

• Profundidade de engenharia aplicada: Latent Space (do swyx), que trata engenharia de IA como disciplina própria — evals, escolha de modelo, custo de inferência, arquitetura de agentes. É a leitura mais próxima das decisões do dia a dia.

• Estratégia e mercado: Stratechery, do Ben Thompson, e The Pragmatic Engineer, do Gergely Orosz, para entender IA no contexto de negócio e de organização de time — não só o release do modelo.

• Fonte primária: a documentação e os blogs técnicos dos próprios provedores (Anthropic, OpenAI, Google) e, quando o assunto pede, o paper no arXiv. Boa parte do que circula “sobre” um lançamento distorce o que o release realmente diz. Para uma âncora anual, o AI Index de Stanford e o State of AI Report ajudam a separar tendência de hype.

Mas a fonte que levo mais a sério é a experimentação direta. Nenhuma newsletter substitui rodar o modelo no seu próprio problema, com o seu próprio dado.

A maior parte das minhas conclusões sobre o que funciona e o que só parece funcionar veio de quebrar a cara construindo, não de ler sobre.

Para liderança, o hábito mais valioso é reservar tempo para colocar a mão, porque a velocidade da área faz qualquer conhecimento de segunda mão envelhecer rápido.