Chatbot Privacy and Compliance: What Your Bot Should Never Ask For

The card number in the chat window

A customer service transcript we reviewed contained a full card number, expiry, and CVV, typed by a customer who was trying to pay a deposit. Nobody had asked for it. The bot had said "I can help with that, what's the booking reference?" and the customer, being helpful, pasted everything.

That transcript sat in a vendor's dashboard for eleven months, readable by anyone in the business with a login, because the retention setting had never been changed from its default.

Nobody did anything wrong deliberately. That's the point. Chat privacy problems are rarely malicious; they're the accumulation of defaults that nobody chose.

Every message is personal information

A transcript becomes personal data the moment it contains something that identifies a person, and identifiers arrive fast: a name in a greeting, an email address, an order number, a postcode.

Under the GDPR in Europe, PIPEDA in Canada, and the CCPA as amended by the CPRA in California, information collected from a customer carries obligations about purpose, disclosure, retention, and access. Chat isn't exempt because it feels like conversation. If anything it deserves more attention, because people type things into a chat window they would never put in a form.

A question about a treatment can reveal a health condition. A question about affordability can reveal a financial situation. A complaint can hand over an address, a phone number, and the name of the person handling the account, all in one sentence.

This is general guidance, not legal advice, and the specifics vary by jurisdiction. The decisions belong with someone who knows your situation; the questions below are the ones to bring them.

Disclose before the first message

A short line in or beside the widget costs nothing and sets expectations: this is an automated assistant, here's what's collected, here's what it's used for, here's the privacy policy.

Two details that get missed:

Say it's a bot, plainly. Not "digital assistant powered by AI" as the only clue. Some jurisdictions require that a person can tell they're dealing with an automated system, and in any case customers are less forgiving when they discover it later.

Ask where consent is required. A brief permission line with a real decline option beats a clause buried in a policy. "Can I take your email to follow up?" with a no that works is better than assuming.

What never to ask for

Data minimisation means collecting only what the task requires. Applied to a chat window, it produces a short list of things the agent should never request, and should redirect if offered:

• Government identification numbers
• Full payment card details, at any point, in any workflow
• Passwords, PINs, or security question answers
• Health, diagnosis, or prescription details beyond what a service enquiry needs
• Date of birth when a name and a time would do
• Home address when a postcode answers the question

If a workflow genuinely needs an identifier, the right pattern is a secure form sent after handoff to a person, not a line in a transcript.

The card number example above is worth designing against directly: teach the agent to say "please don't send payment details here, I'll send you a secure link", and make sure the transcript where someone ignored that is easily deletable.

Sensitive categories need different rules

Health data, financial account details, children's data, and biometric information are treated as sensitive or special category under most privacy regimes. Businesses in healthcare, finance, childcare, and education should assume stricter rules apply: what may be discussed in chat at all, who reviews transcripts, and whether an automated system should be processing that conversation.

The reliable pattern, and the one I'd recommend for regulated services, is to route sensitive topics straight to a human channel rather than attempting an answer. The agent's job becomes recognising the topic and handing over, which is a much smaller privacy footprint.

Four questions that resolve most storage risk

1. Where does the transcript live? Inside your systems or the vendor's platform? Both are workable. Not knowing which is not.
2. Who can read it? Named roles, not everyone with a login. Review the access list quarterly; it grows quietly.
3. How long is it kept? A defined period with automatic deletion beats an indefinite archive. Thirty to ninety days covers most support needs.
4. How is a deletion request executed? It needs a written procedure that includes transcripts held by the vendor, because that's where they'll actually be.

Third-party processing

There is almost certainly at least one other company involved: the widget provider, and often a model provider behind it. They're processors acting on your instructions, which means you need clear answers about what they do with the data, where they process it, whether they train models on it, and what your agreement says.

A vendor who can't answer "are customer conversations used for training" clearly and quickly is a vendor to walk away from. That question has a contractual answer, and vagueness is the answer.

Also check sub-processors and location. A processor storing data in a region your customers' law doesn't permit is a problem that surfaces much later, usually in a complaint.

Customer rights, in words the agent can use

People ask two things constantly: "am I talking to a bot?" and "can you delete my details?"

Both need approved wording, written down, and a route that works. A deletion or access request that disappears into a chat log is a compliance failure waiting to be discovered, and it's the kind of thing that gets found during a dispute rather than in a routine review.

The agent doesn't have to resolve these itself. It has to reliably hand them to a person, with a record that it did.

Security basics worth checking

• Encrypt in transit. A widget loading over an insecure connection undermines everything else.
• Keep credentials out of prompts. No API keys, no internal notes pasted into the system prompt, no admin links.
• Log access to transcripts, not just access to the dashboard.
• Test the handoff. Send a message containing "please delete my data" and see where it goes. Do it before a customer does.
• Review transcripts monthly. Ten is enough. You're looking for what people volunteered that you never wanted.

A note on training your own model

If you're fine-tuning on customer conversations, that is a materially different privacy position from using a hosted assistant. Consent, de-identification, and a documented basis are not optional there. De-identify aggressively: names, order numbers, and any free-text field can carry identifying detail that regexes miss.

Where to start

Two things this week: write the disclosure line for the widget, and check your transcript retention setting. Those are the two that cause the most trouble and take the least time.

A free digital presence audit on Webcheckhub includes website health and conversion readiness, which is where chat widgets usually show up as either an asset or a liability before you get to the legal questions. When you want the chatbot built with these constraints designed in from the start rather than retrofitted, Solutions Elites builds customer-facing automation for small businesses.