Skip to main content

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

How Article 13 (transparency and instructions for use) applies to AI for critical infrastructure: what the provider tells the deployer, why Article 86 does not cover point 2, dates, fines and what the Act leaves open.

Providers of high-risk AI systems for critical infrastructure must give deployers instructions for use that let them interpret the output (Article 13).

These are AI systems intended as safety components under Annex III, point 2. The duty applies from 2 December 2027, unless the Article 6(3) exception applies. The right to an explanation under Article 86 does not cover point 2. Fines can reach up to EUR 15 million or, for an undertaking, up to 3% of worldwide annual turnover, whichever is higher (Article 99(4)). Next step: draft the instructions per Article 13(3).

Article 13 is about instructions for the deployer

Article 13 sets duties for the provider towards the deployer. It sets no duty to publish information or to explain a decision to an affected person.

  • Art. 13(1)
    Transparency that lets deployers interpret outputs

    High-risk AI systems must be designed and developed so that their operation is sufficiently transparent to enable deployers to interpret the output and use it appropriately. An appropriate type and degree of transparency must be ensured, so that the provider and the deployer can meet their obligations in Section 3.

  • Art. 13(2)
    Instructions for use

    High-risk systems must be accompanied by instructions for use in an appropriate digital format or otherwise. They must contain concise, complete, correct and clear information that is relevant, accessible and comprehensible to deployers.

  • Art. 13(3)(a), (b)
    Minimum content: provider, performance and limits

    The instructions must contain at least the provider’s identity and contact details, and the characteristics, capabilities and limitations of performance of the system. These include its intended purpose. They include the level of accuracy, including its metrics, robustness and cybersecurity against which the system was tested and validated and which can be expected, and known circumstances that may affect it. They include known or foreseeable circumstances that may lead to risks to health, safety or fundamental rights. Where applicable or appropriate, they also include the technical capabilities to explain the output, the performance for specific persons or groups, specifications for input data, and information that lets deployers interpret the output.

  • Art. 13(3)(c)–(f)
    Changes, oversight, resources and logs

    The instructions must also state the changes pre-determined by the provider at the initial conformity assessment, if any, and the human oversight measures under Article 14. They must state the computational and hardware resources needed, the expected lifetime and the maintenance measures, including software updates. Where relevant, they describe the mechanisms that let deployers collect, store and interpret the logs in line with Article 12.

Which critical-infrastructure AI must meet Article 13

Article 13 applies to high-risk AI systems only. The rows below show where AI for critical infrastructure becomes high-risk.

  • Critical infrastructure is an Annex III area, not a sector-wide regime

    The Act has no sector-wide critical-infrastructure regime for providers or deployers. Annex III, point 2 is the high-risk area headed “Critical infrastructure”. This site uses the words for AI that reaches the Act through it. Point 2 covers 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. 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”. Point 2 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.

  • 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)).

  • 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.

  • Provider and deployer

    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.

  • Article 86 does not cover point 2

    Article 86(1) gives an affected person a right to explanation of a decision taken by the deployer on the basis of the output of an Annex III high-risk system, “with the exception of systems listed under point 2”. A deployer of a point 2 system is therefore not bound by it. Deployers of high-risk systems referred to in Annex III that make decisions or assist in making decisions related to natural persons must inform them that they are subject to the use of the system (Article 26(11)).

  • 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)).

What the Act leaves open for critical infrastructure

  • No format for instructions for use in infrastructure

    The Act names no format, template or wording for instructions for use of infrastructure safety components. The provider decides how to present the items required by Article 13(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)). 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)).

  • Example: operating conditions in the instructions

    Example, not an Act requirement: instructions for use of a safety component could state the operating conditions in which its accuracy was measured and the conditions in which its output should not be relied on. Article 13(3), point (b)(ii) and (iii) ask for the tested accuracy level and for circumstances that may affect it or lead to risks.

  • Example: describing the stop procedure

    Example, not an Act requirement: instructions for use could describe the stop procedure and the state the system reaches when it halts. Article 13(3), point (d) asks for the human oversight measures under Article 14.

Questions about Article 13 in critical infrastructure

Must the provider publish information about an infrastructure safety component?

Article 13 requires instructions for use that are relevant, accessible and comprehensible to deployers (Article 13(2)). It sets no duty to publish them to the public.

Must the instructions for use state the system’s accuracy?

Yes. Article 13(3), point (b)(ii) requires the level of accuracy, including its metrics, robustness and cybersecurity against which the system was tested and validated and which can be expected. The Act names no value.

Does a person affected by a utility’s AI-assisted decision have a right to an explanation?

Not under Article 86 for a system under point 2, which Article 86(1) excepts. Article 26(11) can still require the deployer to inform natural persons that they are subject to the use of the system.

Scanara prepares evidence from your repositories

Scanara reads your connected GitHub repositories and runs rule-based scans for standard AI and machine-learning patterns. It can miss non-standard code. Separately, it generates draft documentation from templates and your assessment answers as evidence for your compliance work. You make the classification decisions.