Skip to content Skip to footer

AI & Autonomous Driving: SAE, XAI and Simulation at the Heart of Safety

ART-13 · Neo Coeur Intelligence · Published: July 2026 · Mobility vertical · Based on SAE J3016 · ISO 21448 (SOTIF) · ISO/PAS 8800

📋 TABLE OF CONTENTS -

00.Introduction
I.General Overview: Autonomous Driving and the Safety Equation
1.1The 6 SAE levels of driving automation
1.2Why AI safety is a new discipline (ISO/PAS 8800)
1.3The EU AI Act and high-risk ADAS
II.The Three Pillars of Autonomous Driving Safety
2.1Explainable AI (XAI) for critical decisions
2.2Simulation: CARLA, SUMO and the billion-mile problem
2.3Adversarial robustness: the NCI angle
III.A 3-Step Safety Assurance Method
IV.Conclusion
V.FAQ
VI.References

Introduction

At SAE Level 3, liability shifts from the driver to the machine. And no one has fully settled who pays when a Level 3 vehicle causes an accident. That single sentence captures why autonomous driving is not just an engineering challenge. It is a safety, legal and cybersecurity problem rolled into one, and it lands squarely on the desk of every OEM, Tier-1 supplier and mobility operator in Europe.

The promise is real. Around 94% of road accidents involve human error, so removing the human from the loop should, in theory, save lives. But an autonomous vehicle does not "see" the road. It runs a stack of statistical models that infer, from camera, lidar and radar inputs, what to brake for and what to ignore. When those models are wrong, opaque or manipulable, the safety gain evaporates. This guide sets out how sovereign, explainable and resilient AI actually secures autonomous driving in 2026, and how it connects to the broader discipline of AI risk assessment and adversarial AI.

We will cover the six SAE levels and where responsibility breaks, the regulatory stack that now governs in-vehicle AI (ISO/PAS 8800 and the EU AI Act included), the three technical pillars that make an autonomous stack defensible, and a practical method to prove safety before a regulator or an insurer asks you to.

⚡ WHERE WE STAND, 2026

Mercedes-Benz and Honda have both homologated SAE Level 3 systems for conditional automated driving in defined operational domains. That milestone matters because it is the first point where the vehicle, not the human, is legally the driver during activation. Every OEM chasing that certification now has to prove not only that the AI works, but that its decisions are explainable, auditable and robust against manipulation. This is the same evidence burden imposed by UN-R155, ISO/SAE 21434 and the new ISO/PAS 8800, extended to the machine-learning layer.

I. General Overview: Autonomous Driving and the Safety Equation

1. The 6 SAE Levels of Driving Automation

The SAE J3016 standard defines six levels of driving automation, from 0 to 5. The distinction that matters most for cybersecurity and liability is the jump from Level 2 to Level 3, because that is where the human stops being the fallback and the system becomes responsible for the driving task within its operational design domain.

FIGURE 01 · SAE J3016 · SIX LEVELS OF DRIVING AUTOMATIONSAE J3016
0
No Automation
The human does everything. Warnings and momentary assistance only.
1
Driver Assistance
One function automated (steering OR speed). Human monitors permanently.
2
Partial Automation
Steering AND speed automated. Human must supervise and take over instantly. Most "self-driving" features sold today stop here.
3
Conditional Automation · liability shift
The system drives within its domain. The human can disengage but must resume when requested. Mercedes and Honda are homologated here.
4
High Automation
No human fallback needed inside the operational domain (robotaxi zones, defined routes).
5
Full Automation
No steering wheel required. Any road, any condition. Not commercially available.
Source: SAE International J3016 · levels of driving automation for on-road motor vehicles

Below Level 3, an accident is the driver's problem. At Level 3 and above, it becomes the manufacturer's problem, and by extension a question about the integrity of the AI stack. This is the precise moment where cybersecurity stops being an IT concern and becomes a product safety obligation.

2. Why AI Safety Is a New Discipline (ISO/PAS 8800)

Classical automotive safety, governed by ISO 26262, assumes deterministic systems: a brake controller behaves the same way every time, and you can test it exhaustively. A perception model does not work like that. It is a probabilistic function trained on data, and it can fail on inputs no engineer anticipated. The industry created a dedicated standard for exactly this gap, ISO 21448 (SOTIF, Safety Of The Intended Functionality), to address hazards that arise even when nothing is technically broken.

In 2023 the industry went one step further with ISO/PAS 8800 (Road vehicles, Safety and artificial intelligence), now the reference standard for machine-learning systems in vehicles. Where ISO 26262 covers functional safety and ISO 21448 covers the intended-functionality gap, ISO/PAS 8800 addresses the AI itself: the safety lifecycle of an in-vehicle ML model, its data requirements, its performance and robustness targets, and the evidence needed to argue it is safe. For any OEM deploying AI-driven perception or decision-making, ISO/PAS 8800 is no longer optional reading. It is the framework a technical service will expect you to have applied. Together, these four texts form the regulatory stack for autonomous AI.

FIGURE 02 · THE REGULATORY STACK FOR IN-VEHICLE AISTANDARDS
26262
ISO 26262
Functional safety of deterministic electronic systems
21448
ISO 21448 (SOTIF)
Safety of the intended functionality, even when nothing is broken
8800
ISO/PAS 8800
Safety and AI: the ML model lifecycle, data and robustness targets
Plus UN-R155 (cyber management) and the EU AI Act (high-risk classification) · the full compliance stack for autonomous AI

Three properties separate a trustworthy autonomous stack from a dangerous one. It must be explainable, so a human or an auditor can understand why it braked or swerved. It must be validated at scale, because you cannot drive a billion physical miles to prove an edge case is handled. And it must be robust, because an adversary who can nudge a sensor input can flip a decision. These map directly to the three pillars in Part II.

3. The EU AI Act and High-Risk ADAS

The regulatory stack does not stop at automotive standards. The EU AI Act (Regulation 2024/1689) now sits on top of them, and it treats AI systems used as safety components of vehicles as high-risk. An ADAS or autonomous-driving perception system is not a peripheral feature in the eyes of the Act. It is precisely the kind of system the regulation was written to govern.

⚖ WHAT THE EU AI ACT MEANS FOR ADAS AND AUTONOMOUS SYSTEMS

AI systems that act as safety components of regulated products, which includes ADAS and automated-driving functions, fall under the high-risk regime of the AI Act (Article 6 and Annex III / Annex I product logic). That classification carries three consequences OEMs and suppliers must plan for:

  • Robustness and cybersecurity obligations (Article 15): high-risk AI must reach an appropriate level of accuracy, robustness and cybersecurity, and must be resilient to attempts to alter its use or behaviour through adversarial manipulation. This is a legal requirement, not a best practice.
  • Pre-market conformity: the system must demonstrate conformity before being placed on the market, with technical documentation, risk management and human-oversight measures in place. Retro-fitting compliance after launch is not an option.
  • Convergence with automotive law: the AI Act layers on top of UN-R155, ISO 21434 and ISO/PAS 8800 rather than replacing them. The same perception model has to satisfy all of them at once.

In practice, the Article 15 robustness requirement is where the AI Act and adversarial cybersecurity meet. Proving your ADAS model resists adversarial manipulation is now both an engineering task and a regulatory one.

II. The Three Pillars of Autonomous Driving Safety

FIGURE 03 · THE 3 PILLARS OF A DEFENSIBLE AUTONOMOUS STACKFRAMEWORK
🔍
Explainable AI (XAI)
Every safety-critical decision must be traceable and justifiable. Black-box perception is not certifiable.
🎮
Simulation
CARLA and SUMO reproduce millions of edge cases that would take a fleet years to encounter on real roads.
🛡
Adversarial Robustness
The distinctive NCI angle. Sensor fusion and adversarial testing keep the stack stable when inputs are manipulated.
Neo Coeur Intelligence framework · explainability, validation and robustness for autonomous systems

1. Explainable AI (XAI) for Critical Decisions

When a vehicle is the legal driver, "the model decided" is not an acceptable answer to a regulator or a court. Explainable AI turns an opaque perception decision into an auditable one. Techniques such as saliency mapping, SHAP values and counterfactual analysis let an engineer reconstruct why the system classified a shadow as a pedestrian, or failed to. This is not academic. It is the difference between a defensible incident report and a liability with no floor.

What XAI delivers in practice

  • Decision traceability for every safety-critical output, logged and reconstructable after the fact.
  • Bias and blind-spot detection, for example a perception model that underperforms in rain or on non-standard road markings.
  • Evidence for homologation. UN-R155, ISO 21448 and ISO/PAS 8800 all expect documented, justifiable behaviour, not just passing test rates.

🇪🇺EUROPEAN SOVEREIGNTY: WHY THE MODEL'S ORIGIN MATTERS

A European OEM that relies on an opaque foreign model cannot fully audit or defend it. When the perception stack is a black box controlled outside European jurisdiction, three things become impossible: proving to a regulator why a decision was made, guaranteeing that training data and model behaviour meet European standards, and keeping the incident-evidence chain under your own control when a court asks for it.

Sovereign, explainable AI is not a slogan. It is the difference between an OEM that owns its safety argument and one that has outsourced it to a supplier who cannot, or will not, open the box. For European manufacturers competing against non-European stacks, auditability is not a constraint. It is a differentiator, and increasingly a legal requirement under the AI Act.

2. Simulation: CARLA, SUMO and the Billion-Mile Problem

To statistically prove that an autonomous system is safer than a human, you would need to drive hundreds of millions of miles capturing rare events. No fleet can do that on public roads in a reasonable time or budget. Simulation solves it. Open frameworks such as CARLA (photorealistic sensor-level simulation) and SUMO (large-scale traffic flow modelling) let engineers generate and replay millions of edge cases on demand: a child stepping out between parked cars, a truck losing cargo, sensor glare at sunset, a cyclist running a red light.

⚠ THE EDGE-CASE PROBLEM

Most autonomous failures are not caused by common situations. They are caused by the long tail of rare ones the model never saw during training. Simulation is the only economically viable way to manufacture that long tail deliberately, test against it, and document coverage for the certification file. A scenario that never occurs in your test fleet still has to be handled, and simulation is how you prove it is.

Simulation also underpins continuous validation. Every time a model is retrained, the full scenario library can be replayed automatically to confirm no regression was introduced. This is the automotive equivalent of a test suite, scaled to physics and perception.

3. Adversarial Robustness: The NCI Angle

This is where Neo Coeur Intelligence draws the line that sets it apart. Explainability and simulation are necessary, but they assume the inputs to the model are honest. In the real world, they are not. An autonomous vehicle fuses camera, lidar and radar precisely so that if one sensor is degraded, the others compensate. That fusion is also an attack surface, and securing it is a cybersecurity discipline, not a QA task. The AI Act's Article 15 now makes it a legal one too.

Five attack vectors matter for in-vehicle AI, and each one maps to a documented technique from the wider field of AI security. Testing against all five, before type approval, is the core of a defensible robustness argument.

FIGURE 04 · FIVE ADVERSARIAL ATTACK VECTORS ON IN-VEHICLE AITHREAT MODEL
01 · FGSM / PGD
Adversarial Examples
Imperceptible perturbations on camera input, or physical stickers on a stop sign, flip the perception model's classification with high confidence. FGSM and PGD are the reference algorithms.
02 · SUPPLY CHAIN
Data Poisoning
Corrupted or backdoored samples injected during training make the model misbehave on a specific trigger, for example failing to recognise one class of obstacle. Dangerous in fleet-scale continuous learning.
03 · PRIVACY / IP
Model Inversion
Repeated queries against a deployed model reconstruct sensitive training data or extract the proprietary model itself, exposing both privacy and intellectual property.
04 · LLM INTERFACE
Prompt Injection
In-cabin voice assistants and LLM-based interfaces can be hijacked by malicious instructions that bypass guardrails or reach connected vehicle functions. A growing surface as cars add generative AI.
05 · SENSOR LAYER
Sensor Spoofing
Spoofed lidar returns create phantom obstacles or hide real ones; laser and GPS spoofing manipulate what the fusion layer believes about the world. The physical-world attack on perception.
Source: MITRE ATLAS · mapped to in-vehicle perception and interface layers by Neo Coeur Intelligence

The same red-teaming methodology used to test enterprise models, described in our guide to AI risk assessment, applies directly to ADAS perception stacks: FGSM and PGD attacks on the vision model, sensor-spoofing scenarios, and robustness bounds measured before, not after, a costly recall. For a deeper look at why current automotive regulation still under-specifies these AI-layer requirements, see our analysis of the regulatory gaps in automotive AI security.

✓ WHY ROBUSTNESS TESTING PAYS FOR ITSELF

A software-related automotive recall can cost up to 1.5 billion dollars. Testing the robustness of an ADAS perception stack against the five adversarial vectors above, before type approval, is a fraction of that. The economics are not subtle: prove resilience in simulation and red-teaming now, or discover the gap in the field later, after the recall and the AI Act enforcement action.

III. A 3-Step Safety Assurance Method

Making an autonomous stack defensible is a repeatable process, not a one-off audit. The three steps below turn the pillars above into deliverables a technical service or an insurer will accept.

1
STEP

Instrument the stack for explainability

Add saliency, SHAP and counterfactual logging to every safety-critical perception and decision output, so each action can be reconstructed and justified after the fact.

Without this layer, no incident can be properly investigated and no homologation dossier is complete. Explainability is the foundation everything else rests on, and the baseline ISO/PAS 8800 expects.

2
STEP

Validate at scale in simulation

Build a scenario library in CARLA and SUMO covering the operational design domain plus its long tail of edge cases, and replay it on every model release to prove no regression.

The output is a documented coverage report: which scenarios were tested, at what fidelity, and with what pass rate. This is the evidence that replaces the impossible billion physical miles.

3
STEP

Red-team the perception layer

Run the five adversarial and sensor-spoofing attack vectors against the fused perception stack, quantify robustness bounds, and feed the findings back into training and control logic.

The deliverable is a robustness assessment with measured attack success rates and minimum perturbation thresholds, ready to sit alongside the TARA and to answer the AI Act Article 15 requirement, in the certification file described in our UN-R155 and ISO/SAE 21434 guide.

FIGURE 05 · KEY FIGURES · AUTONOMOUS DRIVING SAFETY 2026MARKET DATA
94%
of road accidents involve human error
6
SAE automation levels, from 0 to 5
L3
first level where liability shifts to the machine (Mercedes, Honda homologated)
$1.5B
average cost of an automotive software-related recall
85%
of new vehicles will embed AI systems by 2030
0
current standards mandating adversarial testing of embedded AI models
Sources: SAE International J3016 · NHTSA crash causation data · Gartner Automotive AI Survey 2025 · manufacturer homologation announcements

IV. Conclusion

Autonomous driving will not be won by whichever OEM ships the flashiest demo. It will be won by whoever can prove, in front of a regulator and an insurer, that their AI is explainable, validated and robust. Those three properties are what turn a Level 3 liability from an open-ended risk into a managed one, and they are exactly what ISO/PAS 8800, UN-R155 and the EU AI Act now demand.

The European advantage here is real, provided it is used. Sovereign, explainable and resilient AI keeps the audit trail, the data and the decision logic inside European jurisdiction, which is precisely what the AI Act's Article 15 robustness regime and the automotive standards increasingly require. The manufacturers that treat safety assurance, and adversarial robustness in particular, as a continuous engineering discipline rather than a certification checkbox will reach the market faster and defend their position when an incident inevitably tests it.

The question is no longer whether autonomous vehicles are coming. It is whether your AI stack can survive the scrutiny that arrives with them.

Prove your autonomous stack before the road does

Neo Coeur Intelligence runs mobility proof-of-concepts that stress-test your perception and decision AI: explainability instrumentation, simulation coverage, and adversarial red-teaming aligned with ISO/PAS 8800, UN-R155 and the EU AI Act Article 15.

Find your safety gaps in simulation, not in the field.

📧 contact@neocoeurintelligence.com

→ Book a meeting Request a Mobility PoC

V. Frequently Asked Questions

What are the SAE levels of autonomous driving?

SAE J3016 defines six levels, from 0 (no automation) to 5 (full automation). Levels 0 to 2 keep the human responsible for driving. At Level 3, the system becomes the driver within its operational domain and the human only needs to resume on request. Levels 4 and 5 require no human fallback inside their domain. The critical threshold is Level 3, where legal responsibility shifts from the driver to the manufacturer.

What is ISO/PAS 8800?

ISO/PAS 8800 (2023) is the reference standard for machine learning and artificial intelligence in road vehicles. It complements ISO 26262 (functional safety) and ISO 21448 (SOTIF) by addressing the AI model itself: its safety lifecycle, data requirements, and robustness targets. For any OEM deploying AI-driven perception or decision-making, it is the framework a technical service now expects to see applied.

Are ADAS and autonomous driving systems high-risk under the EU AI Act?

Yes. AI systems acting as safety components of vehicles fall under the high-risk regime of the EU AI Act. This triggers Article 15 obligations on accuracy, robustness and cybersecurity, including resilience to adversarial manipulation, plus pre-market conformity assessment. The AI Act layers on top of UN-R155, ISO 21434 and ISO/PAS 8800 rather than replacing them.

Can autonomous vehicles be hacked through their sensors?

Yes. Adversarial attacks can manipulate perception through five main vectors: adversarial examples (FGSM/PGD), data poisoning, model inversion, prompt injection on in-cabin LLM interfaces, and sensor spoofing. Stickers on a stop sign can cause a vision model to misread it, and spoofed lidar returns can create phantom obstacles. This is why adversarial robustness testing belongs in the safety process, quantified before type approval.

Who is liable if a Level 3 autonomous vehicle causes an accident?

At SAE Level 3 and above, liability generally shifts from the driver to the manufacturer while the system is active, because the vehicle is legally the driver. The precise allocation is still being settled across jurisdictions, which is exactly why documented explainability, validation and robustness evidence matters: it is the manufacturer's defence.

VI. References

[1] SAE International. J3016 · Taxonomy and Definitions for Terms Related to Driving Automation Systems for On-Road Motor Vehicles. 2021.

[2] ISO. ISO 21448:2022 · Road vehicles · Safety of the intended functionality (SOTIF). Geneva: ISO, 2022.

[3] ISO. ISO 26262 · Road vehicles · Functional safety. Geneva: ISO, 2018.

[4] ISO. ISO/PAS 8800:2024 · Road vehicles · Safety and artificial intelligence. Geneva: ISO, 2024.

[5] UNECE WP.29. UN Regulation No. 155 · Cyber security and cyber security management system. Adopted March 2021.

[6] Regulation (EU) 2024/1689 of the European Parliament and of the Council laying down harmonised rules on artificial intelligence (Artificial Intelligence Act). OJ L, 12 July 2024.

[7] Dosovitskiy, A. et al. CARLA: An Open Urban Driving Simulator. CoRL 2017.

[8] Lopez, P.A. et al. Microscopic Traffic Simulation using SUMO. IEEE ITSC 2018.

[9] MITRE Corporation. MITRE ATLAS · Adversarial Threat Landscape for Artificial-Intelligence Systems.

[10] NHTSA. Critical Reasons for Crashes Investigated in the National Motor Vehicle Crash Causation Survey. National Highway Traffic Safety Administration.

Leave a comment