New Standard  ·  ITU-T Study Group 5  ·  Approved 06 February 2026

AI finally has an
environmental report card.

ITU-T L.1801 is the world's first standard for measuring how much AI systems actually cost the planet — from GPU mining to your last query. This is what it means, layer by layer.

4
Life cycle stages every AI must account for
5
Environmental impact categories defined
3
Orders of effect — including ripple effects on the world
Scroll to explore
01 — The Problem

Nobody was measuring the same thing

Explain it like I'm 5
Three kids weigh their Halloween candy. One counts only chocolate. One counts everything including wrappers. One only counts candy they actually liked. Now try to compare who has "more." That's AI environmental reporting before L.1801.

Before this standard, AI companies measured environmental impact using entirely different approaches. Some reported only electricity during inference. Some included hardware manufacturing. Some disclosed only carbon while ignoring water and mineral use. All technically defensible. All incomparable. L.1801 creates the shared rulebook: same methodology, same categories, same reporting structure.

Before L.1801

Self-reported, inconsistent metrics. Company A counts electricity only. Company B adds hardware manufacturing. Company C reports nothing. No meaningful comparison is possible between any of them.

After L.1801

A defined methodology: what to count, how to count it, which boundaries to draw, which categories to report. Voluntary for now — but this is the scientific foundation on which future regulation will be built.

Key insight: Before L.1801, there was no shared rulebook — so all environmental comparisons between AI systems were scientifically meaningless. The standard doesn't solve the problem overnight, but it ends the era of comparing apples to cars.
Scope (Section 1)
Provides guidelines for assessing the environmental impact of AI systems objectively and transparently. Based on LCA methodology in ITU-T L.1410 and the enabling effects method in ITU-T L.1480. Explicitly does not cover aggregated global or national AI environmental impact.
AI System (ISO/IEC 22989)
Engineered system that generates outputs such as content, forecasts, recommendations or decisions for a given set of human-defined objectives.

Developed jointly by ETSI TC EE and ITU-T Study Group 5. Published simultaneously as ITU-T L.1801 and ETSI ES 204 135. Compliance is voluntary, but provides the methodological foundation for mandatory requirements under instruments such as the EU AI Act.

02 — Not All AI is Equal

A spam filter and GPT are not the same problem

Explain it like I'm 5
A bicycle and a jumbo jet both get you places. But comparing their "fuel use" as if they're the same thing would be ridiculous. L.1801 recognises that AI comes in four very different types — and their environmental footprints are not even close to each other.

Before measuring anything, the standard requires you to classify what kind of AI you are assessing. Section 6.3 defines four technology types with fundamentally different hardware, data, and energy demands. This classification is the starting point of every L.1801 assessment.

Type 01
Expert Systems
Medical diagnosis, fraud detection, energy optimisation — rule-based, human-defined logic
Energy
Data
Hardware: CPU only
Type 02
Machine Learning
Email filtering, product recommendations — learns from statistical patterns in data
Energy
Data
Hardware: CPU + GPU
Type 03
Deep Learning
Image recognition, CNNs, RNNs — multiple layers of neural networks
Energy
Data
Hardware: CPU + GPU
Highest Impact
Type 04
Generative AI
LLMs, image/video generation, multi-modal models — generating new content at scale
Energy
Data
Hardware: Significant GPUs and/or TPUs
Key insight: The standard explicitly classifies GenAI as "comparatively high" in both energy and hardware demands — a level above all other AI types. When people debate "AI's environmental impact," they are mostly talking about Type 04.

Table 1 in Section 6.3 classifies AI systems by technology type across five dimensions: technology examples, use case examples, hardware resources, data resources, and energy resources. The standard uses "comparatively low / medium / medium to high / high" as relative descriptors — not absolute numbers.

Generative AI system (ISO/IEC 22989/DAmd 1)
AI system based on techniques and models that aim to generate new content (text, audio, code, video, image). The amendment to add GenAI as a distinct category reflects how rapidly the field evolved after the original ISO/IEC 22989 standard was published.
Foundation model (ISO/IEC 22989/DAmd 1)
AI model that can be used for or readily adapted to a wide range of tasks in one or more domains. Foundation models require special treatment in L.1801's allocation methodology because one training run underlies potentially thousands of downstream applications.

Section 6.2 also describes the full AI system life cycle (based on ISO/IEC 5338): Inception → Design and development → Verification and validation → Deployment → Operation and monitoring → Continuous validation → Re-evaluation → Retirement. All eight stages are in scope for environmental accounting.

03 — The Foundation

Count the whole story, not just the ending

Explain it like I'm 5
Before you say your toy is eco-friendly, you have to count the mine where the metals came from, the factory that built it, the truck that shipped it, and what happens when you throw it away. Not just whether the box is recyclable.

L.1801 is built on Life Cycle Assessment (LCA) — the internationally recognised methodology for environmental accounting, standardised in ITU-T L.1410. The core principle: measure the full life of the system, from raw material extraction to end-of-life treatment. For AI that means four stages. Click each stage below to see what the standard actually requires you to count.

Click any stage to expand its data requirements
STAGE 01
⛏️
Make the Hardware
Before training begins
STAGE 02
🧠
Build & Train
The expensive phase
STAGE 03
Run It Daily
Inference & operation
STAGE 04
♻️
Retire It
Decommission & e-waste
Key insight: Most AI companies today report only Stage 3 — inference electricity. The standard requires all four stages. Stages 1 and 4 in particular are almost universally missing from current AI environmental disclosures.

Section 8.1.1 maps AI-specific stages to the four standard LCA stages:

  • Raw material acquisition: Materials for hardware — mining, processing, transportation to manufacturing
  • Production: Hardware manufacturing + inception, design/development, verification/validation + initial training
  • Use: Deployment, operation and monitoring, re-evaluation, continuous validation + inference and continuous learning / re-training
  • End-of-life treatment (EoLT): Hardware decommissioning + software retirement

Physical transportation is calculated in each stage. Data transmission and storage are calculated in the stage where the activity takes place. In shared infrastructure, the full life cycle impact shall be allocated to users according to their proportional usage.

04 — Training vs. Inference

Teaching the dog vs. the dog doing the trick

Explain it like I'm 5
Teaching your dog to sit took 100 treats over three months. Every time he actually sits after that costs almost nothing. But those 100 treats still happened — and the standard says you cannot pretend they didn't.

L.1801 requires training and inference to be reported separately — always. This is a firm requirement, not a recommendation. The reason: these two activities have completely different cost profiles, different causes, and different solutions. Blending them into one number makes both invisible.

Training
The one-time fixed cost
"Teaching the dog" — happens once, or rarely
  • Can consume enormous amounts of electricity
  • Requires large GPU/TPU clusters running continuously
  • Generates significant heat requiring active cooling
  • Counted in the Production LCA stage
  • Initial training and re-training reported separately
  • Must never be blended with inference data
Inference
The ongoing per-use cost
"The dog doing the trick" — potentially billions of times
  • Individually small per request
  • Collectively significant at population scale
  • Counted in the Use LCA stage
  • Measured per functional unit (token, image, byte…)
  • Includes continuous learning / re-training updates
  • Must never be blended with training data
Key insight: Training is a one-time capital cost. Inference is an ongoing operational cost. They respond to completely different interventions — you reduce training impact by being more efficient up front; you reduce inference impact by running fewer queries or on cleaner energy. Treating them as the same number prevents either problem from being solved.
Continual learning (ISO/IEC 22989)
Incremental training of an AI system that takes place on an ongoing basis during the operation phase. L.1801 requires this to be inventoried and reported separately from initial training — it is not the same as regular inference.

From Appendix III, LCI data for the training phase shall include: GPU/TPU-hours (h), average power draw (W), training FLOPs, data volume processed (TB), and CI/CD pipeline energy. For inference: request counts, accelerator utilisation %, IT energy (kWh), PUE (Power Usage Effectiveness), WUE (Water Usage Effectiveness), and renewable energy percentage.

Emission factor hierarchy (Section 8.1.3): Market-based emission factors are required first. Location-based factors are used when market-based are unavailable. Global average emission factors are only acceptable as a last resort. This hierarchy is critical: the same model trained in a near-zero-carbon grid region vs. a high-fossil-fuel grid can differ by an order of magnitude.

05 — The Functional Unit

What counts as "one use"?

Explain it like I'm 5
Before you can compare two pizzas to see which is "healthier," you have to agree — are you comparing one slice, one whole pizza, or one bite? Your choice changes everything. The same AI task measured in different units can look 1,000× better or worse.

The functional unit is the reference measure against which all environmental impacts are calculated. Choosing it is the first decision in any L.1801 assessment — and it fundamentally changes the numbers. The standard provides specific functional units for each AI type, worked through in Appendix IV. Select a type below.

💬
Text Generation
🖼️
Image Generation
🎤
Speech Recognition
🎬
Video Generation
🌐
Network Management
Select an AI type above to see its functional unit from the standard
Key insight: The standard acknowledges that quality for text generation is difficult to define precisely within the functional unit. Two models generating 1,000 tokens may produce very different quality outputs yet appear equal under this metric. This is a known open problem, not a solved one.

Appendix IV evaluates each functional unit against five criteria from the LCA methodology:

  • Defines performance characteristics — does it describe what the system does?
  • Has a function (what) — is the task clearly identified?
  • Quantifiable unit (how much) — can you assign a concrete number?
  • Duration (how long) — does timing matter for this type of task?
  • Quality — can output quality be captured within the unit?
Functional unit (ISO 14040)
Quantified performance of a product system for use as a reference unit. In L.1801, this is the basis against which all environmental impacts are normalised and against which any comparative claims must be anchored.

Note from Appendix IV: numeric quantification for the network management use case is described as "difficult to set" due to traffic profile dependence. The standard acknowledges this limitation explicitly rather than forcing a false precision.

06 — System Boundary

Where does the AI end?

Explain it like I'm 5
When you tidy your bedroom, do you count the hallway? The garage? The whole street? You have to decide where your room ends before you start. In L.1801, this decision is called the system boundary — and where you draw it depends on what kind of AI product you have.

L.1801 defines three situations based on how AI sits within a product. Each situation changes what must be included in the measurement. The same underlying AI model can have a very different reported footprint depending on which situation applies — and the standard treats this as correct and expected, not as a loophole.

Situation 1
AI is the whole product
Examples: A standalone LLM service, a neural network API, a foundation model accessed directly
Boundary includes: AI hardware and software components only
Situation 2
AI is inside an ICT product
Examples: AI features in a video conferencing app, AI in a smartphone, AI inside enterprise software
Boundary includes: AI components + all non-AI ICT components of the product
Situation 3
AI is inside a non-tech product
Examples: AI in a washing machine, AI-assisted driving system, AI inside a smart thermostat
Boundary includes: AI + non-AI ICT + all non-ICT product components
Key insight: For comparative claims to be scientifically valid — "our model is X% greener" — both systems being compared must use the same functional unit, same system boundaries, and same time horizon. The standard states this explicitly. Without it, all comparative environmental claims are methodologically invalid.

Section 8.2 covers comparative LCA — assessing two product systems side by side. Two cases are defined:

  • Case 1: AI system compared to a different AI system (e.g., LLM A vs. LLM B)
  • Case 2: AI system compared to a non-AI equivalent (e.g., AI customer service chatbot vs. a human call centre operation)
Cut-off rules (Section 8.1.2.4)
Per ITU-T L.1410. Exclusions are only acceptable when they satisfy mass, energy, and environmental significance criteria simultaneously. Companies cannot exclude inconvenient data sources simply by labelling them a "cut-off." All cut-offs must be declared in the compliance statement.
07 — What We Measure

It's not just about carbon

Explain it like I'm 5
A car isn't bad for just one reason. It burns petrol, needs metal to build, uses water in its engine, and takes up space. AI is the same. Measuring only carbon is like judging a car only by how loud it is — you're missing most of the picture.

L.1801 mandates one impact category and recommends four more. In practice, the recommended categories are likely to be skipped by most organisations unless required by regulation. Click any card to see what it measures and why it matters.

Mandatory
🌡️
Climate Change
GHG emissions across full life cycle

The only mandatory metric in L.1801. Covers CO₂, methane, and all greenhouse gases across the complete life cycle — hardware manufacturing, training, inference, and end-of-life.

This is mandatory because it has the most established measurement methodology and the highest current data availability across the industry.

Recommended
💧
Water Use
Cooling systems + energy generation

Data centres use water for direct cooling of hardware. Energy generation — particularly thermal power plants — also consumes significant water. L.1801 requires both to be counted, not just one or the other.

The standard identifies water use as a significant environmental pressure driven by AI's high energy demands throughout the full life cycle.

Recommended
⚙️
Minerals & Metals
Rare earth elements for hardware

GPUs and TPUs require cobalt, lithium, neodymium, tantalum, and other critical minerals. The standard identifies mining and extraction as a significant source of resource depletion across the AI hardware supply chain.

As AI hardware demand scales, the environmental impact of mineral extraction becomes increasingly material — and is almost never included in current AI environmental disclosures.

Recommended
🛢️
Fossil Fuels
Energy source matters enormously

The environmental impact of AI's energy consumption depends on where that energy comes from. The standard's preferred hierarchy — market-based emission factors first, then location-based, global average only as a last resort — exists precisely because grid mix changes results dramatically.

Two identical models trained in different locations can have very different fossil fuel impacts.

Recommended
🌿
Biodiversity
The one almost nobody measures yet

Material extraction and land use for data centres and power infrastructure affect local ecosystems directly. GHG emissions from AI also contribute to climate change, which the standard identifies as a driver of biodiversity impact throughout the life cycle.

Listed as an "additional consideration" rather than a recommended category because credible, scalable measurement methodologies are still developing. Expected to become mandatory in future editions.

Key insight: Only carbon is mandatory. Water, minerals, fossil fuels, and biodiversity are all optional. This means most organisations will report carbon and stop there — which the standard is designed to evolve beyond as measurement methodologies mature and regulation catches up.

Section 8.1.6 defines required reporting elements. A compliant L.1801 report must include:

  • System description: architecture, functionalities, operational context
  • Functional unit (explicitly stated)
  • System boundaries (which life cycle stages are included, what is excluded and why)
  • Data sources and quality: emission factors, assumptions, allocations, and cut-offs
  • Energy consumption: training and inference reported separately
  • Breakdown of environmental impacts per LCA stage (recommended)
  • Compliance statement: full or partial compliance, with explicit declaration of any excluded elements

The compliance statement requirement prevents organisations from selectively reporting favourable metrics without disclosure. Partial compliance is permitted, but the omissions must be declared — they cannot simply be left unreported.

08 — Splitting the Bill

Who pays for the training run?

Explain it like I'm 5
You and three friends order a pizza. It costs £20. Split evenly, you each pay £5. Now imagine that same pizza is shared across 1 billion people. Your share is basically nothing — but the pizza still cost £20. This is the allocation problem that L.1801 has to solve for AI foundation models.

Foundation models are trained once and used billions of times. L.1801's method: estimate the total number of inferences the model will perform across its entire lifetime, then allocate the training footprint proportionally across all of them. Move the slider to see what that means in practice.

Illustrative example: A large AI model requires a significant amount of electricity to train. At a moderate carbon intensity for the electricity grid, that training run produces a large fixed carbon cost. Each individual inference query produces a much smaller ongoing cost. This example is hypothetical — the standard defines the allocation method, not the actual numbers for any specific model.
This model has been used 1,000 times
1,000 uses 1 billion uses
250 kg
Training CO₂ allocated to this query
~0.001 kg
Inference CO₂ for this query
250 kg
Total CO₂ this query "cost"
Drag the slider to see how the allocated training cost per query changes with scale.
Key insight: Accurate allocation requires knowing total lifetime inference volumes — data that AI companies almost never publish. The standard defines the methodology precisely, but cannot force the underlying data to exist. This is the central practical gap between the standard and real-world implementation today.

Section 8.1.3 defines allocation procedures for different scenarios:

  • Shared infrastructure: Allocate by energy or time usage
  • Data transmission and storage: Allocate based on data volume
  • Foundation model: Allocate embodied and pre-training impacts by estimated total inference volumes and the number of derived models built from it
  • Non-foundation model (fine-tuned or distilled): Apply allocations when knowledge transfer, optimisation, or fine-tuning techniques were used
Allocation challenge for open-source models (Appendix II)
When model weights are publicly released, downstream users fine-tune or quantize the base model using diverse hardware. Collecting device-specific power data across a distributed community becomes extremely difficult. IT asset disposition certificates should reference both original and forked projects when forks continue after the original maintainers stop.
09 — The Ripple Effect

AI changes behaviour. Behaviour changes everything.

Explain it like I'm 5
You got a puppy. That one decision caused your dad to build a fence, your neighbour to get allergic, your sister to want one too, and you to buy 50 bags of food over 10 years. None of that was "the puppy" directly — but it all happened because of it. L.1801 calls this the consequence tree — and it is the most intellectually honest part of the whole standard.

Most standards stop at measuring the direct footprint of the system itself. L.1801 goes further, requiring assessment of second- and higher-order effects — the environmental consequences of what AI changes in the world around it. The standard includes a complete worked example directly from Appendix V: a developer using an AI coding assistant. Click each level to expand.

🧑‍💻   A developer uses an AI coding assistant
First Order The AI system's own direct environmental footprint 7 effects + Show
1a
Share of AI system life cycle footprint allocated to this developer by usage
1b1a
Changes in local hardware (terminals, LAN) required due to AI use
1b1b1
Energy to purchase, download, and install the AI application in code editor
1b1b2
Creating libraries, wizards, and inserting project context
1b1b3
Auto-completion and chatbot interactions
1b2
Change in network usage to access AI resources
1b3
Change in data centre use for coding with AI
Second Order What changes in the developer's environment as a result 12 effects + Show
2a1a1
Changes in developer forum traffic (Stack Overflow, GitHub Discussions…)
2a1a2
Evolution in browser-based information search requests
2a1a3
Changes in visits to software documentation libraries
2a1b
Evolution of the reuse of pre-existing code
2a2a1
Changes in messages exchanged between developers
2a2a2
Modification of network exchange resource usage
2a3a1
Changes in how code is tested
2a3a2
Changes in how code is debugged and corrected
2a3b1
Change in time and activities spent generating code
2a3b2
Changes in code execution time and efficiency
2b1
Evolution of security breach risks
2b2
Changes in whether developers choose to use AI for coding at all
Higher Order Systemic changes across the industry and economy 9 effects + Show
3a1
Evolution of awareness and training in use of AI tools across teams
3a2
Use of AI tools other than the one initially adopted (switching behaviour)
3b1a
Change in the nature of the coded elements being built
3b1b
New products made possible in the industry sector by AI-generated code
3b1c
Modified exploration of code application domains
3b1d
Sector-dependent consequences of AI-generated code deployed in production
3b2
Evolution of continuing education for developers through AI-based learning
3b3
Change in customer requirements and product specifications to integrate AI
3b4
Financial effects on companies that employ developers
Other — Non-Carbon Social and human capital effects — mapped even when hard to quantify 4 effects + Show
4a
Gradual decline in expertise in coding without AI assistance
4b
Evolution of autonomy and skill acquisition among junior developers
4c
Changes in workload distribution and effects on developer wellbeing
4d
Evolution of interaction and sharing of best practices on AI among developers
Key insight: L.1801 is the first environmental standard to require mapping what AI causes in the world around it — not just what it consumes itself. Higher-order effects are often impossible to quantify precisely. But requiring that they be mapped, even when they cannot be measured, is a significant shift toward honest environmental accounting.

Section 8.3 applies the methodology from ITU-T L.1480 to assess GHG impacts from the consequences of AI use on third-party processes. Two specific requirements:

  • Identify the user clearly: A specific user or user class must be identified so that second-order and rebound effects can be analysed
  • Precise use case description: The use case must be sufficiently specific to enable evaluation based on actual observed user behaviour — theoretical or hypothetical use cases do not qualify
Rebound effect
When efficiency gains from using AI lead to increased overall consumption that partially or fully offsets the environmental benefit. Example from the standard's Appendix V: AI makes code generation faster → developers build more software → more code runs in production → more compute is consumed. L.1801 requires this to be considered in higher-order analysis, not ignored.

Appendix V provides the complete consequence tree for the developer use case used above. The standard uses this example because AI coding assistants are a broadly applicable, observable use case — and because the vibe coding phenomenon makes it immediately recognisable to the standard's primary technical audience.

10 — What's Still Missing

The standard is honest about its own gaps

Explain it like I'm 5
You wrote the first rules for a brand new board game. It's a good start — but some pieces are missing, some rules need more testing, and a few things you couldn't figure out yet. So you wrote them down honestly, so the next version can fix them. That's exactly what this standard does.

L.1801 is Edition 1.0, approved February 2026. It is notably candid about what it does not yet solve. These are not oversights — they are the research frontier, clearly labelled.

No global aggregation
Explicitly out of scope. The standard cannot tell you how much all AI combined costs the planet. No credible global or national total exists. This is intentional — premature aggregation without rigorous methodology would produce meaningless numbers.
The data transparency problem
Allocation requires knowing total lifetime inference volumes. No major AI company publicly discloses this. The standard defines the method correctly — but cannot force the underlying data to be published or even to exist in accessible form.
Compliance is voluntary
L.1801 is a Recommendation, not a regulation. Organisations can ignore it entirely. Future enforceability depends on regulators — most notably the EU AI Act — adopting it as a mandatory reference standard.
Biodiversity methodology
Listed as "additional consideration" rather than recommended because credible, scalable methods for measuring AI's biodiversity impact at the industry level do not yet exist. Flagged for future development.
Key insight: L.1801 is infrastructure, not a solution. It creates the scientific and methodological foundation that regulators need to write enforceable requirements. The work of turning this into actual environmental accountability — through law, procurement policy, and investor pressure — happens next.

What comes next

Future editions of L.1801 will likely address global aggregation, mandate additional impact categories beyond climate change, and tighten allocation requirements as data availability improves. The EU AI Act is already creating the regulatory context in which L.1801-style methodologies become enforceable. The open-source AI community — where distributed training, community fine-tuning, and indefinite model forks create entirely new allocation challenges — is the specific frontier flagged in Appendix II as requiring further methodological development.