How attacks on data centres can disrupt AI, cloud services and digital infrastructure

AI often gets discussed as if it lives somewhere abstract - in models, apps, APIs and clever prompts. In reality, modern AI is extremely physical. It depends on buildings full of servers, specialist chips, storage systems, network equipment, power supplies and cooling.

That is why the recent attacks on Russian data centres matter beyond the immediate geopolitical story. According to the discussion source, Ukrainian drone attacks hit key data centres linked to Yandex, Sberbank and VKontakte, with reported disruption across cloud services, banking, e-commerce, geolocation, ride-hailing, AI assistants, multimodal chatbots and even parts of the court system.

The exact damage has not been fully disclosed. But Yandex has publicly said its Sasovo data centre was seriously damaged and completely shut down after a drone attack, while its Kaluga facility was also attacked. Yandex described data centres as the iron heart of its services.

That phrase is doing a lot of work. It reminds us that data centres are not background plumbing. They are strategic infrastructure.

Why AI depends so heavily on data centres

For ordinary cloud software, losing a data centre can be serious. For AI, the problem can be even more acute because advanced AI systems often depend on scarce, expensive and highly concentrated compute.

AI training is the process of building or improving a model using large quantities of data and compute. AI inference is what happens when that trained model is used to answer a question, classify a transaction, generate an image, summarise a document or power a chatbot. Both can depend on large clusters of GPUs or other accelerators, plus fast storage and high-bandwidth networking.

If one facility is damaged, the loss is not just a few generic servers. It may mean lost capacity for model training, reduced chatbot availability, delayed deployments, constrained databases, degraded search, unavailable internal tools and less headroom for failover.

Yandex Cloud status updates illustrate this neatly. One incident update said the ru-central1-b availability zone remained unavailable after a fire caused by a UAV attack at Sasovo, with capacity constraints affecting the creation of new resources such as virtual machines, Kubernetes clusters and databases. Another later update said Vladimir data-centre infrastructure had also been damaged, with operation completely suspended and customers advised to use alternative disaster-recovery plans via Yandex Cloud's own incident page.

That is the practical point: cloud resilience is not magic. It has to be designed, paid for and tested.

The cloud can fail in surprisingly broad ways

Many organisations assume that because something is in the cloud, it is automatically resilient. Sometimes that is true. Often, it is only partly true.

A single data-centre or availability-zone failure can affect several layers at once:

• Compute: applications may lose the servers they run on.
• Storage: databases, file stores and backup systems may become unavailable or degraded.
• Networking: services may be online somewhere, but unreachable to users or other systems.
• Identity: staff and customers may be unable to log in if authentication depends on the affected platform.
• AI services: assistants, recommendation systems, fraud models and search features may slow down or stop.

The discussion source describes disruption reaching consumer services, banking, e-commerce, geolocation, ride-hailing, Yandex's Alisa assistant, multimodal AI chatbots and the judicial system. That is a classic cascade: a technology incident becomes a business-continuity incident, then a public-service incident.

This is also why the AI data-centre build-out has become such a big strategic topic. The industry is not only buying software. It is building an industrial base for compute. I have written separately about why big tech is spending tens of billions on GPUs and data centres, and the same theme appears here from a different angle: whoever controls resilient compute controls a large part of AI capability.

The AI race is also an infrastructure race

The quoted claim from Mikhail Klimarev - that this could set Russia far behind in the AI race - is striking, but it should be handled carefully. The long-term effect is not disclosed, and repairing or replacing capacity depends on hardware availability, site damage, network design, backups and political constraints.

Still, the underlying logic is sound. AI capability is not just about having smart researchers or a good model architecture. It also depends on whether you can run enough training jobs, serve enough users, store enough data, and keep systems online when something goes wrong.

If a country or company loses high-performance compute capacity, it may still have models and software. What it may lack is the ability to train, fine-tune, deploy and scale them reliably. Fine-tuning means adapting an existing model for a narrower purpose, such as customer support, fraud detection or internal document search. That work needs compute too, especially when done at scale.

There is another uncomfortable lesson here: redundancy only helps if it is genuinely independent. A backup in the same facility, same region, same power dependency or same cloud control plane may not be much of a backup.

What UK businesses should take from this

For UK readers, this is not a reason to panic about cloud or AI. Cloud services can be far more resilient than small on-premise server rooms. The point is more practical: you need to know what kind of resilience you have actually bought and tested.

UK organisations should treat AI systems as production dependencies once they support customer service, payments, compliance, logistics, case handling or internal decision-making. A chatbot experiment is one thing. A customer support workflow that cannot function without an AI model API is another.

Here is the checklist I would want a board, IT lead or operations team to ask:

1. Which services are business-critical? Map the customer-facing and internal processes that would cause real harm if unavailable.
2. Which cloud regions and providers do they depend on? Do not stop at the main cloud provider. Include SaaS platforms, AI APIs, identity providers, DNS, payment processors and observability tools.
3. Can the organisation survive a full data-centre or availability-zone outage? Test this rather than relying on architecture diagrams.
4. Is there enough spare capacity elsewhere? Failover is not useful if the backup region cannot create the virtual machines, databases or GPU capacity you need.
5. What happens when AI is unavailable? Define degraded modes, such as manual review, static help pages, non-AI support scripts or read-only access to essential records.
6. Are backups protected and restorable? This matters for ordinary data, but also for AI assets such as model weights, vector databases, training data, fine-tuning datasets and logs.
7. Do contracts explain recovery obligations? Check what your cloud, AI and SaaS providers commit to during outages, capacity shortages or force majeure events.

This matters for small businesses too. You may not run your own AI infrastructure, but you may depend on someone else's. A retailer using cloud stock systems, an agency using AI tools for client work, or a finance firm using third-party analytics all have exposure to infrastructure they do not control.

Data-centre resilience is not only a technical issue

Data centres also raise planning, power, water and local infrastructure questions. The UK debate often focuses on whether communities want these facilities nearby, whether the grid can support them and whether the benefits are fairly distributed. Those concerns are legitimate, as I explored in why AI data centres are facing backlash over water, power and planning.

But the resilience angle cuts the other way. If AI, public services, payments and business operations increasingly depend on data centres, then these facilities need serious protection, scrutiny and contingency planning. Physical security and cyber security are now part of the same risk picture. A destroyed cooling system, power feed or network route can be just as disruptive as a cyberattack.

That does not mean every organisation needs multi-cloud everything. Over-engineering is expensive and can create its own complexity. But important systems deserve proportionate resilience based on their real impact.

The practical lesson: design for failure before failure arrives

The most useful takeaway is simple: cloud and AI resilience must be engineered deliberately.

If your organisation depends on AI, ask what would happen if the model provider became unavailable, the chosen region was capacity-constrained, the vector database failed, or the identity provider stopped accepting logins. If the answer is nervous silence, the risk is already there.

The discussion around Russia's disrupted data centres is dramatic because it involves war and national AI ambitions. For UK organisations, the quieter lesson is more useful. AI may feel weightless on the screen, but it runs on physical infrastructure. When that infrastructure fails, the cleverest software in the world still needs somewhere to run.