Durante duas décadas, o software foi a linha mais bem-comportada do orçamento de uma casa. Uma licença tinha um preço, um número de utilizadores e uma data de renovação. A área financeira conseguia prever o custo com um ano de antecedência e acertar, porque o custo quase nada tinha a ver com a intensidade com que alguém usava o produto. O analista que vivia dentro da ferramenta e o partner que a abria duas vezes por trimestre custavam à casa exatamente o mesmo.
A despesa com IA não se comporta assim, e a diferença é estrutural, não um problema de arranque. Os modelos de fronteira são cobrados ao consumo. Cada pedido consome tokens, cada token é faturado, e a fatura no fim do mês é um registo preciso de como a casa realmente trabalhou. O custo deixou de acompanhar o número de pessoas. Acompanha o comportamento: o analista a meio de uma due diligence e o partner que lê o memorando final já não custam à casa o mesmo.
Isto seria gerível se o comportamento fosse disciplinado pelo preço no momento da utilização, mas não é. Para quem está a escrever, cada pedido parece gratuito, porque nada nesse momento indica o contrário. Por isso, a utilização corre para o que é mais fácil, e não para o que vale mais. Data rooms inteiras são coladas numa janela de contexto quando dois documentos teriam respondido à pergunta. O modelo mais capaz é aplicado a trabalho de formatação que um modelo muito mais pequeno resolve. Pedem-se dez versões quando apenas uma seria lida. Nenhuma destas decisões é descuidada por si só; somadas, são o orçamento.
Porque é que os orçamentos morrem na primavera
O resultado é o padrão em torno do qual construímos toda uma área de trabalho: um orçamento de compute planeado para o ano que, no fim do primeiro trimestre, já se foi em grande parte. Quando isso acontece, as casas tendem a recorrer a um de dois remédios, e ambos estão errados. Racionar o acesso ensina à equipa que as ferramentas são escassas, o que desfaz, sem ruído, a adoção que a casa levou meses a construir. Reforçar o orçamento não ensina nada à casa, porque a derrapagem do ano seguinte já está em marcha.
O verdadeiro problema não é a dimensão do orçamento nem o entusiasmo da equipa. É que ninguém consegue dizer o que a despesa comprou. Uma fatura em tokens responde com grande precisão à pergunta «quanto?», sem dizer nada sobre «para quê?». Nenhuma outra linha das contas da casa passaria nesse crivo.
A unidade errada
Os tokens são a unidade certa para faturar e a unidade errada para gerir. Um partner não tem intuição sobre quanto deveria custar, ou produzir, um milhão de tokens, e nenhum dashboard lha vai dar, porque a unidade não corresponde a nada sobre o qual a casa tome decisões. O que um partner consegue avaliar de imediato é trabalho: um memorando revisto, uma data room resumida, um board pack redigido, uma lista de comparáveis montada. São estas as unidades em que a casa já pensa, negoceia e dimensiona as suas equipas.
Um partner não consegue pôr preço a um token. Qualquer partner consegue pôr preço a um memorando.
O custeio por fluxo de trabalho é a tradução entre as duas. Em vez de uma única linha de IA indiferenciada, a despesa é atribuída a fluxos de trabalho com nome, e cada fluxo ganha um custo unitário: quanto custa a primeira triagem de due diligence por empresa-alvo analisada, quanto custa uma revisão adversarial por memorando de comité de investimento, quanto custa resumir cada data room. Lado a lado com as horas de analista que o trabalho substitui, ou com a rapidez que acrescenta, cada linha sustenta uma decisão concreta: manter, melhorar ou parar.
A atribuição também muda o que significa caro. Um fluxo com um custo unitário elevado que poupa a uma equipa dois dias por empresa-alvo é barato. Um fluxo com um custo unitário irrisório que produz resultados que ninguém lê é puro desperdício, e há mais do segundo tipo do que a maioria das casas imagina, precisamente porque cada caso é demasiado pequeno para se notar. Sem atribuição, a despesa inútil esconde-se no agregado, e a despesa valiosa apanha o mesmo aperto quando os cortes acabam por chegar.
Medir, atribuir, podar
A disciplina em si não é complicada, mas a ordem importa. Primeiro vem a medição: a utilização tornada legível por equipa, por fluxo de trabalho e por modelo, em vez de chegar como um único número numa fatura mensal. Depois vem a atribuição, e é o passo que as casas saltam: cada token pertence a um fluxo de trabalho com nome, pelo que a pergunta na revisão do orçamento nunca é porque é que a IA é tão cara, mas se o fluxo de revisão de memorandos vale o que custa. A poda vem no fim, e aplica-se a fluxos de trabalho, não a pessoas. Algum trabalho passa para modelos mais pequenos que produzem o mesmo resultado por uma fração da despesa. Alguns prompts encurtam e algum contexto fica mais enxuto. Alguns fluxos de trabalho param, simplesmente, porque uma linha que não rende nada não deve sobreviver à leitura do P&L que finalmente a tornou visível.
A poda corta nos dois sentidos, e esta é a parte que um leitor com espírito de austeridade vai deixar escapar. Um fluxo que claramente justifica o seu custo deve ser alimentado, não racionado. Na nossa opinião, o desfecho honesto do exercício raramente é um orçamento mais pequeno; é o mesmo orçamento a fazer menos coisas, e bem feitas, ao ritmo certo para durar o ano para que foi planeado. A medida do sucesso não é uma fatura mais baixa. É um partner que consegue olhar para a fatura e explicá-la.
Há uma razão para esta prática andar naturalmente de mãos dadas com o nosso trabalho sobre o critério. Disciplina de custos e disciplina analítica são o mesmo hábito aplicado a recursos diferentes: saber para que serve um trabalho antes de o encomendar, e conseguir defendê-lo depois. Um P&L de tokens que os partners conseguem ler não é um artefacto técnico; é um documento de governação, e uma casa onde o critério é o produto deve exigir ter um. Se a despesa com IA da vossa casa se tornou um número que ninguém consegue explicar, teremos todo o gosto em conversar sobre isso.