The Build You Do Not Have To Do

Ask a team what it will take to build an AI system that runs inside a regulated customer's estate, and the estimate usually covers the application. The application is rarely the expensive part. The expensive part is everything that has to exist before the application can be written, and it is almost always discovered rather than planned.

The inventory

Here is what a team building this from nothing has to produce before the first feature of their actual product. None of it is optional in a regulated deployment, and none of it is what the team set out to build.

An inference runtime that runs where the customer is

Not an API client. Something that loads and serves models on hardware the team does not control, with predictable resource behaviour, on machines that vary between customers. This includes the unglamorous parts: model packaging, memory management, graceful degradation on smaller hardware, and behaving sensibly when the estate is smaller than the sales conversation implied.

A knowledge layer over the customer's records

Ingestion across formats nobody standardised, indexing, retrieval that returns the right passage rather than a plausible one, and a re-index path for when the customer's data changes, which is continuously. Then the harder half: making retrieval respect permissions, so the system cannot surface a record to someone who should not see it.

Permissioning and sensitivity tiering

Native to the data layer rather than checked at the interface. If permissioning lives in the application, then every new application re-implements it, and one mistake exposes records the organisation is legally obliged to protect. This is the item most often deferred and most expensive to retro fit.

An audit record that is worth producing

Not logging. A record that a regulator or an auditor will accept: hash chained so alteration is detectable, signed so authorship is provable, with a checkpoint held somewhere the machine cannot rewrite, and verifiable by someone who does not trust the vendor. Building this properly is a specialist cryptographic exercise, and building it improperly is worse than not claiming it.

Entitlement and licensing that survive the air gap

A way to know the software is being used within terms, on a machine with no outbound connection. Every naive answer to this either fails open, which the finance team will not accept, or calls home, which the customer will not accept.

An update path

Shipping a fix to software running inside estates the team cannot reach, without breaking the audit chain, without requiring the customer's network to open, and while supporting more than one version in the field. This is the item teams forget entirely until the first serious bug.

What the inventory actually costs

The honest figure is not a number, it is a shape. Each item above is a small team and a long tail of maintenance, and crucially each one is a place where a mistake is discovered by a customer's security review rather than by a test. The cost is not only the build; it is that the team's attention is spent on infrastructure for the period in which they were supposed to be establishing a product.

“The question is not whether the team could build it. It is whether the eighteen months spent building it are the eighteen months the company has.”

The adoptable half

The reason to draw the inventory out explicitly is that all six items are generic. None of them is specific to the organisation, none of them is where the product's value sits, and all of them have already been built by anyone operating in this category properly. They are exactly the layer that should be adopted rather than rebuilt.

What is not adoptable is the part above the line: the process specific to the organisation, the judgement encoded into it, the interface the users actually touch. That part cannot be bought from anyone, which is precisely why it deserves the whole of the team's attention.

How to use the list

Take it into the next build-or-adopt conversation and price each of the six honestly, including the maintenance tail and the cost of getting the audit record wrong. Then compare that against the cost of licensing a substrate where all six already exist and are inherited by whatever is built on top. The comparison is usually not close, and it is far more useful than a debate about model quality, which is the argument these conversations tend to have instead.