Sobre demanda induzida, demissões e o custo real da IA que não sabemos usar
Se você já passou algum tempo no Twitter de transporte público, já viu o meme.
"Só mais uma faixa, mano."
Um engenheiro de rodovias desenhado de giz de cera fica ao lado de uma rodovia, apontando para as novas faixas que quer adicionar porque o trânsito está ruim. Seu rosto é sincero. Desta vez ele vai resolver. Com mais uma faixa o congestionamento vai sumir.
Raramente some por muito tempo.
Novas faixas criam novas viagens. Nova capacidade cria nova demanda. Economistas chamam isso de demanda induzida. A Katy Freeway, no Texas, foi ampliada e virou uma das rodovias mais largas do mundo. A 405, em Los Angeles, recebeu uma ampliação de bilhões de dólares. O padrão é familiar em décadas de expansão viária: a capacidade aumenta, o uso cresce até ocupá-la, e o congestionamento volta.
O engenheiro do meme continua pedindo só mais uma faixa mesmo assim.
Agora estamos no mesmo momento com datacenters de IA.
O pitch pela infraestrutura “certa”
A cada trimestre chega mais um anúncio de hyperscaler. Mais uma obra de dez dígitos. Mais um campus. Mais uma subestação. Mais um acordo de energia. Mais uma briga pela água. Mais um condado rural informado de que esse é o preço do progresso.
A justificativa é sempre a mesma.
A demanda por IA está explodindo. Precisamos de mais computação. Se não construirmos, os Estados Unidos ficam atrás da China. As empresas não terão a capacidade de que precisam. Desenvolvedores ficarão limitados. A inovação vai desacelerar.
Só mais um datacenter.
Só mais um campus de um gigawatt.
Só mais um terreno de 2.700 acres.
Só mais uma atualização da rede elétrica.
Aí teremos o suficiente.
É o mesmo engenheiro com uma planta diferente.
Este é um investimento de infraestrutura geracional, e uma parte substancial dele já está assinada.
Isso não é um argumento de que a IA não precisa de infraestrutura. Alguma nova capacidade é necessária.
A questão é se devemos continuar comprometendo nova capacidade nesse ritmo antes de forçar os compradores a provar que estão usando a capacidade existente com inteligência.
Hoje, parte dessa demanda explosiva é produtividade nova genuína. Parte é consumo evitável criado por padrões ruins, tentativas automáticas desenfreadas, credenciais obsoletas, modelos superdimensionados e workloads que ninguém jamais foi obrigado a justificar em termos de custo.
A demanda induzida
Computação não tem uma curva de demanda fixa. Ela se dobra para acompanhar a oferta disponível.
Dê a desenvolvedores acesso barato a modelos de fronteira e muitos workloads passam a usar modelos de fronteira por padrão. Dê a agentes orçamentos grandes e muitos agentes vão gastá-los. Dê a times chaves de API irrestritas e a conta cresce até alguém notar.
Quando isso acontece, o workload já está em produção.
Um fundador roda um modelo caro em cada etapa de um pipeline de suporte ao cliente porque esse era o padrão quando o engenheiro entregou rápido. O pipeline funciona. A conta se torna dolorosa. Depois alguém descobre que boa parte do workload poderia ter rodado em um modelo mais barato com pouca ou nenhuma perda mensurável de qualidade.
Isso não é um caso bizarro de exceção. É assim que o desenvolvimento de IA, em ritmo acelerado, costuma funcionar. Os padrões são ruins. O desperdício é invisível. A fatura chega tarde.
A mesma coisa acontece em todo lugar.
Um sistema de busca por recuperação grava duplicatas. Um agente de suporte entra em loop de tentativas. Um agente de código queima o modelo mais caro em edições triviais. A chave de um contratado sobrevive ao fim do contrato. A chave de um ex-funcionário sobrevive ao offboarding. Uma chave de produção vai parar no laptop de alguém.
Eles não são necessariamente mal-intencionados. O sistema simplesmente não é gerenciado.
Quando a indústria de IA diz que a demanda está explodindo, parte dessa demanda é produtividade real. Parte são padrões ruins, credenciais vencidas, orçamentos ausentes e trabalho de máquina sem qualquer governança.
Adicionar computação não corrige isso. Alimenta isso. Até empresas como a Amazon estão relatando que esse é o caso.
Isso é demanda induzida. Essa é a rodovia.
A mentalidade “tira gente, põe IA”
Com quadro de pessoal em queda e orçamentos de IA em alta, as duas coisas costumam estar explicitamente conectadas. A Microsoft disse claramente que seus cortes não são simplesmente substituição por IA. Sam Altman admitiu que parte da atribuição é o que ele chama de AI washing: citar IA para cortes que a empresa faria de qualquer forma. Pesquisas com CEOs mostram que eles estão tendo que planejar mudanças com base em IA.
O que os dados mostram claramente é uma realocação de prioridades. A Challenger descreve empresas de tecnologia se reestruturando em torno de IA, automatizando alguns cargos e realocando orçamentos para novas capacidades. O trabalhador específico e a GPU específica não precisam ser pareados um a um para que a mudança de capital seja real.
O que torna a pergunta incômoda ainda mais aguda, não mais suave.
Se a troca não é pessoas por produtividade de IA, e não é inteiramente pessoas por nada, então o que exatamente está do lado da máquina no balanço? Ninguém consegue oferecer uma resposta firme, porque o gasto com IA está se tornando folha de pagamento sem ser gerido com nada parecido com a disciplina da folha de pagamento.
Trabalhadores humanos têm gestores, orçamentos, permissões, cartões corporativos, crachás de acesso, offboarding, avaliações de desempenho e trilhas de auditoria.
Trabalhadores de máquina muitas vezes têm uma chave de API.
Estamos movendo nossos orçamentos da folha de pagamento humana para a folha de pagamento de máquinas, e então gerenciando a folha de pagamento de máquinas como um monte de senhas. Sem dono. Sem gestor. Sem validade. Sem política de gasto. Sem recibo. Sem custo por resultado útil. Sem prova de que o trabalho da máquina valeu o custo da máquina.
A chave de API é o novo cartão corporativo
Uma empresa nunca diria: "um ex-funcionário ficou com o cartão corporativo, ninguém sabe o que ele está cobrando, e só fomos descobrir meses depois." Isso seria considerado uma falha operacional óbvia. Mas a versão com API acontece o tempo todo.
Uma chave de provedor de modelo pode gerar gasto. Uma chave de nuvem pode criar infraestrutura. Uma chave da Stripe pode mover dinheiro. Uma chave do GitHub pode enviar código. Uma chave de provedor de dados pode acessar bases pagas. Uma chave de plataforma de anúncios pode torrar o orçamento de campanha. Uma chave de exchange pode negociar ativos.
Elas não são apenas segredos. São autoridade econômica.
Chaves de API demais ainda são tratadas como senhas. Elas precisam ser tratadas como cartões corporativos para máquinas.
Contratados, fábricas de software, agências de marketing, auditores, equipes fracionadas, funcionários e agentes precisam de acesso a recursos que sobem e descem. Hoje, as empresas ou concedem acesso demais ou desaceleram tudo. O projeto acaba, o acesso permanece, e o gasto continua.
Isso não é apenas um problema de segurança. É um problema de contabilidade. Um problema de governança e um problema de infraestrutura.
Os locais sabem
A reação pública contra datacenters não é só NIMBYismo. As pessoas sentem a contradição. Uma pesquisa Gallup recente constatou que sete em cada dez americanos se oporiam à construção de datacenters para IA em suas cidades.
Datacenters consomem quantidades enormes de eletricidade. Dependendo do projeto de refrigeração e da localização, podem consumir também muita água e terra. Geram calor real, ruído, disputas por linhas de transmissão e pressão política local. Os benefícios muitas vezes parecem distantes, privados ou especulativos. Os custos são locais.
O fardo de infraestrutura é concentrado em condados rurais. O benefício econômico é difuso e frequentemente capturado em outro lugar. Os benefícios são prometidos para mais tarde. Os custos chegam agora.
Isso é politicamente instável. Em 2026 isso deixou de ser uma previsão.
A indústria não deveria se surpreender que datacenters tenham se tornado uma briga política nacional. Se a infraestrutura de IA pede às comunidades terra, energia, água e paciência, a indústria deveria ser capaz de provar que a computação está sendo bem utilizada.
Hoje, muitos compradores não conseguem.
A troca de pessoas por máquina não medida é errada
Junte as camadas.
Um CFO lê a tese de investimento em IA, aprova a expansão, corta quadro de pessoal para financiá-la e diz ao conselho que a matemática fecha. A computação é provisionada. Os workloads são lançados. Os padrões estão errados. As chaves não são gerenciadas. Os modelos caros são usados em excesso. Os agentes tentam de novo vezes demais. As credenciais antigas continuam funcionando. A conta cresce mais rápido que o projetado.
O conselho pergunta por quê. A resposta volta: a demanda por IA está explodindo. Precisamos de mais capacidade. Então o CFO assina o próximo contrato. O ciclo se repete.
Enquanto isso, o funcionário dispensado observa a empresa gastar agressivamente em sistemas de IA que podem ou não realmente produzir a produtividade prometida. Um comissário de condado atende ligações irritadas sobre energia, água, terra e ruído. Um operador de rede tenta fazer os números fecharem. Um morador local é informado de que isso é o futuro.
Muitas vezes, a troca não foi pessoas por produtividade. Foi pessoas por trabalho de máquina não medido. Pessoas por padrões ruins. Pessoas por desleixo. E quando o desleixo ficou caro, a resposta da indústria não foi disciplina. Foi mais um datacenter. Só mais um, mano.
A resposta real
A resposta real não é apenas construir mais datacenters.
A resposta real é usar com inteligência os datacenters que já temos.
Isso é algo desconfortável para a indústria dizer, porque os incentivos não estão perfeitamente alinhados. Provedores em geral são pagos quando o consumo sobe. Compradores ganham quando os resultados úteis sobem. Essas duas curvas não são iguais.
O interesse do comprador é específico.
O comprador quer o menor modelo que faça o trabalho. O menor número de chamadas que resolva o problema. A chave que expira quando o projeto termina. A credencial que só funciona do dispositivo certo. O agente que é cortado quando sai da política. A exceção aprovada só quando o caso de negócio é real.
Nada disso exige um novo datacenter. Exige provisionamento inteligente da computação que já temos.
A estrada para a solução é entediante
Dimensionar corretamente o workload para o modelo. Agrupar o que pode ser agrupado. Fazer cache do que pode ser armazenado em cache. Restringir o que deve ser restrito. Autorizar o que precisa exceder. Recusar o que está rodando no modelo errado. credencial, no dispositivo errado, pela pessoa errada, para o trabalho errado. Meça o custo por resultado útil. Faça o acesso expirar automaticamente. Elimine loops fora de controle. Direcione trabalhos de baixo risco para modelos de baixo custo. Escale apenas quando a qualidade exigir. Emita comprovantes.
O mercado começou a perceber. Neste verão, CFOs e conselhos de administração começaram a cortar gastos com IA que estouraram o orçamento. O roteamento de modelos passou de tema de artigo acadêmico para vocabulário de sala de reunião, à medida que as equipes buscavam formas de enviar trabalho rotineiro para modelos mais baratos sem sacrificar a qualidade. Os próprios provedores de modelos começaram a lançar limites administrativos de gastos porque os clientes exigiam uma forma de controlar as contas.
Bom. Essa onda é real e veio tarde. Os provedores agora oferecem tetos duros de gastos que de fato fazem as chamadas falharem quando o limite é atingido, limites por usuário e fluxos de aprovação.
Mas repare no limite da onda atual. Esses controles governam o consumo dentro de um provedor, de um projeto ou de um aplicativo. O roteamento escolhe um modelo mais barato. Um teto interrompe uma conta fora de controle. Nenhum dos dois responde à questão mais ampla da autoridade: qual máquina está agindo, a partir de qual runtime, em nome de quem, com qual finalidade, contra quais recursos externos, e que prova portátil existe depois. Controle de custos não é a mesma coisa que autoridade programável e verificável.
A IA precisa da disciplina completa, não só da metade de custos. Não porque a IA seja ruim. Porque a IA está se tornando trabalho. E trabalho precisa de gestão.
A camada que falta aos agentes de IA
Esta é a camada que achamos que falta à IA, e ela é deliberadamente mais estreita que toda a pilha de FinOps.
A autoridade econômica deve ser governada antes da execução: quem e o que pode gastar, a partir de qual dispositivo e runtime, para qual carga de trabalho e sob quais limites. Tudo com um comprovante ao final que uma pessoa de verdade consiga verificar.
Parte da expansão de datacenters é necessária. IA é real, e coisas reais precisam de infraestrutura. Mas a demanda sem gestão torna a expansão necessária maior, mais rápida e mais difícil de justificar do que precisa ser. O caminho certo não é um painel mais bonito depois que a conta chega. A solução é a camada de controle na credencial, antes que o gasto aconteça.
Dirigindo na direção certa
Só mais um datacenter, cara.
Prometemos que agora vai funcionar. A capacidade de computação está quase entrando no ar. A taxa de desperdício está quase caindo. As margens estão quase se materializando. As cargas de trabalho estão quase ficando eficientes. As comunidades locais estão quase aceitando. A rede elétrica está quase aguentando. O trilhão de dólares em contratos de locação assinados está quase parecendo conservador. O conselho está quase enxergando o ganho de produtividade.
Só mais um.
Talvez parte dessa capacidade seja necessária. Mas, antes de o setor pedir às comunidades mais terra, mais água, mais energia e mais paciência, os compradores deveriam conseguir responder a uma pergunta mais simples.
Estamos usando bem a computação que já temos? Não em um slide ou em um memorando de política interna.
Em comprovantes. Qual modelo foi usado. Que carga de trabalho precisava dele. Qual chave autorizou. Essa é a próxima disputa em infraestrutura de IA. Não computação versus não computação. Computação governada versus desperdício.
Construir com menos cegueira. Usar o que já temos.