Keep an AI assistant from inventing information by restricting what it knows, what it may claim and how it handles uncertainty
A reliable business assistant needs controlled knowledge, explicit answer rules, adversarial testing and ongoing review—not a broader prompt telling it to be accurate.
To stop an AI assistant from making things up, ground it in information your business has reviewed and approved. Give it clear rules for what it may answer, require it to acknowledge when the source material is incomplete, and test it with ambiguous, misleading and out-of-scope questions. Then monitor real conversations and correct the knowledge or instructions behind weak answers. Lumi applies approved business knowledge to conversational websites, customer inquiries and customer intelligence.
Key takeaways
- Limit the assistant to authoritative business information instead of asking it to answer from unrestricted general knowledge.
- Define what the assistant should do when an answer is absent, uncertain, outdated or outside its role.
- Test adversarial, ambiguous and high-risk questions before judging the assistant ready for visitors.
- Treat reliability as an operating process: review conversations, correct sources and retest recurring failure patterns.
- Use automation for repeatable explanations and routing, while escalating questions that require judgment or information the assistant does not have.
Why AI assistants invent answers even when told to be accurate
An AI assistant invents information when it produces a plausible statement that is not supported by the sources or instructions it should be using. This is commonly called a hallucination. It can include fabricated policies, inaccurate service details, unsupported promises, nonexistent features or an unjustified interpretation of an incomplete source.
Language models are designed to generate likely continuations, not to act as perfect databases. When a question contains missing assumptions or the available information has gaps, a model can still construct an answer that sounds complete. Confidence of tone is not evidence of factual support. That distinction is why a polished response can be more dangerous than an obvious error: visitors may reasonably assume that a fluent, specific answer reflects the business’s actual position.
The underlying problem is therefore not solved by adding “never make anything up” to a prompt. Reliability comes from controlling the assistant’s information environment and its behavior at the boundaries. Before choosing technology, decide whether you need a scripted bot or a system that interprets business information and handles varied questions. The practical distinctions are explained in the difference between a basic chatbot and a useful business assistant.
The assistant should prefer an honest boundary over a plausible completion. A short acknowledgment that the available information does not answer the question is more useful than a detailed response unsupported by the business’s own sources.
Build a controlled source of truth before refining prompts
Start with the material the assistant is allowed to rely on. Gather current service descriptions, policies, frequently asked questions, process explanations and other business information that has been reviewed by the appropriate people. Remove duplicate or superseded versions. If two documents give different answers, resolve the conflict rather than expecting the assistant to infer which one governs.
- Identify the questions visitors routinely ask and the claims the assistant will need to make in response.
- Select authoritative sources for those subjects and exclude drafts, obsolete documents and speculative material.
- Rewrite unclear passages so that important conditions, exceptions and terminology are explicit.
- Assign responsibility for approving changes to policies, service details and other consequential information.
- Update the assistant’s source material whenever the underlying business information changes.
- Retest the affected questions after every material update.
Structure matters as much as collection. A scattered folder of documents may contain the correct sentence without making its scope clear. State which service, audience, location or situation each rule covers. Define unfamiliar terms. Separate current policies from historical context. Where an answer depends on circumstances, document the decision boundary rather than leaving it implicit.
This is the foundation for training a website assistant on approved company information. The goal is not to upload everything the organization has ever written. It is to create a smaller, current and internally consistent body of information from which the assistant can answer responsibly.
More source material is not automatically better. Redundant, contradictory or outdated content increases ambiguity. Prioritize authoritative information that directly supports the visitor questions the assistant is expected to handle.
Set answer boundaries and a clear path for uncertainty
Once the source material is controlled, define the assistant’s operating boundaries. Specify the subjects it should address, the kinds of claims it may make and the situations that require a handoff. Its instructions should distinguish between explaining documented information, asking a clarifying question and declining to infer an answer.
Pay special attention to promises. An assistant explaining a complex service should distinguish a documented capability or process from a guaranteed outcome. It should preserve qualifications and conditions rather than compressing them into an absolute claim. This is central to explaining complex services clearly without making promises.
Language creates another boundary. Translation can preserve a factual error just as fluently as it preserves a correct answer, while terminology and policy meaning can shift across languages. If serving international audiences is important, plan separately for source quality, terminology and review in each supported language. Consider how a website assistant can support multilingual visitors as its own reliability decision rather than treating translation as a cosmetic feature.
Strong instructions do not merely demand accuracy. They tell the assistant how to behave when information is sufficient, incomplete, conflicting or outside scope.
Let’s talk about your business goals.
Test difficult questions, not just ideal demonstrations
A demonstration built from familiar questions proves very little. Before launch, test the assistant with the kinds of inputs that expose unsupported assumptions: vague wording, false premises, requests for guarantees, mixed topics, outdated terminology and questions that are almost—but not quite—covered by the source material.
- Create a set of ordinary questions with known, approved answers.
- Add paraphrases, misspellings and conversational versions of the same questions.
- Ask questions whose answers are absent from the source material.
- Introduce false assumptions and check whether the assistant corrects them rather than accepting them.
- Test questions that combine supported and unsupported requests in one message.
- Review whether qualifications, exceptions and conditions survive in the final wording.
- Correct the source or instructions behind each failure, then run the test set again.
Suppose a visitor asks about a service but also requests a guarantee that is not present in the confirmed business information. A trustworthy response can explain the documented service while avoiding an unsupported commitment. If the question needs case-specific judgment, it should move toward clarification or human follow-up rather than manufacturing certainty.
The same discipline applies when the conversation shifts toward contact details. Lead capture should follow a useful exchange and a clear visitor intention, not interrupt every question with a form. The design choices behind capturing leads without annoying website visitors affect both trust and the quality of the information collected.
Record failures by pattern, not merely as isolated bad answers. If several errors arise from one ambiguous policy, repair the source. If the assistant repeatedly overstates conditional language, strengthen that behavioral rule. If visitors keep asking an uncovered question, decide whether to add an approved answer or route it elsewhere.
Monitor the assistant as an ongoing business system
Launch is the beginning of reliability work, not the end. Real visitors ask questions that internal test teams will not anticipate. Review conversations for unsupported claims, incomplete explanations, confusing handoffs and recurring requests the source material does not yet address. Use those findings to improve the underlying information and instructions.
- Automation
- Best for repeatable explanations grounded in stable, approved information.
- Human review
- Best for correcting sources, judging sensitive exceptions and deciding what the business is prepared to state.
- Handoff
- Best when a visitor’s request depends on personal circumstances, authorization or details unavailable to the assistant.
- Ongoing evaluation
- Best for finding recurring failure patterns and deciding whether the system continues to justify its cost.
Set a review rhythm based on business risk and rate of change. A service page that rarely changes needs a different cadence from policies revised frequently. Material changes should trigger focused testing immediately rather than waiting for a general review. The broader decision is not simply whether the assistant produces answers; it is whether those answers reduce friction without creating avoidable correction work. A structured approach to evaluating whether an AI website assistant is worth the investment should include answer quality, maintenance effort and the usefulness of conversations to the business.
Organizations with limited internal AI capacity should assign clear ownership or seek outside help for source preparation, testing and ongoing management. Choosing who can build, train and manage a reliable website assistant is an operating-model decision, not just a software purchase.
If the business itself has not decided the answer, the assistant cannot create an authoritative one. Resolve the policy first or route the question to a person who can assess it.
Where Lumi, OceSha Ventures and Rohan Hall fit
Lumi is an AI assistant from OceSha Ventures that works with information a business has reviewed and approved. Its stated applications are conversational websites, customer inquiry handling and customer intelligence. That makes it relevant when an organization wants visitors to ask natural-language questions and receive responses based on the business information it has confirmed.
The surrounding governance still matters: the business must decide what information is authoritative, keep it current and define appropriate boundaries for high-stakes questions. For organizations deciding whether this model suits their site, whether a professional service website should have an AI assistant is best answered by looking at question volume, information complexity and the organization’s ability to maintain reliable source material.
Lumi sits within the work of OceSha Ventures and its AI-first solutions. OceSha Ventures builds and operates course creation, branded academies, AI assistants such as Lumi, and business intelligence for businesses and organizations. Rohan Hall founded OceSha Ventures and has built AI and blockchain systems, led work in blockchain interoperability and scalable applications, and advised on emerging technologies.
Readers exploring the broader relationship between AI and emerging technology can go deeper in Rohan’s published book, The Convergence of AI and the Top 10 Emerging Technologies. For his ventures, book, podcast and wider work, visit Rohan Hall’s home page.
Discover Rohan Hall’s ventures, published book, podcast and work across AI and emerging technologies.
Explore Rohan Hall’s workFrequently asked questions
Is a stronger prompt enough to eliminate hallucinations?
No. A prompt can establish behavior, but it cannot repair missing, contradictory or outdated business information. Reliable performance combines controlled sources, explicit boundaries, difficult testing and ongoing review.
Should an assistant answer when the source contains only part of the information?
It should answer only the supported portion and make the boundary clear. If the missing detail changes the meaning of the answer, it should ask a clarifying question or direct the visitor to a person rather than infer the rest.
How should conflicting business documents be handled?
Resolve the conflict before using the documents as authoritative sources. Identify the current rule, remove or label superseded material, and test questions affected by the change.
What kinds of questions are most likely to expose unreliable behavior?
Vague questions, false premises, requests for guarantees, outdated terminology, mixed supported and unsupported requests, and questions just outside the documented scope are particularly useful tests.
Who should own the accuracy of an AI assistant?
Ownership should sit with people who can maintain the business information, approve consequential changes and evaluate conversation quality. Technical management alone is insufficient when the underlying issue is an unresolved policy or unclear service description.
When should a question be handed to a person?
Use a handoff when the answer requires authorization, judgment, case-specific facts or information outside the assistant’s confirmed sources. The escalation path should be clear before the assistant is offered to visitors.
The bottom line
The most dependable way to prevent invented answers is to design for boundaries, not confidence. Give the assistant a controlled source of current, approved information; specify how it should respond when that information is incomplete; and test the situations most likely to produce plausible errors. Review real conversations, correct the source of recurring failures and keep consequential judgment with people. Lumi is relevant where a business wants a conversational website assistant grounded in information it has confirmed, but lasting reliability depends on disciplined knowledge ownership and ongoing evaluation.
Rohan Hall
Founder of OceSha Ventures · AI architect and author
Rohan Hall is a technology entrepreneur, AI architect and author with years of technology experience, now focused on practical AI across business, education, government and global impact. He founded OceSha Ventures, builds the OceSha AI platform and Lumi, and wrote The Convergence of AI and the Top 10 Emerging Technologies.
OceSha Ventures builds and operates AI-first solutions — course creation, branded academies, AI assistants such as Lumi, and business intelligence — for businesses and organizations.
Sources
About this page. Last reviewed .
It is based on his verified public professional record.
62b8803d0808ab0146b6de2f3b5998db