MICKAI®ArticlesYour Product, Our Substrate
Article · 4 September 2026

Your Product, Our Substrate

For software companies whose customers will not accept a cloud dependency inside the product they are buying.

Author
Micky Irons
Published
4 September 2026
Follow Micky Irons
LinkedInX
Sovereign AIOEMSoftware companiesBespoke systems
Your Product, Our Substrate

There is a specific way a good software company loses a deal it should have won. The product is right, the demonstration goes well, the buyer wants it, and then the security questionnaire asks where the AI inference happens. The answer is a cloud API, the buyer is a bank, a hospital trust or a defence supplier, and the deal quietly stops progressing.

The problem is not the product

This is worth separating carefully, because the instinct is to assume the product needs more features. It usually does not. What has happened is that a dependency the vendor treated as an implementation detail has become the buyer's primary objection, and it sits at a layer the vendor did not think they were selling.

The vendor is now caught between three bad answers. Strip the AI features out and lose the differentiation they were built for. Tell the customer the data is fine in the cloud, which is a legal argument the vendor is not qualified to win and does not want to own. Or build their own inference stack, which means becoming an infrastructure company in order to keep being an application company.

The fourth answer

The fourth is to license the substrate. The product stays the vendor's: their interface, their workflow, their brand, their roadmap, their customer relationship. What changes is what sits underneath the AI features. Instead of an outbound call to a shared cloud endpoint, the inference runs on a sovereign runtime deployed inside the customer's own estate, grounded on that customer's own records.

From the end customer's point of view, the questionnaire answer changes from a paragraph of assurances to a demonstration: disconnect the network and the product still works. That is a materially different conversation, and it is usually a shorter one.

A vendor should not have to become an infrastructure company in order to keep being an application company.

What the substrate has to do to be worth licensing

Not every arrangement described as an on-premise option actually solves the vendor's problem. Some simply move the operational burden onto the vendor and call it sovereignty. The useful test is whether these are true.

  • The inference runs on the customer's hardware with no call home, and that can be demonstrated with the network physically disconnected.
  • Entitlement is bound to the customer's hardware, so licensing is enforced without a phone-home check that reintroduces the dependency.
  • The audit record is inherited rather than implemented, so every consequential action the product takes is already hash chained, signed and checkable off box.
  • Permissioning and sensitivity tiering exist below the product, so the vendor is not asked to invent a governance model for someone else's regulated data.
  • The vendor keeps their own product surface. If the substrate imposes its interface on the customer, the vendor has not licensed infrastructure, they have become a reseller.

Where the line sits commercially

The arrangement only works if the boundary is explicit at the start rather than discovered during renewal. The workable split is that the vendor owns their product and their customer relationship, the substrate remains Mickai intellectual property and is licensed, and the knowledge layer built from the end customer's data belongs to that end customer. Three parties, three clear holdings, written down before the first deployment.

The alternative, leaving it implicit, produces the argument every OEM relationship eventually has: who owns the improvement, who owns the data, and who the end customer belongs to. It is cheaper to answer those in a contract than in a dispute.

The honest limits

This is not free of work for the vendor. Their product has to be able to run where the customer's estate is, which for a pure cloud application is a real engineering change rather than a configuration flag. Support becomes a shared responsibility with a boundary that has to be agreed. And a sovereign deployment has a capital cost that a per-seat cloud product does not, which changes the vendor's pricing conversation as well as their architecture.

What it removes is the largest item: the vendor no longer has to build, secure, certify and maintain an inference substrate to sell into regulated markets. That was never the product they wanted to build. It was the toll on the road to the customers they wanted to reach.

Subscribe
Get every new Mickai article by email.

Long-form essays on sovereign AI from Micky Irons. One email per article. No tracking, no marketing, no third parties. Every email includes a one-click unsubscribe link.

Prefer RSS? Subscribe at /articles/feed.xml.

Originally published at https://mickai.co.uk/articles/your-product-our-substrate. If you operate in a regulated sector or want sovereign AI on your own hardware, the audit form on mickai.co.uk is the entry point.
More articles