Autonomous Vehicle AI Under the EU AI Act: The Annex I Classification Route
Autonomous-vehicle AI: high-risk via the Article 6(1)/Annex I type-approval route, with integrated conformity and a 2 August 2028 deadline.
This page lives in the "annex-iii" folder, but the correct legal basis for autonomous-vehicle and ADAS safety AI is not Annex III. It is Article 6(1) combined with Annex I of Regulation (EU) 2024/1689. That distinction shapes every obligation, every deadline, and every conformity procedure that follows — so it is worth stating plainly before anything else.
Why the Classification Route Matters
The EU AI Act sorts AI systems into risk tiers by two separate paths:
- Article 6(1) + Annex I: AI that is a safety component of a product covered by EU product harmonisation law, where that product already requires third-party conformity assessment. High-risk via the product route.
- Article 6(2) + Annex III: AI systems listed by use-case area (recruitment, credit scoring, biometrics, critical infrastructure, etc.). High-risk via the standalone AI-system route.
An AI system controlling steering, braking, or collision avoidance in a motor vehicle does not enter Annex III at all. It enters the high-risk tier through Article 6(1) because it is a safety component of a product — the vehicle — covered by Regulation (EU) 2018/858 (the motor vehicle type-approval framework) and Regulation (EU) 2019/2144 (the General Safety Regulation, which mandates systems such as autonomous emergency braking, lane-keeping assistance, and intelligent speed assistance). Those regulations require third-party conformity assessment before a vehicle can be placed on the EU market. Both conditions in Article 6(1) are satisfied.
The practical consequence: the AI Act requirements are integrated into the existing type-approval process, not administered as a separate AI-specific conformity assessment. There is no standalone Article 43 procedure under Annex VI or Annex VII for these systems. The type-approval authority and its technical services assess compliance with the AI Act's Chapter III requirements (Articles 9–15) as part of the broader vehicle approval.
The compliance deadline also differs. Under the Digital Omnibus (political agreement reached 7 May 2026, formal adoption expected before 2 August 2026), Annex III stand-alone high-risk systems must comply from 2 December 2027, but Annex I product-embedded high-risk AI systems — including vehicle safety AI — must comply from 2 August 2028. If you are developing or certifying ADAS or autonomous driving AI today, 2 August 2028 is your hard date.
What Counts as Vehicle Safety AI
Regulation (EU) 2019/2144 mandates a set of advanced vehicle safety systems — among them: autonomous emergency braking (AEB), lane-keeping assistance (LKA), intelligent speed assistance (ISA), driver drowsiness and attention monitoring, and reversing detection. Where any of these functions is delivered by an AI system, Article 6(1) of the EU AI Act applies.
The test is whether the AI system functions as a safety component of the vehicle. An algorithm that adjusts headrest position is probably not a safety component in the relevant sense. An algorithm that decides whether and when to apply full emergency braking manifestly is. The line is not always clean, but the functional question — would a failure of this AI system directly create a risk of death or serious injury? — provides the practical filter.
ADAS versus full autonomy: the Article 6(1) route applies across the spectrum. A Level 2 ADAS system providing lane-keeping and adaptive cruise control on a production car, a Level 4 automated driving system for a defined urban route, and the perception stack of a freight autonomous vehicle are all subject to the same legal basis if they function as safety components of vehicles that require type-approval under EU law.
Infrastructure-level traffic management AI is a different question. AI operated by public authorities to manage traffic signals, congestion pricing, or emergency routing may fall under Annex III point 2 (critical infrastructure) rather than the Annex I product route. The obligations are similar in substance but the procedural path differs — that system is subject to the Annex III standalone process and the 2 December 2027 deadline, not the type-approval integration described here. See the Annex III critical infrastructure guide for that route.
Who Is the Provider
Under Article 3 of the EU AI Act, the provider is the entity that develops and places the AI system on the market or puts it into service under its own name or trademark. For vehicle safety AI, this is typically:
- The vehicle manufacturer (OEM) if it developed the AI system in-house and integrates it into a vehicle it places on the market.
- The Tier-1 system supplier if it develops the AI system — say, an autonomous emergency braking stack — and supplies it to OEMs as a named component or system under its own brand. In that case the supplier is the provider of the AI system; the OEM is effectively a deployer of that system within the vehicle it manufactures.
The boundary matters because the provider carries the heaviest obligations: the risk management system under Article 9, the technical documentation under Article 11 and Annex IV, the post-market monitoring plan under Article 72, and the Article 73 serious-incident reporting duty to market-surveillance authorities.
Article 25 sharpens the analysis: a distributor, importer, or deployer becomes the provider if it places a high-risk system on the market under its own name, substantially modifies it, or changes its intended purpose. An OEM that takes a supplier's perception module and integrates it with its own decision logic to create a system with a materially different intended use should take legal advice on whether that integration constitutes substantial modification.
The Obligation Stack for Providers
Risk Management System — Article 9
A documented risk management system must operate continuously throughout the AI system's lifecycle. For vehicle safety AI, this means systematic identification of failure modes — sensor degradation, edge-case recognition failures, software update interactions, adversarial conditions — and documented risk-acceptance criteria. The Article 9 risk management system complements, but is not identical to, functional safety processes under ISO 26262 (road vehicles) and ISO/PAS 21448 (SOTIF — safety of the intended functionality). Both are expected to exist; the AI Act requires that the risk management logic is documented in the technical file in a form that the type-approval authority can assess.
Data and Data Governance — Article 10
Training, validation, and testing data must be subject to governance practices that address relevance, representativeness, and freedom from error. For perception AI trained on camera, radar, or lidar data, the Article 10 analysis must cover: geographic diversity (road conditions in southern Spain differ from those in Finland), edge-case representation (pedestrians in poor visibility, cyclists without helmets, unusual cargo on roads), and data labelling quality. Any known dataset limitation must be documented and its implications for system performance stated — not swept under the rug.
Technical Documentation — Article 11 and Annex IV
Annex IV specifies nine content areas: general system description and version history; detailed design architecture and training data characteristics; monitoring and control mechanisms; performance metrics and their appropriateness; risk management documentation; lifecycle change descriptions; list of harmonised standards applied; copy of the EU Declaration of Conformity; and post-market monitoring plan. This documentation forms the technical file submitted as part of the vehicle type-approval. Technical services assessing the vehicle will review it alongside the functional safety documentation required under the existing regulations.
Retention: the technical documentation must be kept for ten years after the system is placed on the market (Article 18).
Human Oversight — Article 14
Article 14 requires providers to design their high-risk systems so that human oversight is possible and effective. In the vehicle context, this is expressed as driver-in-the-loop requirements. The system must be designed so the driver receives clear information about what the system is and is not doing (Article 13, which covers information to deployers and, by extension, to drivers through the system's interface), can recognise when the system is operating at the boundary of its capabilities, and can intervene and resume manual control within a time frame that does not create a new safety hazard.
The UNECE framework on automated/autonomous vehicles — particularly WP.29 regulations — intersects here. UNECE Regulation No 157 on automated lane-keeping systems, for example, specifies transition-demand and minimal-risk-manoeuvre requirements that operationalise driver oversight at the functional level. Compliance with those technical standards will be relevant evidence for Article 14, though it is not a substitute for it: the AI Act asks specifically about oversight of the AI system's decision logic, not just the vehicle's overall behaviour.
Accuracy, Robustness, and Cybersecurity — Article 15
Article 15 requires high-risk AI systems to achieve appropriate levels of accuracy, robustness, and cybersecurity. For vehicle perception and decision AI:
- Accuracy: object detection performance must be specified, validated, and documented against defined test scenarios. The test set must cover the edge cases that matter for road safety — partial occlusion, adverse weather, road degradation — not just nominal conditions.
- Robustness: the system must maintain adequate performance under input variations, sensor degradation, and adversarial conditions. Performance degradation curves must be documented.
- Cybersecurity: this is where Article 15 intersects directly with UNECE Regulations R155 (cybersecurity management system for vehicles) and R156 (software update management). R155 requires OEMs to manage cyber risks across the vehicle's lifecycle, including its AI components; R156 governs over-the-air software updates. The EU AI Act adds a requirement to document cybersecurity measures in the technical file as part of AI-system compliance. These are not duplicative: R155 focuses on the vehicle-level cybersecurity management system; Article 15 focuses on the properties of the AI system itself.
Post-Market Monitoring — Article 72
Providers must establish and maintain a post-market monitoring system that actively collects and analyses operational data to detect performance degradation, safety issues, and new risks not anticipated at the time of the initial assessment. For vehicle AI, this feeds directly into the market surveillance obligations under Regulation (EU) 2018/858: type-approval authorities conduct market surveillance on vehicles in service, and serious AI-related safety issues will fall within that surveillance perimeter.
The interplay is deliberate: Article 72 post-market monitoring by the provider feeds data that may trigger corrective actions or, in serious cases, Article 73 reporting obligations. The type-approval framework has its own recall and remediation mechanisms; the AI Act obligations layer on top, with the Article 72 monitoring plan forming part of the technical file reviewed at type-approval.
Serious Incident Reporting — Article 73
Providers must report serious incidents — defined in Article 3(49) — to the market-surveillance authority of the member state where the incident occurred. The timelines under Article 73 are: no later than 15 days from becoming aware of the incident (standard); 2 days where the incident involves widespread infringement or serious and irreversible disruption of critical infrastructure; 10 days where a person has died. These deadlines are independent of the vehicle recall and incident-notification obligations under Regulation (EU) 2018/858, though in practice an OEM will need to manage both notification streams together.
The Conformity Assessment: Integration, Not Duplication
Article 43(3) of the EU AI Act states directly that for high-risk AI systems covered by the harmonisation legislation in Annex I, the provider must follow the conformity assessment procedure required by that legislation. The AI Act's Chapter III requirements (Articles 9–15) apply and are part of that assessment. A notified body notified under the relevant product legislation is entitled to assess compliance with the AI Act requirements as part of the same procedure, provided it meets the AI Act's requirements for notified bodies.
For motor vehicles, this means the type-approval process under Regulation (EU) 2018/858 is the conformity assessment for AI Act purposes. The vehicle manufacturer does not run a separate AI Act conformity assessment; it demonstrates compliance with Articles 9–15 through the technical documentation it submits to the approval authority, which is then assessed by the technical service.
There is one nuance: Regulation (EU) 2018/858 and Regulation (EU) 2019/2144 sit in Section B of Annex I — the "other harmonisation legislation" section, as distinct from the New Legislative Framework legislation in Section A. Article 43(3) refers to Section A. That means the mandatory third-party conformity assessment requirement must be found in the applicable regulation directly. Regulation (EU) 2019/2144 does mandate third-party type-approval for the systems it governs — which satisfies the second condition in Article 6(1). The integrated-assessment approach of Article 43(3) applies by the same logic: the AI Act requirements travel through the type-approval gate.
The upshot: vehicle AI providers do not register their systems in the EU database for high-risk AI systems under Article 49 (that registration obligation applies to Annex III systems, not Article 6(1) systems). They do need to prepare an EU Declaration of Conformity under Article 47 covering the AI Act requirements, as part of the type-approval package.
Deployer Obligations
Fleet operators, autonomous vehicle service providers, and others who deploy vehicle safety AI in a professional context carry deployer obligations under Article 26. Key duties:
- Operate the system only within its intended use and documented performance envelope. Using an ADAS system outside its defined operational design domain — for example, in conditions not covered by its validation data — is a compliance failure.
- Implement human oversight measures as described by the provider. If the system's instructions require drivers to remain attentive and in a position to resume control, the deployer must train drivers and enforce that requirement.
- Monitor the system's performance in use, compare it against provider-documented baselines, and flag risks or malfunctions to the provider under Article 26.
- Retain logs for at least six months under Article 26.
The deployer's Article 73 obligations are narrower than the provider's: deployers flag serious incidents to the provider (and, where required, to the competent authority), but the primary reporting duty to authorities sits with the provider. An OEM operating its own vehicle fleet — a common configuration for robotaxi services — is both provider and deployer simultaneously.
The Regulatory Overlap Map
Vehicle safety AI sits at the intersection of four regulatory regimes. None of them replaces the others; they layer.
| Requirement | Primary instrument | Applies to |
|---|---|---|
| AI risk management, technical documentation, oversight | EU AI Act Arts 9–15 | AI system provider |
| Vehicle type-approval, market surveillance | Regulation (EU) 2018/858 | OEM / vehicle manufacturer |
| Safety system mandates (AEB, LKA, ISA, etc.) | Regulation (EU) 2019/2144 | OEM |
| Cybersecurity management | UNECE R155 | OEM + supply chain |
| Software update management | UNECE R156 | OEM |
The EU AI Act's AI-specific requirements are assessed through the type-approval gate. Compliance with UNECE R155 and R156 is relevant evidence for Article 15 cybersecurity and software-update claims — but the AI Act asks you to document the AI system's properties specifically, not just certify a management system.
What Confir Does Here
The compliance challenge for vehicle safety AI is primarily a documentation and structuring problem. The legal obligations are clear; the difficulty is assembling the Annex IV technical file in a form that is internally consistent, covers all nine documentation areas, and is defensible to a type-approval technical service that may be assessing AI compliance for the first time.
Confir's classification engine — deterministic and rule-based, not AI-generated — confirms the Article 6(1) route and scopes the obligation set: Articles 9, 10, 11/Annex IV, 13, 14, 15, 18, 47, 72, and 73 all apply; the standalone Article 43 Annex VI/VII conformity assessment does not. From there, Confir structures the technical documentation pack — the nine Annex IV areas, the Article 47 Declaration of Conformity, and the Article 72 post-market monitoring plan outline — into a print-ready file that a legal or engineering team can populate with system-specific content.
Pricing from €600/year. No consultants. No six-month implementation.
Penalties
Non-compliance with the high-risk requirements — including Articles 9–15 and the provider obligations in Article 16 — carries a maximum fine of €15 million or 3% of worldwide annual turnover, whichever is higher (Article 99(4)). For start-ups and companies below SME thresholds, Article 99(6) caps the fine at the lower of the percentage or the fixed amount.
Market-surveillance actions under Regulation (EU) 2018/858 can run in parallel — including type-approval withdrawal, market access suspension, and mandatory recall — where a vehicle or component fails to meet its approved specification.
Frequently Asked Questions
Is autonomous vehicle AI classified under Annex III of the EU AI Act?
No. AI that functions as a safety component of a motor vehicle that requires EU type-approval is high-risk under Article 6(1) combined with Annex I of the EU AI Act — not under Annex III. Annex III point 2 (critical infrastructure) may apply to AI used by public authorities for traffic management, but that is a separate system category.
What is the compliance deadline for vehicle safety AI?
2 August 2028. Under the Digital Omnibus (political agreement, May 2026), high-risk AI embedded in products covered by EU harmonisation legislation (Annex I) must comply from 2 August 2028 — not the 2 December 2027 date that applies to stand-alone Annex III systems.
Does the AI Act require a separate conformity assessment for vehicle safety AI?
No. Under Article 43(3), the AI Act requirements are integrated into the existing type-approval conformity assessment. There is no standalone Annex VI internal control or Annex VII notified-body procedure on top of type-approval. Compliance with Articles 9–15 is demonstrated through the technical documentation submitted to the type-approval authority.
Do vehicle AI providers need to register in the EU database?
The Article 49 registration obligation in the EU database applies to Annex III high-risk systems. Annex I product-route systems are not subject to the same registration requirement. Providers must still prepare the Article 47 Declaration of Conformity as part of type-approval.
How does UNECE R155 cybersecurity relate to Article 15 of the EU AI Act?
They overlap but are not identical. R155 requires OEMs to have a certified cybersecurity management system (CSMS) covering the vehicle's supply chain and lifecycle. Article 15 of the EU AI Act requires the AI system itself to achieve adequate cybersecurity — covering measures against model poisoning, adversarial inputs, and unauthorised access. R155 compliance is strong supporting evidence for Article 15, but the AI system's specific cybersecurity properties must still be documented in the Annex IV technical file.
What happens if a Tier-1 supplier develops the AI system and the OEM integrates it?
The Tier-1 supplier is the provider of the AI system if it places the system on the market under its own name. The OEM is a deployer of that system (in addition to being the vehicle manufacturer subject to type-approval obligations). If the OEM substantially modifies the AI system or changes its intended purpose during integration, Article 25 may convert the OEM into the provider for that modified system — a question that should be addressed in the supply contract.
Related guides
- enterprise compliance guide
- Article 6 high-risk classification criteria
- Article 9 risk management obligations
- risk classification framework
- risk assessment methodology requirements
- high-risk AI system assessment framework
- Annex III high-risk use cases
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. 7-day free trial.
Start free trial →