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

This is Part 5 of our five-part series on high-risk AI under the EU AI Act. Each instalment covers one regulated vertical - what "high-risk" means for it, what the current timeline actually requires, and what has to be different about how you build or buy AI in that space. Part 1 covered recruitment and HR tech; 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 power grid, or flags anomalies in a water treatment network. That sounds like exactly the kind of safety-critical AI the EU AI Act was built to regulate - and often, it is. But this is the one vertical in our series where the scope questions get genuinely unsettled: part of what determines whether you're in scope is still draft regulatory guidance, not finalised law.

What just changed

As covered earlier in this series, the "Digital Omnibus on AI" - Regulation (EU) 2026/1744, in force since 27 July 2026 - pushed the compliance deadline for standalone high-risk AI systems back from 2 August 2026 to 2 December 2027. This is now settled, binding law, not a political agreement awaiting ratification - and critical infrastructure is covered by the same postponement as every other vertical in this series.

What wasn't touched by the delay:

Since 2 February 2025: prohibited AI practices are banned outright, and staff AI-literacy obligations apply (the literacy standard itself was softened by the Omnibus, from "ensure" to "support").
Since 2 August 2025: obligations for general-purpose AI models, plus the Act's governance and penalty framework, apply.
From 2 August 2026 (unaffected by the delay): transparency duties apply wherever relevant.

Why infrastructure AI counts as "high-risk" - and where it usually doesn't

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 own text sets out two explicit conditions, confirmed by Recital 55:

It has to 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 don't count. A dashboard that helps an engineer make better decisions isn't automatically a safety component; a system that directly controls a safety-critical function is.
The use case has to match one of the named domains - critical digital infrastructure, road traffic, or water, gas, heating, or electricity supply specifically.

A third condition is commonly cited alongside these two - that the deploying organisation must be a formally designated "critical entity" under the EU's Critical Entities Resilience (CER) Directive - but it's worth being precise about where that comes from. It isn't in the statutory text of Annex III or Recital 55 itself. It reflects the European Commission's draft guidelines on high-risk classification, published for consultation in mid-2026 and still not finalised as of this writing - a strong signal of how the Commission intends to interpret the Act, but not yet settled black-letter law the way the two explicit Recital 55 conditions are.

That distinction matters in practice either way: a great many companies build genuinely useful AI for utilities and infrastructure operators - forecasting, optimisation, predictive maintenance - without the tool qualifying as a safety component rather than a decision-support layer, which on the statutory text alone is already enough to place many of these tools outside this specific high-risk category, before the critical-entity question is even reached.

As with the rest of this series, being potentially in scope isn't the final word either way - the Act's narrower derogation (Article 6(3)) exists for systems that don't pose a significant risk and meet specific conditions, worth confirming with your own advisers rather than assuming.

What actually has to change by December 2027

For a system that does meet the safety-component and named-domain conditions, the obligations lean harder on a few areas than in the rest of this series, given the physical consequences of failure:

Accuracy, robustness, and cybersecurity get real weight. This isn't a checkbox - it's the core of what regulators will scrutinise, given that a failure here can mean an actual outage or safety incident, not just a bad decision.
Human oversight for safety-critical interventions. A person has to be able to intervene before a safety-relevant action is taken, not just review it after the fact.
Logging built for incident reconstruction. If something does go wrong, you need to be able to show exactly what the system saw and decided, in a form that supports a genuine post-incident investigation.
Full technical documentation, conformity assessment, and EU database registration before deployment, plus ongoing monitoring once live.

What we've left out of this piece, on purpose

To keep this readable, we've deliberately skipped some detail: the precise criteria under the CER Directive and how the Commission's classification guidance is likely to firm up, the general-purpose AI model rules, and the overlap with the EU's NIS2 cybersecurity directive - infrastructure operators are very likely already carrying NIS2 obligations that the AI Act layers on top of, not replaces, alongside CER obligations where the critical-entity designation does apply. That overlap is a conversation for your compliance and security teams, not a paragraph in a primer.

What's actually at stake

Fines follow a tiered structure under Article 99, and none of these tiers were changed by the Digital Omnibus:

Up to €35M or 7% of global annual turnover, whichever is higher - reserved for violations of the Act's outright prohibitions (Article 5), not the obligations this post covers.
Up to €15M or 3% - the tier that actually applies to non-compliance with the high-risk obligations described above.
Up to €7.5M or 1% for supplying incorrect or misleading information to a regulator.
For SMEs, each of these caps applies as whichever figure is lower, not higher.

A safety failure in critical infrastructure is rarely just a fine - it's public-facing outages, potential regulatory scrutiny under CER and NIS2 simultaneously where those regimes apply, and the kind of incident that draws attention well beyond a standard compliance breach. Utilities and infrastructure operators procuring AI tools are increasingly asking vendors to clarify safety-component status upfront - a vendor that can't answer clearly adds risk to the deal before it even starts.

Getting ready

If you're building or deploying AI anywhere in infrastructure, utilities, or safety-critical operations and aren't sure whether the safety-component conditions apply to you, get in touch - we'll help you work out whether you're actually in scope, what's already binding today, and what to prioritise before December 2027 arrives faster than expected.

That closes out this run of the series. Recruitment, finance and insurance, education, healthcare, and critical infrastructure each carry their own scope, exceptions, and deadlines - but the same underlying obligations run through all five. If your vertical isn't one we've covered, the same core questions still apply: is your system genuinely in scope, and what would you need to show if asked. Get in touch and we'll help you work it out.

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