Quanto custou a última entrega feita com IA? Por que a fatura de tokens não responde a essa pergunta
A fatura de uma ferramenta de IA para desenvolvimento chega agregada: um valor total do mês, no máximo quebrado por usuário. A pergunta que a diretoria faz é outra, e é econômica: quanto custou entregar aquela funcionalidade, e o resultado justificou o gasto? Entre as duas coisas existe uma lacuna que o Gartner nomeia com clareza, ao afirmar que a maioria das organizações ainda não tem maturidade nem framework para medir custo contra impacto de negócio, e que o gasto orientado a tokens fica cada vez mais difícil de justificar, com orçamentos se esgotando antes do esperado. Fechar essa lacuna exige unir três camadas de dado que quase nunca conversam: a telemetria de consumo da IA, a unidade de trabalho onde a entrega é registrada, e uma plataforma analítica onde o cruzamento vira leitura confiável. Sem as três, existe fatura. Com as três, existe economia unitária.
A pergunta que ninguém consegue responder na reunião de orçamento
A cena é previsível e acontece por volta do segundo trimestre de uso em escala. O CFO pergunta quanto a empresa gastou com ferramentas de IA no semestre, e a resposta existe, porque é o valor da fatura. Em seguida ele pergunta o que se obteve com isso, e a conversa muda de tom. Alguém cita percepção de produtividade, outro cita a sensação de que o time entrega mais rápido, um terceiro lembra de uma funcionalidade específica que saiu antes do previsto.
Nenhum deles traz um número.
Não é falta de rigor do time. É que o dado necessário para responder simplesmente não existe organizado. O Gartner descreve o cenário ao apontar que, sem visibilidade clara do uso de tokens nas tarefas de desenvolvimento, as organizações correm risco de estouro de orçamento e perdem a capacidade de acompanhar a relação entre custo e valor entregue. O release também registra que a migração do licenciamento por assento para o licenciamento por consumo introduziu estruturas de custo altamente variáveis, e que muitos fornecedores carecem de transparência sobre como o consumo é calculado e cobrado, o que limita a capacidade de prever e controlar.
A tese deste guia: a fatura mede o fornecedor; a entrega mede o negócio. Enquanto a empresa só olhar o total consumido, ela consegue no máximo cortar gasto, e cortar gasto sem saber o que ele produz é tão arriscado quanto gastar sem controle. A pergunta que destrava orçamento não é “quanto gastamos em IA”, é “quanto custou cada entrega e o que ela devolveu”. Responder isso é um problema de engenharia de dados, não de negociação com fornecedor.
Três motivos pelos quais a fatura nunca vai responder sozinha
1 · Ela é agregada no eixo errado
A fatura organiza o gasto por conta, por período e, quando muito, por usuário. O negócio organiza valor por entrega: uma funcionalidade, uma correção, um projeto. São dois eixos diferentes, e nenhum relatório de fornecedor faz essa tradução, porque o fornecedor não sabe o que a sua empresa considera uma entrega.
2 · Falta a chave que liga consumo a trabalho
Para dizer quanto custou uma entrega, é preciso saber quais chamadas de IA pertenceram a ela. Isso exige uma chave comum entre o registro de consumo e o item de trabalho, e essa chave raramente existe por padrão. Sem ela, o rateio vira estimativa, e estimativa não sobrevive a uma pergunta do financeiro.
3 · A definição de “entrega” varia entre áreas
Mesmo com dado disponível, o número diverge quando cada time define entrega do seu jeito: uma história, um épico, um deploy, uma funcionalidade percebida pelo usuário. É o mesmo problema de métrica sem dono único que já tratamos no cluster de dados, aplicado agora ao custo de IA. Sem definição única, dois relatórios corretos mostram números diferentes para a mesma pergunta.
As três camadas que tornam o custo por entrega mensurável
Medir economia unitária de IA não é um relatório, é uma arquitetura. Três camadas precisam existir e se conectar:

A leitura da tabela é o argumento central: nenhuma das três camadas resolve sozinha, e as três já existem em empresas de porte, só que desconectadas. A telemetria fica no ambiente de execução, a unidade de trabalho fica no Jira, e a plataforma analítica fica cuidando de dado de negócio, sem enxergar nenhuma das duas. O trabalho de consultoria é fechar esse triângulo.
A chave que liga consumo a entrega
O elo técnico mais delicado é a associação entre a chamada de IA e o item de trabalho. Três abordagens funcionam, e podem se combinar:
• Identificador explícito no fluxo. A chave do item de trabalho acompanha a interação com a IA, seja pelo branch, pelo commit ou por parâmetro na chamada. É a abordagem mais precisa e a que exige mais disciplina de processo.
• Correlação por contexto de código. O arquivo ou módulo tocado pela interação é associado ao item de trabalho que alterou aquele mesmo código. Depende de convenção de commit consistente.
• Correlação temporal por pessoa. O consumo de um desenvolvedor em uma janela de tempo é atribuído ao item em que ele estava trabalhando naquele período. É a mais simples e a menos precisa, útil como aproximação inicial.
Do lado do Jira, o insumo que sustenta as três abordagens é o histórico de transições de cada item, disponível na API oficial da Atlassian por meio da expansão do changelog. É esse histórico que informa quando o item entrou e saiu de cada estado, permitindo tanto a correlação temporal quanto a leitura de quanto tempo cada etapa levou, que é o outro lado da equação de valor.
Por que isso vira projeto de plataforma de dados
Assim que a correlação passa de um experimento para uma leitura recorrente, o problema deixa de ser de planilha e vira de plataforma. São duas fontes com volumes e formatos distintos, que precisam ser unificadas, governadas e servidas a quem decide. É exatamente o desenho que a arquitetura do Lakehouse endereça, com a camada de governança do Unity Catalog controlando acesso, linhagem e auditoria dos ativos, e a organização em camadas do padrão medalhão levando o dado bruto até a tabela pronta para consumo.
Na prática, a telemetria de consumo entra como fonte bruta, a informação de entrega do Jira entra como a outra fonte, a camada intermediária resolve correlação e qualidade, e a camada de consumo entrega as métricas com definição única. A partir daí, a leitura executiva é trabalho conhecido de BI: um modelo semântico onde custo por entrega e tempo de ciclo são definidos uma vez e valem em todo relatório, o que evita a divergência de números entre áreas.
O padrão que se repete, e não por acaso: economia unitária de IA é o mesmo pipeline que este blog vem descrevendo em outros contextos, com uma fonte nova. Origem saudável no Jira, unificação e governança na plataforma de dados, leitura com definição única no BI. É por isso que uma consultoria de IA que não domina dado e não domina a camada de trabalho consegue, no máximo, recomendar boas práticas. Medir exige o pipeline. A CSP Tech opera as três pontas, com consultoria Jira como Atlassian Gold Partner, atuação como especialistas Databricks na plataforma, e Microsoft Gold Partner na leitura executiva.
O que passa a ser respondível quando a arquitetura existe
• Custo por entrega e sua distribuição. Quais tipos de trabalho consomem desproporcionalmente, e se a diferença se justifica pela complexidade ou é desperdício.
• Custo contra tempo de ciclo. Se o gasto adicional de IA está de fato reduzindo o tempo entre início e conclusão, ou se está apenas acompanhando o trabalho sem alterar o resultado.
• Eficácia por modelo. Se o modelo mais caro entrega resultado proporcionalmente melhor nas tarefas em que é acionado, insumo direto para a política de roteamento que o Gartner recomenda.
• Justificativa defensável de orçamento. A conversa com o financeiro deixa de ser sobre percepção e passa a ser sobre a relação entre gasto e entrega, que é o vocabulário em que orçamento se aprova.
Quando montar isso ainda não compensa
• Gasto pequeno diante do custo da medição. Se a fatura de IA é marginal no orçamento de engenharia, construir a arquitetura de medição custa mais que o problema. Vale revisitar quando o uso escalar.
• Registro de trabalho ainda inconsistente. Se o time não registra o trabalho de forma disciplinada, não há unidade a que atribuir custo. A ordem é higiene na origem primeiro, medição depois, como já tratamos no cluster.
• Nenhuma decisão depende do número. Medir para arquivar é custo sem retorno. Se não há decisão pendente (renovar contrato, ajustar política, redistribuir orçamento), a medição pode esperar.
Perguntas frequentes
Por que a fatura da ferramenta de IA não mostra o custo por entrega?
Porque ela é organizada por conta, período e usuário, enquanto o negócio organiza valor por entrega. O fornecedor não sabe o que a sua empresa considera uma entrega, e o Gartner registra que muitos fornecedores nem sequer são transparentes sobre como o consumo é calculado e cobrado, o que limita a capacidade de prever e controlar custos. A tradução entre os dois eixos é trabalho interno de arquitetura de dados.
O que é economia unitária de IA em engenharia de software?
É a leitura do custo de IA por unidade de valor entregue, em vez do total consumido no período. Exige três camadas conectadas: a telemetria de consumo por chamada, a unidade de trabalho onde a entrega é registrada, e uma plataforma analítica que una as duas com governança e métrica de definição única. É o que permite responder se o gasto se converteu em resultado.
Como associar o consumo de tokens a um item do Jira?
Por identificador explícito que acompanha a interação (via branch, commit ou parâmetro na chamada), por correlação entre o código tocado e o item que alterou aquele código, ou por correlação temporal entre o consumo de uma pessoa e o item em que ela trabalhava. As três se apoiam no histórico de transições de cada item, disponível na API oficial da Atlassian pela expansão do changelog. A primeira é a mais precisa e a que mais exige disciplina de processo.
Preciso de uma plataforma de dados para medir isso?
Para um experimento pontual, não. Para leitura recorrente e auditável, sim, porque são duas fontes de formatos e volumes diferentes que precisam ser unificadas, governadas e servidas com consistência. A arquitetura do Lakehouse endereça esse desenho, com governança de acesso, linhagem e auditoria na camada de catálogo e organização do dado em camadas até a tabela de consumo. Sem isso, o cruzamento vira planilha manual que ninguém mantém.
Próximo passo
Se a sua empresa já usa IA em escala no desenvolvimento e a próxima reunião de orçamento vai cobrar retorno, o ativo mais valioso a construir agora não é mais controle de gasto: é a capacidade de mostrar o que cada entrega custou e o que devolveu. Solicite um diagnóstico de economia unitária de IA com a CSP Tech e receba o mapa das três camadas no seu ambiente: que telemetria já existe, o que o seu Jira já permite correlacionar e o que precisa ser construído na plataforma de dados para o número virar defensável.
Autor: Guilherme Matos, estrategista de conteúdo e IA, certificado HubSpot, Google, Anthropic e Semrush. Revisão técnica por especialistas de dados e Atlassian da CSP Tech (Atlassian Gold Partner, Microsoft Gold Partner, parceira Databricks, participante do Anthropic Partner Network, 34 anos de mercado, produto próprio Power BI for Jira no Atlassian Marketplace).
Fontes (oficiais, acesso ago/2026): Gartner, press release “Gartner Predicts AI Coding Costs Will Surpass Average Developer's Salary by 2028 as Token Consumption Surges” (gartner.com/en/newsroom, Stamford, 24/jun/2026), do qual foram usadas as afirmações sobre falta de maturidade e frameworks para medir custo contra impacto de negócio, risco de estouro de orçamento sem visibilidade do uso de tokens, migração para licenciamento por consumo, ausência de transparência de fornecedores e a recomendação de roteamento de modelos por complexidade. Todas atribuídas ao Gartner e mantidas como previsão, tendência ou recomendação, sem conversão em fato realizado. Atlassian Developer, Jira Cloud platform REST API, uso da expansão de changelog para histórico de transições (developer.atlassian.com). Databricks Documentation, arquitetura medalhão e Unity Catalog, para governança, linhagem e organização em camadas (docs.databricks.com). Microsoft Learn, modelo semântico do Power BI como camada de definição única de métricas (learn.microsoft.com/power-bi).










