EU AI Act for Transport & Mobility Developers: Annex III Critical Infrastructure Compliance Guide 2026

Post #3 in the sota.io EU AI Act Sector-Specific Developer Series (Part 2)

Transport AI sits at an awkward intersection: vehicle safety law has governed autonomous systems for decades under UN-ECE frameworks, but the EU AI Act adds an entirely new compliance layer beginning August 2, 2026. For most transport software teams, the question is not whether they are covered — it is which obligations apply, and whether their existing automotive-grade safety processes satisfy the EU AI Act's specific documentation and oversight requirements.

The answer depends on a single distinction: is your AI a safety component in critical infrastructure? If yes, Annex III Point 2 classifies it as high-risk and triggers the full conformity assessment path. If no, you likely fall outside mandatory high-risk obligations entirely. This guide makes that classification precise, then walks through every obligation that follows.

The Transport AI Risk Taxonomy: Four Tiers

Tier 1 — Annex III Point 2 HIGH-RISK (Critical Infrastructure Safety Components)

Annex III Point 2 designates AI as high-risk when used "as safety components in the management and operation of critical digital infrastructure, road traffic, or the supply of water, gas, heating or electricity." For transport developers, this covers:

Road traffic safety AI:

• Autonomous Emergency Braking (AEB) systems where AI is the primary decision-making component
• Intelligent Speed Assistance (ISA) controllers that actively intervene on vehicle speed
• Automated Lane Keeping Systems (ALKS) operating at SAE Level 3+ on public roads
• Traffic signal control AI that autonomously manages intersections without human override per cycle

Rail safety systems:

• AI-based train protection systems that trigger emergency stops
• Automated train operation (ATO) controllers at GoA Level 3-4 (conditional to full automation)
• AI-driven switch control in AI-managed rail segments

Smart city traffic management:

• Real-time traffic flow controllers that reroute emergency vehicles via autonomous signal coordination
• Urban traffic control systems where AI makes junction-by-junction decisions without human intervention in each cycle

Aviation and maritime (where applicable):

• AI systems used as safety components in air traffic management sequencing
• Autonomous vessel collision-avoidance systems classified as safety-critical under SOLAS

Tier 2 — GPAI Obligations Only (Art.50 Transparency)

AI systems that interact with transport users must comply with Art.50 transparency requirements, even if not classified as high-risk:

• Voice assistants in connected vehicles that could be mistaken for human operators
• AI chatbots for passenger information services
• Automated customer service systems for transport operators

Tier 3 — General Purpose AI (Minimal EU AI Act Obligations)

Most transport logistics AI falls here:

• Route optimization for freight dispatching
• Predictive maintenance scheduling (condition monitoring, not safety actuation)
• Demand forecasting for public transport scheduling
• Fuel efficiency AI that provides recommendations (not actuation)
• ADAS features that assist rather than act as the safety component (e.g., lane departure warning vs. lane keeping intervention)

Tier 4 — Prohibited Practices (Art.5)

No transport use case commonly triggers Art.5 prohibitions, but AI-based behavioral scoring of drivers that denies access to transport services based on inferred personal characteristics could fall under Art.5(1)(c).

Annex III Point 2: What Makes Something a "Safety Component"?

The Commission's classification guidance and recitals clarify that "safety component" means the AI system's failure could directly cause harm to persons or property, and the AI output is used to make safety-relevant decisions without a mandatory human decision step in the loop.

Test: Is it a safety component?

The key variable is whether a human decision separates the AI output from the safety-critical actuation. Where the AI output is the actuation (or makes it unavoidable), Annex III Point 2 applies.

Art.9 Risk Management System — Transport-Specific Requirements

Providers of Annex III Point 2 AI systems must establish a risk management system under Art.9. For transport AI, this has four transport-specific dimensions:

Operational Design Domain (ODD) documentation: Every transport AI system must specify the exact conditions under which it operates safely. For ADAS, the ODD typically covers weather conditions (snow, fog, rain intensity thresholds), road types (motorway, urban, rural), speed ranges, and lighting conditions. The Art.9 risk management system must document the ODD, risk mitigation measures at ODD boundaries, and procedures for graceful degradation when ODD boundaries are approached.

Residual risk quantification: UN-ECE R157 (Automated Lane Keeping Systems) and ISO 26262 (functional safety for road vehicles) both require residual risk to be ALARP (As Low As Reasonably Practicable). The EU AI Act's Art.9(4) requires known and reasonably foreseeable risks to be eliminated or reduced to acceptable levels. These requirements align in outcome but differ in documentation format — your ISO 26262 HARA (Hazard Analysis and Risk Assessment) will need supplemental EU AI Act risk documentation.

Testing against real-world data: Art.9(7) requires testing under operational conditions representative of the intended use. For transport AI, this means simulation plus track testing plus public road data (subject to GDPR — see intersection section below).

Continuous risk management: Unlike automotive type-approval (which is a point-in-time event), Art.9 requires continuous risk monitoring. Transport AI providers must maintain risk management documentation throughout the product lifecycle.

Art.10 Data Governance — Connected Vehicle Data Challenges

Art.10 requirements for training data quality are straightforward in principle, difficult in practice for transport AI. Three transport-specific challenges:

Sensor data labelling at scale: ADAS AI typically requires billions of kilometres of annotated driving data. Art.10(3) requires training data to be "free of errors and complete." This does not mean zero-defect perfection — it means documented data quality processes, bias testing across geographic regions (right-hand vs. left-hand traffic, road marking conventions), and validation that rare edge cases (cyclists, road works, adverse weather) are adequately represented.

Cross-border data portability vs. GDPR: Connected vehicle data — GPS trajectories, cabin sensor data (where passengers are identifiable), behavioral driving patterns — is personal data under GDPR when it can identify a natural person. Training autonomous vehicle AI on data collected across the EU requires legal basis documentation (Art.6 GDPR), data minimisation (Art.5 GDPR), and potentially DPIA (Art.35 GDPR) for large-scale vehicle monitoring. The AI Act's Art.10(5) permits processing of special categories of personal data for training only under strict conditions — this is relevant for driver biometric monitoring (fatigue detection, attention monitoring).

Synthetic data augmentation: Edge cases that are rare in real-world data (vehicle on wrong side of road, pedestrian partially occluded by parked vehicles) must be covered. Synthetic data is permitted under Art.10 if documented as synthetic and its relationship to real-world distributions is validated.

Art.14 Human Oversight — The ALKS Design Problem

Art.14 requires providers of high-risk AI to design systems that allow human operators to understand, monitor, and where necessary interrupt or override the AI output. For autonomous vehicle AI, this creates a design tension: SAE Level 3 automation by definition removes the driver from the feedback loop for extended periods.

The resolution lies in what "human oversight" means at the system architecture level vs. the per-decision level:

Per-decision oversight (required for traffic management AI): Traffic signal controllers and smart city AI systems that make real-time safety decisions must include an operator interface that allows human intervention per control cycle. The system must be designed so that a human operator can take over any specific decision when the AI operates outside expected parameters.

Architectural oversight (for ADAS providers): For ADAS operating in normal conditions, Art.14 is satisfied through: (1) take-over request mechanisms with adequate handover time, (2) system status displays that allow operators (drivers) to understand AI operational state, (3) automated transition to minimal risk condition when handover cannot be completed, and (4) data logging that supports post-hoc oversight by regulators and accident investigators.

Fleet operator oversight tools (Art.14(4)): Deployers of high-risk transport AI must put in place appropriate human oversight measures for their specific operational context. A fleet operator deploying SAE Level 3 vehicles must provide: real-time fleet monitoring dashboards, automated alerts for edge-case encounters, and escalation protocols when AI system status changes.

Art.26 Deployer Obligations — Fleet Operators and Traffic Authorities

When transport AI is deployed by fleet operators, logistics companies, public transport authorities, or smart city agencies, Art.26 applies to the deployer separately from the provider's obligations.

Key Art.26 obligations for transport deployers:

Use AI only within its intended purpose and ODD — if a transport operator deploys AI on road types or in weather conditions outside the documented ODD, they bear liability for that deployment decision.

Maintain human oversight capability — deployers must not disable or bypass the human oversight mechanisms the provider built under Art.14.

Monitor operation and report serious incidents — transport deployers must implement post-market monitoring for AI systems in use and report serious incidents to the provider, who in turn reports to national competent authorities under Art.73. For a serious accident where the AI system was involved, this chain must be documented.

Data logging compliance — transport operators must retain logs generated by high-risk AI systems. The log retention period should align with both the AI Act requirements and applicable national road accident investigation timelines.

Art.27 FRIA — Public Transport Operators

Art.27 requires certain deployers to conduct Fundamental Rights Impact Assessments before deploying high-risk AI. The obligation applies to deployers that are bodies governed by public law, or private entities performing public services, for specific categories of high-risk AI.

For transport, Art.27 applies when a public transport authority or government smart city agency deploys high-risk AI in Annex III Point 2 categories. A FRIA for public transport AI must assess:

• Impact on freedom of movement (does the AI restrict access to transport for specific population groups?)
• Non-discrimination in traffic management (does the AI systematically favor certain routes that disadvantage particular neighborhoods?)
• Data protection (Art.27(1)(d) requires reference to the data protection impact assessment if one was conducted)
• Environmental impact where relevant

Private logistics operators deploying Annex III Point 2 AI are generally not subject to Art.27 unless they perform public service obligations.

Intersection with Vehicle Safety Regulation (EU) 2019/2144

The EU Vehicle General Safety Regulation (GSR) mandates specific ADAS features for new type-approvals beginning July 2022 (for new vehicle types) and July 2024 (for all new vehicles). For transport AI developers, the critical intersection point is:

What GSR mandates, AI Act governs: Intelligent Speed Assistance (ISA) is mandatory under GSR. ISA that uses AI for speed limit recognition and vehicle speed control is simultaneously subject to type-approval under GSR (tested against UNECE R151) and high-risk AI classification under Annex III Point 2. A vehicle OEM providing ISA must satisfy both.

Documentation convergence opportunity: The GSR technical documentation for type-approval overlaps substantially with Art.11 technical documentation requirements under the EU AI Act. Automotive OEMs with existing UNECE R151 documentation packages can extend them to satisfy AI Act Art.11, but they will need to add: AI-specific performance metrics, bias testing results, and description of the risk management process in EU AI Act terminology.

Conformity assessment timing: Type-approval under GSR is granted by National Type Approval Authorities. Conformity assessment for high-risk AI is conducted by notified bodies (for Annex IV products) or self-declared via internal control (for most Annex III AI). These run in parallel and must both be completed before market placement.

NIS2 Intersection — Transport as Critical Infrastructure

The NIS2 Directive (Directive 2022/2555) designates transport as an essential sector in Annex I. Transport operators above the size threshold (50+ employees or €10M turnover in most member states) are essential entities subject to NIS2 security obligations.

For transport AI operators, NIS2 adds cybersecurity requirements that are distinct from but complementary to AI Act Art.15 (accuracy, robustness, cybersecurity):

• NIS2 Art.21 requires technical and organisational security measures proportionate to risk, explicitly including supply chain security. Transport AI systems sourced from third-party AI providers must include AI provider cybersecurity assessments.
• NIS2 Art.23 requires reporting of significant incidents to the competent authority within 24 hours (initial notification), 72 hours (incident notification), and one month (final report). A significant cybersecurity incident affecting transport AI — such as adversarial manipulation of traffic management AI — triggers this timeline in parallel with AI Act Art.73 serious incident reporting.
• Cross-reporting coordination: A serious incident under Art.73 AI Act and a significant incident under NIS2 Art.23 may arise from the same event. Transport operators should designate a single incident response lead responsible for coordinating both reporting chains simultaneously.

30-Step Transport AI Compliance Checklist

Classification (Steps 1–6)

1. Map every AI system in your product portfolio against the Annex III Point 2 safety component test
2. For each AI system, document the safety-critical actuation chain: what human decision steps (if any) separate AI output from safety actuation?
3. Classify as high-risk (Annex III Pt.2), GPAI transparency-only (Art.50), or general purpose
4. Check for intersecting regulations: GSR type-approval, UN-ECE R157/R151, ISO 26262, NIS2
5. Identify all deployers in your supply chain (fleet operators, traffic authorities) and their Art.26 obligations
6. Determine if any deployer is a public body subject to Art.27 FRIA requirement

Risk Management (Steps 7–12)

1. Define the Operational Design Domain (ODD) with specific, testable boundary conditions
2. Conduct HARA (Hazard Analysis and Risk Assessment) — if ISO 26262 HARA exists, extend it to cover AI-specific failure modes (data distribution shift, adversarial inputs)
3. Document residual risks after mitigation measures, with justification that risks are ALARP
4. Establish risk monitoring procedures for post-deployment operation
5. Define and document the minimum risk condition (MRC) the system transitions to when safety cannot be guaranteed
6. Test risk mitigation measures under simulated ODD boundary conditions

Data Governance (Steps 13–17)

1. Document training data sources, labelling methodology, and quality validation processes
2. Assess training data for geographic and demographic bias (road types, weather zones, traffic patterns)
3. Establish GDPR legal basis for any training data containing personal data (GPS trajectories, driver monitoring data)
4. Conduct DPIA if large-scale vehicle monitoring data is used for training
5. Document synthetic data augmentation approach and validation against real-world distributions

Technical Architecture (Steps 18–22)

1. Implement Art.14-compliant human oversight interface (take-over request, system status display, MRC transition)
2. Log all AI decisions with sufficient detail for post-hoc review by regulators and accident investigators
3. Implement cybersecurity measures per Art.15: adversarial robustness testing, model integrity checks
4. Design for graceful degradation at ODD boundaries (not sudden failure)
5. Test accuracy and robustness metrics — document minimum acceptable performance thresholds

Documentation (Steps 23–26)

1. Compile Art.11 technical documentation package (system architecture, ODD, training data, test results, risk management records)
2. Prepare instructions for use for deployers (Art.13) — must cover ODD limitations and human oversight obligations
3. Draft EU Declaration of Conformity (Art.47) once conformity assessment complete
4. Affix CE marking (Art.48) before EU market placement

Deployer Coordination (Steps 27–29)

1. Provide deployers with documented human oversight implementation requirements
2. Establish serious incident reporting chain: deployer → provider → NCA under Art.73 (within 15 working days of becoming aware)
3. Implement post-market monitoring data collection from deployers — minimum: incident reports, near-misses, ODD boundary encounters

Ongoing Compliance (Step 30)

1. Register high-risk AI system in the EU AI Act database before deployment (Art.49 registration requirement for high-risk AI placed on market in the EU)

The sota.io Perspective: Why Transport AI Needs EU-Native Infrastructure

For transport AI teams, the compliance documentation and monitoring requirements mean operational overhead proportional to the safety stakes. Logs must be maintained, incident reports filed, post-market data collected from deployers. When your AI system manages safety-critical decisions at scale, the infrastructure to store logs, monitor system behavior, and generate compliance reports is not optional.

EU-native hosting ensures that this operational data — vehicle sensor logs, AI decision records, incident data — stays within EU jurisdiction, satisfies GDPR geographic requirements, and is not subject to CLOUD Act-based US government access requests. For transport operators serving public authorities or government fleets, EU data sovereignty is often a procurement requirement, not just a compliance option.

This is the intersection where transport AI compliance and infrastructure choice converge: choosing EU-native infrastructure from day one eliminates one layer of compliance complexity for every subsequent deployment.

Key Deadlines for Transport AI Teams

Post #3 of 5 in the EU AI Act Sector-Specific Compliance Series. Next: EdTech deep-dive — student profiling, GDPR Art.22 automated decisions, and minor data protection requirements for educational AI.