The same questions come in every day by phone, by email and through the contact form: what the opening hours are, which documents are needed, how long it takes, whether one product is compatible with another. The answers are already on the website or in internal documents; it is just that nobody finds them in time. An AI assistant for your website looks them up on the visitor’s behalf and answers in everyday words, at any hour.
What sets it apart from a generic chatbot is the source. The assistant does not answer from what the model “knows” about the world, but from the content you give it. When the answer is not there, it says so and suggests speaking to a person.
How an AI assistant for your website comes to answer from your content
The method is called retrieval-augmented generation (RAG). The website’s pages, the PDF files and the procedures are split into short chunks. Each chunk is given a numerical representation of its meaning and is stored in a vector database, that is, one that searches by meaning, not just by identical words.
When a visitor asks something, the system finds the chunks closest in meaning and passes them to the language model together with a strict instruction: answer only on the basis of these texts, and if they are not enough, say that you do not know. The answer comes with the page it is drawn from.
A simple rule follows from this: the assistant is only as good as the content. If the website shows out-of-date opening hours, or two documents contradict each other, that is exactly what it will repeat.
The features we usually put in the first version
The first version is best kept narrow: a single clear role and a set of verified sources. Expansion comes once you can see in the log what people actually ask.
A hypothetical example: a services company with three locations, which constantly gets questions about documents, opening hours and the steps involved. Its assistant would include:
- The chat window: an unobtrusive widget that states clearly that there is an automated assistant on the other side.
- Sourced answers: every answer points to the page or document used.
- The honest refusal: for questions outside the content, it is instructed to say it does not have the information instead of improvising.
- Handover to a person: on request or on sensitive topics, the conversation passes to a colleague, with the full history.
- The log: conversations are kept for review, with unanswered questions flagged separately.
- Source updates: when you change a page, the content is re-indexed.
Where it goes wrong and why we do not let it decide
A language model produces plausible text, not verified truth. Even when tied to sources, it can combine two chunks wrongly or answer an ambiguous question with complete confidence. Instructions, clean sources and testing lower the risk, but do not bring it down to zero.
That is why we limit its role. The assistant informs and guides. It does not approve requests, does not promise prices or deadlines that are not written in the sources, does not make diagnoses and does not interpret contracts. On topics like these it refers people to the right person, and we write this behaviour down explicitly and test it.
There is one more risk: visitors who try to push it out of its role with instructions slipped into the question. That is why the assistant has no access to anything that should not become public.
From the source audit to the first real conversations
The work starts with the content, not the technology. We collect the questions you get most often and check whether the answers exist in writing. Whatever is missing gets written first.
On the technical side we use a language model accessed through an API (the interface through which our program sends it the question and receives the answer), a PostgreSQL database with the pgvector extension for searching by meaning, and a chat widget that can sit on most websites, including WordPress ones.
- The test set: a few dozen real questions, with the correct answer noted by you, run after every change.
- The internal trial: colleagues try to trip it up before visitors do.
- The gradual launch: first on a few pages, then across the whole site.
- Reading the log: how many conversations end without a handover and which questions remain unanswered.
Personal data in conversations
People write more in a chat than you ask them to: a name, a phone number, sometimes details about health or money. All of it is personal data and falls under GDPR. Before launch we settle, together with your data protection officer, what privacy notice the visitor sees, what is kept in the log, for how long and who has access.
Where the processing takes place matters too. Questions reach the provider of the language model, so we choose one with which a data processing agreement can be signed, and we check in which region the data is processed and whether it is used for training. We instruct the assistant not to ask for sensitive information.
Frequently asked questions
Can the assistant give a wrong answer?
Yes. Tying it to your sources and testing it greatly reduce mistakes, but do not eliminate them. That is why every answer shows its source, and high-stakes topics go to a person.
What happens to questions it has no answer for?
It says it does not have the information and suggests getting in touch with a colleague. The question stays flagged in the log, so that you can fill the gap in the content.
How much does it cost to keep an assistant running?
It depends on the number of conversations, because the language model is paid for by usage, and on the integrations you want. Then there is upkeep: the sources have to be kept up to date and the log read regularly.
This is a typical project description: it shows how we usually approach this kind of work and does not present a project carried out for a particular client. Every real project starts from your company’s situation, and the stages, timescales and price are agreed after the initial discussion.