Pilot to Production: The Mid-Market AI Playbook

Why your AI pilot passes the demo and stalls before production

You have a pilot that works. It answers correctly on the cases you showed it. Someone senior watched a run and liked it. Then it stops moving. The step from AI pilot to production is where most mid-market AI programs die, and the model is almost never the thing that kills them. Integration kills them, ownership kills them, and above all the missing pass mark kills them. Nobody agreed in advance what good enough to ship meant, so nobody can say the pilot passed.

That is the conclusion. The rest of this is how to avoid it. A system built to demo has to be rebuilt to run. A system built to run needs one workflow, one owner, one number, and a threshold set before the first test case.

The pattern shows up in the research. MIT's Project NANDA, in its 2025 GenAI Divide report, found that roughly 95% of generative AI pilots produced no measurable return. The same report tracked enterprise-grade systems through the funnel: 60% of organizations evaluated one, 20% ran a pilot, and 5% reached production. The collapse is not between idea and pilot. It is between pilot and production.

What the numbers say about pilots that reach production

Read those three together and the shape of the problem is clear. Deloitte's State of AI in the Enterprise 2026, a survey of 3,235 business and IT leaders, found only 25% had moved 40% or more of their pilots into production. McKinsey's State of AI 2026, covering 1,719 respondents, found 37% attribute at least some EBIT impact to AI. So a minority are shipping, and a minority of those can point to earnings.

The third number explains the first two. Grant Thornton's 2026 AI Impact Survey of 950 senior leaders found 55% of CIOs and CTOs report fewer than half their core applications are AI-ready. The pilot ran on an export. Production has to run on the system that holds the record. That gap is not a modelling problem and no amount of prompt work closes it.

Deloitte also found 54% expect to reach 40% or more production deployment within three to six months. Intent is not the constraint. Readiness is. If your core systems cannot be reached programmatically, start at data and systems readiness and stop calling the delay an AI problem.

What has to be true before a pilot is allowed to become production

Seven things. If any one of them is missing, the pilot is not ready, and shipping it anyway is how you end up with a system nobody owns.

1. One workflow, named precisely. Not customer service. One queue, one document type, one motion. Scope you can describe in a sentence is scope you can test.
2. One owner with a number on their sheet. A person, not a committee. If the workflow gets faster and nobody's target moves, nobody will defend it in month four.
3. One number, written down before the build. Resolution rate, cycle time, cost per case, error rate. One. Agreed in writing, by name, with a date.
4. Access to the real systems. If the pilot ran on CSVs somebody exported by hand, the hard part is untested. Authentication, rate limits, stale records and permissions are the work.
5. A test set of 100 to 300 real cases. Pulled from the last 90 days of actual volume, including the malformed ones, the duplicates and the ones a human got wrong.
6. A pass mark set before the test runs. Set it after and you will move it. Everyone does.
7. Controls that cost money to skip. Spend limit, retry limit, kill switch, and a human in the loop wherever an error costs money.

Which workflow should go to production first?

Pick the wrong first workflow and you will spend the credibility you needed for the second one. The candidates that survive contact with production share four traits. Score each one you are considering out of four, and start with the highest.

1. Volume you can count. Hundreds of cases a month, not dozens. Below that the saving is real but too small to measure, and anything you cannot measure you cannot defend at renewal.
2. A repeatable shape. The cases differ in content but not in structure. Invoices vary. Invoice processing does not. A workflow where every case is its own project is a hiring decision, not an automation one.
3. A recorded outcome. Somebody already writes down what happened: the ticket was closed, the invoice was coded, the lead was qualified. That record is your test set and your baseline. Without it you are guessing at both.
4. A cost of error you can name. If a mistake costs a refund, you know where the human belongs. If nobody can say what a mistake costs, nobody will agree what accuracy is worth, and the pass mark conversation goes in circles.

Four out of four is where to start. Two or less is a workflow to revisit after the first one is running and the organization believes you. The temptation runs the other way, toward the most visible process rather than the most testable, and that choice is why a lot of first deployments are also last ones.

How do you set a pass mark you can actually defend?

Baseline the humans first. You cannot judge a system against a standard you never measured. Take the same 100 to 300 cases, work out what your current process does on them, and set the threshold relative to that. A pass mark expressed as a percentage with no baseline underneath it is decoration.

Two rules make the threshold hold. Write it down with a date and a name against it. And test on cases the build never saw, held back from the start. A system tuned on the test set will pass the test set and fail in week two.

What does production need that your pilot did not?

A pilot fails quietly and a person notices. Production fails at 2am, on a Saturday, in a loop, spending money. Every control below exists because that has happened to somebody.

Most organizations know they are short here. Grant Thornton's 2026 survey found 78% lack strong confidence they could pass an independent AI governance audit within 90 days, leaving 22% who have it. The same survey found just 20% have a tested AI incident response plan. Not a written one. A tested one. If you are shipping an agent that can spend money or send messages, the plan for the day it misbehaves is part of the deliverable, not a follow-up project. That is the work we do under governance, evaluation and measurement.

How long does AI pilot to production take, and what does it cost?

For one workflow in a mid-market company, plan on weeks, not quarters. The sequence we run is the same every time.

1. Weeks 1 to 2. Pick the workflow, name the owner, agree the number and the pass mark. Get read access to the real systems. Pull the 100 to 300 case test set.
2. Weeks 3 to 6. Build against the live systems, not a copy. Run the test set weekly. Fix what fails. The pass mark does not move.
3. Weeks 7 to 8. Ship to a bounded group with spend limits, retry limits, a kill switch and human review on the expensive paths. Measure against the number.
4. Monthly, after that. Review the log, add the new failure modes to the test set, and re-run it. Systems nobody maintains repeat their mistakes.

Cost splits into build and run. Our packages start at $999 a month, and the run cost is the part most budgets forget. A workflow with no monthly owner degrades, because the inputs change even when the model does not. Scope the build honestly and the run cost stops being a surprise. Details of each service line are on services, and what this looks like at 50 to 2,000 people is on mid-market.

What makes it take longer is rarely the AI. It is access. Waiting on credentials, on a security review, or on a system that has no API is what turns eight weeks into six months.

What if the pilot already shipped and it does not work?

Then do not scale it. Scaling a system that fails on a meaningful share of cases produces more failures, not fewer. Diagnose first, and be willing to reach one of three verdicts.

1. Fix. The design is sound and the failures cluster in one place: a data field, a prompt, one integration. Bounded work with a clear end.
2. Rebuild. The failures are spread across the workflow, or the system was built without a test set, so no change can be shown to help. Rebuilding against a pass mark is faster than patching in the dark.
3. Retire. The workflow was the wrong candidate. The volume is too low, the cases are too varied, or a rule would have done it. Retiring costs a write-off. Keeping it costs the write-off plus every month it runs.

Our AI Rescue is a 48-hour triage that ends in that written verdict, with what each path costs. Read-only access, one person who knows what the system was supposed to do, and 20 to 50 real cases.

The honest version of pilot to production is unglamorous. One workflow. One owner. One number. A pass mark set before the test. Controls that assume failure. Then a monthly hour spent keeping it true. Out of the pilot, into production, onto the P&L.