Transport is the sector where the stakes of AI failure are most immediately legible. An AI system malfunction in a fully automated train, a vessel traffic management system, or an autonomous bus puts bodies at risk. The EU AI Act builds this intuition directly into law: safety-critical AI in transport is treated as high-risk by design, with compliance obligations that mirror the severity of what can go wrong.
But the sector's regulatory challenge is not simply about safety AI. Transport is also where some of the Act's most contested provisions play out — the boundary between safety and operations, the tension between passenger convenience and biometric surveillance, the collision between product-safety law and AI governance, and the peculiar position of mobility startups navigating compliance requirements calibrated for primes. Every layer of the transport stack, from the satellite-guided aircraft to the ticketing algorithm at the bus door, touches the Act somewhere.
The risk architecture
The Act classifies transport AI as high-risk through two distinct mechanisms, and understanding which one applies to a given system is not always obvious.
The first mechanism — Article 6(1) — applies to AI systems that function as safety components in products already subject to EU harmonisation legislation listed in Annex I. Annex I explicitly includes motor vehicle type-approval law (Regulation (EU) 2018/858 and 2019/2144), aviation safety regulation under Regulation (EU) 2018/1139, marine equipment directives, and rail interoperability legislation. Any AI system embedded in a vehicle, aircraft, vessel, or railway asset as a safety component — meaning its failure would directly endanger health, safety, or property — is automatically high-risk, full stop, and must undergo third-party conformity assessment under both the Act and the sectoral regulation. An autonomous lane-keeping system, a collision avoidance module, a predictive brake monitoring algorithm in a rolling stock management system: all of these, if safety-classified, trigger Article 6(1).
The second mechanism — Article 6(2) via Annex III — covers AI systems used as safety components in the management and operation of road traffic and critical transport infrastructure. This is different from being a safety component of a physical vehicle: it captures network-level systems — urban traffic management AI, vessel traffic service systems in ports, railway network optimisation tools — whose failure could cascade into mass-scale harm. Recital 55 of the Act explains the rationale: these systems are not merely important; their failure may "put at risk the life and health of persons at large scale and lead to appreciable disruptions in the ordinary conduct of social and economic activities."
What this produces, in aggregate, is a sector where the presumption is high-risk and the burden is on the operator or manufacturer to demonstrate otherwise. The Article 6(3) derogation — which permits reclassification where an Annex III system poses no significant risk and does not materially influence decision-making — exists but is limited in transport precisely because the use cases involve physical safety.
Autonomous vehicles
No transport AI application illustrates the Act's layered compliance architecture more clearly than autonomous vehicles. The regulatory question is not whether AVs require governance — they unambiguously do — but how two distinct frameworks apply simultaneously to the same system.
The EU's type-approval framework for autonomous vehicles — anchored in Regulations 2018/858 and 2019/2144, supplemented by Commission Implementing Regulation 2022/1426 for SAE Level 4 systems — governs whether a vehicle may be placed on the market. It specifies test scenarios, system failure requirements, and safety management obligations, and currently limits fully autonomous vehicle approval to "small series" production. The AI Act, separately, governs the AI systems embedded within those vehicles when those systems qualify as safety components. When an AI system is subject to both frameworks, conformity assessment under both must be conducted — not alternatively, but simultaneously.
Volvo Autonomous Solutions' November 2025 analysis of the Act's implications captures the engineering consequence of this duality. Perception modules and motion planning systems in their virtual driver platform may require classification under Article 6(1), triggering strict requirements on training data governance (Article 10), human oversight design (Article 14), and robustness and accuracy standards (Article 15). The compliance burden is not duplicative in the sense of performing the same tasks twice; it is additive, because the two frameworks ask different questions about the same system. Type-approval asks whether the vehicle is safe in defined scenarios. The AI Act asks whether the AI system's development, training data, and ongoing monitoring meet standards that were designed without a specific vehicle type in mind.
The Commission has signalled that the type-approval framework will be revised to accommodate series production of autonomous vehicles, with regulatory sandboxes and autonomous driving corridors planned from 2026 — but as of April 2026, the details of how AI Act compliance integrates into future type-approval procedures remain under development.
Aviation and rail
Aviation and rail are sectors where specialised regulatory bodies have moved quickly to operationalise the Act's requirements within their own frameworks — with consequences for how AI compliance is governed in practice.
In aviation, Article 108 of the AI Act amended Regulation (EU) 2018/1139, the EASA Basic Regulation, to require that any delegated acts relating to AI systems qualifying as safety components must incorporate the Act's high-risk requirements. In November 2025, EASA published Notice of Proposed Amendment 2025-07 — its first specific regulatory proposal on AI trustworthiness — covering AI-based assistance and Human-AI teaming for aircraft operations. The NPA introduces AI-specific Detailed Specifications, acceptable means of compliance, and guidance material that translate the Act's requirements into aviation-specific engineering standards. Manufacturers must map every AI system to an automation level (Level 1: AI assistance; Level 2: Human-AI teaming; with Level 3, fully autonomous, under future development), perform dedicated AI risk and ethics assessments, and design systems with continuous monitoring and recording capabilities.
The practical significance of EASA's approach is that it creates a structured, aviation-specific compliance pathway that the Act's general framework does not provide. An aircraft manufacturer or avionics startup does not face a blank-page conformity assessment; it faces a defined EASA process. This is more demanding in its specificity, but less exposed to the interpretive uncertainty that affects sectors where no sectoral body has developed equivalent guidance.
Rail faces a different structural challenge. The EU's rail interoperability directives and the European Union Agency for Railways (ERA) govern cross-border interoperability, but AI governance in rail remains fragmented at the Member State level. Systems such as ERTMS (the European Rail Traffic Management System) involve AI-adjacent predictive and optimisation components whose classification under the Act depends on whether they constitute safety components — a determination that has not yet been resolved through ERA guidance as of April 2026. National rail operators deploying AI for predictive maintenance, passenger flow management, or timetable optimisation face the Act's general high-risk framework without the sectoral specificity that EASA is developing for aviation.
Ports and logistics
For major European port operators and the logistics companies that depend on their efficiency, the Act creates obligations that flow from the critical infrastructure classification rather than from product safety law.
Annex III(2) classifies as high-risk any AI used as a safety component in the management and operation of road traffic and critical infrastructure. Container Terminal Burchardkai in Hamburg's HHLA, for instance, uses AI to optimise container placement in automated yards in real time — a system whose malfunction could generate cascading safety risks across the port's physical operations. A vessel traffic management AI that monitors and coordinates port entry and exit is similarly safety-critical in the operational management sense. Both require the Act's full compliance stack: risk management systems, training data governance, human oversight mechanisms, post-deployment monitoring, and registration in the EU database.
The distinction that matters operationally is between AI used in safety functions and AI used for pure operational optimisation without direct safety consequences. A route-scheduling algorithm that optimises truck movements through a terminal for fuel efficiency is not a safety component; it does not qualify as high-risk simply because it operates in a port. A predictive collision avoidance system for automated guided vehicles operating in the same terminal is a safety component: its failure puts workers in the path of multi-tonne machinery. The Act draws this line explicitly, and port operators who have deployed AI without mapping their systems against it face both legal exposure and, more concretely, the risk of deploying inadequately governed safety-critical AI.
Ports also create a specific GPAI challenge. Large language models and general-purpose AI tools are increasingly being integrated into port operations for documentation processing, customs pre-clearance, and logistics coordination — the kind of operational AI that sits below the safety threshold. These tools require transparency obligations under Article 50 from August 2026, and port operators must ensure their staff using these tools have the AI literacy required under Article 4.
Public transport
Public transport infrastructure presents the Act's most politically live question in the transport sector: the use of AI-based surveillance systems in passenger-facing environments.
The Act's prohibition on real-time remote biometric identification in publicly accessible spaces applies to law enforcement use. But transit operators — metro systems, bus networks, railway stations — are not law enforcement agencies, and the prohibition does not automatically extend to their use of facial recognition for non-law-enforcement purposes such as ticketing, fraud prevention, or passenger flow management. A March 2026 pilot in Santiago de Chile demonstrated facial recognition-based boarding on city buses with claimed 98% accuracy, including functionality to identify individuals with active legal warrants — a capability that explicitly crosses the civilian-to-law-enforcement boundary and would be subject to the Act's most stringent restrictions if deployed in the EU.
Within the EU, transit operators considering AI-based ticketing or crowd management systems face a compliance analysis that turns on purpose and data classification. Facial recognition for biometric payment verification — confirming that the holder of a registered travel pass is who they claim to be — involves biometric data processing that is subject to GDPR's Article 9 restrictions, requires explicit consent, and must satisfy the Act's high-risk obligations as a biometric identification system listed in Annex III(1). Post-event biometric identification systems — reviewing footage to identify a fare evader or security incident after the fact — are also classified as high-risk. Real-time systems for non-law-enforcement purposes occupy a legal grey zone that the Act does not resolve, and that digital rights organisations have consistently argued requires explicit prohibition rather than case-by-case assessment.
This is not an academic question. European transit operators are under financial pressure to reduce fare evasion — a problem estimated to cost European public transport systems several billion euros annually — and AI-based solutions are commercially available. The regulatory constraint is not that these solutions cannot be deployed but that deploying them lawfully requires a compliance analysis, a FRIA for public body deployers, GDPR legal basis documentation, explicit passenger notification, and human oversight mechanisms that most transit operators have not yet built.
Mobility startups
The Mobility as a Service (MaaS) sector — platforms that aggregate route planning, ticketing, ride-hailing, and multimodal journey coordination — presents a specific compliance challenge because the AI systems embedded in these services span multiple risk classifications in a single user interaction.
A route recommendation algorithm that suggests optimal combinations of bus, metro, and rail is not obviously a safety-critical AI system; it is closer to a navigation aid. However, if the same platform integrates real-time hazard alerts, dynamic rerouting based on incident data, or algorithmic allocation of shared vehicles to passengers, portions of the system may qualify as safety components depending on their architecture and intended purpose. The Act does not provide MaaS-specific guidance, and the classification analysis must be conducted system by system, use case by use case.
For startups, the compliance cost structure is familiar from other sectors. A MaaS platform deploying high-risk AI functionality faces initial compliance costs ranging from €250,000 to €500,000, with annual maintenance obligations of €80,000 to €150,000 thereafter. The AI literacy requirement under Article 4 — enforceable since February 2025 — means that staff at these companies who operate, configure, or make decisions based on the AI must demonstrate sufficient competence, which in practice requires structured training programmes rather than ad-hoc familiarisation.
The Omnibus's extension of SME support measures to small mid-cap companies — endorsed by the European Parliament in its March 2026 position — is a meaningful concession for growth-stage mobility startups that have scaled beyond the traditional SME threshold but remain resource-constrained relative to the large operators whose networks they integrate with. Priority sandbox access, simplified documentation requirements, and proportional conformity fees now potentially apply to companies up to the SMC threshold.
AI in transport operations
Transport employs several million workers in the EU whose roles are directly affected by operational AI — fleet management systems, predictive rostering, driver monitoring, route optimisation. These systems occupy a different risk tier from safety-critical AI, but the Act's obligations do not disappear below the high-risk threshold.
Driver monitoring systems — AI tools that track driver attentiveness, fatigue, and distraction in real time — are increasingly standard in commercial vehicle fleets. When these systems are used to generate performance data that influences driver assessment, assignment, or disciplinary action, they may qualify as high-risk AI under Annex III's employment and worker management category, which covers AI that "materially influences decisions on working conditions." A system that passively monitors fatigue for safety alerts is different from one that scores drivers and generates reports used in HR processes — and the Act treats that distinction as legally significant.
Employers in transport who deploy such systems from August 2026 (December 2027 under Omnibus timelines) must provide workers with prior notice, assign qualified human oversight, and ensure that AI outputs do not serve as the sole basis for significant employment decisions. Under Article 26, workers must be informed before high-risk AI systems affecting them are deployed — a requirement that intersects directly with existing labour law obligations and collective agreement requirements in sectors with high union density, including rail, aviation, and road haulage.
The timeline revision
The Digital Omnibus revisions — with the European Parliament's position adopted in March 2026 — shift the compliance landscape in ways that are sector-specifically significant for transport.
The original August 2026 deadline applied to all Annex III high-risk obligations. Under the Omnibus revision, standalone high-risk AI systems move to December 2027; AI embedded in regulated products subject to sectoral safety legislation — which encompasses motor vehicles, aircraft, marine equipment, and railway systems — moves to August 2028. For the most complex transport applications, where AI is integrated into type-approved products and certification timelines are measured in years rather than months, this extension is operationally meaningful.
What the Omnibus does not defer are the prohibitions (active since February 2025), the AI literacy obligation (active since February 2025), GPAI transparency requirements (active since August 2025), and the watermarking requirements for AI-generated content (moving to November 2026). A transport operator using AI-generated passenger communications, automated fare dispute responses, or AI-drafted regulatory submissions is already subject to transparency obligations. The obligation to ensure that staff operating any AI system have sufficient AI literacy is already enforceable.
Critics of the Omnibus delays have noted that deferring high-risk oversight past 2027 means that autonomous vehicles, port management systems, and transport surveillance AI will operate in commercial deployment without full compliance obligations during a period when AI capabilities are advancing rapidly. The counter-argument from industry is that compliance standards and harmonised technical specifications needed to demonstrate conformity — particularly for aviation and autonomous vehicles — are not yet available, and that enforcing obligations before the tools to satisfy them exist creates legal risk without safety benefit. Both positions are defensible; what is certain is that the deferral creates a two-to-three year window in which the sector must decide how seriously to invest in compliance infrastructure it will be legally required to have, and is not yet legally required to demonstrate.
References
- EU AI Act, Article 6(1) and Annex I — Safety component classification for regulated products.
- EU AI Act Service Desk. "Annex I — Union Harmonisation Legislation." Including Regulation (EU) 2018/858 and 2019/2144.
- EU AI Act, Annex III(2) — Critical Infrastructure including Road Traffic. Recital 55.
- McCarter & English. "AI in Critical Infrastructure Markets: Are Smart Systems AI? The EU AI Act." July 2024.
- Taylor Wessing. "Legal Framework for Automated and Autonomous Driving in the EU." February 2026.
- Volvo Autonomous Solutions. Magnus Heidenvall. "EU AI Act Explained: How Europe's New AI Regulations Will Affect Autonomous Transport." November 2025.
- Lexify. "AI Act in Aviation: EASA Guidance — NPA 2025-07." December 2025.
- EASA. "EASA's First Regulatory Proposal on Artificial Intelligence for Aviation (NPA 2025-07)." November 2025.
- XTRAS-Log. "EU AI Act 2026: AI Deployment in Ports — Obligations and Opportunities for TOS." January 2026.
- Port of Rotterdam. "Artificial Intelligence in the Port." September 2023.
- EDRi. "How to Fight Biometric Mass Surveillance After the AI Act: A Legal and Practical Guide." July 2024.
- Biometric Update. "Innovatrics Claims 98% Biometric Accuracy in Public Transportation Ticketing Pilot." March 2026.
- Verfassungsblog. "AI Act and the Prohibition of Real-Time Biometric Identification." December 2024.
- SoftwareSeni. "Budgeting for EU AI Act Compliance: Cost Models for SMB Tech Companies." January 2026.
- European Parliament TRAN Committee. "Opinion on AI Omnibus — Aviation and SMC Extension." March 2026.
- OneTrust. "How the EU Digital Omnibus Reshapes AI Act Timelines and Governance in 2026." March 2026.
- Verdantix. "The Omnibus Might've Parked the EU AI Act for Now — But Regulation Is Still En Route." March 2026.
- Tech Policy Press. "EU's AI Act Delays Let High-Risk Systems Dodge Oversight." April 2026.
- Latham & Watkins. "EU AI Act: Ban on Certain AI Practices and Requirements for AI Literacy." January 2025.
- EU AI Act, Article 26: Obligations of Deployers. Official text.