Why AI pilots fail to reach production.

When AI pilots fail to reach production, the model is rarely the reason. The pilot was scoped as a model problem, and production is a systems problem: work arriving from real sources, permissions, exceptions, logging, monitoring, and somebody who owns the whole thing after launch.

The pattern is familiar. The demo goes well, everyone agrees the technology works, and then the project quietly stalls somewhere between the meeting room and the systems where the real work happens. Months later somebody asks what happened to it, and nobody has a precise answer.

What does pilot purgatory look like?

Pilot purgatory is the state where a pilot is judged a success but never becomes something the business relies on. Nobody decides to cancel it. It simply never receives what it needs to go live, and it fades.

The symptoms are easy to recognise:

• The demo is rerun for each new audience, but nobody uses the system on real work.
• The next step is called "phase two", with no date, budget or owner.
• The pilot runs from a laptop or a folder of exported files rather than from live systems.
• Nobody can say how accurate it is on last week's work, only on the samples it was built with.
• The people who built it have moved on, and the knowledge left with them.

A stalled pilot costs more than its budget. It uses up the goodwill of the people who gave it their time and makes the next AI project harder to fund, even though the real lesson is narrower: that project was never scoped to go anywhere.

Why is the demo not the product?

A demo answers one question, whether the model can do the clever part, and production depends on everything else. In the demo the model reads a document, drafts a reply or extracts the fields, and the room nods. But the clever part was never the risky part. The risky part is everything the demo skipped: where the documents come from, who is allowed to see them, what happens when the model is wrong, and who finds out.

Demos also flatter the model. The inputs were chosen because they worked, and when something odd comes back the builder corrects it without thinking. There was a person in the loop all along, just not one anybody designed for.

Production removes all of that. Inputs arrive unselected, at volume, from people who have never seen the prompt (the instructions the model was given), and nobody checks each result before it reaches an invoice or a customer.

The gap between the two is not effort, it is scope. A demo and a production system are different pieces of software that happen to share a model.

The supporting systems nobody scopes

Every pilot that has reached production with us needed the same supporting cast, and none of it appears in a demo. Each piece is ordinary engineering. Together they are often the larger share of the work.

Ingestion

Ingestion is how work gets into the system. It arrives through shared inboxes, drives, scanners, portals and people forwarding things to each other, and it is late, duplicated and in the wrong format. A production ingestion layer has to settle:

• Sources. Which inboxes, folders and systems are in scope, and which are not.
• Formats. PDFs, scans, phone photos, spreadsheets, and attachments inside attachments.
• Duplicates. The same invoice sent twice should be recognised, for example by fingerprinting the file, and processed once.
• Failures. What happens when a source is down, or a file is corrupt or password-protected.
• Reprocessing. Handling an item twice after a crash or retry must not create two records or two payments. Engineers call this idempotency.

Poor scans are a common place for extraction pilots to come unstuck, and building document extraction that copes with messy scans covers that problem in detail.

Permissions

The model reads documents on behalf of people, so somebody has to decide, precisely, which people. In a demo everyone in the room sees everything. In production, an HR letter or a client contract must only reach people who could already open it.

The safest pattern is to inherit access from the source system rather than inventing new rules. For systems that search a document collection before answering (often called retrieval, or RAG), that means filtering results by the user's permissions before anything reaches the model, rather than stripping sensitive content from the answer afterwards.

Give the system its own service account (a login used by software rather than a person) with the least access it needs. Separate reading from writing too, so a system that reads invoices cannot also change supplier bank details.

Exceptions

Exceptions are the cases the system should refuse to decide, and the route those cases take to a person. Of everything on this list they deserve the most design attention, because they are where trust is won or lost.

A system that only handles the clean cases has not removed the work. It has removed the easy part of the work and left people the residue, with less context than they had before.

A system that handles the happy path handles nothing yet.

In practice the escalation rule is written before the prompt is. Who receives the doubtful case, what arrives attached to it, and what the system does while it waits. The rule tends to be short, and writing it forces every conversation the pilot postponed.

on_low_confidence:
  stop            # do not act on a guess
  attach: [document, extraction, reason]
  route: finance-review
  wait: human_decision

Low confidence is only one trigger, and rarely the best. Missing fields, sources that disagree and values above a set limit are more dependable, because they are facts about the data rather than the model's opinion of itself. The guide to when AI agents should hand work to a person covers triggers and handoffs in detail.

Logging

Logging is a record of what was read, what was decided and why, written for the person who asks later: an auditor, a customer disputing a decision, or an engineer working out what went wrong. Each decision record should hold:

• A reference to the input document or message.
• The versions of the prompt, rules and configuration in use.
• What the model returned, and which checks passed or failed.
• Whether the case escalated, who reviewed it and what they decided.
• The final action taken in the destination system.

Store references rather than copies where content is sensitive, and agree a retention period with whoever owns data protection. A log kept from the first day also becomes raw material for evaluation.

Monitoring

Monitoring is something that notices when quality drifts, before a customer does. Drift is usually quiet: a supplier changes its invoice layout, a new product line brings new vocabulary, or the provider updates a model. Watch a few signals, each with a named person who receives the alert:

• Escalation rate. A sudden rise often means the inputs changed.
• Overturn rate. How often reviewers change what the system proposed.
• Integration errors. Failed writes, timeouts and rejected records.
• Cost per item. Whether spend tracks volume or runs ahead of it.

Have a person check a regular sample of automatically accepted cases too, since no other signal catches those errors. Where the provider lets you pin a model version, do so, and test a version change like any other release.

Handover

Handover is the documentation and walkthrough that let the team run the system without the people who built it. Without it, the system depends on one engineer's memory.

A practical runbook covers restarting each component, finding the logs, changing a threshold safely, rolling back a prompt change, and who to contact when an integration fails. Test it by rehearsal: before launch, let the operating team run the system while the builders only watch.

Is your data ready for production?

Usually not in the form the pilot used, and the pilot is the cheapest place to find that out. Pilots tend to run on an export or a folder of hand-picked samples. Production reads from live sources, with all their gaps, duplicates and odd cases.

Before building, answer these questions about each input:

• Access. Can software reach it through an API (an interface built for other software), a database or a service mailbox, or does someone export it by hand?
• Approval. Who owns the source, and who must approve access for an automated system?
• Quality. How much of it is scanned, handwritten, incomplete or in another language?
• History. Are there past examples with known correct outcomes to test against?

Access approval can be one of the slowest steps in an early project, so request it in the first week. Build the test set from recent, real examples, including the awkward ones people complain about. A system evaluated only on clean inputs will look better in the pilot report than it ever will in use.

Who owns an AI system after launch?

A named business owner and a named operating team should own it, and both should be agreed before the build starts. A common version of the stall: the pilot was built by an innovation team, for an operations team that did not ask for it, on infrastructure IT never agreed to run. Nobody is at fault, and nobody is responsible.

The roles can sit with one person in a small business or with several in a large one:

• Business owner. Accountable for the outcome. Decides the scope, the escalation thresholds and when to expand.
• Exceptions owner. Works the exceptions queue every day.
• Technical owner. Keeps integrations running, responds to alerts, and controls changes to prompts, rules and configuration.
• Budget owner. Pays the running costs and sees the cost per item each month.

The exceptions queue needs the most care. A queue that belongs to nobody grows, and then people work around the system, quietly returning the process to how it ran before. Agree who works the queue, how quickly cases are picked up, and who covers absences.

How do you measure whether an AI pilot worked?

Agree the measures and record the current baseline before building, so the pilot ends in a comparison rather than an impression. Without a baseline every result becomes an argument, and the loudest opinion in the review meeting decides.

Start by measuring the current process: time per item, errors found downstream, backlog and waiting time. These numbers are often written down nowhere, and collecting them is useful even if the project never goes ahead.

Then define good in terms the business cares about. Accuracy alone is a weak measure, because errors do not all cost the same: a wrong reference number is a nuisance, a wrong bank account is a loss. Set acceptable error levels per field or category, and agree stop criteria alongside success criteria, so that ending the pilot is a legitimate result rather than an embarrassment.

Model output can vary between runs on the same input, so evaluation needs repeated runs over a fixed test set rather than a single pass. The guide to testing LLM systems whose output varies explains how to build that evaluation so it runs before every change.

Integration, security and cost at real volume

These are the constraints a demo never meets. Each is manageable when planned from the start and expensive when discovered at the end.

Integrating with systems of record

A system of record is the one the business treats as the truth: the accounting package for invoices, the CRM (customer relationship management system) for customers. Output left in a spreadsheet or an email for someone to copy across is a new manual step, and people notice.

Production means writing to that system, or preparing a draft there for a person to approve. That brings practical work:

• Use the system's official API where one exists, rather than automating its screens.
• Validate outputs against master data (the approved lists of suppliers, customers and codes), so a code that does not exist becomes an exception.
• Use draft or pending states for anything with financial or customer impact.
• Handle rate limits, timeouts and partial failures without creating duplicates.
• Find out early whether a test environment exists, and what change approval the owning team requires.

Integration is often one of the longest parts of the build, and it depends on other teams' calendars. That alone is a reason to scope it into the pilot.

When should security and privacy review happen?

Security and privacy review should happen at the start, while the design can still change cheaply. A review held at the end can only approve or block, and a block weeks before launch can undo months of work.

Bring security, data protection and, where relevant, legal into the design with a clear picture of how data flows. Their questions are predictable:

• What data goes to which provider, and where is it processed and stored?
• Does the provider retain inputs or use them to improve its models? This depends on the provider and the contract, so check the terms.
• Is personal data involved, and are a lawful basis and a data processing agreement in place?
• Who can access the logs, and how long are they kept?
• If the system reads outside content such as emails, how is it protected from instructions hidden in that content? This is called prompt injection, and it matters most when the system can take actions.

The answers often change the architecture: a different hosting region, redaction before content reaches the model, or a narrower set of permitted actions. Those are easy changes on paper and painful ones in a finished system.

What does an AI system cost at real volume?

More than the pilot suggested, because every per-item cost multiplies and some costs only appear at scale.

The running cost has several parts: model usage (usually billed by the amount of text processed, at rates that vary by provider and model), retries, hosting, storage for logs and documents, monitoring, integration maintenance, and the staff time spent on exceptions.

As an illustrative example, with round numbers that are not real volumes or prices: a pilot that processed 200 documents in a month and a production system handling 20,000 a month differ by a factor of one hundred. If one document in ten escalates, that is 2,000 cases a month for people to review, which is a staffing question before it is a model question.

Estimate cost per item at production volume during the pilot, not after it. Long documents, large prompts and sending every step to the largest model are common reasons costs run ahead of plan. Routing simple items to smaller models, trimming each request and caching repeated work are the usual controls, and how to keep model costs under control goes through them in depth.

How do you get people to use an AI system?

Design it with the people who do the work, put it inside the tools they already use, and make their day easier rather than adding a step. A system can pass every technical measure and still fail if the team quietly checks every output twice or drifts back to the old way.

Adoption problems are usually design problems:

• Involve front-line staff from the start. They know the awkward cases and the unwritten rules no process map records.
• Meet people where they work. Output inside the case system or finance tool gets used; output in a separate tab gets forgotten.
• Show the evidence. Highlight where each extracted value came from, so checking takes seconds, and record every correction a reviewer makes.
• Be honest about the change. Explain what the system handles, what stays with people, and how roles change.

Watch for workarounds after launch. A private spreadsheet kept alongside the system, or outputs re-keyed when they could simply be accepted, is a clear early sign. Ask people why before changing anything, because the answer is usually a missing piece of design.

Common reasons AI pilots fail, with fixes

Stalled pilots often show several of these causes at once, and the symptoms appear well before anyone calls the project stalled.

Every fix in that table is a decision or a piece of scope, and none of them is a better model. That is what it means in practice to call production a systems problem.

How do you scope a pilot as a thin slice of production?

Choose one narrow case and run it end to end on real inputs, real permissions, a real exceptions route and a real destination, leaving everything else out. None of this argues against pilots. Small first projects are the sane way to start, as long as the pilot is a slice of the real system rather than a rehearsal of the demo.

Think of the system as layers: ingestion, the model step, validation, exceptions, integration, logging and monitoring. A demo-shaped pilot builds one layer well. A thin slice builds every layer, simply and for a narrow scope, so nothing has to be invented later.

A good first slice has:

• Enough volume to matter, so the measures mean something.
• Clear rules for a correct outcome, so accuracy can be judged without long debate.
• A contained cost of error, so early mistakes are caught by review rather than by customers.
• A willing owner who wants the work done differently.
• A narrow boundary, such as one document type or one category of enquiry.

Scoped that way, the pilot is production, just small. Growing it is a decision about coverage, not a second project with its own risk of stalling. That is the difference between a pilot that becomes infrastructure and one that becomes a slide in somebody's quarterly review.

A plan from first pilot to production

These steps take a first project from idea to a live system. Access requests and security review should start early and run in parallel, because both depend on other teams.

1. Map the process. Write down where the work comes from, who touches it, what they decide and where the result lands, including exceptions handled from memory.
2. Choose the slice. Pick one narrow, measurable case with a willing owner, and write down what is out of scope.
3. Name the owners. Agree the business, exceptions, technical and budget owners before any build work.
4. Record the baseline. Measure the current process, agree success and stop criteria, and set a decision date.
5. Start access and security review. Request data access and walk security and data protection through the data flow.
6. Build a real test set. Collect recent examples from the live source, awkward ones included, with known correct outcomes.
7. Write the exception rules. Define what the system must not decide, who receives those cases, and what arrives with them.
8. Build the slice end to end. Ingestion, model step, validation, exceptions, draft integration, logging and monitoring, all simple and all real.
9. Run in shadow mode. Let the system process live work without its results being applied, and compare its outputs with what people decided.
10. Go live and hand over. Switch on with review in place, rehearse the runbook with the operating team, and let them take the queue.
11. Expand by coverage. Add the next document type or category only when the current measures hold, and reduce review where overturns stay low.

Key takeaways

• AI pilots fail to reach production mainly because they are scoped as a model problem, when production is a systems problem.
• A demo proves the model can do the clever part, while production depends on ingestion, permissions, exceptions, logging, monitoring and handover.
• Write the exception rule before the prompt, and name the person who works the exceptions queue.
• Agree success measures, stop criteria and a baseline from the current process before building anything.
• Start data access requests and security review early, because both depend on other teams.
• Estimate cost per item at production volume during the pilot, including staff time spent on exceptions.
• Scope the pilot as a thin slice of production, so growing it is a decision about coverage rather than a new project.

Where to start

If you are planning a first project, start with the process, not the model. Map where the work comes from, who touches it, and where it has to land. The model is the easy third of the build; the rest is the supporting systems and decisions described above.

If a pilot has already stalled, the same map is the quickest diagnosis. Hold it against the table of failure causes and the gaps tend to show themselves: an owner nobody named, an integration nobody scoped, or a security review nobody requested.

An AI strategy and review suits a planned or stalled pilot that needs assessing against what production requires, and our custom AI agents work covers building the thin slice end to end, with exceptions, integration and handover in scope. To talk through your own process, schedule a call.

Frequently asked questions

How long should an AI pilot run?

An AI pilot should run long enough to see the normal variation in the work, including a full business cycle if the process has one, such as a month-end close. The right length depends on volume and on how quickly errors surface downstream. Whatever the length, fix an end date and the decision in advance: expand the scope, change the approach, or stop. A pilot without an end date tends to drift.

What is the difference between a proof of concept and a pilot?

A proof of concept tests whether something is technically possible, usually on sample data and without real users. A pilot runs the system on real work, with real users, inside a limited scope. Both are useful, but they answer different questions. Trouble starts when a proof of concept is presented as a pilot, and the organisation assumes the hard parts of production have already been done.

Who should own an AI project, IT or the business?

Both should own it, with separate responsibilities agreed before the build. The business owns the outcome: the scope, the escalation thresholds, the exceptions queue and the decision to expand. IT or a technical team owns running the system: integrations, alerts, access and configuration changes. A project owned only by IT can lack a reason to exist, and one owned only by the business can lack anyone to keep it running.

What is shadow mode in an AI rollout?

Shadow mode means the AI system processes live work alongside the existing process, but its results are not applied. People carry on as normal while the system's outputs are recorded and compared with what they actually decided. It shows how the system behaves on real inputs without any risk to customers or records, and it produces the evidence needed to decide whether to switch it on.

How do you know an AI pilot is ready for production?

An AI pilot is ready when it meets the success measures agreed in advance on real, recent inputs and the supporting pieces are in place. That means exceptions reach a named person, outputs land in the system of record, security and data protection have signed off, logging and monitoring are running, and the operating team has used the runbook without the builders stepping in.

Can you run an AI pilot on sample data?

For an early feasibility check, yes, but a pilot that only ever sees sample data cannot show how the system will behave on live work. Samples are usually cleaner, more consistent and chosen by someone who knows what works. Use them to test the idea, then move to real inputs from the live source as soon as access allows, including the awkward cases people complain about.

When should you stop an AI pilot?

Stop an AI pilot when it misses the stop criteria agreed before the build, when nobody will own the exceptions, or when the cost per item at real volume is more than the value of the work saved. Stopping is also right when the pilot shows that a simple rule or a process change solves the problem better. A clear stop is a useful result, and far better than a pilot left to fade.

Do AI systems need human review forever?

Not for every case, although some decisions may always keep a person involved. Review should focus on the cases the system flags and on categories where errors are costly. When reviewers rarely overturn the system in a category over a sustained period, review there can move to regular spot checks. High-risk decisions, such as payments above a set limit, often keep a person involved permanently as a matter of policy.

Schedule a call