Putting A Model Inside Someone Else's Product
The engineering questions that decide whether an embedded AI substrate is a partnership or a support liability.

When a company asks whether their software can be powered by someone else's models running on someone else's substrate, the conversation usually starts with capability. That is the least interesting part. The questions that determine whether the arrangement is still working in two years are unglamorous, and they are worth putting on the table in the first meeting rather than the fourth.
Whose version is it
A product ships on a release cycle. A substrate improves on its own. If those two are coupled, every substrate improvement becomes a regression risk in someone else's product, and every product release becomes a negotiation.
The workable answer is that the vendor pins a substrate version, tests against it, and moves when they choose. That means the substrate has to support more than one live version in the field at once, which is a commitment made at the architecture level rather than promised in a meeting. Ask to see how an existing deployment is pinned before believing it.
What happens when it is wrong
Every model is wrong sometimes. The question is what the surrounding system does about it, because that is what the end customer experiences and what the vendor gets the support call about.
- Does a low-confidence answer degrade visibly, or does it return something confident and wrong?
- Is there a path that stages the action for a person instead of executing it, and is that the default rather than an option?
- When the system declines to answer, does the product have somewhere sensible to put that, or does it surface as an error?
- Can the vendor reproduce a specific past answer months later, from the record, without the substrate supplier's help?
The last one matters more than it sounds. If reproducing an answer requires the supplier, then every serious end-customer complaint becomes a three-party investigation, and the vendor has lost control of their own support process.
Entitlement without a phone home
Licensing an embedded substrate has an obvious tension. The supplier needs to know it is being used within terms. The end customer bought the deployment precisely so that nothing leaves their estate. A licence check that calls out reintroduces the dependency the arrangement existed to remove.
Binding entitlement to the customer's hardware resolves it: the licence is enforceable locally, verifiable at audit, and requires no outbound connection. It is a small design decision that decides whether the sovereignty claim survives contact with the commercial terms.
“A sovereignty claim that a licence check can break was never a sovereignty claim. It was a deployment preference.”
Audit inheritance
If the substrate carries a tamper evident record, everything built on it should inherit that automatically rather than each product implementing its own logging and hoping it satisfies a regulator. Inheritance is the difference between the vendor being able to say the product is auditable and the vendor having to build an audit feature.
It also changes what the vendor can sell. An application that can produce a signed, offline-verifiable record of what it did is a different proposition to one that produces a log file, and the vendor did not have to build the difference.
The support boundary
Draw it explicitly and draw it early. The vendor supports their product. The substrate supplier supports the substrate. The hard cases are the ones that look like both, and the only workable arrangement is a named escalation path with a response commitment on each side, agreed before the first joint customer rather than during the first joint incident.
Why any of this is affordable
The reason a vendor can consider this at all is that the substrate is finished rather than notional. The sovereign operating system, the inference runtime, the orchestration, the permissioning and the audit record already exist and already carry fourteen production ready studios, with a further forty nine in development on the same platform. The vendor is adopting something load bearing rather than co-developing a foundation, and the mechanisms underneath sit behind 104 filed UK patent applications carrying 2,340 claims.
None of that removes the five questions above. It just means they are the only questions left, which is a considerably better position than the one that starts with building an inference stack.