The handover nobody scheduled between pilot and production

Who takes over, and on what date?

Read down the dates in the plan for any AI pilot: kickoff, build, demonstration, closing review, final invoice. Every one of them is a date the project team needs. The day another group becomes answerable for the system isn't there, because the team has no use for it and never thinks to write it down.

So each party assumes. The sponsor figures the function that will use the system has it in hand. The function figures the sponsor arranged something. The platform group has heard of the pilot and hasn't been asked. The handover then happens by default, as people leave. Access is withdrawn with the contract, the team's channel goes quiet, and the system carries on producing answers. Exhibit 1 sets the project calendar against what the system needs and marks where the plan stops naming dates.

How a handover that looks complete falls apart

Here is a composite, built from patterns we see and not drawn from one client. A legal department pilots a model that sorts incoming contracts by type and flags unusual clauses. It works on exports a paralegal prepared by hand. The closing review goes well. On the last day the operations lead receives a repository link, a slide deck, a recording of the demonstration and an administrator login. By any reasonable reading, the work has been handed over.

Some weeks later the contract management system is updated and one of its export fields is renamed. The model keeps running. For one type of contract it now finds fewer unusual clauses, because the field it leaned on arrives empty. A lawyer notices that the flags look thin and asks whether the tool is any good. The operations lead can't tell whether the model got worse, the data changed or the contracts did. The person who decided how the exports were cleaned is on another engagement and answers when time allows. The answer arrives after the lawyers have written the tool off and gone back to reading everything.

Nothing in the repository was wrong. What was missing was the knowledge that a cleaning step existed, why it mattered, which field it depended on, and how anyone would find out when it broke. That knowledge sat in the team's heads and left with them. The repair takes an afternoon once someone knows where to look. The users' trust takes longer, and it doesn't come back on the same terms.

What actually has to pass across?

A folder holds the easy part. Code, the model or a vendor product's configuration, credentials and documentation can be copied, checked and signed for. A handover that stops there looks complete on paper.

The rest is knowledge and standing. There is operating knowledge: what the system does badly, which inputs defeat it, what healthy data looks like beside unhealthy data, and the small routine that keeps it going. There are decisions and the reasons behind them, such as the exceptions agreed with the business and the approaches tried and dropped. Without the reasons, a receiver will reverse a decision without knowing what it protected, or defend one without being able to say why. There are relationships: who uses the output, who supplies the data, who gets told when the output is wrong, who approves a change. And there is authority, the right to change the system, pause it and switch it off without first asking the people who built it.

Very little of this was written down, because the team never needed it written down. It lived in conversations in the same room. A handover turns those conversations into something another person can use.

Can the receiver do these without calling the team?

• Explain what the system is for and where it's known to be weak
• Say where each input comes from and what a healthy one looks like
• Work out within a working day whether a bad answer came from the model, the data or the process
• Make a small change and release it by the written route
• Pause the system and bring it back
• Name who must hear when the output is wrong, and tell them

How do you rehearse a handover?

Swap the seats. For a stretch before the team's brief ends, the receiver drives and the team watches. The team walks the receiver through the controls once, then hands over the keyboard. The receiver makes a real change and releases it by the written route. Then the team plants a fault, a renamed field in the input, say, and the receiver takes it from the first sign through diagnosis to a fix. The team answers questions and does nothing else. Exhibit 2 shows who does what, including the sponsor's part: signing the takeover on what was seen, not on a document.

What has to be true for the rehearsal to count?

The brief and the calendar have to back it. The team's contract should say the engagement ends when the rehearsal is passed, not when the build is finished, so a team that has stopped building hasn't stopped working. And the overlap needs a place on the calendar and in the budget from the start, because an overlap added late is the first thing a slipping schedule removes.

If the rehearsal finds gaps, it has done its job. The date moves, and the gaps get closed while the people with the answers are still around. If it finds none, you hold the only real evidence that the handover happened.

What goes on the plan?

Make the takeover the plan's first milestone, dated, with the receiver's name beside it, before the build begins. A name, not a role and not a team: a role can be vacant and a team can disagree about who answers. The receiver needs time in the calendar, access to the systems, and authority to change or pause the system without asking permission of those who built it. When any of those is missing, supplying it is the sponsor's job, which is why the sponsor sits in on the last session.

The same date applies when a vendor runs the system. The receiver is then whoever manages the vendor: the person who knows what the contract covers, what vendor support will and won't do, and how to tell whether a change on the vendor's side altered the behavior. A bought system has a handover too, and the buyer is the one who receives it.

A dated takeover also disciplines the pilot. The team starts writing for a reader. The scope shrinks to what a named person can carry. Questions that production would have asked anyway turn up while they are cheap: where the data comes from, who hears when the output is wrong, how the system gets stopped.

The public frameworks lean the same way without speaking of pilots. The NIST AI Risk Management Framework 1.0 asks that post-deployment monitoring plans are implemented, including incident response, recovery, override, decommissioning and change management (MANAGE 4.1), and that roles and responsibilities are documented and clear to the individuals and teams concerned (GOVERN 2.1). A rehearsal is a cheap way to learn whether change, fault handling and pausing exist when they are needed, with the people who understand them still in the building. NIST describes the framework as voluntary.

We haven't measured any of this. It is what delivery work shows: the systems that carried on after the team left had receivers who had already done the work, and the ones that stalled had been handed a folder.