IA agêntica: energia, carbono e água por trás do prompt

A pegada da IA agêntica é a energia, o carbono e a água que um agente de IA consome para concluir uma tarefa. Ela cresce depressa porque o agente planeja, chama ferramentas, revisa o próprio trabalho e tenta de novo, e cada etapa reenvia ao modelo um contexto que só aumenta. Um estudo publicado em 2026 mediu que tarefas de programação feitas por agentes consomem cerca de mil vezes mais tokens que uma consulta de código ao mesmo modelo.

Navveen Balani, à frente da Green Software Foundation (GSF), a entidade que mantém o padrão de medição de carbono de software adotado pela ISO, escreveu em junho de 2026 que os agentes são hoje o maior problema de eficiência da IA. Na avaliação de Balani, a organização que usa agentes precisa medir cada tarefa nas três grandezas, separadas, e projetar o agente para gastar menos tokens desde o início.

Quanto consome uma tarefa de um agente de IA?

Muito mais que uma consulta, e com grande variação de uma execução para outra. Longju Bai e coautores, entre eles Erik Brynjolfsson e Alex Pentland, analisaram em abril de 2026 tarefas de programação executadas por agentes em vários modelos de fronteira. As tarefas agênticas consumiram cerca de mil vezes mais tokens que o raciocínio sobre código e a conversa sobre código, e os tokens de entrada, mais que os de saída, responderam pela maior parte do custo.

O peso da entrada tem uma causa mecânica. A cada passo, o agente reenvia ao modelo o histórico da tarefa, as instruções e o resultado de cada ferramenta já chamada, e esse contexto cresce a cada volta. Outro estudo de 2026, o AgencyBench, de Keyu Li e coautores, montou 138 tarefas em 32 cenários reais de trabalho e mediu, por cenário, uma média de 90 chamadas de ferramenta, um milhão de tokens e horas de execução.

A variação pesa tanto quanto o volume. No estudo de Bai, execuções da mesma tarefa chegaram a diferir 30 vezes no total de tokens, e os próprios modelos subestimaram o consumo quando foram solicitados a prevê-lo. Gastar mais tokens também não garantiu mais acerto: a precisão costumou atingir o máximo em um custo intermediário e se estabilizar dali em diante. Um orçamento feito pela média das execuções erra para menos justamente nas tarefas mais caras.

O que fazer: registre os tokens de entrada e de saída de cada tarefa do agente, execução por execução, e acompanhe a dispersão entre execuções da mesma tarefa ao lado da média.

Energia, carbono e água: três contas separadas

O token é a unidade da fatura. O quilowatt-hora, o grama de CO2 equivalente e o litro de água são as unidades do impacto, e cada uma depende de uma decisão diferente. Balani as trata como três dimensões ligadas e distintas, e alerta que usar uma delas como substituta das outras deixa pontos cegos no inventário.

A energia é a dimensão que o arquiteto controla diretamente: menos tokens significam menos tempo de processador gráfico e menos quilowatts-hora. O carbono depende de onde e de quando o agente roda. Um quilowatt-hora de uma rede com muita energia solar ao meio-dia emite uma fração do que emite o mesmo quilowatt-hora de uma rede a carvão à noite, e a GSF aponta que o carbono incorporado ao hardware, o das emissões de fabricar os equipamentos, cresce com a expansão dos data centers de IA. A água é o impacto local. Segundo a GSF, o resfriamento evaporativo de um data center pode consumir milhões de litros de água doce por dia, e um litro retirado de uma bacia sob estresse hídrico pesa mais que um litro retirado de outra.

As três contas podem andar em sentidos opostos. Levar a carga para uma região com energia renovável abundante reduz as emissões e pode agravar a falta de água, se a região estiver em seca. Trocar o hardware por um mais eficiente reduz a energia por token e acrescenta as emissões de fabricação do equipamento novo.

O que fazer: no inventário de emissões, reporte a IA nas três grandezas, separadas por região de nuvem, e peça ao provedor os dados de energia, carbono e água da região em que cada agente roda.

Medir por tarefa: a SCI e a SCI for AI

O método já existe e é norma internacional. A Software Carbon Intensity (SCI), criada pela GSF, foi publicada em 2024 como a ISO/IEC 21031:2024. Ela calcula a taxa de emissão de um software pela fórmula SCI = ((E × I) + M) por R: a energia consumida (E), em quilowatts-hora, multiplicada pela intensidade de carbono da eletricidade da região (I), somada às emissões incorporadas do hardware (M) e dividida por uma unidade funcional (R), como uma chamada de API, um usuário ou um minuto de uso.

O resultado é uma taxa, e por isso serve para comparar duas versões do mesmo sistema e acompanhar uma meta, mesmo com o volume de uso mudando. Para um agente, a unidade funcional mais útil costuma ser a tarefa concluída: o documento analisado, o chamado encerrado, o pedido processado.

A SCI for AI, ratificada pela comunidade da GSF no fim de 2025, estende o método a todo o ciclo de vida de um sistema de IA, da concepção ao descarte, incluindo a preparação dos dados, o treinamento e a operação. A GSF trabalha ainda em uma norma própria de eficiência energética de software, a Software Energy Efficiency (SEE), com o uso de água previsto como o passo seguinte, e em um padrão para que os provedores de nuvem publiquem dados de energia e carbono por hora e por região.

O que fazer: escolha a unidade funcional de cada agente e calcule a SCI por essa unidade antes de comparar modelos, fornecedores ou regiões de nuvem.

Taiwan e a SCI nas empresas

O caso de Taiwan mostra a SCI levada do governo às empresas. O Taiwan Institute of Economic Research (TIER), centro de pesquisa econômica independente fundado em 1976, executa desde 2024 as iniciativas de software verde do Ministério de Assuntos Digitais de Taiwan. Em entrevista à GSF publicada em julho de 2026, Mei-Lian Wei, do TIER, contou que o instituto desenvolveu ferramentas de cálculo do carbono de softwares e de sites, e que conduz em 2026 projetos-piloto para ajudar empresas taiwanesas a aplicar a SCI.

Wei descreveu o software verde como o meio de transformar emissões digitais, hoje abstratas e difíceis de quantificar, em métricas sobre as quais a empresa consegue agir. O programa taiwanês adotou o padrão existente em vez de criar uma métrica nacional, e com isso as empresas medem pelo mesmo método que a norma ISO descreve e conseguem comparar os resultados entre si.

Para uma empresa brasileira, o caminho é o mesmo e está aberto: a norma está publicada, e aplicá-la exige duas decisões, a fronteira do software (o que entra na conta) e a unidade funcional.

O que fazer: comece por um piloto em um serviço digital de tráfego conhecido, com a fronteira escrita (servidores, rede, armazenamento e o modelo chamado pelo agente) e a SCI recalculada a cada versão do serviço.

O token que não chega a ser gerado

O token de menor impacto é o que o sistema nunca gera. Balani lista o que já está disponível para isso: o roteamento das etapas simples para modelos menores, o cache de respostas e de contexto, os modelos especializados, o limite de novas tentativas e os pontos de revisão humana. Nada disso vem ligado por padrão nas ferramentas de construção de agentes, e cabe à equipe ligar.

A decisão começa antes do projeto. Nem todo problema precisa de um agente, nem todo agente precisa de um modelo de raciocínio, e nem toda etapa precisa do contexto inteiro. A pergunta que decide se um projeto de IA tem retorno, a de qual linha do resultado ele move (ROI da IA), também decide se o problema justifica o consumo de um agente. Como a precisão se estabiliza a partir de um custo intermediário, cortar tokens costuma reduzir a conta de energia sem reduzir o acerto, e a conta da nuvem cai junto.

O que fazer: defina para cada agente um orçamento de tokens e de novas tentativas por tarefa, um modelo menor como padrão e o modelo de raciocínio só nas etapas que o exigem, e reveja o orçamento quando a precisão parar de subir.

Conclusão

A pegada de um agente de IA se mede pela tarefa, em energia, carbono e água, e cada uma dessas contas responde a uma decisão diferente: quantos tokens o agente gasta, onde e quando ele roda, e com que resfriamento. A SCI, norma ISO desde 2024, dá o método para a energia e o carbono, e a SCI for AI o estende ao ciclo de vida da IA. O passo seguinte é escolher a unidade funcional de cada agente, registrar o consumo por execução e fixar um orçamento de tokens antes de pôr o próximo agente em produção.

O Sustenext Green IT® mede a pegada da TI pelo mesmo caminho do restante do inventário, com a origem de cada número rastreável. No módulo de software, a TI Verde calcula a intensidade de carbono de cada serviço digital por transação, pelo método SCI da Green Software Foundation, com um orçamento de carbono por serviço; no de nuvem, mostra a pegada de cada conta com a intensidade de carbono da rede de cada região e simula a mudança de cargas para janelas e regiões de menor intensidade. Para medir a pegada dos serviços digitais e dos agentes da sua organização, fale com a Takter.

Fontes

• Longju Bai e coautores, How Do AI Agents Spend Your Money? Analyzing and Predicting Token Consumption in Agentic Coding Tasks, arXiv, abril de 2026.
• Keyu Li e coautores, AgencyBench: Benchmarking the Frontiers of Autonomous Agents in 1M-Token Real-World Contexts, arXiv, janeiro de 2026.
• Navveen Balani, Green Software Foundation, Tokens and Greens: Measuring the Impacts of Agentic AI, junho de 2026.
• Green Software Foundation, Turning Digital Emissions into Actionable Metrics: Meet Mei-Lian Wei of TIER, julho de 2026.
• ISO/IEC, ISO/IEC 21031:2024, Software Carbon Intensity (SCI) specification, março de 2024.
• Green Software Foundation, SCI for AI, página consultada em outubro de 2026.