Uma das maiores surpresas de quem coloca IA em produção não costuma ser a qualidade das respostas. É a fatura de tokens.

Muita gente ainda encara o custo de um LLM como se fosse o licenciamento de um software SaaS, com um valor relativamente previsível por usuário. Na prática, porém, a lógica é completamente diferente.

Na maioria dos provedores de IA generativa, a cobrança é baseada na quantidade de tokens processados. Isso inclui os tokens enviados ao modelo, como prompts, instruções do sistema, histórico da conversa e contexto recuperado por RAG, e também os tokens gerados na resposta. Se um agente realiza várias chamadas ao modelo para concluir uma tarefa, cada inferência representa um novo consumo.

O problema é que esse consumo cresce de forma pouco intuitiva. Imagine um usuário fazendo apenas uma pergunta. Nos bastidores, o agente pode consultar um índice vetorial, recuperar diversos documentos, chamar APIs, acessar memória, solicitar ajuda a outros agentes, executar várias inferências intermediárias e só então produzir uma resposta. O usuário percebe uma única interação. O sistema pode ter realizado dez ou vinte chamadas ao modelo.

Em arquiteturas multiagentes esse efeito é ainda mais intenso. Um agente especializado pode consultar outro, que consulta um terceiro, que reescreve uma resposta antes de devolvê-la ao usuário. Cada etapa consome novos tokens. Sem observabilidade, ninguém percebe onde o custo realmente está sendo gerado.

Outro fator pouco lembrado é o tamanho do contexto. Muitas equipes acreditam que enviar mais documentos melhora automaticamente a qualidade das respostas. Nem sempre. Além de aumentar o custo, contexto excessivo pode reduzir a precisão do modelo, que passa a lidar com informações irrelevantes ou conflitantes. É o chamado context dilution: mais informação não significa necessariamente mais qualidade.

Há também um aspecto comportamental. Durante o desenvolvimento, costuma-se testar o sistema com poucas consultas. Em produção, centenas ou milhares de usuários fazem perguntas simultaneamente, muitas delas inesperadas. Pequenas ineficiências tornam-se enormes multiplicadores de custo. Um fluxo que desperdiça apenas alguns centavos por execução pode representar dezenas ou centenas de milhares de dólares ao longo de um ano.

O maior problema é que, na maioria das organizações, esse consumo continua sendo uma caixa-preta.

Poucas empresas conseguem responder perguntas relativamente simples: qual agente é responsável pela maior parte do consumo? Qual processo apresenta o pior custo-benefício? Quanto custa atender um cliente específico? O aumento da conta veio do crescimento da demanda ou de uma degradação da arquitetura? Quanto do custo decorre do modelo e quanto resulta de um contexto excessivo ou de chamadas desnecessárias?

Sem essas respostas, qualquer tentativa de otimização vira tentativa e erro. É justamente por isso que começa a ganhar importância o conceito de AI FinOps.

Assim como o FinOps surgiu para controlar gastos variáveis em computação em nuvem, a IA exige disciplina semelhante. Não basta saber quanto foi gasto no mês. É preciso entender por que aquele gasto ocorreu.

Isso exige monitorar o consumo por agente, processo, usuário e unidade de negócio, estabelecer orçamentos e alertas, criar indicadores de custo por tarefa executada e acompanhar continuamente a relação entre custo, qualidade e valor entregue.

Também exige repensar a arquitetura. Nem toda tarefa precisa passar por um LLM. Regras de negócio, consultas a bancos de dados, cálculos e validações determinísticas continuam sendo executados de forma muito mais rápida, barata e previsível por software tradicional. O modelo deve ser utilizado apenas quando realmente agrega capacidade cognitiva.

Outra prática importante é reduzir o contexto ao mínimo necessário. Um bom mecanismo de recuperação de informação não é aquele que envia todos os documentos disponíveis ao modelo, mas aquele que entrega apenas as evidências realmente relevantes para aquela consulta.

Também vale adotar modelos diferentes conforme a complexidade da tarefa. Muitas empresas utilizam sempre o modelo mais poderoso e mais caro, quando boa parte das solicitações poderia ser atendida por modelos menores, especializados ou até locais, reduzindo significativamente os custos sem perda perceptível de qualidade.

Por fim, agentes precisam ser observados continuamente. Assim como monitoramos CPU, memória ou latência em sistemas tradicionais, devemos acompanhar métricas como consumo de tokens, custo por execução, número de inferências por tarefa, taxa de sucesso, qualidade das respostas e impacto de alterações em prompts, modelos ou bases de conhecimento.

O maior problema raramente é o preço do token. É não compreender por que ele está sendo consumido. Na IA corporativa, controlar custos deixou de significar apenas negociar contratos com fornecedores. Passa a exigir visibilidade sobre como agentes, modelos, contexto, ferramentas e processos interagem durante a execução de cada tarefa.

O desafio não é consumir menos tokens. É garantir que cada token consumido gere valor para o negócio.