The chatbot has stopped being a tree of buttons disguised as a conversation. Today's generation of virtual assistants combines natural-language understanding, generative models and real-time connection to business systems to resolve, not merely to reply. But that power brings new risks: hallucinations, leaks of personal data and specific legal obligations. This article explains how to design a conversational assistant that genuinely works, the technical architecture that holds it up and what European regulation requires from 2026 onwards.
From rule-based chatbots to generative assistants
It is worth distinguishing three generations that coexist in production today. Rule-based chatbots follow a fixed script of decision trees: fast and predictable, but frustrating the moment the user strays from the foreseen path. NLU chatbots (natural-language understanding) classify the user's sentence into intents and extract entities (dates, products, amounts), which lets them understand variations of the same request. And generative assistants, powered by large language models, write replies in natural language and keep the context of the whole conversation. The frontier is no longer technological but a matter of design: the norm in 2026 is a hybrid system that uses NLU to route and a generative model to converse, with strict guardrails on what it can and cannot say.
Technical anatomy: NLU, intents and entities
The NLU engine breaks each message down into two pieces. The intent is the user's goal ("check_order_status"); the entity is the specific data the action needs ("order number = 48213"). Good conversational design begins by inventorying the 15 or 20 intents that cover 80% of real queries (not imagined ones), drawn from the history of support tickets. For each intent you define the happy path (the ideal conversation) and, above all, the error paths: what happens if the entity is missing, if the user changes topic halfway through or if they ask for something out of scope. The key metric here is the containment rate: the percentage of conversations the bot resolves without escalating to a human. A realistic target in customer service sits between 40% and 70% depending on the complexity of the domain.
RAG: the antidote to hallucinations
The biggest risk of a generative assistant is the hallucination: inventing a plausible but false answer, such as a returns policy that does not exist. The architecture that mitigates this is RAG (Retrieval-Augmented Generation). Instead of asking the model to answer from memory, RAG first retrieves the relevant fragments from the company's knowledge base (indexed as vectors in a vector database) and hands them to the model as context, instructing it to answer using only that information. This way the assistant cites the real source and, if it finds no support, admits that it does not know rather than inventing. The typical flow is: the user's question is converted into a vector (embedding), the nearest documents are found by semantic similarity, and those documents are injected into the prompt alongside the question.
Comparison of implementation approaches
| Approach | Development cost | Hallucination risk | Ideal for |
|---|---|---|---|
| Rules / decision tree | Low | None | Closed processes (appointment booking, short FAQ) |
| NLU with intents | Medium | Low | Support with a broad catalogue of queries |
| Generative without RAG | Low | High | Internal drafts, not public-facing support |
| Generative with RAG | Medium-high | Low-medium | Support based on your own documentation |
Channel integration and connection to systems
An isolated assistant replies; an integrated one resolves. The difference lies in connecting the bot to business systems through tool calling: rather than inventing the status of an order, the model calls a function that queries the ERP in real time and returns the verified data. On channels, the recommended pattern is to decouple the conversational logic from the delivery channel (web, WhatsApp Business, Telegram, mobile app) so you can reuse the same brain across all of them. The handover to a human agent (the handoff) must be designed from day one: when it triggers (detected frustration, sensitive matter, explicit request) and how the context is transferred so the customer does not have to repeat themselves.
The legal framework in 2026: AI Act and GDPR
Since 2026, any conversational assistant in the European Union operates under two rules that cannot be ignored. The Artificial Intelligence Regulation (AI Act, EU Regulation 2024/1689) imposes a transparency obligation on systems that interact with people: the user must clearly know they are talking to a machine and not a human. Hiding this is an infringement. In addition, artificially generated content must be identifiable as such.
In parallel, the GDPR governs all the personal data the user types. This entails several practical obligations: informing the user of the legal basis and purpose of the processing; applying data minimisation (not asking for more than is necessary); defining a retention period for transcripts; and, if those conversations are used to retrain models, having a specific legal basis and, normally, prior anonymisation. A frequent oversight is sending customers' personal data to a model hosted outside the European Economic Area without the appropriate safeguards for international transfers.
Metrics that really matter
An assistant without instrumentation is an experiment without a control. The metrics we recommend monitoring from day one fall into three families. The resolution metrics measure the business: the containment rate (conversations closed without a human), the escalation rate (when and why the conversation is handed to an agent) and the average resolution time. The understanding metrics measure the engine: intent-recognition accuracy, the rate of messages classified as "not understood" (the fallback rate) and the coverage of entities extracted correctly. And the satisfaction metrics measure the experience: the CSAT at the end of the conversation and the mid-interaction abandonment rate, which usually betrays loops or useless answers.
The usual trap is optimising containment at the expense of satisfaction: a bot that never lets the user out to a human "contains" a great deal but generates furious customers. That is why you should read the metrics together and manually review a sample of transcripts every week, labelling the failures to feed improvements into the training corpus. In RAG-based assistants you must also watch retrieval quality: if the fragments injected into the context are not the relevant ones, the model will answer badly no matter how excellent the model itself is. Measuring, reading real conversations and iterating is what separates an assistant that improves every month from one that stagnates on launch day.
Common mistakes when deploying an assistant
- Designing intents from imagination: instead of starting from the real query history, you cover cases nobody asks about and ignore the ones that flood support.
- Pure generative facing the public: with no RAG or guardrails, the bot ends up promising non-existent discounts or policies.
- Not designing the handoff: the customer gets trapped in a loop with no way out to a human.
- Hiding that it is a bot: besides eroding trust, this now breaches the AI Act.
- Not measuring: without containment rate, satisfaction and escalation rate, it is impossible to improve the assistant.
Frequently asked questions
What is the difference between a chatbot and a virtual assistant?
In practice the terms are used as synonyms, but "virtual assistant" usually refers to the more advanced system, able to keep context, execute actions in business systems and converse in natural language, as opposed to the rule-based chatbot with a fixed script.
How do I stop the chatbot inventing answers?
With a RAG architecture that forces the model to answer only with documentation retrieved from your knowledge base, citing the source and admitting when it has no support, instead of generating from memory.
Am I obliged to disclose that it is a bot?
Yes. The AI Act requires transparency: the person must know they are interacting with an AI system. Hiding it constitutes an infringement of European regulation.
What happens with the personal data users type in?
It falls under the GDPR. You must inform users of the purpose, minimise collection, set retention periods for transcripts and, if you use them for retraining, have an adequate legal basis and anonymisation.
Conclusion: the assistant that resolves and is accountable
A conversational assistant that delivers real value is measured not by how well it converses, but by how many problems it closes without human intervention and how reliably it does so. The recipe we apply at Summum Artificial Intelligence combines four ingredients that rarely fail together: intents drawn from the real query history, a RAG layer that anchors every answer to the company's verified documentation, integration with business systems so it acts rather than merely informs, and a well-oiled human handoff for sensitive cases. On that technical foundation, compliance with the AI Act and the GDPR is not a brake but a competitive advantage: an assistant that declares its nature, cites its sources and treats data with respect generates the trust that turns a conversation into a sale or a customer who stays. The pretty conversation is the wrapping; measurable containment and legal traceability are the business.