Leaders Insights
Leaders Insights

Rester au meilleur niveau, un peu chaque jour.

DomainesMarketingDataFinanceIA
RessourcesApprendreTestOutilsBlogGlossaire
© 2026 Leaders Insights — Tous droits réservés.
Formations/AI in automotive/Governance, risks and checks/Building a model risk framework for safety-critical AI
2/4+150 XP

Governance, risks and checks

10The regulatory map every automotive AI leader must navigate+15011Building a model risk framework for safety-critical AI+15012
The AI risks that bite automakers hardest
+150
13Guardrails and pre-deployment checks before you ship AI+150

Building a model risk framework for safety-critical AI

# Building a model risk framework for safety-critical AI

In 2018, an Uber test vehicle in Tempe, Arizona struck and killed a pedestrian. The perception system detected her 5.6 seconds before impact but kept reclassifying her: vehicle, then unknown, then bicycle. The software was not designed to expect a person crossing outside a crosswalk. That is a model risk failure, and no financial provision covers it.

Banks have spent 25 years building discipline around models that misprice risk. Automotive AI needs the same discipline, but the loss function is a human life, not a bad loan. This lesson adapts banking-grade model risk management (MRM) to perception, prediction, and planning models in vehicles.

What "model risk" means here

Model risk is the risk of loss (financial, reputational, or physical harm) from a model that is wrong or misused. The concept comes from the US Federal Reserve and OCC (Office of the Comptroller of the Currency) guidance SR 11-7, the foundational text on model risk management. Read the original: it is short and surprisingly readable (SR 11-7 guidance).

SR 11-7 says two things that transfer perfectly to cars:

1. A model is any quantitative method that turns input data into a decision. A pedestrian classifier qualifies.

2. Model risk comes from two sources: the model can be fundamentally wrong, and the model can be used incorrectly. Both apply to a lane-keeping system used on a road type it was never validated for.

The difference: a mispriced swap costs money. A missed pedestrian costs a life. So we keep the framework and raise the bar.

The regulatory backdrop for 2026

You are building this framework inside real law.

  • UN Regulation No. 157 (ALKS, Automated Lane Keeping Systems) and UN Regulation No. 171 (DCAS, Driver Control Assistance Systems) set binding requirements in Europe and most UNECE member states.
  • ISO 26262 covers functional safety (failures from faults). ISO 21448 (SOTIF, Safety Of The Intended Functionality) covers the harder problem: the system has no fault but still fails because the world surprised it. Perception AI lives mostly in SOTIF territory.
  • ISO/PAS 8800 (published 2024) is the first standard specifically for AI safety in road vehicles. This is your anchor document.
  • The EU AI Act classifies AI safety components of vehicles as high-risk, but largely defers to existing automotive type-approval law rather than duplicating it.
  • In the US, NHTSA (National Highway Traffic Safety Administration) governs through the Federal Motor Vehicle Safety Standards and its Standing General Order requiring crash reporting for automated systems.

Name these bodies correctly when you talk to a regulator. Vague references signal you have not read the standards.

Step 1: tier your models by safety impact

Banks tier models by materiality. You tier by harm potential. Build a simple tiering matrix combining severity (how bad if it fails) and controllability (can the driver or system recover).

| Tier | Description | Example |

|------|-------------|---------|

| Tier 1 | Failure can directly cause death, no human fallback in time | Pedestrian detection in an L3/L4 system at speed |

| Tier 2 | Failure contributes to harm, driver can intervene | Lane-departure warning, adaptive cruise |

| Tier 3 | Comfort or convenience, no safety path | Cabin gesture recognition, parking assist chime |

The tier sets the governance intensity. Tier 1 gets independent validation, extensive edge-case testing, and a formal sign-off. Tier 3 gets a lightweight review. Do not spend Tier 1 effort on Tier 3 models, or your safety team will drown and the real risks get missed.

Step 2: define the operational design domain

The ODD (Operational Design Domain) is the specific conditions under which the model is validated to work: road types, weather, lighting, speed range, geography. This is your single most important control.

Most "AI failures" are actually ODD violations: a model used outside its validated envelope. The Tempe case involved a system operating at night against a scenario it was not built to handle.

Write the ODD as a contract. Example for a highway pilot:

  • Divided highways only, no cross traffic
  • Daylight and dry or light rain
  • 30 to 130 km/h
  • Clear lane markings present

Then enforce it in code. The vehicle must detect when it is leaving the ODD and hand back control safely.

Step 3: independent validation

SR 11-7's core principle: the team that builds a model cannot be the only team that judges it. You need effective challenge from a group with authority, competence, and independence.

For a Tier 1 perception model, independent validation means:

  • A separate test set the development team never saw (a holdout), especially rich in edge cases: occluded pedestrians, wheelchair users, people pushing strollers, unusual poses.
  • Adversarial and corner-case testing: fog, low sun glare, reflective surfaces, construction zones.
  • Checking for distributional shift: does performance drop on demographics or geographies underrepresented in training data?

Here is a minimal validation gate expressed as code. The point is that acceptance is explicit and non-negotiable, not a vibe.

python
def perception_gate(metrics, odd_ok):
    # Tier 1 acceptance thresholds (illustrative, set by safety team)
    return (
        metrics["pedestrian_recall"] >= 0.995 and
        metrics["false_negative_rate_night"] <= 0.005 and
        metrics["worst_subgroup_recall"] >= 0.99 and
        odd_ok  # model correctly detects ODD boundaries
    )

The thresholds are set by your chief safety officer, not chosen to make the model look good. Note the worst_subgroup_recall: an average that hides a weak subgroup is a lawsuit waiting to happen.

🎬 [VIDEO: "How Tesla's Autopilot and Full Self-Driving Actually Work" - youtube.com - clear breakdown of the perception-to-planning pipelinepipelineAll active sales opportunities across the stages of the sales process, together with their combined potential value and probability of closing.Voir la définition complète → in a real system]

Step 4: governance gates a CSO will sign

A governance gate is a checkpoint where a model cannot advance to the next stage without documented sign-off. Your chief safety officer (CSO) is personally accountable, so the gate must give them defensible evidence.

Design three gates:

Gate A: Development to validation. Requires a completed safety case: a structured argument, backed by evidence, that the system is acceptably safe for its ODD. ISO/PAS 8800 expects this. Also requires a documented ODD and a data sheet describing training data provenancedata provenanceData lineage maps how data moves and transforms across systems, from origin to consumption, showing where it came from, what changed it, and where it goes.Voir la définition complète →.

Gate B: Validation to limited deployment. Requires independent validation passed, edge-case results, subgroup analysis, and a monitoring plan. Deployment is geofenced or shadow-mode first.

Gate C: Limited to full deployment. Requires field data from limited deployment showing real-world performance matches lab results, plus an incident and rollback procedure.

Each gate produces a signed artifact. When NHTSA or a court asks "how did you decide this was safe," you hand over the safety case. That is the difference between a defensible decision and a headline.

Vérification des acquis

1. According to SR 11-7 as adapted in this lesson, why does a pedestrian classifier qualify as a 'model' subject to model risk management?

2. The lesson describes a lane-keeping system used on a road type it was never validated for. Which SR 11-7 source of model risk does this primarily illustrate?

3. What is the core reason the lesson argues automotive AI should 'keep the framework and raise the bar' relative to banking MRM?

CHOIX MULTIPLES

4. Select ALL correct answers about how the Uber Tempe incident illustrates model risk concepts.

Sélectionnez toutes les réponses correctes.

CHOIX MULTIPLES

5. Select ALL correct answers about the regulatory and standards backdrop described for safety-critical automotive AI.

Sélectionnez toutes les réponses correctes.

Step 5: monitor after deployment

Banking learned the hard way that models decay. A credit model trained pre-2008 failed in the crash. Perception models decay too, through data drift: new vehicle designs, new e-scooter shapes, faded road markings, seasonal changes.

Build continuous monitoring:

  • Disengagement tracking: how often the human takes over, and why. A rising rate signals ODD drift or model degradation.
  • Near-miss logging: hard braking events, close approaches. These are leading indicators before an actual crash.
  • Shadow evaluation: run a candidate model silently alongside production, compare decisions, deploy only if it is strictly better on the safety metrics.

A worked example. Suppose your fleet drives 2 million km per month and logs 40 safety-relevant disengagements. That is 1 per 50,000 km. If next month it rises to 80 disengagements over the same distance (1 per 25,000 km), the rate has doubled. That is a trigger to investigate, not to wait for a crash. Set the alarm threshold in advance and in writing, so nobody argues about it during an incident.

Step 6: own the failure path

Every Tier 1 model needs a defined fallback: what the system does when it is uncertain or leaving its ODD. Options include a minimal risk maneuver (controlled slowdown and stop in a safe location) or a timed handover to the driver with escalating alerts.

The failure path is part of the model risk framework, not an afterthought. A perception model that fails gracefully into a safe stop is lower risk than a more accurate one that fails silently.

Key Takeaways

Précédent

The regulatory map every automotive AI leader must navigate

Suivant

The AI risks that bite automakers hardest

Adapt, do not import.
SR 11-7's principles (a model can be wrong or misused; independent effective challenge; ongoing monitoring) transfer directly. The loss function changes from money to lives, so raise thresholds and formalize sign-offs.
  • Tier by harm, then match governance intensity to the tier. Anchor everything to ISO/PAS 8800, ISO 21448 (SOTIF), and the relevant UN Regulations.
  • The ODD is your primary control. Most failures are a validated model used outside its envelope. Write the ODD as an enforceable contract and detect boundary violations in code.
  • Gates produce signed artifacts. A documented safety case is what makes a CSO's approval defensible to NHTSA, regulators, and courts.
  • Monitor for drift and define the failure path. Track disengagements and near-misses with pre-set alarm thresholds, and ensure every Tier 1 model fails into a minimal risk maneuver.