ISO 26262 und AI: die Trennlinie zwischen Assistenz und Safety-Entscheidung

ISO 26262 und AI: Assistenz und Safety-Entscheidung sauber trennen

Funktionale Sicherheit lebt von Nachvollziehbarkeit und klaren Verantwortlichkeiten. AI kann in sicherheitsrelevanten Entwicklungen enorm helfen. Aber nur, wenn von Anfang an klar ist, wo Assistenz endet und die Safety-Entscheidung beginnt.

Unter ISO 26262 bis ASIL-D ist diese Trennung Architektur, kein Nachgedanke. Die Trace-Links sind das Rückgrat der Sicherheitsargumentation. Sie müssen jederzeit belastbar bleiben.

Die Trennung ist Architektur, nicht Nachgedanke.

Damit stehen für Sie als Verantwortliche im Engineering konkrete Fragen im Raum:

• Wo darf AI unterstützen, ohne die Safety-Argumentation zu berühren?
• Wie bleiben Trace-Links als Rückgrat der Argumentation intakt?
• Wie ist belegt, dass eine sicherheitsrelevante Freigabe durch einen Menschen erfolgte?
• Wie verhindern wir, dass Tool-Confidence den AI-Einsatz blockiert?

Dieser Beitrag zeigt, was AI in ISO-26262-Kontexten beitragen darf und was beim Menschen bleibt. Und wie Trace-Links die Argumentation reproduzierbar halten.

Warum die Safety-Frage die AI-Frage vorwegnimmt

In sicherheitsrelevanten Entwicklungen lässt sich die AI-Frage nicht getrennt stellen. Jede Überlegung, wo ein Assistent helfen könnte, trifft sofort auf die Gegenfrage. Berührt das die Sicherheitsargumentation? ISO 26262 verlangt bis ASIL-D eine luckenlose, nachvollziehbare Begründung. Diese Begründung muss von Menschen getragen werden. Sie ist gegenüber einem Assessor zu verantworten.

Daraus folgt kein Verzicht auf AI. Es folgt eine klare Zuordnung. AI darf überall dort wirken, wo sie Zuarbeit leistet. Sie darf die Argumentation nicht selbst fällen. Die Trennlinie ist damit nicht das Ende der Automatisierung. Sie ist ihre Voraussetzung. Sie definiert den Raum, in dem AI sicher und wirksam wirkt.

Assistenz und Entscheidung sauber trennen

Was AI beitragen darf

AI beschleunigt die Zuarbeit erheblich. Sie strukturiert Anforderungen. Sie leitet Testfälle ab. Sie prüft Konsistenz. Sie bereitet Dokumentation vor. Sie macht Änderungsauswirkungen sichtbar. Das entlastet Engineers von mechanischer Arbeit. So bleibt Zeit für die eigentliche Sicherheitsbewertung.

Entscheidend ist der Status dieser Beiträge. Es sind Vorschläge. Sie werden erst nach menschlicher Prüfung Teil der Argumentation. Die Beschleunigung liegt in der Zuarbeit, nicht in der Verantwortung.

Was beim Menschen bleibt

Klar beim Menschen bleibt, was die funktionale Sicherheit trägt.

• Safety-Freigaben und die Bewertung von Sicherheitszielen.
• Die ASIL-Einstufung und die Argumentation der funktionalen Sicherheit.
• Jede Entscheidung, die gegenüber einem Assessor zu verantworten ist.

Diese Trennung ist keine Vorsichtsmaßnahme. Sie ist eine Voraussetzung. Eine Argumentation, deren Kernentscheidungen aus einem Modell stammen, ist gegenüber einem Assessor nicht haltbar.

Trace-Links als Rückgrat der Argumentation

Die durchgängige Verknüpfung von Anforderung, Design, Implementierung und Test ist das Rückgrat der Sicherheitsargumentation. AI kann diese Spuren mitziehen und konsistent halten. Die Bewertung der Spur bleibt menschliche Verantwortung.

So bleibt die Argumentation reproduzierbar. Bei jeder Änderung ist nachvollziehbar, welche Anforderung betroffen ist. Welcher Test sie abdeckt. Und wer die Freigabe erteilt hat. Genau das verlangt ISO 26262 im Audit.

Tool-Confidence und der Einsatz von AI

In Safety-Kontexten stellt sich immer die Frage nach dem Vertrauen in Werkzeuge. Der Ausweg ist nicht, AI zu meiden. Der Ausweg ist, sie richtig einzuordnen. AI ist ein assistierendes Werkzeug. Ihre Ausgaben werden menschlich geprüft. Und sie werden in deterministische, versionierte Artefakte überführt. Nicht das Modell trägt die Entscheidung. Der Mensch trägt sie. Das Modell liefert nachvollziehbare Zuarbeit.

Häufige Fehler in Safety-Kontexten

• AI in der Safety-Entscheidung. Die ASIL-Einstufung oder Freigabe an ein Modell delegieren.
• Trace als Formsache. Verknüpfungen pflegen, aber nicht als Argumentationsgrundlage ernst nehmen.
• AI meiden statt einordnen. Aus Sorge um Tool-Confidence auf jede Zuarbeit verzichten.

Der gemeinsame Nenner ist eine unscharfe Grenze. Ist sie klar und im Werkzeug verankert, wird AI in Safety-Kontexten zum Beschleuniger. Die Sicherheit bleibt in menschlicher Hand. Die mechanische Arbeit wird deutlich schneller. Genau diese Rollenverteilung macht den Einsatz belastbar.

So gehen wir vor: Build, Operate, Transfer

AI-Assistenz in ISO-26262-Kontexten bauen wir nicht als Folienkonzept. Wir bauen es als produktive Fähigkeit. Das folgt dem Prinzip Build, Operate, Transfer. Unsere Beteiligung nimmt über die Phasen ab. Ihre Capability wächst ins eigene Haus. Der Wissenstransfer ist vertragliches Erfolgskriterium, kein Zusatz. Sonst entsteht genau der Lock-in, den wir vermeiden wollen.

1. Build. Setup, Guardrails und erste Workflows entlang Ihres realen Prozesses.
2. Operate. Betrieb mit KPI-Verantwortung auf Wertstrom-Ebene. Nie auf Personen-Telemetrie.
3. Transfer. Dokumentierte Übergabe. Ihr Team übernimmt Tooling, Wissen und Betrieb.

Getragen wird das von drei Modulen. Erstens ein Strategic Engineering Lead. Das ist ein Senior-Embedded-Architekt zusammen mit einem Strategic AI Lead. Zweitens die auditierbare Tooling-Plane sensified AI-OS. Drittens die Automotive-Playbooks. Sie beschreiben die Methodik für AI in Embedded-, ASIL-, ASPICE- und AUTOSAR-Kontexten. Die Leitplanke, was AI nicht entscheidet, ist darin fest verankert.

Die vier Mandat-Typen sind kombinierbar. Sie passen sich Ihrem Reifegrad an. Es gibt den Strategic Engineering Lead für den breiten Aufbau. Es gibt die BOT Engineering-Capability als Programm-Paket je Domäne. Es gibt den ASPICE- oder ASIL-Workflow-Pilot zur Validierung vor dem Mandat. Und es gibt das Modul Tooling, MCP und AI-Governance mit Schlüssel-Isolation und Kosten-Transparenz. Der Einstieg ist bewusst risikoarm. Zuerst ein Qualifying-Call zum Fit-Check. Dann NDA und Discovery-Workshop. Danach der Workflow-Pilot. Erst dann das BOT-Mandat mit Governance-Plane. Kommerzielle Details klären wir im Discovery-Workshop, nicht über öffentliche Preislisten.

Gemessen wird auf Wertstrom-Ebene, nie an Personen. Wir messen Kosten je Wertstrom, den Produktivitäts-Zuwachs und die reale Nutzung. So bleibt jederzeit belegbar, ob sich die Fähigkeit rechnet. Das entscheidet über den nächsten Ausbauschritt. Der Betrieb erzeugt keine Chat-Historie als Ergebnis. Er erzeugt prüfbare Artefakte, die in Ihren Prozess passen. Dazu gehören Reports, Traceability-Matrizen und ausführbare Testsuiten.

Der Pilot ist bewusst klein gehalten. Er dauert wenige Wochen. Er nimmt sich einen realen Ausschnitt Ihres Prozesses vor, nicht ein Laborbeispiel. Am Ende steht ein belastbarer Beleg. Sie sehen, ob die Kette hält und ob sich der Aufwand lohnt. Erst auf dieser Basis entscheiden wir gemeinsam über das volle Mandat. So bleibt jedes Investment an ein sichtbares Ergebnis gebunden.

Dieselbe Grenzziehung aus Prozess-Sicht behandelt Was AI im ASPICE-Prozess nicht entscheidet. Wie die Freigabe-Logik organisatorisch verankert wird, zeigen die Governance-Gates G1 bis G5.

Fazit

Es gibt einen Unterschied zwischen zwei Sätzen. Der erste lautet: Wir nutzen AI-Tools. Der zweite lautet: Wir besitzen eine beherrschte, auditierbare AI-Engineering-Capability. Dieser Unterschied entscheidet, ob AI im Serienprogramm trägt oder im Pilot versandet. Genau diese Entscheidungen hat sensified für den eigenen Betrieb getroffen. Sie sind in einem realen ASPICE-Serienprogramm gebaut. Deshalb kommt sensified mit einer Position, nicht mit Fragen.

Drei Dinge unterscheiden diesen Ansatz. Es gibt einen klaren Plan, belegt durch eigenes, produktives IP. Wir bauen es mit, bis es ASPICE-konform in Produktion läuft. Und es gibt keinen Vendor-Lock-in, abgesichert durch modell-agnostische Architektur und Transfer als Erfolgskriterium. Zwei Tiefen treffen dabei in einem Partner zusammen. Das ist etabliertes Automotive- und SDV-Wissen. Und es ist AI-Engineering-Tiefe aus eigener Plattform.

Wie dieser Baustein in eine beherrschte Gesamt-Capability passt, zeigt unsere Seite zur AI-Transformation im Automotive-Engineering. Den strategischen Rahmen erklärt der Beitrag AI im Engineering ist ein Capability-Thema, kein Tool-Thema. Der nächste Schritt ist ein Discovery-Workshop. Dort ordnen wir Ihren Prozess, Ihre Compliance-Lage und den ersten sinnvollen Use-Case gemeinsam ein.

Das Wichtigste in Kürze

• Die Trennung von Assistenz und Safety-Entscheidung ist Architektur.
• AI liefert Zuarbeit. Safety-Freigabe und ASIL-Einstufung bleiben beim Menschen.
• Trace-Links sind das Rückgrat und müssen reproduzierbar bleiben.
• Tool-Confidence löst man durch Einordnung, nicht durch Verzicht.