There is a familiar pattern in AI projects. A proof of concept is built in two weeks, it demonstrates beautifully, everyone is enthusiastic — and nine months later it is still a proof of concept.
The reason is rarely the model. It is that a demo needs to work once in front of a friendly audience, and a production system needs to work on the tenth thousand request, on malformed input, when the vendor is having an outage, and at a cost per task somebody has to justify.
Here is the work that sits in that gap.
1. An evaluation set, before anything else
If you cannot measure whether a change made the system better, you are not engineering — you are redecorating. Before building, collect 100–300 real examples with the answers you would accept, including the awkward ones: ambiguous questions, missing information, things the system should refuse.
Run that set on every prompt change, every model upgrade and every retrieval tweak. Without it, "the new prompt feels better" is the only evidence you will ever have, and it will be wrong about a quarter of the time.
2. Retrieval is where most quality lives
For anything grounded in your own content, the model matters less than what you put in front of it. In our experience most "the AI gives bad answers" problems are retrieval problems: the right passage was never retrieved, so the model improvised.
What actually moves the number:
- Chunking that respects structure. Split on sections and headings, not on a fixed character count that cuts tables in half.
- Hybrid search. Keyword search still beats embeddings for product codes, error numbers and names. Combine them.
- Metadata filters. Date, document type, region, permissions. Narrowing the candidate set before ranking beats a cleverer prompt.
- Deleting rubbish. Out-of-date policy documents in the index produce out-of-date answers, confidently.
3. Decide what happens when it does not know
A demo never has to say "I don't know". A production system does, constantly. Decide explicitly: when confidence or retrieval quality is low, does it refuse, hand to a human, ask a clarifying question, or answer with a caveat?
Make refusal a first-class, tested path. Users forgive a system that admits uncertainty far more readily than one that invents an answer and is caught.
4. Cost per task, tracked from day one
Token pricing makes unit economics easy to ignore until the first serious invoice. Track cost per completed task — not per call — from the proof of concept onward, and design down from there:
- Use the cheapest model that passes your evaluation set. Reserve the expensive one for cases that fail the cheap one.
- Cache aggressively. A surprising share of real traffic is near-duplicate.
- Keep prompts short. Stuffing the whole manual into every request is both slower and worse.
5. Guardrails on the way in and out
Validate input, constrain output. If the result feeds another system, require a strict schema and validate it before use — then handle the failure case, because occasionally it will not conform. For anything user-visible, filter for content you cannot publish, and log what went in and what came out so a real incident can be investigated.
6. Plan for the model changing underneath you
Models are deprecated, re-versioned and re-tuned. Keep the provider behind an interface, keep your evaluation set runnable on demand, and treat a model upgrade as a change that must pass tests — because it is.
What a realistic plan looks like
- Opportunity review. Pick one process that is repetitive, high volume and text-heavy. Write down the baseline: how long it takes now, how often it is wrong now.
- Proof of concept. Real data, evaluation set, measured against that baseline. Be willing to stop here if the numbers are not there.
- Production build. Retrieval, guardrails, failure paths, logging, cost tracking, integration into the tool people already use.
- Supervised rollout. Humans review output for a defined period. Review rate falls as the evidence accumulates, not as confidence grows.
- Operate. Monitoring for drift, periodic re-evaluation, and a scheduled look at what to automate next.
None of this is exotic. It is ordinary engineering discipline applied to a probabilistic component, and it is the difference between a demo that impresses and a system people quietly rely on.
If you have a proof of concept that has stalled, that is usually a sign the measurement was never set up. Our AI development practice starts by fixing exactly that.
