How to Scope an AI Pilot That Actually Reaches Production
The short answer: scope the pilot to finish a workflow, not to prove a capability. Most AI pilots succeed by their own measure and still never ship, because “the model works” was never the thing standing between a demo and production.
Pick a workflow, not a capability
“Can we use AI on our support tickets?” is a capability question, and it produces a demo. “Can we route and draft first responses for refund requests, end to end, without a human retyping anything?” is a workflow question, and it produces something that can go live.
The difference is where the boundary sits. A capability pilot ends at the model output. A workflow pilot ends where the work actually ends — in the system of record, with the status updated. The distance between those two points is where almost all real projects die.
Decide the failure mode before the success metric
Everyone specifies what happens when the system is right. Far fewer specify what happens when it is wrong, and that omission is what blocks the production decision.
Answer three questions up front. How does the system know it is unsure? Who sees it when that happens? What is the cost of a wrong answer that nobody catches? A workflow where mistakes are cheap and visible can ship with modest accuracy. One where they’re expensive and silent needs a review step designed in from the start — and it’s much cheaper to design it now than to bolt it on after a stakeholder demo has raised expectations.
One integration, not four
Whatever else you cut, cut the number of systems the pilot touches. Every additional integration adds credentials, rate limits, data mapping, error handling and someone else’s release calendar — none of which is the AI, and all of which is the schedule.
If a workflow genuinely spans four systems, that is a signal to fix the plumbing first. Connected, consistent data is the precondition, which is why our engagements tend to start with data readiness rather than a model.
Name the owner on day one
A pilot without a named production owner is a research project with a deadline. The owner decides what “good enough” means, absorbs the workflow change into their team, and has budget authority when the pilot works. Without one, a successful pilot simply has nowhere to go.
Write the exit criteria down before you start, and keep them short: the accuracy the owner will accept, the volume the system must handle, and the date the decision gets made either way. A pilot that can be extended indefinitely usually is, and an extended pilot is just an expensive way to avoid deciding.
Scoping this way is how we run product engineering and AI consulting engagements — small, bounded, and pointed at production from the first week. If you have a pilot that stalled, or one you’d rather not stall, book a free audit.
