EU AI Act High-Risk Series, Part 5: Critical Infrastructure

Part 5 of our five-part series on high-risk AI under the EU AI Act, written for the directors who have to decide what to build, buy and sign off. Part 1 covered recruitment and HR technology; Part 2 covered finance and insurance; Part 3 covered education and EdTech; Part 4 covered healthcare and MedTech.

An AI system balances load across a regional grid, or flags anomalies in a water treatment network. That sounds like exactly the safety-critical AI the EU AI Act was written for, and often it is. But this is the one sector in the series where part of the scope question still rests on draft guidance rather than finalised law, and where many useful products turn out to sit outside the high-risk category altogether. For utilities, infrastructure operators and the vendors that supply them, knowing which side of that line you are on is worth establishing before the next procurement round asks.

What has changed

The "Digital Omnibus on AI", Regulation (EU) 2026/1744, in force since 27 July 2026, moved the compliance deadline for standalone high-risk AI systems from 2 August 2026 to 2 December 2027. That is settled law, and critical infrastructure is covered by the same postponement as every other sector in the series.

What the delay did not touch:

• Since 2 February 2025: prohibited practices and staff AI-literacy obligations (softened from "ensure" to "support").
• Since 2 August 2025: general-purpose model obligations and the governance and penalty framework.
• From 2 August 2026: transparency duties.

Which infrastructure AI is high-risk, and which usually is not

Annex III, point 2 names AI used as a safety component in the management and operation of critical digital infrastructure, road traffic, or the supply of water, gas, heating or electricity. The Act's text, confirmed by Recital 55, sets two conditions:

1. It must be a genuine safety component: something that directly protects the physical integrity of the infrastructure or the health and safety of people and property, where its failure could directly cause harm. Recital 55 is explicit that cybersecurity-only components do not count. A dashboard that helps an engineer decide is not automatically a safety component; a system that directly controls a safety-critical function is.
2. The use must fall in a named domain: critical digital infrastructure, road traffic, or water, gas, heating or electricity supply.

A third condition is often cited: that the deploying organisation be a designated "critical entity" under the Critical Entities Resilience (CER) Directive. That condition is not in the statutory text. It comes from the Commission's draft classification guidelines, published for consultation in mid-2026 and not yet final: a strong signal of intended interpretation, not settled law.

In practice, the first condition already places many products outside this category. Forecasting, optimisation and predictive maintenance tools built for utilities are usually decision support rather than safety components, before the critical-entity question is reached. As elsewhere, Article 6(3) offers a narrow derogation to confirm with your advisers rather than assume.

What has to be in place by December 2027

For a system that does meet the safety-component and named-domain conditions, the obligations weigh more heavily on a few areas, given the physical consequences of failure:

• Accuracy, robustness and cybersecurity carry real weight. A failure here can mean an outage or a safety incident, not only a bad decision.
• Human oversight before safety-critical actions. A person able to intervene before a safety-relevant action, not only review it afterwards.
• Logging built for incident reconstruction, showing what the system saw and decided in a form that supports a proper investigation.
• Technical documentation, conformity assessment and EU database registration before deployment, and monitoring once live.

What is left out, deliberately

The precise CER criteria and how the classification guidance will firm up; the general-purpose model rules; and the overlap with the EU's NIS2 directive. Infrastructure operators are very likely already carrying NIS2 obligations that the AI Act layers on top of, alongside CER obligations where the designation applies. Much of the logging, resilience and oversight work serves all three.

What is at stake commercially

Fines under Article 99 are tiered and unchanged: up to €35M or 7% for breaching a prohibition; up to €15M or 3% for high-risk non-compliance; up to €7.5M or 1% for misleading a regulator; for SMEs, the lower figure.

A safety failure in critical infrastructure is rarely only a fine. It is a public outage, scrutiny under CER and NIS2 at the same time where they apply, and attention well beyond a compliance breach. Operators procuring AI tools are already asking vendors to state safety-component status up front. A vendor that cannot answer clearly adds risk to the deal; a vendor that can, and can show the logging and oversight behind the answer, shortens the sale.

What to do now

1. Determine, per system, whether it is a safety component or decision support, and write the reasoning down with reference to Recital 55.
2. Watch the Commission's classification guidance for the critical-entity condition, and know whether you are a designated entity under CER.
3. For in-scope systems, design oversight before action and logging for reconstruction now; both are also NIS2 evidence.
4. Prepare the safety-component statement operators will ask for in procurement.

How Hexploits helps

We do the engineering side of EU AI Act readiness, and the monitoring, observability and continuity work that in-scope systems depend on. We are the core team behind swarmd.ai, an EU AI Act readiness platform for governing AI agents in regulated industries, and the tamper-evident audit and human-in-the-loop patterns built there are the ones we apply to operational systems.

That closes this run of the series. Recruitment, finance and insurance, education, healthcare and critical infrastructure each carry their own scope and deadlines, but the same underlying obligations run through all five. If your sector is not one of them, the same two questions apply: is your system genuinely in scope, and what would you need to show if asked. Request a proposal or talk to an engineer and we will help you answer both.

This is our view of the operational and technical side of compliance, not legal advice. Pair it with your legal counsel for formal sign-off.