COMPLIANCE BY DESIGN: BUILDING AI FOR SAFETY-CRITICAL ENGINEERING

AI is entering safety-critical engineering at a time when the regulatory bar is rising. The EU AI Act, the Cyber Resilience Act, ISO 26262, ISO/SAE 21434, and related standards are all pointing in the same direction: software-driven systems must become more transparent, more secure, more traceable, and more accountable.

For engineering teams, this creates both pressure and opportunity. AI can reduce repetitive work, accelerate analysis, and help engineers navigate complex safety and cybersecurity workflows. But in regulated domains, speed alone is not enough. The real challenge is using AI without introducing a new layer of unreviewed, untraceable risk.

At AegisSafeForge, this question is central to how we are building the platform. We do not believe AI should replace engineering judgment. We believe AI should support engineers, reduce blank-page syndrome, and help teams work more consistently while keeping human experts firmly in control.

That is what we mean by compliance by design.

The Problem with Black-Box AI in Regulated Engineering

In safety-critical domains, an AI-generated answer is not enough. A hazard analysis, TARA, FMEA, safety goal, or derived requirement cannot simply be accepted because an LLM produced something that sounds plausible.

Engineers need to know where a suggestion came from, which source context influenced it, who reviewed it, whether it was changed, who approved it, and which downstream artifacts depend on it. Without this level of control, AI becomes difficult to trust in real engineering workflows.

That is why AegisSafeForge is not being built as a generic chatbot for engineering documents. It is being built as a governed engineering workflow platform for safety and cybersecurity analysis.

AI Can Draft. Deterministic Logic Must Verify.

One of our core architectural principles is the separation between probabilistic AI assistance and deterministic engineering logic.

AI can help draft hazard descriptions, operational situations, cybersecurity scenarios, requirement suggestions, and supporting analysis. But safety-critical calculations and structured decision logic should not depend on a model's opinion.

For example, in an ISO 26262 workflow, the AI may help propose context for a HARA row. But ASIL-related evaluation should be handled through deterministic backend logic based on defined rules and matrices. The AI assists the engineer, but it does not silently become the decision-maker.

This distinction matters because regulated engineering depends on reproducibility, reviewability, and accountability.

Human Approval Is Not a Checkbox

Human-in-the-loop is often treated as a UI feature. At AegisSafeForge, we treat it as a governance requirement.

AI-generated outputs are not considered final artifacts by default. They enter the system as suggestions that require review, editing where necessary, and explicit approval before they can become accepted engineering content.

This is important because accountability in safety engineering cannot be delegated to an AI model. The engineer must remain responsible for the decision, and the platform should make that responsibility visible, structured, and auditable.

Traceability Must Be Built Into the Workflow

Auditors and engineering reviewers do not only care about the final answer. They care about the path that led to that answer.

That is why traceability is a core part of the AegisSafeForge platform. Every AI-assisted suggestion should be connected to its relevant engineering context, including item definitions, uploaded documents, source references, and the surrounding workflow state.

Our audit trail is already part of this foundation. Actions such as AI generation, edits, review steps, approvals, and state transitions are stored in the database so teams can reconstruct how an artifact evolved over time.

For regulated teams, this is not just a convenience feature. It is the foundation of trust.

Data Sovereignty Matters

Safety and cybersecurity engineering often involves highly sensitive intellectual property. Item definitions, system architectures, security assumptions, hazards, threats, and technical mitigations are not documents that companies can casually send into uncontrolled environments.

That is why AegisSafeForge supports both local-first/on-premise deployment and a future SaaS model. For early enterprise use cases, on-premise deployment is especially important because it gives organizations more control over infrastructure, data boundaries, model execution, and integration with internal security requirements.

We are already working with local model execution through tools such as Ollama and llama.cpp, including models such as Qwen and Llama, while keeping the architecture flexible enough to support cloud-based models where customers explicitly choose that route.

The principle is simple: customers should control where their engineering data goes.

Building for Our Customers' Compliance and Our Own

AegisSafeForge is being built to help engineering teams manage safety, cybersecurity, and regulatory workflows with more structure, traceability, and control. But we also recognize that we are not only building a tool for compliance. We are building a platform that must itself operate responsibly within a changing regulatory environment.

That means we have to think about our own obligations from the beginning. As AI regulations mature, software vendors will increasingly need to demonstrate how their systems handle human oversight, transparency, cybersecurity, data governance, auditability, and risk management.

For us, this is not something to postpone until the rules are fully settled. It is part of the architecture we are building today.

By designing AegisSafeForge around human approval, deterministic verification, traceable AI suggestions, audit logs, and controlled deployment options, we are creating a stronger foundation for our own future compliance journey as well. The regulatory environment will continue to evolve, but platforms built with governance at the core will be better prepared than systems that try to retrofit compliance later.

We cannot credibly build compliance tooling for others if we treat our own compliance as an afterthought. That is why transparency, accountability, traceability, and responsible control over AI-assisted workflows are not only product features for us. They are operating principles.

Preparing for the AI Act, CRA, and Tool Qualification

Compliance is not a one-time checkbox. It is an ongoing engineering discipline, both for the teams using AegisSafeForge and for us as the platform provider.

Our roadmap includes a dedicated regulatory applicability workflow, which we see as a Step 0 for engineering teams. Before starting a HARA, TARA, FMEA, or other safety/cybersecurity workflow, teams should be able to evaluate whether a product may fall under frameworks such as the Cyber Resilience Act, the EU AI Act, or other relevant regulations and standards.

This matters because many teams struggle not only with compliance execution, but with the earlier question: Which obligations apply to this product in the first place?

We are also researching our obligations and roadmap around ISO 26262 Part 8 tool qualification. Our focus is to build the foundations early: documented workflows, traceability, audit logs, review controls, deterministic verification, and clear separation between AI assistance and approved engineering decisions.

We are not claiming that AI removes the need for expert review. We are building the platform around the opposite belief: expert review is what makes AI usable in regulated engineering.

Our View

The future of safety and cybersecurity engineering will not be “AI replaces engineers.” It will be AI assists, deterministic systems verify, human experts approve, and audit trails preserve the evidence.

That is the direction we are building toward at AegisSafeForge.

We will continue documenting our compliance journey openly on our blog, including how we approach the AI Act, CRA, ISO 26262, ISO/SAE 21434, data governance, and trustworthy AI architecture.

Because in safety-critical engineering, the real question is not whether AI can generate an answer. The real question is whether that answer can be reviewed, traced, challenged, and approved.

We will soon publish our product roadmap and share more details about our compliance-by-design architecture. If you are working on safety, cybersecurity, or regulatory engineering workflows and want to explore an early pilot, we would be happy to connect.