EU AI Act obligations for AI in autonomous vehicles, traffic management, aviation, rail, and critical infrastructure. Covers Annex I (NLF) and Annex III category 2.

Why Transport Is an EU AI Act Priority Sector

The EU AI Act (Regulation (EU) 2024/1689) assigns its most demanding obligations to domains where AI failures carry direct consequences for physical safety, critical service continuity, and public security. Transport and critical infrastructure occupy a central position in this architecture for two independent legal reasons: the pervasive deployment of AI as safety components in regulated transport products (triggering Art. 6(1) via Annex I), and the explicit listing of critical infrastructure management AI as high-risk under Annex III, point 2.

The transport sector is also distinguished by the density and maturity of its existing regulatory frameworks. Vehicle type-approval under General Safety Regulation (EU) 2019/2144, aviation certification under EASA Basic Regulation (EU) 2018/1139, railway interoperability and safety under ERA Regulation (EU) 2016/796 and Safety Directive 2016/798, and critical infrastructure cybersecurity under NIS2 Directive (EU) 2022/2555 all create pre-existing legal obligations that stack with — and in some cases structurally interact with — the EU AI Act.

For transport organisations, the practical consequence is that AI compliance cannot be managed as an isolated regulatory workstream. It must be integrated into existing type-approval, certification, safety management, and cybersecurity programmes. Failure to achieve this integration risks not only AI Act non-compliance but also non-conformity with sector regulations that have their own enforcement authorities and market-access consequences.

Safety Component AI (Annex I) vs. Critical Infrastructure AI (Annex III, Point 2)

The EU AI Act creates two distinct high-risk pathways relevant to transport. Understanding which pathway applies — and whether both apply simultaneously — is the first analytical step in any transport AI compliance programme.

Annex I — Safety Components of NLF-Regulated Products

Art. 6(1) of the EU AI Act classifies as high-risk any AI system that is a safety component of a product regulated under New Legislative Framework (NLF) legislation listed in Annex I. For transport, the key NLF instruments are:

An AI system is a safety component of a transport product if its failure or malfunction could endanger the health or safety of persons. For road vehicles, this encompasses autonomous emergency braking systems, lane-keeping AI, adaptive cruise control at SAE L2 and above, and all L3–L5 automated driving systems. For aviation, it encompasses AI in flight management systems, autopilot components, and ground-proximity warning systems. For rail, it encompasses AI in automatic train protection, AI-assisted signalling, and autonomous shunting.

The classification under Art. 6(1) is categorical. It does not require the AI system to independently demonstrate a significant probability of harm — the safety-component designation is sufficient. This means providers of such systems must comply with Chapter III, Section 2 requirements (Arts. 9–15) covering risk management, data governance, technical documentation, automatic logging, transparency, human oversight, and accuracy and robustness.

Annex III, Point 2 — Critical Infrastructure Management

Separately from the safety-component pathway, Annex III, point 2 expressly lists as high-risk AI systems intended to be used as safety components in the management and operation of critical infrastructure, specifically:

AI systems that fall into this category include: motorway traffic management platforms using AI for dynamic speed control and incident detection, AI-based smart grid stability and load balancing systems where grid failure would affect transport operations, and AI systems managing port infrastructure at the level of essential service operation.

The distinction between point 2 and the Annex I pathway is that Annex III, point 2 applies to operators of infrastructure rather than only to product manufacturers. A public authority or private concession holder operating an AI-driven traffic management centre is subject to point 2 obligations as a deployer or, if it has developed the AI system itself, as a provider.

Dual Classification

Where an AI system is both a safety component of an NLF-regulated product and is deployed in critical infrastructure management (e.g., an AI system integrated into a smart motorway platform that also interfaces with vehicle systems), both pathways apply. The more demanding obligations govern.

Provider vs. Deployer in the Transport Context — OEM vs. Operator

The allocation of obligations between providers (Art. 16) and deployers (Art. 26) is particularly complex in transport, where the supply chain between AI developer, system integrator, OEM, infrastructure operator, and end-user fleet may involve multiple legal entities each bearing distinct AI Act responsibilities.

Vehicle OEMs as Providers

An OEM that integrates an AI driving system — whether developed in-house or sourced from a Tier 1 or Tier 2 supplier — and places the vehicle on the EU market under its own brand name is the provider of the AI system under Art. 16. This is the case even if the AI technology was originally developed by a third party, provided the OEM has not merely resold an unchanged system under the third-party's branding. Provider obligations include:

Fleet Operators and Concession Holders as Deployers

A company operating a fleet of autonomous vehicles, a local authority deploying an AI traffic management system, or a rail infrastructure manager using AI-assisted maintenance tools is a deployer under Art. 26. Deployer obligations include:

Interaction with Sector Regulations — EASA, ERA, and Type-Approval

Road Vehicles — GSR 2019/2144 and Type-Approval

The General Safety Regulation (EU) 2019/2144 mandates the inclusion of specific ADAS and autonomous driving features in new vehicle types and establishes technical requirements for their performance. Vehicle type-approval — conducted by national type-approval authorities (e.g., KBA in Germany, DREAL in France, DVSA in the UK for historical approvals) — is the primary market-access mechanism for road vehicles.

The EU AI Act does not displace type-approval. Art. 8(1) of the AI Act specifies that where sector-specific legislation imposes requirements of equivalent or greater stringency, procedural alignment is possible, but AI Act obligations remain. In practice, the conformity assessment for an AI driving system must address both the GSR technical requirements (assessed as part of type-approval) and the AI Act requirements (technical documentation, data governance, logging, human oversight, post-market monitoring). OEMs should plan for an integrated assessment covering both frameworks to avoid duplicative effort and potential gaps.

Aviation — EASA and the AI Roadmap

EASA exercises certification authority over aircraft, engines, and parts under Regulation (EU) 2018/1139. EASA's AI roadmap (published in successive editions from 2020) addresses AI trustworthiness for airborne AI systems and is the primary certification reference for AI in flight-critical applications.

The EU AI Act applies to ground-based aviation AI (traffic management, maintenance diagnostics, cabin management systems) that falls outside EASA's airworthiness perimeter. For airborne AI systems that are certified by EASA, Art. 8(1) alignment is available, but the overlap between EASA airworthiness requirements and AI Act obligations (particularly on logging and human oversight) must be analysed system by system. EASA's concept of "AI assurance level" does not map directly onto the EU AI Act's high-risk classification or conformity assessment requirements.

Rail — ERA and Safety Management Systems

ERA (European Union Agency for Railways) oversees railway interoperability and the common safety framework under Directives 2016/797 and 2016/798. Railway undertakings and infrastructure managers are required to maintain a Safety Management System (SMS) that covers risk assessment, accident investigation, and continuous improvement.

The EU AI Act's risk management requirements under Art. 9 closely parallel ERA's SMS requirements. Organisations that have a mature SMS are well-positioned to integrate AI Act risk management documentation into the existing framework. ERA and the European Commission have indicated a preference for integrated compliance approaches that avoid duplication between SMS and AI Act obligations. AI systems used in automatic train operation, ETCS (European Train Control System) AI components, or predictive maintenance that feeds into safety-critical decisions are high-risk under Annex I (safety component of rail vehicles or infrastructure).

Enforcement and Certification Authorities

Transport AI compliance involves multiple enforcement bodies with partially overlapping jurisdiction, depending on the AI system's function and the product it is embedded in.

EASA is the certification authority for AI in aircraft and aeronautical products. It may conduct investigations into AI system failures that implicate airworthiness, and its decisions affect market access across the EU and bilateral partner jurisdictions.

ERA oversees the common safety framework for railways. Railway safety certificates and authorisations to operate are contingent on SMS conformity, which increasingly intersects with AI Act compliance for AI-enabled rail systems.

National vehicle type-approval authorities — including KBA (Germany), ANFIA-delegated bodies (Italy), and Rijksdienst voor het Wegverkeer (Netherlands) — issue and can withdraw type approvals for road vehicles. Non-conformity with AI Act requirements for AI safety components may constitute grounds for type-approval suspension or recall.

NIS2 national competent authorities — designated by each member state, often a national cybersecurity agency such as BSI (Germany), ANSSI (France), or NCSC-NL (Netherlands) — enforce NIS2 obligations for transport operators of essential services. NIS2 enforcement can result in binding instructions, fines, and in severe cases suspension of operations.

National AI supervisory authorities designated under Art. 70 of the EU AI Act will have general market surveillance powers, with coordination mechanisms for sector-specific authorities to avoid jurisdictional conflicts.

Compliance Priorities for Transport Operators and Providers

Step 1: AI System Inventory and Classification

Conduct a structured inventory of all AI systems in development or deployment across the transport product or operational portfolio. For each system, determine whether it is a safety component of an NLF-regulated product (Art. 6(1) pathway), a critical infrastructure management AI (Annex III, point 2), or both. Document the classification rationale in writing. Systems that cannot be definitively excluded from high-risk classification should be treated as high-risk pending definitive legal analysis.

Step 2: Conformity Assessment Route Planning

For AI systems that are safety components of vehicles, aircraft, or rail products, identify the applicable sector certification procedure and map it against the AI Act conformity assessment requirements. Determine whether a notified body is required (Art. 43(3)) or whether a self-assessment with third-party technical audit suffices. Coordinate the AI Act conformity assessment timeline with the type-approval or certification programme to avoid market access delays.

Step 3: Technical Documentation and Data Governance

Prepare technical documentation under Annex IV for each high-risk AI system. For transport AI, this must include: the intended purpose with precision sufficient to support both AI Act and sector-regulation classification; training data provenance, including any real-world driving, operational, or sensor data used; simulation environment descriptions for AI systems validated through virtual testing; and post-market monitoring plans aligned with sector-specific reporting obligations.

Step 4: NIS2 Integration for Critical Infrastructure Operators

Transport operators of essential services must integrate AI Act cybersecurity requirements under Art. 15 with NIS2 cybersecurity risk management obligations. Establish a single security risk assessment process covering both frameworks. Ensure AI software suppliers — including AI model developers and data providers — are subject to supply chain security requirements consistent with NIS2 Art. 21(2)(d) and AI Act Art. 25 (third-party tool obligations).

Step 5: Human Oversight in Operational Contexts

Design human oversight mechanisms under Art. 14 that are operationally viable in transport environments. For autonomous driving systems, define the conditions under which a driver must be able to take control (L3) or a remote operator must be able to intervene (L4). For air traffic management AI, specify the points in the workflow at which a controller must review and approve AI-generated instructions. For rail maintenance AI, define escalation protocols when the system flags safety-critical anomalies. Oversight mechanisms must be documented in the technical documentation and reflected in the instructions for use provided to deployers.

Step 6: Post-Market Monitoring and Incident Reporting

Establish post-market monitoring systems that satisfy both AI Act Art. 72 requirements and sector-specific safety reporting obligations (ERA accident reporting, EASA occurrence reporting under Regulation (EU) 376/2014, NIS2 incident notification). Serious incidents involving high-risk AI systems must be reported to the national AI supervisory authority under Art. 73 within 15 working days of becoming aware. This timeline must be reconciled with NIS2's 24-hour initial notification requirement for significant cybersecurity incidents, which may cover the same event if the AI malfunction is attributable to a cybersecurity breach.

Official AI Act Compliance Deadline Calendar

Updated · Sources: Regulation (EU) 2024/1689 and the 2026 Digital Omnibus on AI.

Obligation Applies to Original date New date Status Countdown Legal basis
Prohibited Practices (Art. 5) All providers and deployers active — AI Act Art. 5
GPAI Rules (Chapter 5) GPAI model providers active — AI Act Art. 51-56
High-risk AI — Annex III (standalone) Providers of standalone Annex III systems deferred — AI Omnibus 2026 Art. 6(2)
High-risk AI — Annex I (embedded) AI embedded in Annex I regulated products deferred — AI Omnibus 2026 Art. 6(1)
AI-Generated Content Marking Providers of generative GPAI systems active — AI Act Art. 50(2)
Regulatory Sandboxes National competent authorities active — AI Act Art. 57

⬇ Download JSON · CC BY 4.0

AI Act meets DORA and NIS2

Is your organisation subject to both the AI Act and DORA? The two regulations intersect on the operational resilience of financial AI systems. Our sister site regulation-dora.eu covers DORA in depth.

Explore regulation-dora.eu ↗

Frequently Asked Questions

Yes, in most commercially relevant configurations. An AI system that constitutes a safety component of a road vehicle type-approved under General Safety Regulation (EU) 2019/2144 is automatically classified as high-risk under Art. 6(1) of the EU AI Act, read with Annex I (New Legislative Framework). This applies from SAE Level 2+ driver assistance systems that influence steering, braking, or acceleration through to L4 and L5 autonomous driving systems. The classification is categorical and does not require a separate probability-of-harm assessment. Both the AI Act conformity assessment and the type-approval procedure under GSR 2019/2144 must be satisfied before the vehicle is placed on the EU market.

The allocation depends on the contractual and technical structure of the integration. Where the OEM embeds a third-party AI system into the vehicle type without modification and places it on the market under its own name, the OEM is the provider under Art. 16 of the EU AI Act and bears full provider obligations, including conformity assessment, CE marking, and registration in the EU AI database. The original developer of the AI system may be a sub-supplier but is not automatically the AI Act provider. If the OEM makes substantial modifications to the AI system before market placement, provider obligations are confirmed in full. Fleets or rental companies that subsequently deploy the vehicle with the AI system active are deployers under Art. 26.

No. EASA certification under the Basic Regulation (EU) 2018/1139 and the AI Act conformity assessment are distinct legal obligations that operate in parallel. EASA's AI roadmap and forthcoming guidance on AI trustworthiness for aviation address airworthiness and operational safety requirements under aviation law. The EU AI Act's requirements — including technical documentation under Annex IV, automatic logging under Art. 12, and human oversight under Art. 14 — are separate obligations that must be independently satisfied. Art. 8(1) of the AI Act acknowledges sector-specific legislation and may allow procedural alignment where EASA requirements are equivalent, but does not eliminate AI Act obligations for ground-based AI systems or cabin AI that falls outside EASA's airworthiness perimeter.

It depends on the operational context. AI systems used for the management and operation of critical road traffic infrastructure are expressly listed as high-risk under Annex III, point 2 of the EU AI Act. A system managing motorway traffic flow, adaptive signal control for a metropolitan road network, or dynamic lane assignment on a tunnel approach road is likely to meet the threshold of 'critical road traffic infrastructure.' A standalone AI optimising signal timing at a single rural junction with minimal traffic volume and no safety-critical interdependencies may fall outside this definition, but this assessment must be documented. Operators should apply a precautionary interpretation: if a failure or miscalculation in the AI's output could create a material risk of accidents, congestion cascades, or emergency vehicle delay at scale, classification as high-risk is the appropriate default.

Rail operators that qualify as operators of essential services under NIS2 Directive (EU) 2022/2555 face a dual compliance obligation. Under NIS2, they must implement cybersecurity risk management measures, maintain incident reporting timelines (significant incidents within 24 hours to national competent authority, full report within 72 hours), and ensure supply chain security including for AI software suppliers. Under the EU AI Act, AI systems embedded in safety-critical rail operations — predictive maintenance AI, AI-assisted signalling, autonomous shunting systems — are high-risk under Art. 6(1) (as safety components under ERA railway legislation) or Annex III, point 2. The AI Act's cybersecurity and robustness requirements under Art. 15 must be satisfied in a manner consistent with and complementary to NIS2 obligations. A single integrated risk management system addressing both frameworks is operationally preferable and consistent with ERA Safety Management System requirements under Directive 2016/798.

Stay ahead of AI Act changes

Get compliance alerts when deadlines or obligations change.

No spam. One-click unsubscribe.