AegisSafeForge begann nicht mit dem Plan, eine Safety-Engineering-Plattform für mehrere Branchen zu bauen.
Es begann im September 2025 als gemeinsame Masterarbeit der Universität Kassel und Melster Consulting.
Die Arbeit, abgeschlossen von unserem Gründer und CEO Muhammad Aashir, drehte sich um eine konkrete Frage:
Kann KI Ingenieure dabei unterstützen, Hazards für automotive Batteriemanagementsysteme zu klassifizieren?
Das ursprüngliche Ziel war ein Prototyp, der aus einer Automotive Item Definition die Erstellung einer Hazard Analysis and Risk Assessment, kurz HARA, und der daraus entstehenden Safety Goals unterstützen konnte.
Der Scope war damals bewusst eng. Es war ein akademisches Projekt mit einem Use Case, einer Branche und einer begrenzten Anzahl von Safety-Artefakten.
Sehr früh wurde aber sichtbar, dass dahinter etwas Größeres liegen könnte.
Vom Thesis-Projekt zur Produktidee
Waleed Aman kam im September 2025 als Advisor zum Projekt und unterstützte zunächst die allgemeine Architektur und technische Richtung, während Aashir den ersten Prototyp entwickelte.
Der Prototyp nutzte Inhalte aus der Item Definition, um HARA-Ergebnisse und Safety Goals zu erzeugen. Er enthielt ein frühes vektorbasiertes Retrieval-Augmented-Generation-System mit festem Document Chunking.
Es war noch ein akademischer Prototyp, zeigte aber, dass KI mehr leisten kann als generischen Text zu erzeugen. Mit dem richtigen Kontext und der richtigen Struktur kann sie Aktivitäten unterstützen, bei denen Ingenieure Produktinformationen interpretieren, Safety-Methoden anwenden und ihre Entscheidungen dokumentieren müssen.
Wir demonstrierten den Prototyp Ronald Melster von Melster Consulting sowie mehreren Fachleuten aus der funktionalen Sicherheit.
Die technischen Ergebnisse waren ermutigend. Noch wichtiger waren jedoch die Gespräche rund um den Prototyp, denn sie machten ein viel größeres Problem sichtbar.
Safety Engineering hängt weiterhin stark von Excel ab
Während und nach der Thesis sprachen wir mit ungefähr 15 bis 20 Engineers, Consultants, Managern und technischen Leitern.
Die Erfahrung reichte von Engineers mit ein oder zwei Jahren Berufserfahrung bis zu Fachleuten mit mehr als 20 Jahren Safety-Erfahrung. Die meisten arbeiteten im Automotive-Umfeld oder in angrenzenden Bereichen.
Obwohl Rollen und Erfahrungsniveaus unterschiedlich waren, wiederholten sich dieselben Themen.
Spezialisierte Tools existierten für einzelne Teile des Safety Lifecycles, wurden aber uneinheitlich eingesetzt. Teams mussten häufig über mehrere getrennte Systeme hinweg arbeiten, während große Teile des Safety-Prozesses weiterhin in Excel stattfanden.
Auch 2026 blieben Spreadsheets ein zentraler Bestandteil der Safety-Arbeit.
Viele der eingesetzten Tools waren außerdem nicht ursprünglich um Safety-Engineering-Prozesse herum gebaut. Requirements-Management-Plattformen wie DOORS können wichtige Teile des Workflows unterstützen, sind aber allgemeine Werkzeuge und keine vollständigen Arbeitsumgebungen für die Beziehungen zwischen Safety-Artefakten.
Das Problem war also nicht einfach, dass Teams keine Tools hatten.
Das Problem war Fragmentierung.
Requirements werden in einem System verwaltet, Hazard Analysis in einem Spreadsheet durchgeführt, Safety Requirements an anderer Stelle dokumentiert und Verification Evidence in einem weiteren Speicherort abgelegt. Prozesse beginnen außerdem an unterschiedlichen Punkten im Projekt, sodass Teams, die an zusammenhängenden Artefakten arbeiten, nicht immer gleichzeitig voranschreiten.
Diese Artefakte hängen jedoch voneinander ab.
Eine Änderung an einer Anforderung kann die Item Definition beeinflussen. Diese Änderung kann wiederum HARA, Safety Goals, Safety Requirements, Verification Activities und weitere nachgelagerte Analysen betreffen.
Wenn Informationen über getrennte Tools verteilt sind, wird es schwierig, diese Beziehungen zu pflegen. Es wird auch schwieriger, KI sicher einzuführen, weil Wissen, Kontext und Prozesshistorie, die KI benötigt, über mehrere Systeme fragmentiert sind.
Daraus entstand die größere Chance hinter AegisSafeForge:
Safety-Wissen, Prozesse und Artefakte in eine vernetzte Umgebung bringen, damit Engineers KI nutzen können, ohne Traceability, Struktur oder Kontrolle zu verlieren.
Im Februar 2026, während die Thesis noch abgeschlossen wurde, begannen wir, AegisSafeForge als Produkt zu formalisieren.
Die Thesis endete im März 2026, aber die Arbeit war bereits über den ursprünglichen akademischen Scope hinausgewachsen.
Die Prinzipien, auf die wir uns früh geeinigt haben
Als wir den Prototyp in eine Plattform überführten, legten wir mehrere Prinzipien fest, die unsere Entwicklungsentscheidungen bis heute prägen.
Das erste Prinzip war: Die Plattform muss auch ohne KI Wert liefern.
Wir wollten nicht, dass AegisSafeForge nur eine dünne Oberfläche um ein Sprachmodell ist. Die zugrunde liegende Plattform musste genug Wert liefern, dass Engineers sie für strukturierte Safety-Arbeit lieber nutzen als Spreadsheets.
Das bedeutete echte Engineering-Workflows: Artifact Registries, Process Models, Requirements Management, Traceability, Collaboration, Review Controls und Evidence Management.
KI soll den Engineering-Prozess verbessern, aber die Plattform soll nicht von KI abhängen, um ihre Existenz zu rechtfertigen.
Das zweite Prinzip war: KI-Ausgaben müssen begrenzt und quellengebunden sein.
Safety Engineering ist zu folgenreich für unkontrollierte KI-Generierung. Gleichzeitig kann ein zu stark eingeschränktes Modell genau die Reasoning-Fähigkeiten verlieren, die es nützlich machen. Die richtige Balance zu finden, war eine unserer wichtigsten technischen Herausforderungen.
Deshalb kombinieren wir Source Grounding, strukturierte Templates, deterministische Checks und workflow-spezifische Guardrails.
Das Ziel ist nicht, einem KI-Modell zu erlauben, beliebige Inhalte zu erzeugen. Das Ziel ist, dem Modell relevanten Engineering-Kontext zu geben, die erwartete Ausgabestruktur zu definieren, deterministisch prüfbare Dinge zu prüfen und das Reasoning für den fachlichen Review zu erhalten.
Vertrauen entsteht nicht dadurch, dass eine KI-Antwort selbstbewusst präsentiert wird. Vertrauen entsteht, wenn Quellen, Reasoning, Beziehungen und Review-Status sichtbar sind.
Das dritte Prinzip war: Menschen müssen die Kontrolle behalten.
AegisSafeForge basiert auf einem einfachen Governance-Prinzip: KI schlägt vor. Engineers prüfen und genehmigen.
KI-generierte Outputs bleiben Vorschläge, bis eine qualifizierte Person sie überprüft und akzeptiert.
Freigaben sind rechtebasiert. Manager können Arbeit direkt freigeben oder Freigaberechte an geeignete Teammitglieder delegieren. Aktionen werden einzelnen Nutzern zugeordnet und aufgezeichnet, damit Teams nachvollziehen können, wer ein Artefakt erzeugt, geändert, geprüft oder freigegeben hat.
KI kann Arbeit beschleunigen, ersetzt aber nicht die Engineering-Verantwortung.
Auf dem Weg zu einer vernetzten Safety-Engineering-Plattform
Seit dem ursprünglichen Prototyp hat sich AegisSafeForge zu einer Multi-Artefakt- und Multi-Industrie-Plattform entwickelt.
Die Plattform enthält heute industriespezifische Standards und Artifact Registries sowie integrierte Process Models wie V-Modell und Wasserfall.
Unterstützte Workflows und Artefakte umfassen HARA, Safety Goals, Functional Safety Requirements, Technical Safety Requirements, Verification Evidence, FMEA, FMEDA, Fault Tree Analysis, Event Tree Analysis, HAZOP, LOPA und die vollständige ISO/SAE-21434-TARA-Analysekette.
Außerdem haben wir grundlegendes Requirements Management für High-Level und Low-Level Requirements eingeführt.
Der Prozess kann mit Requirements beginnen, aus denen anhand relevanter Standard-Templates Item Definitions abgeleitet werden. Diese Item Definitions können anschließend die Grundlage für HARA, FMEA, FTA, ETA und weitere Analysen bilden.
Wichtig ist nicht nur, dass diese Artefakte in einem System erstellt werden können. Wichtig ist, dass sie verbunden sind.
Eine Änderung an einer Anforderung kann die relevante Item Definition invalidieren und nachgelagerte Artefakte markieren, die möglicherweise überprüft werden müssen. Dadurch können Teams die Auswirkungen einer Änderung einschätzen, statt Inkonsistenzen erst viel später im Projekt zu entdecken.
Traceability ist deshalb kein Bericht, der erst am Ende erstellt wird. Sie ist Teil des Arbeitsprozesses.
Zusammenarbeit und Governance für echte Engineering-Teams
Safety Engineering ist kollaborativ, deshalb mussten wir über Single-User-Dokumentgenerierung hinausgehen.
AegisSafeForge unterstützt inzwischen Echtzeit-Zusammenarbeit mit feldbasiertem Locking, um widersprüchliche Änderungen zu reduzieren.
Rollenbasierter Zugriff umfasst aktuell Organisation Administrator, Manager, Team Lead und Engineer.
Freigabeautorität kann je nach Projektverantwortung gesteuert und delegiert werden. Aktionen werden zugeordnet und nachvollzogen, sodass Teams eine klarere Historie darüber erhalten, wie ein Artefakt entstanden ist und wer für wichtige Entscheidungen verantwortlich war.
Diese Funktionen klingen vielleicht wie gewöhnliche Enterprise Features, sind aber wesentlich, wenn KI-unterstütztes Engineering von Prototypen in reale Safety-Projekte übergehen soll.
Ein Artefakt zu generieren ist nur ein Teil des Prozesses. Teams müssen es auch prüfen, hinterfragen, überarbeiten, freigeben und verstehen können, wie es mit dem Rest des Safety Case zusammenhängt.
Aufbau ohne externe Finanzierung
Wir haben AegisSafeForge bisher ohne externe Finanzierung aufgebaut.
Das hat Grenzen gesetzt, aber auch unser Denken geprägt.
Wir mussten sehr genau nach pragmatischen Lösungen suchen, Funktionen priorisieren, die echten Engineering-Wert schaffen, und vermeiden, Technologie nur deshalb zu bauen, weil sie beeindruckend wirkt.
Aus einem akademischen Prototyp Software zu machen, auf die Engineers sich verlassen können, erforderte weit mehr als zusätzliche KI-Prompts.
Wir mussten an Architektur, Retrieval, Berechtigungen, Zusammenarbeit, Traceability, Artefaktbeziehungen, deterministischer Validierung und User Experience arbeiten.
User Experience war dabei besonders wichtig.
Safety Tools sind oft leistungsfähig, aber schwer einzuführen. Wenn eine Plattform mehr Reibung erzeugt als das Spreadsheet, das sie ersetzen soll, kehren Engineers zum Spreadsheet zurück.
Unser Ziel ist deshalb nicht nur ein technisch leistungsfähiges System. Wir wollen eine Umgebung schaffen, in der strukturierte Safety-Arbeit klarer, vernetzter und leichter zu pflegen wird.
Wo wir heute stehen
Das AegisSafeForge MVP ist inzwischen in einem starken Zustand, und wir gehen in eine Phase der Härtung und Verfeinerung.
Wir verbessern Zuverlässigkeit, erweitern die Workflow-Tiefe, stärken unsere KI-Guardrails und bereiten die Plattform auf reale Pilotumgebungen vor.
Wir suchen außerdem Pilotpartner, die die Plattform anhand realer Safety-Engineering-Workflows bewerten und uns helfen zu verstehen, wo sie echten Wert schafft und wo sie noch besser werden muss.
Parallel zu Pilotpartnerschaften bereiten wir uns auf Pre-Seed-Funding vor. Finanzierung würde es uns ermöglichen, Feature-Entwicklung zu beschleunigen, die Industrieabdeckung zu vertiefen und die Go-to-Market-Fähigkeiten aufzubauen, die nötig sind, um das Produkt zu mehr Engineering-Teams zu bringen.
Die langfristige Vision
Unsere langfristige Ambition ist, dass AegisSafeForge zu einer zentralen Arbeitsumgebung für Safety Engineering wird.
Nicht ein weiteres isoliertes Tool, das nur einen Schritt des Prozesses löst.
Nicht ein KI-Assistent, der ohne Projektkontext arbeitet.
Und kein Ersatz für die Engineers, die für Safety-Entscheidungen verantwortlich sind.
Wir wollen den Ort bauen, an dem Requirements, Analysen, Safety-Entscheidungen, Evidence und Freigaben über den gesamten Lifecycle verbunden bleiben und KI sinnvolle Produktivitätsgewinne innerhalb der Prozesse schafft, die Engineers bereits verstehen.
Die Reise begann mit einer Thesis über die Klassifikation von Hazards für automotive Batteriemanagementsysteme.
Dieses enge Problem führte uns zu einem deutlich größeren: Safety-Teams brauchen eine bessere Möglichkeit, Wissen, Prozesse und Entscheidungen zu verbinden.
Wir stehen noch am Anfang dieser Reise, aber die Richtung ist klar.
Safety-Arbeit sollte nicht über Spreadsheets und getrennte Tools fragmentiert bleiben. KI sollte nicht ohne Kontext oder Aufsicht arbeiten. Und Engineers sollten nicht zwischen Produktivität und Vertrauen wählen müssen.
Genau dieses Problem bauen wir AegisSafeForge, um es zu lösen.
Design Partner
Wir nehmen derzeit ausgewählte Pilot- und Design-Partner-Anfragen an.