The AI Chatbot on Your Site: The Widget That Tracks Before It Asks
A site added an AI chatbot to help visitors find products. The widget appeared in the corner of every page, polite and ready. Nobody asked what it did before the visitor typed anything. The answer was a lot: the widget loaded a third-party script on page load, set cookies, sent the page URL and a device fingerprint to the vendor, and started a session recording. The visitor had not asked the chatbot anything. The chatbot had already told the vendor they were there.
Chat widgets are the most common consent gap on small sites, and AI chatbots make it worse. A plain chat widget loads a script and waits. An AI chatbot loads a script, sends context about the page and the visitor, and often sends the conversation to a model hosted by a third party. The visitor thinks they are talking to the site. The data goes to a vendor they have never heard of, and the banner never mentioned it.
What the widget actually sends
Before the first message, the widget usually sends the page URL, a session identifier, the visitor's browser and device details, and sometimes the referring page. After the first message, it sends the conversation itself, which can include names, email addresses, order numbers, and anything else the visitor types. That conversation is processed by the vendor's model, stored on the vendor's servers, and sometimes used to train future models, depending on the vendor's terms.
The Kukie guide to consent mode and server-side tagging makes the key point: third-party tags do not read Google's consent signals on their own. A tag that is not manually gated will fire regardless of what the visitor chose. A chatbot widget loaded directly in the page template is exactly that kind of tag. The banner can say no, the tag manager can say no, and the widget will still load, because nobody gated it.
How to gate it properly
Load the widget only after the visitor accepts the category it belongs to, usually marketing or functional, depending on what it does. The cleanest pattern is a placeholder: a small button or a collapsed panel that says chat is available, which loads the real widget only when the visitor clicks it or accepts the relevant category. The visitor who never opens the chat never gets tracked by it, and the visitor who does has made a real choice.
Check the vendor's data terms before you deploy. Some chatbot vendors use conversation data to train models by default, and some store conversations indefinitely. If the vendor's terms allow training on your visitors' messages, that is a disclosure the banner has to make, and a choice the visitor has to be offered. A chatbot that trains on visitor messages without telling them is a consent problem that no banner design can fix after the fact.
What the record has to show
The consent record for a chatbot visitor has to show the category the visitor accepted, the version of the widget in place, and the vendor's data terms at the time. If the vendor changes its terms, or the widget starts sending a new kind of data, the visitor has to be told. A chatbot is not a static script. It is a live service that changes, and the consent record has to change with it.
Test it the way a visitor experiences it. Load the site in a fresh browser, reject everything, and watch the network. The chatbot script should not appear. Then accept the relevant category and watch it load. If the script appears before any choice, the gate is decorative, and the widget is tracking visitors who said no. The test takes five minutes, and it is the only check that proves the gate works, because the banner and the settings page will both look right while the widget loads anyway.
Keep reading: what live chat widgets do to consent, what a cookie scan misses after a redesign, and how server-side tagging changes consent mode cover the nearby cases in this series.
Frequently asked questions
Does a chatbot need consent before it loads?
Yes, if it sets cookies or sends data to a third party. Most chatbot widgets load a third-party script, set cookies, and send the page URL and device details before the visitor types anything. That processing needs a legal basis, and for most sites that means waiting for the visitor to accept the relevant category.
What is the cleanest way to gate a chatbot widget?
Show a placeholder, a small button or a collapsed panel, and load the real widget only when the visitor clicks it or accepts the relevant category. The visitor who never opens the chat never gets tracked by it, and the visitor who does has made a real choice.
Can a chatbot vendor use my visitors' messages to train its models?
Some can, depending on the vendor's terms. Check the data terms before you deploy, and if the vendor uses conversation data for training, disclose it in the banner and offer the visitor a choice. A chatbot that trains on visitor messages without telling them is a consent problem no banner design fixes after the fact.
How do I test whether my chatbot respects a rejection?
Load the site in a fresh browser, reject everything, and watch the network tab. The chatbot script should not appear. Then accept the relevant category and confirm it loads. If the script appears before any choice, the gate is decorative and the widget is tracking visitors who said no.