Projetos de IA generativa exigem uma nova lógica de avaliação, que considere não apenas o uso da tecnologia, mas a relação entre o custo dos tokens consumidos e os resultados gerados para o negócio | Crédito: Divulgação
Uma multinacional de varejo no Brasil implementou um copiloto de IA generativa para seu time de atendimento em 2024. Seis meses depois, o projeto rodava em produção, os agentes usavam a ferramenta todos os dias e a diretoria de tecnologia reportava sucesso. Quando o CFO perguntou quanto aquilo tinha economizado ou gerado em receita, o silêncio na sala foi longo. Ninguém tinha uma resposta, porque ninguém tinha definido, desde o início, o que contar como retorno.
Esse cenário se repete em empresas de todos os tamanhos. O projeto de IA funciona tecnicamente, os usuários adotam a ferramenta, os dashboards de uso sobem e à direita. Mas a pergunta que decide se o investimento continua, se ele escala ou se é cortado no próximo corte de orçamento fica sem resposta. A causa não é falta de dados, e sim a ausência de um método que capture a natureza específica de projetos de IA generativa, onde o custo se mede em tokens consumidos e o valor se mede em decisões, horas e receita gerada a partir deles. Esse método é o que chamo de retorno sobre tokens, e é dele que este artigo trata.
Por que o ROI tradicional não basta aqui?
Quando uma empresa compra um ERP ou contrata uma licença de software, o custo é conhecido no dia da assinatura do contrato. Paga-se por usuário, por mês, e o valor não muda se um funcionário usar a ferramenta dez vezes ou cem vezes ao dia. É por isso que o ROI tradicional de TI sempre girou em torno de horas economizadas e redução de headcount. O denominador da conta, o custo, era fixo, só o numerador variava.
Com IA generativa essa lógica se inverte. O custo é o que varia, e varia de um jeito que a maioria dos comitês de investimento ainda não sabe medir. Cada interação com um modelo consome tokens, e o preço é cobrado por token processado. Isso significa que o mesmo time, fazendo o mesmo trabalho, pode gerar contas radicalmente diferentes dependendo de três fatores que nada têm a ver com quantas pessoas usam a ferramenta: quanto contexto é enviado em cada prompt, quantas vezes uma tarefa precisa ser refeita até sair algo utilizável, e se a empresa optou por um modo de resposta mais rápido (e mais caro) ou padrão.
Um exemplo ajuda a tornar isso concreto. Imagine uma empresa de 5 mil funcionários que dá acesso a uma ferramenta de IA para 500 deles, todos fazendo cerca de 20 interações por dia. Se cada interação usa prompts enxutos, a conta mensal fica perto de 5 mil dólares. Mude só um parâmetro, o tamanho do contexto que cada prompt carrega, por exemplo analisando trechos maiores de documentos ou de código, e a mesma operação, com o mesmo número de pessoas e a mesma frequência de uso, pode custar dez vezes mais. Nenhum RH foi cortado, nenhuma hora foi economizada a mais. O que mudou foi a forma como a ferramenta foi usada no dia a dia, um detalhe que escapa completamente de qualquer planilha de ROI construída nos moldes de projetos de TI convencionais.
É esse tipo de surpresa que vem aparecendo nas pesquisas com executivos. Um levantamento da Bain & Company mostrou que boa parte das empresas mirava reduções de custo entre 20% e 30% depois de adotar IA, mas a fatia mais comum de resultado real ficou em 10% ou menos. Muitas dessas empresas continuaram aumentando o investimento antes mesmo de essas economias projetadas se confirmarem, numa espécie de aposta de fé. O problema não é só a lacuna entre expectativa e resultado, é que a conta de tokens continuou subindo durante essa espera.
Há também um sintoma mais direto desse descompasso. Um estudo da EntelligenceAI, citado por Alex Kantrowitz e Marty Swant, estimou que de cada dólar gasto em IA, 82 centavos nunca chegam a virar produto em produção. Apenas 18 centavos se convertem em algo que o cliente final usa. O resto se perde em retrabalho, correções e ciclos de revisão. Não é um problema de a tecnologia não funcionar, e sim um problema de incentivo: quando o sucesso interno é medido por volume de uso, a organização otimiza para gastar mais tokens, não para gastar melhor.
Esse desconforto já chegou à sala de reunião. A Uber declarou publicamente que está ficando cada vez mais difícil justificar o dinheiro gasto em IA. Frases assim vão se tornar comuns à medida que mais CFOs pedirem para ver a fatura de tokens ao lado do relatório de produtividade, e não encontrarem uma relação clara entre os dois números.
O ponto central é este, um projeto de IA não tem um custo, tem uma trajetória de custo. Ela sobe com o número de usuários, complexidade dos prompts, escala de adoção, e quando alguém decide usar o modo mais rápido do modelo. Medir o retorno desse investimento só pelas métricas herdadas do software tradicional é como medir a temperatura de um incêndio com um termômetro de geladeira. É aqui que entra a necessidade de um conceito novo, que trate o consumo de tokens como a variável central da conta, e não como um detalhe técnico a ser resolvido depois pelo time de tecnologia.
Todo investimento em tecnologia sempre teve uma unidade econômica de referência. Na era do software licenciado, era o custo por usuário cadastrado. Na era da nuvem, virou o custo por hora de processamento ou por gigabyte armazenado. Em projetos de inteligência artificial generativa, essa unidade é o token.
Token é o menor pedaço de texto que um modelo de linguagem processa, algo próximo de uma sílaba ou uma palavra curta. Cada pergunta enviada a um modelo consome tokens de entrada. Cada resposta gerada consome tokens de saída. E cada um desses tokens tem um preço, cobrado pelo provedor do modelo. Retorno sobre tokens é, de forma direta, a relação entre o valor gerado por uma interação com um modelo de IA e o custo dos tokens consumidos para produzir essa interação. Uma forma simples de calcular esse retorno, adaptada do conceito de “Return on Tokens” popularizado pelo investidor Packy McCormick, é: retorno sobre tokens, em percentual, é igual a valor do resultado menos custo dos tokens, dividido pelo custo dos tokens, multiplicado por cem. A fórmula parece simples, o que ela expõe é que grande parte das empresas nunca chega a preenchê-la com números reais.
Por que tokens, e não licenças ou horas de projeto
Um investimento em ERP, em um servidor ou em uma licença de software tem uma característica que facilita a vida do CFO: o custo é definido antes do uso começar. Você paga a licença, instala o sistema, e o custo marginal de cada nova consulta feita por um funcionário é praticamente zero. Em projetos de IA baseados em modelos de linguagem, essa lógica se inverte. Não existe uma licença fixa que cobre “todo o uso”. Existe um custo marginal, real, cobrado a cada interação. Quanto mais a empresa usa a IA, mais ela paga, na mesma proporção.
Isso muda completamente a forma como esse tipo de investimento deve ser avaliado. Um projeto de automação com RPA, por exemplo, tem um custo de implementação concentrado no início e depois roda com despesa marginal baixa. Um assistente de IA que analisa contratos, responde clientes ou gera relatórios continua produzindo custo a cada nova execução, mês após mês, à medida que mais times o adotam, os prompts ficam mais longos ou a empresa passa a usar modelos mais caros e rápidos para reduzir latência.
Um exemplo ilustra a escala desse efeito. Um consumo de um bilhão de tokens por mês, com uma divisão razoável entre tokens de entrada e de saída, pode custar algo como 15 mil dólares mensais em modo padrão. O mesmo volume, rodando em modo de resposta rápida, mais caro por token, dobra essa conta para 30 mil dólares. A diferença não está no valor gerado para o negócio, apenas na configuração técnica escolhida, muitas vezes sem que a liderança saiba que essa escolha existe. Multiplicado por dezenas de times, centenas de usuários e milhões de interações ao longo de um trimestre, esse tipo de decisão operacional silenciosa é o que explica empresas descobrindo, tarde demais, contas de dezenas ou centenas de milhões de dólares em consumo de modelos de IA sem controle de limites de uso.
O erro de tratar IA como investimento único
Quando uma empresa aprova um projeto de IA olhando apenas para o custo de implementação, o erro já começou. A pergunta certa não é “quanto vamos gastar para colocar isso no ar”, e sim “quanto vamos gastar, mês após mês, para cada unidade de valor que esse sistema entrega, e esse valor está crescendo mais rápido que o custo”. A pesquisa da Bain & Company mostra o tamanho do problema quando essa pergunta não é feita a tempo. Quase 40% das empresas que mediram economia de custos com automação e IA ficaram abaixo de 10%, mesmo tendo planejado entre 11% e 20%. Ainda assim, 90% dessas mesmas empresas estão aumentando o orçamento de IA novamente, para a próxima onda de projetos com agentes autônomos. Isso é o retorno sobre tokens sendo ignorado em escala. Custo mensurável e crescente, retorno presumido e não verificado.
Esse hábito de aprovar o próximo orçamento sem confirmar se o anterior entregou o prometido tem uma consequência prática direta: quatro em cada dez empresas estão financiando a próxima onda de IA com a economia gerada pela onda anterior, segundo a mesma pesquisa da Bain. Se essa economia anterior nunca foi comprovada com precisão, a empresa está reinvestindo em cima de um número que talvez nunca tenha existido.
O erro de tratar IA como investimento único, descrito na seção anterior, tem uma raiz mais profunda. Ele começa antes de qualquer dashboard mostrar consumo real, no momento em que a equipe técnica ainda está desenhando a solução. É nessa fase que a economia unitária do projeto é decidida, muitas vezes por pessoas que nunca vão olhar para uma fatura de tokens.
Quatro decisões tomadas nesse estágio fixam a curva de custo do projeto antes dele existir em produção: qual problema resolver primeiro, qual modelo usar, como estruturar o acesso da IA à informação da empresa, e como os prompts são construídos. Depois que o projeto está no ar, a área de governança pode ajustar limites de uso e monitorar consumo, mas ela trabalha em cima de uma arquitetura que já foi decidida. Corrigir depois custa reengenharia. Decidir bem antes custa apenas atenção.
A escolha do modelo já é uma decisão financeira
Um estudo apresentado na ICLR de 2025 por pesquisadores da UC Berkeley, Anyscale e Canva, batizado de RouteLLM, mostrou algo que qualquer comitê de tecnologia deveria conhecer antes de aprovar um projeto de IA. Ao invés de mandar toda pergunta para o modelo mais caro e mais capaz disponível, um roteador treinado para reconhecer a complexidade de cada consulta consegue direcionar a maioria delas para modelos mais baratos, reservando o modelo de ponta só para os casos que realmente exigem. O resultado, medido pelos próprios pesquisadores, foi uma redução de 85% no custo mantendo 95% da qualidade de resposta do modelo mais caro usado como referência.
Esse tipo de achado explica um paradoxo que vem incomodando quem acompanha de perto os preços de IA. O custo por token caiu de forma acentuada nos últimos anos, e ainda assim as faturas de muitas empresas subiram. A explicação não está na tabela de preços dos provedores, mas na arquitetura escolhida. Times técnicos, por comodidade ou por falta de orientação, tendem a usar o modelo mais caro disponível para toda e qualquer tarefa, inclusive para as mais simples.
Modelos menores e mais baratos, quando bem ajustados à tarefa certa, entregam qualidade equivalente para boa parte do volume de uso, e a diferença de custo entre eles e os modelos de ponta pode passar de trinta vezes para o mesmo tipo de tarefa. Nenhuma dessas escolhas aparece em uma ata de reunião de aprovação de projeto, elas ficam a critério de quem está implementando, o que significa que o comitê que aprovou o investimento normalmente não sabe que essa alavanca existe.
A arquitetura decide o custo antes do primeiro usuário logar
Há uma segunda decisão, ainda menos visível para a liderança, que é como a IA vai acessar a informação de que precisa para responder. Duas abordagens dominam o mercado. Uma carrega o documento inteiro, ou a base de conhecimento inteira, dentro do contexto enviado ao modelo a cada pergunta. A outra busca só os trechos mais relevantes de informação antes de montar o prompt, uma técnica cada vez mais usada à medida que as equipes vão se especializando nas tecnologias e ferramentas disponíveis.
Uma pesquisa acadêmica recente, aplicada a um caso de assistentes de IA para treinamento de segurança na indústria, comparou as duas abordagens diretamente. Carregar o documento inteiro produziu respostas mais corretas, 73,1% de acerto contra 65,4% da busca por trechos. Mas esse ganho de precisão custou 26 vezes mais tokens por consulta. Os próprios pesquisadores chamam isso de “imposto do token sobre a precisão epistêmica”, e o ponto central do estudo é que essa não é uma escolha técnica neutra. É uma escolha de negócio, feita por um desenvolvedor, que determina se a empresa vai pagar um a mais ou vinte e seis a mais pela mesma pergunta.
Isso não quer dizer que a opção mais barata seja sempre a certa. Em um caso de treinamento de segurança industrial, os sete pontos percentuais de precisão a mais podem justificar o custo adicional. Em um chatbot de dúvidas sobre política de férias, provavelmente não. O problema não é a existência do trade-off, é que ele quase nunca chega à mesa de quem aprova o orçamento como uma decisão explícita, com o custo mostrado ao lado do ganho de qualidade.
O caso de uso escolhido já embute uma curva de custo
A terceira decisão é a mais óbvia e a mais ignorada: qual processo a empresa escolhe automatizar primeiro. Um caso de uso que envolve analisar contratos longos, revisar bases de código extensas ou responder com base em históricos completos de atendimento nasce estruturalmente mais caro em tokens do que um caso de uso de classificação simples ou resposta curta e objetiva. Isso não é um defeito do projeto. É a natureza da tarefa.
O problema aparece quando a empresa escolhe o primeiro caso de uso pelo impacto simbólico ou pela visibilidade interna, sem considerar que esse mesmo caso já nasce no patamar mais caro da escala de consumo. Uma empresa que começa sua jornada de IA por um assistente jurídico que processa contratos inteiros está, sem perceber, escolhendo competir contra sua própria economia unitária desde o primeiro mês. Poderia ter obtido o mesmo aprendizado organizacional, e construído confiança para escalar depois, com um caso de uso mais barato de sustentar.
O que isso muda na prática
Arquitetura, modelo e caso de uso não são detalhes de implementação a serem revisados depois que o projeto provar valor. São a própria definição do valor, porque determinam o denominador da conta de retorno sobre tokens antes de qualquer usuário fazer login. Uma empresa que aprova um projeto de IA sem perguntar qual modelo será usado, como o acesso à informação será estruturado e por que aquele caso de uso foi escolhido primeiro está aprovando um número que ainda não existe.
A consequência prática é que essas perguntas precisam entrar no mesmo comitê que aprova prazo e escopo, ao lado de perguntas como “quem vai usar isso?” e “que problema isso resolve?”. Hoje elas costumam ficar de fora, tratadas como escolha técnica interna, e voltam para a mesa da liderança meses depois, na forma de uma fatura que ninguém consegue explicar.
Como medir na prática
Depois que arquitetura, modelo e caso de uso já fixaram o denominador da conta, falta a parte que a maioria das empresas pula: acompanhar esse número mês após mês, com a mesma disciplina que se aplica à margem bruta ou custo de aquisição de cliente. A primeira mudança de hábito é parar de olhar o gasto total com IA no fim do mês e passar a medir três coisas separadas.
A primeira é o custo por tarefa concluída dentro de um padrão de qualidade aceito. Não basta somar o custo de tokens de uma tarefa, é preciso somar também o custo do retrabalho, ou seja, o percentual de respostas rejeitadas multiplicado pelo custo de uma revisão humana. Uma tarefa que custa um centavo em tokens mas precisa ser refeita três vezes por um analista sênior é mais cara do que parece no painel de consumo.
A segunda é o custo por usuário ativo, calculado por período. Aqui o objetivo não é vigiar quem usa mais a ferramenta, e sim identificar se o custo por pessoa está caindo à medida que a adoção cresce, o que indica ganho de escala real, ou subindo, o que costuma indicar prompts cada vez mais longos ou modelos trocados sem critério.
A terceira, e a mais difícil de instrumentar, é o custo por resultado de negócio. Um contrato revisado, um chamado resolvido sem escalonamento, uma proposta comercial gerada por agentes de IA e aceita pelo cliente. A dificuldade não é técnica, é organizacional, pois exige que a área de negócio defina, antes de o projeto começar, o que conta como resultado, para que a área técnica saiba o que instrumentar.
Na Performa_IT acreditamos que essa organização de análise é o verdadeiro foco de retorno sobre IA, e resumiu bem o motivo dele existir. À medida que projetos saem do piloto e entram em operação contínua, a comparação relevante deixa de ser custo por unidade técnica e passa a ser custo por resultado de negócio. Comparar apenas tokens de um fornecedor com tokens de outro, segundo a mesma análise, se torna uma comparação incompleta assim que o uso envolve texto, voz e imagem ao mesmo tempo, porque cada modalidade é cobrada por uma unidade diferente.
Conectar consumo de tokens a valor gerado exige um passo que poucas empresas dão de forma sistemática. Primeiro, atribuir o consumo de tokens a uma funcionalidade ou fluxo específico, não a um projeto genérico de IA, porque um mesmo assistente pode ter dez usos internos com economias unitárias completamente diferentes. Depois, medir esse consumo em tempo real, e não em um relatório mensal fechado, já que picos de custo aparecem e desaparecem em dias, não em ciclos de orçamento. Por fim, definir uma taxa de rejeição aceitável para cada tarefa, porque é essa taxa que decide se vale a pena usar um modelo mais barato ou se o retrabalho gerado destrói a economia prometida.
Há dois casos reais que ilustram bem essa diferença entre medir atividade e medir resultado. A Intercom mudou o modelo de cobrança do seu agente de atendimento, o Fin, de um preço por resolução para um preço por resultado entregue, reconhecendo publicamente que contar conversas ou mensagens trocadas não capturava se o cliente realmente teve o problema resolvido. A Sierra, outra fornecedora de agentes de atendimento, segue a mesma lógica, cobrando apenas quando o agente entrega uma resolução bem-sucedida, negociada por contrato. Os dois casos mostram fornecedores de IA aplicando a empresas clientes a mesma disciplina que este artigo defende que as empresas apliquem internamente aos seus próprios projetos.
O segundo caso é mais instrutivo porque mostra o ciclo completo, incluindo o erro. A Klarna anunciou em 2024 que seu assistente de IA, construído sobre modelos da OpenAI, fazia o trabalho equivalente a 700 atendentes em tempo integral, reduziu o tempo médio de resolução de 11 minutos para menos de 2, e gerou uma melhoria estimada de 40 milhões de dólares no resultado da empresa naquele ano. Os números de atividade eram inegáveis. Em 2025, no entanto, a companhia recuou parcialmente, voltando a contratar atendentes humanos depois que clientes reclamaram de respostas genéricas e da dificuldade do assistente em lidar com casos mais complexos. O próprio CEO reconheceu publicamente que a empresa havia cortado demais. O episódio resume o risco deste artigo inteiro, volume de interações resolvidas por IA é uma métrica de atividade. Satisfação sustentada do cliente e taxa de reincidência do problema são métricas de resultado. A Klarna tinha a primeira em abundância e só percebeu o custo real da segunda quando o cliente reclamou.
Por que é assunto de liderança, não só de tecnologia
As três métricas descritas acima só funcionam se alguém fora da área técnica estiver olhando para elas com regularidade, porque cada uma delas afeta decisões que tecnicamente pertencem a outras áreas da empresa.
A primeira é a decisão de escopo. Quando um comitê aprova o próximo caso de uso de IA sem perguntar qual vai ser o custo por resultado esperado, ele está aprovando um escopo sem saber se ele é viável financeiramente em escala. Isso não é uma decisão técnica, é uma decisão de priorização de investimento, e cabe à liderança de negócio fazer essa pergunta antes da aprovação, não depois da primeira fatura.
A segunda é a precificação de produtos que incorporam IA. Uma empresa que cobra uma assinatura fixa por um produto cujo custo interno varia com o uso, exatamente como o custo de tokens varia, corre o risco de vender abaixo do custo assim que um cliente usa o produto de forma mais intensa do que o previsto na precificação original. É por isso que fornecedores como Intercom e Sierra abandonaram modelos de cobrança fixos em favor de cobrança por resultado. Uma empresa de médio ou grande porte que lança um produto com IA embutida e mantém a lógica antiga de precificação por assento está repetindo o mesmo erro, só que na ponta da receita em vez da ponta do custo.
A terceira é a viabilidade de escalar. Um projeto de IA que funciona bem com cem usuários pode se tornar inviável financeiramente com dez mil, se o custo por resultado não tiver sido validado antes da expansão. A grande maioria das pesquisas sobre retorno do investimento em projetos de IA aponta que boa parte das empresas ainda mede sucesso pela adoção da ferramenta, não pelo resultado financeiro que ela sustenta, e projeta que a pressão para inverter essa lógica vai vir de cima, dos CEOs cobrando dos demais executivos uma relação clara entre o que a IA custa e o que ela entrega.
Nenhuma dessas três decisões é exclusiva da área de tecnologia. Escopo é decisão de negócio. Precificação é uma decisão comercial e financeira. Viabilidade de escala é decisão do CEO e do conselho. O time técnico pode e deve instrumentar o consumo de tokens com precisão, mas não pode, sozinho, decidir se aquele consumo faz sentido para a estratégia da empresa. Essa é uma conversa que precisa acontecer na mesma sala onde se discute meta de receita e margem, não numa reunião separada de tecnologia à qual o CFO é convidado só quando algo já deu errado.
Conclusão
O nome deste artigo já carrega a virada que ele defende, toda empresa que investe em IA generativa vai, cedo ou tarde, ter que decidir entre dois caminhos para o mesmo consumo de tokens. De um lado estão o que chamo de Rot tokens (tokens podres), tokens gastos sem critério, em prompts inchados, em modelos caros demais para a tarefa, em respostas que precisam ser refeitas, em casos de uso escolhidos pela visibilidade interna e não pela economia unitária. São tokens que apodrecem o retorno do investimento antes mesmo de ele aparecer num relatório. Do outro lado estão os Hot tokens (high-outcome tokens), os tokens de alto resultado, aqueles que geram valor de verdade, uma decisão melhor, uma hora de trabalho qualificado liberada para outra coisa.
A diferença entre os dois não está na tecnologia usada, e sim na disciplina de medir. Uma empresa que não separa RoT de HoT vai, inevitavelmente, financiar mais do primeiro, porque tokens gastos sem critério são mais fáceis de gerar do que tokens que entregam resultado. É mais fácil aumentar o uso do que aumentar o valor por uso.
Por isso, monitorar e reduzir os RoT tokens, e priorizar e premiar os HoT tokens, não pode ser tarefa isolada do time de tecnologia. É responsabilidade de toda a liderança, porque a decisão de que caso de uso priorizar, que modelo aprovar, como precificar o produto e quando escalar o projeto está distribuída entre todo o c-level e áreas de negócio, não concentrada numa única cadeira. A empresa que entender isso primeiro não vai gastar menos em IA, mas vai gastar melhor e essa é a única vantagem competitiva que sobra quando o preço por token cai para todo mundo igualmente.
