How to run a six-week forward-deployed AI pilot that reaches production

Most AI pilots do not fail. They just never end. A demo impresses, the pilot extends, and a year later nothing has changed in daily work. The fix is structural: a short, fixed window, a narrow scope, and a decision at the end that someone has committed to making.

Here is the plan we use.

Week 1: scope and baseline

Pick one step in one workflow. Not “customer service”, but “drafting the first reply to a shipment-status email”. Agree the measure: minutes per case, errors per hundred, holds per month. Record the baseline from real data, not estimates. Name the owner who will make the week-six decision, and get access to the systems and people involved.

Week 2: a thin working version

Build the smallest version that does the step end to end on live data, with a review screen in front of it. It will be rough. That is the point: the fastest way to learn what the model gets wrong is to let the people who do the work see it on their own cases.

Weeks 3 and 4: run beside the current process

The system proposes, a person approves or corrects, and the correction is logged. Keep the existing process running so nobody is exposed. Every day you collect three things: how often the proposal was accepted, where it was wrong, and how long review took. Fix the failure modes in order of cost.

Week 5: measure and harden

Compare against the baseline on the agreed measure. Add the boring parts that make it safe to keep: monitoring, access control, an audit log of proposals and decisions, a way to turn it off. Write the runbook with the person who will operate it.

Week 6: decide and hand over

Present the numbers, the failure modes and the cost to run. The owner decides: keep as is, widen to the next step, or stop. All three are good outcomes if the decision is made on evidence. If it is “keep”, the customer’s team runs it from here, with the builders on call rather than in the loop.

Mistakes that keep pilots in demo

• Scoping a theme (“AI for operations”) instead of a step.
• Building on sample data because production access was “coming”.
• Skipping the review screen, so nobody trusts the output and nobody logs corrections.
• Measuring satisfaction instead of the number agreed in week one.
• Letting the pilot extend without a decision date.