Most sustainability teams working through CSRD compliance are focused on the usual friction points: incomplete supplier data, inconsistent emissions factors, the gap between what ESRS E1 requires and what ERP systems actually track. These are real problems. But there's a newer one compounding quietly in the background, and it's structural in a way that's harder to fix.
Your organization is almost certainly spending material money on purchased AI services — OpenAI, Microsoft Copilot, Azure OpenAI, Anthropic, Google Gemini API, or some combination. That spend is sitting in a finance or IT procurement system. It is not sitting in your ESG data infrastructure. And under CSRD, it needs to be.
## What ESRS E1 Actually Requires
ESRS E1 is the climate standard under CSRD. Disclosure requirement E1-6 requires companies to report gross Scope 1, Scope 2, and Scope 3 greenhouse gas emissions. Scope 3 is comprehensive — it covers emissions in a company's value chain that the company does not directly control but is responsible for through its purchasing decisions.
**Scope 3 Category 1 is purchased goods and services.** It is, by definition, where AI services belong. When your organization pays OpenAI for API access, pays Microsoft for Copilot seats, or runs inference workloads on a third-party cloud, you are purchasing a service that requires significant compute infrastructure to deliver. That infrastructure has an emissions footprint. That footprint is your Category 1 liability under ESRS E1-6.
This isn't an interpretation question or an edge case. It follows directly from how Scope 3 Category 1 is defined under both the GHG Protocol (which ESRS E1 is built on) and the standard itself. Purchased services with material energy intensity are in scope. AI services are purchased services with material energy intensity. The inclusion is logical and — as CSRD enforcement matures — will be expected.
## The Enforcement Timeline
CSRD is phased. If your organization is a large EU company that was already subject to the Non-Financial Reporting Directive (NFRD) — generally, more than 500 employees — you were in scope for FY2024 reporting. Your first CSRD-compliant report, covering FY2024, was due in 2025.
If you're a large company not previously covered by NFRD — over 250 employees, or over €40M in turnover, or over €20M in total assets — FY2025 is your first reporting year, with reports due in 2026.
Listed SMEs follow in FY2026. Non-EU companies with more than €150M in EU net turnover and at least one large EU subsidiary or listed branch come in at FY2028.
The phasing creates a false sense of distance. Companies in the FY2025 cohort are reporting on emissions that are occurring right now. The data you need for your 2026 report is being generated today — every API call, every Copilot prompt, every inference run. If you don't have a system for capturing it, you can't retroactively reconstruct it from memory.
## Why the Blind Spot Exists
The structural problem is simple: AI spend is tracked where spend gets tracked, which is finance. The purchase order for an OpenAI enterprise agreement lives in procurement. The Azure invoice that includes OpenAI Service charges is itemized in accounts payable. The Copilot licensing is bundled into an M365 contract.
None of this flows to the ESG function by default. ESG teams typically receive emissions-related data through purpose-built processes — utility bills for Scope 2, travel data from HR and expense systems, supplier questionnaires for upstream Scope 3. AI services don't fit neatly into any of those existing pipelines. They've arrived faster than the reporting infrastructure has adapted.
The result is that sustainability managers who are doing their jobs correctly — following the GHG Protocol, applying spend-based emissions factors to Category 1 — may genuinely not know what AI services their organization is using, at what volume, or at what cost. That data gap isn't negligence. It's a structural failure in how organizations have wired together their finance and ESG functions.
What makes this harder: even if the spend data were accessible, the emissions factors for AI services are not standardized in the way that, say, electricity grid emission factors are. OpenAI does not publish per-token or per-API-call emissions data. Microsoft publishes sustainability commitments but not the granular compute-to-emissions factors that a Scope 3 Category 1 calculation requires. You're often left applying industry-average emissions factors to cloud compute spend — a methodology that satisfies the "best available data" standard under ESRS E1-6, but only if you actually have the spend data to apply it to.
## What "No Data" Looks Like in an Audit
CSRD reports are subject to third-party limited assurance now, with reasonable assurance requirements phasing in. Auditors reviewing Scope 3 Category 1 disclosures are not simply checking whether a number is present. They are checking whether the boundary of what's been included is appropriate.
If your Category 1 disclosure covers supplier materials and professional services but excludes purchased software and AI services, an auditor is going to ask why. If the answer is "we didn't track it," that's a gap. If the answer is "we assessed materiality and determined AI services are not material to our Scope 3 inventory," that requires documentation of the materiality assessment — which requires knowing what the spend actually is, which requires access to data that, in most organizations, hasn't been pulled into the ESG function.
The risk isn't just a qualified audit opinion. It's reputational. A company that reports confidently on climate performance while having a blind spot on one of the fastest-growing categories of enterprise technology spend will look, at best, behind the curve. At worst, it will look like a company that shaped its disclosure boundary to exclude inconvenient data.
The "no data" position is not safe. It is a position that needs to be actively defended — and defending it requires having done the work to know whether the gap is material.
## The Real Question
The problem isn't that CSRD is asking too much. The problem is that AI services have entered enterprise operations through procurement and IT channels without triggering the usual ESG data capture processes. The spend is real, the emissions are real, and the reporting obligation is real. The infrastructure to connect them hasn't been built yet.
That's a solvable problem — but it requires understanding what ESRS E1-6 actually demands, where the data currently lives, and what methodology is defensible when supplier-specific emissions factors aren't available.
In the next piece, we'll go into what a credible AI emissions methodology looks like under ESRS E1-6: spend-based versus activity-based approaches, what disclosure-quality documentation requires, and how organizations are beginning to build the data infrastructure to close this gap.
*Salish Sea Consulting helps organizations build defensible, audit-ready carbon accounting programs. If your CSRD Scope 3 inventory doesn't yet account for AI services, [get in touch](/contact).*
Your AI Stack Is a Scope 3 Problem. Your ESG Team Doesn't Know It Yet.
Your organization is spending real money on purchased AI services. That spend is in finance. Under CSRD's ESRS E1-6, it should be in your Scope 3 inventory — and most sustainability teams have no way to get there.