The organisations that get value from AI are not the ones with the most pilots. They are the ones with the fewest unowned ones.
Funding a pilot is a governance decision
A pilot is not a free experiment. It consumes attention, data access, vendor time, and political capital. When pilots multiply without a funding gate, organisations collect impressive demos and little operating change. The corrective is not hostility to experimentation. It is a short list of demands that make a pilot worth the spend.
This article is deliberately not another explanation of why a model is not an operational system. That architectural gap matters, and it deserves its own treatment. Here the focus is commercial: what a board, MD, or budget holder should require before approving the next pilot — so money buys learning that can become a production path.
Leaders who skip these demands often discover the cost later: duplicated tooling, confused operators, security exceptions granted “just for the pilot”, and a narrative that “AI does not work here”. Usually AI was never given a fair operating chance. The funding process failed first.
Demand one: a named operating owner
Every funded pilot needs a person who owns the business outcome after the demo ends. Not a steering committee. Not “the AI working group”. A named role who will live with the workflow on a normal week — including exceptions, complaints, and the dull maintenance that follows novelty.
Without that owner, pilots optimise for people who can attend lunchtime demos. Exceptions go nowhere. Handover never happens. Sponsorship from a director is necessary but not sufficient. If nobody will own the changed work, do not fund the pilot.
Ask the candidate owner: will you change how your team works if this succeeds? If the answer is hesitant, the pilot is entertainment. Also ask who covers them when they are on leave.
Demand two: a bounded decision or workflow
Ask: which decision or handoff changes if this works? Qualify an enquiry. Draft a first-pass pack for human review. Flag incomplete onboarding files. Rank exceptions for a supervisor. The answer should be specific enough to measure within the pilot window.
If the proposal only promises “explore generative AI for productivity”, you are funding curiosity. Curiosity belongs in training budgets and sandboxes, not the same governance track as operational delivery. Write the bound on one line and keep it visible in every pilot review.
Demand three: data, tools, and permissions — in writing
Pilots die quietly when access arrives late. Leaders should require a one-page access plan: which systems, which fields, which actions the pilot may take, and what is explicitly out of bounds. Irreversible actions need human approval by design.
If legal, security, or IT cannot commit to that plan within the pilot window, the schedule is fiction. Fund discovery of access constraints first, or reduce scope to data you already control. Include retention and logging expectations on the same page.
Demand four: evaluation that operators recognise
Define success before kickoff with operator measures: time to complete, completeness, exception rate, rework, and willingness to use the path without a shadow process. Model benchmarks inform engineers; they are not enough for a business funding decision.
Also define failure. A pilot that cannot meet the bar should stop cleanly with a short learning note. Stopping is a success mode when it prevents larger waste. Invite two operators who were not on the build team to score outputs against the current process.
Demand five: a production path sketch
You do not need full architecture on day one. You do need a credible sketch: where the capability would live, who supports it, how it is monitored, how audit works if relevant, and what must be true to leave pilot status. Delivery assurance starts here.
Vendors and internal teams who resist this sketch are signalling that the pilot is the product. Treat that as a risk. If the sketch depends on an unfunded platform programme, say so — conditional paths are fine; hidden dependencies are not.
A funding checklist leaders can paste into the meeting
Before approving budget, confirm the following. If any item is missing, fund discovery — not a production-shaped pilot.
- Named operating owner and executive sponsor.
- Single bounded workflow or decision statement.
- Written data, tool, and permission plan with out-of-bounds list.
- Pre-agreed evaluation measures and explicit stop criteria.
- Sketch of production ownership, monitoring, and support.
- Clear distinction between assisted drafts and automated actions.
- Timebox, learning report date, and decision forum for go/no-go.
How these demands change vendor conversations
With the checklist in hand, demos become easier to judge. Ask vendors to walk the bounded workflow, not the feature tour. Ask who handles exceptions in their reference stories. Ask what access successful pilots actually used. Ask what stayed manual on purpose.
Internal teams benefit too. Engineers get clearer acceptance criteria. Operators get a voice before the tool arrives. Finance gets a stop date. Procurement can attach the checklist to statements of work so “pilot success” is not left to storytelling.
How Microcorem uses these gates
Microcorem’s AI product engineering and delivery assurance work treats pilots as gated learning, not theatre. If a client wants a prototype sprint, we still insist on the owner, the bounded path, and the evaluation — because scaling without those proofs only scales confusion.
Leaders who adopt these demands do not slow innovation. They stop paying twice: once for the demo, and again to rebuild trust after an unmanaged pilot lands in production by accident.
A practitioner note before you spend
A final operating note for practitioners: write the workflow in one sentence an operator would recognise; name the owner who will live with exceptions; list the systems that hold truth today; decide which actions stay human because they are irreversible or commercially sensitive; choose three measures that would convince a sceptical supervisor; and only then select mechanisms — rules, integrations, assisted drafting, or models. Revisit the same checklist after the first production week. If operators invent a shadow path, the design failed even if the demo looked polished. Prefer a thinner finished path over a broader unfinished programme. Keep British spelling in documentation your UK teams will maintain. Resist invented benchmarks; report only measures you can observe in your own operations. When in doubt, reduce scope until ownership and evaluation are honest. Document decisions in plain language, keep the fallback path visible, and schedule a go/no-go review with the operating owner present. Treat delivery assurance as part of the work, not an afterthought once enthusiasm fades. Document decisions in plain language, keep the fallback path visible, and schedule a go/no-go review with the operating owner present. Treat delivery assurance as part of the work, not an afterthought once enthusiasm fades. Document decisions in plain language, keep the fallback path visible, and schedule a go/no-go review with the operating owner present. Treat delivery assurance as part of the work, not an afterthought once enthusiasm fades. Document decisions in plain language, keep the fallback path visible, and schedule a go/no-go review with the operating owner present. Treat delivery assurance as part of the work, not an afterthought once enthusiasm fades. Document decisions in plain language, keep the fallback path visible, and schedule a go/no-go review with the operating owner present. Treat delivery assurance as part of the work, not an afterthought once enthusiasm fades. Document decisions in plain language, keep the fallback path visible, and schedule a go/no-go review with the operating owner present. Treat delivery assurance as part of the work, not an afterthought once enthusiasm fades.
Closing
Fund AI pilots that can name their owner, their workflow, their access, their measures, and their path beyond the demo. Everything else is optional theatre. The organisations that get value from AI are not the ones with the most pilots. They are the ones with the fewest unowned ones.
