A large share of corporate AI pilots never reach production, and the ones that stall rarely stall for technical reasons. The model works. The demo is impressive. Then it meets real users, real data and real consequences, and the project quietly loses its sponsor.

Having built and reviewed a number of these systems, we think the pattern is predictable. One property separates the use cases that survive from the ones that do not.

The property that predicts success

How expensive is a wrong answer, and how quickly is it caught?

Language models are probabilistic. They will be wrong sometimes, in ways that are fluent, confident and therefore hard to spot. That is not a defect to be engineered away; it is the nature of the tool. The question is not whether errors happen but what happens when they do.

Use cases where a mistake is cheap and immediately visible tend to succeed. Use cases where a mistake is expensive and invisible tend to fail — and they fail late, after the pilot has been declared a success, which is the worst possible time.

This gives a simple two-axis test. Plot your candidate use case by cost of error and speed of detection. The top-right quadrant — cheap errors, caught fast — is where to start.

Use cases that hold up

Drafting where a human always edits

First-draft responses, summaries, descriptions, documentation, translations for internal use. The human reviewing the draft is the error-detection mechanism, and it is built into the workflow rather than bolted on.

The productivity gain is real, because writing a first draft is often the slowest part of the task. Crucially, the reviewer is doing a job they already understand, so they are well placed to spot a wrong answer.

The design rule: the human must be genuinely editing, not rubber-stamping. If reviewers approve without reading — and they will, if approval is frictionless and volume is high — you have removed the safety mechanism while believing it is still in place.

Classification and routing

Categorising support tickets, routing enquiries to the right team, tagging documents, flagging content for review. These work well because the output space is small and closed, the result is checkable, and errors surface quickly through the ordinary operation of the process — a misrouted ticket gets bounced back.

They are also straightforward to evaluate. You can build a labelled test set from historical data and measure accuracy properly before deploying, which is much harder for open-ended generation.

Extraction from unstructured documents

Pulling structured fields out of invoices, contracts, forms, emails and reports. This is one of the highest-value applications available to most businesses, because the alternative is people re-keying data.

It works well when you add validation. Extracted values can be checked against expected types, ranges, and totals — an extracted invoice total that does not match the sum of extracted line items is caught automatically. Where deterministic validation is possible, use it; it converts a probabilistic system into a mostly-reliable one with a clear exception path.

Search and retrieval over internal knowledge

Helping employees find information across scattered documentation, policies and wikis. It works because the model surfaces sources the user can check, and because the user usually has enough context to recognise an irrelevant answer.

Always show the sources, and make them easy to open. A system that cites its sources is one where users can self-verify; a system that answers without them asks for trust it has not earned.

Use cases that quietly fail

Autonomous customer-facing responses with no review

Fully automated replies to customers, with no human in the loop and no confidence threshold. Errors here are expensive — a wrong commitment on price, eligibility or policy can be binding or at minimum damaging — and detection is slow, because you find out when the customer complains.

This can be made to work, but only with real engineering: strict scoping to a narrow domain, confidence thresholds that hand off to a human, refusal to answer outside scope, and monitoring of what is actually being said. That is a serious system, not a pilot.

Anything where a wrong answer is unverifiable

Generating figures, calculations or factual claims that the recipient cannot easily check. If your process produces a number that someone downstream will act on without verification, a fluent-sounding wrong number is worse than no number.

Where the task is arithmetic or lookup, do not ask a language model to do it. Have it identify what needs calculating and let deterministic code do the calculation. This hybrid pattern — model for interpretation, code for computation — is one of the most reliable architectures available.

Decisions affecting people, without recourse

Screening applications, assessing eligibility, prioritising cases involving individuals. Beyond the accuracy question there are fairness, transparency and increasingly regulatory obligations. If someone is materially affected by an automated decision, they generally need an explanation and a route to challenge it.

Language models are poorly suited to producing auditable justifications, because the stated reasoning is generated text rather than a faithful account of a computation. Treat these use cases as requiring legal review before engineering effort, not after.

Replacing expertise rather than accelerating it

Deployments framed as removing the need for a skilled reviewer tend to fail twice: the output is not reliable enough to be unreviewed, and the people who would have caught the errors have been redeployed. The value is in making experts faster, not in removing them from the loop.

How to run this properly

1. Pick one use case from the top-right quadrant. Cheap errors, fast detection, and a workflow that already contains a reviewer.
2. Build an evaluation set before building the system. A few hundred real examples with known-correct answers. Without this you cannot tell whether a change improved things, and you will be tuning on impressions.
3. Define the failure path first. What happens when the model is unsure, or wrong? Who sees it, and how do they correct it? If you cannot answer, you are not ready to deploy.
4. Instrument everything. Log inputs, outputs and human corrections. The corrections are your most valuable asset — they show where the system is weak and become your improved evaluation set.
5. Keep humans in the loop until the data says otherwise. Then reduce oversight deliberately and measurably, one step at a time.
6. Review cost against value at real volume. Per-request costs that are negligible in a pilot become significant at production scale. Model this before committing.

A note on the boring parts

The engineering effort in a production AI system is mostly not about the model. It is data access and permissions, ensuring the system respects existing entitlements, retention and privacy handling for prompts and outputs, monitoring, cost control, graceful degradation when the provider has an outage, and version control over prompts and configurations.

Teams that treat these as post-pilot concerns produce impressive demos that cannot be deployed. Teams that address them from the start ship slower and reach production.

Working with us

Our AI development team starts engagements by identifying which of your candidate use cases sit in the safe quadrant — and saying plainly which do not. We build with evaluation, monitoring and human oversight designed in from the beginning, integrated with your existing systems by our software engineering teams.

Get in touch to talk through a use case before you invest in it.