Your AI Bill Became a Reported Environmental Number
Inference you buy from a vendor is a purchased service, which puts it in your value chain inventory. The disclosure duties, the customer questionnaires and the substantiation rules all arrived before anyone in the AI stack started publishing a per-customer figure — so the answer has to be built rather than requested.
The Line Item That Broke the Spend-Based Shortcut
Most corporate inventories are built the cheap way: take the general ledger, bucket spend by category, multiply by an industry emission factor. The method is accepted because it is proportionate for categories where money is a reasonable proxy for physical throughput. Accelerated compute is the category where that proxy fails hardest, because the price of a token has been falling while the energy behind a serious workload has not fallen at the same rate, and because a modest invoice can sit on top of a very large amount of physical work.
The practical result is that a company can double or triple its actual AI-related footprint year over year while the spend-based line in its report goes sideways. That divergence is exactly the kind of thing an assurance provider is being paid to notice, and it is why the guidance direction has been to push material categories from spend-based to activity-based estimation. If AI is core to what you ship, it is a material category, and the inventory needs a real denominator: requests, tokens, GPU-hours, or jobs.
There is a second-order effect worth naming. Once the number is activity-based, it becomes sensitive to engineering decisions — model size, caching, batch versus interactive, retrieval instead of longer context, and how often you re-run an evaluation suite. That is the point. A number that responds to decisions is a management tool; a number derived from invoices is a filing obligation.
Where the Obligations Actually Come From
Value chain emissions reporting
Corporate sustainability reporting regimes require disclosure of material upstream and downstream emissions, with purchased goods and services as the largest category for most software businesses. Purchased model inference, training runs on rented capacity, and the cloud underneath both sit here.
Why it reaches you: The obligation is not AI-specific, which is why it gets missed. Nobody wrote a rule saying 'report your AI'; the existing rule already covers it, and the omission shows up as an unexplained category gap.
Data-centre level reporting duties
Facility-level energy, water and efficiency reporting duties now attach to data centres above size thresholds in several jurisdictions, and utilities and planning authorities have added their own conditions on large new loads.
Why it reaches you: You may not operate a facility, but your provider does, and the resulting published figures become the reference data buyers and journalists compare your claims against. It also means the per-facility numbers you need increasingly exist somewhere public.
Customer and procurement questionnaires
Enterprise buyers push their own inventory obligations down through supplier data requests, and sustainability sections have moved from optional annex to scored criteria in RFPs, sitting beside security and privacy sections.
Why it reaches you: This is the fastest-moving of the three and the one with immediate revenue consequence. It reaches companies far below any statutory reporting threshold, purely through contract.
Green-claim substantiation rules
Consumer-protection and advertising regulators require environmental claims to be accurate, specific and substantiated, with particular scrutiny on neutrality and offset-based assertions and on vague unqualified terms.
Why it reaches you: This is where the exposure turns from a reporting gap into an enforcement matter or a competitor complaint. The claim is made by marketing; the substantiation has to exist in a file that marketing has usually never seen.
Building the Estimate When the Vendor Will Not Give You One
The estimate is a chain of four multipliers, and its credibility comes from documenting each link rather than from precision in any one of them. Start with your own activity data, which is the input you fully control: requests, tokens in and out, model class, and the region each call was routed to. Almost every team already has this in billing telemetry and has never aggregated it for this purpose.
Multiply by an energy-per-unit figure for a comparable model class, taken from published measurements or vendor disclosures, and state the source. Multiply by a facility overhead factor to account for cooling and distribution losses, using the provider's published efficiency figure for the region where one exists and a conservative default where it does not. Multiply by grid carbon intensity for that region and period, preferring a location-based figure as the primary disclosure and reporting any market-based adjustment separately rather than instead.
Then handle training separately from inference. A fine-tune or a pre-training run is a discrete, capital-like event that should be reported in the period it occurred rather than smeared, and an evaluation suite that re-runs on every merge can quietly exceed the training run that everyone remembers. Where you use a general-purpose model you did not train, the training footprint sits upstream in the provider's inventory, and your share of it is properly captured through the service you buy rather than double-counted.
The AI Environmental Disclosure Checklist
Work through this once to produce a defensible baseline, then attach it to the reporting cycle so it refreshes rather than being rebuilt each year.
- ☐Aggregate AI activity data from billing telemetry: requests, tokens, model class, region, period
- ☐Separate training and fine-tuning events from steady-state inference, and count evaluation runs
- ☐Record the region each workload actually executed in, not the region it was configured in
- ☐Identify shadow usage — team-level API keys and embedded features in SaaS you resell
- ☐Set the denominator you will report against: per user, per transaction, or per unit of revenue
- ☐Choose energy-intensity sources per model class and cite them explicitly with dates
- ☐Apply a facility overhead factor and state whether it is provider-published or a default
- ☐Use location-based grid intensity as the primary figure; disclose market-based adjustments separately
- ☐State an uncertainty range rather than a single false-precision number
- ☐Write the method down as a repeatable procedure so next year's figure is comparable
- ☐Send a written data request to each model and cloud provider and retain the response
- ☐Add sustainability data provision to contract renewal terms, not just to the questionnaire
- ☐Request region-level water withdrawal and consumption figures where facilities sit in stressed catchments
- ☐Ask whether reported figures are measured, modelled or allocated, and at what granularity
- ☐Track which providers improved disclosure year over year — it is a procurement criterion now
- ☐Route every public environmental claim about the AI product through the substantiation file
- ☐Avoid unqualified terms such as green, clean or sustainable in product marketing
- ☐Never present offset-based neutrality without disclosing gross emissions and the instrument used
- ☐Do not compare against a manual baseline you never measured
- ☐State scope and period on every figure — a number without both is not substantiated
Frequently Asked Questions
We are below every reporting threshold. Can we ignore all of this?
You can ignore the statutory filing, but not the two channels that reach you regardless of size. The first is contractual: large customers assembling their own value chain inventory push data requests to suppliers, and the request arrives as a condition of the deal rather than as a regulatory notice. The second is advertising law, which has no size threshold at all — if you make an environmental claim about your product, it must be substantiated whether you are two people or two thousand. The pragmatic position for a small vendor is therefore not to build a full inventory, but to build one defensible product-level estimate with a written method, and to keep the marketing language specific. That combination answers the questionnaire and survives the claim challenge, which is the entire exposure at your size.
Isn't AI a rounding error next to our office and travel footprint?
It was, for most companies, until it was not — and the question is answerable rather than rhetorical. Run the activity-based estimate once and compare it to the categories you already report. For a company where AI is a feature used occasionally by staff, it will indeed be small, and documenting that with a method is a perfectly good outcome that closes the question for the year. For a company whose product is model calls in a loop, or one running continuous retrieval and evaluation pipelines, the line frequently lands in the same order of magnitude as the categories that receive real management attention. The failure mode is not being large or small; it is asserting either without measuring, in a report that is increasingly subject to assurance.
How do we handle it when the same feature runs in several regions?
Attribute by where the work actually executed, weighted by volume, and disclose the weighting. This is the single largest source of error in AI footprint estimates because default routing, failover, capacity-driven overflow and multi-region deployments mean the region in your configuration is frequently not the region in your logs. Pull the actual routing data, apply the grid intensity and water intensity for each region separately, then sum. The exercise usually produces an unexpected finding that is worth more than the disclosure itself — a meaningful fraction of traffic running somewhere with materially worse intensity, which is a routing configuration change rather than an emissions reduction programme, and one of the very few levers in this domain that costs nothing.
Our provider says its facilities are matched with renewable energy. Can we report zero?
Not as your only figure. Contractual instruments support a market-based number, and reporting one is legitimate, but frameworks expect location-based figures alongside it precisely because a market-based zero can coexist with substantial physical draw on a carbon-intensive grid at the hour of consumption. Report both, label them, and be careful about the language that travels with the number: 'powered by renewable energy' in product marketing is a claim about physical supply that annual matching does not support, and it is a claim regulators have specifically targeted. Hourly matching is a stronger position where a provider offers it, but that too has to be described accurately rather than compressed into a badge.
Where does water actually show up for a company that only buys API access?
In two places. First, as a value-chain impact you disclose where material, on the same logic as emissions — the cooling water consumed serving your workload is an upstream impact of a service you purchased. Second, and more immediately, in customer questionnaires and in local political risk attaching to the facilities your provider uses. Materiality here is driven by catchment stress rather than by volume, so a modest workload in a water-stressed region can be more material than a large one elsewhere. For most buyers the proportionate response is to identify which regions you route to, check whether those regions are water-stressed, note the provider's published water usage effectiveness where it exists, and record the analysis. Where the answer is uncomfortable, region selection is again the cheapest available lever.
Pull One Month of Routing Data
Before building anything, export a single month of AI calls broken down by model class and by the region that served them. That one table answers the questionnaire, sizes the disclosure, and usually reveals traffic running somewhere nobody chose.
Fix the routing first — it is free, it is immediate, and it is the only step in this entire exercise that reduces the number rather than describing it.