A adoção de IA generativa nas empresas saiu da fase de experimentação e começou a ocupar fluxos que têm impacto direto em produtividade, atendimento, crédito, risco, compliance, marketing e operações. Nesse momento, a pergunta deixa de ser “funciona?” e passa a ser “funciona de forma sustentável, com previsibilidade de custo e controle de risco?”.
É nesse ponto que muitos programas de IA entram em atrito.
A organização investe em modelos, pilotos e integrações, valida que a solução responde bem e decide colocar em produção. Quando o uso cresce, o orçamento começa a se deslocar sem explicação clara, e o debate vira uma disputa entre tecnologia, finanças e áreas usuárias.
A origem desse descompasso costuma ser uma variável que não aparece no discurso executivo com a mesma frequência que aparece na fatura: tokens. Como resume Thiago de Moraes Dutra, Diretor Executivo de Pesquisa e Desenvolvimento da MATH Group, o mercado concentra energia em escolher modelos, mas raramente trata o custo recorrente como parte do desenho da solução.
Contexto e diagnóstico
Há uma mudança estrutural em curso.
Com IA generativa, o custo não é apenas o da infraestrutura tradicional nem o de uma licença por usuário. Ele se comporta como um consumo variável por interação, influenciado por contexto, histórico, documentos anexados, qualidade do dado, regras do agente e padrão de uso das equipes. Esse modelo de consumo é mais próximo de uma operação contínua do que de um projeto pontual.
O desafio é que, em muitas empresas, a governança de IA ainda é tratada como um conjunto de princípios abstratos. Falta transformar governança em mecanismos operacionais: limites, medições, alocação de custo, alertas, critérios de arquitetura e responsabilidade por decisão. Sem esses mecanismos, a organização não consegue responder a perguntas simples, porém decisivas: quanto custa manter um caso de uso em produção, por área e por jornada, e qual valor está sendo capturado em troca.
Tokens se tornam, então, uma espécie de “custo invisível” não porque sejam misteriosos, mas porque entram na operação antes de entrarem na planilha. Eles nascem no design do prompt, na forma de compor contexto, na decisão de manter histórico, na política de anexos, no modo como o agente consulta documentos e no quanto a organização tolera respostas longas, redundantes ou sem foco.
Tokens como variável operacional
Para quem não vive o dia a dia de tecnologia, “token” costuma ser associado a autenticação. Em IA generativa, tokens são unidades mínimas de texto processadas por modelos de linguagem. Eles podem ser palavras, partes de palavras, números, símbolos e até espaços. A cada interação, há consumo de tokens de entrada, que incluem prompt, instruções e contexto, e consumo de tokens de saída, que correspondem à resposta gerada.
O ponto crítico é que, em contexto corporativo, quase tudo passa a entrar nesse pacote de entrada. Se o produto ou a solução carrega histórico completo por padrão, cada turno fica mais caro do que o anterior. Se o usuário anexa documentos longos e o sistema injeta esse conteúdo na conversa sem filtragem, a organização está pagando para o modelo ler material que nem sempre é necessário para decidir. Se as instruções do sistema são extensas, repetidas e pouco modularizadas, o custo se torna recorrente e difícil de reduzir sem reengenharia.
É por isso que tokens não devem ser tratados apenas como detalhe técnico.
Eles viram uma métrica operacional comparável a tempo de atendimento, custo por transação, retrabalho e taxa de erro. Se o objetivo é colocar IA em fluxos críticos, tokens precisam entrar no mesmo plano de gestão: medição, alocação, limites e melhoria contínua.
Em um piloto, o volume de uso é baixo, os usuários são poucos, o escopo é limitado e quase sempre existe supervisão de perto do time técnico. Em produção, a realidade muda. O caso de uso se espalha para áreas com rotinas diferentes, horários diferentes, níveis de maturidade diferentes e necessidades que aumentam o volume de contexto. O que era “uma conversa” vira dezenas de milhares de interações, e pequenas ineficiências de design se multiplicam.
Há um padrão que se repete. A solução funciona bem em um primeiro recorte, gera confiança, entra na operação e passa a ser usada com liberdade. Sem limites e observabilidade, o custo cresce de forma silenciosa até virar pauta de comitê, e o projeto perde sustentação política por não conseguir explicar o desvio.
Algumas causas aparecem com frequência nesse ponto de virada:
Uma política de contexto que sempre traz mais informação do que o necessário, por segurança, não por critério.
Prompts extensos e pouco padronizados, com instruções repetidas a cada turno.
Histórico acumulado sem resumo e sem recorte de relevância, fazendo com que a conversa “engorde” indefinidamente.
Agentes com autonomia para iterar e consultar fontes sem regra de parada, gerando loops caros.
Documentos anexados sem indexação e sem recuperação sob demanda, o que transforma leitura em custo fixo.
Em muitos casos, a empresa paga para o modelo processar redundância. A tecnologia não falha, mas a arquitetura incentiva consumo elevado sem garantia proporcional de valor.
FinOps de IA como decisão de arquitetura
FinOps é frequentemente lembrado como disciplina de controle de gasto em cloud. Em IA, ele precisa ser incorporado antes, como parte da arquitetura e do modelo operacional do produto, não como ajuste posterior feito para “conter a fatura”. A lógica é simples: se o custo é determinado por como a solução usa tokens, então o controle precisa acontecer no design.
Quando uma empresa trata custo de IA como problema exclusivamente financeiro, ela chega tarde. O financeiro consegue enxergar o total gasto; o que ele não consegue, sozinho, é decompor esse total por caso de uso, por jornada, por padrão de contexto, por time, por agente, por modelo e por tipo de interação. Essa decomposição é uma decisão de instrumentação e governança técnica.
Na prática, FinOps de IA começa com três movimentos:
Instrumentar: registrar consumo de tokens e custo associado por interação, com tags de usuário, área, aplicação, caso de uso, fluxo e modelo utilizado.
Alocar: criar um modelo de chargeback ou showback que permita enxergar onde o consumo acontece, sem transformar o tema em disputa política. O objetivo não é “punir” áreas, mas permitir priorização racional.
Otimizar: desenhar mecanismos que reduzam desperdício, como roteamento de modelos por complexidade, limites por sessão, compressão de contexto, cache de respostas para perguntas recorrentes, e recuperação de conhecimento sob demanda em vez de anexar documentos inteiros.
Entre as recomendações mais consistentes para reduzir variabilidade e aumentar previsibilidade estão design consciente de tokens, prompts enxutos e reutilizáveis, contexto mínimo viável, monitoramento por usuário e caso de uso, alertas em tempo real, uso de modelos mais econômicos quando possível e correlação explícita entre custo e valor de negócio.
Uma discussão madura sobre custo de tokens não termina em “reduzir tokens”. Ela começa com “qual decisão esta interação suporta” e “qual valor essa decisão captura”. Sem essa ponte, o programa de IA cai em dois erros simétricos: reduzir custo a qualquer preço e perder qualidade, ou manter qualidade sem governar custo e perder sustentabilidade.
Um caminho prático é traduzir cada caso de uso em uma unidade de valor que faça sentido para o negócio. Em vez de medir apenas volume de mensagens, a empresa mede custo por resultado: custo por ticket resolvido, custo por análise de risco concluída, custo por proposta gerada e revisada, custo por conciliação finalizada, custo por minuto de retrabalho evitado. A partir daí, passa a ser possível comparar eficiências entre fluxos e priorizar onde investir.
Um exemplo realista: imagine um agente de atendimento que responde dúvidas sobre contrato. Se ele sempre carrega o contrato inteiro, mais políticas internas, mais histórico completo do cliente, o custo por resposta cresce, mesmo quando a pergunta é simples. Se a arquitetura for redesenhada para recuperar apenas trechos relevantes, resumir histórico e aplicar um padrão de resposta mais direto, o custo por resolução cai sem reduzir a taxa de acerto. O ganho não é só financeiro. É previsibilidade para escalar.
Outro exemplo: um agente interno de apoio a analistas que consulta relatórios longos. Sem indexação e recuperação sob demanda, a equipe tende a anexar documentos completos, e o sistema tende a “ler tudo” para responder qualquer pergunta. Com uma camada de busca e recorte de contexto, a organização paga para o modelo raciocinar sobre o necessário, não sobre o disponível.
O indicador decisivo passa a ser “custo por resposta que gera decisão” e, principalmente, “custo por resposta que evita trabalho humano relevante”. É nessa relação que o ROI deixa de ser narrativa e vira critério.
Este tema conversa com o artigo “Era dos testes com IA acabou”, que discute o momento em que a IA deixa de ser experimento e passa a exigir disciplina de operação
Sem governança, tokens viram apenas uma variável de consumo. Com governança, tokens viram um instrumento de controle de risco operacional. Isso acontece porque custo e risco caminham juntos quando IA entra em fluxos críticos.
Se o consumo cresce sem controle, a empresa perde previsibilidade de orçamento. Se perde previsibilidade, começa a restringir uso de forma indiscriminada, o que reduz valor. Se não consegue explicar variações de custo por fluxo, perde capacidade de priorizar e de justificar investimentos. Em paralelo, a ausência de limites e rastreio abre espaço para erros de arquitetura que também elevam risco: agentes que acessam mais dados do que precisam, logs incompletos, decisões sem trilha de auditoria e respostas com baixa consistência.
O paralelo com cloud é útil como alerta. Muitas organizações aprenderam, na prática, que consumo variável exige disciplina de governança e observabilidade. Em IA, esse aprendizado precisa ser acelerado, porque a velocidade de adoção e o volume de interações tendem a crescer mais rápido.
Um modelo de governança aplicável costuma incluir:
Definição de “dono” por caso de uso, com responsabilidade por custo, qualidade e risco.
Políticas claras de contexto, histórico e anexos, com padrões por tipo de fluxo.
Limites e regras de parada para agentes, evitando iterações sem fim e consultas redundantes.
Alertas por anomalia de consumo, detectando desvios antes que virem surpresa financeira.
Revisões periódicas de prompts, instruções e base de conhecimento, com foco em reduzir repetição e aumentar precisão.
Quando isso existe, a pergunta deixa de ser “qual modelo é melhor” e passa a ser “quanto custa cada resposta, qual valor ela entrega e quais controles garantem que esse custo não se torna uma variável fora do orçamento”.
Tokens são a unidade que conecta arquitetura, consumo e governança em IA generativa. Ignorá-los não impede o custo; apenas empurra a discussão para o momento em que já existe tensão entre times e quando o orçamento já foi impactado. Medir e governar tokens não é obsessão por detalhe técnico. É o que permite sustentar IA em produção sem transformar ganhos iniciais em frustração recorrente.
Se fizer sentido, a MATH pode apoiar o mapeamento dos fluxos e a definição da camada de orquestração e observabilidade necessária para colocar IA em operação com previsibilidade usando a MATH AI Platform.