The question that decides everything else

An organisation that runs AI workloads almost always runs most of them on someone else's hardware. Before any sustainability disclosure can be written, one question has to be answered: whose emissions are they?

The answer is settled accounting, but it is settled the opposite way from how most AI governance documents assume, and the difference changes which number appears in whose report, under which category, with which assurance expectations attached.

The boundary rule

The GHG Protocol Corporate Standard defines the categories nearly every regime builds on. Its Scope 2 definition is a boundary test, not a topic test:

"Scope 2 accounts for GHG emissions from the generation of purchased electricity consumed by the company. Purchased electricity is defined as electricity that is purchased or otherwise brought into the organizational boundary of the company."

A cloud contract does not bring electricity into your organisational boundary. It buys a service. And the GHG Protocol's Scope 3 standard is explicit that Category 1, purchased goods and services, covers exactly that: products "include both goods (tangible products) and services (intangible products)".

So the mapping falls out of the definitions, and it is worth stating plainly because the standard itself never uses the word cloud:

  • Your own servers, your own premises: the electricity is your Scope 2.
  • Cloud, including AI services consumed through an API: the provider's Scope 2, your Scope 3 Category 1.
  • Colocation where you buy the power for your racks: your Scope 2.
  • Colocation where the operator buys the power: your Scope 3 Category 8, upstream leased assets.

That mapping is an application of the category definitions rather than an explicit GHG Protocol ruling on cloud computing. It is the standard reading, but a careful report will document the reasoning rather than cite it as a quotation.

What the reporting frameworks then do with it

IFRS S2. The ISSB's climate standard requires disclosure of Scope 1, Scope 2 and Scope 3 greenhouse gas emissions as a cross-industry metric, measured "in accordance with the Greenhouse Gas Protocol: A Corporate Accounting and Reporting Standard (2004)" unless a jurisdiction requires otherwise, and it requires the location-based Scope 2 figure. So wherever IFRS S2 has been adopted, the boundary logic above is imported wholesale. Energy consumption itself, as distinct from emissions, enters IFRS S2 only through the industry-based guidance, which an entity must "refer to and consider": a genuine obligation, the IFRS Foundation's own material says an entity cannot disregard the guidance, but a consider-and-judge one, not an unconditional duty to publish an energy metric.

ESRS under CSRD. The European standards do require an energy metric, and its boundary is the interesting part. ESRS E1 requires "the total energy consumption in MWh related to own operations", disaggregated by fossil, nuclear and renewable sources. Own operations. Energy consumed on your behalf in a hyperscaler's data centre is not in that number at all. It reaches an ESRS report, if it reaches it, as Scope 3 emissions subject to materiality, not as energy. The revised ESRS set the Commission adopted on 3 July 2026 renumbers the energy disclosure and keeps the own-operations boundary; it is expressed to apply to financial years beginning on or after 1 January 2027.

Who is even in scope. The population that must produce ESRS reports shrank substantially with the EU's Omnibus I simplification. Under Directive (EU) 2026/470, CSRD reporting attaches to undertakings that exceed both EUR 450 million net turnover and an average of 1,000 employees. Many organisations that spent 2024 preparing for CSRD are no longer within it, and a sustainability page that still recites the old thresholds is describing a repealed perimeter.

The two instruments that force computing energy into the open

Neither corporate framework compels anyone to publish the energy an AI workload consumed. Two narrower instruments do touch it, and both stop short of giving a cloud customer a number.

The Energy Efficiency Directive requires Member States to make owners and operators of data centres with installed IT power demand of at least 500 kW publish the information in its Annex VII annually, from 15 May 2024. That is facility-level transparency: installed power, floor area, energy and water performance. It does not attribute anything to individual customers, and it does not separate AI from any other workload.

The AI Act requires providers of general-purpose AI models to document the "known or estimated energy consumption of the model". As we set out in detail in our companion piece on the AI Act's energy provisions, that figure is training-focused, methodology-free, and written for regulators rather than published, and the annex governing what flows to downstream providers contains no energy item at all.

The upshot: there is no regime under which your cloud provider owes you, or the public, the energy figure for your workloads. If you need it, it is a procurement question. Ask for it in the contract, alongside the allocation methodology, because a total without a methodology cannot be compared with anyone else's total.

The migration arithmetic nobody should exploit

One consequence of the boundary rule deserves to be said out loud. Move an on-premises AI workload into a third-party cloud and your reported Scope 2 falls, not because any emission stopped, but because the same electricity moved from your boundary into your provider's. It reappears in your Scope 3 Category 1, a category measured with more estimation and, in most regimes, subject to materiality judgements.

Presenting that reclassification as an emissions reduction is the kind of claim that consumer-protection and securities regulators treat as misleading in the climate context generally. The safe description of a cloud migration is a boundary change, disclosed as such. The unsafe description is a decarbonisation achievement.

What to do, in order

  • Classify before you count. Map every AI workload to own-hardware, cloud, or colocation, and apply the boundary rule. The classification drives everything downstream.
  • Contract for the data. Provider emissions figures, the allocation methodology behind them, and update frequency belong in the agreement, not in a hopeful email after year-end. Fold this into vendor due diligence rather than treating it as a reporting afterthought.
  • Keep energy and emissions separate in your own documents. ESRS wants MWh for own operations; the GHG scopes want emissions wherever they arise. Conflating the two produces disclosures that satisfy neither.
  • Describe cloud migrations as boundary changes. If reported Scope 2 fell because workloads moved, say so.
  • Check whether you are still in scope at all. The CSRD population changed in 2026. Verify against the current thresholds before building a reporting programme sized for the old ones.

This article describes the GHG Protocol standards, IFRS S2, the ESRS and EU directives as at the dates given. It is general information, not accounting, legal or assurance advice. Scope classification can turn on contract terms and organisational-boundary choices that differ between organisations; take advice on your own facts.

Related reading

Sources: GHG Protocol, A Corporate Accounting and Reporting Standard (Revised Edition) · GHG Protocol, Corporate Value Chain (Scope 3) Standard · IFRS Foundation, Greenhouse Gas Emissions educational material for IFRS S2 · Commission Delegated Regulation (EU) 2023/2772 (ESRS Set 1) · Directive (EU) 2026/470 (CSRD scope, Omnibus I) · Directive (EU) 2023/1791 (Energy Efficiency), Article 12