Where Chatbot Conversations Actually Go: A Data Trail You Can Audit

Ask most teams where their chatbot data goes and the answer is the vendor's name. The real path is longer, and a data protection review will want every hop named.

A customer types "where is order 4471, I used [email protected]". That single message can touch:

1. Your website, briefly, as the widget collects it.
2. The chatbot vendor, who stores the transcript.
3. A model provider, if an AI node generates the answer - often a different company in a different country from the vendor.
4. Your own systems, if the flow calls an order lookup.
5. Possibly a fifth - analytics, a CRM write, a helpdesk ticket on handover.

Each is a processor or sub-processor. Each needs a lawful basis, a location, and a retention period. "We use a chatbot tool" is not an answer to any of that.

Why this catches people late

The chatbot is usually bought by support or marketing, and the security review happens at renewal or when a customer sends a due diligence questionnaire. By then it is embedded, and the awkward answers are expensive.

The most common gap in a chatbot data map is assuming one answer covers both.

Where transcripts are stored

The vendor's database, in whatever region they operate. This is what most vendors mean when they say "EU hosted".

Where inference happens

Wherever the model provider runs. A vendor can store your transcripts in Frankfurt and send every message to a model API in the United States, and both statements on their website are true. If your policy restricts where customer text is processed, storage location alone tells you nothing.

The questions to ask

• Which model provider, by name?
• In which country does inference happen?
• Is it the same for every AI feature, or does the knowledge base use a different one?
• Can we choose, or is it fixed?

The ability to choose the provider is what turns this from a constraint into a decision. Where a platform supports several - including options with EU-hosted inference, or self-hosted models on your own hardware where nothing leaves your network - the data question is a setting rather than a reason to reject the tool. That is covered in choosing an LLM.

"Do you train on our data?" gets a no from almost everyone, and the no is not always as broad as it sounds. Ask it in three parts.

• Does the vendor use our conversations to improve their product? Including aggregate analytics, intent models, or quality review.
• Does the model provider train on API traffic? Major providers generally do not train on business API data by default, but defaults change and tiers differ. This is a term to have in writing.
• Is anything retained for abuse monitoring, and for how long? Several providers retain API inputs for a limited period for safety review even when not training on them. That is still a copy of your customer's message on someone else's infrastructure.

The third question is the one nobody asks and the one a thorough reviewer will. Get the answer before they ask rather than after.

Most chatbot privacy problems are designed in, and the fix is a flow decision rather than a legal one.

Do not ask for what you do not need

A bot that collects a full name, email and phone number to answer an opening-hours question has created a data protection obligation for no benefit. Ask at the point the data becomes necessary, not at the start as a reflex.

Keep identifiers out of the model call

If an AI node needs to answer a policy question, it does not need the customer's email in the prompt. Look up first, pass the minimum, and keep personal identifiers in your own systems where possible.

Set retention deliberately

Transcripts are useful for a few weeks for improving the bot, and a liability for years. Pick a period, configure it, and write down why. "Whatever the vendor's default is" is not a decision.

Handle what customers volunteer

People paste card numbers, health details and passwords into chat windows unprompted. Assume it will happen, redact at ingestion where you can, and make sure the transcript that reaches a human agent is not the place that data lives permanently.

Whether it is a formal DPIA or a customer questionnaire, the questions converge. Prepare answers once and reuse them.

1. What personal data does the chatbot process? Be specific: free text, email, name, IP, anything the flow collects.
2. What is the lawful basis? Usually legitimate interest for support, consent for marketing follow-up. Do not use one to cover the other.
3. Who are all the processors and sub-processors? The full list from the first section.
4. Where does each one process data? Storage and inference separately.
5. What is the retention period, and what triggers deletion?
6. How do we satisfy a subject access or erasure request? Including transcripts held by the vendor. If there is no export and delete function, that is a real gap.
7. Is the user told they are talking to an AI? Increasingly a requirement in its own right, not merely good manners.
8. What happens on a breach? Vendor notification timelines, in the contract.

Answering these takes an afternoon if the vendor is straightforward and several weeks if they are not, which is itself a useful signal during evaluation. The vendor evaluation questions cover getting these answers before you sign.

For a small team without formal governance, this is a reasonable baseline.

• Write the data map down - one page, every party, what each receives, where they are. Most of the work is finding out; keeping it current is easy.
• Choose a retention period and configure it.
• Disclose the AI in the first message. One sentence.
• Link your privacy policy from the widget, and make sure it actually mentions the chatbot.
• Collect the minimum, as late as possible.
• Know how to export and delete one person's data, and test it once so you are not learning during a live request.
• Keep the sub-processor list and check it at renewal.

None of this requires a lawyer, and having it ready turns a due diligence questionnaire from a fire drill into a copy-paste. If you are choosing a platform, the ability to pick where inference happens is the single setting that most affects how easy all of the above is to answer - the provider list sets out the options by jurisdiction, and you can test a configuration on the free plan.

Most of the work in answering a data question is finding out the answer, not writing it down. This exercise takes an afternoon and produces the document every future review will ask for.

For each party, record five things

The rows people forget

• Analytics. If conversation events go to a product analytics tool, that tool receives customer text or metadata about it.
• The helpdesk. A handover usually creates a ticket, copying the transcript into a second system with its own retention.
• Email. A confirmation or transcript email puts the content in your mail provider.
• Your own logs. Application logs capturing request bodies are a copy nobody counted.

That last one catches engineering teams routinely. A debug log retaining full request payloads for ninety days is a personal data store, and it is rarely in anyone's map.

Keep it with the flow, not in a drawer

The map goes stale when the flow changes - a new integration adds a party. Reviewing it when the flow changes is the only way it stays true, which makes it a task for whoever owns the bot rather than for legal. Who should own your chatbot covers where that sits.

The basis you rely on for answering a support question is not the basis that lets you email marketing to the address collected during it. Conflating them is the most common compliance error in chatbot flows, and it is designed in rather than accidental.

The usual split

What this means for the flow

If an email is collected to send a quote, it can be used to send the quote. Adding it to a newsletter list needs a separate, specific, unbundled agreement - a tickbox that is not pre-ticked, with the purpose stated next to it. Burying it in a link to a privacy policy does not meet the standard in any jurisdiction that takes this seriously.

Practically, that is one extra step in the conversation and it protects the whole flow. Writing it well matters: "Can we also send occasional product updates?" with yes and no buttons is clear, unbundled and easy to evidence.

Record what they agreed to

Consent you cannot evidence is consent you do not have. Store the timestamp, the wording shown, and the answer. Flows that capture the answer but not the wording fail at the first challenge, because nobody can show what the person was agreeing to.

An erasure request is where a data map stops being paperwork and becomes operational. The question is simple; satisfying it across every party is not.

Where one person's data actually lives

• Transcripts in the chatbot platform.
• Any ticket created on handover.
• CRM records written by the flow.
• Analytics events, if they carry an identifier.
• Email records of confirmations or transcripts.
• Backups, which have their own timeline.
• Model provider logs, if anything was retained for abuse monitoring.

Questions to answer before the first request

Test it once, deliberately

Run a request against a test contact before a real one arrives. Teams discover during a live request that the export contains message text without conversation IDs, or that deletion leaves the transcript visible in the helpdesk. Finding that on your own timetable is considerably better. This is also a question worth asking vendors during evaluation, when you still have leverage.

Every party you remove is a row you never have to document, a retention period you never have to set, and a deletion path you never have to test. These are flow decisions, and they are cheaper than any legal work.

The lookup-first pattern

If the bot needs to tell someone their order status, it does not need the email in the model prompt. Look the order up in your own system, pass only the status, and the model provider never sees an identifier. This costs one extra node and removes personal data from the hop you control least - a good trade in almost every flow.

Choosing where inference happens

Where a platform supports several providers, jurisdiction becomes a setting rather than a constraint on the whole project. EU-hosted options exist, and self-hosting an open-weight model means nothing leaves your network at all. Choosing an LLM covers the trade-offs, and the provider list is grouped by jurisdiction for exactly this reason.

Where to start

Draw the map, set a retention period, disclose the AI in the first message, and test one deletion. That is a defensible position without a legal department, and it turns a due diligence questionnaire from a fire drill into a copy-paste. The visual builder makes the lookup-first pattern easy to see on the canvas, and you can test a configuration on the free plan before rolling anything out.

Most chatbot data questions are ordinary processor questions with a new label. Four are genuinely new, and reviewers are starting to ask them specifically.

Is the model a processor or something else?

A model provider called by your platform on your behalf is a sub-processor. That is the straightforward case. It becomes less clear where the provider uses inputs for their own purposes, such as safety research - at which point the relationship is not purely processing, and your documentation should reflect what actually happens rather than what is convenient.

What is retained for abuse monitoring?

Several providers retain API inputs for a limited period for safety review even where they do not train on them. That is a copy of your customer's message on infrastructure you do not control, for a period you did not choose. It is rarely hidden - it is simply in documentation nobody reads.

Can the output contain someone else's data?

A model grounded only in your content should not. One answering from training data might reproduce something it learned elsewhere. This is an argument for grounding that has nothing to do with accuracy - a tightly scoped retrieval setup constrains what can appear in an answer.

Is automated decision-making involved?

A bot that answers questions is not making decisions about people. A bot that declines an application, scores a lead for routing, or determines eligibility might be, and that carries additional obligations in several jurisdictions. Where a flow does anything consequential, that is worth flagging to whoever handles compliance rather than discovering later.

The difficulty in a chatbot data map is rarely the writing. It is extracting precise answers from a vendor whose documentation is written for marketing.

Ask in a form that is hard to answer vaguely

Not "is it GDPR compliant" - everyone says yes. Ask: name the model provider, name the region inference runs in, and point me at the clause covering training rights. Specific questions produce specific answers or reveal that none exist.

Where the answers usually live

What delay tells you

A vendor who takes three weeks to say where inference happens either does not know or does not want to say. Both are answers. How they handle these questions during evaluation is a fair preview of how they will handle a security incident, and it belongs in the decision alongside the feature comparison - see vendor evaluation.

Keep the evidence

Save the written answers with dates. When a customer questionnaire arrives eighteen months later, the difference between an afternoon and a fortnight is whether someone kept the email.