COMPLIANCE BY DESIGN: KI FÜR SICHERHEITSKRITISCHES ENGINEERING BAUEN

KI kommt genau zu dem Zeitpunkt in sicherheitskritisches Engineering, an dem die regulatorische Messlatte steigt. EU AI Act, Cyber Resilience Act, ISO 26262, ISO/SAE 21434 und verwandte Standards zeigen in dieselbe Richtung: softwaregetriebene Systeme müssen transparenter, sicherer, nachvollziehbarer und verantwortbarer werden.

Für Engineering Teams entsteht dadurch Druck, aber auch eine echte Chance. KI kann repetitive Arbeit reduzieren, Analysen beschleunigen und komplexe Safety- und Cybersecurity-Workflows strukturieren. In regulierten Domänen reicht Geschwindigkeit allein jedoch nicht. Die eigentliche Aufgabe lautet: KI nutzen, ohne eine neue Schicht ungeprüfter, nicht nachvollziehbarer Risiken einzuführen.

Bei Aegis SafeForge praegt diese Frage die Architektur. Wir glauben nicht, dass KI Engineering Judgment ersetzen sollte. Sie soll Engineers unterstützen, Blank-Page-Arbeit reduzieren und Teams konsistenter machen, während Fachexperten klar in Kontrolle bleiben.

Das meinen wir mit Compliance by Design.

Das Problem mit Black-Box-KI im regulierten Engineering

In sicherheitskritischen Domänen reicht eine KI-generierte Antwort nicht. Eine HARA, TARA, FMEA, ein Safety Goal oder ein abgeleitetes Requirement kann nicht einfach akzeptiert werden, nur weil ein LLM etwas Plausibles formuliert hat.

Engineers müssen wissen, woher ein Vorschlag stammt, welche Quellen ihn beeinflusst haben, wer ihn geprüft hat, ob er geändert wurde, wer ihn freigegeben hat und welche Folgeartefakte davon abhängen.

Deshalb bauen wir Aegis SafeForge nicht als generischen Chatbot für Engineering-Dokumente, sondern als gesteuerte Engineering-Workflow-Plattform für Safety- und Cybersecurity-Analyse.

KI darf entwerfen. Deterministische Logik muss prüfen.

Ein Kernprinzip unserer Architektur ist die Trennung zwischen probabilistischer KI-Unterstützung und deterministischer Engineering-Logik.

KI kann Hazard-Beschreibungen, Operational Situations, Cybersecurity Scenarios, Requirements-Vorschläge und Analysebausteine entwerfen. Safety-kritische Berechnungen und strukturierte Entscheidungslogik duerfen jedoch nicht von einer Modellmeinung abhängen.

In einem ISO-26262-Workflow kann die KI zum Beispiel Kontext für eine HARA-Zeile vorschlagen. Die ASIL-bezogene Bewertung muss aber über definierte Regeln und Matrizen laufen. Die KI assistiert, wird aber nicht heimlich zur Entscheiderin.

Diese Trennung ist wichtig, weil reguliertes Engineering auf Reproduzierbarkeit, Reviewbarkeit und Verantwortlichkeit angewiesen ist.

Human Approval ist keine Checkbox

Human-in-the-loop wird oft wie ein UI-Feature behandelt. Bei Aegis SafeForge behandeln wir es als Governance-Anforderung.

KI-generierte Outputs sind nicht automatisch finale Artefakte. Sie kommen als Vorschläge ins System, werden geprüft, bei Bedarf bearbeitet und erst durch explizite Freigabe zu akzeptiertem Engineering-Inhalt.

Verantwortung im Safety Engineering lässt sich nicht an ein KI-Modell delegieren. Die Plattform muss diese Verantwortung sichtbar, strukturiert und auditierbar machen.

Traceability gehoert in den Workflow

Auditoren und Engineering Reviewer interessieren sich nicht nur für das Endergebnis. Sie wollen den Weg dorthin sehen.

Darum ist Traceability Kernbestandteil von Aegis SafeForge. Jeder KI-gestützte Vorschlag soll mit Item Definition, Dokumentquellen, Referenzen und Workflow-Status verbunden sein.

Der Audit Trail gehoert zu dieser Grundlage. KI-Generierung, Bearbeitungen, Review-Schritte, Freigaben und Statuswechsel werden so nachvollziehbar, dass Teams die Entwicklung eines Artefakts rekonstruieren können.

Für regulierte Teams ist das kein Komfortfeature. Es ist die Grundlage für Vertrauen.

Data Sovereignty zaehlt

Safety und Cybersecurity Engineering enthalten oft hochsensibles geistiges Eigentum: Item Definitions, Systemarchitekturen, Security Assumptions, Hazards, Threats und technische Mitigations gehoeren nicht unkontrolliert in fremde Umgebungen.

Deshalb beruecksichtigen wir kontrollierte Deployment-Optionen, darunter lokale oder private Umgebungen und später SaaS dort, wo Kunden das bewusst waehlen. Organisationen müssen ihre Datenraender, Infrastruktur und Modellnutzung kontrollieren können.

Die Architektur bleibt bewusst flexibel: lokale Modell-Ausfuehrung, private Deployments und cloudbasierte Modelle können je nach Kundenanforderung unterschiedlich kombiniert werden.

Das Prinzip ist einfach: Kunden sollen kontrollieren, wohin ihre Engineering-Daten gehen.

Compliance für Kunden und für uns selbst

Aegis SafeForge soll Engineering Teams helfen, Safety-, Cybersecurity- und regulatorische Workflows strukturierter, nachvollziehbarer und kontrollierter zu führen. Gleichzeitig bauen wir nicht nur ein Tool für Compliance. Wir bauen eine Plattform, die selbst verantwortbar betrieben werden muss.

Mit reifer werdender KI-Regulierung müssen Softwareanbieter zeigen, wie sie Human Oversight, Transparenz, Cybersecurity, Data Governance, Auditierbarkeit und Risk Management behandeln.

Für uns ist das nichts, was man später anklebt. Es gehoert in die Architektur von Anfang an.

Indem wir Aegis SafeForge um Human Approval, deterministische Verifikation, nachvollziehbare KI-Vorschläge, Audit Logs und kontrollierte Deployment-Optionen herum bauen, schaffen wir auch für unsere eigene Compliance-Reise eine stabilere Basis.

Wir können nicht glaubwuerdig Compliance-Werkzeuge für andere bauen, wenn wir unsere eigene Compliance als Nebensache behandeln. Transparenz, Verantwortlichkeit, Traceability und kontrollierte KI-Workflows sind deshalb nicht nur Features, sondern Arbeitsprinzipien.

Vorbereitung auf AI Act, CRA und Tool Qualification

Compliance ist keine einmalige Checkbox. Sie ist eine laufende Engineering-Disziplin, für Teams, die Aegis SafeForge nutzen, und für uns als Plattformanbieter.

Unsere Roadmap enthält einen Workflow zur regulatorischen Einordnung. Vor HARA, TARA, FMEA oder anderen Safety-/Cybersecurity-Workflows sollen Teams klären können, ob ein Produkt unter Rahmenwerke wie den Cyber Resilience Act, den EU AI Act oder weitere relevante Standards fällt.

Denn viele Teams kaempfen nicht nur mit der Umsetzung, sondern schon mit der Vorfrage: Welche Pflichten gelten für dieses Produkt überhaupt?

Wir prüfen außerdem unseren Weg rund um ISO 26262 Part 8 Tool Qualification. Der Fokus liegt auf frühen Grundlagen: dokumentierte Workflows, Traceability, Audit Logs, Review Controls, deterministische Verifikation und klare Trennung zwischen KI-Unterstützung und freigegebener Engineering-Entscheidung.

Wir behaupten nicht, dass KI Expert Review ersetzt. Wir bauen die Plattform um die gegenteilige Überzeugung herum: Expert Review macht KI im regulierten Engineering erst nutzbar.

Unsere Sicht

Die Zukunft von Safety und Cybersecurity Engineering lautet nicht: "KI ersetzt Engineers." Sie lautet: KI assistiert, deterministische Systeme prüfen, Expertinnen und Experten geben frei, und Audit Trails sichern die Evidence.

In diese Richtung bauen wir Aegis SafeForge.

Wir werden unsere Compliance-Reise weiter offen dokumentieren: AI Act, CRA, ISO 26262, ISO/SAE 21434, Data Governance und vertrauenswuerdige KI-Architektur.

Denn im sicherheitskritischen Engineering ist die eigentliche Frage nicht, ob KI eine Antwort generieren kann. Die Frage ist, ob diese Antwort geprüft, nachvollzogen, hinterfragt und freigegeben werden kann.

Wenn Sie an Safety-, Cybersecurity- oder regulatorischen Engineering-Workflows arbeiten und einen frühen Pilot diskutieren möchten, sprechen wir gern.