You want visitors to get help without sending every question to a remote AI service. On-device AI can help with that, but the phrase needs one clear limit: it describes where an answer is produced, not every step used to build and deliver the chatbot.

With Kanha, crawling and training happen on Kanha infrastructure. For Kanha's browser path, the finished model is delivered to the visitor's browser. When an answer runs there, it can be produced without sending that message to a hosted model for an answer.

That is useful for privacy. It is not a promise that nothing ever leaves the device. Here is the full path to review.

See where the data goes

1. Your pages go to Kanha for crawling

You choose the website pages the chatbot should learn from. Kanha fetches those pages and processes their text on Kanha infrastructure.

Only include content that is suitable for the service and for your intended audience. A public page can still contain an old price, an accidental personal detail, or internal information that should have been removed.

Review representative pages after they are crawled. The sites and pages guide explains crawling, recrawling, review, and deletion.

2. Training also happens on Kanha infrastructure

Kanha turns the selected content into question-and-answer examples. You review those examples, choose what to include, and start a training run. The training does not happen in each visitor's browser.

Treat account access, stored training material, model files, retention, and vendor terms as part of your normal privacy and security review. Local answers do not remove those decisions.

The dataset guide shows how to remove unsuitable examples before training.

3. The browser downloads the chatbot and model

When a visitor opens the chatbot, the browser needs to download its code and model files. That uses the network. The browser then prepares the model and may store files for a later visit.

The services that deliver those files may receive ordinary request details such as an IP address, browser information, timing, and cache requests. The exact records depend on the delivery setup and its policies.

So on-device answering does not mean zero data travels over the network.

4. A ready model can answer locally

Once the model is loaded and ready, it can produce the answer in the visitor's browser. Kanha does not need to send each message to a hosted model to generate that answer.

This changes the path of the question. It does not control the rest of the page. Analytics tools, tag managers, browser extensions, custom event listeners, and other scripts may still collect or send their own data. A site owner could also add message logging around the chatbot.

That is why the accurate promise is narrower: the local answer itself does not require a per-message request to a hosted model. The full page still needs its own review.

Know what on-device AI privacy improves

Local answers can keep each question out of a hosted model request. That can reduce the number of services involved in a conversation and make it easier to explain the message path.

It can also remove a hosted model fee from each message when the answer actually runs in the browser. Crawling, training, and model delivery are still separate. The AI chatbot pricing guide explains how Kanha counts pages and training runs.

After the model is ready, answer speed is less tied to a trip to a remote model. The first download, preparation time, available memory, and device speed still matter. Use the on-device speed guide to test those parts.

Keep the promises you can prove

On-device AI is one fact in a privacy review. It is not a legal conclusion. Your duties depend on your visitors, content, location, purpose, settings, and the other tools on the page.

Before launch, decide:

Which pages are safe to crawl and use for training.
Whether visitors may type personal or sensitive information.
Which page scripts can observe the chatbot.
Who can access training material and model files.
Whether you added analytics or custom logging.
What you tell visitors about the chatbot and its limits.
How people can get help when an answer is wrong.

Avoid promises that depend on every browser, script, and future site change behaving the same way.

Test the browsers your visitors use

Browser name alone does not tell you whether a model will load or how it will perform. The browser version, device, available memory, selected model, and graphics support can all change the result.

The public install asks for one model size. It does not inspect the device's memory and automatically choose Small, Medium, or Large. Smaller models usually need fewer resources, but you still need to test the exact size you plan to use.

Kanha takes responsibility for compatibility work when an environment needs a different approach. That does not mean every environment already behaves the same way. Any adapted path also needs its own data review.

Do not promise offline use. A first visit needs the chatbot and model files. Stored files can be removed, and the surrounding page may depend on other online services.

Run this privacy check before launch

Draw the path from your source pages to the visitor's answer. Include crawling, example review, training, model storage, file delivery, the browser, and every page script that can observe the chat.

Then verify it:

Check important crawled pages and training examples.
Confirm which model size the public install requests.
Open the chatbot on your target browsers and devices.
Use browser network tools to see downloads and message-time requests.
Review analytics and custom listeners around the chat.
Record any environment that needs compatibility work.

This gives you a privacy statement you can support with evidence. The setup guide walks through the same path from page selection to a tested install.

On-Device AI Privacy: What Stays in the Browser