AI chatbot for your website: what it does for a business and how it differs from a widget

An AI chatbot for your website answers a visitor from the company's knowledge base: it finds suitable fragments in your documents and formulates an answer from them. A button-driven widget instead walks the customer through branches drawn in advance and hits "I didn't understand the question" at the first non-standard enquiry.

Below we look at how such a bot is built internally, which models are actually available in Russia, what Federal Law 152-FZ, Russia's personal data protection law, requires of a bot that collects contact details, when it pays for itself and where projects like this usually break.

What is an AI chatbot for a website?

Short answer: it is a widget on the page backed by a language model that answers strictly from your company's documents.

Technically the approach is called RAG, retrieval-augmented generation. The term was introduced by Patrick Lewis and co-authors in a 2020 paper presented at the NeurIPS conference:

We explore a general-purpose fine-tuning recipe for retrieval-augmented generation (RAG) — models which combine pre-trained parametric and non-parametric memory for language generation — Lewis et al., arXiv.

For a business owner this translates as follows. Parametric memory is what the model learned during training: general knowledge about the world, which goes stale and contains nothing about your price list. Non-parametric memory is your knowledge base, connected from the outside. Amazon Web Services describes the point of the approach as optimising the model's output so that it references an authoritative knowledge base outside its training data before generating a response.

It is the second part that makes the bot yours. Updating its knowledge means replacing a document in the base, not retraining the model.

How does an AI bot differ from a widget, a human agent and a messenger bot?

Short answer: a widget is limited by its script, a human agent costs in direct proportion to the number of enquiries, and a messenger works with a contact you have already captured.

A separate question is the difference between a bot on the site and a bot in a messenger. They cover different jobs. The site widget works with cold anonymous traffic at the moment of choice: it knows the page, the product and the referral source, but it loses the conversation as soon as the person leaves the page. A messenger bot works with a contact you have already captured and can write again later. A sensible combination looks like this: the bot on the site handles objections and qualifies, then hands the conversation over to a messenger and the CRM. On choosing a platform for the second part we have a separate piece on chatbots in Telegram and MAX, MAX being a Russian messenger.

How is a website AI bot built under the hood?

Short answer: a widget, a backend orchestrator, knowledge base search, a model, escalation rules and CRM integrations.

1. The widget on the page. A script that holds the session and passes context: which page is open, which product is being viewed, where the visitor came from.
2. The backend orchestrator. This is where all the logic lives: conversation history, request rate limiting, calling search, calling the model, rules for handing over to an agent, writing to the CRM. The model is never called directly from the browser — otherwise the access key leaks and anyone at all runs up the bill on it.
3. Knowledge base search. Company documents are cut into fragments, a vector representation is computed for each and stored. For a question the system finds the few closest fragments.
4. The model. It formulates an answer strictly from the fragments it was given, with an instruction to say it does not know and call an agent if no suitable material was found.
5. Escalation. Low confidence, the absence of relevant fragments or a direct request from the customer hands the conversation to a human along with the full transcript.
6. Integrations. Creating a lead in the CRM, notifying a manager, firing a goal in analytics.

How much of an engineering job this is can be seen clearly in the write-up of a production deployment by the team at Banki.ru, a Russian financial services portal. They have a vector store on OpenSearch, conversation history in PostgreSQL, session context in Redis, and answers generated by YandexGPT Pro 4. Documents are cut into 1000-character fragments with a 200-character overlap, and indexes are split by knowledge domain rather than dumped into one. The base holds more than 44 thousand corporate wiki documents at a response latency of about 2.5 seconds.

Which AI models are available in Russia?

Short answer: YandexGPT and GigaChat via API, enterprise deployments hosted inside your own perimeter, and open models you can install on your own servers.

• Yandex AI Studio. A platform with an API compatible with the OpenAI format. It has a Vector Store API, that is, a ready-made primitive for document search on which RAG is assembled.
• GigaChat. A Lite, Pro and MAX line-up, also an OpenAI-compatible format, with embeddings and function calling.
• GigaChat Enterprise. A separate corporate product introduced in March 2026, with three delivery options: on-premises as a hardware and software appliance, in the cloud, and a hybrid with data stored on the organisation's own servers.
• Open models on your own servers. Russian models on the level of T-Pro 2.0 from T-Bank are publicly available and suitable for installation inside your own perimeter.
• Foreign models via a proxy. Technically they work; legally they create a cross-border transfer with all that follows.

Prices here change fairly often, so it is worth going by the order of magnitude (rubles per thousand tokens) and checking the current price list on the vendor's portal rather than a figure from an article.

What does Federal Law 152-FZ require if the bot collects contact details?

Short answer: notification of Roskomnadzor, storage in Russia, separate consent and a settled answer on cross-border transfer.

The moment the widget accepts a name, phone number or email, the company becomes a personal data operator. Four requirements then apply.

1. Notify Roskomnadzor before processing begins (article 22). The forms were approved by Roskomnadzor order No. 180 of 28.10.2022 and can be filed electronically.
2. Ensure localisation (part 5 of article 18). Recording, storage and retrieval of the data of Russian citizens are performed in databases located in Russia. The procedure was tightened on July 1, 2025: first recording and storage in Russia, and only then is transfer abroad possible under the established procedure.
3. Obtain separate consent. Since September 1, 2025 consent may not be buried in the text of a contract or an offer. It is executed separately and states specific purposes, the list of data, the retention period and the withdrawal procedure. For a widget this means consent is taken at the moment the contact details are requested.
4. Settle cross-border transfer (article 12) if a foreign service is part of the chain. The operator is obliged to notify the regulator of its intention to carry out such a transfer.

This is also where the most common technical mistake sits. Public language model APIs explicitly restrict sending other people's personal data. In the GigaChat terms of use this is clause 8.7:

Within the operation of the Service and the provision of the Services, the Client undertakes not to provide/upload into the Service any personal data of third parties, nor their own biometric personal data and (or) personal data of a special category — GigaChat terms of use.

A visitor to your site is a third party in relation to you. Which means their name and phone number cannot be sent in a prompt to a public service even with technically flawless code. There are three workable options: keep contact details out of the prompt entirely (the bot answers from the knowledge base, and the enquiry form lives separately), take an enterprise deployment hosted inside the Russian perimeter, or put the model on your own servers.

It is also useful to understand where the provider's responsibility ends. Yandex Cloud states that the platform holds a certificate of compliance with personal data security requirements, and immediately adds that part of the legal requirements must be met on the client's side. A cloud certificate does not by itself make your bot lawful: the provider covers the infrastructure, while consent, notification, policy and retention periods are on you. How to build a perimeter that data does not leave is covered in the article “Neural networks without data leaks”.

Why do bots invent answers and how is that fixed?

Short answer: a model with no knowledge base attached fills in the answer from general data, and the price of that invention lands on the company.

The instructive precedent happened to Air Canada. The chatbot on the airline's website told a passenger that a bereavement fare could be claimed retroactively within 90 days, although the company's actual policy forbade it. The Civil Resolution Tribunal in Canada sided with the passenger, found a negligent misrepresentation and awarded compensation:

It should be obvious to Air Canada that it is responsible for all the information on its website — decision in Moffatt v. Air Canada, analysis by McCarthy Tétrault.

Legally, separating the bot from the brand did not work, and by the spring of 2024 the bot had been removed from the site. The practical conclusion is simple: "the bot said" means "the company said".

The cure is architecture, not talking the model round. The answer is formed only from the knowledge base fragments that were found. When there is no suitable material, the bot says it does not know and hands the conversation to a human. Terms, prices and commitments are taken from a system, not from the model's head.

What does preparation cost and where do projects break?

Short answer: the main cost item is getting the knowledge base into usable shape, not connecting the model.

The most underestimated stage is described well by the Banki.ru team:

Visually everything on the page looked coherent, but after parsing — just fragments of phrases and technical junk — a write-up of a RAG bot deployment, Habr.

Two more conclusions from the same source save budget. First: an attempt to fine-tune the model on their own data took the team about a week and was judged an unjustified use of resources, because RAG is updated by replacing a document. Second, and counterintuitive: storing conversation context turned out to do more harm than good, since users jump from topic to topic, and it was switched off.

The typical anti-patterns that recur from project to project:

1. "The bot must know everything." Trying to cover any question at all turns into an endless task. The bot should know its own domain well.
2. Fine-tuning the model instead of building a knowledge base. More expensive, slower, and the data goes stale with the next price change.
3. No confidence threshold and no escalation. Handing over to a human is a mandatory element of the architecture, not a just-in-case button.
4. Preparing the base by hand one final time. Without a reindexing pipeline the bot goes off within a quarter.
5. Expecting the bot to replace support. The working configuration is a first line plus a guaranteed handover to a human.

When does a website chatbot pay for itself?

Short answer: when the flow of repetitive questions is noticeable, the answers to them are already written, and an enquiry has measurable value.

A usefully sobering benchmark before you talk to a contractor: at T-Bank, which has its own large language model team, the share of support enquiries resolved without an agent has reached roughly 45%. Promises to close 80 or 90% of enquiries with a bot at the start of a project are worth reading sceptically.

It pays off when several conditions coincide:

• the flow of repetitive questions is steady, and the saving in people's time is visible in money;
• the answers already exist in writing: price lists, policies, frequently asked questions, contracts;
• an enquiry has measurable value (a lead, a booking, a sale) against which the effect is calculated;
• traffic arrives around the clock, and the bot covers the window when no agents are on;
• the sales cycle requires standard objections to be handled before the call.

It does not pay off when there are a handful of enquiries a week, when every question requires expert judgement (complex legal services, project engineering) or when no knowledge base exists and there is nobody to maintain one. In the last case the first budget goes on writing the documents. We worked through the economics of a first line with the numbers in the article “When a first-line AI agent pays for itself”, and the difference between a scripted bot and an agent that chooses its own steps in “AI agents for business”.

What is happening to the conversational AI market in Russia?

Short answer: the market is growing, but the pace is slowing, and the share of mature solutions is rising at the expense of experiments.

According to the Naumen study "The Evolution of Conversational AI", the Russian conversational AI market came to 8 billion rubles in 2024 and approached 11 billion in 2025, growing by around 30%. The fastest-growing segment was speech analytics.

We are seeing a qualitative shift in the conversational AI market. Where dialogue analytics used to be limited to a set of standard scenarios, systems built on generative AI are now able to find hidden patterns — Sergey Popov, director of the contact centre and robotic systems department at Naumen, company press release.

For 2026 the same study forecasts growth slowing to 20-25% and a consolidation of players: the share of mature solutions will rise, and there will be fewer experiments without a clear effect.

Where to start if you need a bot?

An order of operations that does not have to be redone:

1. Count the enquiry flow. How many questions a month and what share of them is routine. If there are few routine ones, the bot will not pay off on any platform.
2. Assemble the knowledge base. Price lists, policies, answers to frequent questions in a form a machine can process. This is the main cost item.
3. Define the escalation point. When the bot is obliged to call a human and what the agent sees at that moment.
4. Settle the data question before you start. Where the model runs, what goes into the prompt, who the personal data operator is, how consent is obtained.
5. Connect the CRM. A conversation with no lead created is a lost enquiry.
6. Budget for maintenance. Reindexing the base and reviewing bad conversations, otherwise quality drops within a quarter.

A bot on the site is part of a wider automation picture, whose workings we covered in the pillar article “Business process automation”.

At IncubeAi we build bots like this as an engineering system: the knowledge base and the logic stay on your side, the model is chosen to fit the data requirements, escalation and integrations with CRM and 1C — the accounting and ERP platform most Russian companies run on — are part of the scope, and support is available after handover. If the process is already clear, start with a conversation about it — discuss a project.

Sources

• Patrick Lewis et al., “Retrieval-Augmented Generation for Knowledge-Intensive NLP Tasks”, arXiv, 2020 — the definition of RAG.
• Amazon Web Services, “What is RAG?” — an explanation of the approach and of the typical failures of models without a knowledge base.
• The Banki.ru team, a write-up of a RAG bot deployment, Habr — the stack, the parameters and the pitfalls of a production project.
• GigaChat terms of use, clause 8.7 — the ban on uploading third-party personal data.
• Yandex Cloud, the 152-FZ compliance page — the platform's certificate and the split of responsibility with the client.
• Roskomnadzor, the personal data portal — the notification obligation and the forms under order No. 180.
• GARANT.RU, on consent to personal data processing from September 1, 2025.
• McCarthy Tétrault, analysis of Moffatt v. Air Canada — the company's responsibility for the bot's answers.
• Naumen, the study “The Evolution of Conversational AI”, October 14, 2025 — market size and forecast.