KI SCHLAEGT VOR, MENSCHEN ENTSCHEIDEN

Viele Safety Engineers kennen diesen Moment: Die Item Definition ist offen, daneben der Normtext aus ISO 26262, und die HARA-Tabelle wartet noch leer auf den ersten belastbaren Eintrag.

Die Norm ist klar darin, was am Ende vorliegen muss. Sie sagt deutlich weniger darüber, wie Teams effizient dorthin kommen. Genau diese Luecke frisst in jedem Projekt wertvolle Expertenzeit.

Die Arbeit ist notwendig. Sie ist aber auch wiederkehrend, strukturell aehnlich und mit klassischen Prozessen schwer zu skalieren. Generative KI ist deshalb ein naheliegender Hebel. Gleichzeitig kann sie leise Fehler mit grosser Wirkung in sicherheitskritische Arbeit einschleusen.

Die richtige Frage lautet also nicht, ob man KI nutzt. Die Frage lautet: Wo gehoert sie hin, und wo darf sie auf keinen Fall entscheiden? Aegis SafeForge ist unsere Antwort darauf.

Das ehrliche Problem

LLMs können sehr gut Inhalte erzeugen, die wie HARA-Tabellen aussehen. Sie können aber genauso gut Ergebnisse liefern, die richtig wirken und trotzdem fachlich danebenliegen.

Wir testen das laufend. Gibt man einem leistungsfähigen Modell eine echte Item Definition, wirkt der Output oft sofort überzeugend: saubere Hazard-Beschreibungen, plausible Begruendungen, glatte ASIL-Zuordnung. Dann schaut man genauer hin.

Ein ASIL B wird still zu D hochgezogen. Eine zitierte Klausel sagt gar nicht, was behauptet wird. Zwei Szenarien bekommen dieselbe Controllability, obwohl ein erfahrener Engineer sie sofort unterscheiden wuerde.

Für Nicht-Experten sind solche Fehler schwer sichtbar. Im ISO-26262-Kontext sind sie trotzdem klare Audit-Risiken.

Das ist kein reines Prompting-Problem. Es ist ein Kategorienproblem. Safety Analysis arbeitet mit deterministischen Regeln: Lookup-Tabellen, Ableitungslogik, Traceability Constraints und klaren Abhängigkeiten. LLMs sind nicht für diese Art verbindlicher Entscheidung gebaut.

Trotzdem sind sie im Workflow nuetzlich. Sie können Hazard-Beschreibungen entwerfen, plausible Failure Modes sichtbar machen und einen ersten strukturierten Artefaktentwurf liefern. Deshalb fragen wir nicht, ob KI Safety Engineers ersetzt. Wir fragen genauer.

Was wir gebaut haben

Aegis SafeForge ist eine KI-gestützte Plattform für ISO 26262-, ISO/SAE 21434- und IEC-61511-Workflows. Sie erzeugt erste Entwürfe für HARA, TARA, FMEA, Safety Goals und Requirements. Danach muss jeder Output durch einen Workflow, der nicht umgangen werden kann.

Das Grundprinzip ist einfach: Das LLM übernimmt semantische Generierung. Der Engineer bringt Urteilskraft ein. Deterministische Logik erzwingt korrekte Ableitung. Jede Schicht tut, was sie gut kann, und wird daran gehindert, fremde Aufgaben zu übernehmen.

Leitplanke 1: Normenbasierter Kontext

Bevor das Modell schreibt, ruft das System relevante Passagen aus autoritativen Quellen ab: Normtexte, Projektdokumente und freigegebene Engineering-Unterlagen. Der Vorschlag entsteht damit nicht aus Trainingserinnerung, sondern aus nachvollziehbarem Kontext.

Das veraendert den Fehlermodus. Ein Modell, das sich auf Trainingswissen verlässt, kann Klauseln falsch erinnern. Ein Modell, das mit aktuellem Norm- und Projektkontext arbeitet, lässt sich besser begrenzen und später leichter aktualisieren.

Leitplanke 2: Deterministische Safety-Logik

Das ist der Teil, der für Audits besonders wichtig ist. Das Modell darf Hazard-Beschreibungen und S-, E- und C-Werte vorschlagen. Die ASIL-Ableitung wird jedoch deterministisch nach Regelwerk berechnet. Immer.

Der Grund ist simpel: ASIL steuert alles, was danach kommt. Safety Goals, Verifikationsumfang, Hardware-Ziele und Compliance-Aufwand hängen daran. Ein plausibler, aber falscher ASIL ist kein kleiner Schoenheitsfehler.

Deshalb gilt: Kein Modell-Output überschreibt die deterministische Ableitung. Was die Tabelle vorgibt, bleibt die verbindliche Systemgrenze.

Leitplanke 3: Review-Workflow ohne Hintertuer

Jede KI-generierte Zeile startet als Vorschlag. Sie muss bearbeitet, geprüft und explizit freigegeben werden. Nur freigegebene Artefakte sind für Compliance-Exporte vorgesehen.

Entscheidend ist, dass die Durchsetzung nicht nur in der Oberflaeche passiert. Sie liegt in der Daten- und Workflow-Logik. Fehlende Werte, unvollständige Item Definitions oder ungeprüfte Zeilen blockieren den naechsten Schritt.

Leitplanke 4: Audit Trail als Kernsystem

Jede Änderung wird im Audit Trail sichtbar: Feldbearbeitungen, Statuswechsel, Nutzeridentitaet, Zeitstempel und Systemaktionen. Reviewer können nachvollziehen, wie eine Entscheidung entstanden ist.

Genau das macht KI in diesem Workflow überhaupt vertretbar. Der Audit Trail ist keine nachtraegliche Dokumentation. Er ist der Nachweis, dass Menschen die Safety-Entscheidungen kontrolliert haben.

Woran wir weiter arbeiten

Nicht jede Frage ist endgueltig geloest. Drei Themen beobachten wir besonders genau.

Ausblick

In den naechsten Beitraegen schauen wir unter die Haube: zuerst auf die Retrieval-Architektur, die KI-Vorschläge in Normen- und Projektkontext erdet, danach auf die Schichten aus probabilistischer Generierung, deterministischer Safety-Logik, Workflow-Durchsetzung und Auditierbarkeit.

Die Architektur ist nicht auf maximale Einfachheit optimiert, sondern auf etwas Schwierigeres: Traceability unter regulatorischer Prüfung, reproduzierbare Ableitungen und klare Grenzen zwischen KI-Vorschlag und freigegebener Engineering-Entscheidung.