Chatbot data security: personal data, access and retention

A chatbot is the employee that sees the most data

A chatbot talks to hundreds of customers a day: names, phone numbers, addresses, order numbers, sometimes health or financial details. On top of that it connects to the CRM, the order system and the knowledge base. In other words, the chatbot is the company's «employee» that sees the most data and has access to the most systems. Yet in most projects the security question is asked at the end, the day before the contract is signed.

This article is a practical framework for data security in chatbot integrations: a risk map, the minimum-data principle, access rights, handling personal data, retention, audit logs and questions for the vendor. What the bot may say or do — guardrails — is a separate topic; here the subject is protecting the data itself. Legal requirements differ for every company and should be checked with your own lawyer.

A risk map: where the data lives

1. 1The conversation itselfEverything the customer writes — including what they should not: a card number, a photo of an ID, health details.
2. 2The knowledge baseThe material the bot answers from. An internal document — margins, staff numbers, contract terms — can end up here by mistake.
3. 3IntegrationsCRM, order system, payment status. The more systems the bot connects to, the bigger the impact of a misconfiguration.
4. 4Exports and reportsExcel exports, analytics, reports sent by email — data leaves the system.
5. 5PeopleAgents, salespeople, the technical team, the vendor's support team — who sees what?

The minimum-data principle

The safest data is data never collected. For every field, one question: is this really needed for the next step?

• A lead needs a name and phone; a date of birth or home address usually not
• A status question needs an order number and a verification field; showing the full address is unnecessary
• The bot should not ask for card details, passwords or ID numbers
• If a customer volunteers sensitive data, the bot should not repeat it or copy it into another field
• The fields the bot reads through an integration should also be minimal — not the whole customer card

Access rights

Who sees what is the most often forgotten part of security.

• Role-based access: agents see conversations, salespeople see leads, managers see reports — not everyone sees everything
• The bot should have read-only access in integrations, and write access only to the fields it needs
• A departing employee's access should be closed at once
• The vendor's team should look at your data only when technical support requires it
• Activity in the account — who changed what — should be logged

In Vexvon, access rights are managed at user and role level, a user removed from the account loses access immediately, and activity is logged; these rules are set out on the security page.

Personal data (PII)

1. 1CollectionWhich personal data is collected, and for what purpose, should be written down.
2. 2UseThe data is used only for that purpose — running the service. Marketing needs separate consent.
3. 3SeparationOne company's data should be kept apart from other customers' data.
4. 4TransferData travels over an encrypted channel (HTTPS/TLS).
5. 5Model trainingThe company's conversations and documents should not be used to train shared AI models — a question to ask the vendor in writing.

Retention and deletion

• How long conversations and records are kept — this should be set in the contract
• A specific customer's record can be deleted on request
• The company can export all its data
• When the service ends, data is deleted after an agreed period
• Exported files — Excel, reports — follow the retention rule too

Integration security

When the bot sends requests to company systems, three risks arise: a wrong request, too much data returned, and an attempt to reach another system through the bot.

• The bot sends requests only to addresses allowed in advance
• API keys are issued with minimum rights and rotated regularly
• Only the part of the response the customer needs is shown
• No personal data is returned without an identity check

In Vexvon, the bot's requests to company APIs are protected against SSRF — the bot being tricked into sending requests into an internal network. The integration architecture itself is covered in chatbot API and webhook integration.

What the bot must not say

Data security is protected not only at system level but in the answers too: the bot must not tell a customer internal information that sits in the knowledge base, and must not be talked into revealing someone else's data.

How the bot's read, write and promise permissions are set up is covered in AI chatbot guardrails.

Example: a customer types their card number

1. 1Customer«The payment didn't go through, here's my card: 4169 …, expiry …, the code on the back …»
2. 2Bot«For your security, please don't type card details in chat — we don't store or use them. To retry the payment we can send you a link to the secure payment page, or pass this to a colleague. Which would you prefer?»
3. 3Behind the scenesThe message is not shown to agents as full text and does not reach exports or reports with the card details — a rule the platform and the company should agree in advance.

When an incident happens: first steps

• Who finds out and who they notify — a person named in advance
• Which access or integration key is closed immediately
• How the affected data is identified — the logs
• What customers and, if needed, the regulator are told, and when — with the lawyer
• Which rule changes after the incident

This plan should be written on one page before the project starts — a plan written during an incident is always late.

A vendor checklist

When choosing a chatbot platform or signing the contract, ask these questions in writing:

• Where is our data stored, and how is it separated from other customers' data?
• How is data protected in transit and at rest?
• Are our conversations and documents used to train AI models?
• When and how can your team look at our data?
• At what level are access rights managed, and is activity logged?
• Can we set the retention period ourselves?
• How are export and deletion done, and how long do they take?
• What happens to the data when the service ends?
• Will you answer our legal team's questions in writing?

An internal checklist before launch

• The knowledge base has been checked for internal information — no margins, staff numbers or contract terms
• The list of fields the bot collects is minimal
• Roles and access rights are assigned
• Integration keys are issued with minimum rights
• The bot's reply to a customer who types sensitive data is prepared
• The retention period and deletion procedure are agreed

Limits

This article is not legal advice. Personal-data law differs by country, sector and type of data; banking, insurance and healthcare may have extra requirements, and the company's lawyer should define them. No platform delivers «compliance» on its own — compliance comes from the platform's capabilities and the company's own processes together.

Conclusion: ask about security at the start

Chatbot data security starts with three decisions: collect only the data you need, limit who sees what, and decide in advance how long data is kept and how it is deleted. Minimum rights in integrations, written answers from the vendor and an internal check before launch turn those decisions into practice.

How personal data is protected when analysing conversations is shown in chatbot conversation analytics; the rest of the section is in this category. To discuss your legal team's questions, get in touch.

Frequently asked questions

1. 1Does a chatbot use customer data to train its AI model?It depends on the platform and should be asked in writing. In Vexvon, uploaded databases, conversations and documents are not used to train shared AI models.
2. 2Can the bot accept card details?It should not. Payment should happen on the payment provider's secure page.
3. 3Can data be deleted?Deleting a specific customer's record, and deleting all data when the service ends, should be written into the contract and carried out on request.