Adapted from the Polish article, originally published on 09 May 2026 and updated on 02 October 2026. The English version was published on 02 October 2026.
An enterprise customer asks which model powers your product, where it runs and whether the supplier can provide energy or emissions information. Your team knows the API price and monthly token count. The rest sits across several vendors, dashboards and contracts.
Even if your company does not calculate model-level energy consumption, it needs to understand what its AI stack documentation can actually support. That is a procurement and governance question across markets. The EU AI Act adds specific documentation obligations for general-purpose AI model providers, which should not be applied indiscriminately to every company using an API.
What you will learn
- Who has energy-documentation duties under the AI Act.
- Why authority documentation and downstream integration information are different.
- What the Commission’s 2026 consultation established and what it did not.
- How to ask suppliers for useful information without inventing measurements.
The existing EU duty concerns GPAI model providers
General-purpose AI (GPAI) models can support many tasks and downstream systems. For providers subject to the documentation duty, Article 53(1)(a) and Annex XI of the AI Act require technical documentation for authorities, including known or estimated model energy consumption. When consumption is unknown, an estimate may use information about computational resources.
Article 53(1)(b) and Annex XII separately require information for downstream system providers integrating the model. Annex XII does not simply give every customer access to the whole authority file, including its energy information.
The documentation exemption in Article 53(2) covers qualifying free and open-source models with the specified public parameters and information. It does not cover GPAI models with systemic risk. Model providers need to assess the conditions rather than assume that publishing code alone is enough.
The Commission’s GPAI guidance explains the roles and documentation layers. GPAI obligations apply from 2 August 2025; models placed on the market before that date have a transition until 2 August 2027. The Commission’s full enforcement phase began on 2 August 2026.
The adopted July 2026 Digital Omnibus on AI did not remove the Annex XI energy-information requirement. Its changes to the code-assessment mechanism should not be mistaken for a repeal of the underlying documentation duty.
Using an API does not by itself create that model-provider duty
A company using an external model through an API does not become its GPAI provider merely through that use. Building a product around the model, deploying an AI system and developing or substantially modifying a model are different situations. Establish the actual role before assigning obligations.
The provider and deployer distinction helps frame that analysis. It should be based on what the company develops, places on the market and uses, rather than the label in a vendor’s sales material.
There is no general obligation in the provisions discussed here for an ordinary API user to calculate the upstream model’s energy consumption. A company may nevertheless need supplier information to meet a customer commitment or a separate reporting requirement that genuinely applies to it. Assess that basis specifically; the AI Act is not a shortcut for asserting a universal emissions-reporting duty.
The consultation has ended; a potential label is not a current duty
The Commission opened its targeted energy and emissions consultation on 7 April 2026. Registration closed on 25 May, with questionnaire responses due by 1 June. It formed part of a study on measurement, efficiency and low-emission AI, including training and inference, the stage when a model processes a request.
The consultation described a measurement framework and a potential AI energy and emissions label. That consultation is not itself an adopted labelling rule or a new calculation duty for deployers. The Act’s power to develop measurement methodologies also needs to be distinguished from an adopted methodology applicable to a particular actor.
The GPAI Code of Practice is a voluntary compliance tool, including a Model Documentation Form. Commission guidance is interpretative, while a standard needs assessment of its actual status and scope. Neither a consultation response nor a reference to “best practice” is a substitute for identifying the applicable legal requirement.
Keep energy, emissions and usage figures separate
For procurement, ask what each number represents. Electricity consumption, greenhouse-gas emissions, API usage and the invoice are different measures. A token count or bill does not on its own establish an energy figure. Energy information also needs a stated basis before it can support an emissions claim.
A supplier’s figure might cover training, operation, a whole data centre, a service or an allocation to a customer workload. Ask about the period, boundary, method and limitations before putting it into a customer report. If two suppliers use different boundaries, a comparison may be misleading even when both figures are presented accurately.
Record an unavailable figure as unavailable. An unsupported estimate can create a stronger impression of certainty than the underlying evidence warrants.
These are recommendations for making procurement decisions and supporting claims. They do not prescribe a new reporting methodology.
Map the suppliers and the information they control
A useful stack record should connect a product feature to the model, API service, hosting arrangements and data flows. Record what is known, who supplied the information and which details remain unconfirmed.
- Which model and version does the feature use, and can the vendor change it?
- Who supplies the model and who operates the API or hosting service?
- What can the supplier confirm about processing locations and infrastructure?
- Where are inputs, outputs and logs stored, and who controls retention?
- Who reports usage, and what does that report measure?
- Is any energy or emissions information available for the relevant service and period?
- What contractual access, update notice or assistance can the company obtain?
The same vendor record can support the AI supplier and GDPR assessment. Keep the questions connected, but do not imply that a sustainability statement answers data-protection questions or that an approved DPA validates environmental claims.
A practical example: answering a customer’s procurement questionnaire
Consider a hypothetical startup whose product uses a third-party model for support-ticket summaries. An enterprise customer asks for the feature’s annual emissions and assurance that all processing remains in one region.
The startup should first check what the questionnaire means: which workload, period and emissions boundary the customer expects. Then it can ask the API supplier for applicable documentation and compare the answer with its contract and actual configuration.
If the supplier provides only a company-wide sustainability report, the startup should not present that as a measured footprint of its feature. If the deployment region is configurable but another processing step occurs elsewhere, the response needs to explain that limitation rather than repeat a broad marketing claim.
A workable answer may provide confirmed architecture and usage information, identify missing workload-level data and agree a follow-up. Whether that meets the customer’s requirement is a commercial decision. It does not become a statutory calculation duty because it appears in a procurement form.
Put information access into the vendor discussion
Ask for documentation that the supplier can actually provide and that addresses a defined use. Where the issue matters to a deal, discuss the reporting period, permitted use of supplier figures, change notices and assistance with reasonable customer enquiries. Avoid promising access to information the supplier has not agreed to share.
Assign an owner for the stack record and review it when the model, supplier, configuration or product use changes. The result should help the team explain its architecture, substantiate claims and recognise gaps before committing to a customer answer.
AI governance and vendor contract support can help connect the company’s role, information needs and contractual commitments. The starting point is a documented stack and a clear explanation of which obligations actually apply.