Scope 2 emissions account for the indirect carbon from the electricity your AI workloads consume. You must calculate this using both a location-based method (using the grid's average carbon intensity where your data center operates) and a market-based method (using the carbon intensity of the specific renewable energy contracts your provider has purchased). Tools like the Cloud Carbon Footprint project automate these calculations by pulling energy data from AWS, Google Cloud, and Azure APIs, applying the correct regional emission factors. This data is foundational for Setting Up a Carbon Footprint Baseline for Your AI Portfolio.
Guide
How to Calculate Scope 2 and 3 Emissions for AI Workloads
Go beyond direct energy use to account for the complete carbon footprint of your AI operations. This advanced guide details methodologies for calculating Scope 2 emissions (purchased electricity) using location-based and market-based methods, and Scope 3 emissions (embodied carbon in hardware, cloud provider infrastructure). We'll use real-world examples with cloud carbon footprint tools and discuss allocation strategies for shared resources.
Go beyond direct energy use to account for the complete carbon footprint of your AI operations. This advanced guide details methodologies for calculating Scope 2 emissions (purchased electricity) using location-based and market-based methods, and Scope 3 emissions (embodied carbon in hardware, cloud provider infrastructure). We'll use real-world examples with cloud carbon footprint tools and discuss allocation strategies for shared resources.
Scope 3 emissions are the most complex, covering all other indirect impacts. For AI, this includes the embodied carbon in your GPU hardware (manufacturing, shipping) and the upstream emissions from your cloud provider's infrastructure buildout. Calculate hardware emissions using lifecycle assessment databases or APIs like Boavizta. For cloud infrastructure, you must apply an allocation strategy (e.g., based on vCPU-hours) to your provider's reported corporate Scope 3 data. Integrating these figures is critical for comprehensive AI Energy Scoring and Standardized Disclosure and requires robust Automated AI Energy Data Collection.
EMISSIONS ACCOUNTING
Key Concepts: GHG Protocol for AI
Master the GHG Protocol's framework to measure the complete carbon footprint of your AI workloads, from purchased electricity to the embodied carbon in your hardware.
03
Scope 3: Cloud Provider Infrastructure
This is a critical, often overlooked Category 3: Fuel- and Energy-Related Activities emission. When you use cloud services, you are responsible for a share of the emissions from the construction and operation of the cloud provider's data centers.
- Cloud providers are increasingly disclosing these infrastructure carbon factors.
- Calculation requires allocation. You must allocate a portion of the provider's total data center emissions to your specific usage, typically based on your share of energy consumption or compute time. This moves your accounting beyond just the electricity your VMs use (Scope 2) to include the carbon cost of the building, cooling systems, and networking gear that enable your workloads.
~10%
Of cloud emissions can be infrastructure
04
Allocation Strategies for Shared Resources
A core challenge in Scope 3 calculation is fairly dividing emissions from shared resources (e.g., a GPU cluster used by multiple teams/models). Use these standard allocation methods:
- Time-based: Allocate emissions based on the duration of exclusive use (e.g., GPU-hours). Best for training jobs.
- Utilization-based: Allocate based on average hardware utilization (e.g., % of GPU memory or SM activity). More accurate for inference workloads.
- Economic-based: Allocate based on the cost attributed to each workload. Often used for high-level financial reporting. Document your chosen methodology consistently. Inconsistent allocation is a common mistake that invalidates year-over-year comparisons.
05
Market-Based vs. Location-Based in Practice
Understanding the difference between these two Scope 2 methods is non-negotiable for credible reporting.
- Location-based gives you a baseline footprint. It answers: 'What were the emissions of the grid I physically plugged into?'
- Market-based shows your strategic impact. It answers: 'What emissions am I responsible for based on the clean energy I chose to buy?' Best Practice: Report both numbers. The market-based figure can be lower if you have renewable contracts, but the location-based figure reveals your physical impact and dependency on the local grid's carbon intensity. This dual reporting is required by the GHG Protocol Corporate Standard for comprehensive disclosure.
06
Tools for Automated Calculation
Manual calculation is error-prone. Integrate these tools into your MLOps pipeline for automated, audit-ready emissions tracking:
- Cloud Carbon Footprint: An open-source tool that pulls billing data from AWS, GCP, and Azure, applying both location and market-based emission factors. It provides cost and carbon dashboards.
- CodeCarbon: A Python package that estimates the power consumption (and thus carbon emissions) of your compute hardware during code execution, ideal for tracking training jobs.
- Kepler.gl: For visualizing the geographic distribution of your workloads and the associated carbon intensity of those regions. Start by implementing our guide on How to Automate AI Energy Data Collection and Reporting to operationalize these tools.
EXPLORE
AI ENERGY SCORING
Step 1: Calculate Scope 2 with Location-Based Method
The location-based method is the foundational approach for calculating Scope 2 emissions from purchased electricity for AI workloads. It uses the average carbon intensity of the local power grid where your compute is located.
The location-based method calculates emissions by multiplying your AI workload's electricity consumption (kWh) by the grid emission factor (kg CO₂e/kWh) for the region of your data center. This factor is an average for the entire local grid, published by sources like the International Energy Agency (IEA) or your national energy agency. For example, running a 100 kWh training job in a US-East region with a factor of 0.38 kg CO₂e/kWh results in 38 kg of Scope 2 emissions. This method provides a standardized, geographically accurate baseline, essential for establishing your initial carbon footprint as detailed in our guide on Setting Up a Carbon Footprint Baseline for Your AI Portfolio.
To implement this, you must first collect granular energy data. Use cloud provider tools like the AWS Customer Carbon Footprint Tool, Google Cloud Carbon Footprint, or Microsoft Emissions Impact Dashboard to get usage reports. For on-premises clusters, integrate with data center power distribution units (PDUs). Multiply the kWh values by the correct regional emission factor. Automate this calculation in your MLOps pipeline to attach a carbon cost to every training job and inference hour, creating the foundational data layer for a comprehensive AI Lifecycle Energy Monitoring System.
SCOPE 3 CALCULATION
Allocation Methods for Shared Resources
Methods for apportioning the embodied carbon of shared cloud infrastructure (Scope 3, Category 1: Purchased Goods and Services) to specific AI workloads.
| Allocation Metric | Physical Allocation | Economic Allocation | Time-Based Allocation |
|---|---|---|---|
Primary Driver | Measurable resource consumption (vCPU-hours, GPU-hours, RAM-GB-hours) | Financial cost of resource usage | Wall-clock time of workload execution |
Granularity | High | Medium | Low to Medium |
Cloud Provider Data Support | ✅ (via detailed usage reports) | ✅ (via billing data) | ✅ (via timestamps in logs) |
Embodied Carbon Factor Source | Hardware Lifecycle Assessment (LCA) databases | Financial cost coupled with industry-average $/kgCO2e ratios | Pro-rata share of hardware LCA over allocated time |
Best For | Precise, technical attribution for model training and high-intensity inference | Cost-center reporting and aligning sustainability with FinOps | Long-running, steady-state inference workloads or batch jobs |
Key Limitation | Requires detailed telemetry; may not capture idle resource overhead | Assumes cost correlates directly with physical impact, which can be distorted by discounts | Does not account for intensity of resource use during the time period |
Calculation Example | (GPU-hours used) * (kgCO2e per GPU-hour from LCA) | (Total workload cost) * (Industry avg. kgCO2e per $ of IT hardware) | (Workload duration / Total hardware lifespan) * (Total embodied carbon of hardware) |
Recommended Tool Integration | Integrate with cloud provider's Carbon Footprint Tool + Boavizta API | Use cloud billing exports with tools like Cloud Carbon Footprint | Custom script using workload timestamps and hardware LCA data |
Enabling Efficiency, Speed & Accuracy
Intelligent Analysis, Decision & Execution
We build AI systems for teams that need search across company data, workflow automation across tools, or AI features inside products and internal software.
Talk to Us
Search across company data
Give teams answers from docs, tickets, runbooks, and product data with sources and permissions.
Useful when people spend too long searching or get different answers from different systems.
Enterprise searchRAGPermissions
Read more
Automate internal workflows
Use AI to route work, draft outputs, trigger actions, and keep approvals and logs in place.
Useful when repetitive work moves across multiple tools and teams.
AI agentsWorkflow automationGovernance
Read more
Add AI to products and internal tools
Build assistants, guided actions, or decision support into the software your team or customers already use.
Useful when AI needs to be part of the product, not a separate tool.
AI integrationDecision supportModel routing
Read moreTROUBLESHOOTING
Common Mistakes
Calculating the full carbon footprint of AI workloads is complex. These are the most frequent errors teams make when accounting for Scope 2 and 3 emissions, leading to inaccurate reporting and missed reduction opportunities.
Location-based and market-based are the two standard methods for calculating Scope 2 emissions from purchased electricity, and using the wrong one invalidates your report.
- Location-based method: Uses the average carbon intensity (gCO₂e/kWh) of the local grid where your data center operates. This reflects the physical reality of the electricity consumed.
- Market-based method: Uses the carbon intensity of the specific electricity you contract for, such as Renewable Energy Certificates (RECs) or Power Purchase Agreements (PPAs). This reflects your procurement choices.
Common Mistake: Reporting only market-based emissions to claim a low carbon footprint, while ignoring the location-based figure. Best practice is to calculate and disclose both. The GHG Protocol Corporate Standard requires it, and it provides a complete picture of your grid impact versus your procurement strategy.
About the author
Prasad Kumkar
CEO & MD, Inference Systems
Prasad Kumkar is the CEO & MD of Inference Systems and writes about AI systems architecture, LLM infrastructure, model serving, evaluation, and production deployment. Over 5+ years, he has worked across computer vision models, L5 autonomous vehicle systems, and LLM research, with a focus on taking complex AI ideas into real-world engineering systems.
His work and writing cover AI systems, large language models, AI agents, multimodal systems, autonomous systems, inference optimization, RAG, evaluation, and production AI engineering.
LinkedIn
Limited slotsGet a Free AI Consultation
Partnered with leading AI, data, and software stack.
How We Work
Custom AI workflows for your Business
One-fit-all AI don't work for modern businesses. At Inferensys, we aim to understand your business & custom requirements; which we use to define most efficient agentic workflows, the data, and the tools for your business.
01
Review the use case
We understand the task, the users, and where AI can actually help.
Read more02
Pick the right approach
We define what needs search, automation, or product integration.
Read more03
Build the first useful version
We implement the part that proves the value first.
Read more04
Improve from there
We add the checks and visibility needed to keep it useful.
Read moreThe first call is a practical review of your use case and the right next step.
Talk to Us