An assistant that answers visitors' questions in their own words is one of the most requested additions to a business website this year, and for good reason. Done well, it helps people find the right product, understand a service or resolve a routine question at any hour. Done carelessly, it invents facts, leaks information and leaves visitors unsure whether they are talking to a person. Since August 2, 2026, it also carries a legal duty: Article 50 of the EU AI Act requires that people be told when they are interacting with an AI system. This article covers how we add an assistant to a site so that it is useful, honest and compliant from the first day.
What the law now requires
Article 50 applies to any AI system that interacts directly with people, which includes website chatbots and voice assistants. The core obligation is disclosure: a visitor must be informed that they are talking to an AI, clearly and at the start, unless it is already obvious from the context. The same article requires that AI-generated text, images, audio and video be marked as such, a topic we covered when we wrote about the EU icons for AI-generated content. The European Commission adopted guidelines in July that spell out what adequate disclosure looks like, and the penalties for ignoring the obligation are substantial.
For a website, compliance is not difficult. It is a matter of design: the assistant introduces itself as an assistant, says so in its label and its first message, and offers a route to a human. The harder work is making the assistant worth talking to.
Scope before technology
The first decision is what the assistant is for. An assistant that answers questions about your products, opening hours, delivery terms and documentation is a well-defined tool. An assistant that answers anything is a liability. We start every project by writing down the questions the assistant should handle, the ones it should route to a person, and the ones it should politely decline. That document shapes everything that follows, and it is the single most effective guardrail.
The second decision is what the assistant may know. A good assistant answers from your content, not from the general knowledge of the underlying model. That means grounding it in the pages, documents and structured data on your site, so every answer can point to its source. Drupal is well suited to this because its content is already structured: products have fields, services have descriptions, policies have versions. The assistant reads what your editors publish, and when the content changes, the answers change with it.
Guardrails that hold
Grounding handles most accuracy problems, but an assistant still needs boundaries. We put them in several places at once.
- Instructions that define the role, the tone, the topics in scope, and the exact behavior when a question falls outside them.
- Retrieval limits so the assistant can only see content that is public, or content the logged-in visitor is allowed to see. Permissions are enforced by Drupal, not by the model.
- Output checks that catch answers without a source, answers that include personal data, and answers on topics that were declared out of scope.
- A human handoff that is always one message away, with the conversation attached so nobody repeats themselves.
The Drupal AI ecosystem has matured quickly here. Its guardrail and observability components are production-ready, and they let us log every conversation, review the ones that were escalated or declined, and tune the scope over time. Senior review applies to the assistant's behavior the same way it applies to our own work.
Data and privacy
Every message a visitor types is personal data the moment it might identify them, and a conversation with an assistant is a natural place for people to share details. We design for that. The assistant tells visitors not to share sensitive information and does not ask for it. Conversations are stored for a defined period, for a defined purpose, and the retention rule is written into the privacy policy. The model provider is chosen with data processing terms that keep prompts out of training and, where required, keep processing in the European Union. Consent is handled through the same consent layer as everything else on the site, so the assistant does not load until the visitor has agreed to it.
Measuring whether it helps
An assistant is a product, and products are measured. We track how many conversations reach a useful answer, how many are handed to a person, which questions are asked most often, and which ones the assistant could not answer. The last list is the most valuable output of the whole project: it is a ranked view of what your visitors want to know and cannot find, and it usually improves the website itself. A question the assistant is asked fifty times a week probably deserves a page.
What a project looks like
A typical assistant goes live in a few weeks. The first week is scope and content: deciding what it handles and making sure the content it needs exists and is current. The second is integration: connecting it to the site's content, permissions and consent layer, and writing the instructions and checks. The third is testing, with real questions from your team and from a few trusted customers, and tuning based on what we see. After launch, we review the logs weekly for the first month and monthly after that, adjusting scope as the questions evolve.
If you are considering an assistant, or have one already and want to be sure it meets the new disclosure rules, we would like to help. A short conversation about what it should and should not do is the best possible start.