Short answer: It depends on the vendor, and there are specific questions that separate serious ones from the rest — is your data used to train AI models, who can read transcripts, how long are they kept, and what independent certifications exist. Clerkzo does not use your data to train AI models, and is SOC 2 Type II examined, GDPR compliant and HIPAA assessed. What matters is that you know how to verify claims like that rather than take them on faith.
What data does a chat widget actually handle?
Three categories, with different risk profiles.
Your business content. Pages crawled from your site and files you upload. Usually already public, and the low-risk category — though uploaded internal documents deserve more care than a crawled homepage.
Conversation content. What visitors type. This is where personal data appears, often unprompted: names, phone numbers, email addresses, and sometimes far more than you asked for. People volunteer things to chat interfaces.
Operational metadata. Timestamps, page context, session identifiers. Individually dull, collectively identifying.
Most privacy risk sits in the second category, and most of it arrives without you asking for it.
Where does a message actually go?
It helps to picture the journey, because "is it safe" is really several separate questions about several separate hops.
A visitor types into the widget on your page. That message travels to the vendor's servers. The vendor looks up relevant passages from your crawled content, sends the question and those passages to a language model provider, gets an answer back, returns it to the browser, and stores the exchange so you can read it later. If the conversation produced a lead, a copy of the details is also pushed wherever you told it to go: an email inbox, a webhook, a messaging app.
Every one of those hops is a place to ask a question. Is the connection encrypted in transit, which for anything reputable means HTTPS end to end. Is the stored copy encrypted at rest. Who is the model provider, and what are their terms for data sent through the API. Where does the lead copy land, and who has access to that inbox.
That last hop is the one people forget, and it is frequently the weakest. A transcript sitting in a shared reception mailbox that six people log into with the same password is a bigger practical exposure than anything happening at the vendor.
The questions that actually separate vendors
Ask these directly and insist on specific answers.
Is my data used to train AI models? This is the question people care about most and the one with the most weasel-worded answers. The distinction to press on: a model provider processing a request is not the same as training on your content. Clerkzo does not use your data to train AI models. Get the equivalent statement in writing from anyone you evaluate.
Who can read my conversations? Vendor staff access should be limited, logged and justified by support need. "Anyone in engineering can query the database" is a real answer some vendors would have to give if pressed.
How long is data retained, and can I delete it? You need a stated retention period and a working deletion path — for a single conversation and for your whole account.
Where is data processed and stored? Relevant for GDPR and for anyone with regional obligations.
Who are your sub-processors? Every AI chat vendor uses at least a model provider, and usually a hosting provider, an email sender and an analytics tool. You are entitled to the list, and the list is more informative than any badge, because it tells you exactly whose hands your transcripts pass through.
What independent certification do you hold? A SOC 2 Type II report means an auditor tested controls over a period, not just that a policy document exists. Self-certified security is a marketing claim.
What happens on offboarding? What is deleted, when, and how you get an export first.
Compliance labels and what they mean
GDPR is a legal obligation, not a certification. A vendor claiming compliance should be able to supply a data processing agreement, name their sub-processors, and describe how they handle deletion and access requests. Under GDPR you are typically the controller and the vendor is a processor, which means the accountability for what gets collected is yours.
SOC 2 Type II is an audit of security controls operating over time, conducted by an independent firm. Type I is a point-in-time snapshot and is meaningfully weaker.
HIPAA applies to protected health information in the US and requires a business associate agreement. If you are a healthcare provider, that agreement is the point — the compliance badge alone is not.
The most effective control is collecting less
Every field you ask for is data you must protect. A widget scoped to answer questions and capture a name plus one contact method carries a fraction of the risk of one collecting dates of birth and medical details in free text.
Two configuration habits do most of the work. Do not ask for sensitive information in chat — route anything sensitive to a secure form or a phone call. And scope the widget tightly so it does not invite disclosure it does not need; the guardrails that keep it on your business also keep it from wandering into territory where visitors overshare.
Visitors will still volunteer things. That is a retention and access question, not a collection one, which is why the retention answer matters.
What does data minimisation look like in practice?
Concretely, for a widget you are setting up this afternoon:
- Audit your capture fields one by one. For each, answer "what do I do differently because I have this?" Anything without an answer comes out. Most businesses need a name, one contact method, and a sentence about what the person wants.
- Do not ask for a date of birth, an ID number or a policy number in chat. If the follow-up genuinely needs it, take it on the phone or in a secure form after you have verified who you are talking to.
- Keep free-text prompts narrow. "Briefly, what do you need help with?" invites a sentence. "Tell us about your situation" invites a medical history.
- Say what you do not handle. A widget that states plainly it cannot discuss individual accounts or clinical details gets told fewer of them.
- Check your notification route. If leads arrive by email, that email inbox now holds personal data indefinitely. Decide who can access it and how long you keep it.
The general principle is old and boring and works: the safest record is the one you never created.
What if a visitor overshares anyway?
They will. Someone will paste their full medical history at 11pm because the box was there.
Visitor: I need an appointment. I have been on [medication] since my diagnosis in March and my last consultant said... Widget: Thanks, I have enough to pass this on. Can I take your name and the best number to reach you? The team will call and take the details properly.
That is the behaviour you want: acknowledge, stop soliciting, capture the minimum, move it to a human channel. The widget should not follow up with "tell me more about your diagnosis", because every extra sentence is data you now hold.
Then handle the record. Know how to delete a single conversation in your dashboard, and do it when a transcript contains something it should not. A deletion path you have never tested is not a deletion path.
The security failure modes worth knowing
Injection into the widget. A visitor typing instructions to override its rules is trying to extract or manipulate. The structural defence is that the widget only has access to your published content and the current conversation, so there is little to extract. Read up on prompt injection if you are evaluating this seriously, and there is a practical guide in how to protect a chatbot from prompt injection.
Leakage through knowledge files. Uploading an internal document that contains customer names or staff details makes that content retrievable by anyone who asks the right question. Audit uploads as text before they go in.
The host page. A widget injecting scripts into your site is a supply-chain risk to your own visitors. Clerkzo runs inside a Shadow DOM, isolating the widget from your page and your page from the widget.
Downstream systems. Transcripts flowing into a CRM or a webhook inherit whatever protection that system has. The chain is only as strong as its weakest link, and it is usually not the chatbot.
Your own access habits. A dashboard holding every conversation is a valuable account. Use a strong, unique password and treat the login the way you treat your banking.
What should you tell your visitors?
Be plain about it. Say that the chat is powered by AI, that conversations are recorded, and link to your privacy policy from the widget. Most jurisdictions expect some form of disclosure and all customers appreciate it.
A single line in the greeting does most of the work. Something like: this chat is answered by an AI assistant and conversations are saved so our team can follow up. It costs you nothing, it sets expectations honestly, and it makes the later handoff to a human feel like a feature rather than a reveal.
Hiding the fact that a visitor is talking to software is a bad trade. It buys nothing and costs trust the moment it becomes obvious — which it usually does. The setup and what gets stored is documented on how it works, and pricing is flat, which means security posture is not gated behind an enterprise tier.
A short checklist before you go live
- Read your own capture fields and delete any you cannot justify.
- Confirm in writing whether the vendor trains on your data.
- Get the sub-processor list and the retention period.
- Test deleting one conversation, and confirm it is gone.
- Add an AI disclosure line and a privacy policy link to the widget.
- Decide who can open the dashboard and the lead inbox.
None of that takes more than an hour.
Frequently asked questions
Will my business data be used to train AI models?
Not with Clerkzo. Ask any vendor for that statement explicitly, and distinguish between processing a request and training on your content.
Do I need to tell visitors they are chatting with AI?
Disclose it. It is expected in many jurisdictions, it is straightforward, and concealment damages trust when discovered.
Is chat safe for health-related enquiries?
Only with a business associate agreement in place and the widget scoped so it does not solicit clinical detail. Route anything specific to a secure channel.
Who is responsible if a visitor types something sensitive?
Under GDPR you are usually the controller, so accountability sits with you. Configure the widget to collect the minimum and check the vendor's retention and deletion terms.
What should I ask about the model provider specifically?
Whether the vendor sends your content to a third-party model API, which one, and what that provider's terms say about retention and training. A vendor who cannot answer that quickly has not thought about it carefully enough.