Domain 2 of Annex III AI Act covers AI systems functioning as safety components in critical infrastructure. The Commission guidelines of 19 May 2026 connect this closely to the NIS2 Directive and the CER Directive on critical entities. The critical interpretation: only safety components are in scope, not all AI in the sector.
For the general framework, see the main article on the Article 6(3) filter. For all domains, see the hub overview.
The Six Use Cases of Domain 2
Domain 2 lists six sectors in which AI as safety component is high-risk:
- Critical digital infrastructure
- Road traffic
- Water supply
- Gas supply
- Heating supply
- Electricity supply
What Is a "Safety Component"?
The guidelines explicitly refer to the definition in Article 3(14) AI Act: a component performing a safety function or whose failure or malfunctioning endangers the health and safety of persons or property.
High-risk:
- AI in transport system control (train signalling, traffic lights, smart intersections)
- AI in drinking water control and treatment
- AI in gas detection and leak networks
- AI in load balancing of electricity grids where failure can cause outages
- AI in industrial control systems of power plants
- AI in security of data centres and critical network infrastructure
Outside scope:
- AI in administrative planning at utilities (without safety function)
- AI in customer service of energy companies
- AI in marketing or dynamic pricing by suppliers
- AI in energy consumption forecasting at aggregate level
Interaction with NIS2 and CER
The Commission guidelines explain the AI Act applies alongside NIS2 and the CER Directive, not instead of. An entity can simultaneously be an "essential entity" under NIS2, a "critical entity" under CER, and a deployer of high-risk AI under the AI Act. Compliance must then be integrated:
- NIS2 focuses on cybersecurity measures
- CER on physical security and resilience
- AI Act on AI-specific risks (data quality, oversight, accuracy, robustness)
Sector-Specific Pitfalls
Pitfall 1: Not Every AI in the Sector Is a Safety Component
Many energy companies use AI for forecasting, asset management, customer segmentation. That is not a safety component and falls outside scope, unless it directly touches operational safety.
Pitfall 2: SCADA Integrations
AI systems integrated in SCADA, DCS or OT environments for real-time control of physical processes are almost always safety components. The compliance route then also runs via IEC 61508/61511 functional safety, not only the AI Act.
Pitfall 3: Vendor Lock-in and Updates
Safety components in critical infrastructure often have long lifecycles (10-20 years). The AI Act requires post-market monitoring and, in case of significant change, renewed conformity assessment. Build this into procurement contracts from the start.
What to Do
Map AI in OT/IT with safety function
Separate IT AI (likely out of scope) from OT AI with safety function (in scope).
Align NIS2/CER/AI Act compliance
Build an integrated compliance programme where the three regimes don't sit in silos.
Secure vendor agreements
For AI as safety component, the provider must be able to demonstrate conformity assessment. Build this in as a contractual requirement.
Test your AI against the Article 6(3) filter
Free interactive self-assessment, updated for the Commission guidelines of 19 May 2026. 9 steps, personal report with reasoning, vendor questions and next steps.