The handover problem: what your team must own before the consultants go

An AI project has two endings. The first is the launch, which everyone celebrates. The second is quieter and comes months later, when a supplier changes a form, a regulation shifts, or a model version gets retired, and the system starts giving worse answers. At that point the question is simple: who fixes it?

If the honest answer is "we'd have to call the consultants back," you didn't buy a system. You rented one, and the meter is still running.

What ownership actually means

Ownership is not a folder of documents handed over on the last day. It is four practical capabilities inside your company.

You can run it: someone knows how to check whether it is working today, and gets told when it isn't. You can change it: someone can adjust a rule, add a document source, or update a prompt without opening a support ticket. You can judge it: someone can tell good output from bad, with evidence rather than impressions. And you can replace it: you know what the system depends on, what it would cost to move, and who else could do the work.

Most handovers deliver the first capability and skip the other three. That is why systems drift.

The documentation that matters

Documentation gets written to satisfy a contract clause, so it describes architecture nobody will ever touch and omits the things people actually need. Keep the list short and insist on these:

• A runbook for failure. The five most likely things to go wrong, how each one looks from the outside, and the first three steps for each. Written for the person on duty, not for an engineer.
• An evaluation set. One hundred to two hundred real cases with the correct answer for each, agreed by the people who do the work. This is the single most valuable artifact of the whole project.
• A change log with reasons. Not just what was configured, but why a rule exists. Rules without reasons get deleted by the next person.
• A dependency and cost sheet. Every model, API, and vendor; what it costs per month; contract renewal dates; what breaks if it disappears.
• A data map. What data goes where, who can see it, how long it is retained. Your legal and security teams will need this without warning.

Everything else is optional. If a document does not help someone run, change, judge, or replace the system, it is decoration.

The three people you need

You do not need to hire a machine learning team. You need three named individuals, and you should name them before the project starts, not during the final month.

A business owner who decides what the system should do and holds the budget. They approve changes and say no to scope creep. This is not a technical role.

A technical custodian who can read the configuration, make a controlled change, test it, and put it into production. Often an existing developer or an IT engineer with capacity carved out. They do not have to build models; they have to be able to modify and deploy what exists.

A quality owner from the department the system serves — the senior claims handler, the lead nurse, the head of support. They maintain the evaluation set and decide what "good" means. Without this role, quality becomes a matter of opinion within weeks.

Total in-house cost: usually a fraction of one full-time role each, once the system is stable. The failure mode is not expense. It is that nobody was named.

Test the handover while you can still complain

Do not accept documentation as proof of transfer. Run a live test in the final weeks of the engagement, while the consultants are still under contract.

Pick a real change — add a new product to the knowledge base, tighten a rule about what the system refuses to answer, swap in an updated pricing table. Ask your own team to make it, with the consultants in the room but silent. Time it. Then have your quality owner run the evaluation set and confirm nothing else broke.

If your team completes that in a day, you own the system. If it takes a week and three questions, you have found exactly the gaps to close before the invoices end. Either result is worth far more than a signed handover form.

Write this into the contract at the start. Handover milestones, a named receiving team, and a supervised change test are all easier to negotiate before work begins than after.

We build this way at Hercules A, and it means our engagements end. That is the point. The measure of a good AI project is not how deeply the consultants are embedded a year later — it is how confidently your own people change the system without calling anyone.