Putting AI to Work in the Enterprise: From Pilot Purgatory to Production

Pilot purgatory

The pattern is familiar. A capable team builds a demonstration in six weeks. It works impressively on the examples shown. Leadership is enthusiastic. Then the project spends eighteen months not reaching production, and quietly stops being mentioned.

The demonstration was not dishonest. It was measuring the wrong thing. A demonstration measures whether the approach can work on selected inputs. Production requires knowing whether it works on all inputs, including the ones nobody anticipated, at a cost that makes sense, with a defined behaviour when it is wrong.

Bridging that gap is mostly not a modelling problem.

Start with use-case triage

The most consequential decision in an AI programme is which problem to attack first, and it is routinely made by enthusiasm rather than analysis. Score every candidate on three axes:

• Value if it works. Expressed in currency or in hours, tied to a named owner. "Improves customer experience" is not a score.
• Data readiness. Does labelled or labellable data exist today, in sufficient volume, with the outcome you want to predict actually recorded?
• Cost of being wrong. What happens on a false positive? On a false negative? Is a human in the loop feasible at the required throughput?

The best first project scores high on value, high on data readiness, and low on cost of error. That combination is rarer than it sounds, and finding it is worth two weeks of analysis. The worst first project — high value, low data readiness, high cost of error — is also the one executives most often name first, because high stakes and high value travel together.

The boring winners

In enterprise settings the highest-return early projects are consistently unglamorous: document classification and routing, structured extraction from unstructured forms, demand forecasting at SKU level, anomaly detection in transaction streams, and internal knowledge retrieval. They have clear ground truth, tolerable error costs, and measurable baselines.

Data readiness is the real gate

Before modelling, four questions need honest answers.

Does the outcome exist in the data? To predict which customers will churn, you need a recorded, unambiguous definition of churn that was applied consistently in the past. Many organisations discover at this point that churn has been defined three different ways by three different teams.

Is there leakage? A feature that is only populated after the outcome occurs will produce a spectacular validation score and a worthless model. A cancellation-reason field is the classic example. Leakage is the single most common cause of a model that performs brilliantly in testing and fails in production.

Can you reproduce the training set? If the training data was assembled through a series of manual queries, you cannot retrain, and a model you cannot retrain has a decay clock on it from the day it ships.

Is the historical distribution still valid? Data spanning a period of major process change — a system migration, a pricing overhaul, a pandemic — may describe a world that no longer exists.

Evaluation before enthusiasm

Fix the evaluation set and the acceptance threshold before the first model is trained. Written down, agreed by the business owner, held out from all training.

Three properties matter. The set must be representative of production inputs, including the awkward tail. It must be large enough that the differences you care about are statistically meaningful. And it must be held out completely — no tuning against it, or you have simply moved the overfitting somewhere less visible.

The acceptance threshold is a business decision, not a technical one. It is not "90% accuracy". It is "must beat the current manual process, which achieves 71% with a two-day turnaround, at a cost below $0.40 per document."

If the model cannot beat the existing process on the agreed evaluation set, say so — and say so in week three, not in month nine.

Choose metrics that reflect the actual cost of error

Accuracy is a poor metric for imbalanced problems, which is most enterprise problems. If 3% of transactions are fraudulent, a model that predicts "not fraud" for everything is 97% accurate and entirely useless. Use precision and recall with an explicitly chosen operating point, and be clear about which kind of error is worse and by how much.

For generative systems, evaluation is harder but not optional. Build a graded question set with reference answers, score with a rubric — human-graded initially, model-graded once you have calibrated the grader against human scores — and track it as a regression suite on every change to prompts, retrieval or model version.

Building LLM applications that hold up

Most enterprise generative use cases are retrieval problems wearing generation clothing. The user wants an answer grounded in the organisation's own documents; the model supplies fluency, and the retrieval layer supplies truth.

Retrieval quality determines output quality

Teams reliably spend their time on prompt engineering and model selection when the failure is almost always retrieval. If the correct passage is not in the context window, no model will produce the right answer; it will produce a confident wrong one.

What actually moves the needle:

• Chunking that respects document structure. Split on sections and headings, not on a fixed character count that severs tables and lists.
• Hybrid retrieval. Combine semantic search with keyword search. Pure vector search fails badly on exact identifiers, product codes and acronyms.
• Reranking. Retrieve broadly, then rerank with a cross-encoder. Consistently the highest-return single addition to a RAG pipeline.
• Metadata filtering. Restrict by document type, date, jurisdiction or permission before semantic search, not after.
• Retrieval-level access control. Filter by the requesting user's permissions at retrieval time. A generative interface must never become a way to read documents you could not otherwise open.

Grounding and abstention

Require citations to retrieved passages and make them visible in the interface. Instruct the system to abstain when retrieval returns nothing relevant, and measure the abstention rate — a system that never says "I do not know" is not being careful, it is fabricating.

The operational layer

The distance between a notebook and production is mostly plumbing, and skipping it is what leaves organisations with models nobody dares change.

• Versioning of code, data snapshot, model artefact and configuration — together, so any prediction can be traced to what produced it.
• Reproducible training as a pipeline, runnable by someone who did not write it.
• Registry and promotion, with an explicit gate between staging and production.
• Shadow deployment — run the new model against live traffic without acting on its output, and compare.
• Progressive rollout with automated rollback on a defined metric breach.
• Serving that meets the latency and throughput the use case actually requires, with cost per inference tracked from day one.

Monitoring: models decay quietly

Software fails loudly. Models degrade silently — they keep returning confident predictions that are progressively less correct as the world drifts away from the training distribution.

Monitor four things:

1. Input drift. Distribution of incoming features against the training baseline.
2. Prediction drift. Distribution of outputs. A sudden shift usually means an upstream change, not a change in reality.
3. Outcome quality. Where ground truth eventually arrives, measure accuracy on the delay. This is the only true measure.
4. Operational health. Latency, error rate, cost per inference, and token consumption for generative systems.

Define the retraining trigger in advance — a metric threshold or a fixed cadence — so retraining is a routine operation rather than an emergency response to a complaint.

Governance that engineers can live with

For every deployed system, maintain a short record: what it does, what it must not be used for, what data trained it, how it was evaluated, what the known failure modes are, and who owns it. One page. Maintained. It answers the auditor's questions and, more usefully, the questions of the engineer who inherits it in two years.

Keep humans in the loop wherever the decision materially affects a person — hiring, credit, health, safety, benefits, discipline. Design the review so it is genuine: give the reviewer the evidence, the confidence, and enough time. A reviewer approving four hundred decisions an hour is providing legal cover, not oversight.

What a realistic first year looks like

The compounding is the point. The first project pays for the pipeline, the registry, the monitoring and the evaluation discipline. The second and third projects use all of it and land far faster. Organisations that run three pilots in parallel with three different teams get three demonstrations and no platform.