The carbon footprint of software and AI compute is rarely measured, so it cannot be managed

Why this is its own facet

The parent issue is the size and growth of computing's footprint. This facet is narrower: the measurement and attribution gap that must be closed before any reduction can be verified. What is not measured cannot be managed, and today most compute emissions are estimated after the fact, at organisation level, if at all.

Observable evidence

The standard developer and ML workflow surfaces latency, dollar cost and accuracy — almost never emissions. Inference is now the dominant share of AI compute (roughly 80–90%) and is projected to be the majority of AI energy demand by 2030, pushing the footprint into everyday production traffic rather than one-off training runs.

The transparency gap

Most closed model providers do not disclose enough about model size, hardware or data-centre efficiency to estimate energy or carbon reliably (MIT Technology Review, 2025). Grid carbon intensity also varies widely by region and by hour, so the same computation can carry very different emissions depending on where and when it runs.

Current vs desired state

Today: after-the-fact, org-level estimates. Desired: a per-run, per-service or per-request figure available at the moment of the engineering decision, so compute can be optimised for carbon the way it is already optimised for cost and latency.

Impact if unaddressed

Absolute demand is rising even as per-task efficiency improves. Without a number attached to the work there is no baseline, no feedback loop, and no way to tell whether an optimisation helped. Reduction stays aspirational.