AI as a Safety Component in Critical Infrastructure: Annex III Point 2 Under the EU AI Act

An AI system that controls chlorine dosing in a water treatment plant, manages voltage across a transmission grid, or adjusts train spacing on a mainline railway is not just "used in" critical infrastructure — it is part of how that infrastructure stays safe. That distinction is what Annex III point 2 of Regulation (EU) 2024/1689 is built on, and it is the threshold that triggers automatic high-risk classification.

What Annex III Point 2 Actually Covers

Annex III point 2 applies to AI systems intended to be used as safety components in the management and operation of:

• critical digital infrastructure
• road traffic
• the supply of water, gas, heating, or electricity

The phrase "safety component" carries legal weight. It means the AI must be one whose failure or malfunction could endanger the health or safety of persons or the integrity of property. An AI system that merely reports performance data, generates energy-use reports, or helps schedule maintenance crews does not automatically qualify. The question is whether the AI is in the decision-making or control loop in a way that, if it failed, could directly compromise physical safety.

This matters because the classification test for Annex III point 2 is intentional use as a safety component, not sector of deployment. A predictive-maintenance model used at a power station that flags equipment wear is different from an AI that autonomously adjusts load-shedding to prevent grid collapse. The second is a safety component. The first probably is not — unless its outputs feed directly into a control action without human review.

The Article 6(3) Filter Does Not Apply Here

Article 6(3) allows providers of most Annex III systems to self-assess their way out of high-risk classification if the system poses no significant risk of harm — for example, because it performs only a narrow procedural task or improves a previously completed human activity. That filter is meaningful for Annex III points 3–8.

For systems that are genuine safety components in critical infrastructure, the filter is rarely available in practice. If the system's failure can endanger persons, it poses a significant risk of harm by definition. Providers who want to invoke Article 6(3) carry the documentation burden and must still register the system under Article 49. Most safety-component providers will not clear that bar.

Who Bears What Obligations

Providers (AI vendors and developers — Article 16)

If you develop and place the AI system on the market, or put it into service under your own name, you are the provider. The high-risk stack applies in full:

Article 9 — Risk management system. You must establish, maintain, and document a continuous risk management process covering foreseeable hazards, their severity and probability, the controls that reduce residual risk, and the evidence that those controls work. For infrastructure AI, this means mapping not just normal-operation failure modes but also degraded-mode scenarios: sensor dropouts, network latency, data corruption, and adversarial inputs. The system must be designed to fail safe — entering a conservative or halted state rather than an unconstrained one.

Article 10 — Data and data governance. Training, validation, and testing data must be relevant, representative, and free of errors that could distort the system's behaviour under real operating conditions. For safety-critical applications, this includes edge-case coverage: what happens when the system encounters conditions it has never seen before?

Article 11 — Technical documentation (Annex IV). You must compile and maintain the documentation set specified in Annex IV: system architecture, data characteristics, model performance metrics, failure mode analysis, human oversight interface specifications, and post-market monitoring protocols. The documentation must be sufficient for an independent assessor to evaluate whether the system meets the Act's requirements.

Article 13 — Transparency to deployers. Provide instructions for use that cover: intended operational domain; performance characteristics under normal and degraded conditions; known limitations; what the system cannot do reliably; and the requirements for human oversight and incident reporting.

Article 14 — Human oversight. Design the system so that the operator can understand what it is recommending, intervene in real time, and override it without delay. Automation bias — the tendency for operators to defer to the AI even when their judgment would have been better — must be addressed in the interface design, not left as an operator-training problem.

Article 15 — Accuracy, robustness, cybersecurity. The system must maintain performance across its operational lifetime, remain accurate under adversarial conditions, and be designed to resist cybersecurity threats appropriate to its risk profile. For infrastructure AI, this intersects directly with the NIS2 Directive (Directive (EU) 2022/2555), which imposes separate cybersecurity obligations on essential entities. These are parallel regimes; compliance with NIS2 does not satisfy Article 15, but a well-implemented NIS2 programme provides substantial evidence for it.

Article 43 — Conformity assessment. Before you place the system on the market or put it into service, you must conduct a conformity assessment. For Annex III point 2 systems, the applicable route is Annex VI internal self-assessment — unlike biometric systems under point 1, critical infrastructure safety-component AI does not require a notified body. You assess your own documentation, verify that the system meets Articles 9–15, draw up an EU Declaration of Conformity under Article 47, and register the system in the EU database under Article 49 before deployment.

Article 72 — Post-market monitoring. Once deployed, you must actively collect and analyse data on system performance in real-world conditions. If performance degrades, the system must be updated. The post-market monitoring plan should define metrics, monitoring frequency, and the thresholds that trigger corrective action.

Article 73 — Serious incident reporting. If the system is involved in a serious incident — one that results in death, injury, significant property damage, or a serious and irreversible disruption of essential services — you must report it to the market-surveillance authority of the member state where the incident occurred. Timeframes: 15 days from awareness (Article 73(2)); 2 days where the incident constitutes a widespread infringement or a serious and irreversible disruption of critical infrastructure (Article 73(3)); 10 days where a person has died (Article 73(4)). These are not aspirational — they are statutory.

Deployers (infrastructure operators — Article 26)

If your organisation is a power utility, water authority, road traffic management body, or telecommunications operator that deploys a third-party AI system for safety purposes, you are the deployer. Your obligations under Article 26 include:

• Using the system only within its intended purpose as defined by the provider's instructions.
• Maintaining the human oversight mechanisms the provider has designed into the system — and not disabling or bypassing them.
• Monitoring actual performance in your specific operational context and flagging risks and serious incidents to the provider (and, where relevant, directly to the competent authority).
• Retaining automatically generated logs for at least six months (Article 26 — do not cite a sub-paragraph; cite the article).
• Notifying worker representatives before deploying the system in the workplace (Article 26).

Deployers of critical infrastructure AI also sit at the intersection of two other EU frameworks. The NIS2 Directive requires essential entities to implement risk management measures covering, among other things, the security of AI-enabled systems they operate. The Critical Entities Resilience Directive (CER Directive, Directive (EU) 2022/2557) imposes physical and digital resilience requirements on operators of essential services. Where incident reporting overlaps — a serious AI-related incident that is also a NIS2-reportable cybersecurity incident — the general principle is to report once to the appropriate authority and coordinate between your AI Act market-surveillance authority and your NIS2 national competent authority. The legal duties under each regime remain separate; the practical response can be consolidated.

Role Shifts Under Article 25

If your organisation takes a third-party AI system and substantially modifies it — retrains it on your own data, changes its intended purpose, or puts it on the market under your own name — you become the provider for those purposes under Article 25, and the full Article 16 stack applies to you. For infrastructure operators with bespoke AI development programmes, this is the scenario that most often catches people out.

The Conformity Assessment Route in Practice

Annex VI internal self-assessment means exactly what it says: the provider does the assessment. There is no notified body for Annex III point 2 systems, and no EU approval of the assessment itself. What the Act requires is that you conduct the assessment rigorously, document it thoroughly, draw up the EU Declaration of Conformity under Article 47, affix the CE marking under Article 48, and register the system in the EU AI Act database under Article 49 before deployment.

The internal nature of the assessment does not reduce the evidentiary burden. Market-surveillance authorities can inspect the technical documentation at any time. If your documentation cannot demonstrate that Articles 9–15 are met, the system is non-compliant regardless of whether a notified body was involved.

In practice, the Annex IV documentation for a safety-critical system is substantial: architecture diagrams, data provenance records, performance test results across representative and edge-case scenarios, failure mode analysis, human oversight specifications, change management logs, and the post-market monitoring plan. Start assembling it early. The documentation alone takes several months to build credibly for a complex system.

Overlapping Regulatory Obligations: Coordinate, Don't Duplicate

Operators of critical infrastructure face multiple concurrent regulatory regimes. The EU AI Act adds to an existing stack; it does not replace it.

NIS2 Directive: Operators of essential services must implement security risk management measures (Article 21 of NIS2) covering, among other things, AI-enabled systems. NIS2 security testing, incident reporting (NIS2 requires reporting within 24 hours for significant incidents, with a final report within one month), and governance structures can be aligned with — but do not substitute for — EU AI Act obligations. Where both regimes apply, build a single incident-response procedure that satisfies both, and report to the relevant authorities in each.

CER Directive: Operators designated as critical entities under CER must develop resilience plans covering physical and digital threats. AI systems that are part of critical infrastructure will feature in those plans. The risk assessment conducted under CER can inform and be cross-referenced to the Article 9 risk management system, reducing duplicate effort.

The goal is not to run three separate compliance programmes. It is to build one documented framework that satisfies all three, with clear mapping between the requirements of each.

The Deadline: 2 December 2027

The EU AI Act originally set the high-risk deadline at 2 August 2026. That date has been deferred. Under the Digital Omnibus — a political agreement between the Parliament and Council reached on 7 May 2026, with formal adoption expected before the original 2026 general-application date — the obligations for stand-alone high-risk AI systems under Annex III apply from 2 December 2027.

Note that this is the Annex III deadline, and it applies to Annex III point 2 systems because they are assessed under the Annex VI internal-assessment route, not under Annex I product-safety law. The Annex I route (for AI embedded in regulated products like medical devices or machinery) carries the later 2 August 2028 date. For water, grid, traffic, and digital infrastructure AI assessed under Annex III point 2: 2 December 2027.

That is roughly 18 months from mid-2026. For organisations that have not started technical documentation, it is not surplus time. Annex IV documentation for a safety-critical system, written to the standard that would survive an inspection, is typically a six- to nine-month programme for a single system.

Penalties: Article 99(4)

Non-compliance with the high-risk obligations — Articles 9–15, provider obligations under Article 16, and deployer obligations under Article 26 — falls under Article 99(4). The maximum fine is €15,000,000 or 3% of total worldwide annual turnover, whichever is higher. For infrastructure operators and AI vendors alike, the 3% figure will dominate for any organisation of meaningful scale.

There is no "critical infrastructure exemption" from penalties. The Act's enforcement framework expressly anticipates that market-surveillance authorities will coordinate with sector regulators — energy, transport, telecoms — when overseeing AI systems in those sectors.

For smaller vendors and companies, Article 99(6) provides a proportionality protection: the fine is capped at the lower of the percentage and the fixed amount. That is genuine relief for a 15-person AI software company, but it does not eliminate the compliance obligation.

How Confir Helps

Confir's classification module walks you through the Annex III point 2 determination via plain-English scenarios: what does the system output, what happens if it fails, is a human in the loop before the output affects a physical process. The rule-based engine — deterministic, not AI-generated — applies the same logic each time, producing a documented classification finding you can attach to your technical file.

Once classified as high-risk, Confir's assessment framework covers the four compliance areas that map directly to the high-risk stack: risk classification and conformity (Articles 9, 43), data and technical robustness (Articles 10, 11, 15), transparency and human oversight (Articles 13, 14), and governance and post-market monitoring (Articles 9, 72, 73). The output includes a pre-structured Annex IV technical documentation pack and the Article 47 Declaration of Conformity template — both ready for your legal and engineering teams to complete.

Frequently Asked Questions

Does Annex III point 2 apply only to the AI vendor, or to the infrastructure operator too?

Both. The vendor who develops and places the system on the market is the provider under Article 16 and bears the heaviest obligations: risk management, technical documentation, conformity assessment, post-market monitoring, serious incident reporting. The infrastructure operator who deploys the system is the deployer under Article 26, with duties to use the system as intended, maintain human oversight, monitor performance, and retain logs. If the operator substantially modifies the system or puts it on the market under its own name, Article 25 converts it into a provider.

What makes an AI system a "safety component" rather than just a tool used in critical infrastructure?

The test is whether the AI is in the control or decision-making chain in a way that, if it failed or produced an incorrect output, could directly endanger health, safety of persons, or the integrity of essential services. An AI that autonomously adjusts power-grid load balancing, controls train spacing, or regulates chemical dosing in a water treatment plant is a safety component. An AI that generates performance reports or schedules maintenance windows without feeding into a control action is not — unless its outputs are acted on without human review, in which case the analysis changes.

Is a notified body required for Annex III point 2 systems?

No. Critical infrastructure safety-component AI is assessed under the Annex VI internal self-assessment route (Article 43). The provider conducts and documents the assessment, draws up the EU Declaration of Conformity (Article 47), and registers the system (Article 49) before deployment. Notified bodies are required for Annex III point 1 biometric systems, not for points 2–8. That said, internal does not mean informal — the technical file must meet the same evidential standard.

How do the EU AI Act obligations relate to NIS2 cybersecurity requirements?

They are parallel, not overlapping. NIS2 imposes cybersecurity risk management and incident-reporting obligations on essential entities operating in sectors including energy, transport, and water. The EU AI Act's Article 15 requires AI systems to resist cybersecurity threats appropriate to their risk profile. A well-implemented NIS2 programme generates strong evidence for Article 15, but does not satisfy Article 43 conformity assessment or any other high-risk obligation. Where an AI-related incident also qualifies as a NIS2 incident, design your response procedure to satisfy both reporting chains with a single coordinated report where possible.

What is the deadline, and does it apply to systems already deployed?

The deadline for stand-alone high-risk Annex III systems is 2 December 2027, under the Digital Omnibus agreed in May 2026. Systems already deployed when the obligations apply must be brought into compliance — they are not grandfathered. If your system was deployed before the obligations take effect, you will need retroactive documentation: risk management assessment under Article 9, technical documentation under Article 11, and the conformity self-assessment under Article 43. Start now; the documentation work is substantial.

What are the penalties for non-compliance?

Under Article 99(4), the maximum fine for non-compliance with high-risk obligations is €15,000,000 or 3% of total worldwide annual turnover, whichever is higher. This covers breaches of Articles 9–15, provider obligations (Article 16), and deployer obligations (Article 26). For smaller companies, Article 99(6) caps the fine at the lower of the percentage and the fixed amount. There is no sector carve-out for critical infrastructure — enforcement is expected to be coordinated between market-surveillance authorities and sector regulators.

Related guides

• Article 6 high-risk classification
• Article 6-11 risk classification requirements
• SaaS provider compliance obligations
• Article 3 key definitions
• AI governance software comparison
• Annex III high-risk use cases