What Articles 40 and 95 actually establish
Enterprise teams often search for EU AI Act energy reporting requirements as if the Act imposed a single metric, template, and filing deadline. Articles 40 and 95 work differently. Article 40 is the standards route: conformity with relevant harmonised standards can support presumption of conformity with applicable requirements, and standards work is where detailed technical methods for performance, documentation, and efficiency-related evidence commonly mature. Article 95 is the codes-of-conduct route: it encourages voluntary application of practices beyond mandatory high-risk controls, including environmental sustainability themes such as energy-efficient design, training, and use.
For governance leaders, the practical reading is constrained. Do not invent a statutory energy return that the text does not state. Do map where energy consumption becomes relevant because a system is in scope for standards-driven documentation, a code your organisation adopts, customer or regulator expectations tied to those pathways, or internal risk policy that treats energy as a material AI operating metric. That framing keeps programmes defensible and avoids overstating legal duty while still building evidence that audits can follow.
Which systems, roles, and lifecycle stages matter
Energy-related documentation is rarely owned by one team. Model owners know training and fine-tuning profiles. Platform and cloud teams see accelerator utilisation, region, and instance mix. Application and agent owners see inference volume, tool loops, and orchestration overhead. Procurement owns third-party model and API terms. Legal and compliance own whether a system is high-risk, otherwise regulated, or voluntarily covered by a code. Security and runtime governance own identity, permissioning, and audit logs that prove which agent or workload produced consumption.
Prioritise categories where consumption is material and attributable: large training and fine-tuning runs; high-volume inference services; multi-agent workflows with repeated tool calls; batch evaluation and red-team jobs; and embedded third-party models where you lack direct meter access. Cover the full lifecycle that creates energy use: data preparation, training, evaluation, deployment, scaled inference, retraining, and decommissioning. If a system is a candidate for standards-aligned technical files or for voluntary code commitments under Article 95 themes, treat energy evidence as part of the same control environment as risk, logging, and change management rather than a side spreadsheet.
| Role | Primary contribution | Evidence focus |
|---|---|---|
| Model owners | Training and fine-tuning profiles | Model version, run windows, method changes |
| Platform and cloud | Accelerator utilisation, region, instance mix | Infrastructure signals and provider exports |
| Application and agent owners | Inference volume, tool loops, orchestration | Agent identity, path, and call volume |
| Procurement | Third-party model and API terms | Data rights and measurement boundaries |
| Legal and compliance | Scope and voluntary code posture | Mandatory vs voluntary labelling |
| Security and runtime governance | Identity, permissioning, audit logs | Who ran what, with which approvals |
Telemetry and calculation methods that hold up in audit
Auditable energy evidence needs more than a monthly cloud sustainability dashboard screenshot. Define the measured object: model version, endpoint, agent identity, job ID, environment, and time window. Capture infrastructure signals that can be converted or correlated to energy: GPU and accelerator hours, instance types, utilisation, data centre or region metadata, and provider-reported energy or carbon figures where available. Separate direct meter data from estimated data. Document the estimation model, emission or energy factors, allocation rules for shared clusters, and known error bounds.
Provenance controls matter as much as the number. Record who produced each dataset, which API or export it came from, when it was pulled, and whether it was transformed. Retain raw extracts alongside derived reports. Version calculation notebooks or pipelines the same way you version models. Bind energy records to change tickets when model weights, decoding settings, agent tools, or traffic patterns shift. Retention should match your wider AI compliance and financial control periods so energy figures remain reconstructable after staff or vendor changes.
For agents and tool-using systems, log the runtime path that drives consumption: which agent ran, which tools were approved, how many iterative calls occurred, and whether human approval gates limited runaway loops. Runtime monitoring and least-privilege tool governance reduce uncontrolled inference spend and give compliance a causal trail from policy to measured load.
Evidence design checklist
- Measured object defined (model, endpoint, agent, job, environment, time window)
- Direct meter data separated from estimates, with method and error bounds
- Raw extracts retained beside derived reports
- Calculation pipelines versioned and linked to change tickets
- Agent runtime path logged with tool approvals and iteration counts
Incorporating cloud, model providers, and third parties
Most enterprise AI energy footprints span assets you do not fully meter. Build a supplier evidence tier list. Tier one: first-party clusters with direct power or facility feeds. Tier two: cloud accounts with native energy or carbon tooling and exportable usage. Tier three: model APIs and managed agent platforms that only provide aggregate usage, token counts, or qualitative efficiency statements. Contract for machine-readable usage exports, definition of measurement boundaries, region-level granularity, and notice when estimation methods change.
Normalise units before rollup. Token counts and request volumes are activity drivers, not energy, unless paired with a documented conversion method appropriate to the provider and modality. Allocate shared services with explicit rules, for example by GPU-seconds, job tags, or cost centre, and keep the allocator under change control. For multi-tenant agent platforms, require identity-level usage attribution so enterprise tenants can separate their workloads. Where providers cannot supply energy figures, record the gap, use stated estimation methods, and avoid presenting estimates as measured values in external reports.
| Tier | Source | Typical data | Governance note |
|---|---|---|---|
| One | First-party clusters | Direct power or facility feeds | Strongest measured baseline |
| Two | Cloud accounts | Native energy or carbon exports, usage | Define regions and export cadence |
| Three | Model APIs and managed agents | Aggregate usage, tokens, qualitative statements | Never label estimates as measured |
Operating the process without overstating duty
- Separate mandatory scope from voluntary code scope: Label reports as standards-aligned technical evidence, voluntary Article 95 code metrics, customer reporting, or internal KPI so legal posture stays accurate.
- Govern agents as first-class consumers: Apply runtime policy enforcement, tool approval workflows, and audit logging so iterative agent behaviour cannot silently multiply inference energy.
- Review on material change: Recalculate baselines when models, hardware, regions, traffic, or provider methodologies change, and store the before and after package.
- Use energy signals in release gates: Add efficiency thresholds to deployment reviews for high-volume services, not only to annual sustainability summaries.
Evaluation criteria for an auditable programme
A workable enterprise programme answers five questions consistently. Can you identify which AI systems are subject to standards-driven documentation expectations, voluntary code commitments, or internal policy only? Can you reconstruct energy or energy-proxy figures from retained raw inputs with a named method version? Can you attribute consumption to models, endpoints, agents, and vendors? Can you show who approved high-draw runtimes and tool permissions? Can legal and audit teams read the same package without reconciling conflicting spreadsheets?
If those answers are weak, prioritise inventory quality, provider data rights, and runtime attribution before polished dashboards. Runtime governance capabilities such as monitoring, policy enforcement, agent identity, least privilege, and audit logging strengthen the operational backbone of energy evidence, especially where autonomous or semi-autonomous agents drive variable load. Keep product choices secondary to evidence design: clear boundaries, conservative claims, and durable records will matter more than any single visualisation when Articles 40 or 95 pathways, customers, or auditors ask how you know.