If you look at what a rack actually draws in the data centre, you already hold half of a CO2 report. The other half is arithmetic and agreements: which scope the kilowatt-hours fall under, which factor converts them, and which evidence your provider must be able to show. This article walks through that for colocation and for AI inference as a service, and explains why a figure like "grams of CO2 per request" mostly suggests precision.
Who still has to report
The obligation narrowed considerably in 2026. With Omnibus I (Directive 2026/470, in force since 18 March 2026) the CSRD only applies to companies with more than 1,000 employees and more than 450 million euros in turnover, and then from financial year 2027. For everyone below that there is the voluntary VSME standard. It still does something useful: it limits what large customers may ask of their smaller suppliers. If you receive a questionnaire from a corporate as an SME, you no longer have to deliver more than VSME.
That does not make the subject go away. Banks, tenders and large customers still ask for figures, and anyone who can supply measured numbers is finished faster than anyone who has to estimate.
Colocation and inference are scope 3, not scope 2
The first misconception: "our servers are in a data centre, so that is scope 2". Scope 2 is the electricity you buy yourself. With colocation the energy contract is in the name of the data centre or your provider; you buy a service, electricity included. That makes it scope 3, category 1: purchased goods and services. The same applies to inference as a service, whether you pay per token or per reserved card.
The practical consequence: you cannot derive it from your own energy bill. You depend on what your provider measures and reports, which is why you need to know what to ask for.
Location-based and market-based
The GHG Protocol has two ways to convert kilowatt-hours, and a proper report shows both:
- Location-based — the average Dutch grid mix. For 2026 that is 0.244 kg CO2e per kWh (co2emissiefactoren.nl). This number says what the grid physically emits, regardless of your contract.
- Market-based — what you have contractually purchased. Electricity from Dutch solar or wind, evidenced by cancelled guarantees of origin (GoOs), counts as 0 at generation. Grey electricity without GoOs is calculated at 0.483 kg CO2e per kWh.
A worked example: a rack using 10,000 kWh a year is 2,440 kg CO2e under the location-based method. Under the market-based method it is 0 kg if the GoOs are there, and 4,830 kg if they are not. Same rack, three outcomes. That is why the two methods sit side by side: location-based shows the physical reality, market-based shows what your purchasing choice contributes.
Do not forget the facility share. Cooling and losses come on top of IT consumption; the hall's PUE is the factor. Large data centres (from 500 kW of IT load) have reported their PUE annually to a European database since the EED, but that database is only public in aggregate. The PUE of your hall is something you ask your provider for.
What to ask your provider
The second misconception is that a line like "we run on green power" is enough. Since 27 September 2026 the ECGT directive prohibits generic environmental claims without substantiation, and the Dutch ACM guidance says the same. A report you can actually use contains:
- Measured IT kWh — from a meter on your feed or your unit, not estimated from your connected load or nameplates.
- PUE with source and period — the value for the hall you are in, over the month or year of the report.
- GoO evidence — which party certifies, how many kWh, and whether the certificates have been cancelled. "Green power" without cancellation is an intention.
- Both methods — location- and market-based, with the factor used and the version of the list.
- Allocation method for shared services — for inference per token: how is the consumption of a shared server divided among customers, and where does idle consumption go?
- Scope label and method version — so you can compare next year's report with this year's.
Why grams of CO2 per request is false precision
Language-model providers like to give a number per answer. Mistral published a life-cycle assessment with Carbone 4 and ADEME: 1.14 grams of CO2e and 45 millilitres of water per 400-token answer, on the French electricity mix. Careful work, and precisely because of that it shows how many assumptions go in: prompt length, electricity mix and how busy the server is.
That utilisation is the largest variable. ML.ENERGY measured 3.76 joules per token on a 70B model at eight concurrent requests and 0.37 joules per token at over a thousand. Same card, a factor of ten apart, depending on how busy it was when your request came in. A number per request is an average over a situation you do not know.
More honest is: measured watt-hours per million tokens, per model, over the reporting period, with the emission factor shown separately. That you can check, compare and recalculate when the factor changes.
Reporting at Xyphen IT
For AI inference we supply, on request, a monthly energy and CO2 report with measured IT kWh, the hall's PUE with source, the facility share, both calculation methods and consumption per model in watt-hours per million tokens. With colocation you see the measured consumption per PDU outlet in kWh per month in the customer dashboard, the basis for the same calculation. The electricity in our data centre at BIT comes from Dutch solar and wind: for 2025, E.D.Mij certified 12,204,056 kWh, with cancelled GoOs. If you place your own servers in GPU colocation, you see the consumption per outlet in the dashboard in the same way.
Want to know what such a report looks like for your setup? Get in touch or request a proposal.