Putting an LLM assistant into production — safely

The demo answers the twenty questions you rehearsed. Production faces everything else: ambiguous requests, half-remembered product names, customers pasting in ID numbers and bank statements, and — sooner than you expect — people who are actively trying to make the assistant misbehave. A demo is judged on its best answer; a production system is judged on its worst.

So the work of productionising an assistant is mostly not prompt-tweaking. It is deciding what the assistant is allowed to know, what it is allowed to say, what it is allowed to do, and how you will notice when any of that goes wrong.

For most business assistants, retrieval beats fine-tuning. Fine-tuning bakes knowledge into weights you cannot easily inspect, correct, or roll back — and your tariffs, policies, and product names change monthly. Retrieval-augmented generation keeps the model generic and pulls answers from a knowledge base you control, so a wrong answer is usually a wrong document, which is a thing you can fix by lunchtime.

That only works if the knowledge base is treated as a product, not a dumping ground. Curate it: one authoritative document per topic, owners named, stale versions removed. Version it, so you can say exactly what the assistant knew on the day it gave a disputed answer. And instruct the model to say “I don’t know” when retrieval comes back thin — a confident guess about a loan rate or a dosage is far more expensive than an honest referral to a human.

Guardrails are layered, and each layer earns its place. On the way in, screen for prompt injection — instructions smuggled inside user messages or inside retrieved documents (“ignore your previous instructions and…”). Treat everything the user or the knowledge base supplies as data, never as instructions, and keep the system prompt out of reach.

On the way out, enforce policy in code rather than hoping the prompt holds. Scan responses for personal data that should not be echoed back, and draw hard boundaries around regulated territory — an assistant at a bank or insurer should explain products, not dispense personal financial advice. If the assistant can call tools, scope them ruthlessly: read-only wherever possible, per-user permissions inherited from the person chatting (never a super-user service account), and a human approval step for anything that moves money or deletes data. Finally, build the handoff: when confidence is low, the topic is sensitive, or the customer is frustrated, route to a person — and make that transfer graceful, with the conversation context carried across.

Before launch, build a golden-question set: 100–200 real questions with agreed correct answers, including the awkward ones — ambiguous phrasing, out-of-scope requests, and a handful of deliberate injection attempts. Every change to the prompt, the model, or the knowledge base gets scored against it before shipping. It is the closest thing this field has to a regression test.

After launch, the same set becomes your drift alarm: re-run it on a schedule, because provider model updates and knowledge-base edits can quietly change answers you thought were settled. Pair that with a feedback loop — thumbs up/down in the interface, plus a weekly human review of a sample of transcripts. The transcripts are where you find the questions your golden set never imagined.

# golden-set entry (illustrative)
question: "Can I get a refund after 30 days?"
must_include: ["14-day window", "warranty exception"]
must_not_include: ["yes, always"]
on_fail: block release

If you serve Kenyan customers, the Data Protection Act, 2019 follows the data into your prompts and logs. A customer message pasted into a third-party model is a disclosure to a processor, so you need a lawful basis, a data-processing agreement, and retention rules that cover conversation logs — which teams routinely forget are full of personal data. Minimise what reaches the model in the first place: redact ID numbers, phone numbers, and account details before the prompt leaves your systems wherever the use case allows.

Ask your provider the residency questions early: where are prompts processed, where are they stored, are they retained for training, and can you opt out in writing? And test the languages your customers actually use. An assistant that is fluent in English but stumbles in Swahili — or in the code-switching mix real customers type — will quietly exclude a large share of your market. Put Swahili and mixed-language questions into the golden set from day one, not as an afterthought.

A short list we would want answered “yes” before any assistant meets customers:

• The knowledge base is curated, versioned, and has a named owner.
• A golden-question set exists, including injection attempts and Swahili/multilingual coverage, and gates every release.
• Output policy is enforced in code: PII redaction, regulated-advice boundaries, scoped tool permissions.
• Low-confidence and sensitive conversations hand off to a human, with context intact.
• Logging, retention, and your provider’s data-residency terms have been reviewed against the Data Protection Act.

None of this slows a good team down for long — most of it is a few focused weeks. What it buys you is an assistant you can defend: to a regulator, to a customer, and to yourself at 2 a.m. when someone finds the edge case you did not.