EU AI Act: High-Risk AI in Critical Infrastructure (Annex III Point 2)

Overview: Why Infrastructure AI Is Singled Out

Annex III point 2 of the EU AI Act (Regulation (EU) 2024/1689) classifies as high-risk those AI systems intended to be used as safety components in the management and operation of critical digital infrastructure, road traffic, or in the supply of water, gas, heating or electricity. The logic is straightforward: when an algorithm helps keep a power grid balanced, a water network pressurised or traffic lights sequenced, a malfunction is not a customer service problem — it can endanger lives, public health and the continuity of essential services at scale.

This category differs from most other Annex III points in one important respect. The risks it targets are primarily to physical safety and service continuity rather than to fundamental rights such as non-discrimination or privacy. That shapes how the high-risk requirements should be implemented in practice: accuracy, robustness, cybersecurity and fail-safe behaviour carry the most weight.

What the Provision Actually Covers

The decisive concept is the safety component. Article 3(14) defines it as a component of a product or system that fulfils a safety function for that product or system, or whose failure or malfunctioning endangers the health and safety of persons or property. An AI system is therefore captured by point 2 when it performs a safety function within the listed infrastructure, not merely because it operates somewhere inside an infrastructure organisation.

Three domains are listed:

• Critical digital infrastructure — this connects to the framework of Directive (EU) 2022/2557 on the resilience of critical entities, which treats digital infrastructure such as internet exchange points, DNS service providers, top-level-domain registries and cloud and data centre services as critical sectors
• Road traffic — for example AI controlling traffic signal networks, motorway management systems or tunnel safety systems
• Supply of water, gas, heating and electricity — AI managing grid stability, pressure control, load balancing or leak and fault response

The recitals clarify the boundary: safety components in this context are systems used to directly protect the physical integrity of infrastructure or the health and safety of persons and property, such as systems monitoring water pressure or fire alarm control systems in cloud computing centres. Components used purely for cybersecurity purposes are not treated as safety components under this point, and an AI system that merely produces analytics dashboards for engineers, without fulfilling a safety function, is generally outside it.

What Is Likely Outside the Category

Not every AI deployment at a utility or transport operator is high-risk under point 2. Demand forecasting for energy trading, predictive maintenance scheduling that feeds a human work order queue, customer churn models, chatbots and billing optimisation do not normally fulfil a safety function. The test is functional: would failure or malfunctioning of this specific AI component endanger health, safety or property through the management and operation of the infrastructure? If the system only informs commercial decisions, or if a conventional engineered safety layer fully contains the consequences of AI failure, the classification analysis may come out differently — but that analysis must be documented, especially where a provider intends to rely on the Article 6(3) derogation.

Note also the interplay with Article 6(1). AI embedded as a safety component in products covered by Annex I harmonisation law (for example machinery or rail interoperability legislation) follows the product route, with compliance dates in 2027. Point 2 of Annex III addresses infrastructure operation use cases that are not already captured through that product law route.

Who Must Comply

Two groups carry obligations. Providers — typically industrial software vendors, SCADA and energy management system suppliers, smart grid platform developers and traffic management vendors — must implement the Chapter III Section 2 requirements: a risk management system (Article 9), data governance (Article 10), technical documentation (Article 11), record keeping (Article 12), transparency to deployers (Article 13), human oversight design (Article 14) and accuracy, robustness and cybersecurity (Article 15). They must complete conformity assessment, affix CE marking and register the system in the EU database.

Deployers — grid operators, water utilities, district heating companies, road authorities and operators of critical digital infrastructure — must operate the system according to the instructions for use, assign trained human oversight, monitor performance, retain automatically generated logs for at least six months and report serious incidents. Many of these organisations are simultaneously in scope of NIS2 and the Critical Entities Resilience Directive, so AI Act controls should be folded into existing resilience and incident management programmes rather than built in parallel.

Practical Compliance Priorities

1. Inventory all AI components in operational technology environments and tag those fulfilling safety functions
2. Clarify provider and deployer roles with vendors, including responsibility for technical documentation and logs
3. Stress-test accuracy and robustness under abnormal grid or traffic conditions, not just average load
4. Define human oversight that is real: operators must be able to intervene, override or shut down the AI function safely
5. Align AI incident reporting with existing NIS2 and sector incident processes; Article 73 requires reporting of serious incidents, including infrastructure disruptions
6. Document fallback behaviour: what the system does when inputs degrade, sensors fail or the model encounters out-of-distribution conditions

Concrete Examples

Example one: a vendor sells an AI-based voltage stability controller that autonomously adjusts reactive power in a distribution grid. Failure could trigger outages and equipment damage. This is a safety component in electricity supply — high-risk, with the vendor as provider and the grid operator as deployer.

Example two: a city deploys an adaptive traffic signal system that uses computer vision to modify light phasing in real time. Malfunction could cause collisions. This falls under road traffic management — high-risk.

Example three: a data centre operator uses machine learning to optimise cooling energy costs, with conventional thermal protection systems retaining full authority to shut equipment down. The AI optimiser arguably fulfils no safety function; the documented analysis may support a non-high-risk conclusion. The same model given direct authority over cooling safety thresholds in critical digital infrastructure would land back in point 2.

Preparing for August 2, 2026

The high-risk obligations for Annex III systems apply from August 2, 2026. Infrastructure procurement cycles are long, so deployers should act now: insert AI Act conformity clauses in tenders, ask vendors for their classification analysis and technical documentation roadmaps, and budget for oversight training. Providers should sequence conformity assessment work immediately — most point 2 systems can use the internal control procedure of Annex VI, but it still requires complete technical documentation and a functioning quality management system under Article 17. A system already on the market before August 2, 2026 is caught when it undergoes a significant change in design, so version planning matters. Regulators in the energy and transport sectors will coordinate with market surveillance authorities, and operators that can show integrated AI risk management within existing safety cases will be in the strongest position.

Relationship With NIS2 and the CER Directive

Critical infrastructure operators already live under two adjacent EU frameworks, and the AI Act is designed to slot alongside them rather than replace them. The NIS2 Directive imposes cybersecurity risk management and incident reporting on essential and important entities, including energy, water, transport and digital infrastructure. The Critical Entities Resilience Directive (EU) 2022/2557 imposes physical and operational resilience duties on designated critical entities. The AI Act adds a third layer focused on the AI component itself: how it was trained, how it behaves under stress, how humans supervise it and how its failures are reported.

The practical consequence is that the same incident can trigger multiple reporting clocks. An AI malfunction in a grid control system that disrupts supply may be a serious incident under Article 73 of the AI Act, a significant incident under NIS2, and an event reportable under sector rules. Mature operators are building unified incident taxonomies and single intake processes that fan out to the relevant regulators, rather than asking control room staff to make legal classifications during an outage. Similarly, evidence produced for AI Act conformity — robustness testing, fallback design, oversight procedures — should be cross-referenced in NIS2 risk analyses and CER resilience plans so that each framework reinforces rather than duplicates the others. Vendors who can hand their utility customers a documentation package mapped to all three frameworks will find procurement doors opening faster than those who treat the AI Act in isolation.

One further coordination point deserves attention: harmonised standards. Article 40 of the AI Act gives a presumption of conformity to systems built to harmonised standards once these are cited in the Official Journal, and European standardisation work for AI covers risk management, data quality and robustness. Infrastructure operators already apply functional safety standards in their engineering practice, and the most efficient compliance route is to map AI Act requirements onto that existing standards culture. Engineering teams that document AI components with the same rigour they apply to protection relays and safety instrumented systems will find that the AI Act asks for discipline they largely already have — the new work is mostly in data governance, oversight design and the documentation format.

This article is for informational purposes only and does not constitute legal advice. Regulatory requirements change frequently — verify current rules with official sources. Built by Sawai Gyoseishoshi Office, Hiroshima, Japan.