How to Build an AI Assistant That Does Not Make Things Up
A general-purpose model asked about your refund policy will produce something plausible, confident and wrong. Here is the engineering that closes that gap.
The gap that matters
A general-purpose model knows a great deal and nothing about your business. Asked about your refund policy, it produces something plausible, confident and wrong. Almost all of the engineering that makes generative AI usable in a company is about closing that gap: retrieving the right passage from your own material and requiring the answer to come from it.
What gets built
- Retrieval-grounded assistants over policies, manuals, contracts and product data
- Internal copilots — drafting replies, summarising threads, pulling the right record into view
- Customer-facing chatbots with a defined escalation to a human and a logged handover
- Document intelligence — extracting fields from invoices and forms into your system
The guardrails, which are most of the work
The model is a component. What makes the system safe to put in front of customers is the layer around it: answers built from retrieved passages with the passage shown, an explicit "I don't know, here is who does" instead of an invented answer, a defined escalation path with the conversation attached, and logging of every question and answer so a bad one can be investigated.
Content is the actual dependency
A grounded assistant is exactly as good as the material it reads. If your policies contradict each other, the assistant will faithfully reproduce the contradiction. A content review is normally part of the engagement, not an afterthought.
What it costs to run
Hosted models bill per token, so running cost scales with conversations rather than users. A low-volume internal copilot is a small monthly line; a busy customer-facing assistant is a real one — modelled at your expected volume before you commit.