East · Technology Sourcing & Optimization

Should my company measure the environmental impact of the AI tools we deploy?

Yes, your company should measure the environmental impact of the AI tools it deploys, because the public per-query figures vary by a factor of thirty and none of them describe your deployment. The measurable lever is not which model your staff choose but how your organization routes requests by default.

Yes, and the reason has almost nothing to do with environmental reporting. Measure it because an unowned question produces an unmanaged cost, and AI consumption is currently the least owned line in most technology estates.

The figures circulating publicly are not a foundation to build on. Google's own disclosure puts the median Gemini text prompt at 0.24 watt-hours, 0.03 grams of CO2 equivalent, and 0.26 milliliters of water. A study published in Joule in April 2026 puts optimized frontier-scale inference at a median of 0.31 watt-hours per query. Brookings, writing in June 2026, still cites roughly 2.9 watt-hours for an advanced generative query against 0.3 watt-hours for a conventional web search. Those are all credible sources describing ostensibly the same act.

Across the AI deployments we have reviewed, consumption has never once had a named owner, not because anyone declined the responsibility, but because it was never assigned to begin with.

Which AI model is most energy efficient?

Nobody can tell you, and the vendors cannot either.

The obstacle is methodological rather than evasive. Google reports that a chip-only methodology would put the same Gemini prompt at 0.10 watt-hours, which the company describes as an optimistic scenario that substantially understates the real operational footprint. Roughly half the energy in a served prompt sits outside the accelerator entirely, in host processors, idle capacity held for latency, and cooling overhead. Two vendors measuring honestly with different boundaries produce figures that differ threefold before either one has exaggerated anything.

Which AI assistant uses the least energy: ChatGPT, Claude, Gemini, Copilot, or another model?

There is no defensible ranking, and any published one is measuring boundaries rather than models. Google disclosed per-prompt figures first and encouraged buyers to seek granular data from their providers rather than relying on public estimates. That invitation is the useful part. The ranking is not.

How much energy does a single AI or ChatGPT query actually use?

Between roughly a tenth of a watt-hour and three watt-hours, depending on who is counting and what they counted.

Published estimates of energy per AI query, and what each one measures.
Source Figure per query What it includes
Google, chip-only method 0.10 Wh Active accelerator consumption only
Google, comprehensive method 0.24 Wh Host processors, idle capacity, full data center overhead
Joule, optimized production 0.31 Wh median Large-scale serving with batching and high concurrency
Brookings, widely cited estimate 2.9 Wh Non-production assumptions
Joule, long reasoning query 3.91 Wh median Extended token generation, reduced concurrency

The Joule authors state plainly that high-profile public estimates based on non-production assumptions overstate energy use by four to twenty times. The cause is prosaic. Estimates built by running a model in isolation miss batching and concurrency, which are exactly the mechanisms that make production serving efficient. A well-intentioned measurement taken in the wrong conditions produces a number that is wrong by an order of magnitude and then repeated for two years.

This is the pattern worth naming. The problem is not dishonesty. It is an absent measurement standard, and absent standards do not announce themselves. They simply produce confident numbers that disagree.

Is AI's environmental impact mostly from training models or from people using them?

From people using them, and by a wide margin. Analyses cited by Brookings put inference at eighty to ninety percent of the computing power used for AI, and the International Energy Agency's Energy and AI work projects inference at roughly two-thirds of total AI compute globally by 2026, up from one-third in 2023.

That single fact relocates the entire question. Training is a capital event that happens once, in someone else's facility, on a decision you did not make. Inference is an operating cost that happens every time one of your staff presses return, in volumes your organization controls. The impact you can govern is the one you generate.

The instinct to measure energy where it is actually consumed is not new, and it is considerably better developed outside software than within it. Vince Bradley, Founder and CEO of Abundant IoT, joined MTMG's IT Roundtable to discuss how sensing changed what organizations can see about their own energy use, and how sustainability moved from a reporting exercise into an operational one. The conversation predates the current argument about AI entirely, which is rather the point. The discipline of metering consumption at the place it occurs was worked out in buildings, fleets and plant long before anyone thought to apply it to a software estate. Thirty minutes, and worth it if the question of where your energy goes is a live one.

Should I use a smaller AI model instead of a frontier model to reduce environmental impact?

Probably not, and the individual choice matters far less than the routing policy above it.

Here is the figure that should change how this is discussed. The Joule study finds that serving a billion queries a day requires 0.7 gigawatt-hours, but if ten percent of those queries are long ones, demand rises to 1.7 gigawatt-hours, because long reasoning and agentic queries increase consumption by more than an order of magnitude through greater token generation and reduced serving concurrency.

Ten percent of requests more than doubles total consumption. Which means the lever is not model size. It is whether extended reasoning runs by default on requests that never needed it. One person choosing a lighter model is noise.

There is now a name for this discipline, and it did not come from sustainability. Tokenomics, a term borrowed back from cryptocurrency where it refers instead to the supply, distribution and incentive design of blockchain tokens, describes the unit economics of inference: what a token costs, which workloads consume them, and who is accountable for the total. The FinOps Foundation has stood up a body dedicated to the question of how organizations consume, allocate, optimize and measure AI costs. The relevance here is that energy and cost are not parallel concerns. They are the same variable read on two instruments, because the token is the unit of both.

The parallel runs deeper than the metaphor. Reasoning tokens are billed even though they never appear in the response, so a fifty-token reply can conceal several hundred tokens of internal deliberation, all of them charged. That is precisely the mechanism the energy figures describe, arriving on an invoice instead of a grid. Any organization already tracking token spend for financial reasons holds most of the instrument it needs for the environmental question and has usually never pointed it that way.

The correlation is not perfect, and claiming otherwise would be its own form of greenwashing. A cheaper model served on a carbon-intensive grid can cost less and emit more. Cost is a proxy, not a substitute. But it is a proxy that finance is already measuring, which makes it the most available starting point most organizations have.

Is self-hosting a smaller open-source model more sustainable than using a large cloud AI service?

Usually not, and the reason is the same mechanism that makes public estimates unreliable.

Efficiency at scale comes from batching and high concurrency, meaning hardware saturated so that fixed overheads are shared across many simultaneous requests. A self-hosted deployment serving one organization has, by definition, the conditions the Joule authors identify as inflating energy per query: low concurrency, unsaturated nodes, idle capacity held for responsiveness. Self-hosting also transfers embodied hardware emissions onto your own balance sheet, a category the Green Software Foundation notes the EU AI Act does not address at all.

There are sound reasons to self-host. Data residency, latency, and control over model behavior are all defensible. Environmental performance is not usually among them, and a sustainability argument for self-hosting deserves scrutiny rather than agreement.

Which AI companies publish real carbon or water data, rather than vague pledges?

Very few, and regulation will not resolve this for you before 2028.

The EU AI Act requires general-purpose model providers to document known or estimated energy consumption, but the design of that obligation rewards close reading. Estimates are permitted in place of measurement, disclosure runs to the AI Office rather than to the public, and the inference phase is frequently omitted despite dominating real-world use. There is no public registry tracking environmental metrics and no requirement to monitor consumption in real-world conditions after deployment. The first reports are not due until 2 August 2028.

So the obligation to ask sits with the buyer. Five questions worth putting to any AI vendor, in writing, at sourcing rather than renewal:

  1. What is your measured energy per query, and does the figure include host processors, idle capacity and cooling overhead, or accelerator consumption alone?
  2. Is that figure measured in production, under batching and normal concurrency, or derived from isolated testing?
  3. What is the figure for a long reasoning or agentic request, as distinct from a standard one?
  4. Which grid regions serve our workload, and what is the carbon intensity of each?
  5. Will you provide consumption data on our account, at our volumes, on a recurring basis?

Any provider who cannot answer the first three is not concealing information. They have not measured it. That distinction matters, because it tells you whether you are negotiating with a supplier or with an industry that has not yet built the instrument.

What is the carbon footprint of an AI project over its entire lifecycle?

Unknown in almost every organization, because no standard currently spans the whole of it.

A complete lifecycle covers model training you did not perform, hardware manufacturing you did not commission, inference you generate continuously, and eventual hardware disposal. The Green Software Foundation observes that the EU AI Act requires reporting of electricity consumed but does not account for grid carbon intensity, so identical consumption in two regions reports identically while producing very different emissions.

Which returns the question to ownership. Lifecycle impact stays unmeasured not because measurement is impossible but because it belongs to nobody: procurement owns the contract, IT owns the platform, sustainability owns the report, and consumption is generated by everyone. Data with no owner degrades. This is that pattern, arriving in a new category.

One closing observation. Google reports a thirty-three-fold reduction in energy per prompt and a forty-four-fold reduction in carbon over a twelve-month period. Genuine engineering, honestly reported. Total demand rose regardless, because efficiency of that magnitude does not reduce consumption. It reduces price, and cheaper capability is used more. Anyone waiting for efficiency gains to resolve this is waiting for the wrong thing.

The organizations that will manage AI consumption well are not the ones choosing greener models. They are the ones that assigned the question an owner before anyone asked them to.