A friend of mine, an engineer who builds systems modeling tools, sent me a note a couple of weeks ago about two projects he's juggling.
One is using AI to help build the models at the core of model-based systems engineering (MBSE), the methodology that lets you design a complex system, like an aircraft or a medical device, as a set of interlocking models instead of a mountain of documents. The other is, in effect, the reverse: using the discipline of systems engineering to manage the AI itself, its access rights, its decision boundaries, and its behavior over time.
He was candid about where each project actually stands. AI can help build a model faster, but it's nowhere near a reliable tool for the production work itself. It's still full of limitations. The second project, managing AI as a governed system in its own right, hasn't even been started yet, because, in his words, it sits outside the rules of the game his organization currently plays.
I found myself turning that distinction over for days afterward, because it's actually the same question I ask, implicitly, almost every company I evaluate: Is AI the end here, or is it the means?
Two very different approaches wearing the same word
The first kind of company builds AI into the product itself. The AI is the capability being sold: computer vision that identifies a threat, a diagnostic model reading a medical scan, a fraud-detection system approving or blocking a transaction in real time. Here, AI is the end. It's what the customer is buying, and everything about the company - its certification path, its testing regime, and its liability exposure - has to be built around the fact that the product's core function is a model whose behavior is not fully deterministic.
The second kind of company builds a product that has nothing to do with AI at all - an armor plate, a radar component, a medical device, a trading platform - and uses AI internally to design it, test it, document it, or manufacture it faster and cheaper than its competitors can. Here, AI is the means. The customer never sees it, never has to trust it, never has to certify it. What they get is a company that ships faster, iterates faster, and prices more competitively because AI is compressing the engineering, testing, and manufacturing cycle behind the scenes.
Both of these get pitched as "AI-enabled." They are not similar, and they carry almost opposite risk profiles.
Why the distinction matters more in highly regulated industries
In most commercial sectors, this ambiguity is mostly a marketing nuisance. In highly regulated industries - defense, aviation, medical devices, and financial services - it's significantly more important, for a reason that is specific to how these industries actually work: procurement and approval cycles are long, certification is unforgiving, and trust, in the literal sense of trusting a system with human life or a person's life savings, is not something you can iterate your way into after deployment.
A company where AI is the end has to clear a much higher bar before a single unit reaches the field. Explainability, robustness against adversarial manipulation, behavior under conditions the model never saw in training - all of that becomes part of the product's certification burden. This is not an engineering nice-to-have. This is a significantly higher risk profile, but not a reason to avoid these companies.
Some of the most important innovations of the next decade will come from exactly this category. However, it does mean the timeline to revenue is longer, the technical risk is real, and the regulatory path is still being written in real time - across every jurisdiction where these systems are built and deployed.
A company where AI is the means faces almost none of this friction. This is the part I think gets underappreciated. If your organization uses AI to accelerate systems engineering, manufacturing, or testing, to compress a design-review cycle from months to weeks, to catch a flaw in a model before it becomes an expensive physical prototype, you are moving faster than your competitors without asking any customer to certify a neural network. This speed is a competitive advantage, and it's one that's much harder for a competitor to copy than a product feature, because it's baked into how the organization works, not what it sells.
What investors are actually looking for
When evaluating a company that operates in a highly regulated industry, investors look for both kinds of the AI story.
For companies where AI is the end, the question is whether they understand, and have budgeted for, the actual cost of getting an AI-enabled capability through certification and into the field. A model that performs beautifully in a lab and a model that a customer will actually trust in an operational, mission-critical environment are separated by a gap that a lot of founders badly underestimate.
For companies where AI is the means, the question is whether the efficiency is real and structural, or just a slide in the pitch deck. Are employees actually using AI-assisted tools daily inside their systems engineering, testing, supply chain, and their manufacturing in a way that shows up in cycle time and cost? Or is it a proof of concept that ran once, worked well enough to mention to investors, and never got embedded into how the company actually operates? The gap between “we used AI to do this once” and “AI is now part of how we build everything” is enormous, and it's exactly the gap my friend was describing between AI as the end and AI as the means.
Back to the voice note
What struck me most about my friend's update was the honesty. He didn't oversell this genuinely useful tool, and he didn't pretend the harder, more ambitious project was further along than it is. That kind of clarity - about which category of AI you're actually building and how far along it really is - is rarer than it should be, and it's exactly what separates a company that investors want to back from one that's borrowed a buzzword to describe an old idea.
AI as the end and AI as the means are both valuable things to build. The mistake I see most often is not knowing which one you're actually pitching. And, derivatively, building your roadmap, your certification strategy, and your investor deck as if the other one were true.