People will type almost anything into a box that looks like it belongs to your business. Card numbers so they can pay a deposit. Their online banking password because they are locked out. Their passport number, their National Insurance number, a detailed account of a medical condition or a legal dispute.
They do it because they are trying to be helpful and get things moving. The trouble is that a chat transcript was never meant to hold that material. It gets stored, read by whoever checks the inbox, passed through webhooks to other tools and kept for as long as your retention window says.
Keeping sensitive data out of your chatbot is not a technical project. It is mostly a matter of deciding what belongs elsewhere and saying so at the right moment.
What should never go in chat
Draw the list up once, agree it with your team, and put it in the assistant's instructions. Here is a starting point, with where each thing should go instead.
| Never in chat | Why it is a problem | Where it goes instead |
|---|---|---|
| Card numbers and security codes | Card data has strict handling rules and chat is not built for them | Your payment page or a payment link |
| Bank account and sort code for refunds | Easy to misuse if a transcript is exposed | A phone call, or your accounts system |
| Passwords and login codes | Nobody at your business should ever need them | Password reset on your site |
| Passport, driving licence or ID numbers | Identity theft risk with little business need in chat | Secure upload portal or in person |
| National Insurance or tax references | Rarely needed at enquiry stage | Your client onboarding process |
| Detailed medical history | Special category data; chat is the wrong place | A consultation or clinical record |
| Details of legal disputes or allegations | Confidential and potentially privileged | A call with the right professional |
Your list will vary. A letting agent might add tenant referencing details. A school might add safeguarding concerns, which should go straight to the designated person and never sit in a chat queue.
Tell them at the moment it matters
A line in your privacy policy saying "please don't share sensitive information" is read by nobody. The useful warning is the one that arrives just before someone types a card number.
That means teaching the assistant to recognise the situations where people are about to overshare: paying a deposit, requesting a refund, being locked out, describing symptoms, explaining a dispute. In those moments it should say plainly what not to share and where to go instead.
Visitor: I want to pay the £50 deposit for Saturday. What card details do you need? Assistant: Please don't type card details here, chat isn't a secure place for them. You can pay the deposit on our payments page, and it will ask for your booking name. If you would rather, the team can call you to take payment over the phone.
Visitor: I can't log into my account, my password is Summer2024 and it won't work. Assistant: Thanks for letting me know. Please change that password straight away, since it's now been written down here. The reset link on the login page will email you a new one. If that doesn't arrive, I can open a ticket for the team.
Neither reply lectures. They name the problem once, send the person somewhere sensible and keep the conversation going.
Stop the assistant inviting it
Sometimes the assistant creates the problem. A lead capture message asking for "any details that will help us" invites life stories. A support flow asking visitors to "describe the issue in full" invites account numbers and screenshots of statements.
Go through what your assistant asks for and tighten it:
- List every question the assistant is set to ask during lead capture and ticket creation.
- Remove anything your team does not need to make the next contact.
- Replace open prompts with specific ones. "What's the best number to call you on?" rather than "Tell us about yourself".
- Add an instruction that the assistant never requests payment details, passwords or ID numbers, under any circumstances.
- Check your Q&A pairs and documents for old text telling people to "send your card details" or "email your ID", and remove it so it is never quoted.
- Test it: try to pay, try to get a refund and try to reset a login, and see what it asks for.
Give sensitive tasks a proper home
Warnings only work if there is somewhere better to send people. If your only payment method is "ring the office", visitors at 10pm will keep trying chat.
Check you have a real destination for each item in your table: a payment page or link, a password reset flow, a way to upload documents securely, a phone number for the matters that need a conversation. Put those destinations in the assistant's content so it can name them. For structured, non-sensitive details such as preferred dates, a simple form can sit alongside chat.
Health, legal and financial businesses have extra lines to draw around advice as well as data. Guardrails for regulated industries covers that side.
When it lands in a transcript anyway
It will happen. Someone will paste a full card number before the assistant can stop them. Have a short routine ready:
- Do not use it. Never process a payment from a card number seen in chat.
- Tell the customer. Ask them to pay through the proper route and, for passwords, to change them.
- Remove it. Clear it from wherever you can, in line with your data procedure, and check whether a webhook already sent a copy to a CRM, Slack or email.
- Shorten exposure. A sensible retention window means old transcripts do not sit around for years. See chat transcript retention.
Conversations are encrypted in transit and each account's data is isolated, but the safest sensitive data is the data you never collected. Our GDPR checklist covers how this fits your wider obligations.
This week
Write your own version of the table above, then search your existing conversations for words like card, password, passport and bank. What you find tells you which situations need a warning first.
Add those warnings to the assistant, tighten its questions and make sure every sensitive task has a named destination. Then agree who deletes a transcript when something slips through, and how quickly.