Bar chart comparing AI carbon footprint per request across Texas and cleaner grid regions

The same AI request to the same model on the same hardware emits 0.4 grams of CO₂ in Sweden and 3.2 grams in Texas. That is 8.5 times the emissions for identical output, and until this month you had no way to see it. Swedish provider Berget AI has now published an open-source method, built with the Stockholm Environment Institute, WattTime and Klimatkollen, that calculates emissions request by request instead of multiplying an average by a guess.

For manufacturers reporting on Scope 2 and 3, that changes what you can put in a supplier questionnaire. Region selection turns out to be the biggest lever you control, especially for open-weight models that run anywhere. Here is what the numbers actually say, and how to turn them into a procurement requirement.

Your CSRD Report Covers Every Machine on the Floor, Except Your AI

You can tell me the kilowatt-hours your injection moulding line drew last Tuesday. You can tell me the energy intensity per unit shipped, broken down by shift. Ask what your quality team’s AI inspection tooling or your document-processing models emitted over the same period, and the answer is a shrug or a vendor sustainability PDF with no numbers in it.

That gap is not sloppiness on your side. Buyers rarely get emissions figures from AI providers at all, and the public estimates that circulate are outside-in averages calculated by people with no access to the actual infrastructure. Berget AI’s Christian Landgren is blunt about what those are worth:

Most of the alarming figures about AI’s footprint come from multiplying an average by a guess at the volume, and nobody can check them.

Unverifiable numbers cannot go in a CSRD disclosure. So they go nowhere.

Factory energy dashboard showing kilowatt readings per production line with AI carbon footprint column empty

What Berget AI Actually Released, and Who Verified It

On 21 October 2026, Berget AI published the calculation method itself, not a report about it. It is open source and free to use, developed with researchers from the Stockholm Environment Institute and the non-profits WattTime and Klimatkollen. Berget customers see emissions accumulate request by request in the console as they use the service.

Two design choices matter for procurement. The figures are location-based, using the average grid mix where the servers physically run, so no renewable energy certificates are netted off. And the method includes emissions from manufacturing the hardware, not just the electricity it draws. The stated goal is to get other providers reporting per-request emissions so buyers can compare on data instead of marketing claims.

The numbers: 0.4g in Sweden, 1.6g Ireland, 2.5g Germany, 3.2g Texas on Kimi K3

A typical request to the open model Kimi K3 produces roughly 0.4 grams of CO₂ in Sweden, 1.6 grams in Ireland, 2.5 grams in Germany and 3.2 grams in Texas. Identical hardware, identical model, identical prompt. The only variable is the grid.

Ireland at four times Sweden is the figure worth sitting with, because a lot of European enterprise AI traffic already lands there by default. Nobody chose that for carbon reasons. It happened because that is where the capacity was.

Why averages failed: Landgren on multiplying an average by a guess at the volume

The method calculates each request separately rather than applying a blanket figure, because the result shifts with the model, the time of day, and whether part of the prompt is cached. An average flattens all three. Berget’s CTO and co-founder is blunt about what that produced:

Most of the alarming figures about AI’s footprint come from multiplying an average by a guess at the volume, and nobody can check them. The only fair comparison is to calculate each request and add them up. We have published our judgement calls so anyone can check and use them.

Published judgement calls are the part your auditor will care about. An unverifiable estimate does not survive assurance. A documented method you can inspect does.

Why Open-Weight Models Make Region a Buyer’s Choice, Not a Vendor’s

A 3.2 gram figure is trivia unless you can move the workload that produced it. With open-weight models you can. They run in any data centre with the right hardware, which means the grid behind your inference is something you specify rather than something you inherit.

This is no longer a fringe share of traffic. Open-weight models accounted for 29% of tokens on Vercel’s AI Gateway in June 2026, up from 11% in April. That is more than doubling in two months, and it is the portion of your AI spend where region is genuinely negotiable.

Where the lever exists: inference workloads you can relocate

Look for batch and asynchronous work first. Supplier document extraction, non-conformance report classification, overnight summarisation of inspection logs, CAPA drafting. None of these care whether the response lands in 200 milliseconds or two seconds, and none of them require a frontier model to do well.

For these workloads, region becomes a line in the contract. You specify the data centre, you get location-based emissions per request, and you can put a real number in your Scope 3 reporting instead of a vendor’s marketing claim. The same model on the same hardware in a cleaner grid costs you nothing in output quality.

Where it doesn’t: proprietary models and latency-bound use cases

Closed frontier models give you no choice. The vendor decides the region, and you take whatever grid mix comes with it. If part of your stack depends on a proprietary model for capability reasons, accept that and stop pretending the sustainability conversation is open there.

Latency-bound cases are the second limit. Real-time vision inspection on a line, operator-facing copilots, anything where a round trip to a distant data centre breaks the interaction. Those stay close to the plant, and the local grid is what it is.

Split your AI inventory into these two buckets. The movable half is where the AI carbon footprint work actually pays off.

Chart comparing the AI carbon footprint of one open-weight model deployed across clean and coal-heavy regions

What Operations and Quality Leaders Should Do in the Next 90 Days

Start with an inventory. List every AI workload running in your plant and your back office, and next to each one write the provider and the data centre region. Most teams cannot fill in that second column, which is the first finding worth having.

Then test one thing: whether your inference can be routed to a lower-carbon grid without a rewrite. If you are calling an API and the provider offers regional endpoints, this is a configuration change, not a project.

Three questions to put in your next AI vendor RFP

Ask for per-request, location-based emissions figures in writing. Ask which physical region each workload runs in and whether you can specify it. Ask whether the provider’s calculation method is published and independently reviewed, the way Berget AI’s was with SEI, WattTime and Klimatkollen.

Vendors who answer with a sustainability brochure instead of numbers have told you something useful. As Berget’s Christian Landgren put it, “The only fair comparison is to calculate each request and add them up.” Treat anything else as an estimate, and label it that way in your reporting.

Mapping which workloads are region-agnostic and which aren’t

Not everything can move. Vision inspection running on the line stays on the line. Latency-sensitive control loops stay close to the equipment. But document extraction, supplier correspondence, CAPA drafting, non-conformance summarisation and most batch analysis have no geographic constraint at all beyond data residency rules you are already meeting.

That batch tier is usually the bulk of your token volume and the cheapest thing to relocate. Nordic and other European regions are frequently cost-competitive on compute, so moving it rarely carries a price premium. You are trading a config value, not a budget line.

The payoff is procurement speed. When sustainability review asks what your AI inspection rollout emits, a verifiable per-request figure closes the question in a meeting instead of parking the project for a quarter. That is the real return on measuring your AI carbon footprint.

Ready to find AI opportunities in your business?
Book a Free AI Opportunity Audit. It is a 30-minute call where we map the highest-value automations in your operation.

Per-Request Reporting Becomes Table Stakes Before Demand Catches Up

The International Energy Agency projects data-centre electricity consumption to more than double, to roughly 945 TWh by 2030, with AI as the principal driver. Somya Joshi, Research Director at the Stockholm Environment Institute, makes the point that matters for planning:

Any promise of efficiency gains is likely to be outweighed by higher demand, negating any emission reductions from renewables.

Read that as a procurement warning, not a climate headline. Model efficiency improves every quarter and your token volume will grow faster. Waiting for better models to solve your AI carbon footprint means the number goes up while you wait. Grid location is the only variable you control that cuts emissions immediately and does not depend on anyone shipping a new release.

There is a practical reason to measure now rather than in 2028. Whoever sets up per-request measurement first establishes the baseline their customers, auditors, and competitors get benchmarked against. If your automotive or pharma customers start asking for AI emissions in their supplier questionnaires, having two years of request-level data makes you the reference point. Having a vendor PDF makes you the laggard.

What to expect from vendors who still refuse to publish figures

They will offer a market-based number instead, netted down with renewable energy certificates bought somewhere other than where the servers run. They will cite a company-wide PUE figure that tells you nothing about your workload. Some will say per-request attribution is technically impossible, which is now provably false because the method is open source and free for anyone to adopt.

Treat continued refusal as information about the vendor, not about the difficulty of the problem. A provider that cannot tell you which region served your inference also cannot tell you much about data residency, latency variance, or capacity planning. Those are the same visibility gaps.

Put a date on it. Ask for per-request figures in the next contract cycle, and if the answer is still an average or a promise, move the open-weight portion of your traffic to a provider that publishes.

Source: berget.ai

Leave a Reply