AI Pilot to Production: A Go-Live Checklist for Small Businesses
The demo worked, and then the pilot stalled. Seven gates an AI tool has to pass before your team can rely on it every day, with a way to check each one yourself.
The pilot worked. It drafted replies to the test emails and everyone in the room nodded. That was in the spring. Today it sits in a browser tab that one person opens now and then, and the job it was meant to take over is still done by hand.
For a small business, production means the tool does its job on a normal Tuesday with real customers and nobody watching over it. The checklist below covers the seven gates between the demo and that Tuesday, and each item says how to check it yourself.
Where pilots get stuck between the demo and daily use
A demo shows the tool at its best. Daily use shows it at its worst, on the odd request that lands at 5:45 on a Friday. Pilots that never make it across usually fail in one of these ways.
The demo ran on hand-picked data. Someone chose twenty clean examples. Real inquiries arrive with typos, missing details and attachments it can't read.
Nobody owns the switch-over. The person who built the pilot moved on, and nobody retired the old way of doing the job. So the old way kept running and the new tool became optional.
Nobody decided what happens when it's wrong. Without a review step or a fallback, the first bad answer in front of a customer ends the trust. Staff go back to doing it themselves and don't mention it.
Nobody worked out the bill at real volume. Usage fees that looked trivial in testing look different after a full month of traffic.
The people who'd use it weren't involved. They first saw it on launch day, didn't know what it was allowed to do, and worked around it.
Nobody defined "working". Without a measure agreed in advance, the pilot can't pass or fail, so it stays "in testing" for months.
To catch these before a build starts, use the pre-start checklist for AI projects.
How to run this checklist
Go through the gates in order with two people: the person who will own the tool and someone who will use it every day. Mark each item yes, no or "don't know". Count a "don't know" as a no.
You don't need every gate green before anything goes live. You do need every gate green before the tool runs without someone checking its work. A project with three red gates is still a pilot, and you should keep calling it one.
Gate 1: a named owner and the process it replaces
Every AI tool that sticks has one person whose job includes making it work, and one existing process that it replaces. Without the second, you've added a step instead of removing one.
| Check | How to check it |
|---|---|
| One named owner | Ask "who do I call when it gets something wrong on a Saturday?" If the answer is a team or a vendor, there is no owner. |
| The owner has time for it | Look at their calendar. If no hours are set aside for the first month, the job will lose to everything else on it. |
| The process it replaces is written down | Write the current steps on one page. If you can't, the tool has nothing clear to take over. |
| The old way has an end date | Pick the date the manual process stops, put it in the calendar and tell the team. |
Gate 2: real data and the awkward cases
Before rollout, the tool has to see what your business actually produces.
| Check | How to check it |
|---|---|
| Tested on a week of real input | Pull last week's actual emails, forms or invoices, not examples someone wrote for the test. Run all of them through and count how many it handled correctly. |
| The awkward cases are in the test | Ask the person who does the job today for the ten requests they dread most. Run those too. |
| One source of truth for each answer | For every fact the tool relies on, such as prices, policies and opening hours, name the one document or system that is correct. |
| Someone keeps that source current | Each source has a person's name and a review date next to it. |
If the third row is a struggle, start with a source-of-truth list for your business data. It takes about an afternoon.
Gate 3: what happens when it's wrong
The tool will get things wrong. What matters is whether you find out before your customer does, and what happens next.
| Check | How to check it |
|---|---|
| A person approves outputs at first | Decide which outputs need sign-off in the first weeks. Customer-facing messages, prices and anything with legal weight usually do. |
| It hands over instead of guessing | Give it a few requests it shouldn't handle. It should pass them to a person. |
| Work still flows when it's down | Switch it off for an hour on a test day. Check whether the work still reaches a person or disappears. |
| Every action is logged | Pick a random output from yesterday. You should be able to see what came in, what the tool did and who approved it. |
| Mistakes have a fix path | Agree who corrects a wrong answer and how the correction stops it happening again. |
Start with more review than feels necessary and remove it once the log shows the tool getting the job right. Some work should keep a person in charge for good, and the jobs to keep away from an AI employee covers which.
Gate 4: the running cost and who pays it
A pilot often runs on a free trial or someone's personal card. Production needs a budget line.
| Check | How to check it |
|---|---|
| You know the monthly cost at real volume | Take the usage from your real-data week and scale it to a month. Then price it at double that volume as well. |
| Every cost is on the list | Include subscriptions, usage fees per message or minute, the connection to your other systems, and the staff hours spent reviewing its work. |
| It sits in a budget with an owner | Name whose budget pays for it and move the charge off any personal card. |
| You know the cost of leaving | Check the notice period, and whether you can export your data and settings if you switch. |
If the total costs more than the staff hours it saves, narrow the scope before you roll it out.
Gate 5: security and privacy basics
This gate doesn't need a security team. It needs plain answers to a few questions, in writing.
| Check | How to check it |
|---|---|
| You know where your data goes | Ask the vendor which companies process your data and in which country. Get the answer in writing. |
| Your data isn't used to train their models | Read the data terms for the plan you're on, or ask. Consumer and business plans often have different terms. |
| Accounts belong to the business | Logins and API keys sit in a company account, not in an employee's personal one. |
| Access ends when people leave | Add the tool to your offboarding list next to email and payroll. |
| Regulated data gets the right agreement | If it touches patient records, card details or similar data, confirm the vendor will sign what your rules require, such as a HIPAA business associate agreement for US health data. |
Gate 6: training the people who use it
Staff who don't trust a tool route around it, and the pilot dies from disuse. The training itself is short, but someone has to plan it.
| Check | How to check it |
|---|---|
| Users know what it's for | Ask two of them to explain in one sentence what the tool does and what it doesn't do. |
| They know how to flag a mistake | There is one obvious way to report a bad output, and the owner sees every report. |
| They've used it on real work | Each user has handled a handful of real cases with it before launch day. |
| Their questions about their jobs got answered | You've told the team what the tool changes about their work and what it doesn't. |
The last row decides more pilots than people expect. The conversation with your team about AI is worth having before launch day, not after.
Gate 7: a go/no-go measure agreed before rollout
Agree the measure before launch, while nobody has a stake in the answer. Agree it afterward and people will reach for whichever number backs the view they already hold.
| Check | How to check it |
|---|---|
| One number says it's working | Pick one, such as hours per week spent on the job or the share of inquiries answered the same day. Write down today's figure. |
| A target and a date | Write "by this date, this number reaches this level" and have the owner sign it off with you. |
| An error limit | Decide how many wrong outputs per week you'll accept before you pause it. |
| A plan if it misses | Agree in advance whether a miss means you fix it, shrink the scope or stop. |
Once it's live, the 90-day scorecard for an AI employee picks up where this gate ends.
Roll it out in slices
When the gates are green, don't switch everything over at once. Start with one channel, say email inquiries but not phone calls, or with one team. Run it there for two weeks with review switched on, then widen it. Keep the old process available during the first slice, and switch it off on the end date you set in gate 1.
When the pilot is already stuck
If you ran this list and found four or five red gates, the project hasn't failed. A row of red gates usually means the last stretch of work never got done: the real data, the fallback, the owner and the measure. That stretch is often cheaper to finish than starting over, provided someone looks honestly at what you already have.
That is the job of our Project Rescue for stalled AI projects. We look at what was built, tell you plainly what's worth keeping, finish what's missing and get it running in your business.
If you would rather work through it yourself first, how to rescue a failing AI project sets out the order, starting with whether the project is worth saving and ending with a named owner.
