Ask ten people what AI is used for, and nine will say ChatGPT. The tenth will mention image generation. Both are correct, both are incomplete, and neither tells you much about what the technology is doing when it is not sitting on a consumer’s phone.
The honest answer depends on who’s asking. For a shopper, AI is a chatbot and a recommendation engine. For a UK operator running compute at scale, it is a different question entirely: which workloads actually command enough resource to matter, which sectors in Britain are leaning in hardest, and what any of this demands of the physical infrastructure underneath. This piece sets out the real picture, grounded in what the hardware is doing rather than what the marketing says it is doing.
The four things AI actually does
Strip the branding away and every production application of AI fits into one or more of four categories.
Pattern recognition at scale. Reading data too large or too noisy for a human to parse and finding the signal in it. Medical imaging, fraud detection, cybersecurity monitoring, equipment-failure prediction, satellite image analysis. The workload is dominated by inference: running trained models against new data in near-real time. Compute demand is persistent rather than peaky.
Prediction. Forecasting the next value, next frame, next word or next event in a sequence. Demand forecasting, financial risk modelling, weather and climate simulation, supply-chain optimisation. These workloads sit at the overlap of classical statistics and modern machine learning, and they tend to run on CPU-heavy infrastructure with GPU acceleration for the deep-learning components.
Generation. Producing plausible new content from a prompt. Large language models, image and video generation, synthetic data, code assistance. Training these models is where the headline compute figures come from. According to the IEA’s Energy and AI report, training the largest frontier models now runs into hundreds of thousands of GPU-hours per run. Inference is cheaper per request but runs at vast query volume, which is why hyperscalers run entire halls dedicated to it.
Narrow autonomous action. Deciding on a bounded system without a human in the loop. Trading systems, autonomous vehicles, warehouse robotics, grid balancing, dynamic pricing. These workloads sit close to the data source, which is why edge compute and micro data centres keep showing up in the same sentence as “AI”.
Everything else is a combination of these four or a repackaging.
Where it runs, and what it needs
The useful question for anyone planning infrastructure is not “what is AI used for” in the abstract. It is “what workload type is my business running, and what does that mean for power, cooling and location”. The table below sets out how the four categories map against sector workloads currently running at scale in the UK.
| Category | Typical workload | Where it runs in the UK | Infrastructure demand |
|---|---|---|---|
| Pattern recognition | Medical imaging triage, fraud scoring, cybersecurity SIEM | NHS trusts, financial services, SOC providers | Steady inference load, 10kW to 30kW per rack, air cooling adequate at low density |
| Prediction | Demand forecasting, risk modelling, weather simulation | Energy traders, insurers, Met Office-adjacent providers | CPU-heavy with GPU bursts, 15kW to 40kW per rack, hybrid cooling |
| Generation (training) | LLM training, image model fine-tuning, synthetic data | Research universities, UK neocloud operators, hyperscalers | Sustained 60kW to 120kW per rack, liquid cooling essential, high power volatility |
| Generation (inference) | Chatbot and copilot serving, image generation APIs | SaaS providers, consumer AI products | Persistent high-utilisation inference, 25kW to 60kW per rack, direct-to-chip or immersion |
| Autonomous action | Algorithmic trading, grid optimisation, logistics routing | City of London trading floors, DNOs, logistics operators | Low latency to source, often edge-deployed, standard rack densities |
Two things fall out of this table that the hype cycle tends to miss.
The first is that most AI compute in the UK today is inference, not training. Training is what makes the newspaper headlines because the compute involved is spectacular. Inference is what pays for the facility, because it runs continuously and at scale across every production AI product in use. For a UK data centre operator, the inference workload is the one that reshapes the facility.
The second is that AI is not a single infrastructure problem. A fraud-detection model running at a UK bank and an LLM training cluster at a neocloud operator are both “AI workloads”, but they place almost no overlapping demands on the physical environment. One wants predictable low-density compute near the transaction network. The other wants 100kW per rack and liquid cooling. Treating them as the same procurement question is how facilities get specified wrong.
The three UK sectors leaning in hardest
The sector breakdown is more interesting than most “AI use cases” articles make it. In the UK specifically, three sectors are driving the majority of commercial AI deployment that reaches an infrastructure team.
Financial services uses AI across fraud detection, risk modelling, algorithmic trading, document processing and regulatory analysis. These workloads are typically steady-state inference, which means they do not need the headline-grabbing densities of a training cluster but they do need audit-grade physical security, UK data sovereignty and low latency to the financial network. The infrastructure requirement maps to secure cages or private halls inside well-connected UK sites.
Healthcare and life sciences uses AI for medical imaging triage, genomics pipelines, drug discovery and clinical decision support. Imaging workloads are inference-heavy and run against patient data that cannot leave UK soil under NHS Digital standards. Genomics is more compute-intensive and often runs in bursts, which maps closely to HPC colocation. Both sit firmly on the ISO 27001 side of the fence, and both increasingly route into UK sovereign healthcare colocation rather than hyperscale regions where the physical location of the hardware cannot be named.
Manufacturing and industrial operations uses AI for predictive maintenance, factory-floor automation, computer vision quality control and supply-chain optimisation. The pattern here is different again: compute lives close to the production line, often in micro data centres or edge deployments, feeding back into a central environment for retraining. The density is low per site but the number of sites is high.
A fourth category is coming up fast: UK neocloud operators and research universities running training compute. The numbers here are smaller in facility count but much larger in power draw per facility. These are the deployments that need the liquid-cooled, 100kW-plus environment the newspaper headlines describe.
Why the question matters for anyone running a data centre
The question “what is AI actually used for” matters commercially because the answer dictates every important facility decision for the next decade. Rack density, cooling architecture, power contract shape, geography, compliance posture, all of them flex depending on which category of AI workload the tenant is bringing.
This matters at a national level too. A UK Parliament research briefing on data centres sets out that UK data centre capacity is forecast to roughly double by 2030, with AI workloads driving the majority of that demand. The government formally recognised data centres as Critical National Infrastructure in September 2024, and the AI Growth Zone programme has followed. Which category of AI workload sits in which facility is now a question of national compute strategy, not just a procurement decision.
A facility built for 2015-era enterprise colocation (4kW to 10kW per rack, CRAC-cooled, Tier III power) can comfortably host the pattern-recognition and prediction workloads at the top of the table. It cannot host generation training without a major retrofit, and it cannot host dense inference at scale without compromising on sustained throughput. Operators who understand which half of the AI workload stack they are building for are operators who will not need to rebuild in three years.
Our sites across the UK are engineered around sustained high-density compute, with air-cooled, direct-to-chip and immersion environments in the same halls. The architecture reflects the real distribution of UK AI workloads today: inference-heavy, density-mixed, UK-sovereign, rather than the fictional one where everything is training.
Frequently asked questions
Which AI workloads need the most compute?
Training is the most compute-intensive by a wide margin, particularly for large language models and foundation models where a single run can consume tens of thousands of GPU-hours. Inference uses less compute per request, but production inference at scale (serving millions of API calls a day) can add up to a larger total power draw than training over the same period. The practical rule: if the question is “where should I rent GPU time”, training. If the question is “what is reshaping the UK data centre industry”, inference.
Is UK AI compute mostly cloud or colocation?
Both, but the split is changing. The consumer-facing generation workloads chatbots and image generation APIs are mostly run on hyperscale cloud. Enterprise AI workloads with data sovereignty, regulatory or latency requirements are increasingly moving to colocation, because the facility can be named, certified and audited in a way a hyperscale region cannot. UK financial services, healthcare and public sector workloads sit disproportionately in colocation for this reason.
What does running an AI workload actually cost in power terms?
A single eight-GPU NVIDIA H100 server draws roughly 5.6kW continuously under load. A populated 42U GPU rack running a sustained training workload can exceed 100kW, which is 10 to 20 times the draw of a traditional enterprise rack. Over a year, that single rack consumes roughly as much electricity as 150 to 200 average UK homes. For organisations evaluating AI infrastructure, the power contract is now the primary cost variable, not the rack space.





