Does the EU AI Act apply to our critical infrastructure AI?
If an AI component helps run water, gas, heating, electricity, road traffic or critical digital infrastructure, and it is intended to act as a safety component in managing or operating that service, it is a high-risk AI system under Annex III point 2 of the AI Act. Most such systems do not go through a notified body. They use the internal control procedure in Annex VI, which the operator carries out itself, so the conformity route is the organization's own process. Whether a given component is a safety component depends on its role in the plant or network, so the first decision is a documented scoping review of each AI function against the wording of Annex III point 2, with legal review of borderline cases.
The organization owns the controls and the evidence. Article 15 requires an appropriate level of accuracy, robustness and cybersecurity that holds across the system lifecycle, and Article 15(3) requires the accuracy levels and metrics to be declared in the instructions for use. Those declarations, the technical documentation and the Annex VI records are what an assessor or market surveillance authority will ask for. An implementation partner can prepare the test harnesses, logging, configuration baselines and document set, but it does not issue a conformity declaration or certificate, and the operator remains accountable for what is placed in service.
Confirm the dates early. As amended in 2026, the high-risk rules for Annex III systems apply from 2 December 2027, so a system that enters operation before then still needs its evidence in place when the rules bite, and changes made after that date may trigger new conformity work. Critical infrastructure systems are registered at national level rather than in the EU database, so ask your national market surveillance authority which registration form and process it expects. The consolidated text of the AI Act as amended in 2026 is the primary reference for the exact wording of Annex III point 2 and the applicable articles.
Which of our systems count as safety components?
Classifying an AI system for critical infrastructure is a sequence of decisions, not a single yes or no. Each card below is a point to settle, and to confirm with counsel against the consolidated text, before deciding which AI Act duties apply to a system.
Is the AI a safety component?
Start with whether the AI system is intended to act as a safety component, meaning its failure or malfunction would endanger health, property or the safe running of the service. Supervisory, monitoring and control logic for digital infrastructure, road traffic, water, gas, heating or electricity can qualify. Document the failure scenarios your engineers identified, because they are the evidence that the component is safety-relevant.
Is it intended for management or operation?
Annex III point 2 covers AI used in the management and operation of critical digital infrastructure, road traffic, or the supply of water, gas, heating or electricity. Check the intended purpose stated in your design documents, not only what the model can technically do. A system used for planning or reporting only sits differently from one that drives real-time control of the network.
Is it a non-safety feature?
Many AI features support operators without affecting safety, such as demand forecasting for reports, asset documentation search or customer messaging. Record why each feature has no safety role and whether any output can feed a control decision. Changes to a feature's purpose can move it into scope, so the assessment needs a review trigger.
Does an Annex I product route apply?
If the AI is a safety component of a product covered by EU product legislation listed in Annex I, the system follows the product route with its own dates and conformity procedures, not the Annex III route. Identify which product rules apply to the equipment, controller or device the AI sits inside. The product route determines who performs conformity assessment and when obligations start.
Is it used only for back-office tasks?
Article 6(3) can exempt an Annex III system that performs only narrow procedural tasks, improves a previously completed human activity, or detects patterns without replacing or influencing a human assessment. It does not apply to systems that perform profiling of natural persons. Document the reasoning and the registration decision, and confirm with counsel that the exemption is available for your use.
Are we the provider or the deployer?
The role follows from who develops the system or places it on the market under its own name, and who uses it in operations. Operators that build an AI tool in-house or substantially modify a supplied system may take the provider role. Utilities that buy and run a vendor system usually carry deployer duties, so check contract terms and the vendor's documentation before assigning responsibilities.
What high-risk duties apply to critical infrastructure AI
The core technical duty for a critical infrastructure safety component is the accuracy, resilience and cybersecurity requirement in Article 15 of the AI Act. The system must reach an appropriate level of accuracy, withstand errors, faults and attempts to manipulate it, and keep its performance consistent across its lifecycle, including after updates and retraining. Article 15(3) adds a documentation step that teams often miss: the accuracy levels and the metrics used to measure them must be declared in the instructions for use. For a grid load forecasting model or a water treatment anomaly detector, that means naming the metric (for example, forecast error at a stated horizon or false alarm rate under defined conditions), the test data behind the figure, and the conditions where the figure stops holding. Confirm with your vendor which metrics were measured, on what data, and whether you can reproduce those values in your own environment before you copy them into your file.
Article 15 sits inside a chapter of duties that run across the whole lifecycle. Your quality management system has to cover how the system is designed, tested, changed and monitored. For Annex III point 2 systems, conformity is shown through the internal control procedure in Annex VI, so no notified body is involved. Technical documentation must describe the system in enough detail for an assessor to check it, logging must record events so that operation can be traced after an incident, and human oversight must be designed so that the people responsible for the plant or network can understand the output, detect when it is wrong and stop or override it. A control room operator, for example, needs a written override procedure, and the logs need to show when it was used. Assign each of these duties to a named owner, because providers and operating organizations often split them differently.
Critical infrastructure is the exception to the fundamental rights impact assessment. Article 27(1) requires that assessment before first use of most Annex III high-risk systems by public bodies, private entities providing public services and certain financial deployers, but it does not extend to Annex III point 2 critical infrastructure systems. Do not leave that exclusion implicit in the file. Record in writing that the system falls under Annex III point 2, that no fundamental rights impact assessment is required for it, the date of that decision and who approved it. Then check the other side of the decision: if the same deployment also serves a covered use, such as a public service that uses the system for eligibility decisions, that use still triggers the assessment. Keep this reasoning with the technical file so that an assessor or supervisor can see the exclusion was considered and documented.
Internal control, national registration and where notified bodies fit
This table compares the conformity route, registration, real-world testing and supervision rules for Annex III point 2 safety components in critical infrastructure. Read each row as a question an assessor or regulator will ask, then confirm the national position for your member state.
| Requirement | What applies to point 2 systems | What it means for your program |
|---|---|---|
| Conformity route | Internal control under Annex VI, reached through Article 43(2); no notified body is involved | The provider runs the quality and technical documentation checks itself and keeps the evidence ready for market surveillance |
| EU database registration | Registered at national level rather than in the EU database, under Article 49 | Ask your national authority which registration portal and format it expects before first placing the system on the market |
| Real-world testing registration | Exempt from registering the test in the EU database under Article 71(4) and Article 60(4)(c) | Testing in live conditions still needs its own safeguards and documentation, even though the EU database entry is not required |
| Market surveillance authority | National market surveillance authorities supervise these systems, not the AI Office, under Article 75(1)(a) | Identify the designated authority in each member state where the system is used, since supervision follows the national map |
| Notified body role | Not required for the Annex VI route; notified bodies apply to some biometric systems and Annex I products | Confirm with counsel whether any co-deployed product or component triggers a separate third-party assessment |
| Fundamental rights impact assessment | Not required for critical infrastructure systems under Article 27(1) | Document the reason for the exclusion, and recheck it if the use case widens to public services or credit or insurance pricing |
| Local requirements | National rules, sector regulators and grid or utility codes may add conditions beyond the Act | Confirm local requirements in writing with your national authority and sector regulator before the system goes live |
How to move from classification to a documented internal control file
This sequence takes a critical infrastructure operator from knowing which AI systems are high-risk to holding a dated internal control file, a signed declaration and a national registration record. Plan the work against the 2 December 2027 date for Annex III systems and confirm any earlier local deadlines with your national authority.
Scope and classify each AI system
Start with an inventory of every AI system that touches operations, including vendor products and embedded features. For each one, decide whether it is a safety component in the management or operation of critical digital infrastructure, road traffic, or the supply of water, gas, heating or electricity under Annex III point 2, and whether the Article 6(3) exemption could apply. Your legal and operations teams own this decision, and the output is a signed classification record per system stating the reasoning and the role you hold (provider or deployer). Keep the record with the system's intended purpose, because the classification follows that purpose.
Build the technical file and risk records
For each high-risk system, assemble the technical documentation that describes its design, intended purpose, data, development process and expected behavior in operation. Pair it with a risk management record that identifies foreseeable risks to safety and to the continuity of supply, the controls chosen for each, and the residual risk accepted by a named owner. Engineering and the operations lead prepare these documents, and the output is a versioned technical file that a reviewer can read without asking the authors questions.
Verify accuracy and cybersecurity testing
Test the system against the requirements of Article 15 on accuracy, robustness and cybersecurity, and confirm that performance stays consistent across its lifecycle. Record the accuracy levels and metrics you will declare in the instructions for use under Article 15(3), along with the test conditions that produced them. Security testers and the system's engineers share this work, and the output is a test report with pass or fail results, known limitations and the retest history. Where a figure is not in your own test data, do not declare it.
Run the internal control procedure and sign
For Annex III point 2 systems, Article 43(2) points to the internal control procedure in Annex VI, which does not involve a notified body. Your organization checks that the quality management system, technical file and testing evidence meet the requirements, then the accountable executive signs the EU declaration of conformity. The output is the signed declaration and a dated internal control file that links each requirement to its evidence. Ask any outside assessor you engage to test the file, but remember that the decision and signature remain with your organization.
Register the system at national level
Critical infrastructure systems under Annex III point 2 are registered at national level rather than in the EU database, as set out in Article 49(4) and (5). Confirm with your national authority which registration portal, form and information it expects, using the content of Annex VIII as the reference for the data points. The output is a registration record with the reference number, kept with the technical file and updated when the system changes. Test-related registrations follow Article 71 and Article 60(4)(c), so check those rules before any real-world testing.
Set up post-market monitoring and incident handling
Define how the system's performance and incidents will be monitored after deployment, who reviews the data and how changes trigger a reassessment of the technical file. Prepare an incident procedure that meets Article 73, including the two-day deadline for widespread infringement or serious and irreversible disruption of critical infrastructure and the 10-day deadline for death, with the option to file an incomplete initial report followed by a complete one. The output is a monitoring plan, an incident runbook and a tested contact path to the national authority, reviewed on a fixed schedule and after any material change.
Testing in real conditions and what supervisors will ask
Critical infrastructure operators who test AI before full deployment need to know which testing rules apply, what records they must keep, and what a supervisor will expect to see. The cards below cover the testing exemption, the evidence to retain, how supervision works and how to prepare for an inspection.
Real-world testing exemption from registration
Article 71(4) exempts providers from registering a real-world test of an Annex III point 2 critical infrastructure system in the EU database, which is a narrower point than many teams assume. The exemption covers registration of the test only, not the test itself. Confirm with your national authority and any sector safety regime whether the trial also needs approval, notification or a safety case before it starts.
Test records and safety evidence
Keep a dated record of each test: the system version, the test environment, the operating conditions, the people who approved the trial and the results against the accuracy levels declared in the instructions for use. Record every deviation and every stop decision. Where a test touches live water, gas, heating or power operations, keep the operational safety evidence next to the AI evidence so both can be produced together.
Accuracy and robustness proof
Supervisors will ask whether the system performed within the accuracy levels and metrics declared under Article 15(3), and whether it stayed robust and cyber-resilient across the test period. Prepare the metric definitions, the test datasets, the drift checks and the results for adversarial and degraded inputs. Keep the declared values fixed in the documentation so the test results can be compared against them directly.
How national authorities supervise
National market surveillance authorities supervise AI systems for critical infrastructure, and the AI Office does not take these systems under its exclusive competence. Expect the authority to ask which body is responsible in your Member State, how it can request documentation, and whether sector regulators for energy, water or transport will join the inquiry. Confirm the designated authority for your jurisdiction before the first test.
Incident reporting during testing
A serious incident during a test, such as a serious and irreversible disruption of critical infrastructure, carries a short reporting clock. Under Article 73(3) and (4), the initial report is due within two days for a widespread infringement or serious disruption, and within 10 days where a death occurs. Prepare the notification route, the named contacts and a template for an incomplete initial report that can be completed later under Article 73(5).
Preparing for an inspection
Assemble a single evidence pack before any request arrives: the technical documentation, the test log, the risk and deviation register, the incident procedure and the named accountable owners. Run a mock inspection with staff who did not build the system. Your implementation partner can prepare and organize this evidence, but only the organization and its authorities can answer for it.
Reporting serious incidents to the authorities on time
This sequence turns the Article 73 reporting duty into a tested routine, so that a suspected serious incident reaches the right authority within the short windows the Act sets. Each step produces a record that shows who decided what and when.
Define what counts as a serious incident
Before any incident happens, the compliance lead and the operations owner agree in writing which events in your critical infrastructure AI system would count as a serious incident under Article 73. Cover the two triggers that matter for this sector: a widespread infringement, and a serious and irreversible disruption of critical infrastructure. Add the death trigger as well. Record the definitions in the incident response procedure and confirm them against the current Article 73 text and the Commission's draft guidance. The output is an approved definition sheet that operators can apply without debate during an incident.
Set up triage criteria and a named decision owner
Assign a triage lead who can classify an alert within the operating day, plus a deputy. Give them a short checklist that maps observed effects to the Article 73 triggers, covering safety impact on water, gas, heating, electricity or road traffic operations, the number of affected users or sites, and whether the disruption is reversible. Document who may declare a reportable incident and who signs off the report. The output is a triage record template and a named roster that is tested in a tabletop exercise.
Build the internal escalation path
Map the route from the control room or monitoring team to the triage lead, then to the compliance lead, legal counsel and the executive who can authorize external communication. Set the escalation thresholds in the procedure rather than leaving them to individual judgment at 2 a.m. Include the vendor or integrator responsible for the AI component, because the provider duties and the deployer duties may both be engaged. The output is a documented escalation matrix with contact details kept current and a record of the last test.
Start the clock and record the facts
From the moment an incident is classified as potentially serious, the incident lead opens a single log entry that records the time of detection, the time of classification, the systems involved, and the people notified. Keep the log in a system that cannot be silently edited, so that the timeline can be reconstructed later. Confirm with counsel which authority is the competent national authority for your Member State and the contact route it publishes. The output is a time-stamped incident record that supports the initial report.
File the initial report, incomplete if necessary
Submit the initial report within the deadline that applies to your case: two days for a widespread infringement or serious and irreversible disruption of critical infrastructure, and ten days where a death occurs. Under Article 73(5), an incomplete initial report may be followed by a complete one, so do not hold the submission until every root cause is known. Use the reporting template in the Commission's draft guidance of 26 September 2025 where it fits your case, and check whether a final version has been published before filing. The output is a dated submission receipt and a list of facts still under investigation.
Complete the report and track follow-up
Once the investigation establishes the cause, the incident lead files the complete report and records what changed in the design, data, monitoring or operating procedure. Track each corrective action to closure with a named owner. Feed the findings into the risk management file and the post-market monitoring records, which the provider duties require. The output is a closed incident file linking the timeline, the root cause analysis, the corrective actions and the authority correspondence.
Test the sequence and refresh it
Run at least one tabletop exercise per year that walks a hypothetical critical infrastructure incident through detection, triage, escalation and filing. Illustrative scenario: a control algorithm in a district heating network begins issuing faulty setpoints across several sites. Measure how long each step took against the internal targets you set, and record gaps. Update the procedure, contact lists and template whenever the Commission publishes final guidance. The output is an exercise report with dated corrective actions, which an assessor can review as evidence that the process works.
Who owns the controls and who prepares the evidence
The operator is the organization that places the high-risk system on the market or puts it into service in its own infrastructure, and it keeps legal ownership of the obligations. For a safety component used in managing water, gas, heating, electricity or digital infrastructure, the operator decides whether the system is high-risk, owns the risk management and accuracy decisions, approves the technical documentation, and signs the EU declaration of conformity. The operator also files the registration and handles serious incident reporting to the market surveillance authority.
- Risk and scope decisions: Confirming that the system is a safety component under Annex III point 2 and documenting the reasoning for the classification.
- Declaration and CE marking: Signing the EU declaration of conformity and affixing the marking when the internal control route applies.
- Registration: Registering the system at national level, since critical infrastructure systems in point 2 do not go into the EU database.
- Incident reporting: Owning the reporting clock, including the two-day and 10-day windows in Article 73.
- Post-market monitoring: Keeping logs, watching performance and acting on field data.
Check with your national competent authority and legal counsel which registration form and reporting channel apply in your member state.
An implementation partner such as DeployOpen can help the operator prepare the technical side of the evidence. Work usually covers the self-hosted platform the AI system runs on, the logging and monitoring configuration, the technical documentation pack, test records for accuracy and robustness, and the runbooks that operators follow during an incident. The partner works inside the operator's own cloud accounts, data centers or air-gapped networks, so the operator keeps custody of the evidence from the start.
- Systems and logs: Configuring logging, access control and retention so records of operation can be produced on request.
- Technical documentation: Drafting the system description, data and architecture records that the operator reviews and approves.
- Test evidence: Running accuracy, robustness and cybersecurity tests and recording the metrics that the instructions for use must declare.
- Runbooks: Writing incident response and reporting procedures aligned to the Article 73 deadlines.
- Limits: The partner does not sign the declaration, does not issue a certificate, and does not report incidents on the operator's behalf.
Ask any partner to put in writing which deliverables it produces and which decisions remain with your organization.
Most Annex III point 2 systems follow the internal control route in Annex VI, which involves no notified body, so the operator's own assessment is the conformity step. National market surveillance authorities supervise these systems and can request documentation, test access and incident reports. An independent reviewer or notified body only becomes relevant where a specific rule or national arrangement calls for one, and that depends on the system's classification and member state practice.
- Market surveillance: The national authority can inspect the system, request technical documentation and act on non-compliance.
- Testing exemption: Real-world testing of point 2 systems is exempt from registration in the EU database under Article 71(4), but the operator should confirm national test notification practice.
- Independent review: Where a review applies, the reviewer tests the evidence and issues its own findings, not the operator's declaration.
- Fundamental rights assessment: Not required for critical infrastructure under Article 27(1), but the operator should confirm this against any public service duties it holds.
- Sources to confirm: Your national authority's guidance and the current consolidated text of the Act.
Confirm with the competent authority, in writing, which review route applies before you commit budget to a reviewer.
Common questions from utilities and infrastructure operators
Does a critical infrastructure AI system need a fundamental rights impact assessment?
No, not for Annex III point 2 systems. Article 27(1) requires a fundamental rights impact assessment before first use of certain Annex III high-risk systems, but it explicitly excludes critical infrastructure. The obligation that does apply is the general set of provider and deployer duties, including risk management, logging, human oversight and accuracy, robustness and cybersecurity under Article 15. Operators should still document how the system could affect people and essential services, because that analysis feeds the risk management file even though it is not the formal FRIA. Confirm the exact scope of the exclusion with your national market surveillance authority or legal counsel before you rely on it for a specific system.
Do we need a notified body to assess a critical infrastructure AI system?
Generally no. For Annex III points 2 to 8, Article 43(2) points to the internal control procedure in Annex VI, which involves no notified body. The provider prepares the technical documentation, runs the quality management system, verifies compliance and draws up the EU declaration of conformity itself. Notified bodies matter mainly for certain biometric systems and for Annex I products, so an operator whose safety component is also part of a regulated product should check the product route separately. Ask any consultant who suggests a notified body to show the article that requires one for your specific system.
Where is a critical infrastructure AI system registered?
In the national registration system, not the central EU database. Article 49(4) and (5) place critical infrastructure systems under point 2 in national registration, while law enforcement, migration and border control systems go into a secure non-public section. The provider is responsible for the registration entry, and the information required is set out in Annex VIII. Operators should confirm with their national authority which registry, format and submission route apply, because national arrangements differ across member states.
How does a safety component differ from an ordinary office AI tool?
Under Annex III point 2, the question is whether the system is intended to be used as a safety component in managing or operating digital infrastructure, road traffic, or the supply of water, gas, heating or electricity. A safety component protects people or assets when a failure could cause harm, for example a control function that triggers protective action on a grid or water treatment process. A scheduling assistant, reporting dashboard or helpdesk chatbot in the same organization is usually outside point 2, even though it may still carry transparency duties or other obligations. Classification depends on intended purpose and function, so document the reasoning for each system and review it when the use changes.
What must an operator do itself, and what can a partner prepare?
The organization owns its controls and decisions. As the deployer, the operator must use the system according to its instructions, assign competent human oversight, monitor operation, keep logs under its control, and report serious incidents. Article 73 sets short deadlines: two days for a widespread infringement or a serious and irreversible disruption of critical infrastructure, and 10 days in the event of a death. An implementation partner can prepare logging, monitoring pipelines, test evidence, documentation and runbooks, but it does not issue conformity declarations or registrations on the operator's behalf, and an independent auditor or authority is never the one who certifies compliance. Ask the partner to name which artifacts it delivers and which decisions remain with your staff.
How do system count and evidence maturity change the cost and effort?
Cost follows the number of systems in scope, how much of their documentation already exists, and how much testing and logging must be built. Each system needs its own classification, risk management file, accuracy declaration under Article 15(3), technical documentation and registration entry, so effort scales with the count. Organizations that already run mature change management, testing and security monitoring usually need less new work. Quotes are most useful when they list each system, the artifacts to be produced, the test cases, the environments in scope and what the operator must supply. No duration or fee figure is given here because none is supplied for this topic. Request a fixed-scope written proposal that separates one-time build work from recurring monitoring and retesting.
What to ask an implementation partner before you sign
Start by fixing the scope in writing before any work begins, because a fixed-scope engagement is only as clear as its deliverables. Ask the partner to work from a system inventory that you own: every AI component that performs a safety-component function in water, gas, heating, electricity, road traffic or digital infrastructure, with its supplier, its place in the control architecture and the OT networks it touches. Then require a written list of deliverables, and for each one a statement of the evidence it produces, such as a risk management file, data governance records, technical documentation, logging design, instructions for use that declare accuracy levels under Article 15(3), and the internal control records behind the Annex VI procedure. A deliverable with no named evidence is a deliverable you cannot test later.
Settle the boundary between preparation and certification before you sign. For critical infrastructure systems under Annex III point 2, the conformity route is internal control with no notified body, so the organization, as provider, makes the declaration of conformity and keeps it. The partner prepares systems, controls and evidence; it does not issue a declaration, report or certificate, and no independent body is involved unless a specific product law requires one. Ask who signs the declaration, who keeps the technical documentation available to market surveillance authorities, and who is named as the contact for national registration. Confirm also which regulator will supervise your system, since national authorities, not the AI Office, hold competence for these systems.
Ask how the partner works in OT and air-gapped environments, since that decides whether testing and evidence collection are safe to run at all. Good answers describe a written method for passive observation, change windows agreed with plant operators, offline copies of logs and configurations, and a rule that no test touches a live control loop without the operator's approval. Ask how operational data is handled: where it is stored, who can access it, whether it leaves your network, how it is encrypted and how it is deleted at the end. Ask for the process when a test or change causes an incident, and check that it aligns with your own reporting duties under Article 73, which in this sector can run to two days for a serious and irreversible disruption of critical infrastructure. Request these answers in writing and make them part of the statement of work.
How DeployOpen prepares AI Act evidence for critical infrastructure
DeployOpen is a Chainscore Labs company that plans, implements, hardens, documents and supports self-hosted open-source platforms inside the client's own infrastructure. For critical infrastructure and utilities, we prepare the systems, controls and evidence that an internal-control assessment and national supervision will look at, while the organization keeps ownership of its controls and the conformity declaration.
How we scope
- Confirm which AI systems are safety components in digital infrastructure, road traffic, water, gas, heating or electricity supply.
- Record the Annex III point 2 classification decision and the Article 6(3) reasoning in the written scope.
- Agree in writing which national authority, registration steps and testing conditions apply in each member state.
How we build
- Set up logging, versioning and monitoring for the AI system inside your own cloud accounts, data centers or air-gapped networks.
- Test accuracy, robustness and cybersecurity against the metrics you will declare in the instructions for use.
- Configure incident detection and reporting workflows that support the two-day and 10-day deadlines in Article 73.
How we hand over
- Deliver the technical documentation, test reports and risk management records mapped to your internal control procedure.
- Provide the registration information package for national-level registration, prepared for your review and submission.
- Document runbooks, access records and evidence locations so your team and any independent assessor can trace each claim.
How we support
- Engagements are fixed-scope, with deliverables and timelines agreed in writing before work starts.
- Ongoing support, upgrades and continuous security testing are available as retainers after handover.
- Confirm with your legal counsel and national authority which obligations apply to your organization and system.
