High-Risk AI in Critical Infrastructure: the Annex III Category

“AI in critical infrastructure is high-risk” is the version of Annex III point 2 that circulates, and it is wide enough to sweep in every energy company’s chatbot. The annex is narrower than that in two directions at once: it names five infrastructures, and it only catches systems used as safety components.

The five infrastructures the annex names

Point 2 of Annex III to Regulation (EU) 2024/1689 covers AI systems intended to be used as safety components in the management and operation of:

• critical digital infrastructure;
• road traffic;
• the supply of water;
• the supply of gas;
• the supply of heating;
• the supply of electricity.

That is the whole list. Rail signalling, aviation, maritime traffic, hospitals, banking systems, telecommunications as such, food supply and the chemical sector are not in point 2 — not because the legislator thought them unimportant, but because several of them are already regulated as products under the Union harmonisation legislation listed in Annex I, and are therefore captured by Article 6(1) rather than Article 6(2). An AI safety component in a machine, a lift, a medical device or an aircraft is high-risk by the Annex I route, and that route has always run on a later timetable than the stand-alone Annex III one — originally 2 August 2027 against 2 August 2026, and now 2 August 2028 against 2 December 2027 following the amendment described at the foot of this page. If your system is a safety component in a product already covered by Union harmonisation legislation, the later date is the one that applies to it.

Safety component is the filter, not infrastructure

Article 3(14) defines a safety component as a component of a product or of an AI system which fulfils a safety function for that product or system, or the failure or malfunctioning of which endangers the health and safety of persons or property.

Two limbs, and either is enough. The first is about intent: the component is there to keep something safe. The second is about consequence: whether or not safety is its job, its failure endangers people or property. The second limb is why an operational optimisation system can be a safety component without anyone having designed it as one — if the grid-balancing model that nobody called a safety system fails in a way that trips supply, the definition is satisfied by the consequence.

Equally, the definition excludes a great deal of software that sits inside a utility. A demand-forecasting model used for procurement, a customer service assistant, a maintenance scheduler that a human approves, a document search tool over engineering drawings — none of these fulfils a safety function or endangers persons on failure, and none of them becomes high-risk because the company that runs it operates a pipeline. The question the annex asks is about the system’s function, not the sector of its owner.

Recital 55 to the Regulation makes the same point from the other side, describing safety components of critical infrastructure as systems used to protect the physical integrity of the infrastructure or the health and safety of persons and property, which are not themselves necessary for the infrastructure to function. That framing — protective rather than functional — is a useful test when a system sits close to the line.

The Article 6(3) filter is separately available: an Annex III system is not high-risk where it does not pose a significant risk of harm, including by not materially influencing the outcome of decision-making, and one of the four listed conditions applies — narrow procedural task, improving the result of a previously completed human activity, detecting decision patterns without replacing human assessment, or performing a preparatory task. A provider relying on that must document the assessment before placing the system on the market and register it under Article 49(2). Note that the “always high-risk where it performs profiling of natural persons” override in Article 6(3) rarely bites here, because infrastructure safety components generally do not profile people.

What critical digital infrastructure means here

“Critical digital infrastructure” is not defined in Article 3, and reading it as “important software” is the single largest source of over-scoping in this category. Recital 55 anchors the term to the digital infrastructure sector listed in the Annex to Directive (EU) 2022/2555, the NIS2 Directive — which is a specific and closed list: internet exchange point providers, DNS service providers, TLD name registries, cloud computing service providers, data centre service providers, content delivery network providers, trust service providers, and providers of public electronic communications networks and services.

A SaaS application that many businesses depend on is not, on that reading, critical digital infrastructure. A data centre’s AI-driven cooling and power management, or a DNS provider’s automated mitigation system, plausibly is — if it also meets the safety-component definition. The primary text of NIS2 is on EUR-Lex, and the NIS2 obligations for an AI infrastructure provider are covered separately.

The Article 86 carve-out nobody mentions

Article 86 gives any affected person subject to a decision taken by a deployer on the basis of the output of a high-risk system listed in Annex III — where that decision produces legal effects or similarly significantly affects them adversely — a right to obtain clear and meaningful explanations of the role of the AI system in the decision-making procedure and of the main elements of the decision.

Annex III point 2 is expressly excluded from that right. It is the only category carved out. The reason is structural rather than political: point 2 systems act on plant, traffic and networks, not on individuals, so there is no individual decision to explain. The consequence for a compliance programme is that the explanation tooling other Annex III categories need — per-decision records intelligible to a member of the public — is not part of the point 2 obligation set, while Article 12 logging and Article 19 log retention very much are.

What does apply with full force is Article 15. A safety component is exactly the case the accuracy, robustness and cybersecurity requirements were written for: technical redundancy, fail-safe behaviour, resilience against inputs designed to cause the model to err. See what Article 15 requires.

Where NIS2 and the CER Directive sit

Operators in these sectors are usually already regulated twice over. Directive (EU) 2022/2555 (NIS2) imposes cybersecurity risk-management measures and incident reporting on essential and important entities; Directive (EU) 2022/2557 on the resilience of critical entities covers physical resilience for a similar population. Both are directives transposed into national law, so the operative text is the Member State’s, not the Union’s.

The three regimes do not collapse into each other and it is not yet settled how national authorities will coordinate them in practice, since the AI Act market surveillance authority for a given sector may be a different body from the NIS2 competent authority. Where they do meet usefully is evidence: an incident process built for NIS2 reporting can usually be extended to carry the Article 73 serious-incident duty, and a risk-management system built for Article 9 can feed the NIS2 measures. Building them separately is the common and avoidable mistake.

The consolidated Regulation is on EUR-Lex.