Funktionale Sicherheit, SOTIF, Ethik und Datenschutz — Künstliche Intelligenz im Automobilbau

Gewinne:

Fähigkeit, ISO 26262 funktionale Sicherheit und ISO 21448 (SOTIF) Frameworks und ihre Auswirkungen auf Systeme mit künstlicher Intelligenz zu erklären
Fähigkeit zum Umgang mit Datenschutz, Fahrerdaten, Cybersicherheit (ISO/SAE 21434) und ethischen Risiken im Automobilkontext
Fähigkeit, die menschliche Verantwortung für sicherheitskritische Entscheidungen aufrechtzuerhalten, indem man versteht, dass die KI-Ergebnisse kein Ersatz für die Genehmigung durch einen kompetenten Ingenieur sind

Sie befinden sich in der kritischsten Einheit dieses Moduls. Bisher haben wir KI als Beschleuniger vom Design bis zur Fertigung, vom Testen bis zur Lieferkette gesehen. Aber die entscheidende Frage im Automobilbereich ist: Schadet dieses System irgendjemandem und wer ist dafür verantwortlich? Diese Einheit behandelt im Klartext die Rahmenbedingungen für den verantwortungsvollen Einsatz von KI in einer sicherheitskritischen Branche – funktionale Sicherheit, SOTIF, Cybersicherheit, Datenschutz und Ethik. Das Grundprinzip bleibt unverändert: Die KI-Ergebnisse ersetzen niemals die Genehmigung eines kompetenten Ingenieurs; Sicherheitskritische Entscheidungen und Verantwortung liegen beim Menschen.

ISO 26262: funktionale Sicherheit

ISO 26262 ist die funktionale Sicherheitsnorm für elektrische/elektronische Systeme von Straßenfahrzeugen. Funktionale Sicherheit; Es geht darum sicherzustellen, dass ein Ausfall eines Systems (ein Sensor geht kaputt, eine Software fällt aus) nicht zu einer gefährlichen Situation führt.

Das Herzstück dieses Standards ist ASIL (Automotive Safety Integrity Level). Eine Gefährdung wird in drei Dimensionen bewertet:

Schweregrad: Wie schlimm wäre es, wenn es passieren würde? (leichte Verletzung oder Tod)
Exposition: Wie oft kommt das vor?
Kontrollierbarkeit: Wie gut kann der Fahrer die Situation kontrollieren?

Diese drei zusammen ergeben ein Niveau von ASIL A (am niedrigsten) bis ASIL D (am höchsten, z. B. Bremsen, Lenken). Mit steigendem Level werden die Entwicklungs-, Test- und Dokumentationsanforderungen strenger.

HAUPT

Probensystem

Anforderungsintensität

Fehlfunktion der Innenbeleuchtung

niedrig

Rücklicht

mittel

Einige ADAS-Funktionen

hoch

Bremse, Lenkung, Airbag

am höchsten

Tipp: Wenn Sie die MAIN-Ebene einer Funktion kennen, erfahren Sie, wie viel Aufmerksamkeit der Einsatz von KI in dieser Funktion erfordert. KEINE Entscheidung basierend auf der KI-Ausgabe in einer Funktion kann ohne unabhängige Sicherheitsüberprüfung akzeptiert werden.

ISO 21448 (SOTIF): Sicherheit der vorgesehenen Funktion

Die klassische funktionale Sicherheit (ISO 26262) konzentriert sich auf die Frage „Was passiert, wenn das System ausfällt?“ Bei Erkennungssystemen mit künstlicher Intelligenz gibt es jedoch ein neues Problem: Auch wenn das System nie ausfällt, kann es dennoch unzureichend sein. Die Kamera funktioniert einwandfrei, kann aber eine Schneeplatte nicht erkennen; Das Radar ist stabil, aber es ignoriert ein stehendes Fahrzeug als Geistersignal. Hier liegt kein Hardware-/Softwarefehler vor; Das Problem liegt an der Grenze des vorgesehenen Funktionsumfangs.

ISO 21448 – SOTIF (Safety Of The Intended Functionality) adressiert genau diese Lücke: das Management von Risiken, die aus unerkannten Szenarien, Erkennungsgrenzen und unvorhergesehenen Situationen entstehen, selbst wenn das System wie vorgesehen funktioniert. Im KI-basierten ADAS/autonomen Fahren ist SOTIF genauso wichtig wie ISO 26262.

Rahmen

Konzentrieren Sie sich

Beispiel

ISO 26262

Risiko durch Scheitern

Sensor geht kaputt, Signal verschwindet

ISO 21448 (SOTIF)

Gefahr der Unzulänglichkeit/Nichtanerkennung

Robuste Kamera erkennt Schneedecke nicht

ISO/SAE 21434

Cybersicherheit

Systemangriff, Datenmanipulation

Achtung: KI-Modelle sind statistisch; Sie können nicht garantieren, dass sie „jede Situation richtig sehen“. SOTIF zielt darauf ab, unbekannte Gefahrenszenarien in diesen inhärent begrenzten Systemen einzugrenzen und das verbleibende Risiko auf ein akzeptables Maß zu reduzieren. „Das Modell ist zu 99,9 % genau“ ist kein Sicherheitsbeweis.

ISO/SAE 21434: Cybersicherheit

Vernetzte und softwaredefinierte Fahrzeuge sind anfällig für Cyberangriffe. Ein entfernter Angreifer kann den Bremsbefehl ändern, Telemetriedaten stehlen oder das Erkennungsmodell austricksen (gegnerischer Angriff: Er bringt das Modell dazu, es falsch zu erkennen, indem er einen kleinen Aufkleber auf einer Platte anbringt). ISO/SAE 21434 ist der technische Rahmen für die Cybersicherheit von Fahrzeugen. Im Zusammenhang mit künstlicher Intelligenz fallen zwei Risiken auf: die Täuschung des Modells (adversarial) und die Vergiftung der Trainingsdaten (Data Poisoning). Sicherheitskritische KI-Systeme sollten gegen diese Angriffe getestet werden.

Datenschutz und persönliche Daten

Das moderne Fahrzeug ist ein „Datenzentrum auf Rädern“: Standort, Fahrverhalten, Audio, sogar Kabinenkamera. Bei den meisten davon handelt es sich um personenbezogene Daten, die durch KVKK (Türkiye) und DSGVO (Europa) abgedeckt sind. VIN (Fahrgestellnummer) kann ein Fahrzeug und indirekt seinen Besitzer identifizieren. Grundprinzipien:

Datenminimierung: Sammeln Sie nur das, was benötigt wird.
Zweckbeschränkung: Verwenden Sie die Daten nicht für andere Zwecke als den Zweck, für den sie erfasst wurden.
Anonymisierung/Pseudonymisierung: Persönliche Informationen entfernen oder verschlüsseln.
Ausdrückliche Einwilligung und Transparenz: Der Fahrer muss wissen, was gesammelt wird.
Sichere Speicherung und Übertragung.

Achtung: Das Senden von Roh-FIN, Standortverlauf oder Fahrverhalten an ein öffentliches Cloud-KI-Tool kann sowohl eine Verletzung der Privatsphäre als auch ein vertragliches Risiko darstellen. Wenn Sie mit diesen Daten arbeiten, anonymisieren Sie diese und nutzen Sie eine institutionelle, datengeschützte Umgebung.

Ethik und Ingenieurverantwortung

Künstliche Intelligenz birgt einige ethische Risiken:

Bias: Wenn die Trainingsdaten bestimmte Bedingungen überwiegen (z. B. tagsüber, helle Haut, bestimmte Regionalstraßen), kann das Modell unter unterrepräsentierten Bedingungen (Nacht, andere Bedingungen) schlecht funktionieren. Dies ist eine Schwachstelle.
Selbstüberschätzung (Automatisierungsbias): Menschen vertrauen blind der Automatisierung und setzen sich über ihr eigenes Urteilsvermögen hinweg. Wenn der Testingenieur aufhört, sich die Rohdaten anzusehen, nur weil die KI „bestanden“ sagt, ist das ein gefährlicher Trend.
Verantwortungsverlust: „Das Modell hat entschieden“ ist keine Verteidigung. Hinter der Entscheidung sollte immer eine Person stehen, die unterschreibt.

Mini-Fallstudien

Fall 1 – SOTIF-Grenzwert. Ein automatisches Notbremssystem besteht alle Labortests ohne Störungen. Auf dem Feld, in der tiefstehenden Sonne, verwechselt ein weißer Lastwagen seinen Anhänger mit dem Himmel und bremst zu spät. Hierbei handelt es sich nicht um eine Fehlfunktion, sondern um eine SOTIF-Schwachstelle: Das System ist intakt, das Szenario liegt jedoch außerhalb der Erkennungsgrenze. Das Team fügt dieses Szenario der Testbibliothek hinzu und stärkt die Radarfusion. Fazit: „Kein Ausfall“ ist kein Beweis für Sicherheit; Auch Insuffizienz ist ein Risiko.

Fall 2 – Verzerrte Daten. Ein Fußgängererkennungsmodell wurde überwiegend mit Tagesdaten trainiert; Die Nachterinnerung ist deutlich geringer. Das Team gleicht Nacht- und Schwachlichtdaten aus, trainiert sie neu und berichtet separat über Nachtszenarien. Fazit: Unausgeglichene Daten schaffen unter bestimmten Umständen eine tödliche Sicherheitslücke.

Fall 3 – Verhinderung von Datenschutzverletzungen. Ein Analyst ist gerade dabei, Flottendaten in ein öffentliches KI-Tool einzufügen, als er feststellt, dass die Daten rohe VIN- und GPS-Standorte enthalten. Es funktioniert in einer Unternehmensumgebung durch Anonymisierung der Daten (Fahrzeug_01..arac_50 statt VIN, Regionalcode statt Standort). Ergebnis: Ein Moment der Aufmerksamkeit verhinderte einen schweren KVKK-Verstoß.

Eingabeaufforderungsvorlagen

Vorlage 1 – PRIOR/vorläufige Risikobewertung (Entwurf):

Rolle: Sie sind ein Berater für funktionale Sicherheit. Aufgabe: Bereitet einen Entwurf zur Unterstützung der Gefahren- und Risikoanalyse für eine Funktion vor. Kontext: Funktion: automatische Notbremsung; urban und intercity. Einschränkung: genaue Zuordnung von ASIL; Geben Sie eine Liste mit Fragen und Schwerpunkten zu den Dimensionen Schweregrad/Exposition/Kontrollierbarkeit an; Geben Sie an, dass die endgültige Zuweisung beim autorisierten Sicherheitstechniker liegt.Ausgabe: Größe | Bewertungsfrage | Aufmerksamkeitsnotiztabelle.

Vorlage 2 – SOTIF-Szenario-Scan:

Rolle: Sie sind SOTIF-Experte. Aufgabe: Listen Sie Szenarien auf, in denen eine Erkennungsfunktion möglicherweise „System intakt, aber unzureichend“ ist. Kontext: Kamera + Radar; Tiefstehende Sonne, Schnee, Tunnelausgang, ungewöhnliche Objekte.Ausgabe: Szenario | warum Unzulänglichkeit | Reduktionsempfehlung.

Vorlage 3 – Datenschutzkontrolle:

Rolle: Sie sind Datenschutzbeauftragter (KVKK/DSGVO). Aufgabe: Führen Sie eine Datenschutzprüfung durch, bevor Sie einen Datensatz freigeben. Kontext: Flottentelemetrie; Die Spalten enthalten Fahrgestellnummer, GPS und Fahrbewertung. Einschränkung: Welche Felder sind personenbezogene Daten, wie sollten sie anonymisiert werden, was sollte ich überhaupt nicht weitergeben; sort.Output: Feld | Risiko | Empfohlenes Transaktionsdiagramm.

Vorlage 4 – Bias-Check:

Rolle: Sie sind ein ML-Sicherheits- und Fairness-Auditor. Aufgabe: Sagen Sie mir, wie ich in einem Erkennungsmodell nach dem Risiko einer Verzerrung suchen kann. Kontext: Fußgängererkennung; Trainingsdaten gewichtet Tag/Stadt.Ausgabe: Zu prüfende Bedingung | Messung | Risikozeichen.

Schwache Eingabeaufforderung / Starke Eingabeaufforderung

Schwache Eingabeaufforderung:

Ist dieses autonome Bremssystem sicher, bestätigen Sie.

Der Versuch, eine KI-Sicherheitsfreigabe zu erhalten, ist gefährlich; Die Genehmigung liegt beim autorisierten Ingenieur.

Kraftvolle Aufforderung:

Rolle: Sie sind ein Berater für funktionale Sicherheit und SOTIF. Aufgabe: Listen Sie auf, welche Fragen ich stellen und welche Beweise ich bei der Sicherheitsbewertung meiner automatischen Bremsfunktion sammeln sollte. Kontext: KI-basierte Erkennung; Kamera+Radar; ASIL kann hoch sein. Einschränkung: Das System „genehmigen“; Bereitstellung separater Listen mit Fragen und Nachweisen im Hinblick auf ISO 26262 (Mangel) und SOTIF (Mangel); Betonen Sie, dass die endgültige Genehmigung beim autorisierten Sicherheitstechniker liegt.Ausgabe: Framework | Frage | erforderliche Beweistabelle.

Häufige Fehler

Verwechslung von „keine Fehlfunktion“ mit „sicher“. Ein SOTIF-Mangel kann tödlich sein, ohne dass es zu Fehlfunktionen kommt.
KI-Sicherheitsfreigabe erhalten. Die Genehmigung und Verantwortung liegt beim autorisierten Ingenieur.
Modellgenauigkeit wird als Beweis für Sicherheit verwechselt. Eine Genauigkeit von 99,9 % bedeutet nicht, dass das verbleibende Risiko gemanagt wurde.
Kein Schutz personenbezogener Daten. Fahrgestellnummer/Standort/Fahrverhalten liegen im Geltungsbereich der KVKK/DSGVO.
Ignorieren von Voreingenommenheit und Selbstüberschätzung. Unausgeglichene Daten und blindes Vertrauen in die Automatisierung sind Schwachstellen.

Zusammenfassend

ISO 26262 verwaltet das Risiko aufgrund von Fehlern (mit ASIL), während ISO 21448/SOTIF das Risiko von Fehlern ohne Fehler verwaltet; Beide sind für die KI-Erkennung von entscheidender Bedeutung.
ISO/SAE 21434 Cybersicherheit; Adversarial- und Data-Poisoning-Angriffe sind KI-spezifische Bedrohungen.
Datenminimierung, Zweckbindung und Anonymisierung sind im Rahmen der KVKK/DSGVO verpflichtend; VIN/Standort sind personenbezogene Daten.
Vorurteile, Selbstüberschätzung und Verantwortungsverlust sind die größten ethischen Risiken.
Die KI-Ausgabe ist kein Ersatz für die Genehmigung eines qualifizierten Ingenieurs. Die sicherheitskritische Entscheidung und Unterschrift liegen immer bei der Person.

Anwendungsaufgabe

Wählen Sie eine sicherheitsrelevante Funktion (z. B. Spurhaltung). (1) Besprechen Sie, warum das ASIL-Niveau dieser Funktion entlang der Dimensionen Schweregrad/Exposition/Kontrollierbarkeit hoch/niedrig sein kann. (2) Generieren Sie 5 „System solide, aber unzureichend“-Szenarien mit Vorlage 2. (3) Vertraulichkeitsprüfung eines relevanten Datensatzes mit Vorlage 3. (4) Erklären Sie, warum die Aussage „Das Modell bestätigt“ keine Verteidigung darstellt.

Checkliste

[ ] Ich habe die TATSÄCHLICHEN Dimensionen der Funktion ausgewertet (die genaue Zuordnung habe ich der Behörde überlassen).
[ ] Ich habe zwischen ISO 26262 (Fehlfunktion) und SOTIF (Unzulänglichkeit) unterschieden.
[ ] Ich habe das Risiko der Cybersicherheit (Adversarial/Poisoning) berücksichtigt.
[ ] Ich habe personenbezogene Daten anonymisiert und minimiert.
[ ] Ich habe nach dem Risiko von Voreingenommenheit und Selbstüberschätzung gesucht.
[ ] Ich habe bestätigt, dass die Sicherheitsfreigabe beim qualifizierten Techniker liegt.