AI for Data Centres and Cloud Providers
Data centres are the one place where AI both creates the problem and helps solve it: training and inference workloads are driving power demand up, and energy optimisation is the most reliable AI application on the floor.
Cooling optimisation is one of the best-evidenced AI applications anywhere in infrastructure, and it comes with a constraint that matters: the thermal envelope exists to protect equipment, and an optimiser will find its edges.
AI for data centres and cloud providers covers cooling and energy optimisation, capacity planning and GPU scheduling, infrastructure failure prediction, workload placement and utilisation, and the energy performance reporting required under the Energy Efficiency Directive.
Cooling optimisation, and the envelope it must respect
Cooling is typically the largest controllable energy cost in a data centre after IT load itself, and it responds well to optimisation because the system is well instrumented, the objective is unambiguous and the feedback is fast.
- The thermal envelope is a hard constraint. Set by equipment specifications and your own risk tolerance, not a penalty the optimiser can trade against.
- Model the whole system, not the chillers. Setpoints, airflow, economiser operation and IT load interact, and optimising components separately leaves most of the gain on the table.
- External conditions drive the opportunity. Free cooling availability shifts with weather, and capturing it fully is where a meaningful share of savings sits.
- Advisory before automatic. Recommendations to facilities engineers first, with an operating record accumulated before anything closes the loop.
- Measure against a matched baseline. PUE varies with load and weather, so a like-for-like comparison matters more than a headline number.
Never let an optimiser have the thermal envelope
An optimiser asked to minimise cooling energy will raise temperatures until something stops it, because that is what optimisation does. The limits exist to protect equipment worth far more than any energy saving, and they must be encoded as inviolable constraints set by your facilities and engineering leadership. Where a recommendation would approach a limit, the system should say so rather than approach it — and we build them that way as a matter of course.
Capacity, GPUs and the scheduling problem
AI workloads changed the shape of the problem
Training jobs are long, large, restartable and power-hungry; inference is latency-sensitive and bursty. Scheduling both across shared accelerators, with power and thermal limits, is a genuinely harder optimisation than traditional virtual machine placement.
Utilisation is the number that pays
Accelerators are expensive and frequently idle between jobs or under-utilised within them. Improving effective utilisation returns more than almost any other infrastructure work, and it is a scheduling and packing problem rather than a modelling one.
Power capping and workload shifting interact
Where power is the binding constraint rather than space, shifting flexible workloads in time — against tariffs, grid conditions or thermal headroom — becomes a live lever. That requires knowing which workloads are genuinely deferrable, which is a customer conversation as much as a technical one.
Failure prediction has the usual constraint
Infrastructure components fail rarely, so failure prediction runs into the same shortage of examples as everywhere else. Condition monitoring against known-good behaviour works better and needs no failure history.
Energy reporting, which is now an obligation
Data centres with at least 500 kW of installed IT power demand report energy performance indicators to a European database under the Energy Efficiency Directive, with a common rating scheme now operational. For anyone adding AI capacity in the EU, this is a reporting duty attached to a cost line that AI workloads are pushing upward.
| Obligation | What it means operationally | Note |
|---|---|---|
| Reporting threshold | 500 kW installed IT power demand | Catches most colocation and enterprise facilities |
| Performance indicators | Reported to a European database | Metrics set by the delegated regulation |
| Rating scheme | Operational, with published guidance | A comparative position, not just a filing |
| Data quality | Sub-metering determines what you can report | Frequently the gap; instrumentation comes first |
| Heat reuse | Increasingly incentivised nationally | Varies by member state; worth checking locally |
| Cyber Resilience Act | If you ship products with digital elements | Reporting since Sept 2026; full obligations Dec 2027 |
Reporting quality depends on metering you may not have
The common gap is not the reporting process but the sub-metering underneath it — facilities that cannot separate IT load from cooling from ancillary systems cannot report accurately or optimise credibly. Instrumentation is the unglamorous precondition for both the compliance obligation and the energy work, and it is worth doing once, properly, rather than twice.
How an engagement runs
The thermal envelope and the metering position are established before any optimisation.
Instrumentation and constraint review
Sub-metering coverage, BMS data quality, and the thermal limits set by facilities as hard constraints.
Data foundation
Power, thermal, workload and external conditions joined at a resolution that supports optimisation.
Optimisation build
Whole-system cooling optimisation with constraints encoded, or GPU scheduling and utilisation improvement.
Advisory trial
Recommendations to facilities engineers, measured against a matched baseline for load and weather.
Operation
Constraint adherence audited, savings tracked like-for-like, and reporting data quality maintained.
What you receive
Lower cooling energy inside your thermal limits, and reporting you can stand behind.
Constraint set
Thermal and operational limits from facilities, encoded as inviolable rather than as penalties.
Metering assessment
What your sub-metering supports for both optimisation and statutory reporting.
Whole-system cooling optimisation
Setpoints, airflow, economiser and load modelled together rather than separately.
Capacity and GPU scheduling
Utilisation improvement across mixed training and inference workloads.
Condition monitoring
Against known-good infrastructure behaviour, needing no failure history.
Baseline-matched measurement
Savings reported like-for-like against load and weather.
Is this the right starting point?
Worth being direct. There are situations in data centres and cloud where custom AI work is the wrong spend, and those are listed rather than buried.
Worth doing if
- Cooling energy is a major cost and setpoints are managed conservatively by hand.
- Accelerator utilisation is low and scheduling is first-come-first-served.
- Power is the binding constraint and workload shifting has never been modelled.
- You are above the reporting threshold and sub-metering will not support accurate reporting.
- Free cooling availability is not being captured fully against weather conditions.
Do something else if
- Sub-metering cannot separate IT load from cooling. Instrument first.
- You want an optimiser with authority over thermal limits. We will not build that.
- BMS data is not retrievable at a usable resolution.
- The constraint is grid connection capacity, which no model creates.
Frequently asked questions
Marked up with FAQPage schema so these answers can surface directly in search results and inside AI assistant responses.
How much can cooling optimisation actually save?
Enough to be one of the best-evidenced AI applications in infrastructure, and the honest figure depends on your facility, your climate and how conservatively setpoints are currently managed. What matters more than the headline number is measuring against a matched baseline, because PUE moves with load and weather — a saving claimed without controlling for both is not a saving you can defend to a board.
Can the optimiser control cooling directly?
Eventually, and not first. Advisory recommendations to facilities engineers, with an operating record accumulated over months, is the sequence that gets deployed and stays deployed. And in either mode the thermal envelope is a hard constraint set by your facilities leadership — an optimiser asked to minimise energy will raise temperatures until something stops it, and the limits protect equipment worth far more than the savings.
What does the EU require us to report?
Data centres with at least 500 kW of installed IT power demand report energy performance indicators to a European database under the Energy Efficiency Directive, with the metrics set by delegated regulation and a common rating scheme now operational. The practical gap is usually sub-metering: facilities that cannot separate IT load from cooling and ancillary systems cannot report accurately or optimise credibly, so instrumentation comes first.
How do we improve GPU utilisation?
It is a scheduling and packing problem rather than a modelling one, and it is where the money is. Training jobs are long, large and restartable; inference is bursty and latency-sensitive; and scheduling both across shared accelerators under power and thermal limits is genuinely harder than traditional virtual machine placement. Effective utilisation returns more than almost any other infrastructure work.
Can we predict infrastructure failures?
Rarely well, because components fail infrequently — the same shortage of failure examples that limits predictive maintenance everywhere. Condition monitoring against known-good behaviour works better, requires no failure history, and catches degradation trends. It is a weaker claim than prediction and it is the one the data supports.
Related verticals
Organisations in data centres and cloud usually share data, buyers or regulators with these. All fourteen are listed on the Technology & Telecom page.
AI for Telecommunications Operators
Network optimisation, fault root cause, churn and field operations — at the scale telecoms actually runs.
Read more →AI for Hardware and Device Makers
On-device inference, fleet telemetry and OTA model updates — with CRA and Data Act obligations designed in.
Read more →AI for Managed Service Providers
Ticket triage, alert noise reduction and per-client margin — with client segregation enforced architecturally.
Read more →Tell us what the problem looks like.
Thirty minutes, no charge, no deck. We will tell you whether this is an AI problem, a data problem, or a process problem — and we will say when the honest answer is to buy something rather than build it.