Your Next RFP Will Ask for Grams of CO2 per Transaction. Your Stack Cannot Answer It.

Why Is a Sustainability Question Landing in Your Engineering Backlog?

For most of the last five years, sustainability reporting was somebody else's problem. A finance or ESG team pulled utility bills, travel bookings and a supplier spreadsheet into a framework, an assurance provider looked at it, and engineering was asked for a cloud invoice at most. That division of labour has quietly stopped working, and the reason is that the numbers being requested have moved down the stack to a level of granularity that only telemetry can produce.

Three things changed inside eighteen months. The first is that European data centres became individually measured. Under Article 12 of the Energy Efficiency Directive, Delegated Regulation (EU) 2024/1364 requires operators of facilities with at least 500 kW of installed IT power to report to a European database by 15 May each year, covering Power Usage Effectiveness, Water Usage Effectiveness, Energy Reuse Factor and Renewable Energy Factor. A draft regulation would convert those filings into an automated A-to-G sustainability label, with the first labels generated by 15 August 2027 and refreshed annually after each May filing. The European Commission opened the rating scheme for feedback in March 2026 with adoption targeted for the second quarter, as part of a wider data centre energy efficiency package.

The second is that the demand-side numbers got large enough to attract policy attention on their own. The IEA's analysis of energy demand from AI puts data centre electricity consumption at around 415 TWh in 2024, about 1.5% of global consumption, and projects roughly 945 TWh by 2030 in its base case, growing at about 15% a year and led by AI-optimised facilities whose demand more than quadruples over the period. When a sector's load curve looks like that, the regulatory response is not a question of whether but of shape.

The third is the one that actually lands in your backlog. Reporting frameworks have started asking for primary data rather than spend-based estimates, and primary data about software means per-workload energy, per-region carbon intensity and a defensible denominator. Nobody in finance can produce that from an invoice. It comes from your instrumentation, your tagging discipline and your architecture, which makes it an engineering deliverable with a deadline attached to somebody else's calendar.

Didn't the Omnibus Just Cancel All of This?

This is the objection I hear first, and it is half right in a way that makes it dangerous. The Omnibus I directive genuinely did narrow corporate sustainability reporting. PwC records it as Directive (EU) 2026/470, published in the Official Journal on 26 February 2026 and in force from 18 March, restricting mandatory ESRS reporting to EU entities above 1,000 employees and EUR 450 million net turnover. Accountancy Europe's summary of the changes puts the reduction in scope at roughly 85% of previously covered companies, and adds a value chain cap: companies at or below 1,000 employees can refuse to provide information beyond the voluntary SME standard.

So if you are a 200-person software business, you almost certainly have no direct filing obligation. Good. Now read the second half of that sentence, because it is the half that reaches you. The companies still in scope are precisely the large European enterprises that buy software, run procurement functions and have Scope 3 categories they must populate with something better than an industry average multiplied by spend. They cannot legally compel a small supplier to answer. They can, and do, decide who wins the contract.

The mechanics of that pressure are already visible in voluntary disclosure. CDP's own analysis of supply chain disclosure notes that corporate supply chain emissions run on average around 26 times higher than operational emissions, which tells you where a reporting enterprise has to look once its own operations are tidy. The direction of travel in the accounting rules points the same way: the GHG Protocol's Scope 3 revision work, whose Phase 1 progress update was published on 31 March 2026, has been consulting on tighter supplier data rules, coverage floors and explicit data quality tiers. Data quality tiers are the part engineering should care about, because a tier is exactly the thing that distinguishes a number you measured from a number you inferred.

The honest framing for a supplier is commercial rather than legal. No regulator is going to fine you for not knowing the carbon intensity of your API. A procurement team scoring three shortlisted vendors will, however, notice which one answered the question with a measured figure and a method, which one answered with a marketing page, and which one asked for an extension. We have been on the receiving end of enough European enterprise questionnaires to say that the gap between those three answers is now worth real money, and it is closing slowly enough that being early is still a differentiator.

Why Can't You Just Export the Number From Your Cloud Console?

Every hyperscaler now ships a carbon dashboard, and the obvious move is to treat it as the answer. It is a genuinely useful input and a genuinely poor deliverable, for four reasons worth understanding before you promise anybody a figure.

The first is granularity. AWS expanded its Customer Carbon Footprint Tool in October 2025 to include Scope 3 and additional Scope 1 categories, with historical data recalculated back to January 2022 and a filter between location-based and market-based methods. That is a real step forward at account level. It is not a per-service, per-tenant or per-request number, and the question you will be asked is almost always about a product, a customer or a transaction rather than an account.

The second is method ambiguity. Market-based accounting credits the renewable energy contracts your provider has signed; location-based accounting reflects the grid your workload actually ran on. The two can differ by an order of magnitude for the same compute, and Google Cloud's carbon footprint methodology publishes both precisely because they answer different questions. If you quote one and your customer reports the other, your figure gets discarded in reconciliation.

The third is embodied carbon and amortisation. The AWS methodology amortises manufacturing emissions over asset lifetimes, six years for IT hardware and fifty for buildings, then allocates a monthly share. That is defensible accounting and it is invisible to any optimisation you make, which means a chunk of your reported footprint will not move no matter how efficient your code becomes. Knowing which part is inelastic keeps you from promising reductions you cannot deliver.

The fourth is latency and coverage. Provider data arrives on a monthly cadence, well after the deploy that caused it, and covers that provider only. If you run anything on a second cloud, a colocated rack, a SaaS dependency or a model API, the console has nothing to say about it. The practical conclusion is not to ignore these tools but to demote them: they are a reconciliation source, and your own telemetry is the system of record.

What Metric Actually Fits an Engineering Feedback Loop?

Total emissions is a reporting metric and a terrible engineering one, because it goes up when your business grows and down when it shrinks. Ship a successful feature, watch the number worsen, learn nothing. The metric that behaves properly under load is a rate, and the standardised version is Software Carbon Intensity.

The Green Software Foundation's SCI specification, accredited as ISO/IEC 21031:2024, expresses carbon per functional unit: operational energy multiplied by the grid intensity where it was consumed, plus embodied emissions attributable to the hardware, all divided by a unit of work you choose. The formula is simple enough to fit in a header comment. The hard part is the denominator, and that is a product decision rather than a sustainability one.

Choosing the functional unit is where teams either get something useful or generate a dashboard nobody opens. Per API request is easy to instrument and nearly meaningless when requests vary by three orders of magnitude in cost. Per completed business transaction, per active tenant per month, per document processed or per model inference are all harder and all defensible, because they map onto how the customer asking the question thinks about your service. A good test: if the denominator is a unit that appears on your pricing page, the number will survive contact with procurement. If it only appears in your metrics stack, it will not.

The reason SCI earns its place in a CI pipeline is that it makes efficiency comparable across releases. A rate per functional unit lets you say that version 4.2 emits 18% less per processed document than 4.1, which is a claim an engineer can act on, a product manager can prioritise and an auditor can check. It is the same discipline we argued for when the hardware market forced the issue on price, in the piece on efficiency becoming an engineering requirement again: the instrumentation you build for cost per request is, to a first approximation, the instrumentation you need for carbon per request.

How Do You Account for AI Inference When Nobody Publishes the Numbers?

This is the genuinely new part, and the part most likely to appear in a customer questionnaire during 2027. If your product calls a model API, you have added a supplier whose emissions belong in your purchased goods and services category, and whose per-call figures your provider may or may not disclose.

The measurement problem became far more tractable in 2025, when Google published a full-stack methodology alongside a headline figure. Its measurement of the environmental impact of AI inference puts the median Gemini Apps text prompt at 0.24 Wh of energy, 0.03 gCO2e and 0.26 ml of water, with the accompanying paper on measuring environmental impact at Google scale breaking that down into active accelerator draw, host CPU and DRAM, provisioned idle capacity and data centre overhead. Two details in that breakdown matter more than the headline. Idle provisioned capacity is a real, non-trivial share of per-prompt energy, which means overprovisioned inference fleets carry a footprint even when serving nothing. And the same work reports a 33-fold drop in energy and a 44-fold drop in carbon for the median prompt across twelve months, which tells you that any figure you cite has a short shelf life and needs a date attached.

For accounting purposes, the research community has started to formalise how to treat this. A 2026 methodology paper proposes a four-tier approach to accounting for AI inference in corporate greenhouse gas inventories under Scope 3 Category 1, ranked from vendor-supplied primary data down to spend-based estimation. The tiering is the useful idea: you are not obliged to have the best tier, you are obliged to say which tier you used. That is an achievable engineering goal for this quarter.

The practical build is smaller than it sounds, and you may already be most of the way there. If you meter tokens per feature for cost control, which any team paying attention to the AI invoice nobody budgeted for now does, you already have the volume side of the equation. Add a per-model energy coefficient with a documented source and date, multiply by the grid intensity of the serving region where you know it, and record the tier. When your provider publishes better data, you swap the coefficient and recompute history. When they do not, you have a defensible estimate with its assumptions on the record instead of a blank cell.

There is a second-order effect worth naming for teams choosing an architecture rather than reporting on one. A smaller model that answers the same question well is the single largest lever available, which is why the economics and the emissions both point the same direction as our analysis of deploying small language models instead of calling the frontier API. Routing, caching and batching are not sustainability initiatives. They are ordinary engineering that happens to move both numbers.

Where Do the Emissions Actually Sit in a Typical Stack?

Before optimising anything, it is worth knowing that the dominant variable is usually not your code. It is where and when the code runs.

Grid intensity varies enormously by geography. A survey of energy-aware workflow execution notes that identical computation can produce up to thirty times more emissions in one European grid than in a low-carbon region such as Quebec, purely because of the electricity mix. No refactor competes with that. Region selection, subject to data residency constraints you probably cannot move, is the highest-leverage decision on the list and it is usually made once, early, by whoever set up the account.

Time matters almost as much for anything that can wait. Carbon-aware scheduling, shifting flexible load to hours when the grid is cleaner, has moved from research to operations; Electricity Maps documents Google shifting compute to cleaner times and locations using intensity forecasts. Most enterprises have more deferrable work than they think: nightly ETL, model fine-tuning, batch reindexing, report generation, backup verification, CI on non-blocking branches. The engineering cost is a scheduler that takes a carbon signal as an input alongside cost and deadline.

Then comes utilisation, which is the unglamorous middle of the distribution and where most of the recoverable waste lives. Idle capacity, oversized instances, zombie environments, duplicated staging stacks and the inference fleet provisioned for a launch that never came all burn energy that produces no functional units at all. This is the same waste your FinOps practice is already hunting, which is the strongest practical argument for running the two efforts as one workstream rather than two.

Only after those three do code-level choices matter, and then they matter mostly at scale: query patterns, serialisation formats, retry storms, chatty service meshes, and observability pipelines that ingest far more than anyone reads, a problem we looked at in the observability bill of the agent era. A rule of thumb that has held up well in our own delivery work: fix the region, then the schedule, then the utilisation, then the code, and stop when the next step costs more engineering time than the reduction is worth.

What Does the Build Actually Look Like?

Strip away the framework vocabulary and this is a data engineering project of modest size with an unusually demanding consumer. Four components, none of them exotic.

A resource attribution layer comes first, and it is the one that fails most often. Every compute, storage and network resource needs tags that map to a product, a team and an environment, applied by policy at provisioning time rather than by a quarterly clean-up. If your tagging is inconsistent, everything downstream is an allocation argument rather than a measurement. In our own engagements this is where the first surprise lands: a meaningful share of the estate turns out to have no identifiable owner at all, and reclaiming it usually pays for the rest of the project out of the cost budget.

A metering layer comes second: energy proxies per workload, which in practice means instance-hours by type, GPU-seconds, storage-terabyte-months, egress, and tokens by model. These are counters you can source from billing exports and application telemetry. They do not need to be perfect. They need to be consistent, because the year-on-year delta is what gets reported and a consistent method with a known bias beats an inconsistent one that is occasionally exact.

A conversion and provenance layer comes third, joining those counters to carbon intensity factors and embodied coefficients, each stored with its source, its date, its method and its tier. This is the part that turns a plausible dashboard into an auditable one. When an assurance provider or a customer's ESG team asks where a coefficient came from, the answer has to be a row in a table rather than a conversation with whoever built it.

A presentation layer comes last, and should be smaller than you expect: an SCI figure per functional unit trended over releases, an absolute total for reporting, and an export that matches the shape of the questionnaires you actually receive. If you want to run it as a scored exercise rather than a vanity chart, put a per-unit threshold in CI for your two or three heaviest paths and let it fail like any other regression. The whole build is comfortably a quarter for a small team that already knows the estate, and it is an ideal candidate to hand to a dedicated development team working alongside your platform group, because it is self-contained, well-specified and competing for exactly the senior platform attention your roadmap also wants.

How Should an Engineering Leader Sequence the Next Ninety Days?

The trap here is symmetrical. Do nothing and you will answer a customer questionnaire under time pressure with numbers you cannot defend. Launch a sustainability programme and you will spend two quarters on governance artefacts while the underlying data stays unmeasurable. The path between the two is narrow and quite short.

In the first month, answer the scoping questions rather than the measurement ones. Which of your customers are above the Omnibus thresholds and therefore obliged to ask you something eventually? Which questionnaires have already arrived, and what exactly did they ask for? Which regions do your workloads run in, and why? Which of your dependencies are model APIs? This is a week of work for one senior engineer and a procurement contact, and it usually reframes the whole effort, because the real questions being asked are narrower and more concrete than the framework literature suggests.

In the second month, pick one functional unit and instrument it end to end. One product, one denominator, all four layers, provider data reconciled against your own counters. Resist the urge to cover the estate. A single defensible number for your flagship service is worth more commercially and technically than a partial number for everything, and the second product costs a fraction of the first because the pipeline already exists.

In the third month, use it. Run the region and schedule analysis against real data, take the two or three largest reductions, and write the methodology note that accompanies the figure: functional unit, boundary, coefficients, tiers, exclusions, date. That note is the artefact procurement teams actually value, because it lets them decide whether your number is comparable to somebody else's. Then set a review cadence, because coefficients move and, as Google's own year-on-year numbers show, they can move by more than an order of magnitude.

Where this tends to stall is capacity rather than conviction. It is well-specified work that needs senior platform engineers, arrives with a deadline set by someone else's compliance calendar, and competes with revenue features every sprint. That is the shape of engagement we build for at StepTo: senior engineers in Serbia working in European hours, taking a self-contained platform workstream end to end while your own team stays on the roadmap. Our delivery process is designed around that split, and the same argument applies here that applies to every third-party dependency now under scrutiny, which we covered when looking at how third-party risk rules reach your development partner: the partner you can ask a hard question of, and get a documented answer from, is worth more than the one with the better slide.