What Are the Scope 3 Emissions of AI, and How Should You Estimate Them?

The emissions behind the AI your company buys are reported by you and measured by somebody else, and the method most companies use to bridge that gap works less well for AI than for anything else in the category.

The electricity is consumed in a data center you do not own, so it never reaches your energy bill. The emissions return to you as scope 3, category 1, the line that already carries your software licenses and your professional services. How that line gets calculated varies. Where a supplier publishes figures, companies use them, and the cloud platforms now do. Where none exist, the standard fallback is to multiply what you spent by an industry emissions factor. That is how most companies handle purchased services, and how a company buying models through an API will usually end up treating AI. That is also where the difficulty starts, because there is no industry factor for AI.

How much that missing factor costs you depends on scale. Where AI spending is small next to travel and buildings, an industry average is a proportionate answer, and the same one you are applying across the rest of the category. The calculation only starts to distort the total once the spending is large. That is the position of companies running AI across a workforce or building it into a product, and those are the companies the rest of this is written for.

Why Is Spending a Poor Guide to AI Emissions?

With no factor for AI to reach for, companies fall back on the published sets built from national accounts. In the United States that means the EPA supply chain factors, and for European reporters EXIOBASE, with regional equivalents elsewhere. Between them they cover from around two hundred to just over a thousand industry categories, priced in emissions per unit of currency spent. None of those categories is AI. Spending on it gets mapped to whichever sits closest, usually computer or data processing services, so the number attached to your AI is an average for a whole industry, drawn from economic data assembled before most of the AI buildout happened.

That approach holds up elsewhere because, for most things a company buys, cost and energy move together. A ton of steel takes roughly the energy it takes, whoever produced it. AI is less predictable. The International Energy Agency reports that a simple text prompt, where the model answers a question in one pass, now draws less electricity than a television running for the same length of time. At the other end sit reasoning models, which generate long internal workings before replying, and agentic tasks, where the model runs many steps in sequence and calls tools as it goes. Those can use hundreds or thousands of times more energy for a single request. Two companies with the same AI invoice can therefore be causing very different amounts of electricity to be burned, and a spend-based calculation returns the same figure for both.

The underlying ratios also move faster than the data describing them. Energy use per task has been falling by at least an order of magnitude a year, so any factor resting on figures gathered a year or two ago describes an industry that has since moved on. And where a company might keep a steel supplier for a decade, teams change AI models often, for capability or for price. A switch of that kind can change the energy behind a workload while the invoice stays much the same, and the person preparing the disclosure is not always told that it happened.

How far wrong a spend-based figure ends up being is hard to establish across a whole market, though one attempt has been made to measure it. Guillermo Llopis, in a working paper on AI inference, runs both methods over the same usage and finds the spend-based result coming out ten to forty times higher than a calculation built from electricity. The reason he gives is that an API price carries the vendor’s margin and the cost of developing the model, neither of which has a physical counterpart when your query runs. That is one unreviewed estimate rather than a settled finding, but the direction is the part to take seriously. The invoice contains a great deal that the electricity does not.

The same paper is careful about what those multiples mean in absolute terms. Worked through for a 200-person European firm, the whole AI inventory still lands under a tonne of CO2e, and almost all of that comes from the spend-based figure attached to one bundled SaaS subscription. The argument is not that AI emissions are secretly enormous. It is that the number most companies will file is the least defensible one they could have produced, and that the case for measuring properly is auditability rather than tonnage.

What Emissions Data Will AI Providers Give You?

If spending is a poor guide, the alternative is to get measured figures from the supplier. What you can get depends on who the supplier is. The cloud platforms now report emissions against your account. AWS added scope 3 to its customer figures in October 2025, and Google Cloud’s Carbon Footprint separates market-based and location-based emissions. Microsoft’s Emissions Impact Dashboard covers Azure and Microsoft 365 across all three scopes. None of them separates the AI from the rest of your usage, so what you receive is one cloud total with model training and inference somewhere inside it.

Go direct to a model vendor and there is currently nothing at account level to be had. Google has published a per-prompt methodology for Gemini, putting a median text prompt at 0.24 watt-hours and 0.03 grams of CO2e. That is the most detailed public work of its kind and still an average for a consumer product, market-based and limited to text. As far as we can establish, no major model vendor reports emissions attributed to a particular customer’s usage, so a request for one should be expected to come back empty. That is worth knowing in advance. A vendor that has not built per-customer measurement cannot produce it because a customer asked, and pressing for a figure it does not hold tends to produce an estimate presented as a measurement. What the conversation can establish is what the vendor publishes today and whether account-level reporting is planned. Terms are most easily revisited at renewal, so that is the moment to write in a requirement that takes effect if the capability arrives.

The capability may arrive sooner than the renewal cycle suggests. Shareholders at Amazon, Meta, and Alphabet have filed proposals asking how those companies will meet their climate commitments given the electricity demand of AI and data centers. Those three build the data centers and, for Alphabet and Meta, the models as well, so they sit on both sides of the market. Proposals of that kind do not ask for customer reporting directly. Companies under scrutiny for their own emissions do tend to respond with fuller disclosure, and the tools they hand their customers are part of how they demonstrate it, and that is the route AWS took when it expanded its customer reporting last October. The pure model vendors are privately held, so no shareholder mechanism reaches them. Pressure on the platforms may still reach them at one remove, and the reason is that disclosure practice here has tended to spread from whoever moves first, and once account-level reporting exists anywhere, the vendors still withholding it will stand out.

How Should You Estimate AI Emissions from Usage?

The cloud total, whatever it blends together, is at least a measured figure that can go into the disclosure as supplied. For AI bought through an API, estimating is unavoidable at present, and the improvement available is to estimate from what you consumed rather than what you paid. That means taking the tokens or compute hours from your billing records and multiplying them by a published energy figure for a comparable model, adjusted for the carbon intensity of the grid where the work ran. That approach has a standard behind it in ISO/IEC 21031, the Software Carbon Intensity specification, which expresses emissions per unit of software use and treats an API call as a legitimate unit.

The energy figure is the term to settle first, since few vendors publish one for their own models. Independent benchmarking covers some of the gap. The AI Energy Score leaderboard measures GPU energy per thousand queries across a range of models and tasks, and its reasoning results put reasoning models at roughly thirty times the energy of non-reasoning ones. Those tests run on standard hardware with standard prompts, so the number describes the model rather than your particular use of it. It is still a far closer starting point than a figure derived from your invoice.

Two record-keeping habits keep that calculation defensible, and both use material you are already given. Export the usage report your provider already produces, every month. This is not a carbon report and does not need to be. What you want is the consumption data every billing dashboard shows, tokens or compute hours broken down by model, and that is the first term in the calculation above. Kept monthly, it records what you ran and when that changed. Then write down which energy figure you used, and when it was published. Whether it came from a vendor disclosure or a public benchmark, record the source alongside the figure itself. These figures date quickly, and a dated source lets next year’s reviewer see why your number moved without assuming an error.

Who Should Own the AI Emissions Figure?

Nobody is asking companies about their AI emissions yet, so it is fair to wonder whether monthly usage exports and dated assumptions deserve the effort. The question arrives in another form, as an auditor asking how the purchased services category was calculated, or an investor wanting to know why the number went up. Answering either means describing a method and defending the inputs. That is possible from records kept while the year was running, and close to impossible from an annual invoice afterwards.

Records only get kept, however, if they are somebody’s responsibility. In most companies the figure belongs to whoever signs the disclosure, which means the chief sustainability officer or the CFO. Neither tends to hear when a team switches model or provider, and that is the very change that moves the energy behind a workload while the invoice stays flat. Closing that gap requires no new role, only an agreement that when those choices change, sustainability is told, in the same way finance is told when a material contract changes.

Wherever responsibility for the figure lands, the role has changed shape. Reporting a category used to be the whole of it. The moment somebody examines the number, being able to explain how the category was built comes with the role as well. Sustainability leaders are expected to hold their own with technology and procurement in ways their predecessors were not, and finance executives who have inherited the reporting are expected to show a technical grasp that was never in the position specification. Stanton Chase’s Sustainability and ESG Practice works with boards and executive teams on exactly this problem, whether that means defining what the role now demands before anyone is appointed to it, or finding and assessing the people who can meet it. That sits alongside our work on board services, executive assessment, leadership development, and succession planning.

About the Author

Christian Ehl is a Partner at Stanton Chase Düsseldorf and the firm’s Global Functional Leader for Sustainability and ESG. He has more than twenty years of experience in executive search and leadership advisory. Christian began working on sustainability in 2004, when he wrote his thesis on corporate social responsibility, and he has since built a network of candidates across the field. He is the author of several sustainability white papers and articles, and he supports clients moving to more sustainable business models with the right people in place. He completed a coaching certification in systemic and change coaching in 2008. Christian holds a degree in international business administration from Accadis Business School and a further degree from the University of Newcastle.