Energy has become an architectural constraint, not a sustainability line
The limit on AI infrastructure has moved from capital to power delivery, and that changes where inference can be placed, what it costs and how quickly capacity can be added. It belongs in the design review, not the annual report.
Energy appears in most AI programmes exactly once, in a paragraph near the end of a sustainability section, and it is written by someone who was not in the architecture review. That placement made sense while compute was something you bought rather than something you queued for.
It has stopped making sense. The constraint on new AI capacity in most markets is now the ability to deliver power to a site on a timescale anyone can plan around, and a constraint of that kind does not stay in the sustainability section. It shows up as a lead time, a region choice, a price, and eventually as a design decision about how much inference a system performs at all.
The claim: power availability has become an input to architecture, and the teams making placement and capacity decisions are largely not treating it as one.
What the published numbers actually say
The International Energy Agency’s work on energy demand from AI is the most useful public reference here, because it separates data centre demand overall from the AI-specific portion and states its uncertainty rather than hiding it. Its central projection has global data centre electricity consumption roughly doubling by 2030, with AI-optimised facilities accounting for most of the growth — and the report is candid that the spread between its scenarios is wide, which is itself the planning-relevant fact.
Two things follow for an enterprise that will never build a data centre. First, the cost of hosted inference has a floor that is set by electricity prices and grid connections rather than by competitive pressure between providers. Second, capacity in a specific region on a specific date is not a given, and residency requirements interact with that in a way that removes options rather than adding them.
Where it lands in a design
- Decision 01 Placement Which regions can serve this workload, and whether the residency-constrained ones have capacity when you need it.
- Decision 02 Capacity commitment Reserved throughput versus on-demand. Reservation is now a hedge against availability, not only against price.
- Decision 03 Work per request How much reasoning, retrieval and re-ranking each request performs. This is the only lever fully inside your control.
- Decision 04 Batch versus interactive Work that does not need an immediate answer can be scheduled, which is cheaper and easier to place.
- Decision 05 Model size The largest lever on energy per request, and the one most often set by habit rather than by requirement.
The fourth row is the underused one. A large share of enterprise AI work is not interactive at all — document classification, enrichment, summarisation of things nobody is waiting for — and it is being served through interactive endpoints because that is how the first prototype was built. Moving it to a batch path reduces the cost, relaxes the placement constraint and improves the utilisation of whatever hardware is underneath it. It is an ordinary engineering decision with an energy consequence that nobody counts.
The reporting problem underneath it
Organisations that want to account for this honestly run into a measurement problem straight away: energy per request is not something most providers expose, and the published per-query figures vary by more than an order of magnitude depending on model, context length and whether the system performs extended reasoning. Anyone quoting a single watt-hour figure for “an AI query” is quoting an average over a distribution they have not described.
What can be measured internally is tokens — in and out, per route, per system. That is not energy, and it is the best available proxy, because it moves with the thing that actually consumes power. An organisation that already measures tokens per case for cost reasons has most of what it needs for a defensible energy narrative, and one that measures neither has neither.
What this does not tell you
We do not publish an energy figure for any system, because we cannot measure one we did not instrument, and the modelled numbers in circulation are mostly derived from assumptions their authors were clear about and their readers were not. If this piece contained a watt-hour figure per query it would be doing the thing it is arguing against.
It also does not claim that efficiency work reduces total consumption. Historical experience with efficiency in computing suggests the opposite is at least as likely at the level of the whole system, and an organisation that reduces its cost per request and then serves ten times as many requests has not reduced anything. What efficiency buys at the enterprise level is headroom and optionality, which is worth having on its own terms and is not a climate claim.
The person who should read this differently is whoever chooses the deployment region for the next system. The question used to be latency and price. It now includes whether the capacity exists in the place your obligations require it to be — and that answer changes fast enough to be worth asking again at each renewal rather than assuming it held.