Who Owns the System When the Builders Leave

For two weeks, the reporting team of a private equity group consolidated a newly acquired company's figures by hand, next to the system built to do it. Six months after handover, the new company's accounts needed one new mapping into the group's reporting layer. The team was unsure whether they were allowed to add it, who should approve the change, and how they would know if they had broken something. The handover had not named an owner for the mappings, so they changed nothing until their head of portfolio reporting called us.

The handover documents were complete and accurate. They did not transfer what ownership needs in practice: the confidence and the authority to change the system without asking the people who built it.

We changed how we hand over after that call. The measure we use now: a handover is only as good as the smallest change the client's team would hesitate to make.

Documents transfer knowledge, not authority

A typical handover pack describes how the system works: architecture, data flows, runbooks for known failures. It answers "how does this work". It does not answer the questions a team asks when the business changes: may we change this, who has to agree, how will we know it still works, and what do we do if it does not.

With AI systems, that hesitation is reasonable. Sculley and colleagues at Google named the reason in "Hidden Technical Debt in Machine Learning Systems" (NeurIPS 2015): changing anything changes everything. A mapping, a prompt or a model version can shift results in cases nobody was looking at. A team that cannot see the blast radius of a change is right to hesitate.

Without those answers, a careful team does the careful thing, which is nothing. The system freezes in its handover-day shape while the business keeps moving. A frozen system can look like a success until it is quietly replaced by a spreadsheet.

The change matrix makes authority explicit

The core of the handover is now a change matrix: the kinds of change the business will need, and for each, who may make it and what must happen first. It has three columns.

Changes the team makes alone. Adding a mapping for a company's accounts, adjusting a tolerance within a band the controller approved, adding a reason code, updating a routing table. The system checks the change against its limits and runs the relevant acceptance cases. If they pass, it goes live.

Changes that need a second person. A new consolidation rule, a new exception cause, a tolerance outside the band, a new approval threshold. One person makes it, a named reviewer approves it, and the full acceptance set runs before release.

Changes that need re-qualification. A new model version, a new document type, a new kind of source system, a change to what goes straight through. These get a qualification run with a written comparison of results, and the process owner signs off.

The matrix is short, specific to the system and signed by the process owner. It turns a vague sense of risk into a rule anyone can look up. The mapping in that phone call belonged in the first column, and the handover had not said so.

Every changeable part has a named owner

A part nobody owns cannot be changed safely, because nobody can say yes. So every changeable part has an owner on the client's side: the acceptance set, the thresholds and account mappings, the prompts, the model version, each integration and its data contract, the exception causes and reason codes.

Owners are roles with a named person and a deputy, so a job change reassigns the role instead of orphaning it. The acceptance set matters most, because it is what lets people who did not build the system change it with confidence. Whoever owns it owns the ability to change everything else. So the set has to run without the builders: if it needs their environment, their scripts or their knowledge, the client does not yet fully own the system.

Changes are rehearsed before the builders leave

Reading how to make a change is not the same as having made one. In the last weeks of every engagement, the client's team makes a real change from each column while we watch and stay quiet: a mapping added alone, a rule added with a reviewer, a qualification run on a candidate model version. Each goes through the full process, acceptance run and approvals included.

Before the rehearsals comes the fear inventory. Each owner writes down, privately, the changes they would not make without calling us. The lists are usually short and specific: the mapping prompt, the tolerance for one awkward portfolio company, anything touching the cash figures. Every item ends in one of two places. Either it moves into a column of the matrix with a procedure and an acceptance run behind it, or it is a gap in the handover and we close it before we leave. The inventory is repeated in the last week. The handover is done when the lists are empty or every remaining item is a change the matrix says should need a second person anyway.

The rehearsals turn up things a document review misses. A step that was obvious to the people who built it and unclear to the people taking it over. An approval nobody knew how to give. A test that took longer than a normal working day allows. Each one gets fixed while the builders are still around.

What has to be true on the last day

An engagement ends when these hold, not on a date:

• Every credential, service account and API key is owned by the client and has been rotated since we had access.
• Prompts, thresholds, mappings and rules live in a repository the client owns, and every change, from any column of the matrix, is a small reviewed difference in it.
• The client's team can run the full acceptance set on their own infrastructure, in a working day.
• Someone on the client's side is named to decide what happens when the model provider retires the version in use, and has done one qualification run.
• The fear inventory is empty, or every item left on it belongs in the second column anyway.

Support follows the business calendar

A reporting workflow does not need the round-the-clock on-call a public website needs. It needs someone available when the reporting team works, and more so in the days before a board pack is due. The handover names the first responder on the client's side during business hours, what they may do without escalating, and the escalation path during reporting week.

Ownership is the ability to change

A client owns an AI system when its own people can change it at the pace the business changes, and in a group that buys companies, the business changes with every closing. Before you sign off a handover, ask each owner for the smallest change they would not make alone. Whatever they name is the distance still to go.