Por que custo por tarefa importa mais que preço por token

# 5. Por que custo por tarefa importa mais que preço por token *Preço por token ajuda a entender a tarifa. Custo por resultado ajuda a decidir se a automação vale a pena.* Duas soluções prometem automatizar o mesmo trabalho. Uma utiliza um modelo com preço baixo por token. A outra custa mais a cada chamada. Qual delas é mais econômica? Ainda não há informação suficiente para responder. Precisamos saber quantas tentativas cada uma exige, quanto trabalho humano permanece e quantos resultados realmente atendem ao objetivo. Nós, da KeyCore, defendemos que essa comparação comece pela operação. Se uma automação produz respostas baratas que alguém precisa refazer, parte do custo apenas saiu da fatura da API e voltou para a agenda da equipe. A FinOps Foundation descreve essa evolução das métricas de IA: partir do consumo técnico e avançar para unidades associadas ao resultado do negócio. O objetivo é entender o que foi entregue com aquele consumo, não apenas contar tokens. [1] ## Antes de medir o custo, defina o que significa concluir Um atendimento não está necessariamente resolvido porque a IA enviou uma resposta. Um agendamento não está concluído porque o agente escreveu uma data. Uma análise não está pronta apenas porque existe um documento. A primeira decisão é estabelecer um critério de sucesso verificável. Em um fluxo de agendamento, por exemplo, poderíamos considerar concluída a tarefa quando há uma reserva válida no sistema, vinculada ao cliente correto e comunicada adequadamente. Em uma triagem documental, o resultado aceito pode exigir campos obrigatórios preenchidos e validações aprovadas. Esses critérios são propostas de medição. Cada negócio precisa escolher uma definição que represente seu resultado real, evitando confundir atividade com entrega. Sem isso, um painel pode comemorar milhares de interações enquanto a equipe continua executando o trabalho mais importante manualmente. ## A conta precisa incluir o processo inteiro Propomos uma fórmula operacional simples: ```text Custo por tarefa concluída = Custo total atribuível ao fluxo no período ÷ Quantidade de tarefas que atingiram o critério de sucesso ``` No numerador, entram os custos das tentativas bem-sucedidas e das que falharam. Esconder o gasto das falhas faria o processo parecer mais eficiente do que é. Recomendamos considerar consumo do modelo, ferramentas externas, processamento, infraestrutura atribuída e tempo humano de conferência ou correção. Em canais de voz, por exemplo, pode existir custo além do modelo de linguagem, conforme a solução contratada. Abandono, atraso e perda de oportunidades também merecem acompanhamento. Não é necessário inventar um valor financeiro para todos eles. É melhor manter uma métrica operacional honesta do que preencher a planilha com estimativas sem fundamento. A perspectiva da FinOps Foundation é conectar consumo e valor produzido. Isso não significa que toda empresa precise começar com uma estrutura sofisticada de rateio. Significa que a tarifa isolada não deve encerrar a análise. [2] ## Um exemplo numérico, sem esconder o retrabalho A tabela abaixo é uma **simulação didática**, não uma comparação real de fornecedores nem um resultado obtido pela KeyCore. Os dois fluxos recebem 1.000 tarefas semelhantes no período. | Item da simulação | Fluxo A: modelo de menor tarifa | Fluxo B: modelo de maior tarifa | |---|---:|---:| | Consumo dos modelos | R$ 120,00 | R$ 320,00 | | Ferramentas e reprocessamento externo | R$ 180,00 | R$ 60,00 | | Tempo humano atribuído ao fluxo | R$ 500,00 | R$ 100,00 | | Infraestrutura atribuída | R$ 100,00 | R$ 100,00 | | Custo total | R$ 900,00 | R$ 580,00 | | Tarefas que atingiram o critério de sucesso | 700 | 900 | | Custo por tarefa concluída | R$ 1,29 | R$ 0,64 | Neste exemplo, os custos de consumo dos modelos já incluem suas novas tentativas. A linha de reprocessamento externo não os conta novamente. O fluxo B gasta mais com modelos, mas entrega mais tarefas aceitas com menor custo total. O cálculo é R$ 900 dividido por 700 no primeiro caso e R$ 580 dividido por 900 no segundo, com arredondamento para centavos. Isso não demonstra que modelos caros são sempre melhores. Demonstra que o preço de uma etapa não determina, sozinho, o custo do processo. ## Tempo devolvido também precisa de critério Uma automação pode reduzir o esforço total e, ainda assim, demorar demais para o cliente. Outra pode responder rapidamente, mas exigir correção posterior. Por isso, recomendamos acompanhar três dimensões em conjunto: custo por resultado aceito, qualidade e tempo até a conclusão. O tempo humano de supervisão deve permanecer visível, mesmo quando não é cobrado separadamente na fatura do produto. Também é importante distinguir capacidade liberada de economia financeira realizada. Recuperar horas da equipe pode permitir mais atendimento ou mais análise, sem reduzir imediatamente a despesa mensal da empresa. Na KeyCore, “devolver tempo” não deve virar um número decorativo. A pergunta é onde esse tempo deixou de ser consumido e para qual atividade mais útil ele pode ser direcionado. ## Como escolher a rota certa para cada tarefa Nossa proposta não é encontrar um único modelo vencedor para tudo. É construir rotas compatíveis com o tipo de trabalho. Uma informação estruturada e estável pode vir de uma consulta ao sistema. Uma tarefa curta pode usar um modelo econômico, desde que passe na avaliação de qualidade. Uma análise difícil pode justificar um modelo mais capaz. Uma decisão sensível pode continuar dependendo de uma pessoa. O encaminhamento para uma rota mais cara deve seguir critérios verificáveis, como ausência de dados obrigatórios ou falha em uma validação. Não recomendamos depender somente da “confiança” declarada pelo próprio modelo. Também é necessário contabilizar o custo da escalada. Se o fluxo sempre começa com uma tentativa que falha antes de chamar o modelo adequado, a aparente economia pode desaparecer. ## O que registrar para comparar com justiça Para cada execução, recomendamos manter um identificador da tarefa, a versão do fluxo, os modelos utilizados, o custo atribuído e o resultado de aceitação. O contexto de autorização e o vínculo com a empresa atendida também precisam acompanhar a medição. Os testes devem usar tarefas representativas da operação, com critérios equivalentes entre as alternativas. Casos fáceis demais podem esconder o retrabalho que aparece nos atendimentos reais. Um artigo da AWS sobre a Jamf mostra a importância de atribuir o consumo de IA a usuários e aplicar controles de gasto. Essa visibilidade é útil, mas não equivale, por si só, a medir o resultado entregue ao cliente. [3] Para nós, são duas perguntas complementares: quem consumiu os recursos e qual trabalho foi concluído com eles? ## Comece por um processo, não pela empresa inteira Escolha uma rotina repetitiva com resultado identificável. Meça como ela funciona hoje. Em seguida, compare um fluxo automatizado com a referência, usando o mesmo critério de qualidade. Depois de identificar os principais custos, ajuste uma variável por vez: quantidade de contexto, modelo, validação, ferramenta ou intervenção humana. Assim fica mais fácil entender de onde veio a melhoria. Essa é a conexão que buscamos entre engenharia e negócio: decisões técnicas sustentadas pelo impacto no processo, e não apenas por uma tabela de preços ou por um resultado de demonstração. **Preço por token é uma tarifa. Custo por tarefa concluída é uma forma de enxergar se a tecnologia está realmente ajudando a operação.** **Continue a leitura:** [Como impedir que um tenant consuma todo o orçamento de IA](/blog/orcamento-ia-saas-multi-tenant). ## Fontes e referências **[1]** FinOps Foundation. *Capability: Unit Economics*. **[2]** FinOps Foundation. *Token Economics: The Atomic Unit of AI Value*. **[3]** AWS. *Tokenomics at scale: How Jamf built real-time spend enforcement for Amazon Bedrock*. *Referências consultadas em 8 de setembro de 2026.* [1]: https://www.finops.org/framework/capabilities/unit-economics/ [2]: https://www.finops.org/insights/token-economics-the-atomic-unit-of-ai-value/ [3]: https://aws.amazon.com/blogs/machine-learning/tokenomics-at-scale-how-jamf-built-real-time-spend-enforcement-for-amazon-bedrock/