Who Owns the System When the Builders Leave

For two weeks, the reporting team of a private equity group combined a newly acquired company's figures into the group's reports by hand, next to the system built to do it. Six months after handover, the new company's accounts needed one new mapping: a rule saying which of its accounts feeds which line of the group's reports. The team wasn't sure whether they were allowed to add it, who should approve it, or how they'd know if they had broken something. The handover hadn't 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 didn't pass on 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. Our measure now: a handover is only as good as the smallest change the client's team would hesitate to make.

Documents pass on knowledge, not authority

A typical handover pack describes how the system works: its design, how data flows, step-by-step guides for known failures. It doesn't 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 doesn't.

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, an AI instruction or a model version can shift results in cases nobody was looking at. A team that can't see how far a change reaches 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 table makes authority explicit

The core of the handover is now a change table: 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 an allowed margin of difference 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 test cases; if they pass, it goes live.

Changes that need a second person. A new rule for combining the group's figures, a new cause of exception, a margin outside the band, a new approval limit. One person makes it, a named reviewer approves it, and the full set of test cases runs before release.

Changes that need a full retest. A new model version, a new document type, a new kind of source system, a change to what goes through without review. These get a test run with a written comparison of results, and the process owner signs off.

The table 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 hadn't said so.

Every changeable part has a named owner

A part nobody owns can't be changed safely, because nobody can say yes. So every changeable part has an owner on the client's side: the acceptance set (the real cases with known right answers that every change is tested against), the limits and account mappings, the AI instructions, the model version, each connection to another system and its data agreement, 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 lets people who didn't 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 doesn't yet fully own the system.

Changes are rehearsed before the builders leave

Reading how to make a change isn't 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 full retest on a candidate model version. Each goes through the whole process, approvals included.

Before the rehearsals comes the fear inventory. Each owner writes down, privately, the changes they wouldn't make without calling us. The lists are usually short and specific: the AI instruction for mappings, the margin for one awkward portfolio company, anything touching the cash figures. Every item either moves into a column of the table with a procedure and a test run behind it, or it's 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 table says should need a second person anyway.

The rehearsals turn up things a document review misses: a step obvious to the builders and unclear to the people taking over, an approval nobody knew how to give, a test that took longer than a working day allows. Each 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 login, system account and access key is owned by the client and has been changed since we had access.
• AI instructions, limits, mappings and rules live in a version-controlled store the client owns, and every change, from any column of the table, is a small reviewed edit there.
• The client's team can run the full set of test cases on their own systems, within 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 full retest.
• The fear inventory is empty, or every item left belongs in the second column anyway.

Support follows the business calendar

A reporting workflow doesn't need the round-the-clock standby 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 deal that closes. Before you sign off a handover, ask each owner for the smallest change they wouldn't make alone. Whatever they name is the distance still to go.