What to tell visitors about AI chat and data

Almost every site with an AI assistant has a privacy policy that covers it somewhere. Almost none have anything useful at the moment of interaction, which is the only moment the visitor is thinking about it.

What belongs at the point of interaction

Four facts, in as few words as they can honestly be expressed:

• This is an AI assistant, not a person.
• The conversation is stored.
• Roughly what it is stored for.
• How to reach a human instead.

That is it. Not the full data flow, not the provider list, not the retention schedule. Those belong on the policy page and linking to it from here is enough.

Why the AI disclosure matters even when it is obvious

Some teams skip it because they think it is evident. It usually is, and stating it anyway does two things. It removes any argument that a visitor was misled, and it sets expectations so that a limited answer reads as a known limitation rather than a person being unhelpful.

There is also a direction of travel worth noting: disclosure requirements for automated systems are tightening in several jurisdictions. Stating it plainly is cheap now and avoids a retrofit later.

Writing it without a legal tone

The failure mode is writing three sentences that read like a contract. Compare:

Interactions with this automated service may be recorded and processed by third party service providers in accordance with our privacy policy.

You are chatting with an AI assistant. We save these conversations so we can improve our website. Ask for a person any time.

Both are accurate. The second gets read. The first is a legal reflex that produces no comprehension and no goodwill.

Where to put it

Below the input field, in small but readable text, visible when the chat is open. Not in a tooltip, not behind an info icon, and not only in the first message where it will scroll away.

Small text still has to meet contrast requirements. This is a place where sites routinely fail their own accessibility standard because the text is considered incidental. It is not incidental. It is the disclosure.

What to do if a visitor types something sensitive

They will. People paste order numbers, email addresses, and occasionally things far more sensitive into chat boxes. Two things follow.

Decide in advance whether the assistant should acknowledge and redirect when it detects something like a card number, and have a deletion path so that when someone asks you to remove what they typed, there is a real process rather than an improvised one.

Our own position

Applying this to Creobot: its provider and retention details are not final, and we would rather publish that than a confident placeholder. When those details are settled they will be published before anyone is charged.

The minimum honest disclosure

Three things, in one line, before the first message. That this is an AI assistant. That the conversation is stored. Where the privacy detail lives.

One line, not a consent wall. A long disclosure at the point of a question is read by nobody and reduces the chance the question gets asked at all, which serves neither party.

The reason to include it despite that is straightforward: visitors paste things you did not ask for, and the disclosure is what makes storing the conversation defensible.

Where a second disclosure is required

At the point of capture. When the assistant asks for an email, that is a different act from answering a question, and the visitor is entitled to know what it will be used for at the moment they decide.

One sentence again. What you will send, and that they can decline and still get the answer. The second half matters, because a capture prompt that reads as a condition of help is both worse for conversion and worse for trust.

Wording that works

Say AI assistant rather than a name. Visitors need to know they are not talking to a person and a friendly name obscures exactly that.

Say conversations are saved rather than we may collect certain information. The first is a fact. The second is a category of facts and reads as evasion.

Do not claim more than you can support. We never share your data is a strong claim that involves every subprocessor in your chain, and it is one most vendors cannot honestly make.

And link rather than summarise. A one line disclosure with a link to real detail respects both the person who wants to read it and the person who does not.

What happens when someone pastes something sensitive

They will. Order numbers, email addresses, occasionally a card number, usually because they are trying to be helpful and think they are talking to support.

Plan for it rather than hoping. Detect and redact obvious patterns at write time, before the transcript is stored, so the value is never persisted rather than persisted and hidden.

Tell the visitor when it happens, briefly. A line saying that details like that are not needed here and have not been kept does more for trust than any policy page, because it is visible at the moment it matters.

And make sure the redaction applies to whatever ships in the escalation payload too. A transcript scrubbed in storage and unscrubbed in an email notification has not been scrubbed.

Say it once, in the right place

The common failure is disclosing everywhere. A banner, a first message, a footer note and a checkbox all saying versions of the same thing, which reads as anxiety and gets ignored wholesale.

One line before the first message, one line at the point of capture, and a link to real detail. That is the complete set, and anything beyond it is protecting you rather than informing them.

The test is whether a visitor who read only your disclosure could correctly describe what happens to their message. If yes, it is enough. If they would need the privacy page to answer that, the line is too vague rather than too short.

Where consent genuinely applies, and where it does not

There is a difference between telling someone what happens and asking their permission, and conflating the two produces either an unnecessary barrier or a missing safeguard.

Answering a question the visitor asked is generally not a moment that requires consent. They initiated it, the processing is the thing they requested, and putting a checkbox in front of it is friction with no protective value.

Storing the transcript for your own analysis is a different act, and it is the one the disclosure covers. Telling them plainly is the right standard for most sites, and a jurisdiction may require more.

Capturing contact details for marketing is a third act and it is the one that clearly needs an affirmative choice rather than a notice. It should be a decision the visitor makes, phrased so that declining is obviously available and obviously costless.

Analytics or tracking scripts loaded alongside the widget fall under whatever consent regime the rest of your site already operates. The assistant does not get an exemption because it arrived later.

This is not legal advice and the specifics vary by jurisdiction. What is portable is the principle: separate the acts, and match the mechanism to the act rather than applying one banner to all of them.