Automobil · Ein Model-Risk-Framework für sicherheitskritische KI aufbauen

2018 erfasste ein Uber-Testfahrzeug in Tempe, Arizona, eine Fußgängerin und tötete sie. Das Perception-System erkannte sie 5,6 Sekunden vor dem Aufprall, klassifizierte sie aber immer wieder neu: Fahrzeug, dann unbekannt, dann Fahrrad. Die Software war nicht darauf ausgelegt, einen Menschen außerhalb eines Zebrastreifens zu erwarten. Das ist ein Model-Risk-Versagen, und keine Rückstellung deckt es ab.

Banken haben 25 Jahre damit verbracht, Disziplin im Umgang mit Modellen aufzubauen, die Risiken falsch bepreisen. Automotive-KI braucht dieselbe Disziplin, aber die Loss Function ist ein Menschenleben, kein fauler Kredit. Diese Lektion überträgt Model Risk Management (MRM) auf Bankenniveau auf Perception-, Prediction- und Planning-Modelle im Fahrzeug.

Was „Model Risk“ hier bedeutet

Model Risk ist das Risiko eines Schadens (finanziell, reputationsbezogen oder kkDie durchschnittliche Zahl neuer Nutzer, die jeder bestehende Nutzer über Empfehlungen generiert. Über 1,0 verstärkt sich das Wachstum selbst und wird exponentiell.Vollständige Definition ansehen →örperlich) durch ein Modell, das falsch ist oder falsch eingesetzt wird. Das Konzept stammt aus der Guidance SR 11-7 der US Federal Reserve und des OCC (Office of the Comptroller of the Currency), dem Grundlagentext zum Model Risk Management. Lesen Sie das Original: es ist kurz und überraschend gut lesbar (SR 11-7 guidance).

SR 11-7 sagt zwei Dinge, die sich perfekt auf Fahrzeuge übertragen lassen:

1. Ein Modell ist jede quantitative Methode, die Input-Daten in eine Entscheidung überführt. Ein Fußgängerklassifikator fällt darunter.
2. Model Risk hat zwei Quellen: das Modell kann grundsätzlich falsch sein, und das Modell kann falsch eingesetzt werden. Beides gilt für ein Lane-Keeping-System, das auf einem Straßentyp verwendet wird, für den es nie validiert wurde.

Der Unterschied: ein falsch bepreister Swap kostet Geld. Ein übersehener Fußgänger kostet ein Leben. Also behalten wir das Framework und ziehen die Messlatte höher.

Der regulatorische Rahmen für 2026

Sie bauen dieses Framework innerhalb realen Rechts.

• UN Regulation No. 157 (ALKS, Automated Lane Keeping Systems) und UN Regulation No. 171 (DCAS, Driver Control Assistance Systems) setzen verbindliche Anforderungen in Europa und den meisten UNECE-Mitgliedstaaten.
• ISO 26262 deckt Funktionale Sicherheit ab (Ausfälle durch Fehler). ISO 21448 (SOTIF, Safety Of The Intended Functionality) deckt das schwierigere Problem ab: das System hat keinen Fehler und versagt trotzdem, weil die Welt es überrascht hat. Perception-KI bewegt sich überwiegend im SOTIF-Bereich.
• ISO/PAS 8800 (veröffentlicht 2024) ist der erste Standard speziell für KI-Sicherheit in Straßenfahrzeugen. Das ist Ihr Ankerdokument.
• Der EU AI Act klassifiziert KI-Sicherheitskomponenten von Fahrzeugen als hochriskant, verweist aber weitgehend auf das bestehende automobile Typgenehmigungsrecht, anstatt es zu duplizieren.
• In den USA regelt die NHTSA (National Highway Traffic Safety Administration) über die Federal Motor Vehicle Safety Standards und ihre Standing General Order, die eine Unfallmeldepflicht für automatisierte Systeme vorschreibt.

Nennen Sie diese Institutionen korrekt, wenn Sie mit einer Aufsichtsbehörde sprechen. Vage Verweise signalisieren, dass Sie die Standards nicht gelesen haben.

Schritt 1: Modelle nach Sicherheitsrelevanz in Tiers einteilen

Banken teilen Modelle nach Materialität ein. Sie teilen nach Schadenspotenzial ein. Bauen Sie eine einfache Tiering-Matrix, die Severity (wie schlimm bei Versagen) und Controllability (kann der Fahrer oder das System das abfangen) kombiniert.

Das Tier bestimmt die Governance-Intensität. Tier 1 erhält unabhängige Validierung, umfangreiche Edge-Case-Tests und eine formale Freigabe. Tier 3 erhält eine leichtgewichtige Prüfung. Investieren Sie keinen Tier-1-Aufwand in Tier-3-Modelle, sonst geht Ihr Safety-Team unter und die echten Risiken werden übersehen.

Schritt 2: die Operational Design Domain definieren

Die ODD (Operational Design Domain) sind die konkreten Bedingungen, unter denen das Modell validiert funktioniert: Straßentypen, Wetter, Lichtverhältnisse, Geschwindigkeitsbereich, Geografie. Das ist Ihr wichtigster Kontrollmechanismus.

Die meisten „KI-Fehler“ sind in Wirklichkeit ODD-Verletzungen: ein Modell, das außerhalb seines validierten Rahmens eingesetzt wird. Im Fall Tempe war ein System nachts in einem Szenario im Einsatz, für das es nicht gebaut war.

Schreiben Sie die ODD als Vertrag. Beispiel für einen Highway-Pilot:

• Nur getrennte Richtungsfahrbahnen, kein Querverkehr
• Tageslicht, trocken oder leichter Regen
• 30 bis 130 km/h
• Klar erkennbare Fahrbahnmarkierungen vorhanden

Und setzen Sie das dann im Code durch. Das Fahrzeug muss erkennen, wenn es die ODD verlässt, und die Kontrolle sicher zurückgeben.

Schritt 3: unabhängige Validierung

Das Kernprinzip von SR 11-7: das Team, das ein Modell baut, kann nicht das einzige Team sein, das es beurteilt. Sie brauchen Effective Challenge durch eine Gruppe mit Autorität, Kompetenz und Unabhängigkeit.

Für ein Tier-1-Perception-Modell bedeutet unabhängige Validierung:

• Ein separates Test-Set, das das Entwicklungsteam nie gesehen hat (ein Holdout), besonders reich an Edge Cases: teilverdeckte Fußgänger, Rollstuhlfahrer, Menschen mit Kinderwagen, ungewöhnliche Körperhaltungen.
• Adversarial- und Corner-Case-Tests: Nebel, tief stehende Sonne, spiegelnde Oberflächen, Baustellen.
• Prüfung auf Distributional Shift: sinkt die Performance bei Demografien oder Geografien, die in den Trainingsdaten unterrepräsentiert sind?

Hier ein minimales Validierungs-Gate als Code. Der Punkt ist, dass die Akzeptanz explizit und nicht verhandelbar ist, kein Bauchgefühl.

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
    )

Die Schwellenwerte setzt Ihr Chief Safety Officer, sie werden nicht so gewählt, dass das Modell gut aussieht. Beachten Sie worst_subgroup_recall: ein Durchschnitt, der eine schwache Subgruppe verdeckt, ist eine Klage mit Anlauf.

🎬 [VIDEO: "How Tesla's Autopilot and Full Self-Driving Actually Work" - youtube.com - clear breakdown of the perception-to-planning pipelinepipelineAlle aktiven Verkaufschancen über die Phasen des Vertriebsprozesses hinweg, zusammen mit ihrem gesamten potenziellen Wert und ihrer Abschlusswahrscheinlichkeit.Vollständige Definition ansehen → in a real system]

Schritt 4: Governance-Gates, die ein CSO unterschreibt

Ein Governance-Gate ist ein Checkpoint, an dem ein Modell ohne dokumentierte Freigabe nicht in die nächste Phase gelangt. Ihr Chief Safety Officer (CSO) haftet persönlich, also muss das Gate ihm belastbare Evidenz liefern.

Entwerfen Sie drei Gates:

Gate A: Entwicklung zu Validierung. Erfordert einen fertigen Safety Case: eine strukturierte, mit Evidenz gestützte Argumentation, dass das System für seine ODD akzeptabel sicher ist. ISO/PAS 8800 erwartet das. Erfordert außerdem eine dokumentierte ODD und ein Data Sheet zur Herkunft der Trainingsdaten.

Gate B: Validierung zu begrenztem Rollout. Erfordert bestandene unabhängige Validierung, Edge-Case-Ergebnisse, Subgruppenanalyse und einen Monitoring-Plan. Der Rollout erfolgt zunächst geofenced oder im Shadow Mode.

Gate C: Begrenzter zu vollem Rollout. Erfordert Felddaten aus dem begrenzten Rollout, die zeigen, dass die Real-World-Performance den Laborergebnissen entspricht, plus ein Incident- und Rollback-Verfahren.

Jedes Gate erzeugt ein unterzeichnetes Artefakt. Wenn die NHTSA oder ein Gericht fragt „wie haben Sie entschieden, dass das sicher ist“, reichen Sie den Safety Case ein. Das ist der Unterschied zwischen einer verteidigungsfähigen Entscheidung und einer Schlagzeile.

Schritt 5: nach dem Rollout monitoren

Die Banken haben auf die harte Art gelernt, dass Modelle verfallen. Ein Kreditmodell, das vor 2008 trainiert wurde, versagte im Crash. Perception-Modelle verfallen auch, durch Data Drift: neue Fahrzeugdesigns, neue E-Scooter-Formen, verblasste Straßenmarkierungen, jahreszeitliche Veränderungen.

Bauen Sie kontinuierliches Monitoring auf:

• Disengagement-Tracking: wie oft der Mensch übernimmt, und warum. Eine steigende Rate signalisiert ODD-Drift oder Modellverschlechterung.
• Near-Miss-Logging: starke Bremsvorgänge, knappe Annäherungen. Das sind Frühindikatoren vor einem tatsächlichen Unfall.
• Shadow Evaluation: ein Kandidatenmodell still parallel zur Produktion laufen lassen, Entscheidungen vergleichen, nur ausrollen, wenn es bei den Safety-Metriken strikt besser ist.

Ein durchgerechnetes Beispiel. Angenommen, Ihre Flotte fährt 2 Millionen km pro Monat und loggt 40 sicherheitsrelevante Disengagements. Das ist 1 pro 50.000 km. Wenn es im nächsten Monat bei gleicher Distanz auf 80 Disengagements steigt (1 pro 25.000 km), hat sich die Rate verdoppelt. Das ist ein Auslöser zur Untersuchung, nicht zum Warten auf einen Unfall. Legen Sie die Alarmschwelle vorab und schriftlich fest, damit im Incident niemand darüber diskutiert.

Schritt 6: den Failure Path verantworten

Jedes Tier-1-Modell braucht ein definiertes Fallback: was das System tut, wenn es unsicher ist oder seine ODD verlässt. Optionen sind ein Minimal Risk Maneuver (kontrolliertes Abbremsen und Anhalten an einer sicheren Stelle) oder eine zeitgesteuerte Übergabe an den Fahrer mit eskalierenden Warnungen.

Der Failure Path ist Teil des Model-Risk-Frameworks, kein Nachgedanke. Ein Perception-Modell, das kontrolliert in einen sicheren Halt versagt, ist risikoärmer als ein genaueres, das stillschweigend versagt.

Key Takeaways

• Adaptieren, nicht importieren. Die Prinzipien von SR 11-7 (ein Modell kann falsch sein oder falsch eingesetzt werden; unabhängige Effective Challenge; laufendes Monitoring) lassen sich direkt übertragen. Die Loss Function wechselt von Geld zu Leben, also erhöhen Sie die Schwellenwerte und formalisieren die Freigaben.
• Nach Schadenspotenzial tiern, dann die Governance-Intensität an das Tier anpassen. Verankern Sie alles in ISO/PAS 8800, ISO 21448 (SOTIF) und den relevanten UN Regulations.
• Die ODD ist Ihr wichtigster Kontrollmechanismus. Die meisten Fehler sind ein validiertes Modell, das außerhalb seines Rahmens eingesetzt wird. Schreiben Sie die ODD als durchsetzbaren Vertrag und erkennen Sie Grenzverletzungen im Code.
• Gates erzeugen unterzeichnete Artefakte. Ein dokumentierter Safety Case macht die Freigabe eines CSO gegenüber NHTSA, Aufsichtsbehörden und Gerichten verteidigungsfähig.
• Auf Drift monitoren und den Failure Path definieren. Verfolgen Sie Disengagements und Near-Misses mit vorab festgelegten Alarmschwellen, und stellen Sie sicher, dass jedes Tier-1-Modell in ein Minimal Risk Maneuver versagt.