Moving AI compute to sparsely populated regions solves an energy problem and creates a security one. When training capacity sits in a few large sites, the decisive defences become power, cooling, fibre and physical access rather than software.
Key takeaways
- The BBC reports that dozens of data centres are under construction in Inner Mongolia as China pursues a leading position in artificial intelligence.
- Large AI training sites depend on a short list of physical inputs — electricity, cooling, long-haul fibre and skilled on-site staff — and each of those is a potential single point of failure.
- Concentrating national compute capacity in a few remote clusters makes infrastructure engineering, not application security, the main determinant of resilience.
- The opposing case is serious: isolated, tightly controlled sites are harder to reach physically and easier to defend uniformly than thousands of scattered server rooms.
The security of a large AI cluster is decided before any software is installed
Discussion of AI security usually starts with models: prompt injection, data poisoning, model theft, misuse. Those matter. But a frontier-scale training run is not an abstraction. It is a building, or a cluster of buildings, containing racks that draw enormous amounts of electricity, reject enormous amounts of heat, and are connected to the rest of the country by a limited number of fibre routes. Every one of those properties is a dependency, and a dependency is an attack surface.
The argument here is simple. When a country routes its most capacity-hungry computing into a small number of remote industrial sites, the realistic failure modes shift away from the software stack and towards the physical layer. A model weights file can be protected by encryption and access control. A substation cannot. A cooling plant cannot. A fibre trunk running for hundreds of kilometres across open country cannot be patched.
This is not an argument that remote data centres are badly built or uniquely vulnerable. It is an argument about where the residual risk sits once they are built. The more compute a country concentrates into a handful of engineered locations, the more its AI programme inherits the risk profile of heavy infrastructure — grid faults, construction quality, water availability, supply chains for transformers and chillers, insider access during construction and maintenance — rather than the risk profile of ordinary enterprise IT. Security teams that are organised around the second are not organised around the first.
Compute is being steered towards remote regions by policy, not market drift
The clustering is deliberate. China has for several years pursued a national strategy of siting computing capacity in western and northern regions while keeping demand concentrated in the coastal east, designating hub locations where large-scale facilities are encouraged. Inner Mongolia is one of the regions associated with that approach. The BBC, reporting from the region, describes dozens of data centres being built there as the country aims to lead the world in artificial intelligence.
The logic is straightforward and not unique to China. Remote inland regions offer land, energy and a cool climate for much of the year, which lowers the cost of the two largest operating inputs: power and heat rejection. Inner Mongolia is a significant energy-producing region, which makes the co-location of generation and consumption attractive. Data centres are among the few industrial loads that can be placed almost anywhere, because their output travels as light down a cable rather than as freight down a road.
The security consequence of a policy-driven build-out is that the resulting map is not diverse by accident. Market-led data centre growth tends to scatter capacity across many metropolitan areas near customers. Policy-led growth towards designated hubs does the opposite: it aligns many operators on the same regions, the same climate, the same grid and often the same long-haul routes. Correlated siting produces correlated risk. A regional event — a grid disturbance, an extreme weather episode, a construction or component defect common to a build generation — does not affect one operator in isolation.
How many sites are involved, who operates them, and what redundancy exists between them is not established by the available reporting, and this article does not assume it.
A hyperscale site depends on a short list of physical inputs
Consider what a large AI facility actually needs to keep running. It needs firm electrical supply at industrial scale, delivered through substations and transmission lines that are themselves physical assets in open terrain. It needs continuous heat removal, whether by air, water or liquid-to-chip systems; when cooling stops, high-density AI racks reach unsafe temperatures far faster than legacy server halls. It needs network capacity to reach users and to synchronise with other sites. It needs people on site to replace failed components, because at cluster scale hardware failure is routine rather than exceptional.
Each item is a chokepoint in a way that software rarely is. Software can be replicated cheaply across regions; a transformer cannot, and replacement lead times for heavy electrical equipment are long everywhere in the world. Long-haul fibre is resilient because it is redundant, but redundancy in remote geography is expensive and route diversity tends to be thinner than in dense corridors. Staffing a highly technical facility far from large cities is a recognised operational challenge, and thin staffing raises the value of every individual with physical access.
None of this is speculative harm. It is the ordinary engineering reality of heavy infrastructure, and it is why utilities and telecoms operators treat physical security, component provenance and outage restoration as first-order disciplines. The point is that AI capacity has now joined that category. A country that concentrates its training capacity accepts a resilience problem that resembles the electricity sector’s more than the software sector’s.
Distance changes the threat model rather than removing it
Remoteness is often described as protective, and in one narrow sense it is: fewer people are nearby. But the threat model does not disappear; it changes shape.
Physical isolation increases reliance on a small set of long links, which are harder to monitor continuously along their whole length than short urban routes. It increases the significance of construction and maintenance supply chains, because equipment, contractors and subcontractors must be brought in from elsewhere, and a supply chain with many hands and long distances is a supply chain with more opportunities for tampering or substitution. It raises the consequence of insider risk, since a smaller resident workforce means broader individual privileges. And it lengthens response times: incidents that would be resolved in an hour in a city can take considerably longer when the nearest specialist team is far away.
There is also a data-flow dimension. If compute sits far from the population it serves, then data must travel — training corpora moving in, inference traffic moving back and forth, telemetry and management traffic crossing the same links. Encryption addresses confidentiality on the wire, but availability and integrity of the management plane remain infrastructure problems. The more separation between where data is generated and where it is processed, the more the security of the transport layer matters.
The case against: isolation and central control are genuine defences
The strongest objection is that this analysis undervalues what remote, purpose-built, centrally planned facilities do well.
Physical distance from dense urban areas genuinely reduces some categories of risk. A controlled perimeter in open country, with restricted approaches and no casual foot traffic, is a harder target than a colocation suite in a city centre shared with other tenants. Purpose-built sites can be designed from the outset with hardened power, segregated management networks and strict access control, rather than retrofitted into buildings designed for something else.
Scale also cuts the other way. Defending a small number of large, standardised facilities can be done to a consistently high standard with specialist teams, whereas defending thousands of small distributed server rooms almost guarantees inconsistent practice and forgotten equipment. Standardisation makes monitoring, auditing and incident response tractable. Co-locating generation with consumption can reduce dependence on long transmission paths, not increase it. And a coordinated national build-out can, in principle, design cross-site failover deliberately rather than hoping the market produces it.
That case is coherent. The honest position is that concentration is a trade: it reduces the number of weakly defended places and increases the consequence of any single place failing. Which effect dominates depends on engineering choices that are, from the outside, largely unobservable.
What evidence would change this conclusion
The argument above should not be treated as settled, and specific evidence would move it.
Documented cross-site redundancy would weaken it most directly: if training and inference workloads can be failed over between geographically separated clusters on different grids and different fibre routes, concentration becomes far less consequential. Evidence of genuine route diversity and independent power paths for individual facilities would have the same effect.
Operational track records would help. Published outage statistics, independent audits, or regulatory reporting on availability and incident causes would show whether the theoretical physical risks materialise in practice. Infrastructure that has run through extreme weather, grid disturbance and peak demand without correlated failure is evidence that the engineering answers the objection.
Conversely, evidence of correlated outages across multiple sites in one region, or of dependence on a single substation, water source or fibre corridor, would strengthen the argument considerably. So would evidence that inference — the latency-sensitive, user-facing half of the workload — remains distributed near population centres, which would mean concentration affects training capacity rather than everyday service availability.
Almost none of this information is publicly available for the facilities described in the reporting, and that absence is itself part of the picture: the resilience of concentrated national compute is currently a matter of assumption rather than verification.
Sources and further reading
- BBC News technology reporting, including video reporting filmed in Inner Mongolia on data centre construction and China’s artificial intelligence ambitions.
- Chinese national planning documents on the distribution of computing infrastructure between eastern demand centres and western hub regions, published by state planning bodies.
- Data centre industry engineering standards and operator documentation on power, cooling and redundancy tiering, which set out the physical dependencies described here.
- Critical national infrastructure security guidance from national cybersecurity agencies, which covers physical access, supply chain and insider risk for large facilities.
Surfaced from the rss:bbc_tech signal “remote AI data centre construction”. AI-assisted draft, editorially reviewed.
