Why "Powerful" isn't Enough: Making AI Reliable in Requirements Engineering

In regulated, complex system development, AI needs more than capability; it needs control.

Powerful Isn't the Same as Reliable

Ask almost any engineering leader today whether AI belongs in their development process, and the answer is yes. Ask them whether they actually trust it inside their requirements, design, and testing workflows, and the answer gets a lot more careful.

That hesitation is well-founded. In complex system development, especially in regulated environments, the bar isn't "does the AI produce something useful?" It's "can we trace it, verify it, defend it, and repeat it?" Those are very different questions, and most AI tools haven't been built with them in mind.

The real challenge: AI that fits the way engineering actually works

Most AI tools today are built to be generally helpful. Engineering teams don't need generally helpful; they need AI that understands their domain language, respects their rules, and produces artifacts that downstream tools and reviewers can actually use.

In our work with requirements and systems engineering teams, the same friction points keep surfacing:

• Fragmented language. Requirements, domain concepts, business rules, and test scenarios live in different tools, in different formats, described in different ways. AI inherits that fragmentation and amplifies it.

• Tools that don't talk to each other. One AI assistant drafts a requirement; another generates test cases, and a third reviews for quality. Without shared artifacts and formats, each one operates in its own little world, and small inconsistencies pile up faster than reviewers can catch them.

• No safety net. AI output without structured human review is a liability, not an accelerator, especially when compliance, traceability, or safety is on the line.

What "reliable AI" actually looks like in practice

Reliability isn't a property of the model. It's a property of the system you build around it. In our experience, four things make the difference:

A shared information model. When requirements, domain concepts, rules, and scenarios are unified under one model, AI has a stable foundation to reason against, and humans have a single source of truth to review against.

Standardized artifacts and formats. This is what lets different AI tools "speak the same language." Domain-specific models and dictionaries turn loose, general-purpose AI into something that behaves consistently across the lifecycle.

Tool add-ons that combine AI support with quality controls. AI in the loop is only valuable if quality is in the loop too. The two need to be designed together, not bolted on afterwards.

A genuine human-in-the-loop approach. Not as a checkbox, but as a workflow, one that fits the requirements tools your teams already use, and gives reviewers leverage rather than more work.

Put together, these aren't just safeguards. They're what turns AI from an interesting experiment into something you can confidently deploy across product and system development, and, just as importantly, defend in front of an auditor or a safety case.

Going deeper on June 15

If this is the kind of problem you're working on, or thinking about working on, we'd love to have you join us for a practical session on exactly this topic.

Together with Time People Group, we're hosting a webinar on Reliable AI in Complex System Development. Anders Ekman, Lasse Mikkonen, Heike Schneider, and Stefan Lundequist will walk through how this works in practice, including live demonstrations of tool add-ons and human-in-the-loop workflows across different requirements tools.

It's aimed at the curious, and at teams working with AI for requirements, product and system development in regulated environments, requirements/PMO/quality functions, and tool and consulting partners exploring co-delivery.

📅June 15 | 11:00 AM (CEST)

Register to secure your spot →

Celeris Consulting