What the EU AI Act requires on energy documentation, and how to estimate energy when it is unknown

Providers of general-purpose AI models must document the known or estimated energy consumption of each model. Article 53(1)(a) requires them to draw up and keep up to date technical documentation containing at a minimum the information in Annex XI, for the purpose of providing it, on request, to the AI Office and national competent authorities. Annex XI, Section 1, point 2(e) lists "known or estimated energy consumption of the model" and adds that where consumption is unknown it "may be based on information about computational resources used". The duty is to document. The Act sets no energy limit in this item and does not ask for publication. This page reads the text as consolidated on 27 July 2026, as shown on the Commission's AI Act Service Desk. It is general information and not legal advice.

To providers of general-purpose AI models, meaning, in the Commission's guidelines, the entity that develops a model or has it developed and places it on the market under its own name. Those guidelines treat a model as general-purpose when it was trained with more than 10²³ floating point operations and can generate language, text-to-image or text-to-video. Three edges decide most real cases.

• Modifiers. Under the guidelines, a company that fine-tunes someone else's model becomes a provider when the modification uses more than one-third of the original training compute. The Code of Practice limits its commitments in that case to the modification.
• Open-source releases. Article 53(2) lifts points (a) and (b) for models under a free and open-source licence with public parameters, unless the model has systemic risk.
• Deployers and integrators. Article 53 is addressed to model providers. A company calling an API has no Annex XI duty, and the documentation form does not route energy items to downstream providers, as shown below.

The documentation duty has applied since 2 August 2025, the Commission's power to enforce it since 2 August 2026, and models placed on the market before 2 August 2025 have until 2 August 2027. That last date is confirmed by the text of Article 111(3). It covers existing models, not later releases, which are in scope from the day they reach the market. The Commission's guidelines describe the year to 2 August 2026 as a period of informal collaboration, so 2026 is the point at which the Act's fines became available for this duty.

A training energy figure in megawatt-hours and, for inference, a benchmarked amount of computation rather than an energy figure. The Code is voluntary and has three chapters, Transparency, Copyright, and Safety and Security. There is no energy chapter. Energy sits in the Model Documentation Form of the Transparency chapter, under the heading "Energy consumption (during training and inference)". Article 53(4) lets providers rely on the Code to show compliance until a harmonised standard is published, and those who do not adhere must show other adequate means. Signatories keep earlier versions of the documentation for 10 years after the model is placed on the market.

The form explains the inference choice in a footnote. Inference energy "depends on more than just the model itself", so the item is "limited to relevant information depending only on the model". For anyone looking for a published kWh per token from providers, this is why the form will not supply one, and a reason to treat a provider's filing and a per-token factor as answers to different questions.

Methodology, and it is not settled. Article 53(5) empowers the Commission to adopt delegated acts detailing measurement and calculation methodologies for Annex XI points 2(d) and (e), "with a view to allowing for comparable and verifiable documentation". An empowerment is not an obligation or a date, and SOMA found no adopted or draft act on the Commission pages it reviewed as of 30 October 2026. Meanwhile the Service Desk FAQ says signatories report an estimate unless they lack critical information about compute or hardware, in which case they say what is missing, and that the AI Office then relies on what it knows, on available scientific resources and on preliminary results of a Commission study on energy-efficient and low-emission AI.

• The consultation. The targeted consultation opened on 7 April 2026. The Commission's page gives 25 May for expressing interest and 1 June for the questionnaire, extended from 10 and 25 May, so it is closed. Results feed a measurement framework and "a potential AI energy and emission label", which is a possibility and not a scheme.
• The Ombudsman. On 6 October 2026 the European Ombudswoman closed case 3162/2025/MIK, opened after a Member of the European Parliament raised possible discrepancies between the Act and the Code. She encouraged the Commission to keep improving technical solutions for estimating energy use and stressed its duty to monitor how the Code performs.
• Standards. Article 40(2) has standardisation requests cover the energy-efficient development of general-purpose models, and Article 112(6) has the Commission assess by August 2028 whether further measures, including binding ones, are needed.

• It does not require public disclosure. The documentation goes to authorities on request, and Article 53(7) applies the confidentiality rules of Article 78.
• It does not set an energy cap or an efficiency threshold in Annex XI.
• It does not ask for greenhouse gas emissions. Annex XI point 2(e) names energy consumption.
• It does not give a deployer a duty to calculate its usage, and it gives no deployer a right to the provider's energy figure through the form.
• It does not approve any factor, dataset or calculator, including this one.
• It does not change Scope 3 accounting. A company's AI line in a GHG inventory comes from GHG accounting rules, not from this Act.

Article 50 is about telling people they are dealing with AI, and it has nothing to do with emissions. Its paragraph 2 says providers of systems generating synthetic audio, image, video or text "shall ensure that the outputs of the AI system are marked in a machine-readable format and detectable as artificially generated or manipulated". The article does not mention energy. It addresses systems and their outputs, while Article 53 addresses models and their documentation. Its deadlines differ as well. Article 50 applies from 2 August 2026, and Article 111, as amended, gives systems already on the market until 2 December 2026 for paragraph 2. Treat a statement that "Article 50 requires AI carbon reporting" as an error, wherever you read it.

Start from compute logs, because that is the route Annex XI itself allows. Accelerator-hours come from your scheduler or your compute provider's invoices. Multiply by an average power per accelerator, using telemetry where you have it and a documented assumption where you do not, then uplift for the rest of the server and the facility. No formula is prescribed while no delegated act exists, so the method description carries real weight in the form. State what was included, such as final runs against experiments, and what was left out. If a compute provider refuses the inputs, the Code's route is N/A with an account of what is missing, not a guess presented as a figure.

A worked illustration, with placeholder inputs. 2,000 accelerators for 60 days is 2,880,000 accelerator-hours. At an assumed average of 0.5 kW that is 1,440,000 kWh. Applying a host uplift of 1.5 and a facility overhead of 1.20, the central values SAEF uses for inference and offered here as defaults to replace, gives about 2,592 MWh, which is the two significant figures the form asks for. SAEF does not supply your training figure. Its training term spreads other models' disclosed emissions over tokens and says nothing about your run.

As a cross-check on order of magnitude, not as a filing. The form asks a provider for computation on a benchmark task, so a kWh-per-token factor does not fill that box. It helps with a different question, whether your internal estimate of serving energy at a given volume is plausible, and it gives a provider with no telemetry on a third-party host a starting range to describe. The table gives SAEF's estimated facility electricity per million billed tokens, by model class, at the dataset's default input and output mix. It includes the server, capacity held idle and facility overhead. At 1,000 million billed tokens a class C model comes to about 265 kWh. If your own figure is ten times away from that, find out why before you file.

The limits are real, and any use of the factor should state them.

• Class values are means of open-weight models benchmarked on specific GPUs, so they are not a reading of your model or your fleet.
• A closed model reaches a class by disclosed size or pricing tier, and the wrong class moves the answer far more than the spread shown.
• Tokens do not convert to the floating point operations the form asks for, and no such conversion is offered here.
• The factors cover chat and completion inference. Image, speech, video and embedding models are outside this version.
• The method paper is under peer review, and no authority has endorsed the factors for Annex XI purposes.

A provider with its own telemetry has better data than any published factor and should use it. The honest role for a public factor is independent comparison, and that role may grow if a delegated act brings the comparability Article 53(5) aims at.

Nothing is required under Article 53, so start from your own reason for wanting the figure, usually a Scope 3 line, a customer questionnaire or a procurement comparison. Expect little from the provider's model documentation, since the form does not route energy to downstream providers, although you can always ask directly. Then work from your own usage. Export billed tokens by model, assign the class, multiply by the table above, and report the result as an estimate with the version attached. For 240 million billed tokens on a class B model that is about 17.1 kWh. Note in your file that the electricity is the provider's, not yours, so this is value chain information and it does not belong in your own energy consumption.

The same usage yields different emissions by region, which is the part an inventory needs. On the SOMA AI Emission Factors it comes to about 5.9 kg CO₂e served from EU West - Ireland, 1.7 kg from EU North - Sweden and 6.3 kg from US East - N. Virginia, including embodied hardware, construction and amortised training. These are location-based estimates. If a provider gives you its own figure for your account, use that instead and record its boundary.

The boundary and equations are on the methodology page, and the factors are open under CC BY 4.0, so anyone can rerun them. AI providers, regulators, standards bodies and researchers who can correct an input or a mapping can write to guillermollopis@somaai.earth. Accepted corrections go into the next dataset version and its changelog.

Figures per query are one plain exchange, before the Tier 2b reasoning uplift. Electricity term. GPU energy per token from the ML.ENERGY Leaderboard v3, a facility overhead of 1.20, and grid carbon intensity from EPA eGRID 2023 and Ember 2023. Embodied hardware, data-centre construction and amortised training terms are documented on the methodology page. Water combines on-site cooling water (Li et al. 2025) with the water embedded in grid electricity (Reig et al. 2020). The modelled range of the models inside a class, around the class value, is −41% to +48% for class A, −39% to +24% for class B and −67% to +55% for class C.

Dataset: AI Inference Emission and Resource Factors for Corporate GHG Inventories (SOMA AI Emission Factors (SAEF)), Llopis-Garcia, G., SOMA AI, 19 October 2026, CC BY 4.0, concept DOI 10.5281/zenodo.20443585, which resolves to the latest version (this version 10.5281/zenodo.23371447, earlier version 2 values at 10.5281/zenodo.22767475). Method: Accounting for Purchased AI Inference in Corporate GHG Inventories: A Token-Based Method, arXiv:2606.10660, under peer review.

Partners can fetch any row from the AI factors API, and the whole table is a CSV download.

• Where AI usage sits in the GHG Protocol's draft Scope 3 data types. The inventory side of the same question
• How to account for AI usage in your Scope 3 inventory under CSRD. The full method, step by step
• SOMA AI Emission Factors table and download. kg CO₂e, water and uncertainty by class and region