ISO PAS 8800: KI-Sicherheit im Fahrzeug einordnen

ISO PAS 8800 einordnen: KI-Sicherheit im Fahrzeug für Praktiker

ISO/PAS 8800:2024 ist die erste internationale Spezifikation, die die Sicherheit KI-basierter Funktionen im Straßenfahrzeug eigenständig behandelt. Sie gilt für sicherheitsrelevante E/E-Systeme mit KI-Technologie in Serienfahrzeugen und definiert einen KI-Sicherheitslebenszyklus, der Daten, Modell und Betrieb umfasst. Sie ergänzt ISO 26262 (funktionale Sicherheit) und ISO 21448 (SOTIF) um KI-spezifische Eigenschaften wie Robustheit, Verzerrung und Generalisierungsfähigkeit. Werkzeug-KI im Engineering, etwa Coding-Assistenz, fällt ausdrücklich nicht in ihren Geltungsbereich. sensified ordnet die Spezifikation für Safety- und Entwicklungsverantwortliche ein und beschreibt, was Teams heute vorbereiten können.

Die Frage kommt selten aus dem eigenen Team zuerst. Ein Kunde schickt einen Fragebogen zur Behandlung von KI-Anteilen im Projekt, ein Assessor kündigt im Vorgespräch an, sich das Thema anzusehen, oder eine Ausschreibung nennt ISO/PAS 8800:2024 als Referenz (Herausgeber: ISO, veröffentlicht Dezember 2024). Wer dann Safety oder Entwicklung verantwortet, braucht eine belastbare Einordnung: Was steht in dieser Spezifikation, für wen gilt sie, und was folgt daraus für das eigene Projekt. Dieser Beitrag liefert diese Einordnung. Die Praxis-Einschätzungen am Ende sind typisierte Hypothesen aus Projekterfahrung, die je Kunde und Toolchain zu prüfen sind.

Was die PAS regelt: Geltungsbereich und Anspruch

Der offizielle Titel lautet „Road vehicles — Safety and artificial intelligence“. Schon der Titel markiert den Anspruch: Es geht um die Sicherheit von KI im Fahrzeug selbst, auf Ebene des Fahrzeugverhaltens.

Sicherheitsrelevante KI im Serienfahrzeug

Die PAS gilt für sicherheitsrelevante Systeme, die ein oder mehrere elektrische oder elektronische (E/E) Systeme mit KI-Technologie enthalten und in Serien-Straßenfahrzeugen verbaut sind; Mopeds und Sonderfahrzeug-Systeme sind ausgenommen. Adressiert wird das Risiko unerwünschten sicherheitsrelevanten Verhaltens auf Fahrzeugebene, das aus drei Fehlerbildern von KI-Elementen entstehen kann: unzureichende Ausgaben des Modells (output insufficiencies), systematische Fehler und zufällige Hardwarefehler. Eingeschlossen sind auch Wechselwirkungen mit KI-Elementen außerhalb des Fahrzeugs, wenn sie direkt oder indirekt auf die Fahrzeugsicherheit wirken, etwa eine Objekterkennung in der Infrastruktur oder ein Feld-Monitoring im Backend. Der Fokus liegt primär auf maschinellem Lernen; Detailvorgaben zu einzelnen Verfahren wie tiefen neuronalen Netzen macht das Dokument bewusst nicht. Im Kern beschreibt es sicherheitsrelevante Eigenschaften von KI-Systemen, aus denen sich ein belastbares Sicherheitsargument für die Abwesenheit unvertretbarer Risiken aufbauen lässt.

Warum eine PAS und noch keine vollwertige Norm

PAS steht für Publicly Available Specification. Das ist ein Veröffentlichungsformat der ISO mit kürzerem Konsensweg als bei einer internationalen Norm: schneller verfügbar, dafür mit begrenzter Laufzeit und turnusmäßiger Überprüfung, an deren Ende die Überführung in eine vollwertige Norm stehen kann. Für Praktiker heißt das zweierlei. Erstens können sich Inhalte in einer künftigen Norm-Fassung noch verschieben. Zweitens ist die Grundlogik aus Lebenszyklus, Datenbehandlung und Sicherheitsargument bereits heute der Bezugspunkt, an dem sich Kunden, Prüfdienstleister und Assessoren orientieren.

Was die PAS nicht regelt: die Grenze zur Werkzeug-KI

Ebenso wichtig wie der Geltungsbereich ist seine Grenze. Hier entsteht die häufigste Verwechslung, und der Scope-Text der PAS löst sie selbst auf.

Coding-Assistenz und Engineering-Werkzeuge bleiben außen vor

Der Geltungsbereich stellt ausdrücklich klar, dass das Dokument keine spezifischen Leitlinien für Software-Werkzeuge liefert, die KI-Methoden nutzen. Coding-Assistenz, Qualitäts-Vorprüfung von Anforderungen, abfragbare Entwicklungsdokumentation oder KI-gestützte Testselektion fallen damit nicht unter ISO/PAS 8800, solange die KI im Werkzeug arbeitet und keine KI-Funktion ins Fahrzeug ausgeliefert wird. Diese Werkzeug-Ebene hat ihren eigenen, längst etablierten Pfad: die Tool-Vertrauensbetrachtung nach ISO 26262, sobald ein Werkzeug sicherheitsrelevante Arbeitsprodukte beeinflusst, plus einen definierten Freigabepfad je Einsatzfeld, bei dem KI assistiert und der Mensch verantwortet. Welche Einsatzfelder dort heute tragen und welche Triage-Klasse zu welchem Freigabepfad gehört, ordnet der Überblick zur KI in der Automotive-Softwareentwicklung ein. Wer beide Ebenen sauber trennt, beantwortet die Assessor-Frage nach KI im Projekt in zwei klaren Sätzen statt in einer Verteidigungsrede.

Weitere Grenzen des Geltungsbereichs

Auch innerhalb der Fahrzeug-Welt regelt die PAS nicht alles. Die Entwicklung von KI-Elementen, die nicht Teil des Fahrzeugs sind, liegt außerhalb des Geltungsbereichs; für solche Elemente verweist das Dokument auf domänenspezifische Leitlinien. Zulassungs- und Genehmigungsfragen behandelt die PAS ebenfalls nicht; sie ist ein technischer Standard, keine Rechtsvorschrift. Konkrete Algorithmen, Architekturen oder Werkzeugketten schreibt sie auch nicht vor; sie beschreibt nachzuweisende Eigenschaften und überlässt den Weg dorthin dem Entwicklungsteam.

Der KI-Sicherheitslebenszyklus: Daten, Modell, Betrieb

Das methodische Herzstück der PAS ist ein iterativer KI-Sicherheitslebenszyklus mit Anforderungen je Phase. Er erweitert die vertraute V-Modell-Denkweise um zwei Aspekte, die bei klassischer Software so nicht existieren: Daten als eigenständiges Sicherheitsartefakt und die fortlaufende Absicherung nach dem Produktionsstart.

Daten als Sicherheitsartefakt

Bei einer gelernten Funktion bestimmt der Datensatz das Verhalten mit, also behandelt die PAS Datensätze wie Arbeitsprodukte mit Sicherheitsrelevanz. Anforderungen an die Daten werden aus den Sicherheitsanforderungen des KI-Systems abgeleitet und müssen die vorgesehene Einsatzdomäne abdecken, die Operational Design Domain (ODD). Dazu gehören Versionierung, Ablage und Zugriffsrechte ebenso wie inhaltliche Fragen: korrekte Annotation, zueinander passende Rohdaten und Metadaten, dokumentierte Lücken mit verknüpften Maßnahmen. Verifikation und Validierung der Datensätze sind eigene Schritte, getrennt von der Prüfung des Modells. Die Nachweiskette läuft damit von der Gefährdung über die Sicherheitsanforderung bis in den Datensatz-Stand hinein.

Vom trainierten Modell zur Absicherung im Betrieb

Der zweite neue Aspekt ist der Betrieb. Ein trainiertes Modell ist mit der Freigabe nicht fertig abgesichert, weil sich seine Umgebung verändert und weil seine Grenzen erst im Feld vollständig sichtbar werden. Die PAS verlangt deshalb eine kontinuierliche Absicherung während des Betriebs: Monitoring des Systemverhaltens, Rückführung von Feld-Beobachtungen in Datensätze und Tests sowie die Pflege des Sicherheitsarguments über Änderungen hinweg, etwa bei Updates. Das Sicherheitsargument wird damit zu einem lebenden Arbeitsprodukt. Wer heute Release-Prozesse und Änderungsmanagement nach Automotive SPICE (ASPICE) betreibt, erkennt das Muster; neu ist, dass Datenstand und Modellstand denselben disziplinierten Umgang brauchen wie Code-Stände.

ISO 26262, ISO 21448 und ISO PAS 8800 im Vergleich

Die drei Dokumente konkurrieren nicht, sie beantworten unterschiedliche Fragen an dasselbe System. Die Kurzfassung für das nächste Kundengespräch:

In der Praxis wird ein KI-basiertes System im Fahrzeug entlang aller drei Quellen abgesichert: ISO 26262 bleibt die Grundlage, SOTIF behandelt die Leistungsgrenzen der beabsichtigten Funktion, und die PAS liefert Vokabular und Lebenszyklus für den KI-Anteil.

Abgrenzung zum EU AI Act: Regulierung und technischer Standard

Neben der Norm-Landschaft steht die regulatorische. Die Verordnung (EU) 2024/1689, die KI-Verordnung der EU, ist ein Rechtsakt: horizontal, risikobasiert, mit Pflichten je Risikoklasse und mit der seit Februar 2025 geltenden KI-Kompetenz-Pflicht für Beschäftigte nach Artikel 4. ISO/PAS 8800 ist dagegen ein technischer Standard: Sie beschreibt, wie ein Sicherheitsnachweis für KI im Fahrzeug methodisch aufgebaut wird. Ein Rechtsakt sagt, dass und wofür Nachweise zu erbringen sind; ein Standard sagt, wie der Stand der Technik dabei aussieht.

Für die Einordnung im Projekt hilft eine zweite Unterscheidung. KI-Funktionen im Fahrzeug berühren die Fahrzeugsicherheit und laufen regulatorisch über das sektorale Typgenehmigungsregime; hier ist die PAS der fachliche Referenzpunkt. Werkzeug-KI im Engineering ist dagegen in der Regel keine Hochrisiko-KI im Sinne von Anhang III der KI-Verordnung, wobei die Einstufung je Anwendung zu prüfen bleibt. Es wäre also doppelt falsch, eine Coding-Assistenz mit Verweis auf ISO/PAS 8800 zu problematisieren: Sie liegt außerhalb des PAS-Geltungsbereichs, und ihre regulatorische Behandlung folgt eigenen, deutlich schlankeren Regeln.

Was Teams heute vorbereiten können

Viele Entwicklungsbereiche liefern noch keine KI-Funktion ins Fahrzeug aus und werden trotzdem gefragt, wie sie zu der PAS stehen. Die ehrliche Antwort darf lauten: Wir liefern heute keine KI im Produkt, und wir haben die Grundlagen vorbereitet, auf denen ein PAS-konformes Vorhaben aufsetzen würde. Vier Bausteine tragen diese Antwort.

Daten-Governance und Modell-Dokumentation

Der erste Baustein ist eine geordnete Datenhaltung: versionierte Datensätze mit dokumentierter Herkunft, geregelten Zugriffsrechten und beschriebenen Lücken. Wer heute Messdaten, Log-Daten oder Annotationsbestände pflegt, kann diese Ordnung einführen, lange bevor ein Modell trainiert wird. Der zweite Baustein ist eine Dokumentationsroutine für Modelle, auch für interne Piloten: Zweck, Trainingsdatenstand, bekannte Grenzen, Bewertungsmetriken und Verantwortliche.

Monitoring-Konzepte und Nachweisstruktur

Der dritte Baustein ist ein Monitoring-Konzept: Welche Signale würden im Betrieb beobachtet, wie werden Auffälligkeiten protokolliert, wer entscheidet über Reaktionen und Rückholwege. Der vierte ist die Nachweisstruktur, und hier zahlt bestehende Arbeit direkt ein: Wer Traceability von der Anforderung bis zum Testergebnis sauber führt, verlängert dieselbe Kette später um Datensatz- und Modellstände. Wie eine solche Evidenzkette aufgebaut wird, beschreibt der Beitrag zu Traceability und Evidenz für KI-Arbeitsergebnisse; wie KI-gestützte Testfälle vor einem Assessment bestehen, zeigt der Beitrag zur Nachweisführung für KI-Testfälle nach ISO 26262. Über Personen oder deren Leistung trifft dieser Beitrag keine Aussage.

Nächste Schritte

Ob und wann ISO/PAS 8800 für ein konkretes Projekt relevant wird, hängt an einer einzigen Frage: Wird eine gelernte Funktion Teil des ausgelieferten Fahrzeugs, oder bleibt die KI im Werkzeugkasten des Engineering. Der Einstieg sieht so aus:

1. Werkzeug-Ebene klären: Der Überblick zur KI in der Automotive-Softwareentwicklung zeigt, welche Einsatzfelder heute tragen und welcher Freigabepfad zu jedem gehört.
2. Vorgehen prüfen: Die Seite zur AI-Transformation im Automotive Engineering beschreibt, wie aus Einzelbausteinen ein geführtes Transformationsvorhaben mit Nachweisstruktur wird.
3. Gespräch vereinbaren: In einem Qualifying-Call klären wir, ob Scope, Toolchain und Ausgangslage Ihres Projekts zum Vorgehen passen.

Häufige Fragen

Die folgenden Antworten fassen die Einordnung von sensified zu ISO/PAS 8800:2024 zusammen. Sie beruhen auf dem veröffentlichten Geltungsbereich der Spezifikation und auf typisierten Projekterfahrungen, die je Kunde und Toolchain zu prüfen sind.

Was regelt ISO PAS 8800 und was bedeutet sie für Entwicklungsteams?

ISO/PAS 8800:2024 regelt die Sicherheit KI-basierter Funktionen in Serien-Straßenfahrzeugen. Sie definiert einen KI-Sicherheitslebenszyklus über Daten, Modell und Betrieb und beschreibt Eigenschaften wie Robustheit und Generalisierung, aus denen ein Sicherheitsargument aufgebaut wird. Für Entwicklungsteams bedeutet sie: Sobald eine gelernte Funktion ins Fahrzeug ausgeliefert wird, brauchen Datensätze, Modellstände und Betriebs-Monitoring denselben disziplinierten Umgang wie Code-Stände.

Ist ISO PAS 8800 verpflichtend?

Als technischer Standard ist die PAS selbst kein Gesetz. Verbindlich wird sie auf zwei Wegen: über Kundenverträge und Lastenhefte, die sie als Referenz nennen, und über ihre Rolle als Stand der Technik, an dem sich Sicherheitsnachweise messen lassen. Wer KI-Funktionen ins Fahrzeug bringt, sollte deshalb damit rechnen, dass Kunden und Prüfinstanzen Nachweise entlang ihrer Logik erwarten.

Ersetzt ISO PAS 8800 die ISO 26262 oder ISO 21448?

Nein. Die funktionale Sicherheit nach ISO 26262 bleibt die Grundlage für E/E-Systeme, ISO 21448 (SOTIF) behandelt die Leistungsgrenzen der beabsichtigten Funktion. ISO/PAS 8800 erweitert beide um den KI-Anteil: Sie liefert Vokabular, Lebenszyklus und Nachweislogik für gelernte Funktionen, damit die etablierten Normen auch dort tragfähig bleiben.

Fällt Coding-Assistenz im Engineering unter ISO PAS 8800?

Nein. Der Geltungsbereich der PAS stellt klar, dass sie keine spezifischen Leitlinien für Software-Werkzeuge mit KI-Methoden liefert. Coding-Assistenz, Requirements-Prüfung oder Doku-Abfragen sind Werkzeug-KI und laufen über die Tool-Vertrauensbetrachtung nach ISO 26262 sowie einen definierten Freigabepfad je Einsatzfeld. Die PAS greift erst, wenn eine KI-Funktion Teil des ausgelieferten Fahrzeugs wird.

Wie unterscheidet sich ISO PAS 8800 vom EU AI Act?

Die KI-Verordnung (EU) 2024/1689 ist ein Rechtsakt mit risikobasierten Pflichten, die PAS ein technischer Standard mit Methodik für den Sicherheitsnachweis. Der Rechtsakt bestimmt, dass und wofür Nachweise nötig sind; der Standard beschreibt, wie der Stand der Technik dabei aussieht. Engineering-Werkzeuge sind zudem in der Regel keine Hochrisiko-KI im Sinne von Anhang III; die Einstufung bleibt je Anwendung zu prüfen.

Was können Teams heute vorbereiten, auch ohne KI im Fahrzeug?

Vier Bausteine: geordnete Daten-Governance mit Versionierung und dokumentierter Herkunft, eine Dokumentationsroutine für Modelle inklusive Grenzen und Metriken, ein Monitoring-Konzept mit Zuständigkeiten und Rückholwegen sowie eine Nachweisstruktur, die die bestehende Traceability später um Datensatz- und Modellstände verlängert. Alle vier sind auch unabhängig von der PAS gute Ingenieurspraxis und deutlich günstiger, solange die Bestände klein sind.

Wird aus der PAS eine vollwertige ISO-Norm?

Eine Publicly Available Specification hat eine begrenzte Laufzeit und wird turnusmäßig überprüft; am Ende kann die Überführung in eine internationale Norm stehen. Einzelne Inhalte können sich dabei noch verschieben. Die Grundlogik aus Lebenszyklus, Datenbehandlung und Sicherheitsargument gilt aber bereits heute als Referenzpunkt für Kunden und Prüfinstanzen.