AI runs on energy.
Measure the system.

Every energy number describes a different boundary.

The International Energy Agency’s 2026 outlook estimates that data centres used about 485 terawatt-hours (TWh) of electricity in 2025 and projects roughly 950 TWh in 2030—around 3% of global electricity demand. Its AI-focused subset is projected to triple over that period. These figures describe data-centre infrastructure, which serves many workloads; they are not a measurement of AI alone or of one chat request.

In the IEA’s estimates, data-centre electricity use grew 17% in 2025, while electricity use from AI-focused data centres grew 50%. The difference matters: a data centre runs many kinds of computing, while AI use is itself expanding and changing. The IEA also notes that global statistics on how often and how deeply people use AI are incomplete, so forecasts should be read as estimates with stated assumptions.

Three questions often get collapsed into one: how much electricity a task used, how much a facility draws over time, and what adding that facility means for its local energy system. A useful estimate names the boundary, time period, and unit, then states what it leaves outside the calculation.

Read the IEA’s 2026 energy and AI outlook ↗

A cheaper task can sit inside a larger system.

Hardware and software improvements can reduce the electricity needed for an individual AI task. The IEA reports that energy per task has fallen by at least an order of magnitude annually in recent years. At the same time, overall data-centre electricity use is rising as more people use AI and more compute-intensive services arrive.

The task itself matters too. The IEA contrasts simple text queries with video generation, reasoning, and agentic workloads, which can use hundreds or thousands of times more energy per query in its analysis. That is a comparison between types of work—not a constant that applies to every model, prompt, or service.

So “energy per prompt” needs a definition: the model and hardware, input and output length, tools and retries, duration, and whether facility overhead is included. Without that setup, a crisp number can create more certainty than the measurement supports.

A global average can hide a local constraint.

Data centres draw power in specific places and at specific times. New facilities can face grid-connection delays, and a project pipeline is not the same as electricity already being consumed: proposals may be duplicated or speculative, while operating sites add load gradually as buildings, servers, and workloads come online.

Water is part of the picture as well. The IEA’s 2026 analysis found that nearly 40% of identified capacity dedicated to AI is in areas with high or extremely high baseline water stress. That is a location-level screening signal, not a measurement of each facility’s actual water use. Cooling choices also involve trade-offs: systems that use less water can require more energy, and water is used upstream in electricity generation too.

The IEA’s central scenario estimates data-centre emissions from electricity use could reach around 350 million tonnes of CO₂ in 2035, about 1.5% of global energy-related emissions in that scenario. This is a projection for data centres overall; it does not assign the same emissions to every AI task. The electricity mix, timing, cooling design, and the facility’s own demand shape the result.

Read the IEA’s 2026 report on powering AI ↗

New demand does not have one automatic price effect.

A large, concentrated load can require new generation or grid investment, especially where supply and network capacity are already tight. In a system with spare capacity, a predictable new customer can help make existing infrastructure more fully used. The effect on bills depends on local conditions, the timing and shape of the load, and how connection and upgrade costs are allocated.

The IEA highlights a practical complication: data centres can reserve more grid capacity than they initially use, then ramp up as buildings and servers come online. A credible assessment therefore asks which demand is operating, which is committed, and which is only proposed. It also looks at who pays for capacity built in anticipation of that demand.

These are questions about electricity systems and policy, not a universal verdict that data centres raise or lower everyone’s bills. The IEA explains the local price and investment trade-offs ↗.

AI can consume electricity and help manage energy use.

The same technology can monitor grid equipment, support maintenance, improve forecasting, or help operators use existing capacity. These are potential applications with their own data, engineering, and reliability requirements; their benefits should be measured against a clear operational baseline.

The IEA estimates that well-documented AI use cases could save more than 13 exajoules of energy by 2035—about 3% of global final energy consumption—if barriers to wider adoption are overcome. Separately, it says AI-enabled process optimization could reduce energy costs by 3–10 percentage points in energy-intensive industries. One figure is estimated potential energy savings across use cases; the other concerns energy costs in a defined sector. Neither is a guaranteed saving from any individual AI product.

To test a claim, compare the same service before and after deployment. Define whether the result is lower energy use, lower energy cost, fewer outages, or another outcome; include the computing and operational overhead of the AI system; and state the time period and counterfactual. Do not subtract a modeled future benefit from a separate data-centre forecast as if the two estimates covered the same places, users, or time window.

Adoption has practical limits too. The IEA identifies skills, fragmented data, privacy, cybersecurity, and interoperability among the barriers to greater AI use in the energy sector. Read the IEA’s analysis of AI’s energy-sector applications ↗.

Efficiency needs a quality target.

A smaller or faster system is not more efficient if it fails the task and needs repeated correction. Compare systems on the same work and success criteria, then report the resources required to reach that result alongside quality, latency, retries, and human review.

For a practical energy report, ask:

• What exact task and success threshold were measured?
• Which model, hardware, location, tools, and retry budget were used?
• Does the estimate include cooling and facility overhead, or only compute?
• Are time, workload volume, water context, and measurement uncertainty visible?
• Did the system complete the task at the required quality, with how much review?

This turns an abstract footprint into an engineering question: which part of the system can change, and does that change preserve the result people need?