Why we hand the system back

Here is a story you have probably lived. A vendor ships an AI system. It demos beautifully. Six months later it is still running, but only because the vendor is still running it. Every retrain goes through them. Every config change goes through them. When the data drifts, you wait for their ticket queue. The system works, for as long as you keep paying the people who built it.

That system was never delivered. What you signed for was a dependency, and in machine learning that is the default outcome.

The model is the small part

The intuition that gets clients into trouble is that the model is the product. It is not. In a real-world ML system, only a small fraction of the code is the machine-learning code itself; the surrounding infrastructure (data collection, feature extraction, configuration, serving, monitoring) is vast and complex.¹ Google’s own MLOps guidance adopts the same point and states the operational thesis bluntly: the real challenge is not building the model but building an integrated system and continuously operating it in production.²

This matters because the maintenance burden sits in everything around the model. The same research frames ML systems through the lens of technical debt and finds it is common to incur massive ongoing maintenance costs in real-world deployments, driven in part by the outside world’s background rate of change.¹ The data keeps moving after launch, so the system that was correct on day one becomes wrong without anyone changing a line of code.

The model can be handed over in an afternoon. Everything that keeps it correct has to be handed over on purpose.

The last mile is where ownership is won or lost

The gap between a model that works in a notebook and a system that works in production is the last mile of ML, and it is where most engagements quietly fail to transfer ownership. Google describes the lowest maturity level of ML operations as one where the model-building and operations teams are disconnected, which is the source of handoff failures, training-serving skew, and silent model decay.²

That disconnection is exactly what a vendor relationship institutionalises. When the people who built the system and the people who must run it are different organisations, the seam between them becomes permanent. Every operational decision has to cross a contract boundary. The client’s team never learns to operate the system, because operating it is what the vendor sells.

The cost of not owning it

The cost is rarely on the invoice. It shows up later, in three forms.

1. 01

   Lock-in and switching cost. A system wired into proprietary services and formats becomes expensive and difficult to move. NIST warns that non-interoperable applications create the danger of isolated islands of cloud solutions and vendor lock-in, and treats workload and data portability as the standards-based remedy.³ Ownership has a plain test: can the workload and the data move somewhere else? As long as the answer is no, whoever hosts them sets the terms.

2. 02

   Bus factor. Operational knowledge concentrates dangerously fast. The truck factor is the minimal number of developers who must leave before a project is incapacitated, and an empirical study of 133 popular systems found 65% have a truck factor of two or lower.⁴ When the vendor is the only party who understands the pipeline, your bus factor is effectively zero on your own side of the table.

3. 03

   Compounding dependency. Every change you cannot make yourself is a paid request in someone else’s queue. Retrains, config changes, drift fixes: the older the system gets, the more of these there are, and each one widens the gap between what the vendor knows about your system and what your team does.

None of this is exotic. Each risk follows predictably from treating the model as the deliverable and the system as the vendor’s private property.

Handover is the product

We take the opposite position. The deliverable is a documented, governed system your team owns and operates without us. By that standard the model is a milestone and the demo is a rehearsal. Handover is the design constraint from the first commit.

Concretely, that means transferring four things deliberately, throughout the engagement instead of saving them for the last sprint.

1. 01

   Documentation that matches reality. Architecture decisions, data contracts, and runbooks written as the system is built, so they describe what is actually deployed rather than what someone remembers. A wiki assembled the week before we leave fails that test.

2. 02

   A governance posture you own. Onshore residency, zero-retention, and row-level isolation are configured in your accounts, under your control, and none of it is bolted onto ours. The compliance story survives our departure intact.

3. 03

   Operational knowledge, transferred by doing. Your engineers run the retrain, trip the alert, and fix the drift while we are still in the room. Nobody learns a runbook by watching someone else follow it. This is the direct countermeasure to a low bus factor: spread the operational knowledge across your team before we go.⁴

4. 04

   Portability by construction. Standard formats, movable workloads, no hidden umbilical to our infrastructure. The portability that NIST prescribes against lock-in is built in from the start,³ so there is nothing to retrofit under duress later.

This is the Immerse, Spot, Execute loop run to completion: we immerse until we know the system you actually run, we spot the piece that belongs in production, and the execute step is not finished until your team can carry it alone. The loop ends where it should, with us unnecessary.

We’d rather you not need us again

Most AI never reaches production. The part that does is mostly the surrounding system; the model is the small fraction of the code.¹ A system counts as delivered only when someone other than its builder can keep it alive. A handover that leaves you dependent has failed. The invoices just take a while to say so.

So we hand all of it back: the documentation, the governance posture, the operational knowledge, and the option to walk away from us. A good engagement ends with your team running the whole system; a long tail of billable support is evidence of the opposite. If you call us back, it should be by choice, from a team that could have managed alone. We would rather you not need to.