The environmental footprint of artificial intelligence: what ITU-T L.1801 says

Write “environmental footprint of artificial intelligence” and most people picture the model vendor: chips, training runs, hyperscaler data centres. On 6 February 2026, ITU-T Study Group 5 approved a recommendation that moves part of that account elsewhere. ITU-T Recommendation L.1801 (02/2026), Guidelines for assessing the environmental impact of artificial intelligence systems, sets out that a site’s cooling and lighting, during the use of an AI system, are calculated in the stage where that system actually runs — inside the building. That is not a footnote: it is the line that brings the plant room, by name, into the environmental declaration of a system the facility operator did not design.

Where L.1801 comes from, and what it doesn’t do

The recommendation is a joint effort. The Introduction says so directly: “This Recommendation was developed jointly by ETSI TC EE and ITU-T Study Group 5. It was published respectively by ITU as Recommendation ITU-T L.1801 and ETSI Standard [ETSI ES 204 135], which are equivalent in technical content” — developed together by ETSI TC EE and ITU-T Study Group 5, published as L.1801 and as ETSI standard ES 204 135: one text, two reference numbers.

It builds on two earlier recommendations — the life cycle assessment (LCA) methodology of ITU-T L.1410 (equivalent to ETSI ES 203 199), and the method for enabling effects on other sectors of ITU-T L.1480 (equivalent to ETSI ES 204 087) — and states a limit up front: “Aggregation of AI impact on the international, national, or regional level is not part of this Recommendation.” It is built to assess one system, not to produce sector-wide statistics.

Eight life cycle stages, two processes that cut across them

Clause 6.2 takes the eight stages of an AI system’s life cycle from ISO/IEC 22989: inception, design and development, verification and validation, deployment, operation and monitoring, continuous validation, re-evaluation, retirement. Then comes the clarification that matters, verbatim: “Training and inference are not separate AI life cycle stages according to [ISO/IEC 5338], but they are central processes in AI systems.” They have no box of their own: they run through the stages, and L.1801 places them inside the environmental account by a specific rule, not as a bolt-on.

Where initial training and inference land in the environmental account

The operative core, at clause 8.1.1, maps those stages onto the four LCA stages of L.1410: raw material acquisition, production, use, end-of-life. Raw material acquisition holds the impact of the hardware’s materials. Production covers hardware manufacturing plus inception, design and development, verification and validation — and, verbatim, “initial training shall be calculated as part of the LCA production stage.” Use covers deployment, operation and monitoring, re-evaluation and continuous validation, and “inference and continuous learning (as part of re-training) shall be calculated as part of the LCA use stage.” End-of-life holds the hardware’s end-of-life treatment and the system’s retirement.

On transparency: “It is required that the training impact is also reported separately for full transparency.” On the reliability of the figure: “Since initial training can be measured and an accurate figure provided but continuous learning will be based on estimated figures (using assumptions), these shall be reported separately.” Initial training is measured; continuous re-training is estimated: the two figures do not get folded silently into one total.

The two lines that concern whoever runs the hall

This is where the recommendation steps inside the building. The first: “AI system installation and maintenance, as well as site specific support activities (e.g., cooling systems, lighting, etc.) during use shall be calculated for the LCA use stage.” Installing and maintaining the AI system, and the site’s specific support activities — cooling, lighting — during use, are calculated in the use stage of the life cycle. Cooling is not a line item sitting outside the AI’s environmental account: it is inside it.

The second concerns whoever hosts several clients under one roof: “In shared infrastructure use, full life cycle impact of the infrastructure shall be allocated to the users according to their usage.” In every colocation, that means the impact of the building — not only of the AI hardware it hosts — has to be split among tenants by a usage-based criterion, not a flat estimate.

How we check it

When we write a specification for a hall that will host third-party AI workloads, the first question is not which server goes in, but which meter measures what, and by what criterion the shared infrastructure gets split among clients. In the specifications we write and check that criterion becomes a clause fixed before the fact, not negotiated afterwards: measurement point, the boundary of the plant allocated, a clear line between measured and estimated data. At acceptance, we verify that the declared meter actually exists at the declared point, and that the record — as-built, position, share — is the kind a client can carry into their own declaration, not a verbal promise.

See the service · Talk to an engineer

What changes for whoever runs a machine room

One last warning in the text, verbatim: “Multiple AI systems in the assessment may become very complex with agentic AI, especially if multiple agents are involved.” For a multi-tenant hall that is, before any calculation, a question of scope.

The practical consequence is that the client who has to declare their AI system’s footprint depends on data they do not hold: cooling and lighting are measured by whoever runs the hall, not by whoever brings the workload into it — the same hall we wrote about when covering availability classeshe right point, not one master meter divided up after the fact; an allocation criterion fixed before the first client arrives, not renegotiated at every tender; and a record of which share of which plant is attributed to whom. A data centre that cannot answer is not in breach: L.1801 is an international technical recommendation, not a law — a different declaration from the mandatory energy one we’ve already covered the energy declaration we have written about. But it is a data centre a client cannot put into their own account, and at tender that shows.

What to write in the specification, what to check at acceptance

In the specification: the hosting contract states which allocation criterion for the shared infrastructure applies, against which measured quantity — not a flat estimate. The measurement point needs specifying: what is counted upstream and downstream, and which site plant falls inside the allocated share. Cooling and lighting should be required as measured and attributable, not derived from an average annual ratio. The data handed over should distinguish what is measured from what is estimated: the recommendation requires them reported separately.

At acceptance: check that the declared meters actually exist at the declared points, that the allocation criterion is the one written down — not a more convenient one introduced along the way — and that the as-built record holds the position and boundary of every meter, in the same logic as the single map of the infrastructure we’ve covered elsewhere. Without that register, the same declaration is not repeatable the following year.

Two threads, applied to this account

First thread: the allocation criterion and the measurement requirements become verifiable lines in the specification and acceptance checkpoints, with the record a client can exhibit to build their own declaration.

Second thread: meters, allocation criterion and as-built records stop being scattered files for each client. Together with CSIDIA, the group’s other company, they become a single map of the infrastructure: which meter covers which plant, which share is attributed to which client — the same data needed when someone asks about an anomalous consumption figure, and the one an AI runs diagnostics on while the crew acts. Within the client’s own perimeter: on-premise, on autonomous machines with no deep integration into the existing network, or a dedicated cloud with a data centre in Italy, always with shared management.

Do you host third-party AI workloads and need a defensible allocation criterion, or need to check whether your current meters can support one? Talk to an engineer: the site visit costs nothing, and the measurement point gets designed before the next client, not after.