If you are building AI systems for motorcycles, mopeds, scooters, or quadricycles sold in the EU, Article 106 of the EU AI Act directly affects your compliance obligations. EU AI Act Art.106 amends Regulation (EU) No 168/2013 — the EU framework governing type approval and market surveillance of two- or three-wheel vehicles and quadricycles — to formally integrate EU AI Act requirements into the L-category vehicle sector.

The amendment creates an Annex I bridge: AI systems embedded in L-category vehicles that qualify as safety components under Reg. 168/2013 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 ABS controllers, CBS units, autonomous emergency braking systems, and rider assistance AI — all of which increasingly rely on machine learning rather than purely deterministic logic.

What Regulation (EU) No 168/2013 Covers

Regulation (EU) No 168/2013 establishes the EU type-approval and market surveillance framework for L-category vehicles. It defines the standards these vehicles must meet before they can be placed on the EU market and regulates their ongoing safety compliance.

The regulation covers the following vehicle categories:

Reg. 168/2013 covers type approval across five technical domains: environmental performance (emissions), functional safety, constructional safety, roadworthiness, and market surveillance. The AI Act Art.106 amendment inserts the EU AI Act compliance pathway into the constructional and functional safety domain.

What Art.106 Actually Changes

Article 106 is a targeted legislative amendment — like Art.105 for agricultural vehicles, it does not rewrite Reg. 168/2013 wholesale. Instead, it inserts references to the EU AI Act framework into specific provisions of Reg. 168/2013 that govern safety components.

The operative mechanism: AI systems embedded in L-category vehicles that are classified as safety components under Reg. 168/2013 now sit within EU AI Act Annex I — the list of harmonisation legislation that creates Art.6(1) high-risk AI classification. This means a motorcycle ABS controller that uses machine learning must satisfy both:

1. Reg. 168/2013 type-approval obligations — ECE R78 braking compliance, UN technical regulations, national market surveillance
2. EU AI Act Title III obligations — technical documentation (Annex IV), quality management system (Art.9), conformity assessment (Art.43), post-market monitoring (Art.72), incident reporting (Art.65)

The classification trigger is the functional safety designation within the type-approval dossier. If the component is designated as a safety component in the Reg. 168/2013 type-approval process, and it contains AI, it is high-risk under the EU AI Act.

Which Motorcycle AI Systems Become High-Risk

The high-risk classification applies when two conditions are met simultaneously: (a) the AI system is embedded in or constitutes a safety component under Reg. 168/2013, and (b) the component performs a function that directly affects rider or road-user safety.

Definitively High-Risk

ABS Controllers (Anti-Lock Braking System) ABS controllers for L3e and L4e vehicles are the clearest case. Modern ABS units use sensor fusion algorithms — processing wheel speed sensors, IMU data, and road surface estimation — to modulate brake pressure across multiple channels in milliseconds. When the core logic is implemented as a trained model rather than a lookup table, the controller is an AI system in the EU AI Act sense. ABS is a mandatory safety feature for new type-approved L3e motorcycles from 2016 onward, making it a per-se safety component under Reg. 168/2013.

CBS Controllers (Combined Braking System) CBS is mandatory for L3e-A1 class motorcycles (≤11 kW). CBS electronically couples front and rear brake circuits. AI-based CBS controllers that use adaptive algorithms to determine optimal brake force distribution at varying load conditions qualify as high-risk safety components.

Autonomous Emergency Braking (AEB) AI AEB systems for two-wheelers are an emerging category. These systems use forward-facing sensors (radar, lidar, camera) and AI classifiers to detect imminent collision threats and autonomously apply partial or full braking. For L5e tricycles and L7e quadricycles, AEB increasingly mirrors the car-equivalent systems regulated under ALKS frameworks. AI-based AEB for any L-category vehicle is high-risk.

Rider Monitoring Systems Rider monitoring AI that detects drowsiness, loss of attention, or impaired riding behaviour interacts with both safety function (triggering alerts or intervention) and natural person monitoring classifications under the EU AI Act. These systems are high-risk under Art.6(1) via the safety component pathway, with additional scrutiny from Art.6(2) for biometric monitoring of individuals.

Conditionally High-Risk

Traction Control Systems (TCS) AI-based traction control uses wheel slip detection, acceleration modelling, and sometimes reinforcement learning to prevent rear wheel spin. If the traction control system is listed as a safety component in the type-approval dossier, it is high-risk. Many manufacturer implementations are safety-designated; verify against the specific type-approval certificate.

Stability Control / Lean Angle Management Inertial Measurement Unit (IMU)-based stability AI — which adjusts braking force based on lean angle in corners — is a safety component when included in the type-approval dossier. High-performance L3e motorcycles increasingly use neural-network-assisted IMU fusion.

Adaptive Cruise Control (ACC) ACC for motorcycles (available on high-displacement L3e models from BMW, Honda, Kawasaki) uses radar and AI speed control. If the ACC system has the authority to apply braking without rider input, it is a safety component and high-risk.

Not High-Risk (Examples)

The Dual Conformity Assessment Pathway

Art.106 creates a dual compliance obligation that operates in parallel, not sequentially. You cannot complete EU AI Act conformity assessment and then type approval in sequence as though they are independent — the assessments share evidence.

Layer 1: Reg. 168/2013 Type Approval (ECE R78 Pathway)

ECE Regulation No. 78 (UN/ECE R78) is the core braking performance standard for L-category vehicles. It specifies stopping distance requirements, brake actuation timing, and performance in wet conditions. The Art.106 amendment does not change R78 performance requirements — but it requires the type-approval technical file to additionally address AI Act compliance for AI-based components.

The manufacturer or their technical service must:

• Include AI system description in the type-approval technical dossier
• Demonstrate that the AI component meets the Reg. 168/2013 essential requirements
• Provide evidence that the AI Act obligations are satisfied (or confirm they are addressed in a parallel AI Act conformity assessment)

The consolidated dossier approach is most efficient: one technical documentation set that satisfies Annex IV of the EU AI Act and the Reg. 168/2013 type-approval dossier requirements simultaneously. Both frameworks require similar core evidence: functional description, safety requirements, test results, software documentation, quality management references.

Layer 2: EU AI Act Conformity Assessment (Art.43)

For high-risk AI in vehicles where the sector regulation (Reg. 168/2013) involves a notified body in its conformity assessment, Art.43 of the EU AI Act provides that the AI Act conformity assessment can be integrated into the sector regulation's notified body procedure.

Practical implications:

• If the Reg. 168/2013 type approval requires notified body involvement (Type Approval Authority or Technical Service), that same body can assess AI Act compliance
• Self-assessment under Art.43(2) may be available for certain ABS/CBS controller AI systems if the type approval does not mandate third-party assessment
• The CE marking that satisfies Reg. 168/2013 constructional safety requirements also covers the EU AI Act declaration of conformity when assessment is integrated

Critical for OEM-supplier relationships: Many L-category vehicle OEMs source ABS/CBS controllers from Tier 1 suppliers (Bosch, Continental, Brembo). Under the EU AI Act, the AI system provider (typically the Tier 1 supplier building the AI controller) bears the primary Art.9–16 compliance obligations. The OEM, as deployer, bears the Art.25–29 obligations. This creates a new contractual interface requirement: supplier agreements must address AI Act compliance documentation sharing, post-market monitoring data access, and incident notification chains.

ECE R78 and EU AI Act: The Braking Compliance Interface

UNECE Regulation 78 specifies objective braking performance: stopping distances from defined speeds on defined surfaces. A motorcycle ABS controller can comply with R78 by meeting performance thresholds regardless of the internal algorithm. The EU AI Act introduces a layer that R78 does not address: how the AI system was designed, validated, and monitored.

The R78 Compliance Gap for AI Systems

R78 requires demonstrable performance outcomes. EU AI Act Art.9 requires a systematic risk management process covering the full AI lifecycle. For AI-based ABS controllers:

The gap between R78 physical performance verification and EU AI Act AI lifecycle documentation is where most compliance effort concentrates. R78 test results are necessary but no longer sufficient for AI-based ABS controllers.

IMU-Based Lean Angle Braking: Specific Considerations

Motorcycles brake under lean angles that vary from 0° (upright) to 45°+ in aggressive cornering. Traditional ABS algorithms used lookup tables calibrated for specific lean ranges. Neural-network-based IMU fusion — which estimates lean angle from accelerometer and gyroscope data and feeds it into braking force distribution — presents specific EU AI Act documentation requirements:

• Training data description: What lean angles, road surfaces, speed ranges, and rider weights are represented in the training data?
• Out-of-distribution detection: Does the system detect and handle scenarios outside the training distribution (e.g., gravel, ice, extreme lean angles)?
• Bias analysis: Is braking performance uniform across rider weights (a 50 kg rider vs. a 120 kg rider + luggage)?

These are not requirements under R78. They are Art.9 and Annex IV requirements under the EU AI Act.

Connected Motorcycles and the CLOUD Act Problem

Modern L3e motorcycles are increasingly connected: BMW's ConnectedRide, Honda's Honda Road Sync, Kawasaki RIDEOLOGY all transmit telemetry to manufacturer cloud platforms. For EU-market motorcycles with AI systems, this creates a data sovereignty dimension.

What data is transmitted:

• GPS tracks and route data
• Rider biometric proxies (heart rate via paired wearables, braking force patterns, lean angle history)
• ABS activation events and severity
• Diagnostic data including AI controller inputs/outputs (increasingly included for OTA diagnostics)
• OTA software update delivery (including AI model updates)

The CLOUD Act exposure: If the motorcycle OEM or cloud platform provider is US-headquartered or US-controlled (BMW AG — not US, but Honda Motor Co. — Japan, Kawasaki Heavy Industries — Japan; however, their cloud platform providers may be US entities like AWS or Azure), CLOUD Act warrants can compel disclosure of EU rider telemetry data to US law enforcement without EU judicial process.

For AI-specific data: Post-market monitoring data (Art.72 EU AI Act) requires collection of field performance data. If this data is stored on a US-controlled cloud platform, it is CLOUD Act-accessible. For EU riders, this creates a GDPR Art.44–49 transfer obligation and a potential conflict between EU AI Act post-market monitoring obligations and CLOUD Act access rights.

The EU-sovereign path: Operating the OTA platform and post-market monitoring data store on EU-sovereign infrastructure — where the infrastructure provider is EU-headquartered and not subject to US jurisdiction — eliminates CLOUD Act exposure for motorcycle AI monitoring data. For teams building connected motorcycle platforms or OTA management systems, this is an increasingly regulatory-relevant design decision, not just a commercial preference.

Provider and Deployer Obligations Under Art.106

Who is the provider?

The provider is the entity that develops the high-risk AI system and places it on the market. For motorcycle AI:

• Tier 1 supplier building the ABS controller (e.g., Bosch Mobility supplying an ABS unit with ML-based brake pressure control): Provider
• OEM that develops AI in-house (e.g., BMW Motorrad's own IMU stability system): Provider
• Software vendor supplying AI models to an ABS controller manufacturer: Provider (for the AI component)

Who is the deployer?

• Motorcycle OEM integrating a Tier 1 AI ABS controller: Deployer
• Motorcycle rental or fleet operator using L3e motorcycles with AI systems: Deployer
• Road transport company operating L5e tricycles with AI route guidance: Deployer

Provider obligations (Arts.8–16):

• Quality management system (Art.9)
• Training, validation, testing data governance (Art.10)
• Technical documentation (Art.11, Annex IV)
• Record keeping and logging (Art.12)
• Transparency to deployers (Art.13)
• Human oversight measures (Art.14)
• Accuracy, robustness, cybersecurity (Art.15)
• Registration in EU database (Art.16, Art.71)

Deployer obligations (Art.25–29):

• Use AI only as intended and per provider instructions (Art.25)
• Technical and organisational measures for the intended purpose (Art.26)
• Human oversight implementation (Art.26(1)(d))
• Serious incident monitoring and reporting to provider (Art.27)
• DPIA compliance for Regulation (EU) 2016/679 interactions (Art.27(5))

Motorcycle-specific deployer scenarios:

Python Tooling: TwoWheelerAIComplianceTracker

The following implementation provides a structured framework for tracking EU AI Act Art.106 compliance across L-category vehicle AI systems:

from dataclasses import dataclass, field
from enum import Enum
from typing import Optional
import json
from datetime import date


class VehicleCategory(str, Enum):
    L1E = "L1e"      # Two-wheel moped
    L2E = "L2e"      # Three-wheel moped
    L3E = "L3e"      # Two-wheel motorcycle
    L3E_A1 = "L3e-A1"  # Low-power motorcycle (CBS mandatory)
    L4E = "L4e"      # Motorcycle with sidecar
    L5E = "L5e"      # Motor tricycle
    L6E = "L6e"      # Light quadricycle
    L7E = "L7e"      # Heavy quadricycle


class AISystemType(str, Enum):
    ABS_CONTROLLER = "ABS Controller"
    CBS_CONTROLLER = "CBS Controller"
    EMERGENCY_BRAKING = "Autonomous Emergency Braking"
    TRACTION_CONTROL = "Traction Control System"
    STABILITY_CONTROL = "Lean-Angle Stability Control"
    ADAPTIVE_CRUISE = "Adaptive Cruise Control"
    RIDER_MONITORING = "Rider Monitoring System"
    OTHER_SAFETY = "Other Safety Component AI"
    NON_SAFETY = "Non-Safety AI"


class HighRiskClassification(str, Enum):
    DEFINITIVELY_HIGH_RISK = "Definitively High-Risk"
    CONDITIONALLY_HIGH_RISK = "Conditionally High-Risk"
    NOT_HIGH_RISK = "Not High-Risk"
    REQUIRES_ANALYSIS = "Requires Case-by-Case Analysis"


@dataclass
class MotorcycleAISystem:
    system_name: str
    system_type: AISystemType
    vehicle_category: VehicleCategory
    is_safety_component_in_type_approval: bool
    uses_ml_or_neural_network: bool
    has_autonomous_actuation: bool  # Can act without rider input
    cloud_platform_jurisdiction: str  # "EU", "US", "JP", etc.
    tier1_supplier: Optional[str] = None
    ece_r78_compliant: bool = False
    art9_qms_documented: bool = False
    annex_iv_technical_doc: bool = False
    art72_monitoring_plan: bool = False
    training_data_documented: bool = False
    ood_detection_implemented: bool = False

    def classify_high_risk(self) -> HighRiskClassification:
        if self.system_type == AISystemType.NON_SAFETY:
            return HighRiskClassification.NOT_HIGH_RISK

        if self.system_type in [
            AISystemType.ABS_CONTROLLER,
            AISystemType.CBS_CONTROLLER,
            AISystemType.EMERGENCY_BRAKING,
            AISystemType.RIDER_MONITORING,
        ] and self.uses_ml_or_neural_network:
            return HighRiskClassification.DEFINITIVELY_HIGH_RISK

        if self.is_safety_component_in_type_approval and self.uses_ml_or_neural_network:
            return HighRiskClassification.CONDITIONALLY_HIGH_RISK

        if self.uses_ml_or_neural_network and self.has_autonomous_actuation:
            return HighRiskClassification.REQUIRES_ANALYSIS

        return HighRiskClassification.NOT_HIGH_RISK

    def cloud_act_risk(self) -> str:
        if self.cloud_platform_jurisdiction == "US":
            return "HIGH — US-hosted platform exposes rider telemetry to CLOUD Act"
        elif self.cloud_platform_jurisdiction == "EU":
            return "LOW — EU-sovereign platform, CLOUD Act does not apply"
        else:
            return f"MEDIUM — {self.cloud_platform_jurisdiction} jurisdiction, assess bilateral agreements"

    def compliance_gaps(self) -> list[str]:
        gaps = []
        classification = self.classify_high_risk()

        if classification in [
            HighRiskClassification.DEFINITIVELY_HIGH_RISK,
            HighRiskClassification.CONDITIONALLY_HIGH_RISK,
        ]:
            if not self.ece_r78_compliant and self.system_type in [
                AISystemType.ABS_CONTROLLER,
                AISystemType.CBS_CONTROLLER,
                AISystemType.EMERGENCY_BRAKING,
            ]:
                gaps.append("ECE R78 compliance not confirmed")
            if not self.art9_qms_documented:
                gaps.append("Art.9 QMS not documented for AI lifecycle")
            if not self.annex_iv_technical_doc:
                gaps.append("Annex IV technical documentation incomplete")
            if not self.art72_monitoring_plan:
                gaps.append("Art.72 post-market monitoring plan missing")
            if not self.training_data_documented:
                gaps.append("Training data description (Art.10) not documented")
            if not self.ood_detection_implemented:
                gaps.append("Out-of-distribution detection not implemented")
            if self.cloud_platform_jurisdiction == "US":
                gaps.append("CLOUD Act exposure: migrate OTA/monitoring to EU-sovereign platform")
        return gaps

    def report(self) -> dict:
        return {
            "system": self.system_name,
            "vehicle_category": self.vehicle_category.value,
            "ai_system_type": self.system_type.value,
            "high_risk_classification": self.classify_high_risk().value,
            "cloud_act_risk": self.cloud_act_risk(),
            "compliance_gaps": self.compliance_gaps(),
            "gaps_count": len(self.compliance_gaps()),
            "tier1_supplier": self.tier1_supplier,
        }


# Example: motorcycle ABS controller with ML-based pressure control
abs_controller = MotorcycleAISystem(
    system_name="NeuralABS v2 — L3e ABS Controller",
    system_type=AISystemType.ABS_CONTROLLER,
    vehicle_category=VehicleCategory.L3E,
    is_safety_component_in_type_approval=True,
    uses_ml_or_neural_network=True,
    has_autonomous_actuation=True,
    cloud_platform_jurisdiction="US",  # OTA diagnostics via AWS
    tier1_supplier="Bosch Mobility",
    ece_r78_compliant=True,
    art9_qms_documented=False,  # Gap
    annex_iv_technical_doc=False,  # Gap
    art72_monitoring_plan=False,  # Gap
    training_data_documented=False,  # Gap
    ood_detection_implemented=False,  # Gap
)

rider_monitor = MotorcycleAISystem(
    system_name="RideSafe Attention Monitor",
    system_type=AISystemType.RIDER_MONITORING,
    vehicle_category=VehicleCategory.L3E,
    is_safety_component_in_type_approval=True,
    uses_ml_or_neural_network=True,
    has_autonomous_actuation=False,
    cloud_platform_jurisdiction="EU",
    ece_r78_compliant=False,  # Not applicable for monitoring
    art9_qms_documented=True,
    annex_iv_technical_doc=True,
    art72_monitoring_plan=True,
    training_data_documented=True,
    ood_detection_implemented=True,
)

systems = [abs_controller, rider_monitor]
for sys in systems:
    print(json.dumps(sys.report(), indent=2))

25-Item Art.106 Compliance Checklist

SCOPE AND CLASSIFICATION

• 1. Identify all AI components in the L-category vehicle design
• 2. Cross-reference each AI component with the Reg. 168/2013 type-approval safety component designation
• 3. Apply the Art.6(1)/Annex I high-risk test: is the AI system a safety component in the type-approval dossier?
• 4. Document the high-risk classification decision with legal basis reference
• 5. Confirm the Art.106 amendment applies to the vehicle category (L1e–L7e)

DUAL CONFORMITY ASSESSMENT PREPARATION

• 6. Identify the applicable ECE regulation for each safety AI (R78 for braking, R130 for lane departure if applicable)
• 7. Confirm whether Reg. 168/2013 type approval requires notified body involvement for the AI component
• 8. Map the AI Act Art.43 conformity assessment procedure to the sector regulation assessment procedure
• 9. Design the consolidated technical dossier structure satisfying both Reg. 168/2013 and Annex IV requirements
• 10. Assign compliance ownership: identify providers (Tier 1 AI suppliers) and deployers (OEMs, fleet operators)

TECHNICAL DOCUMENTATION (Annex IV)

• 11. Document AI system description, intended purpose, and scope of deployment
• 12. Describe training data sources, geographic coverage, and rider demographic representation
• 13. Define accuracy, robustness, and performance metrics for the AI system
• 14. Document validation and test methodology including R78 physical test integration
• 15. Describe IMU/sensor data processing pipeline and lean-angle estimation methodology (if applicable)

QUALITY MANAGEMENT SYSTEM (Art.9)

• 16. Implement AI-specific QMS procedures covering data governance, training, validation, and post-deployment
• 17. Define risk management procedures identifying motorcycle-specific failure modes (wet roads, gravel, extreme lean angles)
• 18. Establish change management criteria triggering re-assessment (model updates, new vehicle configurations)
• 19. Document human oversight mechanisms and rider override capabilities

POST-MARKET MONITORING AND INCIDENT REPORTING

• 20. Establish Art.72 post-market monitoring plan with field data collection from connected vehicle telemetry
• 21. Define Art.65 serious incident criteria for motorcycle AI (ABS failure mode, emergency braking false activation)
• 22. Set up incident reporting chain between OEM deployer and Tier 1 supplier provider

CONNECTED MOTORCYCLE DATA SOVEREIGNTY

• 23. Audit cloud platform provider jurisdiction for OTA delivery and post-market monitoring data storage
• 24. If US-jurisdictioned platform: evaluate CLOUD Act exposure for rider telemetry and AI diagnostic data
• 25. Assess migration to EU-sovereign PaaS for OTA and monitoring data to eliminate CLOUD Act exposure

Art.106 in the Art.104–112 Amendment Series

Art.106 is the fourth in a sequence of sector-specific amendments in the EU AI Act's final chapter. Understanding the full sequence matters for any organisation operating across multiple vehicle or machinery categories:

Organisations operating across both the agricultural (Art.105) and two-wheel vehicle (Art.106) sectors should note the structural similarity: in both cases, the Annex I bridge creates dual compliance obligations triggered by the safety component designation in the sector type-approval process.

See Also

• EU AI Act Art.107: Amendment to Regulation (EU) 2019/2144 — ALKS, AEB, ISA, Driver Monitoring High-Risk AI for Passenger Cars, Trucks and Buses
• 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