Your AI pilot worked. Who owns Monday morning?

The demo went well. Someone uploaded a folder of supplier contracts, asked the assistant to compare payment terms across all of them and got a clean, useful table in under a minute. People nodded. Then the operations director asked the question nobody had prepared for: “Who deals with it when a contract is missing?”

A pause. Then: “We’ll work that out in the rollout.”

That moment is where a lot of AI programmes quietly stall. The pilot proved the model could do the task. It didn’t prove the organisation could run the task every day, with real documents, real exceptions and real people on leave. Those are different achievements, and only the second one changes the business.

Two owners, not one

Every AI service needs a technical owner, the person who keeps it running and manages changes. That part usually gets sorted. What gets skipped is the business owner: the person who decides whether an answer is good enough, which cases go to a human and what success means in the operating budget.

In a small team one person might wear both hats. That’s fine. What isn’t fine is nobody wearing the second one.

The business owner also protects you from measuring the wrong thing. Count generated summaries and you’ll get a lovely upward chart, even if buyers now spend longer fixing those summaries than they used to spend writing their own. Measure from the moment a usable request arrives to the moment a buyer accepts the result. That’s the number that tells you whether anything improved.

Google Cloud’s 2025 DORA research describes AI as an amplifier of an organisation’s existing strengths and weaknesses. It studies software teams, not procurement, so don’t read it as a forecast for your buyers. But the question it raises travels well: which weakness in your current process will faster output expose first?

Rehearse a bad day before you invite more users

Most pilots are tested on good days. Clean documents, cooperative data, a specialist sitting next to the user. Before you widen access, run a bad day on purpose.

Give the team a supplier with two near-identical legal names. An expired contract. A document the buyer isn’t allowed to see. A request that needs information nobody has loaded. Then watch where the work goes. A polite refusal is often the right outcome. A confident answer about the wrong supplier is the one to worry about.

Keep those awkward cases as a standing test and run them again whenever something changes: the model, the retrieval rules, the source data, the prompt. Sign-off for one configuration isn’t sign-off for every version that follows it.

Write down the fallback while it’s still easy to think about. Can a buyer finish the comparison by hand if the service is down? Can you find every output produced during a faulty release? Who can switch off access while you investigate? NIST’s AI Risk Management Framework gives you a lifecycle way to think about these risks. The specific checks above are our own application of it, not a universal checklist.

Fund the work around the answer

Here’s the part that rarely makes it into the business case. Someone has to keep the documents current, review who can see what, support confused users, rerun the evaluations and handle the exceptions. That work is permanent. If it isn’t budgeted while the pilot team is still around, it lands on whoever sits closest to the customer or the deadline. Usually both.

Be precise, too, about what a successful pilot actually permits. A limited release to trained users might be justified long before a broad one. A waiting list of keen colleagues is evidence of interest. It isn’t evidence of readiness.

Make the next funding decision a specific one

When the sponsor comes back for rollout money, ask them to bring four things: a named process owner, an agreed definition of a finished task, the results of the bad-day exercise and an honest estimate of the running cost. Then compare the new service with the current process, including the current process’s own errors and delays. The AI doesn’t need to be perfect. It needs to be better in a way you can see.

Governed data can make an answer trustworthy. The decision, and the work that follows it, still belongs to you.