Chatbot data privacy comes down to three flows of information, and most vendor pages only discuss the third. There are the documents you connect, which may include internal policies never meant for the public. There are the messages your visitors type, which arrive with whatever personal detail they chose to include. And there is your own account and billing data, which is the ordinary part.

Each flow leaves your control at a different moment and reaches a different set of companies. What follows is the set of questions worth asking any chatbot vendor, and our own answers to them, so you can see what a complete answer looks like even if you buy from somebody else.

Does anyone train a model on your data?

This is the question people mean when they ask about chatbot privacy, and the answer has two halves.

The first half is the vendor. Ours is straightforward: we do not use customer content, conversation transcripts or lead submissions to train third-party AI models. If a vendor’s answer involves the phrase “to improve our services”, ask what that covers.

The second half is whoever runs the model, because almost no chatbot company runs its own. Your customers’ questions and the relevant passages from your documents are sent to an inference provider to produce each answer. Serochat uses Groq, which has confirmed it does not train on API inputs, and our privacy page names it and says exactly what is sent. A vendor who will not tell you which model provider sees your content has not answered the question.

Who else sees the data

The honest answer for any SaaS chatbot is: more companies than the marketing page implies, and the list should be published. Ours sets out inference, payments, hosting, email delivery and the services you connect yourself, each with the data it receives and the reason it receives it.

Two of those are worth thinking about specifically. Payments mean a card processor holds your billing details, which is normal and preferable to the vendor holding them. And connected sources mean an ongoing relationship with Google, Microsoft, Notion or Zendesk on your side of the line, governed by the permission you grant.

Several of the companies involved in producing an answer are headquartered in the United States, so data reaches them there under the standard transfer terms. We would rather write that plainly than let you discover it in a schedule.

The permission question nobody asks

When you connect a document store, the scope of the permission you grant matters more than any encryption claim in the brochure.

Serochat asks Google for a permission that only ever exposes the files you individually pick in Google’s own picker. We cannot list your Drive, browse it, or read anything you did not choose, and if we wanted to we would have to ask you for a different permission and you would see the request. Compare that with a connector that asks to read your entire Drive because it is simpler to build. Both will say your data is secure; only one has limited what it can reach.

Ask every vendor which permission scope their integration requests, and what it can see that you did not select.

The questions to ask before you connect anything

  • Which model provider sees our customers’ messages, and does it train on them?
  • Is the full sub-processor list published, or available only on request?
  • What permission scope does each integration request, and what does that scope expose?
  • How long are conversation transcripts kept, and can we delete them ourselves?
  • What is encrypted at rest, and what is deliberately not?
  • Who is the controller and who is the processor for visitor data, and does the contract say so?

The last one catches people out. For the conversations on your site, you are the controller: you decide what happens with that data, and any request from a visitor comes to you. The vendor is the processor, acting on your instructions. It is a legal shape, not a technicality, and it determines whose responsibility a subject-access request is.

What we do, specifically

Passwords are stored as bcrypt hashes. Integration tokens and API keys are encrypted at rest with a key kept outside the database. Conversation message bodies are encrypted at rest, as are captured lead details: names, email addresses and phone numbers.

One deliberate exception, because a list of security claims without its exceptions is marketing: the short preview line shown beside each conversation in the inbox is stored unencrypted so that search works. We chose searchable inboxes over a claim of total encryption, and we would rather tell you which trade we made than say “all data is encrypted” and be quietly wrong.

Visitor IP addresses are stored only as a salted hash in the widget’s event log rather than in plain form. The widget itself loads no analytics of ours onto your site. On our own website, analytics only run for visitors who accept the cookie banner, and declining changes nothing about how anything works.

Delete your account and it enters a seven-day grace period, after which everything is hard-deleted from the live database and drops out of encrypted backups on the next rotation. Billing records survive for seven years because HMRC requires it. We operate under UK GDPR and the Data Protection Act 2018, and a personal-data breach affecting you gets notice within 72 hours.

What we do not claim

We are not SOC 2 certified and we do not hold ISO 27001. We do not publish an uptime guarantee. We do not describe anything as end-to-end encrypted, because it would not be true of a system that has to read messages to answer them.

If those certifications are a procurement requirement, that is a legitimate reason to buy elsewhere, and we would rather you learn it here than three weeks into an evaluation. A small UK sole trader can offer clear answers and published specifics; it cannot offer an audit it has not had.

Privacy claims are only as good as the detail behind them. Read the sub-processor list before the security badges, ask what a connector’s permission can reach, and treat any vendor who cannot answer those two questions the way you would treat a support bot that never says it does not know.