Adding an AI chatbot? Check these 5 data flows before launch

Before adding an AI chatbot to a website, inspect what loads on arrival, what happens when someone opens the chat, where messages go, how long they are kept and whether data is reused. Cookie consent is one part of that review. It does not settle every question about the conversation itself.

This guide uses a fictional online shop adding an assistant to answer delivery questions. The workflow is illustrative, not a claim about a specific chatbot provider.

1. What loads before anyone opens the chat?

Install the widget in a test environment and visit the page without interacting. Inspect the browser's requests and storage. The small chat icon may arrive with analytics, identifiers or services you did not expect.

Ask the supplier which components are required to display the button and which support optional measurement or advertising. Do not categorise the whole integration as necessary merely because the team wants a chatbot.

For the browser inspection, Chrome's Network panel helps show where requests go. Compare the observed behaviour with the supplier's documentation.

2. What changes when a visitor opens it?

Clicking “Chat” can load a new frame, establish a session or introduce a separate service. Repeat the inspection at this point.

In our fictional shop, the team chooses a lightweight launcher and loads the conversational service when requested. That is a design choice to reduce unnecessary loading; it is not, on its own, a determination that every resulting cookie or data use is exempt from consent.

For UK sites, use the ICO's current guidance on storage and access exceptions to assess the relevant conditions. Do not automatically apply a UK exception to EU markets.

3. Where does the message go?

A delivery question may contain an order number, email address or home address. Follow that message beyond the browser: chatbot vendor, model provider, support platform and any internal logs.

Ask for the actual processing arrangement, not only a statement that the tool is “secure”. If personal data is involved, the GDPR requires attention to matters such as lawful basis, transparency, processor arrangements and international transfers where applicable.

Give visitors a short explanation before they submit information. Where possible, design the experience so they do not need to type sensitive details into a general chat box.

4. Is the conversation used for anything else?

Separate providing the answer from improving the vendor's models, product analytics and marketing. Ask which uses are enabled by default and whether they can be disabled.

In the fictional shop, the assistant needs a delivery postcode to answer one question. It does not follow that the same conversation should populate an advertising audience or be retained indefinitely for model training.

Record the intended purposes and the vendor settings that implement them. Keep a copy of the relevant configuration so a later account change can be checked against it.

5. What happens after the conversation ends?

Confirm retention, deletion, access controls and the route for handling privacy requests. Find out whether deleting a conversation in the dashboard also removes it from connected systems, backups or model-provider logs under the applicable arrangements.

Test with synthetic information, not a real customer's details. Submit a sample request, follow it through the agreed process and record which systems need action.

Add the chatbot to your normal consent review

Retest the relevant website journeys after installation:

• A fresh visit before any consent choice.
• A visit after optional tracking is rejected.
• Opening the chat and sending a synthetic message.
• Changing preferences after the chat has loaded.
• Returning with a saved choice.

Use the cookie-banner test guide and update the website's inventory. A new widget deserves the same scrutiny as a new advertising pixel.