+150 XP

Guardrails und Pre-Deployment-Checks, bevor Sie KI ausliefern

# Guardrails und Pre-Deployment-Checks, bevor Sie KI ausliefern

2023 nahm Cruise (die Robotaxi-Einheit von GM) die gesamte Flotte von den US-Straßen, nachdem eine Fußgängerin von einem der Fahrzeuge rund 20 Fuß mitgeschleift worden war. Das California DMV setzte die Genehmigungen aus. Die Lehre war nicht, dass das Perception-Modell besonders schlecht war. Sie war, dass der Go/No-Go-Prozess und die Rollback-Trigger nicht stark genug waren, um einen seltenen, katastrophalen Edge Case vor oder nach dem Deployment abzufangen.

Diese Lektion liefert Ihnen die Checkliste. Nicht die Philosophie, sondern die konkreten Gates, die ein Release Manager abzeichnen sollte, bevor ein KI-System im Fahrzeug beim Kunden landet.

Warum Automotive-KI härtere Gates braucht als die meisten Branchen

Eine Recommendation Engine, die daneben liegt, zeigt Ihnen einen schlechten Film. Eine Automotive-KI, die daneben liegt, kann einen Radfahrer erfassen. Die Schwere der Konsequenz verändert alles an den Prüfungen.

Zwei regulatorische Ankerpunkte, die Sie kennen müssen:

  • UNECE-Regelungen (United Nations Economic Commission for Europe), konkret UN R157 für Automated Lane Keeping Systems und UN R155 für Cybersecurity-Management. Sie sind in der EU, Japan, Korea und vielen weiteren Märkten verbindlich.
  • Der EU AI Act (seit 2024 in Kraft, mit Übergangsfristen bis 2026 und 2027), der Sicherheitskomponenten von Fahrzeugen als hochriskante KI einordnet, zusätzlich zu den bestehenden Typgenehmigungsregeln.

In den USA gibt es kein einheitliches Bundesgesetz für KI im Fahrzeug. Die NHTSA (National Highway Traffic Safety Administration) steuert über Sicherheitsstandards und ihre Rückrufbefugnis und betreibt eine Standing General Order, die eine Unfallmeldepflicht für automatisierte Fahrsysteme vorschreibt. Die State DMVs (Kalifornien, Arizona, Texas) erteilen Test- und Deployment-Genehmigungen.

Übersetzt heißt das: Ihre Checkliste ist keine optionale Dokumentation. Sie ist der Evidence Trail, den eine Behörde per Subpoena anfordern wird.

Die fünf Gates der Go/No-Go-Checkliste

Gate 1: Durchsetzung der ODD-Grenzen

Die ODD (Operational Design Domain) ist der genaue Rahmen, in dem das System funktionieren soll: Straßentypen, Geschwindigkeitsbereich, Wetter, Lichtverhältnisse, Geografie.

Ein Gate-Check fragt nicht nur „Was ist die ODD?“ Er fragt: Was passiert in der Sekunde, in der wir sie verlassen?

Konkretes Beispiel. Ein Highway-Pilot, zertifiziert für richtungsgetrennte Autobahnen, trocken oder leichter Regen, über 5 Grad Celsius, bis 130 km/h. Der Check muss belegen, dass:

  • Dichter Nebel, erkannt über Kamera und einen Abfall der Lidar-Confidence, innerhalb eines definierten Zeitbudgets eine Übernahmeaufforderung auslöst.
  • Die Annäherung an eine nicht kartierte Baustelle (außerhalb der HD-Map-ODD) zu einem geordneten Degradieren führt und das System nicht stillschweigend weiterlenkt.

Sie wollen einen expliziten ODD-Monitor im Code-Pfad, keine Annahme, die in einer Folie verschwindet.

python
# ODD monitor: a guardrail, not a model
def within_odd(state):
    return (
        state.road_type == "divided_highway"
        and state.speed_kmh <= 130
        and state.ambient_temp_c >= 5
        and state.sensor_confidence >= 0.85
        and state.on_hd_map
    )

if not within_odd(current_state):
    request_driver_handover(timeout_s=10)  # then escalate to MRC

Gate 2: Fallback- und MRC-Verhalten

Die MRC (Minimal Risk Condition) ist der sichere Zustand, den das Fahrzeug erreicht, wenn es nicht weiterfahren kann: typischerweise Verlangsamen, Ausweichen auf den Seitenstreifen oder Anhalten in der Spur mit Warnblinker. UN R157 verlangt ausdrücklich ein definiertes Minimum Risk Manoeuvre.

Der Gate-Check validiert die komplette Fallback-Leiter:

1. Fahrer verfügbar und reaktionsfähig: Kontrolle zurückgeben.

2. Fahrer reagiert nicht: eskalierende Warnungen.

3. Weiterhin keine Reaktion oder kein Fahrer (Robotaxi): MRC ausführen.

Testen Sie die hässlichen Fälle. Der Fahrer hat einen medizinischen Notfall bei 120 km/h auf der Mittelspur. Was tut die MRC dann tatsächlich? „In der Spur anhalten“ kann auf einer Autobahn tödlich sein. Der Check muss zeigen, dass die MRC kontextangemessen ist und dass sie in der Simulation und auf einer abgesperrten Strecke validiert wurde, nicht nur in einem Anforderungsdokument steht.

Gate 3: Red-Team-Ergebnisse

Red-Teaming heißt, das eigene System bewusst anzugreifen, bevor es jemand anderes tut.

Bei Automotive-KI nehmen Red-Teams sowohl das Modell als auch die Pipeline unter Feuer:

  • Adversarial Perception: Aufkleber auf Stoppschildern, projizierte Phantombilder, gezielt darauf getunt, den Classifier zu täuschen. Das klassische Forschungsbeispiel sind kleine Aufkleber, die ein Modell ein Stoppschild falsch lesen lassen. Der breitere Sicherheitsrahmen der NHTSA findet sich in ihrer Arbeit zu Automated Vehicles.
  • Sensor-Spoofing und Jamming: GPS-Spoofing, das das Fahrzeug aus seiner kartierten Spur drängt.
  • Cybersecurity (Terrain von UN R155): Kann ein Angreifer über den Connectivity-Stack des Fahrzeugs an das Inferenz-System gelangen?

Das Gate lautet nicht „Haben wir ein Red-Teaming gemacht?“ Es lautet: Was hat das Red-Team gefunden, was ist behoben, welches Restrisiko akzeptieren wir, und wer hat die Akzeptanz gezeichnet? Ein offenes kritisches Finding ohne Owner ist ein automatisches No-Go.

How to Trick a Self-Driving Car

Watch on YouTube

Gate 4: Sign-off zur Data Lineage

Data Lineage ist die dokumentierte Herkunft, Transformation und Rechtehistorie jedes Datensatzes, der zum Trainieren und Validieren des Modells verwendet wurde.

Warum ein Release-Gate das interessiert:

  • Bias und Coverage-Lücken: Wenn Ihre Trainingsdaten zur Fußgängererkennung Rollstuhlnutzer oder Personen in bestimmter Kleidung in der Dämmerung unterrepräsentieren, erbt das Modell diesen blinden Fleck. Das Gate will Belege zur Abdeckung über alle Bedingungen Ihrer ODD.
  • Provenienz und Einwilligung: Wurden die Bilder legal erhoben? Unter der DSGVO (der EU-Datenschutz-Grundverordnung) sind Gesichter und Kennzeichen in europäischen Straßendaten mit Pflichten verbunden.
  • Reproduzierbarkeit: Können Sie genau die Modellversion neu bauen, die ausgeliefert wird? Wenn im siebten Monat ein Unfall passiert, müssen Sie den exakten Trainingsdatensatz und die Gewichte wiederherstellen.

Ein saubere Lineage-Sign-off nennt die Dataset-Versionen, den Labeling-Dienstleister, die Lizenz und bestätigt, dass das Validierungsset vom Training disjunkt ist. Kein Leakage, keine mysteriösen Daten.

Gate 5: Monitoring-Hooks und der Rollback-Trigger

Das Ausliefern ist nicht die Ziellinie. Das Gate verlangt, dass das System im Feld so instrumentiert ist, dass Sie Probleme sehen und flottenweit zurückdrehen können.

Definieren Sie die Auslöseschwellen vor dem Launch:

  • Disengagement-Rate: Eingriffe pro 1.000 km. In Kalifornien werden Disengagement-Daten öffentlich an das DMV gemeldet, das ist also eine echte, vergleichbare Metrik.
  • Near-Miss- und Hard-Braking-Events pro Fahrzeugtag.
  • Häufigkeit von ODD-Exits: plötzliche Spitzen deuten darauf hin, dass sich die Welt (neue Baustellensaison) schneller geändert hat als die Karte.
  • Model Drift: Die Input-Verteilung entfernt sich vom Training (zum Beispiel verändert ein Software-Update an einem verbreiteten Wettbewerber-Scheinwerfer das Nachtbildprofil).

Definieren Sie dann den Rollback: einen dokumentierten, getesteten Weg, alle Fahrzeuge over the air auf eine frühere validierte Softwareversion zurückzusetzen, plus die Frage, wer die Befugnis hat, den Auslöser zu ziehen, und wie schnell. Das Versagen von Cruise lag teils darin, dass die Reaktion langsam war und die Flotte im Einsatz blieb.

Ein durchgerechnetes Beispiel für eine Trigger-Schwelle (illustrativ, kein zertifizierter Standard):

  • Validierte Baseline-Rate für hartes Bremsen: 0,4 Events pro Fahrzeugtag.
  • Trigger: Rate übersteigt 2x Baseline (0,8) durchgehend über 24 Stunden flottenweit.
  • Maßnahme: automatische Alarmierung des Safety Owners, Rollout auf neue Fahrzeuge einfrieren, Rollback vorbereiten.

Das ist 0,4 x 2 = 0,8, ein einfacher Multiplikator, auf den Sie sich einigen und den Sie vor dem Launch festschreiben, damit ihn niemand in der Krise nachverhandelt.

Wissenscheck

1. Was war laut Lektion das Kernversagen, das der Cruise-Robotaxi-Vorfall illustriert?

2. Warum argumentiert die Lektion, dass Automotive-KI härtere Release-Gates braucht als ein System wie eine Recommendation Engine?

3. Welche Rolle spielt eine Operational Design Domain (ODD) vor allem in einer Pre-Deployment-Checkliste?

MEHRFACHAUSWAHL

4. Wählen Sie ALLE korrekten Aussagen zum regulatorischen Umfeld für Automotive-KI, wie in der Lektion beschrieben.

Wählen Sie alle richtigen Antworten aus.

MEHRFACHAUSWAHL

5. Wählen Sie ALLE korrekten Aussagen dazu, warum die Pre-Deployment-Checkliste aus Compliance-Sicht wichtig ist.

Wählen Sie alle richtigen Antworten aus.

Aus der Checkliste eine Entscheidung machen

Ein Go/No-Go ist ein binäres Meeting mit benannten Ownern. Strukturieren Sie es so, dass kein Team seine eigenen Hausaufgaben korrigiert.

| Gate | Owner | Go-Kriterium |

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

| ODD-Durchsetzung | Systems Engineering | Exit-Verhalten getestet, Monitor im Code |

| Fallback / MRC | Safety Engineering | MRC in Sim + auf Strecke validiert, kontextsensitiv |

| Red-Team | Security + Safety | Keine offenen kritischen Findings, Restrisiken gezeichnet |

| Data Lineage | Data / ML Governance | Provenienz sauber, Sets disjunkt, reproduzierbar |

| Monitoring + Rollback | Operations | Trigger gesetzt, OTA-Rollback end to end getestet |

Den Vorsitz sollte jemand führen, der Nein sagen kann und es überlebt. Wenn der Safety Owner an die Person berichtet, deren Bonus vom Ausliefern abhängt, ist Ihre Governance Theater.

Noch ein Prinzip: der Safety Case. Das ist eine strukturierte, mit Evidenz unterlegte Argumentation, dass das System für seine ODD hinreichend sicher ist. Standards wie ISO 21448 (SOTIF, Safety Of The Intended Functionality) und ISO 26262 (funktionale Sicherheit) liegen dem zugrunde. SOTIF adressiert speziell das Automotive-KI-Problem: Gefahren aus Performance-Grenzen, auch wenn nichts defekt ist (das Modell erkennt die Situation einfach nicht). Ihre fünf Gates sind die Evidenz, die in den Safety Case einfließt.

Key Takeaways

  • ODD und MRC müssen im Code durchgesetzt werden, nicht nur dokumentiert sein. Das Gate belegt, was an der Grenze und im Worst-Case-Fallback passiert, getestet in der Simulation und auf der Strecke.
  • Red-Team-Findings sind ein Release-Gate: Ausliefern nur mit null offenen kritischen Punkten und einem gezeichneten, mit Owner versehenen Nachweis über akzeptiertes Restrisiko.
  • Data Lineage verschafft Ihnen Reproduzierbarkeit und Verteidigungsfähigkeit. Sie müssen das exakt ausgelieferte Modell neu bauen und zeigen können, dass Ihre Trainingsdaten Ihre ODD ohne Leakage abdecken.
  • Definieren Sie Rollback-Trigger und Befugnisse vor dem Launch, mit konkreten Schwellen (zum Beispiel 2x Baseline beim harten Bremsen über 24 Stunden) und einem getesteten Over-the-Air-Pfad. Die langsame Reaktion von Cruise ist die Warnung.
  • Verankern Sie das Ganze in echten Regimen: UN R157 und R155, EU AI Act, NHTSA-Aufsicht und ein Safety Case nach SOTIF/ISO 26262. Die Checkliste ist Ihr regulatorischer Evidence Trail.