Diletta Solutions
IA aplicada

O odômetro e o token: você paga pelo consumo, mas o seu cliente paga pelo resultado

O custo dos tokens virou assunto de diretoria. É como se tivesse chegado a fatura do hype em torno da IA. Mas a pergunta que a maioria está fazendo, “como reduzir o gasto com tokens?”, é a pergunta errada.

E tem um dado que mostra por quê. O preço por token despencou: modelos no nível do GPT-4 saíram de cerca de US$ 20 por milhão de tokens no fim de 2022 para menos de US$ 0,50 hoje, uma queda da ordem de mil vezes em três anos, no fenômeno que a a16z apelidou de LLMflation. E mesmo assim a fatura total não parou de crescer. O motivo é simples: quanto mais barato fica processar, mais a gente processa. Cortar o preço do insumo não resolve, porque o problema nunca foi o preço do insumo.

A preocupação com o custo da TI não é nova. Décadas atrás, alguns mainframes traziam medidores eletromecânicos que registravam o tempo de utilização, uma espécie de odômetro da computação. Numa época em que capacidade de processamento era cara e quase sempre alugada, medir o uso tinha impacto econômico direto. O token é o odômetro da vez. E, como todo odômetro, ele diz quanto a máquina rodou, não se ela foi para o lugar certo.

Um problema antigo, uma unidade nova

A cada geração de tecnologia, a unidade de custo mudou:

Mainframe: compartilhávamos um recurso caro e precisávamos medir o consumo com precisão.

Client/Server: distribuímos a computação e passamos a focar em capacidade adquirida, com servidores dedicados, bancos de dados e licenças por assento.

Cloud: voltamos ao consumo elástico e mensurável. A infraestrutura virou serviço cobrado conforme o uso.

IA: surge uma camada de consumo hipergranular, o token.

Na cloud, aprendemos a decompor o custo entre computação, memória, armazenamento, tráfego e requisições. Com os LLMs, entra uma unidade nova e particularmente visível, usada para medir o volume de informação que o modelo processa e gera.

O problema é que token é unidade de consumo, não de valor. Usar o modelo mais caro ou gastar mais tokens não garante o melhor resultado. O desafio é garantir que cada token consumido esteja associado a valor real para o cliente final. Para enxergar isso, vale percorrer a linha do tempo típica de uma aplicação de software:

Problema → Produto → Arquitetura → Engenharia → Operação → Resultado → Valor

Três perguntas

Olhando essa linha do tempo, o desafio se divide em três perguntas:

  1. Estamos resolvendo o problema certo? Foco em problema e produto.
  2. Estamos construindo a solução certa, da maneira certa? Foco em arquitetura, engenharia e operação.
  3. Estamos transformando consumo de tokens em resultado que o cliente valoriza? Foco em resultado e valor.

A primeira pergunta, o que vale a pena fazer, pertence ao domínio de produto e estratégia. É preciso encontrar o encaixe entre um problema relevante do cliente, uma oportunidade de mercado e as capacidades que a empresa consegue mobilizar. Não é trivial: envolve inteligência de mercado, análise de concorrência, definição de MVP, plano de negócios. Mas é o trabalho que dá direção a todo o resto. Peter Drucker resumiu isso melhor do que ninguém: “não há nada tão inútil quanto fazer com grande eficiência algo que não deveria ser feito de forma alguma”.

Decidido o que fazer, vem o como. Aqui entram arquitetos, especialistas em DevSecOps e líderes com visão de governança técnica. São as pessoas que vão definir como ferramentas, times e IA se integram em todo o ciclo: jornada do cliente, UI/UX, codificação, testes, integração, documentação e operação. A IA não elimina a engenharia. Ela aumenta o retorno de uma boa engenharia e amplifica o custo de uma ruim.

Dito de outro jeito: mais do que nunca, é preciso especificar bem, porque a IA cobra caro por contexto desnecessário, premissa mal definida e ciclo de tentativa e erro. Um pedido vago faz o modelo preencher as lacunas sozinho, e isso vira custo extra, em token e em retrabalho. Especificação clara, com restrições, regras de arquitetura, padrões de segurança, fluxo enxuto, modelos padronizados, testes obrigatórios e critérios de aceite: é isso que aumenta o valor extraído de cada token.

Por fim, como conectar o custo de produção à entrega de valor percebido? São duas coisas: primeiro medir o custo, depois monetizar o resultado.

Como medir o custo

Que o custo da IA virou prioridade de gestão não é opinião. Na pesquisa State of FinOps, a fatia de organizações que gerenciam ativamente o gasto com IA saltou de 31% em 2024 para 63% em 2025 e chegou perto da totalidade das empresas em 2026, quando “FinOps para IA” passou a ser a prioridade número um do setor. Duas práticas ajudam:

FinOps: disciplina de gestão financeira da nuvem e da IA que junta engenharia, finanças e negócio para dar visibilidade ao gasto, atribuí-lo a produtos e equipes, definir orçamento e otimizar continuamente o que se paga pelo que se usa.

AI token economics: a gestão do consumo de tokens em si. Escolher o modelo certo para cada tarefa, controlar o tamanho do contexto enviado, reaproveitar respostas via cache e medir o custo de cada tarefa e de cada resultado entregue.

Assim como fizemos com a linha do tempo do software, dá para montar uma sequência de custos:

Infraestrutura → Tokens → Tarefas → Processos → Entregas → Resultado de negócio

Quanto mais à direita (mais perto do resultado), mais nos afastamos do que a tecnologia mede com facilidade e mais nos aproximamos do que o cliente de fato valoriza:

Infraestrutura: quanto custa manter o ambiente que sustenta a IA, e ele está dimensionado para o uso real?

Token: quanto pagamos por token, e o modelo é o adequado para cada tarefa?

Tarefa: quanto custa concluir uma tarefa de ponta a ponta, incluindo a integração com as nossas ferramentas?

Processo: qual foi o impacto em custo, tempo, capacidade e qualidade?

Entrega: quanto custa cada resultado de negócio entregue?

Do custo ao resultado

As perguntas acima equacionam o custo. Para colocar cliente e receita na conta, vale olhar modelos orientados a resultado, ou outcome. Quanto mais a unidade econômica se aproxima do resultado que o cliente realmente quer, menos sentido faz discutir o custo do insumo técnico isoladamente.

Isso já chegou à precificação, e não só no papel. No atendimento ao cliente, ferramentas como o Fin, da Intercom, cobram por resolução: cerca de US$ 0,99 por atendimento efetivamente resolvido pela IA, sem intervenção humana. Outras, como o Agentforce da Salesforce, cobram por conversa (na faixa de US$ 2), resolvida ou não. A diferença não é de centavos, é de incentivo: a cobrança por resultado alinha o fornecedor ao valor entregue, enquanto a cobrança por consumo transfere ao cliente o risco da ineficiência. É o começo do “outcome as a service”, em que o cliente deixa de pagar pela capacidade utilizada e passa a pagar pelo resultado contratado.

Nesse ponto, a medida de sucesso é expressa em resultado mensurável. Alguns exemplos do nosso mundo:

Análise de fraude com IA: qual a redução de perdas por fraude, descontando o custo dos falsos positivos?

SDR assistido por IA: quanto caiu o custo por oportunidade qualificada?

Agentes de atendimento: quanto caiu o custo por chamado resolvido, preservando satisfação e qualidade?

A conta fecha quando ligamos as duas pontas: quanto custa produzir um resultado e quanto esse resultado vale para o cliente. Entre uma coisa e outra está a verdadeira economia da IA.

Ninguém queria que o odômetro do mainframe girasse menos. Todo mundo queria extrair mais trabalho útil de cada unidade de computação. Com a IA é igual: o objetivo não é consumir menos token, é gerar mais valor por token consumido.

Isso levanta perguntas bem práticas para quem está usando IA hoje. Qual é a unidade de resultado da sua operação? Quanto custa produzi-la com IA? Que ciclos de feedback permitem comparar continuamente custo, qualidade e valor? Como medir se a IA está, de fato, entregando um produto melhor ao cliente?

O odômetro dizia quanto a máquina havia rodado. O token diz quanto a IA trabalhou. Nenhum dos dois diz se fomos para o lugar certo.

Celso Gonçalves Jr.

Celso Gonçalves Jr.

Chief Information Security Officer - CISO

Executivo de tecnologia com mais de 25 anos de experiência em software bancário, meios de pagamento, cloud, arquitetura corporativa e cibersegurança. Ex-CTO da Matera por 15 anos, liderando mais de 400 profissionais e iniciativas estratégicas como PIX, Open Finance, modernização cloud e governança de segurança para instituições financeiras.