From GenAI PoC to production, five lessons

Most organisations have run a GenAI pilot by now. Many of those pilots produced an impressive demo, a positive steering committee and then nothing. Six months later, the tool is not in anyone’s daily work.

The model is rarely the reason. In our experience, pilots stall because they were never tied to a real workflow, never tested the way experts would test them, and never designed for what happens when the AI is wrong. Here are five lessons from the GenAI work we have taken from prototype towards production.

1. Start from one workflow, not from the model

“How can we use GenAI?” is the wrong first question. The right one is: which decision or task is slow, inconsistent or dependent on a few people, and what would good look like?

For an engineering division selling equipment to biopharma customers, the problem was clear. The answers customers needed sat in an external expert’s lecture recordings and slides, and only a few people knew where to find them. That one workflow, answering technical questions with confidence, defined everything else.

2. Evaluate with real material and real experts

A demo with hand-picked questions proves very little. Before anyone relies on the tool, test it with the questions people actually ask, checked by people who know the right answer.

For the knowledge assistant, we built an evaluation set from real questions. In testing, it answered all 22 correctly, cited a source for every answer, and refused all three questions whose answers were not in the material. Refusing to answer is as important as answering. A tool that guesses will not be trusted twice.

Where teams work in more than one language, evaluate in each of them from the start. Terminology problems show up in testing, not in the demo.

3. Design for being wrong

Every GenAI system will sometimes be wrong. The question is what happens then.

Two patterns have worked well for us. The first is cite everything: every answer points to the lecture, timestamp, slide or page it came from, so users can check it in seconds. The second is AI proposes, people decide. In a new-business exploration tool we built, the AI drafts research and proposes changes, but nothing is applied until a person approves it, and evidence that is not a verified fact cannot be marked as verified. The system records who decided what, and why.

4. Make confidentiality a design decision, not an afterthought

Many pilots stop at the security review. It is better to design for it from the first day. In the knowledge assistant, the original recordings never leave the client’s control: transcription and indexing run locally, only short text excerpts go to the language model under commercial terms that exclude training, and all model calls sit in one module so they can be switched to a different endpoint if policy requires it. When web search is used, it is limited to an allow-list of authoritative sources, and answers clearly separate internal from public information.

These choices make the conversation with IT and legal much shorter.

5. Budget for operations, not just the pilot

A pilot has a budget. Production needs one too: for re-indexing new material, monitoring answer quality, updating prompts and models, and supporting users. If the operating model is not part of the business case, the pilot ends when its budget does.

Plan the path explicitly. In our projects, it is a sequence: prove value in a short sprint, run a trial with real users, then build for production with the security and operations the organisation needs.

Where to start

Pick one workflow where the cost of the problem is clear, gather the real questions or documents behind it, and agree with the experts how you will judge the answers. A working prototype tested against that standard tells you far more than a demo, and gives decision makers something real to approve.

If your GenAI pilots are stuck at the demo stage, tell us about it.