AI Won't Save MBSE - But It Might Make It Usable

Every struggling MBSE deployment has the same hopeful refrain from leadership: “Don’t worry, AI will fix it.”

It’s a comforting idea. The tools are hard to use? AI will generate the models. The learning curve is brutal? AI will flatten it. Nobody reads the models? AI will translate them. The promise is that if we just layer enough machine learning on top of the current tooling, all the problems we’ve spent seven weeks diagnosing in this series will simply dissolve.

This is mostly wrong. But it’s wrong in an interesting way - because some of it is right, and the distinction matters enormously for where the industry goes next.

The marketing machine is ahead of the engineering

Open any MBSE vendor’s 2025-2026 roadmap and you’ll find “AI-powered” features prominently displayed. Established vendors have announced AI hubs, copilot-style assistants, and generative design capabilities woven into their platforms. Smaller vendors pepper their pitch decks with “LLM-powered” and “intelligent” features.

But look past the press releases and ask: what do these tools actually do today?

The most mature AI offerings in the space focus on requirements quality analysis, traceability detection, and natural language search across engineering artifacts. These are genuinely useful capabilities. The AI can flag ambiguous requirements, suggest missing trace links, and help engineers find relevant artifacts in large repositories. These tools integrate with existing requirements management and modeling platforms to provide contextual assistance within existing workflows.

What it does not do is “generate system architecture.” It does not take a set of stakeholder needs and produce a validated functional decomposition. It does not synthesize a component architecture from a requirements set. These capabilities - the ones the marketing implies - are years away from being reliable enough for safety-critical engineering.

This matters because the gap between what AI can do and what vendors imply it can do is creating a dangerous expectations deficit. Organizations are delaying hard decisions about tooling and process - “let’s wait for the AI features” - while the underlying accessibility and integration problems continue to compound.

What AI actually does well today

Strip away the hype and there’s a solid set of capabilities where AI is delivering real value in systems engineering right now. They share a common characteristic: they augment human judgment rather than replacing it.

Requirements quality analysis

Natural language processing can evaluate requirement statements against quality criteria - atomicity, measurability, ambiguity, passive voice, escape words like “etc.” and “as appropriate.” Several vendors now offer this capability, and the results are real. These tools catch the kind of quality issues that human reviewers miss after their third hour of requirements review. Studies from aerospace organizations have shown that AI-assisted requirements review catches 20-30% more defects than manual review alone.

Traceability detection

This is perhaps the highest-value AI application in MBSE today. AI can analyze a corpus of engineering artifacts - requirements, design documents, test cases, code - and suggest trace links that should exist but don’t. Given that incomplete traceability is the number one finding in most system audits, the impact here is substantial. The AI doesn’t create the trace links authoritatively; it proposes them for engineer review. That distinction is critical.

Test case generation

Given a requirement with clear acceptance criteria, AI can generate draft test procedures - not production-ready, but a starting point that saves 40-60% of the initial authoring time. When combined with formal requirement structures like those in SysML v2, the generated test cases are increasingly useful as first drafts.

Natural language search and retrieval

Large engineering repositories are notoriously hard to search. Traditional keyword search fails because the same concept is expressed differently across documents, models, and code. Semantic search - using embeddings to match on meaning rather than exact text - makes it possible to ask “where do we handle brake system failure modes?” and get relevant results from requirements, hazard analyses, and test plans simultaneously.

Change impact analysis

When a requirement changes, AI can traverse the trace network and identify downstream artifacts that are potentially affected - design elements, test cases, interface definitions. This is tedious work that engineers currently do manually (or skip entirely, leading to “suspect links” that nobody reviews).

What AI does poorly - and may never do well

Here’s where the conversation gets uncomfortable for the vendor marketing teams.

Generating system architecture

System architecture is not pattern matching. It is judgment under uncertainty, balancing competing concerns (performance, safety, cost, schedule, manufacturability) with incomplete information. When an experienced systems engineer decomposes a system into subsystems, they’re drawing on domain knowledge, organizational context, regulatory constraints, manufacturing capabilities, and decades of failure analysis.

LLMs can generate something that looks like a functional decomposition. It will have boxes and arrows. It will use the right vocabulary. And it will be subtly, dangerously wrong in ways that only a domain expert would catch - because the model has no understanding of the physical system, the operational environment, or the failure modes that actually matter.

In safety-critical domains, “mostly right” is not a useful category. An architecture that is 95% correct and 5% wrong is not 95% useful. It is potentially catastrophic, because the 5% will be the non-obvious interactions and edge cases that are the entire reason we do systems engineering in the first place.

Validating model correctness

AI can check syntax. It can verify that a model conforms to a metamodel. What it cannot do is validate that a model correctly represents the system it claims to describe. That requires domain knowledge, stakeholder alignment, and physical-world verification - none of which are tractable for current AI systems.

Replacing engineering judgment

Every vendor who puts “AI-powered” in their feature list needs to answer one question: who is accountable when the AI is wrong? In aviation, the answer is the Design Approval Holder. In automotive, it’s the OEM under ISO 26262. In defense, it’s the program office. None of these organizations will - or should - delegate engineering judgment to a system that cannot explain its reasoning in terms the domain demands.

The real opportunity: AI as accessibility bridge

Here’s what gets lost in the hype cycle: the single biggest problem in MBSE isn’t that models are hard to create. It’s that models are hard to access.

We covered this in Week 2 - MBSE tools were designed for modelers, not for the 90% of stakeholders who need to consume, review, and contribute to model data. A program manager shouldn’t need to learn SysML to understand whether their system is on track. A safety analyst shouldn’t need a three-day training course to trace hazards to requirements.

This is where AI can be transformative - not by generating models, but by making models accessible to everyone who needs them.

Natural language interaction with models is the unlock. Imagine asking “Show me all safety requirements that trace to the braking subsystem and don’t have verification evidence” - and getting an answer in seconds, with links to the relevant model elements. No SysML fluency required. No tool expertise needed. Just a question in plain English and a structured, trustworthy answer grounded in the model.

This isn’t science fiction. The building blocks exist today: semantic understanding of model structure, natural language processing, and structured query generation. The SysML v2 API specification - with its standardized REST endpoints and query services - makes this architecturally feasible in ways that proprietary tool APIs never did.

The real AI revolution in MBSE won’t be artificial intelligence replacing engineers. It will be artificial intelligence making engineering data accessible to everyone in the organization. That accessibility is what breaks the priesthood problem we described in Week 6. It’s what connects models to the daily work of people who don’t (and shouldn’t) think in metamodels.

The risk: AI washing

There’s a darker side to the AI-in-MBSE conversation, and it needs to be named directly: AI washing.

AI washing is when a vendor wraps a thin LLM integration around an unchanged product and calls it “AI-powered.” The UI is still hostile. The integration story is still broken. The learning curve is still months. But now there’s a chatbot in the corner that can answer basic questions about the tool’s own documentation.

This is not AI-powered MBSE. This is a support chatbot.

The risk is that AI washing gives organizations permission to avoid the harder work of actually fixing their tools and processes. “We added AI” becomes a substitute for “we redesigned the experience.” The fundamental problems - the accessibility crisis, the integration gaps, the maturity blindness - remain unsolved, just slightly papered over with a conversational interface.

Honest AI integration looks different. It looks like quality checking that runs continuously, not just when someone remembers to click “analyze.” It looks like traceability suggestions that appear in context, during the act of engineering, not in a separate dashboard. It looks like intelligent defaults that learn from organizational patterns, reducing the mechanical effort of model creation without obscuring what the model actually says.

The human-in-the-loop imperative

There’s a principle that should govern every AI feature in every MBSE tool: AI proposes, engineer disposes.

This isn’t just a philosophical preference. In regulated industries - and most industries where MBSE matters are regulated to some degree - there are legal and ethical requirements for human accountability in engineering decisions. ISO 26262 requires that safety goals be set by qualified engineers. DO-178C requires that design decisions be traceable to human judgment. INCOSE’s own frameworks emphasize the role of systems thinking - a distinctly human capability.

AI should be a force multiplier for human engineers, not a replacement. It should reduce the drudgery - the manual trace link maintenance, the requirement quality checking, the boilerplate test case authoring - so that engineers can spend more time on the work that actually requires their expertise: making judgment calls about architecture, safety, performance, and trade-offs under uncertainty.

The best AI features will be the ones engineers forget are AI. Not because they’re invisible, but because they’re woven so naturally into the engineering workflow that they just feel like “the tool working well.” Suggestions that appear at the right moment. Quality checks that run in the background. Search that actually finds what you’re looking for.

That’s the AI future worth building toward. Not artificial intelligence that replaces systems engineering, but augmented intelligence that makes systems engineering accessible, efficient, and trustworthy.

The model is still the source of truth. The engineer is still the authority. AI just makes sure that more people can access the truth and that the authority has better information to work with.

---

This is Part 8 of “The MBSE Reckoning,” a 10-part series from Luvian on the state and future of Model-Based Systems Engineering.

In this series: Part 1: The Breaking Point · Part 8: AI Won’t Save MBSE (You are here) · Part 9: Models That Run · Part 10: A Practitioner’s Manifesto

Subscribe to our newsletter to get each article as it publishes.