Driver assistance (ADAS) is now standard in new European cars, while driverless (Level 4) services are expanding city by city, mainly in the US and China and in first European pilots. The same AI stack, sensor fusion, learned perception, prediction and planning, serves both. For most companies the realistic role is integrating certified components, validating them, or operating shuttles and fleets, not building a driving stack from scratch.
Problem & value
- Today: human error is a leading factor in road collisions; professional driving faces driver shortages; urban shuttles and logistics hubs struggle with staffing and night operation.
- AI value: consistent attention (lane keeping, emergency braking, adaptive cruise), potential for driverless operation in constrained domains (motorway, depot, geofenced urban area), and lower operating cost per kilometre once safety drivers are removed.
- Benefits: the EU General Safety Regulation (2019/2144) makes emergency braking, lane-keeping assistance and driver-drowsiness warning mandatory in new vehicle types, based on the Commission's estimate that these systems can save lives; concrete safety benefit per system should be taken from type-approval and insurer studies, not vendor claims [1].
Variants
- Level 2 / 2+ ADAS (driver supervises): lane centring, adaptive cruise, hands-off highway assist, parking assist. Regulated in the EU by UN R171 (DCAS) [2].
- Level 3 (conditional automation): system drives, driver must take over on request; UN R157 ALKS, in Germany additionally the Autonomous Driving Act (StVG, in force since 2021) [2][3].
- Level 4 robotaxis and shuttles: geofenced driverless service; in Germany the StVG Level-4 framework with technical supervision ("Technische Aufsicht") and operating-area approval by KBA and state authorities; EU Regulation 2022/1426 covers type-approval of fully automated vehicles in limited small series [3][4].
- Autonomous trucking and yard/hub logistics: motorway hub-to-hub and closed-site operation; see ROBO-022 for mines and closed sites.
- Out of scope here: driver and in-cabin monitoring (VIS-028), trains (ROBO-019), sidewalk robots (ROBO-020).
How it works
- sensors (camera, radar, lidar, GNSS/IMU)
- perception (detection, segmentation, lanes, free space, tracking, occupancy)
- localisation & map (HD map or map-light)
- prediction (intent and trajectories of other road users)
- planning (behaviour + motion, learned or rule-based, with safety envelope)
- control (steering, braking, acceleration)
- safety monitor / fallback (minimal-risk manoeuvre, driver takeover or remote assistance)
- fleet data loop (logging
- triage
- labelling
- retraining
- simulation
- release)
- Architectures: classic modular stacks (separate perception, prediction, planning) versus end-to-end learned driving models that map sensor input to trajectories; most production systems in 2026 are hybrids with a learned core and a rule-based safety layer.
- Perception: multi-camera bird's-eye-view transformers, radar/lidar fusion, occupancy networks.
- Human-in-the-loop: the driver at Level 2/3, a technical supervisor or remote operator at Level 4, and engineers approving every software release through the safety case.
Data preparation
Data here means recorded fleet drives (camera, radar, lidar, CAN bus), HD maps and simulated scenarios. It typically lives on vehicle loggers, in object storage and on engineering file shares, rarely in the ERP or DMS. Typical gaps are missing time synchronisation between sensors, unlabelled drives, duplicated or near-identical clips, poor coverage of rare situations (night, rain, cyclists) and personal data in the footage (faces, number plates).
Preparation steps: inventory the sources and their formats (see PREP-001 and GUIDE-003), get data out of loggers and legacy systems (PREP-005), define a category scheme before labelling (PREP-019), build a scenario-based test and evaluation set with domain experts (PREP-018), and anonymise faces and plates before wider use (PREP-022). Tools: ROS 2 bag tooling, auto-labelling with foundation models plus human review, scenario catalogues in ASAM OpenSCENARIO. Data preparation, labelling and scenario curation typically take well over half of the total effort; for buyers of certified components it shrinks to ODD documentation and validation data.
Implementation paths
Which path for whom
- Enterprise (OEMs, Tier 1s, fleet operators): Path B, because the driving stack is strategic and the real work is the cloud data loop (storage, labelling, training, simulation) around certified in-vehicle components.
- Developer: Path C, because Autoware, CARLA and open datasets allow own research and integration work without vendor lock-in.
- Public (transport authorities, municipal shuttle operators): Path A, because type-approved shuttles and operator services with a clear safety case and support are the only procurable option.
Path A: Buy (off-the-shelf)
- ADAS and automated-driving stacks for OEMs and Tier 1s: Mobileye (EyeQ chips, SuperVision, Chauffeur, Drive), NVIDIA DRIVE (Hyperion platform, DriveOS, certified safety OS), Qualcomm Snapdragon Ride, Bosch and ZF (EU), Continental and Aumovio (EU), Valeo (EU), Wayve (UK, embodied-AI driving software), Momenta, Applied Intuition (tools and vehicle OS).
- Driverless services and shuttles: Waymo, Baidu Apollo Go, Pony.ai, WeRide (Level 4 operators); in Europe MOIA/VW (ID. Buzz AD), Holon, Karsan, Oxa, Verne and EasyMile/Navya-lineage shuttles; operators such as KIRA (DB, Germany) run pilots.
- Choose A when: you are a fleet, municipality or transport operator, or an OEM integrating certified compute and software. Check type-approval status, ODD (operational design domain), safety case and update support.
Path B: Build on cloud APIs
- Cloud is used for the data loop, not for driving: object storage and labelling, training on managed GPU clusters, and large-scale simulation (NVIDIA Omniverse/Cosmos, AWS, Azure, EU clouds such as STACKIT, OVHcloud). Vision-language models help auto-label, search fleet data ("find rain at night with cyclists") and generate scenarios.
- Real-time driving decisions never depend on a cloud API; connectivity is only used for teleoperation, maps and OTA.
Path C: Self-host (open source)
- Stacks: Autoware (open-source, ROS 2, used in shuttles and research), Apollo (Baidu), openpilot (comma.ai, Level 2 for supported vehicles, research and hobby use, check legal status per country).
- Models and data: BEVFormer/UniAD-style research models, open datasets (nuScenes, Waymo Open Dataset, Argoverse 2, KITTI) mostly under non-commercial licences; check terms before commercial use.
- Simulation: CARLA, ASAM OpenSCENARIO/OpenDRIVE for scenarios.
- Hardware: HW4 for training and simulation; in-vehicle compute is automotive-grade SoCs (NVIDIA Orin/Thor class), outside the HW tiers.
Path D: Custom training
Only for OEMs, Tier 1s and well-funded start-ups. Needs fleet-scale driving data across weather, countries and edge cases, an auto-labelling pipeline, large GPU clusters and a functional-safety organisation (ISO 26262, SOTIF ISO 21448). Typical SMB involvement is limited to niche domains such as private-site shuttles, yard trucks or specialised perception modules.
State of the art (2026)
- End-to-end and foundation-model driving: transformer-based models trained on large fleet data, with vision-language-action ideas from ROBO-004 entering driving research, reasoning about scenes and giving explanations.
- Scaled driverless services: Waymo and Chinese operators run commercial Level 4 robotaxi services in multiple cities; European operations remain pilots and small deployments, with the UK and Germany the most active markets. Check operator pages for current city lists.
- Level 2 hands-off systems are widely sold; supervised "full self-driving" style products are moving through UN R171 approval in Europe, which restricts what a Level 2 system may do.
- Simulation and synthetic data: generative world models and neural reconstruction enable closed-loop testing of rare scenarios (ROBO-010).
- Limits: long-tail events (unusual objects, construction zones, adverse weather, sensor degradation), unreliable behaviour outside the ODD, difficulty proving safety statistically, driver over-trust in Level 2, and the sheer cost of validation.
Shared resources & combinations
- Shared stack: object detection, tracking, 3D vision and edge inference are shared with ROBO-016 (machine safety), ROBO-019 (rail), ROBO-020 (sidewalk robots), ROBO-022 (haulage) and ROBO-015.
- Simulation and digital twins: ROBO-010; policy foundations: ROBO-004.
- Adjacent: VIS-028 (driver monitoring, mandatory in new EU vehicles), PRED-030 (telematics scoring), OPT-001 (routing for robotaxi and shuttle fleets).
Effort, cost & KPIs
- Path A: months for pilots of shuttles or vehicle integration; main costs are vehicles, safety operators, insurance and approvals.
- Path C: a research prototype in months; production-grade release requires years and a safety organisation.
- Path D: multi-year programme with hundreds of engineers at OEM level.
- KPIs: disengagements or interventions per 1,000 km, collision and near-miss rate against a human baseline, ODD coverage, mean distance between safety-relevant events, uptime, scenario-coverage in simulation, remote-assistance requests per hour.
People & change
Management decides on the role (integrate, validate or operate) and funds the safety organisation. The department lead and end users (test drivers, safety drivers, remote operators) join from the start, because takeover concepts and driver-monitoring rules depend on them. IT security and legal/compliance are needed early for type approval, product liability and OTA updates; the DPO for camera footage and driver monitoring (GUIDE-005), where a DPIA is likely.
Works council: depends. Driver monitoring, fleet telemetry and in-cabin cameras are technically suited to monitor behaviour, so §87(1) no. 6 BetrVG applies in practice wherever employees drive or supervise; §90(1) no. 3 requires timely information about AI-planned work processes. Public operators involve the Personalrat. See GUIDE-004.
AI literacy: support the development of staff competence with training for operators and safety drivers (GUIDE-006). Typical concerns are job loss and liability after accidents; address them with a clear role description, transparent incident handling and a start with a small pilot group on one route or ODD (GUIDE-008). Humans stay in control through safety drivers, teleoperation and defined minimal-risk manoeuvres.
Risks, regulation & compliance
- EU AI Act: AI safety components in vehicles are handled through type-approval legislation (Annex I section B); the AI Act's high-risk requirements are not applied directly but must be taken into account when delegated acts under the vehicle regulations are adopted (Art. 2(2), Art. 102 ff.) [5]. Applications outside type-approval, such as private-site vehicles, may be machinery or high-risk safety components. Art. 5: biometric inference of emotions from drivers' faces is prohibited in the workplace context (fleet drivers); driver monitoring must stay limited to drowsiness and distraction.
- Vehicle law: UN R157 (ALKS), UN R171 (DCAS), EU 2022/1426 (ADS), General Safety Regulation 2019/2144, UN R155 (cybersecurity) and R156 (software updates); Germany StVG Level 4 and the AFGBV ordinance [2][3][4].
- GDPR: camera and sensor data capture faces, number plates and locations of bystanders; fleet and driver data is personal data. Needs a legal basis, data minimisation, on-device anonymisation (blur) before upload, retention limits and DPIA; the EDPB guidelines 01/2020 on connected vehicles apply [6].
- Liability: Product Liability Directive (EU) 2024/2853 covers software; Level 3/4 shifts liability toward keeper and manufacturer.
- Mitigations: defined ODD, ISO 26262/SOTIF/UL 4600 safety case, redundancy, driver-monitoring, staged rollouts, incident reporting, cybersecurity management system.
Getting started
- Define the use case and ODD: assist or driverless, public road or private site, speed, weather.
- Check the legal route: type-approval, StVG operating-area approval or machinery rules for closed sites.
- For shuttles: run a pilot with an established operator before any build decision.
- For developers: run Autoware or CARLA with an open dataset to learn the stack and scenario tooling.
- Set up a GDPR-compliant data loop (on-device anonymisation, retention, DPIA) before collecting data.
Sources
- Regulation (EU) 2019/2144 General Safety Regulation: https://eur-lex.europa.eu/eli/reg/2019/2144/oj
- UNECE, vehicle regulations (UN R157 ALKS, UN R171 DCAS, R155, R156): https://unece.org/transport/vehicle-regulations
- German Autonomous Driving Act (StVG, Level 4 framework), Federal Motor Transport Authority (KBA): https://www.kba.de/EN/Home/home_node.html
- Implementing Regulation (EU) 2022/1426 on ADS type-approval: https://eur-lex.europa.eu/eli/reg_impl/2022/1426/oj
- Regulation (EU) 2024/1689 (AI Act): https://eur-lex.europa.eu/eli/reg/2024/1689/oj
- EDPB Guidelines 01/2020 on connected vehicles: https://www.edpb.europa.eu/our-work-tools/our-documents/guidelines/guidelines-012020-processing-personal-data-context_en
- Autoware Foundation: https://autoware.org
- NVIDIA DRIVE: https://developer.nvidia.com/drive
- Mobileye: https://www.mobileye.com
- Waymo Open Dataset: https://waymo.com/open/