EU AI Act Compliance for Critical Infrastructure

The Act has no sector-wide critical-infrastructure regime. Annex III, point 2 is the high-risk area headed “Critical infrastructure”. This site uses the words for AI that reaches the Act through the points below.

• Annex III point 2

  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 are listed in Annex III, point 2. They are high-risk under Article 6(2), subject to Article 6(3). Point 2 has no sub-points. It does not name rail, air or maritime transport, ports or airports. A system for one of these is high-risk only if another point of Annex III or Annex I covers it.

• Only safety components are covered

  A safety component is a component of a product or of an AI system which fulfils a safety function for that product or AI system, or the failure or malfunctioning of which endangers the health and safety of persons or property. A component fulfils a safety function where its intended purpose is to prevent or mitigate risks to health and safety of persons or property (Article 3(14)). AI systems that are solely used for non-safety related aspects of user assistance, performance optimisation, service efficiency, automation or convenience or quality control do not qualify as safety components (Article 6(1a)). AI systems the failure or malfunctioning of which would endanger health and safety do qualify (Article 6(1b)). Article 6(5) required the Commission to provide, no later than 2 February 2026, guidelines with a comprehensive list of practical examples of high-risk and not high-risk use cases. Recital 55 of the 2024 text describes safety components of critical infrastructure as systems used to directly protect the physical integrity of critical infrastructure or the health and safety of persons and property, but which are not necessary for the system to function. It says that components intended to be used solely for cybersecurity purposes should not qualify. A recital is not an operative rule. Whether a given forecasting, optimisation or maintenance tool is a safety component is a question for counsel.

• “Critical infrastructure” and “critical digital infrastructure”

  Article 3(62) defines “critical infrastructure” by reference to Article 2, point (4), of Directive (EU) 2022/2557. The Act has no separate definition of “critical digital infrastructure”, the term used in point 2. Which digital systems it covers is a question for counsel.

• Annex I products are a separate route

  An AI system can also be high-risk under Article 6(1). That requires a safety component of a product, or a product, covered by the Union harmonisation legislation listed in Annex I, where the product must undergo a third-party conformity assessment. Section A of Annex I lists, for example, pressure equipment (item 7) and appliances burning gaseous fuels (item 10). The requirements for these systems apply from 2 August 2028 (Article 113, point (c)(ii)). Section B lists, for example, the rail system (item 17, Directive (EU) 2016/797). For high-risk systems related to products under Section B, only Article 6(1), Article 60a and Articles 102 to 112 apply. Articles 57, 58 and 59 apply only in so far as the requirements for high-risk AI systems have been integrated in that legislation (Article 2(2)). Articles 9 to 15 are not among the provisions that apply.

• Article 6(3) can take a system out of Annex III

  A system under point 2 is high-risk under Article 6(2). Under Article 6(3) it is not high-risk if it does not pose a significant risk of harm to health, safety or fundamental rights. That includes not materially influencing the outcome of decision making. The Act applies this exception where any of the following conditions is fulfilled (Article 6(3), points (a) to (d)). The system is intended to perform a narrow procedural task. Or it is intended to improve the result of a previously completed human activity. Or it is intended to detect decision-making patterns or deviations from prior decision-making patterns and is not meant to replace or influence the previously completed human assessment, without proper human review. Or it is intended to perform a preparatory task to an assessment relevant for the use cases listed in Annex III. How these conditions combine with the significant-risk test is a question for counsel. The system is always high-risk where it performs profiling of natural persons. Profiling is defined by Article 4(4) GDPR (Article 3(52)). A provider that relies on the exception documents its assessment before the system is placed on the market or put into service. It must also register the system (Article 6(4), Article 49(2)).

• Serious incidents at critical infrastructure

  A serious incident includes an incident or malfunctioning of an AI system that directly or indirectly leads to a serious and irreversible disruption of the management or operation of critical infrastructure (Article 3(49), point (b)). The provider’s report is due immediately and not later than two days after the provider or, where applicable, the deployer becomes aware of that incident (Article 73(3)). A deployer that has identified a serious incident informs first the provider, then the importer or distributor and the relevant market surveillance authorities (Article 26(5)). For Annex III systems placed on the market or put into service by providers that are subject to Union legislative instruments laying down equivalent reporting obligations, the notification is limited to the incidents in Article 3(49), point (c) (Article 73(9)). Which instruments count is a question for counsel. Article 113 names no separate date for this provision; see the dates row.

The provider develops an AI system, or has it developed, and places it on the market or puts it into service under its own name or trademark (Article 3(3)). Putting into service includes supply for the provider’s own use (Article 3(11)). A utility, a municipality or a road authority that develops a system and puts it into service under its own name is therefore a provider. One that uses a system under its authority is a deployer (Article 3(4)). A deployer becomes the provider in three cases. It puts its name or trademark on a high-risk system already on the market, without prejudice to contractual arrangements stipulating that the obligations are otherwise allocated. It makes a substantial modification to such a system that leaves it high-risk. Or it changes the intended purpose of a non-high-risk system so that it becomes high-risk (Article 25(1)). The provider that initially placed the system on the market or put it into service is then no longer considered the provider of that specific system, and must closely cooperate with the new provider (Article 25(2)). This does not apply where the initial provider clearly specified that its system is not to be changed into a high-risk AI system.

Providers must ensure that their high-risk systems meet the requirements of Section 2 of Chapter III, Articles 8 to 15 (Article 16, point (a)). They must also meet the other provider obligations of Article 16.

• Art. 9
  Risk management system

  A continuous iterative process over the lifecycle, with testing against prior defined metrics and probabilistic thresholds appropriate to the intended purpose.

• Art. 10
  Data and data governance

  Training, validation and testing data sets that meet the quality criteria of Article 10, including an examination for possible biases.

• Art. 12
  Logging by design

  The system must technically allow for the automatic recording of events (logs) over its lifetime.

• Art. 13
  Instructions for use

  Information that lets deployers interpret the output and use it appropriately, including the declared level of accuracy and its metrics.

• Art. 14
  Human oversight by design

  Measures that let natural persons effectively oversee the system while it is in use.

• Art. 15
  Accuracy, robustness and cybersecurity

  An appropriate level, achieved consistently throughout the lifecycle. The levels of accuracy and the relevant accuracy metrics are declared in the instructions for use.

• Art. 17
  Quality management system

  Written policies, procedures and instructions covering the aspects listed in Article 17(1), implemented in proportion to the size of the provider’s organisation (Article 17(2)).

• Art. 43(2)
  Conformity assessment

  For the systems in points 2 to 8 of Annex III, which include point 2, the provider follows the conformity assessment procedure based on internal control (Annex VI). That procedure does not provide for a notified body. Article 113 names no separate date for this provision; see the dates row.

• Art. 16, 49(1), (5)
  EU declaration, CE marking and registration

  The provider draws up an EU declaration of conformity and affixes the CE marking (Article 16, points (g) and (h)). Article 49(1) excludes systems referred to in point 2 of Annex III from registration in the EU database. Article 49(5) provides that they are registered at national level. Article 113 names no separate date for this provision; see the dates row.

• Art. 72, 73
  Post-market monitoring and serious incidents

  The provider establishes and documents a post-market monitoring system (Article 72(1)) and reports serious incidents to the market surveillance authorities (Article 73). Article 113 names no separate date for this provision; see the dates row.

• Art. 26(1), (2)
  Use as instructed, assign oversight

  Deployers take appropriate technical and organisational measures to use the system in accordance with the instructions for use. They assign human oversight to natural persons who have the necessary competence, training and authority.

• Art. 26(4)–(6)
  Input data, monitoring and logs

  To the extent they control the input data, deployers ensure it is relevant and sufficiently representative. They monitor the operation of the system on the basis of the instructions for use. They keep the logs under their control for at least six months, unless provided otherwise in applicable Union or national law.

• Art. 26(11)
  Inform the persons concerned

  Deployers of high-risk Annex III systems that make or assist decisions related to natural persons inform them that they are subject to the use of the system, without prejudice to Article 50 (Article 26(11)).

• Art. 27(1)
  No fundamental rights impact assessment for point 2

  Article 27(1) requires an assessment of the impact on fundamental rights before a high-risk AI system referred to in Article 6(2) is deployed, “with the exception of high-risk AI systems intended to be used in the area listed in point 2 of Annex III”. A deployer of a point 2 system is therefore not bound by Article 27(1) for that system. For any other high-risk Annex III system it uses, the deployer checks Article 27(1) separately.

• Art. 49(3), (5), 86(1)
  No deployer registration and no right to explanation for point 2

  Article 49(3) excludes systems listed in point 2 of Annex III from the registration of the deployer and of the use in the EU database. Article 49(5) provides that they are registered at national level. Article 86(1) gives the right to explanation for Annex III systems “with the exception of systems listed under point 2”.

• Dates

  The requirements for these Annex III uses apply from 2 December 2027 (Article 113, point (c)(i)). A system placed on the market or put into service before that date is covered only if its design changes significantly afterwards. In any case, providers and deployers of high-risk systems intended to be used by public authorities must take the necessary steps to comply by 2 August 2030 (Article 111(2)). Articles 43 and 49 (Chapter III, Section 5) and Articles 72 and 73 (Chapter IX) sit outside Article 113, point (c). Article 113 names no separate date for them, so by its general rule they apply from 2 August 2026. How this fits with the date above is a question for counsel.

• Fines

  Providers must ensure that their high-risk systems meet the requirements of Section 2 of Chapter III, which includes Articles 9 to 15 (Article 16, point (a)). A breach of the provider obligations in Article 16 or of the deployer obligations in Article 26 can be fined. The fine is up to EUR 15 million or, for an undertaking, up to 3% of its total worldwide annual turnover for the preceding financial year, whichever is higher (Article 99(4), points (a) and (e)). For SMEs, including start-ups, each fine is up to whichever of the two is lower (Article 99(6)). The same applies to small mid-cap enterprises (Article 3(14b), Article 99(6a)). Each Member State lays down rules on to what extent administrative fines may be imposed on public authorities and bodies established in that Member State (Article 99(8)).

• Reach and limits of the Act

  The Act applies to providers and deployers established or located in a third country where the output produced by the AI system is used in the Union (Article 2(1), point (c)). It does not apply to areas outside the scope of Union law, and it does not affect the competences of the Member States concerning national security (Article 2(3)). It does not apply to AI systems where and in so far they are placed on the market, put into service, or used with or without modification exclusively for military, defence or national security purposes (Article 2(3)). It does not apply to obligations of deployers who are natural persons using AI systems in the course of a purely personal non-professional activity (Article 2(10)). The Act does not apply to AI systems or AI models, including their output, specifically developed and put into service for the sole purpose of scientific research and development (Article 2(6)). It does not apply to research, testing or development activity before a system is placed on the market or put into service. Testing in real-world conditions is not covered by that exclusion (Article 2(8)). AI systems released under free and open-source licences are outside the Act. That exclusion does not apply if they are placed on the market or put into service as high-risk AI systems, or if they fall under Article 5 or 50 (Article 2(12)).

• No numeric thresholds or standards for infrastructure

  The Act names no accuracy value, response time, availability level, redundancy level or technical standard for safety components in critical infrastructure. Providers set the metrics for testing (Article 9(8)) and declare the accuracy levels and metrics in the instructions for use (Article 15(3)). The Act itself names no harmonised standard. High-risk systems that conform to harmonised standards published in the Official Journal are presumed to conform to the requirements of Section 2, to the extent those standards cover them (Article 40(1)). Article 42 adds presumptions of conformity with Article 10(4) (paragraph 1) and with the cybersecurity requirements of Article 15 (paragraphs 2 and 3). The Commission is to develop guidelines on the practical application of the requirements and obligations in Articles 8 to 15, 25 and 26 (Article 96(1), point (a)).

• Other law applies alongside the Act

  Other Union and national law continues to apply, for example on the protection of personal data (Article 2(7)) and on product safety (Article 2(9)). Rules on the security of networks and infrastructure are separate from the Act. This page does not describe them.

• Example: one inventory of AI systems

  Example, not an Act requirement: a utility or road authority could keep one inventory of its AI systems. It could list for each system whether it is a safety component in a point 2 area, the Article 6(3) assessment where it relies on one, and whether the organisation is provider or deployer.

Each page applies one article to AI for critical infrastructure.

• Article 9 for Critical Infrastructure AI: Risk Management System

  Risk management system for safety-component AI.

• Article 10 for Critical Infrastructure AI: Data and Data Governance

  Data sets, bias examination and special categories of personal data.

• Article 12 for Critical Infrastructure AI: Record-Keeping and Logs

  Automatic logging, who keeps the logs and serious incidents.

• Article 13 for Critical Infrastructure AI: Transparency and Instructions for Use

  Instructions for use and why Article 86 does not cover point 2.

• Article 14 for Critical Infrastructure AI: Human Oversight

  Human oversight, the stop procedure and what the Act does not require.

• Article 15 for Critical Infrastructure AI: Accuracy, Robustness and Cybersecurity

  Accuracy, robustness and cybersecurity.

• Article 17 for Critical Infrastructure AI: Quality Management System

  Quality management system.

• Article 26 in Critical Infrastructure: Deployer Obligations

  Deployer obligations of utilities, municipalities and road authorities.

• Article 50 for Critical Infrastructure AI: Transparency and Disclosure

  Transparency duties for chatbots and generated content.

• Article 53 in Critical Infrastructure: Obligations of General-Purpose AI Model Providers

  Providers of general-purpose AI models.

• Annex III Deep Dive: All 8 High-Risk Categories

  Point 2 of Annex III in the context of all eight categories.

• Article 6: High-Risk AI System Classification

  How Article 6 classifies high-risk AI systems, including safety components and the Article 6(3) exception.

• Article 27: Fundamental Rights Impact Assessment

  Who must carry out the impact assessment: Article 27(1) excludes systems under Annex III point 2.