Horas poupadas não são dinheiro ganho, e os casos de negócio de IA confundem as duas coisas

No primeiro semestre de 2025, um grupo de pesquisa chamado METR conduziu um ensaio randomizado com dezesseis desenvolvedores experientes de código aberto. Cada um trabalhava em projetos maduros que conhecia bem, com cerca de cinco anos de experiência prévia em média, e cada tarefa, 246 ao todo, era atribuída ao acaso para permitir ou proibir as ferramentas de IA da época, principalmente o Cursor Pro com o Claude 3.5 e 3.7 Sonnet. Antes de começar, os desenvolvedores previram que a IA reduziria o tempo de conclusão em 24%. O resultado medido foi o oposto: com a IA permitida, as tarefas levaram 19% mais tempo. Depois do estudo, quando perguntados, os desenvolvedores estimaram que a IA havia reduzido o tempo deles em 20%. Especialistas em economia e em aprendizado de máquina consultados de antemão haviam previsto acelerações perto de 40%.

O estudo foi pequeno, com uma população particular de pessoas altamente qualificadas trabalhando em bases de código que conheciam intimamente, e seus autores dizem com clareza que não deve ser estendido a todos os desenvolvedores nem a todas as tarefas. Mesmo assim, é um alerta útil sobre as evidências em que a maioria dos casos de negócio se apoia. As pessoas que usavam a ferramenta erraram sobre o efeito dela sobre si mesmas, por cerca de quarenta pontos percentuais e no sentido errado. Um caso de negócio construído sobre pesquisas de quanto tempo as pessoas acham que pouparam se apoia numa medida que, em pelo menos um teste cuidadoso, não acompanhou a verdade.

Este ensaio acompanha uma hora desde o momento em que alguém diz que ela foi poupada até o momento em que aparece como dinheiro, e argumenta que a maior parte dos retornos de IA que se relatam é potencial e não realizada. A distinção importa, porque o lado dos custos no livro-razão é real e o lado dos benefícios é muitas vezes uma previsão.

Quatro números que parecem retorno

O primeiro é o uso: quantas pessoas entraram, quantos prompts foram enviados. Mostra interesse. O segundo é o tempo poupado autodeclarado, em geral de uma pesquisa. Mostra crença, e o resultado da METR mostra o quanto a crença pode estar longe da medição. O terceiro é o tempo medido por tarefa para tarefas feitas com e sem a ferramenta, que é evidência genuína de uma mudança de eficiência, embora só para essas tarefas. O quarto é o valor financeiro: um custo que caiu, uma linha de receita que subiu, uma contratação que foi evitada. Só o quarto é um retorno, e ele precisa de um caminho a partir do terceiro.

Esse caminho tem quatro conversões, e cada uma perde alguma coisa.

A primeira conversão é do tempo relatado para o tempo real. Os autorrelatos exageram, como o ensaio mostrou, e as tarefas diferem quanto ao quanto a ferramenta ajuda. Um desconto é apropriado até que a medição o substitua.

A segunda é do tempo poupado numa tarefa para o tempo liberado numa semana. Cinco minutos poupados em cada uma de doze tarefas por dia só viram uma hora se as tarefas puderem ser comprimidas e a pessoa não estiver esperando outra coisa. O tempo poupado em fragmentos tende a ser absorvido, gasto em cafés mais lentos, e-mails mais cuidadosos ou trabalho que se expande para preencher o dia.

A terceira é do tempo liberado para a capacidade redirecionada. A hora precisa ir para algo valioso: mais clientes atendidos, um projeto concluído mais cedo, uma pendência liquidada. Se a capacidade extra não tem nada que a absorva, o valor é zero, por maior que pareça o número de horas.

A quarta é da capacidade redirecionada para o caixa. A capacidade só vira dinheiro quando muda a receita ou o custo, por vendas adicionais, contratações evitadas, horas extras reduzidas ou menos terceirizados. Até lá, é uma possibilidade.

Um exemplo numérico, e quão frágil ele é

Tome uma empresa que implanta um assistente para 1.000 funcionários que relatam economizar três horas por semana, trabalhando 46 semanas por ano. O tempo bruto poupado relatado é de 138.000 horas. Suponha que o custo total de uma hora deles seja de US$ 40.

Agora aplique as conversões. Metade do tempo relatado é real, ou seja, 69.000 horas. Suponha que 40% disso seja redirecionado para trabalho valioso, o que deixa 27.600 horas. A US$ 40 cada, o benefício é de cerca de US$ 1,1 milhão por ano. Os custos: licenças a US$ 30 por usuário por mês somam US$ 360.000, e integração, treinamento, avaliação, trabalho de revisão e suporte acrescentam, digamos, US$ 300.000, num total de US$ 660.000. O saldo é de cerca de +US$ 444.000, um retorno de 67% sobre o custo.

O resultado é sensível. Se apenas 20% do tempo real for redirecionado, o benefício cai para US$ 552.000 e o saldo é de −US$ 108.000. A realização de equilíbrio, com metade do tempo relatado sendo real, é de cerca de 24%. Uma empresa que relatou o primeiro valor tinha um bom caso de negócio. Uma empresa cujos funcionários redirecionam seu tempo com menos eficácia está pagando mais do que ganha. As duas mostrariam os mesmos painéis de uso e as mesmas pesquisas entusiasmadas. Pular o desconto e tratar todas as 138.000 horas relatadas como valor dá um benefício de US$ 5,5 milhões e um retorno de mais de oito vezes o custo, que é o tipo de número que circula em apresentações.

Por que as horas não aparecem

O economista Robert Solow escreveu em 1987 que a era do computador podia ser vista em todo lugar, menos nas estatísticas de produtividade. A observação foi revivida para a IA porque continua verdadeira de um modo particular. Os estudos encontram ganhos reais no nível das tarefas, e os números agregados se movem devagar.

Erik Brynjolfsson, Daniel Rock e Chad Syverson ofereceram um mecanismo em seu trabalho sobre a curva J da produtividade. Uma tecnologia de uso geral exige investimentos complementares em processos, habilidades e organização, que são intangíveis e não aparecem nas estatísticas usuais. Enquanto esses investimentos são feitos, a produtividade medida pode estagnar ou cair, e os ganhos chegam depois, quando os complementos estão no lugar. Para uma empresa, o significado prático é que uma medição do primeiro ano subestima o efeito de longo prazo quando a organização ainda não mudou, e o superestima quando os números vêm dos entusiastas iniciais.

As estimativas macroeconômicas são modestas. Um estudo do Federal Reserve Bank de St. Louis pesquisou americanos sobre o uso de IA generativa e constatou que os respondentes relatavam economias de tempo equivalentes a 1,4% do total de horas trabalhadas, com uma faixa de 1% a 5% das horas de trabalho atualmente assistidas pela tecnologia. O modelo macroeconômico simples de Daron Acemoglu, construído a partir da fração de tarefas afetadas e das economias de custo nessas tarefas, situou o ganho de produtividade total dos fatores em no máximo 0,66% em dez anos, e argumentou que o número poderia ser menor porque a evidência inicial vem de tarefas fáceis de aprender. São números da economia como um todo, e uma empresa individual pode se sair muito melhor ou muito pior. Eles sugerem, sim, que afirmações de ganhos agregados grandes e imediatos merecem ceticismo.

Onde a evidência é forte

Alguns ambientes permitem que a conversão aconteça. O estudo de suporte ao cliente de Brynjolfsson, Li e Raymond mediu chamados resolvidos por hora para 5.179 atendentes, com acesso escalonado que tornou possível a comparação, e encontrou um aumento de 14% em média e de 34% para novatos. Nesse ambiente, a unidade de produção (chamados resolvidos) era contável, o trabalho era um fluxo de itens semelhantes, de modo que o tempo liberado podia ser preenchido com mais itens, e a empresa podia converter capacidade em dinheiro por menos contratações, resposta mais rápida ou melhor atendimento. As propriedades que fortaleceram a evidência foram uma unidade padrão de trabalho, uma fila de itens à espera e um grupo de comparação.

Onde elas valem, dá para relatar o custo por unidade de trabalho. Onde não valem, como no trabalho de conhecimento variado e sem fila, o relato honesto é uma faixa com premissas declaradas, rotulada como potencial.

O mesmo estudo traz uma segunda lição sobre onde olhar. O ganho foi de 34% para novatos e mínimo para atendentes experientes, e o ensaio com desenvolvedores encontrou uma lentidão entre pessoas com profunda experiência nas próprias bases de código. Os benefícios tendem a se concentrar entre trabalhadores menos experientes, para quem a ferramenta fornece conhecimento que lhes falta, e a encolher ou se inverter para pessoas que já fazem a tarefa com fluência e precisam conferir ou brigar com as sugestões da ferramenta. Uma implantação que trata todos os funcionários do mesmo modo fará a média desses efeitos e esconderá os dois. Segmente a medição por experiência, e o plano de implantação por quem tem probabilidade de ganhar, contando a velocidade de integração e a retenção como benefícios quando se aplicam, já que o estudo de suporte também encontrou maior retenção de funcionários.

Um desenho de medição

Um plano crível decide várias coisas antes de a ferramenta ser ligada.

Escolha a unidade de trabalho a contar: um chamado resolvido, um sinistro processado, uma nota fiscal conciliada, um pull request integrado. Meça a linha de base por algumas semanas antes da implantação. Introduza a ferramenta em etapas entre as equipes, de modo que algumas sejam grupos de comparação, ou randomize o acesso dentro de uma equipe. Acompanhe a qualidade junto com a velocidade, com taxas de erro, retrabalho, satisfação do cliente ou defeitos, porque mais rápido e pior é um custo. Conte o tempo de revisão: quando uma pessoa precisa conferir e corrigir a saída da ferramenta, esse tempo pertence ao lado dos custos. Calcule o custo por unidade concluída, incluindo licença, inferência, suporte e revisão, e compare com a linha de base.

Para o trabalho de conhecimento variado, sem fila de itens idênticos, o desenho da METR oferece um modelo que uma empresa pode copiar. Randomize no nível da tarefa dentro da mesma pessoa: para cada tarefa que chega, um cara ou coroa decide se a ferramenta pode ser usada. Ao longo de algumas centenas de tarefas, cada pessoa funciona como seu próprio controle, e a comparação não é contaminada por diferenças de habilidade entre as pessoas. Acrescente uma avaliação cega de qualidade, em que um gestor que não sabe qual condição produziu a saída a pontua. Um mês disso custa pouco perto de uma conta de licenças de várias centenas de milhares de dólares por ano, e substitui uma pesquisa de crenças por uma medição.

A qualidade entra no livro-razão como dinheiro. Suponha que uma ferramenta reduza o tempo de uma transação de retaguarda de seis minutos para 4,8, e que a empresa processe 100.000 por ano. A economia é de 120.000 minutos, ou 2.000 horas, que valem US$ 80.000 a US$ 40 por hora. Se a ferramenta também elevar a taxa de erro em um ponto percentual, são 1.000 erros a mais por ano, e a US$ 200 para achar e corrigir cada um, o custo é de US$ 200.000. O saldo é um prejuízo de US$ 120.000, escondido atrás de uma economia de tempo que todo usuário relataria com satisfação. Métricas de proteção para erros, retrabalho e reclamações pertencem ao mesmo painel que a velocidade.

Depois decida de antemão o que acontece com a capacidade. Se o plano é tratar mais volume com a mesma equipe, diga que volume está esperando. Se o plano é evitar contratações, nomeie os cargos. Se nenhum dos dois é verdade, o benefício previsto deve ser marcado como possibilidade.

O lado dos custos merece o mesmo escrutínio

Os custos são mais fáceis de ver e fáceis de subestimar. As taxas de licença são visíveis. Os encargos de inferência são variáveis e dependem do projeto: o relato da Anthropic sobre seu sistema de pesquisa informa que um agente usa cerca de quatro vezes os tokens de um chat e um sistema multiagente cerca de quinze vezes, de modo que uma fatura baseada em uso pode crescer mais depressa que o número de licenças. Os custos maiores costumam ser internos: tempo de engenharia para integrar, o trabalho de avaliação e monitoramento que mantém a qualidade, revisão jurídica e de segurança, treinamento e gestão da mudança, e o tempo dos gestores gasto redesenhando fluxos de trabalho. Um caso de negócio que lista apenas licenças subestima o investimento por um fator grande.

O que dizer ao conselho

Conselhos e comitês financeiros pedem um único número de retorno, e um número único convida à falsa precisão. Uma resposta melhor tem três partes. Declare o valor realizado até agora, com sua origem nas contas. Declare o valor potencial que está sendo convertido, com o plano e a data em que deve aparecer. Declare a faixa de resultados sob premissas pessimistas, esperadas e otimistas sobre as conversões, para que o comitê veja a mesma tabela de sensibilidades que a equipe usou. Um comitê que viu a realização de equilíbrio, como o cerca de um quarto do exemplo acima, pode julgar se o programa tem chance de superá-la, e pode fazer a pergunta certa sobre cada iniciativa: qual das quatro conversões ainda não foi comprovada?

Dois hábitos protegem contra o autoengano. Faça a medição ser de responsabilidade de alguém de fora da equipe que construiu a implantação, porque os construtores são as pessoas mais inclinadas a ler um número ambíguo de forma favorável. E publique as estimativas que falharam: um programa que relata só suas vitórias não ensina nada à organização sobre quais conversões falham, e os mesmos erros voltarão com a próxima ferramenta.

Relate o valor realizado e rotule o potencial

Uma convenção prática separa dois livros. O valor realizado cobre mudanças que aparecem num orçamento ou numa linha de receita e podem ser rastreadas até a implantação. O valor potencial cobre a capacidade liberada que ainda não foi transformada em nenhuma das duas. Apresente ambos, com as premissas de conversão e a sensibilidade, para que o leitor veja quanto do caso depende do que ainda não aconteceu. Um programa que consegue mostrar valor realizado tem um caso defensável. Um programa que só consegue mostrar potencial tem uma hipótese, e o remédio é um plano para convertê-la.

Fontes

1. Becker, J., Rush, N., Barnes, E., Rein, D. (2025). Measuring the Impact of Early-2025 AI on Experienced Open-Source Developer Productivity. METR. arXiv:2507.09089.
2. Solow, R. M. (12 de julho de 1987). We'd better watch out. New York Times Book Review.
3. Brynjolfsson, E., Rock, D., Syverson, C. (2021). The Productivity J-Curve: How Intangibles Complement General Purpose Technologies. American Economic Journal: Macroeconomics 13(1).
4. Bick, A., Blandin, A., Deming, D. J. (2024, revisado em 2025). The Rapid Adoption of Generative AI. Federal Reserve Bank of St. Louis Working Paper 2024-027; NBER Working Paper 32966.
5. Acemoglu, D. (2024). The Simple Macroeconomics of AI. NBER Working Paper 32487.
6. Brynjolfsson, E., Li, D., Raymond, L. R. (2023, revisado). Generative AI at Work. NBER Working Paper 31161.
7. Anthropic (junho de 2025). How we built our multi-agent research system. anthropic.com/engineering/multi-agent-research-system.
8. Caso de negócio ilustrativo: 1.000 usuários, três horas relatadas por semana poupadas durante 46 semanas, custo horário total de US$ 40, licenças de US$ 30 por usuário por mês e US$ 300.000 de outros custos, premissas declaradas no texto.