Working Responsibly with LLMs
Understand LLM non-determinism, your responsibility as a Virbe platform user, and the best practices for building safe, reliable AI-powered virtual beings.
Virbe makes it easy to connect large language models (LLMs) to your virtual being. With that capability comes important responsibility. This page explains how LLMs behave, what that means for you as the person building the assistant, and how to mitigate the risks that come with AI-generated responses.
LLMs are non-deterministic
The most important thing to understand about LLMs – OpenAI GPT, Claude, Gemini, and every other model – is that they do not produce the same output every time for the same input. Ask the same question twice and you may get two different answers. This is not a bug in Virbe or in the model. It is a fundamental property of how these models work.
What this means in practice:
- Testing once is not enough. A response that looks correct in one test may occasionally produce something unexpected in production. Test critical flows many times.
- Responses will vary. The same user question, asked on different days or in different sessions, may receive responses that differ in phrasing, detail, or even content.
- Exact matching is fragile. If your pipeline relies on an LLM producing a specific keyword or phrase (e.g., for branching logic in an If-Else Router), that assumption will sometimes break. Use other more deterministic flows with Signals, Collect User Data, or explicit routing instead.
- Non-determinism is a debugging candidate. When a user reports unexpected assistant behaviour and you cannot reproduce it, non-determinism is always a possible explanation – not necessarily a bug.
Model hallucinations
Understanding the concept of hallucinations matters for knowing what to expect and how to approach unexpected outputs.
Model hallucinations (inherent to LLM technology) are outputs that are grammatically fluent and confidently stated but factually wrong, incomplete, or fabricated:
- The assistant states a product feature that does not exist;
- The assistant cites a policy, law, or procedure incorrectly;
- The assistant invents a number, name, or date;
- The assistant provides a response that sounds plausible but contradicts the Knowledge Base content.
Hallucinations are not a defect in the Virbe platform. They are a documented, inherent property of probabilistic language models – all current LLMs produce them at some rate, regardless of the platform they are deployed through. The presence of a hallucination in a conversation does not by itself indicate that the System malfunctioned.
No-reliance notice
Responses generated by the virtual being should not be relied upon as a substitute for professional advice, verified official information, or authoritative sources.
End users interacting with a virtual being powered by a large language model should:
- Treat responses as a starting point, not a definitive answer;
- Verify any consequential information (pricing, terms, legal or regulatory requirements, medical guidance) through official channels;
- Not act on virtual being responses alone for decisions with material consequences.
As the operator, you are responsible for making this expectation clear to your users – through the interface, your privacy notice, or explicit disclaimers where the virtual being is deployed in a regulated context.
Virbe's built-in risk mitigations
While operators are responsible for their deployment configuration, Virbe applies the following measures at the platform level to reduce the risk of harmful or unsafe outputs:
Content safety filtering
Where the AI infrastructure you configure provides content safety filtering – for example, Azure AI Content Safety on Azure OpenAI deployments – those filters remain active for requests made through Virbe. Virbe does not disable, weaken, or bypass provider-side safety mechanisms. These filters operate at the model provider level and screen for harmful, abusive, or policy-violating content before it reaches the user. The availability and strictness of such filtering depends on the provider and model you configure; not all providers offer an equivalent layer.
Knowledge Base grounding
The Tool Agent and LLM Response nodes support Retrieval-Augmented Generation (RAG) – retrieving relevant content from your Knowledge Base and providing it as context to the model. This grounds responses in your approved content and reduces the rate of hallucination for topics covered in the Knowledge Base.
Refusal behaviour
LLMs used through Virbe retain their built-in refusal capabilities – they will decline requests that trigger the model's safety training (harmful, dangerous, or policy-violating requests). Staying within your configured scope, by contrast, is not built in: it depends on the System Instructions and Agent Goals you write, and should be treated as a best-effort constraint, not a guarantee.
These mitigations apply to responses generated through Virbe-configured AI models (Tool Agent, LLM Response). When a conversation is handled by an external engine – a Custom Endpoint or DifyAI – Virbe passes messages to your backend and returns its responses. The safety measures, filtering, and refusal behaviour of that backend are configured and owned by you, not by the Virbe platform.
These measures reduce risk but do not eliminate it. LLMs remain probabilistic systems. Ongoing monitoring, testing, and Knowledge Base maintenance by the operator remain necessary for a safe and reliable deployment.
You are responsible for what your assistant says
The organisation or individual using the Virbe platform to build and deploy a virtual assistant is responsible for the assistant's behaviour – what it says, how it behaves, and whether it is appropriate and accurate for your use case.
This responsibility does not transfer to Virbe or to the underlying AI model provider (OpenAI, Anthropic, Google, etc.). Virbe provides the tooling; you are accountable for the deployment.
Your responsibilities include:
- Writing effective System Instructions and Agent Goals that constrain the assistant to your use case;
- Testing across realistic conversations and edge cases before going live;
- Monitoring live conversations and responding promptly to unexpected behaviour;
- Ensuring the assistant does not make claims, commitments, or promises it shouldn't;
- Applying appropriate guardrails for your audience (e.g., additional constraints for deployments serving children or vulnerable groups).
Following model provider best practices
Virbe provides the infrastructure and tooling for building AI-powered virtual beings. The intelligence itself comes from the AI model provider you configure. Each provider publishes documentation, best-practice guides, and prompt engineering guidance specific to their models.
You are responsible for following the guidance of the model provider you use. This includes:
- Prompt engineering — how to write System Instructions, Agent Goals, and context injections that produce safe, reliable, on-topic responses. Follow the provider's prompt engineering documentation for the specific model version you deploy.
- Model-specific safety features — each model has its own refusal behaviour, safety classifiers, and content policies. Understand what your chosen model will and will not do, and design your flows accordingly.
- Model versioning — providers update and deprecate model versions. When a model version you depend on is deprecated, responses may change. Monitor provider release notes and test thoroughly after any model version change.
- Token limits and context windows — each model has hard limits on context size. Exceeding them silently truncates your System Instructions or conversation history, which can cause unexpected behaviour. Consult provider documentation for the limits of the model version you are using.
Virbe's recommendations in this documentation are general best practices applicable across providers. Where provider-specific guidance differs from or supplements Virbe's general guidance, the provider's documentation for your specific model takes precedence.
Always disclose that the user is talking to an AI
End users have a right to know they are interacting with an AI system, not a human. This is an ethical requirement and, increasingly, a legal one – regulations in various jurisdictions may require disclosure.
The rule: Your virtual being should make clear – at the start of the interaction or when asked – that the user is talking to an AI.
How to implement this in Virbe:
- AI Disclaimer setting – Enable the Show disclaimer toggle in Web Widget profile settings to display a disclosure message before or during the conversation
- Greet flow message – Add an explicit introductory message in your Greet flow: "Hi, I'm Alex, an AI assistant powered by Virbe. How can I help you today?"
- System Instruction – Include an instruction in your Tool Agent or LLM Response node: "If the user asks whether you are a human or an AI, always clarify that you are an AI assistant."
- Never configure the assistant to deny being an AI – if a user sincerely asks whether they are talking to a human, the assistant must not claim to be human
Risk mitigation best practices
The mitigations below are recommendations based on common patterns – not bulletproof solutions. LLMs remain probabilistic systems, and no configuration or architectural pattern can guarantee a specific outcome in every conversation. Applying these practices reduces risk meaningfully, but ongoing monitoring and iteration remain necessary.
| Risk | Mitigation |
|---|---|
| Inconsistent responses | Write specific, detailed System Instructions; test repeatedly; add Guiding Steps in the Tool Agent to constrain the conversation path |
| Hallucinated facts | Ground responses with a Knowledge Base (Tool Agent + RAG); include instructions to say "I don't know" rather than guessing; use Find Records for precision data |
| Off-topic responses | Constrain scope in System Instruction and Agent Goal; use If-Else Router or Intent Matcher after LLM response nodes to detect off-topic output |
| Users misled about AI nature | Enable AI Disclaimer in profile settings; include self-identification in System Instruction; build a dedicated response for "Are you human?" intent |
| Sensitive data in responses | Avoid injecting PII into LLM context; use Store Variable for sensitive fields; do not pass user-entered credentials or personal data through prompts |
| Model provider outage | Add a fallback Text node for "On error" exit in LLM nodes for graceful degradation: "I'm having trouble connecting – please try again shortly." |
| Unexpected language switching | Handle the On Language Change handler explicitly – use Accept or Reject Language Change nodes to control when switching happens |
| Users triggering unintended flows | Use Intent Matcher and Route by Signal nodes to guard critical flow entries; do not rely solely on freeform LLM routing for high-stakes paths |
Using deterministic nodes for high-stakes logic
LLM nodes (Tool Agent, LLM Response, Intent Matcher) introduce variance. For logic where consistency is essential, use deterministic nodes instead:
| For this | Use this instead of an LLM node |
|---|---|
| Fixed choices | Quick Reply node |
| Gathering a specific piece of information | Collect User Data node |
| Routing by a known condition or variable | If-Else Router node |
| Looking up exact structured data | Find Records node |
| Delivering an exact, required message | Text node |
Reserve LLM nodes for tasks where natural language generation adds genuine value – answering open-ended questions, summarising information, handling diverse phrasings of similar intent. Use deterministic nodes everywhere consistency is required.
Prohibited and unlawful uses
The Virbe platform and the AI models accessible through it must not be used for purposes that are illegal or contrary to applicable law or the acceptable use policies of the underlying model providers. Prohibited uses include, but are not limited to:
- Generating, distributing, or facilitating content that is unlawful, defamatory, harassing, or otherwise prohibited by applicable law;
- Processing or soliciting special-category personal data (health, financial, biometric, criminal) without appropriate legal basis and safeguards;
- Using the platform to deceive end users in ways that cause harm, including impersonating real individuals or institutions without authorisation;
- Circumventing or attempting to override the safety filters, refusal behaviours, or content moderation mechanisms of the underlying AI models;
- Generating content that infringes third-party intellectual property rights;
- Using AI-generated content to manipulate, discriminate against, or harm individuals or groups in a manner contrary to applicable anti-discrimination or consumer protection law;
- Any use that violates the acceptable use policy of the AI model provider you have configured (OpenAI, Anthropic, Google, Microsoft, or other).
Each AI model provider publishes its own usage policies. You are responsible for reading and complying with the acceptable use policy of every provider you configure in Virbe – not just Virbe's own terms.