An AI app depends on models, infrastructure, chips, and energy. Scope 1, 2, and 3 emissions describe those dependencies from a particular organization's point of view, so understanding whose footprint we are reading comes before comparing the numbers.
An AI app depends on models, infrastructure, chips, and energy. Scope 1, 2, and 3 emissions describe those dependencies from a particular organization's point of view, so understanding whose footprint we are reading comes before comparing the numbers.
This retrospective entry occupies the October 23 archive slot and was first published on October 27, 2026. It was prepared from research assembled on October 24 and includes the October 16 standards update.
Follow an AI application far enough and the chat window becomes a building, a rack of machines, a chip factory, and a power plant. That is what I want the AMICE stack to make easier to explore: Applications, Models, Infrastructure, Chips, and Energy.
Carbon accounting adds another question to that journey. Whose emissions are these?
The company making an application, the company operating its model, the data center operator, and the electricity generator can all report emissions associated with the same work. Reading their reports as separate pieces to add together would count some emissions several times. Reading only the app company's direct emissions could miss much of the physical system underneath it.
The GHG Protocol Corporate Standard establishes organizational boundaries before assigning emissions to scopes. Its 2004 revised edition describes equity-share and control approaches in Chapter 3, including financial and operational control. Ownership, leases, and operating arrangements determine which emissions belong in the inventory. A familiar logo on a building does not settle the accounting boundary.
The Corporate Standard and its 2015 Scope 2 amendment distinguish three scopes:
For an AI service using somebody else's infrastructure, much of the computing footprint may therefore sit outside its own Scope 1 and 2. Moving a workload to a supplier changes the reporting relationship; it does not make the underlying activity disappear.
Consider a simplified electricity supply chain. This is an accounting illustration, not a claim that a particular AI request followed this route.
| Reporting organization | How the same electricity-generation emissions can appear |
|---|---|
| Generator burning fuel | Scope 1 |
| Data center operator purchasing the electricity | Scope 2 |
| Business purchasing the resulting cloud service | Scope 3, usually purchased goods and services |
An app buying a model API adds another commercial relationship. Whether the model provider runs its own servers, rents a controlled facility, or purchases a cloud service affects its inventory. We need the actual arrangement before assigning categories.
The GHG Protocol's Scope 3 FAQ, pages 20–21, explains why this overlap is inherent to value-chain accounting. It supports action by several organizations with different opportunities to reduce emissions. It also means their inventories should not be summed into one supply-chain footprint. Avoided-emissions comparisons belong outside the inventory, with a stated baseline and method.
AMICE's layers and the three scopes are two different views of the system. A chip can have manufacturing emissions and electricity-use emissions. An application company can have direct emissions as well as supplier emissions. There is no rule that applications are Scope 3 while energy is Scope 1.
A data center draws power from an electricity system that changes over time. It may also purchase renewable electricity attributes through contracts. Those are related facts, but they answer different questions.
The 2015 Scope 2 Guidance, especially pages 25–26 and 59–60, distinguishes location-based accounting, using the average emissions intensity of a defined grid, from market-based accounting, reflecting qualifying contractual instruments and supplier information. Companies operating in markets with the relevant contractual information generally report both.
Those figures are alternatives, not two amounts to add. A low market-based result does not mean the building physically received carbon-free electricity every hour. Annual matching, hourly matching, and the generation mix at a particular place should remain separate fields.
The rules are also evolving. GHG Protocol's October 16, 2026 update describes hourly matching, deliverability, and other questions still under development. They are proposals, not requirements that can quietly be applied to every existing report. The joint GHG Protocol–ISO corporate standard is planned for 2028.
Electricity is only part of the picture. Making chips, servers, cooling equipment, and buildings creates emissions before those assets serve a model.
There is a useful accounting wrinkle here. The Scope 3 Standard, page 39, puts purchased capital goods' cradle-to-gate emissions into the corporate inventory in the acquisition year. It does not depreciate those emissions over the equipment's financial life.
A model estimating one workload's lifecycle footprint might instead allocate a share of equipment production over an assumed useful lifetime and expected usage. That can be useful, but it is a different calculation. The lifetime, utilization, allocation rule, included equipment, and exclusions need to travel with the result. We cannot mix a year's capital purchases with an allocated task estimate and call the combination consistent.
The same distinction applies to operational versus embodied emissions. Those labels describe lifecycle stages; they are not replacements for scopes.
Alphabet's 2025 environmental metrics assurance letter, dated June 22, 2026, gives a concrete example. Appendix A, printed page 3, reports these figures in metric tons of CO2 equivalent:
These cover global Alphabet, including subsidiaries, under an operational-control boundary. They are not Gemini's footprint. The selected metrics received limited assurance; the methods still include estimates. Scope 1 and 2 are rounded to hundreds, Scope 3 to thousands. Google's separately discussed ambition-based footprint uses different adjustments and boundaries, so it should not replace this inventory without explanation.
NVIDIA's FY2026 Sustainability Report, printed page 30, reports Scope 1 of 9,822, market-based Scope 2 of 568, and location-based Scope 2 of 308,891 metric tons CO2e. Its Scope 3 table reports 10,700,940, with categories 1–8 listed. The period runs from January 27, 2025 to January 25, 2026. These are company disclosures, not a Blackwell chip footprint or a measurement of an AI task. The report also notes methodology changes affecting earlier figures.
The point of these examples is to read the boundaries, not rank two very different businesses. Amazon's July 2026 methodology, pages 2–3 also says its reported Scope 1 and 3 reflect the use of certain environmental attribute certificates. A field labeled only “emissions” would lose that distinction. Offsets, removals, contractual adjustments, and gross inventory amounts need their own treatment rather than a single unexplained net number.
For choosing how to use AI, I want to get closer to the work being completed. A cheaper token is a price. It does not tell us how much energy the model uses, how many tokens it needs, or how often it retries.
Training, fine-tuning, evaluation, and inference should be recorded separately. An agent may make several inference calls, invoke tools, repeat failed work, and leave services running between calls. A comparison needs a defined task and a quality or success criterion, along with the model version, configuration, input and output lengths, and retries.
The measurement boundary determines what is included. GPU energy alone omits other parts of a server and facility. A whole-facility allocation needs to explain shared resources and idle capacity. Electricity emissions then require a compatible time, location, and accounting basis. Hardware production needs a separate allocation model if it is included.
Provider tools can help without resolving every question. Google Cloud's methodology explicitly allocates provider Scope 1, 2, and 3 emissions into customers' Scope 3 reporting. It also says customer-specific results are not third-party assured and documents exclusions. An allocated cloud estimate is more specific than a company total, but it is not automatically telemetry for one model response.
The next addition to the AMICE explorer should make these disclosures inspectable beside the existing relationships. Select a reporting organization, choose a period, and see the reported scopes, electricity basis, source page, methodology, and missing information.
Location-based and market-based results should sit beside each other. Operational and embodied boundaries should be visible. Company-reported estimates should be labeled as such, and an undisclosed allocation should stay unknown rather than become zero. Downloads should preserve those qualifications.
That would help answer both “What does this company disclose?” and “What would we still need to estimate this task?” without pretending they are the same question. The useful destination is a clearer route through the evidence, including the point where it stops.
The company figures and methods here were checked on October 27, 2026. Reporting boundaries, allocation methods, and the proposed Scope 2 rules can change. None of these company totals establishes the emissions of an individual AI task.