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

# 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, eine Person außerhalb eines Zebrastreifens zu erwarten. Das ist ein Model-Risk-Versagen, und keine finanzielle Rückstellung deckt es ab.

Banken haben 25 Jahre damit verbracht, Disziplin rund um Modelle aufzubauen, die Risiko falsch bepreisen. Automotive-KI braucht die gleiche Disziplin, aber die Verlustfunktion ist ein Menschenleben, kein fauler Kredit. Diese Lektion überträgt Model Risk Management (MRM) auf Banken-Niveau auf Perception-, Prediction- und Planning-Modelle in Fahrzeugen.

Was „Model Risk“ hier bedeutet

Model Risk ist das Risiko eines Schadens (finanziell, reputationsbezogen oder kkThe average number of new users each existing user generates through referrals. Above 1.0, growth compounds on itself and becomes exponential.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 Autos übertragen lassen:

1. Ein Modell ist jede quantitative Methode, die Eingabedaten in eine Entscheidung verwandelt. Ein Fußgänger-Klassifikator zählt dazu.

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 Spurhaltesystem, das auf einem Straßentyp genutzt wird, für den es nie validiert wurde.

Der Unterschied: ein falsch bepreister Swap kostet Geld. Ein übersehener Fußgänger kostet ein Leben. Wir behalten also das Framework und erhöhen die Anforderungen.

Der regulatorische Hintergrund für 2026

Sie bauen dieses Framework innerhalb echten 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 in den meisten UNECE-Mitgliedsstaaten.
• 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 lebt ü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 Typgenehmigungsrecht im Automobilbereich, statt es zu duplizieren.
• In den USA reguliert 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 einem Regulator sprechen. Vage Verweise signalisieren, dass Sie die Standards nicht gelesen haben.

Schritt 1: Modelle nach Safety-Impact in Tiers einteilen

Banken stufen Modelle nach Materialität ein. Sie stufen nach Schadenspotenzial ein. Bauen Sie eine einfache Tiering-Matrix aus Severity (wie schlimm bei Versagen) und Controllability (kann der Fahrer oder das System sich fangen).

| Tier | Beschreibung | Beispiel |

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

| Tier 1 | Versagen kann direkt zum Tod führen, kein menschliches Fallback in der verfügbaren Zeit | Fußgängererkennung in einem L3/L4-System bei Geschwindigkeit |

| Tier 2 | Versagen trägt zum Schaden bei, der Fahrer kann eingreifen | Spurverlassenswarnung, adaptive Geschwindigkeitsregelung |

| Tier 3 | Komfort oder Bequemlichkeit, kein Safety-Pfad | Gestenerkennung im Innenraum, Signalton des Parkassistenten |

Das Tier bestimmt die Governance-Intensität. Tier 1 bekommt unabhängige Validierung, umfangreiche Edge-Case-Tests und ein formales Sign-off. Tier 3 bekommt eine leichtgewichtige Prüfung. Verwenden Sie keinen Tier-1-Aufwand für 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 als funktionsfähig validiert ist: Straßentypen, Wetter, Lichtverhältnisse, Geschwindigkeitsbereich, Geografie. Das ist Ihr wichtigstes Kontrollinstrument.

Die meisten „KI-Fehler“ sind tatsächlich 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-Piloten:

• Nur getrennte Fahrbahnen, kein Querverkehr
• Tageslicht und trocken oder leichter Regen
• 30 bis 130 km/h
• Deutliche Fahrbahnmarkierungen vorhanden

Dann setzen Sie es im Code durch. Das Fahrzeug muss erkennen, wann 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, darf 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 Testset, das das Entwicklungsteam nie gesehen hat (ein Holdout), besonders reich an Edge Cases: verdeckte Fußgänger, Rollstuhlnutzer, Menschen mit Kinderwagen, ungewöhnliche KKThe average number of new users each existing user generates through referrals. Above 1.0, growth compounds on itself and becomes exponential.Vollständige Definition ansehen →örperhaltungen.
• Adversarial- und Corner-Case-Tests: Nebel, tiefstehende Sonne mit Blendung, reflektierende Oberflächen, Baustellen.
• Prüfung auf Distributional Shift: fällt die Performance bei Demografien oder Regionen ab, die in den Trainingsdaten unterrepräsentiert sind?

Hier ein minimales Validierungs-Gate als Code. Der Punkt ist, dass die Abnahme 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, die nur auf ihren Moment wartet.

🎬 [VIDEO: "How Tesla's Autopilot and Full Self-Driving Actually Work" - youtube.com - klare Aufschlüsselung der PipelinePipelineAll active sales opportunities across the stages of the sales process, together with their combined potential value and probability of closing.Vollständige Definition ansehen → von Perception zu Planning in einem echten System]

Schritt 4: Governance-Gates, die ein CSO unterschreibt

Ein Governance-Gate ist ein Checkpoint, an dem ein Modell nicht in die nächste Phase gehen kann, ohne dokumentiertes Sign-off. 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 belegte Argumentation, dass das System für seine ODD hinreichend 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 eine Incident- und Rollback-Prozedur.

Jedes Gate erzeugt ein unterschriebenes Artefakt. Wenn die NHTSA oder ein Gericht fragt „wie haben Sie entschieden, dass das sicher ist“, übergeben Sie den Safety Case. Das ist der Unterschied zwischen einer belastbaren Entscheidung und einer Schlagzeile.

Schritt 5: nach dem Rollout monitoren

Das Banking hat auf die harte Weise gelernt, dass Modelle verfallen. Ein vor 2008 trainiertes Kreditmodell 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:

• Disengagement-Tracking: wie oft der Mensch übernimmt, und warum. Eine steigende Rate signalisiert ODD-Drift oder Modelldegradation.
• Near-Miss-Logging: starke Bremsungen, 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 Rechenbeispiel. Angenommen, Ihre Flotte fährt 2 Millionen km pro Monat und protokolliert 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. Setzen Sie die Alarmschwelle vorab und schriftlich, damit während eines Vorfalls niemand darüber diskutiert.

Schritt 6: den Failure-Pfad verantworten

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

Der Failure-Pfad 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 still versagt.

Key Takeaways

• Adaptieren, nicht importieren. Die Prinzipien von SR 11-7 (ein Modell kann falsch oder falsch eingesetzt sein; unabhängige effective challenge; laufendes Monitoring) übertragen sich direkt. Die Verlustfunktion wechselt von Geld zu Leben, also erhöhen Sie Schwellenwerte und formalisieren Sie Sign-offs.
• Nach Schaden in Tiers einteilen, 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 primäres Kontrollinstrument. 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 unterschriebene Artefakte. Ein dokumentierter Safety Case macht die Freigabe eines CSO gegenüber NHTSA, Regulatoren und Gerichten belastbar.
• Auf Drift monitoren und den Failure-Pfad definieren. Verfolgen Sie Disengagements und Near-Misses mit vorab gesetzten Alarmschwellen und stellen Sie sicher, dass jedes Tier-1-Modell in ein Minimal Risk Maneuver versagt.