The most replaceable part of your AI system is the model
Ask an industrial company what makes its AI capability defensible and you will usually hear about the model. Which foundation model, fine-tuned how, on what data.
This is the one part a competitor can also buy.
Foundation models are converging in capability and collapsing in price. The gap between the best available model and the third-best is narrower every quarter, and the cost of a given level of capability falls by roughly an order of magnitude a year. Whatever advantage you hold today because you picked well is an advantage with a shelf life measured in months.
Meanwhile the parts nobody puts on a slide — the workflow the system sits inside, the domain vocabulary it reasons over, the evaluation harness that tells you whether it is working, the integration with the ERP and the PLM and the historian — took years, cannot be bought, and get more valuable with use.
That asymmetry is the whole argument.
What actually compounds
Four things accumulate value in a way model choice does not.
Proprietary workflow and data. Not “we have a lot of data” — everyone says that and most of it is unusable. What matters is data generated by the workflow the system participates in: which recommendations were accepted, which were overridden and why, what the operator did instead. That exhaust exists only if you built the system to capture it, and it is the input to every subsequent improvement.
Domain ontology and context. A general model does not know that in your plant a “batch” means something different from what it means in the supplier’s system, or that three part numbers refer to the same physical component for historical reasons. Encoding that is unglamorous, slow, and specific to you. It is also the difference between a system that works in a demo and one that works on a Tuesday.
Evaluation. More on this below, because it is the one most often skipped.
Integration and operational reliability. The distance between a working prototype and a system that runs unattended inside a regulated industrial process is enormous, and almost none of it is model work. It is permissions, failure modes, audit trails, fallbacks, latency budgets, and what happens at 3am when an upstream system returns something unexpected.
None of these transfer to a competitor when the model they are using becomes available to everyone. All of them get better the longer you run.
Evaluation is the underrated moat
Most organizations cannot answer a simple question about their AI system: is it working better than it was last month?
Not “does the demo impress people.” Whether task completion improved, whether human rework went down, whether the cost per accepted result fell, whether it degraded on the edge cases that matter.
Without that, every decision becomes an argument between people with opinions, and improvement is a matter of luck. With it, you have a loop: change something, measure, keep what worked. The organization that can run that loop weekly pulls away from the one that runs it by committee, and the gap widens rather than closing.
This is also what makes the model swappable in practice rather than in principle. If you can measure quality, you can evaluate a new model in an afternoon and switch when it wins. If you cannot, you are married to whatever you chose first, because nobody can prove the alternative is better.
Evaluation is what converts a falling model price into your margin instead of your vendor’s.
Why this gets ignored
The system is harder to talk about than the model. “We are building on the latest frontier model” is a sentence a board understands immediately. “We are investing in an evaluation harness and a domain ontology” sounds like overhead.
It is also harder to buy. There is a vendor for the model. There is no vendor for the specific way your maintenance workflow actually operates, and the consultants who claim otherwise are selling you a template.
And it pays back on a slower clock. Model upgrades produce a visible jump. Systems work produces a capability that compounds quietly and only looks obvious in retrospect.
Where this argument is weakest
Three honest objections.
Sometimes the model really is the moat. If you are a frontier lab, or you hold genuinely unique training data in a narrow domain — protein structures, seismic traces, decades of proprietary process telemetry — then a specialized model can be the asset. This argument is about industrial companies applying AI, not about companies whose product is a model.
“The system is the moat” can become an excuse. It is a comfortable thesis for an organization that does not want to do the work of adopting better models. Switching costs are real, but they should be an engineering problem to reduce, not a reason to stay three generations behind. If your system makes model changes painful, that is a defect in the system, not evidence for the thesis.
Systems ossify. The ontology that encodes your domain today encodes your assumptions today. Heavy investment in workflow and integration can become the legacy that prevents the next change — the same way carefully built ERP customizations became the thing nobody could move off. A moat and a trap have similar geometry.
What to do now
Five things, roughly in order, none of which require picking a model first:
- Instrument before you optimize. Build the evaluation harness before the capability it measures. It feels backwards and it is the highest-return sequencing decision available.
- Keep the model layer swappable by design. Vendor-neutral interfaces, no provider-specific assumptions leaking into business logic. Assume you will change models twice in the next eighteen months, because you will.
- Invest in the context layer, not the model layer. Retrieval, domain vocabulary, the mapping between how your systems name things and how people name things. This is where the durable work is.
- Measure cost per accepted result, not benchmark scores. A system that is right 95% of the time but whose output always gets checked has a very different economics than one that is right 90% of the time and trusted.
- Do not build a platform until you have three use cases. Platforms built for one use case are architecture fiction. Platforms extracted from three real ones tend to be right.
The uncomfortable version of this argument: most of the durable work in industrial AI is not AI work. It is the same systems, data and process engineering that was undervalued before the models arrived — and is now the only part that stays scarce.
