ISO/PAS 8800-Konformität: Wie Automobilteams die Sicherheit von KI durch kontinuierliche Tests validieren können

ISO/PAS 8800 ist die neue Automobilnorm für KI-Sicherheit. Was bedeutet das für Ihr Automobilteam? Erfahren Sie, warum zuverlässige C/C++-Software rund um das KI-Modell wichtiger denn je ist. Lernen Sie, wie kontinuierliches Testen einen glaubwürdigen, auditfähigen Sicherheitsnachweis für KI-fähige Fahrzeuge liefert.

Was ist ISO/PAS 8800?

ISO/PAS 8800 ist eine neue, öffentlich verfügbare Spezifikation (PAS) mit Fokus auf die Sicherheit KI-gestützter Systeme in Straßenfahrzeugen. Sie befasst sich mit den Herausforderungen des maschinellen Lernens (ML) und KI-basierter Entscheidungsfindung, insbesondere dort, wo das Verhalten von Daten, Umgebungsbedingungen und nichtdeterministischen Ergebnissen abhängt. Sie ersetzt weder ISO 26262 (Funktionale Sicherheit) noch ISO 21448 (SOTIF), sondern erweitert diese um KI-spezifische Risiken.

Wie KI das Sicherheitsmodell verändert

Die traditionelle Fahrzeugverifizierung ging von deterministischem Verhalten aus: korrekte Logik + erwartete Bedingungen = sicheres Ergebnis. KI durchbricht dieses Modell. Ein KI-System kann exakt wie geplant funktionieren und dennoch unsicher sein, weil:

• Die Trainingsdaten waren unvollständig oder verzerrt.
• Seltene Grenzfälle wurden nicht berücksichtigt.
• Die Umweltbedingungen haben sich geändert, zum Beispiel ist es jetzt Nacht, es herrscht Nebel oder es gibt neue Bauarbeiten.
• Das Modell ließ sich in der Praxis nicht korrekt verallgemeinern.

Dadurch verlagert sich der Fokus der Sicherheit von der Überprüfung der Korrektheit der Software hin zur kontinuierlichen Validierung des Systemverhaltens unter Unsicherheit.

Was der Standard über den gesamten KI-Lebenszyklus hinweg abdeckt

ISO/PAS 8800 deckt den gesamten Lebenszyklus von KI ab, aber sein Umfang ist bewusst gewählt.

Im Visier

KI-Systeme in Serienfahrzeugen wie Pkw und Lkw, bei denen KI Auswirkungen auf die Sicherheit hat, umfassen auch externe KI-Systeme, beispielsweise cloudbasierte Wahrnehmungssysteme für intelligente Kreuzungen, die die Fahrzeugsicherheit beeinflussen.

Außerhalb des Geltungsbereichs

Die Behauptung, KI könne vollkommen sicher sein, ist falsch. Ziel ist es, das KI-bezogene Risiko im Rahmen eines umfassenderen Systemsicherheitskonzepts auf ein akzeptables Niveau zu reduzieren.

Schlüssel Nachricht

Die Sicherheit von KI ist ein Problem auf Systemebene, keine Eigenschaft eines einzelnen Modells.

Warum dies für die Sicherheit von KI-Systemen in der Automobilindustrie wichtig ist

Künstliche Intelligenz birgt Risiken, für deren Bewältigung herkömmliche Sicherheitsverfahren in der Automobilindustrie ursprünglich nicht konzipiert wurden. Hier einige Beispiele:

• Ein ADAS-Wahrnehmungssystem erkennt einen Fußgänger nachts möglicherweise nicht, weil nächtliche Bedingungen in den Trainingsdaten unterrepräsentiert waren.
• Ein Fahrspurerkennungsmodell kann Schatten oder Baustellenmarkierungen falsch interpretieren.
• Falsch-positive Ergebnisse können unnötige Bremsvorgänge auslösen.
• Falsch-negative Ergebnisse können dazu führen, dass Gefahren gar nicht erkannt werden.

Dies sind keine herkömmlichen Softwarefehler. Die Software kann einwandfrei funktionieren, während das KI-System dennoch unsicher agiert. Genau das unterscheidet KI grundlegend.

KI-Systeme sind:

• Datenabhängig
• Kontextsensitiv
• Nicht deterministisch
• Stark beeinflusst von betrieblicher Variabilität

Da automobile Systeme zunehmend softwaredefiniert und KI-gesteuert werden, müssen Unternehmen über die deterministische Verifikation hinausgehen und kontinuierliche Validierungsstrategien einführen, die in der Lage sind, das Systemverhalten unter Unsicherheit zu bewerten.

Der Wandel von Softwarefehlern zu KI-Unzulänglichkeit

Derzeit wird der Wandel von Softwarefehlern hin zu KI-Unzulänglichkeiten zwar implizit angenommen, aber nicht explizit als grundlegendes Konzept benannt. Dies ist wohl der wichtigste Gedanke in ISO/PAS 8800.

Eines der wichtigsten Konzepte in ISO/PAS 8800 ist die Unterscheidung zwischen traditionellen Fehlern und KI-Unzulänglichkeit.

• Typische Fehlerquellen sind beispielsweise ein gebrochenes Zahnrad, ein Logikfehler oder eine Speicherbeschädigung. Die Komponente ist defekt und muss repariert werden.
• Ein KI-Mangel könnte beispielsweise eine Karte mit fehlenden Straßen sein. Die Karte (das Modell) funktioniert zwar korrekt, aber wenn das Fahrzeug auf eine fehlende Straße trifft, kann dies gefährliche Folgen haben.

Ein ML-Modell kann technisch korrekt funktionieren, aber unsichere Ergebnisse liefern, weil es kein ausreichendes Verständnis der realen Welt besitzt.

KI-Systeme bergen eine andere Art von Risiko: Unzulänglichkeit.

Ein Modell des maschinellen Lernens kann technisch korrekt funktionieren und dennoch unsichere Ergebnisse liefern, weil es die reale Welt nicht ausreichend versteht. Hier einige Beispiele.

• Ein Wahrnehmungssystem kann Objekte bei ungewöhnlichen Wetterbedingungen falsch klassifizieren.
• Ein autonomes System erkennt möglicherweise seltene Verkehrssituationen nicht, denen es während des Trainings nie begegnet ist.
• Ein KI-Modell kann außerhalb seines erwarteten Einsatzbereichs fehlerhaft generalisieren.

Dies ist kein Fehler in der Codeausführung, sondern eine Einschränkung des erlernten Verhaltens. Diese Unterscheidung verändert die Art und Weise, wie Sicherheit konzipiert werden muss.

Teams müssen Folgendes bestätigen:

• Repräsentativität des Datensatzes
• Abdeckung von Grenzfällen
• Umweltvielfalt
• Verhaltensrobustheit
• Betriebsgrenzen

Mit anderen Worten: Bei der Sicherheit von KI im Automobilbereich geht es weniger darum zu beweisen, dass Software niemals versagt, sondern vielmehr darum zu verstehen, wo KI möglicherweise unzureichend ist.

KI-Systeme gehen über das Modell hinaus

KI ist nicht nur ein Modell. Sie ist Teil eines größeren Systems. Im Folgenden wird erläutert, dass ein KI-System typischerweise Folgendes umfasst:

• Vorverarbeitung, wie z. B. Sensoraufbereitung und Datenvorbereitung
• Das KI-Modell – Schlussfolgerung und Entscheidungsfindung
• Nachbearbeitung, einschließlich Validierung, Plausibilitätsprüfungen und Sicherheitskontrollen

Dies wird dazu beitragen, die Diskussion auf reale Systemdesigns zu stützen und sie besser mit Tests, Validierung und den Sicherheitsvorkehrungen von C/C++ zu verknüpfen.

Ein häufiges Missverständnis bei der Entwicklung von KI in der Automobilindustrie besteht darin, das KI-Modell als das System selbst zu betrachten. ISO/PAS 8800 stellt klar, dass KI nicht nur das Modell ist, sondern Teil einer umfassenderen Betriebsarchitektur.

Ein KI-gestütztes Automobilsystem umfasst typischerweise:

1. KI-Vorverarbeitung. Bereitet Sensordaten auf und konditioniert sie, beispielsweise durch Normalisierung von Bildern und Filterung von LiDAR-Rauschen.
2. Das KI-Modell. Bearbeitet grundlegende Schlussfolgerungen oder Entscheidungsprozesse, wie neuronale Netze und Entscheidungsbäume.
3. KI-Nachbearbeitung. Es validiert Ausgaben, führt Plausibilitätsprüfungen durch und setzt Sicherheitskontrollen durch. Hier sind häufig die deterministischen Schutzmechanismen von C/C++ verankert.

Diese Architektur ist wichtig, weil das Modell selten allein die Sicherheit bestimmt, zum Beispiel:

• Die Konditionierung der Sensoren beeinflusst die Genauigkeit der Wahrnehmung.
• Die Nachbearbeitungslogik kann unplausible Ausgaben ablehnen.
• Die Laufzeitüberwachung kann eine verminderte Zuverlässigkeit erkennen.
• Deterministische C/C++-Schutzmechanismen können unsicheres Verhalten außer Kraft setzen.

Hier bleibt eingebettete Software von entscheidender Bedeutung. KI mag zwar Entscheidungen treffen, aber herkömmliche Automobilsoftware steuert weiterhin, wie diese Entscheidungen validiert, eingeschränkt und umgesetzt werden.

Die Sicherheit hängt daher von der Validierung der gesamten Pipeline ab, nicht nur von der Genauigkeit des Modells.

Wie ISO/PAS 8800 mit ISO 26262 und SOTIF zusammenhängt

ISO/PAS 8800 ersetzt weder ISO 26262 noch ISO 21448 (SOTIF). Vielmehr erweitert es bestehende Rahmenwerke für die Fahrzeugsicherheit, um KI-spezifische Risiken zu adressieren.

Jeder Standard konzentriert sich auf eine andere Dimension der Fahrzeugsicherheit.

• ISO 26262 befasst sich mit Ausfällen in elektrischen und elektronischen Systemen.
• SOTIF konzentriert sich auf Gefahren, die aus einer unzureichenden beabsichtigten Funktionalität resultieren.
• ISO/PAS 8800 befasst sich speziell mit KI-bedingten Risiken wie Nichtdeterminismus, Datenunzulänglichkeit und Verhaltensunsicherheit.

Zusammen bilden diese Standards einen umfassenderen Sicherheitsrahmen für moderne KI-fähige Fahrzeuge.

Der entscheidende Unterschied besteht darin, dass ISO/PAS 8800 die Sicherheitstechnik über die deterministische Fehleranalyse hinaus auf die kontinuierliche Validierung des KI-Verhaltens und die Systemsicherheit ausweitet.

ISO 26262 vs. SOTIF vs. ISO/PAS 8800: Unterschiede und Zusammenhänge

Wie sie zusammenhängen:

• ISO/PAS 8800 baut auf ISO 26262 und SOTIF auf. Es ersetzt diese nicht.
• Wenn eine Komponente kein KI-Modell besitzt, funktioniert ISO 26262 unverändert.
• Sobald ein KI-Modell zum Einsatz kommt, reicht ISO 26262 allein nicht mehr aus. ISO/PAS 8800 schließt die Lücken für datengetriebenes, nichtdeterministisches Verhalten.

Welche Änderungen bringt ISO/PAS 8800 für Softwaretestteams mit sich?

ISO/PAS 8800 verändert die Rolle von Softwaretestteams grundlegend. Tests beschränken sich nicht mehr auf die Überprüfung deterministischer Softwarefunktionen. Teams müssen nun nachweisen, dass KI-gestützte Systeme auch unter Unsicherheit, Variation und unvollständigen Informationen sicher funktionieren.

Dies verschiebt den Testansatz hin zu:

• Kontinuierliche Überprüfung
• Laufzeitvalidierung
• Abdeckung über die Codeausführung hinaus.
• Vernetzte Rückverfolgbarkeits-Workflows
• Verhaltensrobustheitstests
• Beweiserhebung für Zusicherungsargumente

Tests werden zu einem zentralen Bestandteil des Nachweises der Sicherheitsbereitschaft von KI und nicht nur der Validierung der korrekten Implementierung.

KI-spezifische Risiken, die herkömmliche Testverfahren übersehen können

Traditionelle Softwaretests gehen von vorhersehbarem Verhalten aus. KI-Systeme verhalten sich nicht auf dieselbe Weise vorhersehbar. Das Verhalten von KI kann sich aus folgenden Gründen ändern:

• Verteilung der Trainingsdaten
• Umweltbedingungen
• Sensorqualität
• Grenzfall-Eingaben
• Konfidenzschwellen

Daher können Systeme herkömmliche Tests bestehen, obwohl sie sich unter seltenen oder unerwarteten Bedingungen unsicher verhalten. Aus diesem Grund müssen die Teams in der Automobilindustrie die Verifizierung erweitern und Folgendes umfassen:

• Validierung von Grenzfällen
• Robustheitsprüfung
• Adversarial-Tests
• Szenarioabdeckungsanalyse
• Driftüberwachung
• Vertrauensbasierte Bewertung

Ohne diese Praktiken könnten wichtige KI-Risiken bis zum Einsatz unsichtbar bleiben.

Anforderungen, Validierung, Abdeckung und Überwachungsaspekte

Die ISO/PAS 8800-Konformität hängt von der Aufrechterhaltung eines durchgängigen Nachweisnetzwerks während des gesamten Entwicklungslebenszyklus ab.

Organisationen müssen Folgendes nachweisen können.

• Anforderungen im Zusammenhang mit Testfällen
• Validierungsergebnisse im Zusammenhang mit Sicherheitszielen
• Belege für die Vollständigkeit der Abdeckung
• Überwachungsdaten, die das Betriebsverhalten widerspiegeln
• Überprüfung der Historie und der Risikominderungsmaßnahmen

Dies erfordert die Rückverfolgbarkeit von Software, KI-Modellen, Datensätzen, Tests und betrieblichen Nachweisen.

Fragmentierte Arbeitsabläufe und unzusammenhängende Tools machen es extrem schwierig, dies konsequent zu erreichen.

Nachweis der KI-Sicherheit durch Rückverfolgbarkeits- und Konformitätsnachweise

Die Sicherheit von KI lässt sich nicht allein durch Genauigkeitsmetriken belegen. Selbst ein hochpräzises Modell kann in seltenen, aber betriebskritischen Szenarien katastrophal versagen. Daher betont ISO/PAS 8800 strukturierte Sicherheitsnachweise, die durch nachvollziehbare Belege gestützt werden.

Ein Zusicherungsargument kombiniert:

• Sicherheitsbehauptungen
• Belege
• Ingenieurslogik

Das beinhaltet:

• Analyse der Datensatzabdeckung
• Robustheitsprüfung
• Laufzeitschutz
• Deterministische Softwaresteuerungen
• Überwachung und operative Rückmeldung

Sicherheit wird zu einem kontinuierlich gestützten technischen Argument und nicht zu einem einmaligen Validierungsmeilenstein, der mit „bestanden/nicht bestanden“ bewertet wird.

Welche prüfungsfähigen Nachweise sollten enthalten sein?

Auditfähige Nachweise gemäß ISO/PAS 8800 sind kein statischer Ordner, der eine Woche vor der Prüfung zusammengestellt wird. Es handelt sich vielmehr um eine dynamische Nachweiskette, die sich kontinuierlich parallel zu Ihrem KI-System weiterentwickelt. Für jede Sicherheitsaussage – beispielsweise „Die Spurhaltehilfe wird ausgelöst, wenn die Modellzuverlässigkeit unter 0.7 fällt“ – müssen Sie zusammenhängende Artefakte vorlegen können, die sowohl die Absicht als auch die Umsetzung belegen.

Die für die Prüfung geeigneten Nachweise sollten zumindest folgende Zusammenhänge herstellen:

• Anforderungen. Rückverfolgbar von fahrzeugspezifischen Sicherheitszielen bis hin zu KI-spezifischen Anforderungen, zum Beispiel „Wahrscheinlichkeit einer Fehlerkennung von Fußgängern < 1e-6 pro Stunde“ gemäß Klausel 9.
• Ergebnisse der statischen Analyse. Berichte, die die Durchsetzung von Codierungsstandards wie MISRA und AUTOSAR für alle C/C++-Leitlinien belegen, wobei Ausnahmen gerechtfertigt sind.
• Ergebnisse der Unit- und Integrationstests. Nachweise dafür, dass deterministische Softwarekomponenten wie Plausibilitätsprüfungen und Fallback-Logik sich unter normalen Bedingungen und unter Fehlereinspeisung wie erwartet verhalten.
• Regressionstestverlauf. Ein Nachweis, dass bei jeder Code- oder Modelländerung die sicherheitskritischen Pfade einschließlich der Abdeckungsänderungen erneut überprüft wurden.
• Berichterstattung. Bieten Sie eine strukturelle Abdeckung, einschließlich Anweisungs-, Zweig- und MC/DC-Abdeckung, für Software-Schutzmechanismen sowie Metriken zur Szenarioabdeckung für das KI-Verhalten, zum Beispiel den Prozentsatz der ausgeführten definierten Szenarien der Betriebsdomäne.
• Mängel und Korrekturmaßnahmen. Erfassung von etwaigen Mängeln der KI oder Softwarefehlern, einschließlich Ursachenanalyse gemäß Klausel 13 und Nachweis der Behebung.
• Risikobewertungen. Dokumentation der Gefahrenanalyse, der Auslösebedingungsanalyse und der STPA/STAMP-Ausgaben für KI-spezifische Risiken.
• Arbeitsabläufe überprüfen. Freigaben, unabhängige Überprüfungen und Governance-Dokumente, die die menschliche Aufsicht über sicherheitskritische Entscheidungen belegen.

Kernpunkt: Diese Nachweise müssen während des gesamten Lebenszyklus kontinuierlich aktualisiert und nachvollziehbar sein – und dürfen nicht erst am Ende der Entwicklung manuell zusammengestellt werden. Automatisierte Toolchains, einschließlich statischer Analyse, Unit-Test-Runnern, Abdeckungstools und Rückverfolgbarkeitsmatrizen, sind die einzige praktikable Möglichkeit, diese dynamischen Nachweise in großem Umfang zu gewährleisten.

Häufige Lücken, die ein Risiko für die ISO/PAS 8800-Bereitschaft darstellen

Selbst Teams mit fundierten Kenntnissen im Bereich funktionale Sicherheit (ISO 26262) können auf KI-spezifische Lücken in ihrer Vorbereitung stoßen. Basierend auf Branchenbeobachtungen und den expliziten Anforderungen der Norm sind im Folgenden die häufigsten Schwachstellen aufgeführt.

Häufige Lücken

• Nicht miteinander verbundene Testwerkzeuge und manuelle Berichterstellung. Wenn statische Analysen, Komponententests, Abdeckungstests und Simulationstools keine Daten austauschen, verschwenden Ingenieure Wochen damit, Beweise manuell zusammenzutragen. Auditoren decken Lücken in der Rückverfolgbarkeit auf.
• Schwache Nachvollziehbarkeit der Anforderungen. Fehlende Verbindungen zwischen fahrzeugbezogenen Sicherheitsanforderungen, KI-Sicherheitsanforderungen, Datensatzversionen, Testfällen, Leitplankenvorschriften und Abdeckungsergebnissen. Ohne diese Verbindungen lässt sich die Frage „Wodurch wird die Erfüllung dieser Anforderung belegt?“ nicht beantworten.
• Unvollständige strukturelle Abdeckung. Teams erreichen möglicherweise eine 100%ige Abdeckung der Schutzmaßnahmen, übersehen dabei aber kritische Verzweigungen oder MC/DC-Abdeckungen, wodurch unsichere Pfade ungenutzt bleiben. Die Verifizierungsziele von Klausel 12 können mit einer nur teilweisen Abdeckung nicht erreicht werden.
• Die Behandlung von Datensätzen als informelle, unstrukturierte Artefakte. Das Versäumnis, Datensätze zu versionieren, Kennzeichnungsfehler zu verfolgen oder die Rückverfolgbarkeit von Datensatzlücken – wie beispielsweise fehlenden Nachtszenen – zu Testfällen oder Abhilfemaßnahmen zu gewährleisten, verstößt gegen die Anforderungen an den Datensatzlebenszyklus gemäß Klausel 11.
• Schlechte Transparenz hinsichtlich des KI-Validierungsstatus. Den Teams fehlt ein Dashboard, das anzeigt, welche Sicherheitsanforderungen durch Simulationen validiert wurden, welche Grenzfälle noch ungetestet sind und ob die Laufzeitüberwachung im Feld verifiziert wurde. Dies führt zu einem falschen Sicherheitsgefühl vor der Bereitstellung.

Schnelle Abhilfemaßnahmen zur Schließung der Lücken

1. Bewerten Sie die aktuellen Sicherheitsabläufe. Ordnen Sie Ihre bestehenden Verifizierungs- und Validierungsprozesse dem ISO/PAS 8800-Lebenszyklus zu. Identifizieren Sie, wo KI neue Aktivitäten wie Datensatzverwaltung, Robustheitstests und Laufzeitüberwachung einführt.
2. Behandeln Sie Daten als ein Gut. Implementieren Sie einen strukturierten Datensatzlebenszyklus mit Versionierung, Rückverfolgbarkeit zu Sicherheitsanforderungen und regelmäßiger Gap-Analyse gemäß Klausel 11.
3. Die Rückverfolgbarkeit verbessern. Verbinden Sie Gefahren → Anforderungen → Datensätze → Tests → Leitplanken-Code → Abdeckung → Feldvorfälle. Automatisieren Sie so viel wie möglich davon.
4. Automatisierte, wiederholbare Tests. Integrieren Sie statische Analysen, Unit-Tests und Testabdeckung in CI/CD. Führen Sie Regressionstests bei jeder Änderung am KI-Modell oder der zugehörigen Software durch.
5. Errichte deterministische Leitplanken. Stellen Sie sicher, dass die gesamte C/C++-Software rund um die KI – Plausibilitätsprüfungen, Vertrauensüberwachungen, Ausweichlogik – mittels struktureller Abdeckung und Fehlereinspeisung verifiziert wird.
6. Implementierung im Rahmen der Feldüberwachung. Setzen Sie Laufzeitmonitore ein, die Eingaben außerhalb der Verteilung, Vertrauensverluste und ausgelöste Fallbacks protokollieren. Nutzen Sie diese Daten, um die Anforderungen zu verfeinern und gemäß Abschnitt 14 neue Testszenarien hinzuzufügen.

Wie man ISO/PAS 8800 im Entwicklungslebenszyklus operationalisiert

Die ISO/PAS 8800-Konformität lässt sich nicht allein durch Dokumentation erreichen. Ein Ordner voller Prozesse, die niemand befolgt, wird einer Prüfung nicht standhalten und auch kein sicheres Fahrzeug hervorbringen. Der Fokus der Norm auf die kontinuierliche Erfassung von Nachweisen bedeutet, dass Sicherheit integraler Bestandteil der täglichen Entwicklungsabläufe werden muss.

Die erfolgreichsten Organisationen setzen die Sicherheit von KI um, indem sie die folgenden Praktiken in ihren Entwicklungslebenszyklus integrieren.

• Shift-Left-Testing. KI-Mängel und Softwarefehler so früh wie möglich erkennen, beginnend am Arbeitsplatz des Entwicklers.
• CI/CD-Automatisierung. Automatische Ausführung von statischer Analyse, Unit-Tests, Abdeckungsanalyse und Simulationsszenarien bei jedem Commit oder nächtlichen Build.
• Kontinuierliche Regressionstests. Überprüfen Sie erneut, ob Änderungen am KI-Modell, am Datensatz oder am Leitplankencode bestehende Sicherheitseigenschaften beeinträchtigen.
• Automatisierte Rückverfolgbarkeit. Nutzen Sie Tools, um Live-Verknüpfungen von Anforderungen über Tests bis hin zu Ergebnissen aufrechtzuerhalten und so manuelle Matrixaktualisierungen zu vermeiden.
• Kontinuierliche Rückkopplungsschleifen. Felddaten (Überwachungsprotokolle, Anomalien) werden in Testsuiten und Datensatzanforderungen zurückgeführt, wodurch der Kreislauf zwischen Betrieb und Entwicklung geschlossen wird.

Dadurch wird die KI-Sicherheit von einer reaktiven Aktivität – Tests kurz vor der Veröffentlichung, hektische Suche nach Beweisen zum Zeitpunkt der Prüfung – in eine kontinuierliche Entwicklungskompetenz umgewandelt, die mit der Komplexität Ihres Systems skaliert.

Shift-Left-Testing und CI/CD-Integration

Bei der traditionellen V-Modell-Entwicklung erfolgt das Testen erst spät, oft nachdem das KI-Modell trainiert und integriert wurde. Wenn dann eine Schwäche der KI festgestellt wird, beispielsweise ein Fußgängerdetektor, der bei Schnee versagt, kann dies ein erneutes Training des Modells, eine erneute Validierung der Datensätze und eine Rezertifizierung des gesamten Systems erforderlich machen.

Das ist teuer und langsam.

Shift-Left-Testing verlagert Verifizierungsaktivitäten in frühere Phasen des Produktlebenszyklus, wo Probleme kostengünstiger zu beheben sind. Für ISO/PAS 8800 bedeutet dies:

• Statische Analyse. Bei jedem Entwickler-Commit ausgeführt, um Verstöße gegen Codierungsstandards wie MISRA und AUTOSAR im Leitplankencode zu erkennen, bevor diese zusammengeführt werden.
• Durchsetzung von Codierungsstandards. Setzen Sie automatisierte Prüfmechanismen ein, um undefiniertes Verhalten zu verhindern, das die Sicherheitsüberwachung von KIs untergraben könnte.
• Unit Testing. Entwickler schreiben oder generieren automatisch Unit-Tests für jede deterministische Softwarekomponente. Beispielsweise eine Plausibilitätsfunktion, die unplausible KI-Ausgaben ablehnt. Diese Tests laufen in Sekundenschnelle und liefern sofortiges Feedback.
• Abdeckungsanalyse. Messen Sie die Codeabdeckung (Anweisungen, Zweige und MC/DC) im Rahmen der CI/CD-Pipeline. Der Build schlägt fehl, wenn die Abdeckung einen definierten Schwellenwert unterschreitet.

Durch die Integration dieser Funktionen in CI/CD-Pipelines wird sichergestellt, dass jede Codeänderung eine schnelle, automatisierte Sicherheitsprüfung auslöst. Bei Integration in Ihre Modelltrainingspipeline kann dasselbe CI/CD-System zudem simulationsbasierte Szenariotests erneut ausführen, sobald der Datensatz oder das Modell aktualisiert wird.

Das Ergebnis? Überraschungen bei Audits in der Spätphase werden drastisch reduziert, da Nachweise – wie Testergebnisse, Abdeckungsberichte und statische Analyseprotokolle – kontinuierlich und nicht erst in der Nacht vor der Prüfung generiert werden.

Kontinuierliche Verifizierung, Regressionstests und Feedbackschleifen

KI-Systeme sind nicht statisch. Modelle werden anhand neuer Daten neu trainiert. Ihre Einsatzgebiete erweitern sich – ein Beispiel hierfür ist die Ausweitung vom Autobahn- auf den Stadtverkehr.

Die Sensoreigenschaften verändern sich mit der Zeit. Ohne kontinuierliche Überprüfung kann ein System, das im Januar die Validierung bestanden hat, im Juni unsicher sein – selbst wenn der Code nicht absichtlich geändert wurde.

ISO/PAS 8800 trägt dem durch seinen iterativen Lebenszyklus in Abschnitt 7 und die operativen Maßnahmen in Abschnitt 14 Rechnung. Konkret müssen Organisationen kontinuierlich:

• Modelle neu validieren. Nach jedem erneuten Training sollte die gesamte Reihe der szenariobasierten Tests, einschließlich Grenzfällen und adversariellen Beispielen, erneut durchgeführt werden, um sicherzustellen, dass es zu keiner Regression im sicherheitskritischen Verhalten kommt.
• Führe Regressionstests durch. Führen Sie alle automatisierten Unit-, Integrations- und Systemtests für die Leitplankensoftware durch. Die Abdeckungsanalyse muss bestätigen, dass kein sicherheitskritischer Pfad unbeabsichtigt verändert wurde.
• Abdeckung analysieren. Verfolgen Sie die strukturelle Abdeckung im Zeitverlauf. Ein Rückgang der MC/DC-Abdeckung bei einer Ausweichfunktion ist ein Warnsignal, das einer Untersuchung bedarf.
• Überwachen Sie das Laufzeitverhalten. Bei Feldmonitoren (Abschnitt 14) werden Daten aus der Praxis erfasst, wie z. B. Modellvertrauenswerte, Eingaben außerhalb der Verteilung und ausgelöste Ausweichmechanismen. Dies dient nicht nur der Fehlersuche, sondern ist auch ein Sicherheitsnachweis.
• Operative Erkenntnisse fließen zurück in die Entwicklung. Erkennt ein Monitor ein neues Szenario, beispielsweise eine neue Art von Straßenmarkierung, wird dieses Szenario Ihrer Testbibliothek hinzugefügt. Der Datensatz wird erweitert, das Modell gegebenenfalls neu trainiert und das Sicherheitsargument aktualisiert.

Dadurch entsteht ein wiederholbarer Qualitätssicherungsrahmen, der mit KI-gestützten Automobilsystemen skalierbar ist. Sicherheit wird so von einem einmaligen Zertifizierungsmeilenstein zu einer kontinuierlichen, geschlossenen Entwicklungsdisziplin.

Wie automatisierte C/C++-Tests die ISO/PAS 8800-Konformität unterstützen

Automatisierte C/C++-Testlösungen sind nicht nur praktisch, sondern unerlässlich für die Skalierung der von ISO/PAS 8800 geforderten Verifizierungsaktivitäten. KI-Modelle bergen zwar neue Risiken wie Datenmangel und fehlerhafte Generalisierung, doch die sie umgebende deterministische Software – die Schutzmechanismen, Überwachungsmechanismen und Ausweichlogik – muss höchsten funktionalen Sicherheitsstandards genügen.

So funktioniert die moderne Automatisierte Testlösungen direkte Unterstützung der ISO/PAS 8800-Konformität:

• Durchsetzung von Codierungsstandards. KI-gestützte Systeme basieren weiterhin auf Millionen Zeilen C/C++-Code. Die Einhaltung von Standards wie MISRA, AUTOSAR oder CERT verhindert undefiniertes Verhalten, das die Sicherheitsmechanismen der KI gefährden könnte. Statische Analysen erkennen Verstöße frühzeitig, bevor sie sich auf sicherheitskritische Pfade auswirken.
• Strukturelle Abdeckungsanalyse. Man kann die Wirksamkeit von Software-Schutzmechanismen nicht nachweisen, wenn man nicht weiß, welcher Code ausgeführt wurde. Die Abdeckungsanalyse (Anweisungs-, Zweig-, MC/DC-Abdeckung) liefert objektive Belege dafür, dass die Tests die Software umfassend geprüft haben – unerlässlich für jede Sicherheitsprüfung gemäß ISO 26262 und ISO/PAS 8800.
• Automatisierte Unit-Tests. Hunderte von KI-Schutzmechanismen sind als deterministische C/C++-Funktionen implementiert: Plausibilitätsprüfungen, Logik für Konfidenzschwellen und Fallback-Trigger. Automatisierte Unit-Test-Frameworks wie GoogleTest mit automatischer Generierung validieren diese Komponenten isoliert und decken Regressionen bei jeder Softwareänderung auf.
• Rückverfolgbarkeits-Workflows. ISO/PAS 8800 betont die Bedeutung vernetzter Nachweise. Automatisierte Tools können Anforderungen → Testfälle → Code → Abdeckungsergebnisse → Fehler verknüpfen. Ändert sich eine Sicherheitsanforderung – beispielsweise ein neuer Schwellenwert für die Fußgängererkennung –, zeigt die Rückverfolgbarkeit genau, welche Tests erneut ausgeführt werden müssen.
• Prüfungsfertige Berichterstattung. Die manuelle Zusammenstellung von Nachweisen stößt bei großem Umfang an ihre Grenzen. Automatisierte Testlösungen generieren Compliance-Dokumente in Echtzeit, darunter Testprotokolle, Abdeckungsberichte, Ergebnisse statischer Analysen und Anforderungsabdeckungsmatrizen. Dadurch wird die Auditvorbereitung von einem hektischen, panikartigen Vorgehen zu einem kontinuierlichen, nachvollziehbaren Prozess.
• Kontinuierliche Überprüfung. KI-Systeme entwickeln sich durch Nachtraining und OTA-Updates weiter. Jede Änderung am Modell oder der zugehörigen Software birgt das Risiko neuer Fehler. Durch die Integration automatisierter Tests in CI/CD-Pipelines überprüfen Teams bei jedem Commit die Sicherheitsvorkehrungen und stellen so sicher, dass Sicherheit niemals vernachlässigt wird.

Diese Tools ersetzen nicht das Urteilsvermögen von Ingenieuren, sondern ermöglichen wiederholbare und skalierbare Sicherheitsabläufe. Der Ingenieur entscheidet weiterhin, was getestet wird und wie die Ergebnisse zu interpretieren sind, aber die Automatisierung übernimmt die Datengenerierung, sodass sich die Teams auf die neuen Risiken konzentrieren können, die KI mit sich bringt.

Wo KI-gestütztes Testen sinnvoll ist und wo menschliche Aufsicht weiterhin erforderlich bleibt

KI-gestützte Entwicklungs- und Testwerkzeuge werden immer leistungsfähiger, sind aber kein Ersatz für die menschliche Verantwortung in sicherheitskritischen Systemen.

ISO/PAS 8800 schreibt KI-gestütztes Testen weder vor noch verbietet es dieses. Es fordert jedoch, dass Werkzeuge für ihren vorgesehenen Zweck validiert werden und die Gesamtargumentation zur Qualitätssicherung weiterhin stichhaltig bleibt.

Wo KI-gestütztes Testen einen Mehrwert bietet:

• Tests werden generiert. KI kann Unit-Tests, Integrationstests oder sogar szenariobasierte Tests für Simulationsumgebungen synthetisieren und so die Testabdeckung drastisch erweitern, ohne den manuellen Aufwand linear zu erhöhen.
• Beschleunigung der Deckungsschließung. Durch die Analyse unentdeckter Codepfade können KI-Tools Eingaben priorisieren oder automatisch generieren, um schwer erreichbare Zweige auszuführen.
• Identifizierung potenzieller Mängel. Maschinelles Lernen auf Basis historischer Fehlerdaten kann risikoreiche Bereiche im Quellcode vorhersagen und Teams so helfen, Überprüfungen und Tests auf die wichtigsten Bereiche zu konzentrieren.
• Steigerung der Entwicklerproduktivität. Durch die Automatisierung der routinemäßigen Testgenerierung und -analyse können Ingenieure mehr Zeit für komplexe Sicherheitsbetrachtungen und die Untersuchung von Grenzfällen aufwenden.

Aber sicherheitskritische Systeme erfordern weiterhin die menschliche Verantwortung für:

• Menschliche Überprüfung. KI-generierte Tests können fehlerhaft, unvollständig oder irreführend sein. Ein qualifizierter Ingenieur muss die Testlogik, die erwarteten Ergebnisse und die Testabdeckung überprüfen.
• Governance-Prozesse. Governance-Entscheidungen können nicht an einen Algorithmus delegiert werden.
  • Wer entscheidet, wann eine Testsuite ausreichend ist?
  • Wer gibt grünes Licht für die Einstellung des Versicherungsschutzes?
• Nachweisbare Beweise. Ein KI-Modell, das einen Test generiert, liefert keine Begründung. Das menschliche Team muss dokumentieren, warum der Test für eine bestimmte Sicherheitsanforderung relevant ist.
• Deterministische Validierung. KI-gestützte Tools können sich nichtdeterministisch verhalten und beispielsweise bei verschiedenen Durchläufen unterschiedliche Tests generieren. Für sicherheitskritische Verifizierungen müssen die endgültigen Validierungsnachweise reproduzierbar und nachvollziehbar sein.

Fazit: KI kann Arbeitsabläufe beschleunigen, doch die Verantwortung für Sicherheit und Zuverlässigkeit bleibt bei den Entwicklungsteams. Gemäß Abschnitt 15 der Norm, „Entwicklungsframeworks und Softwaretools“, wird von Ihnen erwartet, dass Sie Vertrauen in jedes verwendete Tool schaffen, sei es ein Compiler, ein Testgenerator oder ein KI-Assistent. Menschliche Aufsicht ist die Grundlage dieses Vertrauens.

Wie Sie mit der ISO/PAS 8800-Vorbereitung beginnen

Sie müssen nicht über Nacht vollständige Konformität erreichen. Ziel ist es, einen skalierbaren, iterativen Fahrplan zu entwickeln, der zunächst die kritischsten Lücken schließt. Basierend auf der Struktur des Standards und den häufigsten Problemen der Branche finden Sie hier einen praktischen Einstiegspfad:

• Bewerten Sie die aktuellen Sicherheitsabläufe. Ordnen Sie Ihre bestehenden Prozesse dem ISO/PAS 8800-Lebenszyklus zu.
  • Gibt es für Sie eine klare Unterscheidung zwischen KI-Verifizierung (Modell isoliert) und Validierung (System im Fahrzeug)?
  • Erfüllen Sie bereits die Anforderungen von ISO 26262 und SOTIF? Ermitteln Sie, wo KI neue Aktivitäten einführt.
• Identifizieren Sie KI-spezifische Validierungslücken. Nutzen Sie Klausel 11 (Daten) und Klausel 13 (Sicherheitsanalyse) als Checkliste. Häufige Lücken sind:
  • Rückverfolgbarkeit fehlender Datensätze
  • Keine strukturierte Handhabung der Grenzen des operativen Bereichs
  • Mangelnde Robustheitsprüfung – adversarieller oder Grenzfall
  • Keine Laufzeitüberwachungsstrategie
• Die Rückverfolgbarkeit verbessern. Rückverfolgbarkeit ist das verbindende Element jeder Sicherheitsargumentation. Beginnen Sie mit der Verknüpfung von übergeordneten Sicherheitszielen → KI-Sicherheitsanforderungen → Datensätzen → Testfällen → Testabdeckungsergebnissen. Selbst eine einfache Rückverfolgbarkeitsmatrix ist besser als gar keine, und automatisierte Tools können sie im Laufe der Zeit skalieren.
• Automatisierte, wiederholbare Tests. Manuelle Regressionstests stoßen bei wachsenden KI-Systemen an ihre Grenzen. Implementieren Sie automatisierte Unit-Tests für die Software-Sicherheitsvorkehrungen (C/C++) und integrieren Sie simulationsbasierte Szenariotests für das KI-Verhalten. Führen Sie diese Tests bei jedem Build oder nächtlichen Build aus, um Regressionen frühzeitig zu erkennen.
• Zentralisierung der Beweisgenerierung. Verstreute Tabellen und manuelle Berichte bergen ein Prüfungsrisiko. Nutzen Sie eine einheitliche Plattform oder Toolchain, um statische Analyseergebnisse, Testergebnisse, Abdeckungsmetriken und Rückverfolgbarkeitsverbindungen zu erfassen. Ziel ist es, prüfungsfertige Nachweise bedarfsgerecht bereitzustellen, nicht erst nach wochenlanger manueller Datenerfassung.

Ziel ist es nicht, alles sofort zu lösen. Vielmehr geht es darum, einen skalierbaren Fahrplan für die kontinuierliche Gewährleistung der KI-Sicherheit zu entwickeln. Beginnen Sie klein, zeigen Sie Fortschritte auf und erweitern Sie die Maßnahmen schrittweise, sobald Ihr Team an Sicherheit gewinnt.

Erstellen Sie einen ISO/PAS 8800-Testfahrplan für die KI-Sicherheitsbereitschaft

ISO/PAS 8800 ist mehr als nur eine neue Spezifikation für die Sicherheit von KI-Systemen in der Automobilindustrie. Sie spiegelt einen grundlegenden Wandel in der Entwicklung, Validierung und Überwachung sicherheitskritischer Softwaresysteme wider. Anders als bei traditionellen V-Modell-Prozessen, bei denen die Sicherheit erst am Ende nachgewiesen wird, erfordert die KI-Sicherheit eine kontinuierliche, iterative Evidenzgenerierung.

Die Teams in der Automobilindustrie benötigen praktische Arbeitsabläufe, die die folgenden Elemente zu einem wiederholbaren Entwicklungssystem verbinden.

Warum dies für Ihre Roadmap wichtig ist:

Jede dieser Komponenten kann schrittweise implementiert werden. Zum Beispiel:

• Phase 1. Automatisieren Sie die statische Analyse und die Unit-Tests für C/C++-Schutzmechanismen. Stellen Sie die grundlegende Rückverfolgbarkeit zu den Anforderungen sicher.
• Phase 2. Fügen Sie simulationsbasierte Szenariotests für das KI-Modell hinzu. Beginnen Sie mit der Erfassung von Datensatzversionen und -abdeckung.
• Phase 3. Implementieren Sie Laufzeitmonitore in Testfahrzeugen. Schließen Sie den Regelkreis, indem Sie Feldanomalien in Szenariotests zurückführen.
• Phase 4. Erreichen Sie eine durchgängige Automatisierung, bei der eine Code- oder Modelländerung eine vollständige Verifizierung, eine Abdeckungsanalyse und die Zusammenstellung der Nachweise auslöst.

Organisationen, die diese Praktiken frühzeitig umsetzen, sind besser aufgestellt, um KI-Innovationen zu skalieren und gleichzeitig das Vertrauen in Sicherheit, Zuverlässigkeit und Auditbereitschaft zu wahren. Der Standard ist kein Hindernis – er ist ein Leitfaden für mehr Vertrauen.