Nobody Regulates Your Energy Use. Your Biggest Customer Does.

How a Rule You Are Exempt From Becomes Your Problem

Corporate climate reporting frameworks share a structure. They separate direct emissions, purchased energy, and everything else in the value chain — and the third category is where purchased software and cloud services sit. A large enterprise reporting under any of the major regimes has to produce a number for that category, and it cannot invent one for its supplier base.

So the requirement propagates. It shows up not as legislation naming small vendors but as a new section in a procurement questionnaire, a supplier code of conduct amendment, or a renewal conversation where someone asks a question your team has never been asked before. The obligation is contractual and commercial rather than regulatory, which makes it easy to dismiss right up until it blocks a renewal.

AI made this specific rather than generic. Software used to be a rounding error in a supplier footprint. A product whose core loop invokes large models at volume is a visible line, and buyers with sustainability targets have begun treating AI-heavy vendors as a category worth asking about directly.

Three Places Your AI Consumes Energy

The public conversation fixates on training, which is largely somebody else's expenditure. For most product companies the distribution looks different.

• Inference at scale is the dominant term for a shipped product. Each request is small; the aggregate across a live user base usually is not, and it grows with adoption rather than with your engineering activity.
• Pipelines you forgot are running — nightly re-embedding of an entire corpus, evaluation suites executing on every commit, background enrichment jobs on data nobody reads. These often out-consume the user-facing feature.
• Fine-tuning and experimentation is lumpy and visible in cost, which means it draws attention disproportionate to its share.

What a Defensible Number Looks Like

Nobody expects a metered figure. What passes review is a stated method, applied consistently, with its assumptions visible. The general shape is activity data multiplied by an energy intensity assumption multiplied by a grid emissions factor, adjusted for infrastructure overhead.

1. Activity data. Token or request volume by model, which your billing records already contain. This is the one input you can measure exactly, so measure it.
2. Energy intensity. An assumption per unit of work for each model class. Use your provider's published figures where they exist and a cited public estimate where they do not — and say which you used.
3. Location. Grid carbon intensity varies enormously by region, so the same workload has materially different emissions depending on where it runs. If you do not know which region serves your inference, that is worth finding out for reasons beyond reporting.
4. Overhead. Data center efficiency factors account for cooling and facility load. Providers commonly publish an efficiency figure you can apply.
5. Document the whole thing on one page. The artifact that answers a questionnaire is the method plus the caveats, not a bare number in an email.

Be explicit that the result is an estimate with a stated uncertainty. Presenting a modeled figure with false precision is worse than presenting a range, both for credibility with a sophisticated buyer and for exposure if the number is ever challenged.

The Marketing Claim Is the Real Near-Term Risk

Failing to have an emissions estimate costs you a deal. Publishing an environmental claim you cannot substantiate costs you considerably more. Consumer protection authorities treat green claims as ordinary advertising claims requiring support, offset-backed neutrality assertions have attracted specific scrutiny and litigation, and some jurisdictions have moved to restrict unqualified neutrality language altogether.

The failure pattern is predictable. A marketing page says "sustainable AI" or "carbon neutral infrastructure" because it reads well and someone found an offset provider. There is no calculation behind it, the offsets cover a fraction of the actual load, or the claim covers only the corporate office and not the compute. When a competitor, journalist or regulator asks for the basis, the company discovers it has none.

• Prefer specific to sweeping: "we route inference to a region with lower grid intensity" is substantiable; "green AI" is not.
• Say what is covered: a claim about corporate operations that reads as though it covers your compute is the classic overstatement.
• If you rely on offsets, say so plainly and describe them. Neutrality achieved by purchase is a different statement from reduction achieved by engineering, and readers are entitled to know which one they are being told.
• Keep the file. The substantiation should exist before the claim publishes, not be assembled after someone asks.

The Reductions Worth Making Anyway

The unusual feature of this area is that nearly every meaningful reduction also cuts cost and latency. That makes the work easy to justify without appealing to sustainability at all, and it means a company that has been optimizing spend already has most of the story.

• Right-size the model per task. Routing classification and extraction to a small model while reserving a frontier model for genuinely hard work is the single largest lever most products have.
• Cache aggressively. Repeated identical requests are pure waste, and many production systems generate more of them than their authors believe.
• Trim context. Stuffing a large context window because it is available consumes proportionally, often without improving the output.
• Delete the dead pipelines you found in the exercise above.
• Do not call a model for deterministic work. A regular expression, a lookup table or a database query costs a rounding error and is more reliable.

Frequently Asked Questions