Critical Digital Infrastructure AI Under the EU AI Act: Annex III Point 2
AI as a safety component running critical digital infrastructure — data centres, networks, DNS — is high-risk under Annex III point 2. IT-ops AI is not.
Most AI running inside a data centre or a network operations team is not high-risk. The narrow slice that is high-risk is AI used as a safety component in the management and operation of critical digital infrastructure — and that phrase, from Annex III point 2 of the EU AI Act, Regulation (EU) 2024/1689, is doing precise work. An autoscaler, a capacity-planning model, or a log-anomaly classifier is ordinary IT operations. A model whose failure would knock out an essential network, a core DNS resolver, or a data centre that society depends on, in a way that endangers people or breaks the supply of an essential service, is the part that qualifies.
If you run a data centre, a telecom or backbone network, a CDN, or a managed DNS service, this page draws the line between safety-component AI and everyday IT-ops AI — and explains why the distinction, not the tech stack, decides the tier.
What "critical digital infrastructure" means here
Point 2 makes high-risk AI intended to be used as a safety component in the management and operation of critical digital infrastructure, road traffic, or the supply of water, gas, heating and electricity. "Critical digital infrastructure" is not every server rack — it tracks the systems whose continuity society and the wider economy rely on: core network and routing, internet-exchange and DNS infrastructure, and the data centres and digital services treated as critical or essential under the EU's broader resilience regimes (the CER Directive for critical entities and NIS2 for essential and important entities). The AI Act borrows that gravity: the infrastructure has to be genuinely critical and the AI has to be a safety component of running it.
A safety component, as Article 3(14) now defines it after Regulation (EU) 2026/1744, is one that fulfils a safety function — its intended purpose is to prevent or mitigate risks to the health and safety of persons or property — or whose failure or malfunction would endanger the health and safety of persons or property. In critical infrastructure, recital 55 gives the typical case: a failure that puts people's health and safety at risk at scale and appreciably disrupts the essential service. Both halves — critical infrastructure and safety component — must hold.
The line: safety-component AI vs ordinary IT-ops AI
This is where most digital-infrastructure operators land in the minimal-risk tier. Day-to-day AIOps — autoscaling compute, predicting capacity, classifying log anomalies, routing helpdesk tickets, optimising cooling for efficiency, recommending a config change for a human to approve — is ordinary IT operations. None of it is a safety component in the Annex III sense; a wrong autoscaling decision degrades a service, it does not endanger the continuity of critical infrastructure in the way point 2 contemplates. That is minimal-risk, no mandatory obligations.
The high-risk sliver is AI woven into the safety-critical control of the critical asset itself: a model that autonomously controls failover and traffic routing for a backbone whose collapse would cut off essential communications, that drives the safety envelope of a critical data-centre's power and cooling, or that manages the resilience of core DNS resolution that essential services depend on — where its malfunction would break the supply.
| Digital-infrastructure AI use | Classification | Why |
|---|---|---|
| Safety-critical failover / routing control for a critical network | High-risk | Safety component, Annex III pt 2 |
| Resilience control of core DNS / IXP infrastructure | High-risk | Safety component, Annex III pt 2 |
| Power-and-cooling safety control of a critical data centre | High-risk | Safety component, Annex III pt 2 |
| Autoscaling, capacity forecasting, cost optimisation | Minimal-risk | Ordinary IT-ops, not a safety function |
| Log-anomaly detection / observability | Minimal-risk | Ordinary IT-ops |
| Helpdesk triage, config recommendations for human approval | Minimal-risk | Ordinary IT-ops |
The honest sanity check: would this model's failure, on its own, endanger people or break the continuity of a critical digital service? For the overwhelming majority of AIOps tooling the answer is no, and the page ends at minimal-risk. Reserve the high-risk label for the genuine safety-control cases — over-claiming high-risk is as much a misclassification as missing one.
What high-risk digital-infrastructure AI owes
Where a system clears the safety-component test, the full high-risk regime applies. The provider (whoever builds it and places it on the market under their own name, Article 16) owes risk management (Article 9), data governance (Article 10), technical documentation (Article 11 / Annex IV), logging (Article 12), human oversight (Article 14), and accuracy, robustness and cybersecurity (Article 15). Conformity runs through the Annex VI internal-control route under Article 43 — no notified body outside biometrics — then the Declaration of Conformity (Article 47) and CE marking (Article 48); as an Annex III point 2 critical-infrastructure system it registers at national level (Article 49(5)), not in the public EU database. The operator, usually the deployer, carries the Article 26 duties: operate per instructions, assign human oversight, monitor, and retain the logs. NIS2 and CER obligations run in parallel and are not displaced by the AI Act.
Deadline. Stand-alone high-risk Annex III obligations were originally timetabled for 2 August 2026; the Digital Omnibus moved that to a fixed 2 December 2027. The deferral is law — Regulation (EU) 2026/1744 was published in the Official Journal on 24 July 2026 and has been in force since 27 July 2026. Plan against 2 December 2027.
Worked example: Nordkern Datacenter OÜ
Nordkern Datacenter OÜ operates a colocation data centre in Tallinn classified as an essential entity under NIS2, ~95 employees, ~€22M turnover. It runs three AI tools.
- An autonomous failover-and-load-shedding controller that, on a power or cooling fault, decides which critical workloads to keep alive and how to re-route — protecting the safety envelope of an essential facility. This is a safety component under Annex III point 2 — high-risk. Nordkern is the deployer.
- A cooling-efficiency optimiser that trims energy use under normal conditions. Ordinary IT-ops — minimal-risk.
- A capacity-forecasting model for sales and procurement planning. Back-office — minimal-risk.
Nordkern scopes the high-risk obligations to the failover controller only, runs Article 14 oversight and Article 15 robustness/cybersecurity work, keeps the logs, and documents why the optimiser and forecaster stay minimal-risk. It is already an NIS2 essential entity, so those cybersecurity duties run alongside. As an SME it benefits from the Article 99(6) cap.
How Confir helps
Confir registers each digital-infrastructure AI use, derives the role (deployer under Article 26, provider under Article 16 if you build the control system), and applies the safety-component test to separate genuine Annex III point 2 safety control from ordinary IT-ops AI that stays minimal-risk. For qualifying systems it assembles the provider and deployer obligations, with the Article 15 robustness-and-cybersecurity weight these assets demand, and flags the parallel NIS2/CER overlap. The engine is deterministic and rule-based, with every finding cited to the rule that fired.
Related guides
- Critical infrastructure AI under Annex III point 2
- How Article 6 classifies high-risk AI
- What counts as a safety component
- Accuracy, robustness and cybersecurity (Article 15)
- Deployer obligations under Article 26
- EU AI Act for cybersecurity teams
Manage your EU AI Act compliance in one place
Confir automates risk classification, technical documentation, and audit trails for any company. No consultants. No 6-month projects. 14-day free trial.
Start free trial →