If you are building AI systems for passenger cars, vans, trucks, or buses sold in the EU, Article 107 of the EU AI Act directly affects your compliance obligations. EU AI Act Art.107 amends Regulation (EU) 2019/2144 — the EU General Safety Regulation for Motor Vehicles (GSOMV) — to formally integrate EU AI Act requirements into the mainstream automotive sector covering M-category (passenger vehicles) and N-category (goods vehicles) vehicles.
The amendment creates an Annex I bridge identical in mechanism to Art.105 and Art.106: AI systems embedded in M and N category vehicles that qualify as safety components or systems under Reg. 2019/2144 become high-risk AI systems through the Art.6(1) pathway, triggering the full Title III EU AI Act compliance stack. This matters most for automated lane keeping systems (ALKS), autonomous emergency braking (AEB), intelligent speed assistance (ISA), driver monitoring systems, and eCall — all mandated under Reg. 2019/2144 and increasingly reliant on machine learning inference rather than rule-based logic.
What Regulation (EU) 2019/2144 Covers
Regulation (EU) 2019/2144 establishes general safety requirements for motor vehicles and their trailers, and systems, components, and separate technical units (STU) intended for such vehicles. It replaced Directive 2007/46/EC as the EU's primary general motor vehicle type-approval framework.
The regulation covers the following vehicle categories:
| Category | Description | Examples | AI Relevance |
|---|---|---|---|
| M1 | Passenger cars, ≤8 seats + driver | Passenger cars, SUVs | HIGH (ALKS, AEB, ISA, DDAW, eCall) |
| M2 | Minibuses, ≤5t GVM | Minibuses, minivans | HIGH (AEB, ISA, DDAW) |
| M3 | Buses, >5t GVM | City buses, coaches | HIGH (AEB, ISA, DDAW, AEBS) |
| N1 | Light commercial vehicles, ≤3.5t | Vans, pickup trucks | HIGH (AEB, ISA, DDAW) |
| N2 | Medium trucks, 3.5–12t | Medium haulage | HIGH (AEB, AEBS, ISA) |
| N3 | Heavy trucks, >12t | HGV, articulated lorries | HIGH (AEBS, LDWS, ISA) |
| O1/O2 | Light trailers | Caravans, trailers ≤3.5t | Low |
| O3/O4 | Heavy trailers | Semi-trailers | Medium (AEBS integration) |
Reg. 2019/2144 mandated a phased introduction of advanced safety systems. Several systems that were optional or newly mandated are now AI-driven rather than purely sensor-based or deterministic rule systems.
What Art.107 Actually Changes
Article 107 is a targeted legislative amendment. Like Art.105 (agricultural vehicles) and Art.106 (two/three-wheel vehicles), it inserts EU AI Act references into the safety system provisions of Reg. 2019/2144.
The operative mechanism: AI systems in M and N category vehicles that constitute safety systems or components under Reg. 2019/2144 now sit within EU AI Act Annex I, activating the Art.6(1) high-risk pathway. Compliance requires satisfying both:
- Reg. 2019/2144 type-approval obligations — UN technical regulations (Reg. 157, 152, 131), national type approval, WVTA, market surveillance
- EU AI Act Title III obligations — technical documentation (Annex IV), QMS (Art.9), conformity assessment (Art.43), post-market monitoring (Art.72), incident reporting (Art.65)
The classification trigger is the safety system designation within the WVTA (Whole Vehicle Type Approval) dossier. If the AI-based component is listed as a safety system in the type-approval, it is high-risk under the EU AI Act.
Which GSOMV AI Systems Become High-Risk
The high-risk classification applies when the AI system constitutes or is embedded within a safety system mandated or regulated under Reg. 2019/2144. The following systems are directly affected:
Definitively High-Risk
ALKS — Automated Lane Keeping System (UN Reg. 157)
ALKS is an SAE Level 3 automated driving function: the vehicle can control lateral and longitudinal motion within its operational design domain (ODD) without continuous driver supervision. UN Regulation 157 provides the technical standard; Reg. 2019/2144 references it as a mandatory approval pathway for Level 3+ automated driving.
Any ALKS system using machine learning for environment perception, trajectory planning, or handback request determination is definitively high-risk. The failure modes — lateral drift into adjacent lanes, failure to detect slow-moving or stationary objects, incorrect ODD boundary detection — are life-safety critical. The Art.9 QMS requirement must include ODD documentation, edge-case training data, and validation protocols aligned with UN Reg. 157 system testing requirements.
AEB/AEBS — Autonomous Emergency Braking (UN Reg. 152 for M1/N1, ECE R131 for M2/M3/N2/N3)
AEB systems for passenger cars and light vans are governed by UN Regulation 152. Advanced Emergency Braking Systems (AEBS) for heavy trucks and buses operate under ECE Regulation 131. Both regulations require specific performance scenarios (car-to-car, car-to-pedestrian, car-to-cyclist, night conditions) that modern implementations satisfy using deep learning-based object detection and trajectory prediction.
A neural-network-based perception module feeding an AEB activation decision is definitively high-risk. False negatives (failure to brake) and false positives (unnecessary braking at speed) both represent life-safety failure modes. Training data geographic and demographic representation requirements under Art.10 are particularly demanding given the variety of road user types, weather conditions, and road environments.
Driver Drowsiness and Attention Warning (DDAW)
Reg. 2019/2144 mandated DDAW as compulsory for new M1 and N1 vehicles from 2022 and all new vehicles from 2024. Modern DDAW systems use computer vision analysis of eye closure patterns, head position, and steering behaviour. Camera-based DDAW using facial landmark detection or gaze estimation is an AI system meeting the Art.3(1) definition.
Where DDAW triggers an alert that the driver acts upon (reducing an accident), or where DDAW data feeds into a connected emergency response system, it constitutes a safety component. High-risk classification applies.
ISA — Intelligent Speed Assistance
ISA was mandated for all new M and N vehicles from July 2022 (new models) and July 2024 (all new vehicles). ISA systems combine map data with sign-recognition AI: camera-based traffic sign recognition (TSR) modules read speed limit signs and present or apply speed limits. Sign recognition using convolutional neural networks is AI under Art.3(1). Where the AI output directly affects vehicle speed (advisory or intervention mode), it is a safety system under Reg. 2019/2144 and therefore high-risk.
Conditionally High-Risk
Lane Departure Warning and Correction
Lane departure warning (LDW) and lane keeping assist (LKA) systems use camera-based lane marking detection. LDW purely issuing an alert is borderline; LKA applying a steering correction is a safety intervention. AI-based LKA that applies corrective torque to the steering system is a safety component.
Event Data Recorder (EDR)
Reg. 2019/2144 mandates EDRs for M1 vehicles from July 2022. EDR systems that use AI to classify accident severity, determine trigger thresholds based on sensor fusion, or generate automated incident reports are AI systems under Art.3(1). Where the EDR classification directly influences post-accident response (emergency services activation, insurance assessment), high-risk classification may apply.
Reversing Detection Systems
Camera and sensor-based reversing systems with AI-driven object detection and proximity classification are safety components for manoeuvring assistance. High-risk classification applies when the AI output can activate automatic braking or steering intervention.
The Dual Compliance Pathway
Satisfying both Reg. 2019/2144 and the EU AI Act requires integrating two distinct compliance workflows that have different timelines, documentation formats, and authority relationships.
Type Approval Side (Reg. 2019/2144)
The WVTA process is managed by the vehicle OEM as the type-approval applicant. Technical services (nationally accredited) conduct testing against UN Regulations. The approval authority (KBA in Germany, DREAL in France, VCA in the UK pre-Brexit) issues the type approval certificate.
For AI-based safety systems, the OEM must submit:
- Software version identification and change management procedure
- Validation test results for all mandated performance scenarios (UN Reg. 157 / ECE R131 / UN Reg. 152)
- ODD documentation for ALKS
- Cybersecurity management system (CSMS) per UN Regulation 155
- Software update management system (SUMS) per UN Regulation 156
EU AI Act Side (Title III)
The EU AI Act obligations apply to the provider of the AI system — which is not always the vehicle OEM.
In modern automotive supply chains, the AI perception and decision stack is often supplied by Tier-1 suppliers (Mobileye, Bosch, Continental, Aptiv, ZF) or specialist AI companies. The OEM integrates these AI components into the vehicle platform. This creates a provider/deployer split that must be explicitly mapped.
| Role | Party | EU AI Act Obligations |
|---|---|---|
| AI system provider | Mobileye, Bosch, Continental (ADAS stack supplier) | Art.11 (tech docs), Art.9 (QMS), Art.43 (conformity assessment), Art.65 (incident reporting) |
| AI system deployer | Vehicle OEM | Art.26 (deployer obligations), Art.72 (post-market monitoring) |
| Importer / Distributor | Vehicle importer | Art.23/24 (registration, due diligence) |
Where the OEM builds the AI system in-house (Tesla Autopilot, BMW, Mercedes), the OEM is both provider and deployer.
Conformity Assessment Integration
For high-risk AI systems covered by harmonisation legislation in Annex I, Art.43(2) applies: the conformity assessment for the AI system must be carried out as part of the conformity assessment under the sector regulation. This means integrating EU AI Act documentation requirements into the WVTA technical dossier rather than running a separate parallel assessment.
In practice, for ALKS:
- The UN Reg. 157 validation data package must also satisfy EU AI Act Art.10 training data documentation requirements
- The ODD documentation satisfies both UN Reg. 157 operational design domain requirements and EU AI Act intended purpose documentation
- The CSMS under UN Reg. 155 must align with the EU AI Act's cybersecurity requirements under Art.15
Provider-Deployer Interface in Automotive AI
The Tier-1 supplier model creates structured provider-deployer interfaces that must be contractually defined. The AI system provider (Mobileye, Bosch, etc.) must:
- Provide complete technical documentation per Annex IV to the OEM for integration into the WVTA dossier
- Define the operational conditions within which the AI system performs as specified (equivalent to ODD for non-ALKS systems)
- Establish incident reporting protocols with the OEM for Art.65 serious incident notification chains
- Provide post-market monitoring data access under Art.72
The OEM as deployer must:
- Integrate the AI technical documentation into the overall vehicle technical file
- Implement the post-market monitoring plan at the fleet level
- Report serious incidents to the NCA (national type approval authority) under both Reg. 2019/2144 (defect reporting) and EU AI Act Art.65
- Maintain records of the AI system version installed in each vehicle for the 10-year minimum Art.18 retention period
This dual-reporting chain is particularly complex for ALKS, where a single serious incident may trigger simultaneous notifications to the type-approval authority (under Reg. 2019/2144 defect reporting), the NCA under EU AI Act Art.65, and potentially the CSMS authority under UN Reg. 155.
CLOUD Act Intersection for Connected Vehicles
Modern AI systems in vehicles do not run in isolation. They depend on connectivity for:
- OTA software update delivery (UN Reg. 156 SUMS requires software update management)
- Post-market monitoring data transmission (Art.72 post-deployment performance data)
- Map data for ALKS ODD boundary determination
- HD map updates for ISA and ALKS
- Connected eCall data transmission (mandated eCall in EU since 2018 for M1 vehicles)
Where these services are provided by US-headquartered cloud platforms (AWS, Azure, Google Cloud), the CLOUD Act creates a legal conflict: US authorities can compel the cloud provider to disclose vehicle operational data, incident data, and monitoring data stored on US-controlled servers — regardless of where the physical servers are located.
For automotive AI providers with EU operations, the CLOUD Act exposure extends to:
| Data Type | CLOUD Act Risk | Mitigation |
|---|---|---|
| OTA update packages and version history | Medium (IP + security disclosure) | EU-sovereign OTA delivery platform |
| Post-market monitoring telemetry | HIGH (incident data, near-miss patterns) | EU-hosted monitoring infrastructure |
| ALKS operational logs (trajectory, sensor fusion) | HIGH (accident reconstruction evidence) | EU-sovereign log storage |
| Driver monitoring camera data | CRITICAL (biometric + GDPR Art.9) | EU-sovereign processing, no US transfer |
| eCall emergency data | HIGH (location + occupant data at accident time) | EU-hosted eCall PSAP connectivity |
Automotive AI providers evaluating cloud infrastructure should assess whether their OTA, monitoring, and telemetry platforms are under EU-sovereign jurisdiction to eliminate CLOUD Act exposure for accident-relevant AI data.
Python Tooling: GSOMV AI Compliance Tracker
from dataclasses import dataclass, field
from enum import Enum
from typing import Optional
class VehicleCategory(Enum):
M1 = "M1" # Passenger cars
M2 = "M2" # Minibuses
M3 = "M3" # Buses
N1 = "N1" # Light commercial
N2 = "N2" # Medium trucks
N3 = "N3" # Heavy trucks
class AISystemType(Enum):
ALKS = "ALKS" # Automated Lane Keeping
AEB_M1N1 = "AEB_M1N1" # UN Reg. 152
AEBS_HCV = "AEBS_HCV" # ECE R131
ISA = "ISA" # Intelligent Speed Assistance
DDAW = "DDAW" # Driver Drowsiness/Attention Warning
LDW_LKA = "LDW_LKA" # Lane Departure Warning/Keeping Assist
EDR = "EDR" # Event Data Recorder
REV_DET = "REV_DET" # Reversing Detection
ECALL = "ECALL" # Emergency Call System
class HighRiskStatus(Enum):
DEFINITIVE = "definitive"
CONDITIONAL = "conditional"
NOT_HIGH_RISK = "not_high_risk"
@dataclass
class GSOMVAISystem:
system_type: AISystemType
vehicle_category: VehicleCategory
uses_ml: bool
un_regulation: str
provider_company: str
oem_deployer: str
cloud_platform: Optional[str] = None
cloud_us_jurisdiction: bool = False
def classify_high_risk(self) -> HighRiskStatus:
definitively_high_risk = {
AISystemType.ALKS,
AISystemType.AEB_M1N1,
AISystemType.AEBS_HCV,
AISystemType.ISA,
AISystemType.DDAW,
}
conditionally_high_risk = {
AISystemType.LDW_LKA,
AISystemType.EDR,
AISystemType.REV_DET,
}
if not self.uses_ml:
return HighRiskStatus.NOT_HIGH_RISK
if self.system_type in definitively_high_risk:
return HighRiskStatus.DEFINITIVE
if self.system_type in conditionally_high_risk:
return HighRiskStatus.CONDITIONAL
return HighRiskStatus.NOT_HIGH_RISK
def dual_compliance_obligations(self) -> dict:
hr = self.classify_high_risk()
if hr == HighRiskStatus.NOT_HIGH_RISK:
return {"eu_ai_act": False, "gsomv_type_approval": True}
return {
"eu_ai_act": True,
"gsomv_type_approval": True,
"eu_ai_act_articles": ["Art.9 QMS", "Art.10 Data", "Art.11 TechDoc",
"Art.43 Conformity", "Art.65 Incidents", "Art.72 PMM"],
"un_regulation": self.un_regulation,
"provider_obligations": self.provider_company,
"deployer_obligations": self.oem_deployer,
"cloud_act_risk": self.cloud_us_jurisdiction,
}
def cloud_act_assessment(self) -> str:
if not self.cloud_us_jurisdiction:
return "No CLOUD Act exposure: EU-sovereign platform"
risk_map = {
AISystemType.ALKS: "CRITICAL — ALKS operational logs contain accident reconstruction data",
AISystemType.AEB_M1N1: "HIGH — AEB incident data may be compelled in litigation",
AISystemType.AEBS_HCV: "HIGH — AEBS logs relevant to commercial vehicle accidents",
AISystemType.DDAW: "HIGH — Driver biometric monitoring data (GDPR Art.9 + CLOUD Act)",
AISystemType.ISA: "MEDIUM — Speed data correlation with accident reports",
}
return risk_map.get(self.system_type,
"MEDIUM — Review data categories for CLOUD Act exposure")
def build_compliance_matrix(systems: list[GSOMVAISystem]) -> dict:
matrix = {
"total_systems": len(systems),
"high_risk_definitive": [],
"high_risk_conditional": [],
"cloud_act_exposed": [],
"dual_compliance_required": [],
}
for sys in systems:
status = sys.classify_high_risk()
if status == HighRiskStatus.DEFINITIVE:
matrix["high_risk_definitive"].append(sys.system_type.value)
elif status == HighRiskStatus.CONDITIONAL:
matrix["high_risk_conditional"].append(sys.system_type.value)
if sys.cloud_us_jurisdiction:
matrix["cloud_act_exposed"].append(sys.system_type.value)
if status != HighRiskStatus.NOT_HIGH_RISK:
matrix["dual_compliance_required"].append(sys.system_type.value)
return matrix
# Example: Passenger car ADAS stack
if __name__ == "__main__":
vehicle_systems = [
GSOMVAISystem(
system_type=AISystemType.ALKS,
vehicle_category=VehicleCategory.M1,
uses_ml=True,
un_regulation="UN Reg. 157",
provider_company="Mobileye",
oem_deployer="Vehicle OEM",
cloud_platform="AWS",
cloud_us_jurisdiction=True,
),
GSOMVAISystem(
system_type=AISystemType.AEB_M1N1,
vehicle_category=VehicleCategory.M1,
uses_ml=True,
un_regulation="UN Reg. 152",
provider_company="Bosch",
oem_deployer="Vehicle OEM",
cloud_platform="Azure",
cloud_us_jurisdiction=True,
),
GSOMVAISystem(
system_type=AISystemType.ISA,
vehicle_category=VehicleCategory.M1,
uses_ml=True,
un_regulation="Reg. 2019/2144 Annex II",
provider_company="HERE Technologies",
oem_deployer="Vehicle OEM",
cloud_platform="HERE Cloud (EU)",
cloud_us_jurisdiction=False,
),
GSOMVAISystem(
system_type=AISystemType.DDAW,
vehicle_category=VehicleCategory.M1,
uses_ml=True,
un_regulation="Reg. 2019/2144 Annex II",
provider_company="Seeing Machines",
oem_deployer="Vehicle OEM",
cloud_platform="AWS",
cloud_us_jurisdiction=True,
),
]
matrix = build_compliance_matrix(vehicle_systems)
print(f"Vehicle AI compliance matrix: {matrix}")
for sys in vehicle_systems:
print(f"\n{sys.system_type.value}: {sys.classify_high_risk().value}")
print(f" CLOUD Act: {sys.cloud_act_assessment()}")
UN Regulation 157 and ALKS: The SAE L3 Compliance Interface
UN Regulation 157 is the primary technical standard for automated lane-keeping systems operating at SAE Level 3. The regulation defines the Operational Design Domain (ODD) within which ALKS may operate without continuous driver supervision:
- Motorways and controlled-access roads only
- Up to 130 km/h (initial approval) or 60 km/h for urban automated driving applications
- Dry and wet road conditions within defined parameters
- Daytime and nighttime operation
For EU AI Act purposes, the ALKS ODD definition maps directly to the intended purpose documentation required under Art.9 and Annex IV. An AI system operating outside its validated ODD is operating outside its intended purpose — a high-risk condition. The Art.72 post-market monitoring plan must include ODD boundary detection logging and out-of-ODD operation alerts.
The UN Reg. 157 system testing requirements — including cut-in scenarios, slow stationary vehicle detection, and handback request response — provide a partial but not complete validation dataset for EU AI Act Art.10 training data and test data documentation. Providers must supplement UN Reg. 157 test scenarios with broader edge case coverage documentation.
25-Item GSOMV AI Compliance Readiness Checklist
HIGH-RISK CLASSIFICATION (Art.6(1), Annex I)
- 1. Identify all AI systems embedded in M or N category vehicles in EU type-approval scope
- 2. Determine whether each AI system constitutes a safety component or system under Reg. 2019/2144
- 3. Confirm whether the AI system uses machine learning (neural networks, statistical models) rather than purely deterministic logic
- 4. Map each AI system to its applicable UN regulation (UN Reg. 157, 152, ECE R131, etc.)
- 5. Apply Art.6(1) + Annex I classification: safety component under Reg. 2019/2144 = high-risk
PROVIDER-DEPLOYER SPLIT
- 6. Identify the legal entity as provider (AI system developer/supplier) vs. deployer (vehicle OEM)
- 7. Establish contractual interfaces for technical documentation transfer from Tier-1 to OEM
- 8. Define incident reporting chain between AI provider and OEM under Art.65
- 9. Assign post-market monitoring responsibilities between provider (data collection) and deployer (fleet-level monitoring)
TECHNICAL DOCUMENTATION (Annex IV)
- 10. Document AI system description, intended purpose, and ODD scope for ALKS systems
- 11. Describe training data sources, geographic coverage, and environmental condition representation
- 12. Define accuracy, robustness, and performance metrics aligned with applicable UN regulation test scenarios
- 13. Document validation methodology integrating UN regulation physical tests with EU AI Act statistical validation
- 14. Describe sensor fusion pipeline, perception model architecture, and decision logic
QUALITY MANAGEMENT SYSTEM (Art.9)
- 15. Implement QMS covering data governance, model training, validation, and post-deployment monitoring
- 16. Define risk management procedures identifying automotive-specific failure modes (adverse weather, lane marking quality, cyclist detection at night)
- 17. Establish change management criteria for model updates triggering re-assessment
- 18. Align QMS with ISO 26262 (functional safety) and ISO 21448 (SOTIF) documentation requirements
CONFORMITY ASSESSMENT (Art.43)
- 19. Integrate EU AI Act conformity assessment into WVTA technical dossier under Art.43(2)
- 20. Identify notified body if applicable (ALKS third-party assessment requirements)
- 21. Complete Declaration of Conformity referencing both Reg. 2019/2144 and EU AI Act
POST-MARKET MONITORING AND INCIDENTS
- 22. Establish Art.72 post-market monitoring plan with fleet telemetry collection
- 23. Define Art.65 serious incident criteria for vehicle AI (AEB false negative, ALKS ODD boundary failure)
- 24. Map dual reporting chain: type-approval authority (Reg. 2019/2144 defects) + NCA (EU AI Act Art.65)
CLOUD AND DATA SOVEREIGNTY
- 25. Audit cloud platform jurisdiction for OTA delivery, monitoring telemetry, and ALKS operational logs; assess migration to EU-sovereign PaaS if CLOUD Act exposure exists
Art.107 in the Art.104–112 Amendment Series
Art.107 covers the largest and most commercially significant vehicle sector in the EU AI Act's amendment series. Passenger cars and commercial vehicles represent the broadest deployment context for AI safety systems.
| Article | Sector Regulation Amended | Key AI Systems Affected |
|---|---|---|
| Art.104 | Framework — Annex I coordination | All sector AI systems |
| Art.105 | Reg. (EU) No 167/2013 | Agricultural/forestry vehicles (T/C/R/S categories) |
| Art.106 | Reg. (EU) No 168/2013 | Motorcycles, mopeds, quadricycles (L1e–L7e) |
| Art.107 | Reg. (EU) 2019/2144 | Passenger cars, trucks, buses (M1/M2/M3/N1/N2/N3) |
| Art.108 | Directive 2014/90/EU | Marine equipment |
| Art.109 | Reg. (EU) No 2018/858 | General motor vehicle framework |
| Art.110 | Directive 2010/35/EU | Transportable pressure equipment |
| Art.111 | Directive 2014/53/EU | Radio equipment (RED) |
| Art.112 | Reg. (EU) No 2019/1009 | Fertilising products |
See Also
- EU AI Act Art.108: Amendment to Directive 2014/90/EU — ECDIS, Autopilot, ARPA Radar and Maritime AI High-Risk Classification Under the Marine Equipment Directive
- EU AI Act Art.106: Amendment to Regulation (EU) No 168/2013 — Motorcycle and Two/Three-Wheel Vehicle AI Systems, ABS Emergency Braking High-Risk Classification
- EU AI Act Art.105: Amendment to Regulation (EU) No 167/2013 — Agricultural and Forestry Vehicle AI Systems, Autonomous Guidance High-Risk Classification
- EU AI Act Art.104: Amendments to EU Sector Legislation — Annex I Dual Compliance, Conformity Assessment Coordination
- EU AI Act Art.103: Transitional Provisions — Aug 2026 Full-Application Deadline and 98-Day Compliance Countdown
- EU AI Act Art.6: High-Risk AI Classification Rules — Annex I and Annex III Pathways Explained
- EU AI Act Art.43: Conformity Assessment Procedures for High-Risk AI Systems
- EU AI Act Art.72: Post-Market Monitoring Plan — Mandatory Obligations Developer Guide