Calculating AI emissions for CSRD

Why AI emissions belong in your CSRD report

Under the EU Corporate Sustainability Reporting Directive (CSRD), companies report against the European Sustainability Reporting Standards — specifically ESRS E1 (Climate change), which requires disclosure of gross Scope 1, 2 and 3 greenhouse gas emissions using GHG Protocol methodology.

CSRD creates no separate "AI emissions" category. AI workloads slot into existing scopes:

• Scope 2 — electricity purchased to run AI on infrastructure you control (your own data centre, a co-location lease).
• Scope 3, Category 1 — Purchased goods and services — the most common case for enterprise AI users who consume models via API or SaaS.

This matters now because AI electricity consumption is growing faster than most corporate energy budgets, regulators are beginning to ask pointed questions about it, and third-party assurance providers are starting to require traceable methodology for IT-related Scope 3 estimates. Getting this right in 2025–2026 is early-mover positioning, not compliance theatre.

Step 1 — Pull token usage data from provider APIs

Token and request counts are the most granular activity data you can actually obtain. They are the starting point for all downstream calculations.

What each major provider exposes

Recommended data collection approach

For a defensible annual CSRD disclosure, collect data at three levels of precision, working down from what you have:

• Per-call token logs — ideal; capture input tokens, output tokens, model name, and Unix timestamp from the API response for every call your application makes. Store in a data warehouse.
• Monthly API billing exports — acceptable fallback; most providers show token volume in billing breakdowns even when the usage API is not integrated.
• Cost-based back-calculation — last resort only; divide spend by published pricing per million tokens to estimate token volume. Document clearly as an approximation.

# Example: pull Anthropic monthly token totals via console export
# Then aggregate by model for the reporting period

import pandas as pd

df = pd.read_csv("anthropic_usage_export.csv")

# Group by model, sum input and output tokens over fiscal year
summary = (
  df
  .groupby("model")[["input_tokens", "output_tokens"]]
  .sum()
  .reset_index()
)
print(summary)

Record the reporting period, the data source, and any gaps or exclusions. This documentation is what an assurance provider will ask for first.

Step 2 — Apply an emissions methodology

Two credible open methodologies exist for translating token counts into energy and CO₂e estimates. Use them in combination — or choose the one best suited to your provider mix.

Methodology A: EcoLogits (open-source)

EcoLogits is an open-source Python library developed by Boavizta that wraps major AI provider clients and returns energy and GHG estimates alongside every API response. It uses a hardware-based model of GPU energy consumption, normalised by model size and utilisation assumptions.

The core inference energy formula it applies:

Where:

• T_output = output tokens generated
• S_tokens = model throughput (tokens/second) per GPU
• P_GPU = TDP of GPU type (watts)
• n_GPU = number of GPUs serving the model
• PUE = data centre Power Usage Effectiveness

EcoLogits ships with default parameter tables for GPT-4, Claude 3, Gemini, Mistral, and Llama variants, derived from published model cards, academic benchmarks, and hardware specs. You can override these for proprietary models.

from ecologits import EcoLogits
from anthropic import Anthropic

EcoLogits.init()  # patches supported clients automatically
client = Anthropic()

response = client.messages.create(
  model="claude-3-5-sonnet-20241022",
  max_tokens=1024,
  messages=[{"role": "user", "content": "Summarise our Q3 risk register."}]
)

# EcoLogits attaches impacts to the response object
print(response.impacts.energy.value)   # kWh
print(response.impacts.gwp.value)      # kg CO2e

For batch CSRD calculations where you have historical token data rather than live API calls, use the functional interface directly:

from ecologits.tracers.utils import llm_impacts

impacts = llm_impacts(
  provider="anthropic",
  model_name="claude-3-5-sonnet-20241022",
  output_token_count=850,       # average per call
  request_latency=2.4,            # seconds
  electricity_mix_zone="US"     # ISO 3166-1 or region code
)

# Scale to annual volume
annual_calls = 2_400_000
total_kwh = impacts.energy.value * annual_calls
total_co2e_kg = impacts.gwp.value * annual_calls

Methodology B: Green Software Foundation Software Carbon Intensity (SCI) for AI — 2025 specification

The Green Software Foundation ratified its SCI for AI specification in 2025. It standardises how to express the carbon intensity of an AI service as a rate — carbon emitted per functional unit — making it consistent with ESRS E1's emphasis on intensity metrics alongside absolute figures.

The SCI equation:

The SCI's value for CSRD is that it gives you a per-unit intensity figure you can disclose and track over time — useful in the qualitative narrative of your ESRS E1 report to show efficiency improvements even if absolute usage grows.

For absolute Scope 3 totals (what ESRS E1-6 actually mandates), you still need E × I + M summed across all calls in the reporting year. SCI and EcoLogits are complementary, not competing.

Which to use when

Step 3 — Apply grid carbon intensity by data centre region

The single biggest variable in AI emissions calculations is where the inference runs. A query routed to a coal-heavy grid emits roughly 8–10× more CO₂e than one running on a predominantly renewables grid. Getting the regional factor right matters.

Data sources for grid intensity

Mapping AI providers to regions

Most providers do not tell you which physical data centre handled your request. Use these defaults, documented clearly in your methodology:

Handling multi-region workloads

If your AI usage spans multiple regions or providers, calculate emissions separately per region-model combination, then sum:

Step 4 — Format as a Scope 3 Category 1 line item

The output of Steps 1–3 needs to be shaped into something that sits cleanly inside your ESRS E1 disclosure. Here is how to structure it.

Where it sits in ESRS E1

For most companies using AI as a purchased service:

• ESRS E1-6, Disclosure Requirement E1-6 — Gross Scope 3 GHG emissions, Category 1 (Purchased goods and services)
• AI emissions are part of Category 1 — they do not need their own ESRS line item, but you may break them out in supplementary disclosures or the narrative sections of ESRS E1
• If AI electricity runs on infrastructure you control, classify as Scope 2 instead

What to document

An auditable CSRD disclosure for AI Scope 3 Category 1 emissions should contain:

• Activity data — total tokens consumed by provider, model, and reporting period
• Emissions methodology — e.g. "EcoLogits v0.x functional interface, applying hardware-based GPU energy model; GSF SCI specification for intensity metrics"
• Emission factors — per-query energy factors by model (from EcoLogits parameter tables, cited by version); grid intensity by region (source, year)
• PUE assumption — the data centre PUE applied (EcoLogits default is 1.2; document if you override it)
• Confidence / uncertainty range — provide a range (e.g. ±40%) reflecting uncertainty in hardware parameters and region allocation
• Explicit modelled-not-measured statement — required for credibility; see section below

Worked example disclosure entry

The transparency principle: modelled, not measured

This is not a caveat to hide in footnotes. It should be stated plainly in the body of your methodology disclosure.

Here is why this is the right approach — and why experienced assurance providers will respect it:

• Every estimate in corporate GHG accounting involves assumptions. Scope 3 Category 1 for physical goods already relies on spend-based or average emission factors that are rougher than most AI estimates.
• Claiming measured precision you do not have is an audit failure waiting to happen. Stating uncertainty ranges is standard GHG Protocol practice.
• The existence of recognised open methodologies (EcoLogits, GSF SCI) means your estimates are not arbitrary — they are traceable to published, peer-reviewed parameter sets.
• Providers' own sustainability reports (where they exist) use the same modelling approaches for AI workloads. You are doing what the industry does.

Regulators and assurance bodies accept methodological uncertainty when it is disclosed honestly, bounded quantitatively, and accompanied by a credible improvement plan — such as committing to integrate live EcoLogits instrumentation into production systems by the following reporting year.

Automating the pipeline

The four steps above are entirely automatable. Once the pipeline runs in production, the marginal cost of producing CSRD-ready AI emissions data approaches zero.

A minimal production architecture

1. Instrumented API wrapper
   Wrap all outbound AI API calls (OpenAI, Anthropic, Azure) in a thin middleware layer. On each response, call llm_impacts() and log impact metadata — kWh, kg CO₂e, model, timestamp, region — to a structured log or your data warehouse alongside the business transaction ID.
2. Monthly aggregation job
   A scheduled query (SQL or dbt model) aggregates logged impact data by reporting period, provider, and model. Output: a flat table with columns [period, provider, model, region, total_kwh, total_co2e_kg, input_tokens, output_tokens, call_count].
3. Grid intensity refresh
   An annual (or more frequent) job pulls updated grid intensity factors from Electricity Maps or EPA eGRID for each region in use and writes them to a reference table. Calculation jobs always join to the reference table rather than hard-coding factors.
4. CSRD reporting export
   A parameterised report template (SQL + Python or a BI tool) takes the aggregation table, applies embodied hardware factors, outputs the Scope 3 Category 1 figure with confidence range, and generates the methodology appendix text in structured form ready for the sustainability report.

This architecture also produces the data lineage trace that CSRD's assurance requirements are increasingly demanding — a clear, auditable path from raw API response to reported CO₂e figure.

The tooling landscape

Several commercial platforms now offer to automate this pipeline with provider integrations, pre-built emission factor libraries, and CSRD/ESRS reporting templates. If you are evaluating tooling, the questions to ask are: does it use a recognised, versioned methodology (EcoLogits or equivalent)? Can you export the underlying calculation for audit? Does it produce both absolute and intensity metrics? And does it handle multi-provider, multi-region workloads in a single view?

The open-source approach described in this guide remains the most transparent option for companies that need full auditability — and the pipeline, once built, requires only modest maintenance as model versions and grid factors change annually.

Summary

Calculating AI emissions for CSRD is a four-step process: collect token usage data from provider APIs, convert tokens to energy and CO₂e using a recognised methodology (EcoLogits for hardware-based estimates, GSF SCI for intensity metrics), apply the appropriate grid carbon intensity for each region, and report the result as a Scope 3 Category 1 line item under ESRS E1-6 with an explicit uncertainty range and a clear statement that all figures are modelled, not measured.

The companies that will handle this most effectively in 2026 and beyond are those instrumenting their AI usage now — building the data infrastructure to move from rough retrospective estimates to real-time, per-call accounting, and using that pipeline as the foundation for both compliance and genuine emissions reduction.