Chatbot Data Privacy

How to Answer an Access, Correction, Deletion or Portability Request When the Conversation Lives in Five Systems

Quick answer: A chatbot writes one conversation into as many as five systems, and a privacy request is a demand that you find, return, fix or remove it from all of them inside a fixed window: one month under the GDPR, 45 calendar days under the CCPA. The work is not legal; it is inventory. This guide is the procedure: know which law and which clock; build the five-system inventory before the first request, using the export and delete mechanisms Manychat, Intercom and Tidio document; verify the person by the channel they used; handle each of the five rights on its own terms; write the response; log it. By our estimate, a small operator with the inventory built can answer most requests in under an hour; the runbook in step 6 is that estimate, and we have not timed it against a real request. Without it, the same request is a search across five logins against a clock that started before anyone noticed.

Step 1. Know which clock is running

Which law applies depends on where the person is and what your business is, and the three regimes our readers meet most run different clocks.

Two details from the ICO's guidance (updated 8 December 2025) settle the arguments operators have with themselves. The clock starts on receipt: "you must start from the actual date you receive the request … and count forward to the end of the same date in the following month." And "A request is not complex just because you have to rely on a processor to provide the information you need to respond," so a slow platform is not an extension ground. The clock pauses only if you need clarification "about the information requested," and even then "you cannot force a person to narrow the scope of their request." It also does not start until identity information you reasonably asked for arrives, which is why step 3 comes on day one rather than day twenty.

The CCPA point that matters for a chatbot operator is the second threshold. The revenue test excludes most of our readers; the second test counts California residents or households whose personal information you buy, sell or share, and "share" under the CCPA reaches cross-context behavioral advertising. A brand that pushes its Messenger or Instagram audience into an ad-platform integration can cross it without a $25 million turnover. Count before you assume, and ask an adviser whether what your integrations do is "sharing."

Step 2. Build the five-system inventory before the first request

A single conversation can exist in five places at once: the chat platform's transcript and contact store, the CRM record the bot wrote to, the analytics warehouse, the model provider's request logs if the bot is generative, and any export a person made to a spreadsheet. The ICO's position is that this is your problem to solve in advance: "The right of access applies whether the personal information you hold is stored in one location or in many different locations," and "there is no technology exemption from the right of access" for backups and archives.

The inventory is one table, kept somewhere the person answering requests can open it. For each row: what personal data the system holds, who can act on it, how, and what the mechanism does not reach.

Three lines in that table are the ones that produce wrong responses. Intercom keeps CSAT records after deletion, so "everything has been deleted" is false in one particular unless you say so. Manychat's deletion leaves a copy in Meta's Page Inbox, which means Meta is a recipient your access response has to name. And Tidio, which stores data on EEA servers and documents deletion cleanly, does not document a per-visitor export in its GDPR article; the operator has to assemble the record from the contact view and the chat history. None of these is a defect. They are the details that go in the inventory so that they are not discovered on day 29. Whether a record the vendor keeps after deletion is still personal data, and if so which Article 17(3) ground covers keeping it, is a question for an adviser; what this guide asks is that you know it exists and say so.

The model-provider row is different in kind. You cannot export or delete from it, and you do not need to: the provider holds a transient copy under its own retention (OpenAI's documented default is 30 days for abuse-monitoring logs; Anthropic's help center states API inputs and outputs are deleted "within 30 days" with listed exceptions). Your response names the provider as a recipient under Article 15(1)(c) and states its retention. Our BYOLLM guide covers the contractual side of that row.

Step 3. Verify by the channel, and handle the anonymous case honestly

Article 12(6) lets you ask for "additional information necessary to confirm the identity" where you have "reasonable doubts." The ICO's reading is that you should "Only request formal identification documents if necessary" and "can use verification measures that you already have in place (eg an existing username and password)." Recital 64 adds the other half: "A controller should not retain personal data for the sole purpose of being able to react to potential requests."

For a chatbot the channel is the verification:

• WhatsApp, Telegram, SMS. The conversation is tied to a number the person controls. A request from the same number is verified; a request by email about a WhatsApp conversation needs the number confirmed from the WhatsApp side.
• Messenger, Instagram. The platform identifier is tied to an account the person is logged into. Same rule.
• Website widget, identified. If the flow captured an email or the visitor logged in, verify against that.
• Website widget, anonymous. The visitor is a cookie identifier until the flow captures something (Intercom's help center says as much about its own visitor records). If a person emails you asking for "my chat from last Tuesday" and nothing links them to a record, Article 12(2) applies: you need not act where you demonstrate you are "not in a position to identify the data subject," unless the person supplies information that lets you. Say that, in writing, inside the month, and ask what would let you find them. Do not guess, and do not send the nearest transcript.

Step 4. Handle each of the five rights on its own terms

People rarely ask for one right by its article number. "Send me everything and then delete it" is an access request and an erasure request on the same clock, and the two need different work. The DSAR glossary entry sets out the eight items an access response must contain; this table is the procedure per right.

Two of those rows deserve a sentence more.

The erasure row's Article 19 duty is the reason every row of the inventory doubles as the recipients list: the same systems your access response names under Article 15(1)(c) are the ones an erasure has to reach. Deleting the contact from the chat platform and leaving the CRM row, the analytics row and the spreadsheet is what our GDPR compliance guide calls "a partial erasure described as a complete one." Both a partial erasure and a missed deadline are failures, and neither is the safe choice.

The objection row is the one most often mishandled by automation rather than by people. Every messaging platform we cover offers some form of opt-out; the question is what re-subscribes. A flow that adds a contact back to a sequence on a keyword, a re-engagement campaign that targets "inactive" contacts, or a CRM sync that overwrites the opt-out from a stale record each undo the objection without anyone deciding to. Test the objection path the way you would test a purchase path.

Step 5. Write the response

Article 12(1) asks for "a concise, transparent, intelligible and easily accessible form, using clear and plain language." Article 15(3) says that where the request came in electronically, the answer goes out "in a commonly used electronic form" unless the person asks otherwise. For an access response that means:

1. A cover note stating what you found, which systems you searched, and the date range.
2. The copy: transcripts, contact record, custom fields, and the derived labels, as files (the JSON or CSV export from the platform, plus a query result from analytics).
3. The eight items from Article 15(1), as a short list: purposes, categories, recipients (name the platform, the CRM, the analytics tool, the model provider, Meta where Messenger is involved), retention period or criteria, the other rights, the right to complain, the source of any imported data, and any automated decision with meaningful information about the logic.
4. Any redaction, explained: another customer's name in a group thread, an agent's private note if it is that agent's data too. Recital 63 limits the right where it would affect "the rights or freedoms of others," and then says "the result of those considerations should not be a refusal to provide all information."
5. Any exception, stated: "Intercom retains satisfaction-survey records after deletion," or "Meta holds a copy of Messenger conversations in our Page Inbox and in your Messenger app."
6. Where the platform holds the data outside the EU (Intercom's help center identifies app.intercom.com workspaces as US-hosted, with EU and Australian regions available; check where yours is), the transfer mechanism its data processing agreement relies on: Article 15(2) gives the person the right to be informed of the Article 46 safeguards for the transfer.

For an erasure response the same shape applies with the copy replaced by a confirmation of what was deleted, where, and what was retained on which ground.

Step 6. Log it and price it

Every request goes in an audit log: date received, channel, what was requested, identity check performed, date answered, what was done per system, what was excepted and why. Article 5(2) makes you responsible for demonstrating compliance, and a log is the demonstration. Under the UK Data Protection Act, the ICO warns, "you are committing an offence if you make any amendment to requested information with the intention of preventing its disclosure"; that is UK law, and a sensible rule everywhere.

On cost, the DSAR entry discusses the one published industry figure (a vendor's $1,524 per manual request, for a company far larger than most of our readers); the useful part is the direction, which is that the cost is the searcher's time and scales with the number of logins. The runbook below is written for an operator with three systems in the inventory (platform, CRM, analytics), a model provider named as a recipient, and no spreadsheet exports, which is the shape most 1-to-100-employee deployments have:

The one-hour figure is ours and assumes the inventory exists. Without it, the first request is the inventory-building exercise, and that is what the 29th day tends to be spent on.

What our fifteen reviews record

Eleven of our fifteen platform reviews mention GDPR; none records whether a single contact can be exported or deleted. The search strings and counts are printed in the sources of the DSAR glossary entry, along with the two questions entering our review protocol as a result. The mechanisms in step 2's table were read from help centers for this guide, not from our reviews.

Where it breaks

The request nobody recognized. It arrived in the widget, in a WhatsApp thread, or as a reply to a broadcast, and the person who saw it did not know it started a clock. The fix is the intent and the route in step 1, plus one sentence in staff onboarding.

The deletion that came back. The contact was deleted from the platform, the CRM sync ran, and the contact was recreated from the CRM record. The fix is the order of operations (CRM first, then platform, then analytics) and the diary entry in the runbook.

The response that omitted the labels. The transcript went out; the lead score and the sentiment did not, because nobody thought of them as data about the person. The analytics row in the inventory exists to stop this.

The exception nobody stated. "All your data has been deleted," when the vendor's own help center says CSAT records or Meta's inbox copy remain. The fix is the last column of the inventory table, read into every response.

FAQ

What are data subject rights?

Under the GDPR they are the rights in Articles 15 to 22: access to a copy of your data and information about its processing; rectification of inaccurate data; erasure where one of six grounds applies; restriction of processing; portability of the data you provided, in a machine-readable format; objection, unconditional for direct marketing; and protection against solely automated decisions with legal or similarly significant effects. Under the CCPA the counterparts are the rights to know, delete, correct, opt out of sale or sharing, and limit the use of sensitive information. For a chatbot operator, access, rectification, erasure, portability and objection are the five that arrive as requests, and each needs a different action across the systems the bot writes to.

How do I delete a customer's data from a chatbot?

Delete from every system the conversation reached, in an order that stops it coming back: the CRM first, then the chat platform (Manychat's Delete Contact Data, Intercom's Delete data tab in settings, Tidio's Contacts delete), then the analytics store, then any spreadsheet export. Note what each mechanism leaves behind, because the vendors document it: Intercom keeps CSAT records, Manychat's deletion does not reach Meta's Page Inbox. Then tell the person what was deleted and what was retained on which ground, inside the month.

Does GDPR apply to a chatbot conversation?

Where the conversation can be linked to an identifiable person, yes, because the transcript, the extracted fields and the inferred labels are personal data within Article 4(1). That link exists through a phone number, a messaging account, a captured email or a login, which covers most channels except anonymous website chat. The GDPR applies regardless of your company's size; the CCPA applies only above its thresholds.

Can a customer ask for their data through the chatbot itself?

Yes, and the request is received on the date it is typed. Recital 59 says the controller should provide means for requests to be made electronically. Design an intent that recognizes the request, confirms receipt with the date, and routes it to a named person, so that it does not fall to the fallback message and start a clock nobody is watching.

What does the chatbot platform have to do when I receive a request?

The platform is your processor (GDPR) or service provider (CCPA); the request is addressed to you and the deadline is yours. What the platform provides is its own export and delete mechanism, which Manychat, Intercom and Tidio document with their exceptions, and its data processing agreement, which our GDPR compliance guide covers. Relying on a processor does not extend your deadline, in the ICO's words.

Do I have to include the AI's inferred data, like a lead score, in an access response?

Where the label is tied to an identifiable person, yes. The ICO treats observed and inferred information about a person as within the right of access, and Article 15(1)(h) separately requires you to disclose any automated decision-making with meaningful information about its logic. The scoring formula may be a trade secret under Recital 63; the score assigned to the person is not.

Related guides

• Data subject access request (glossary) — the definition, the clocks and the eight items an access response must contain.
• GDPR chatbot compliance guide — the four controller documents and the AI Act duties; the inventory in step 2 is the same one Article 30 asks for.
• Chatbot security and PII handling — securing the data while you hold it, and the minimization that shrinks every request.
• Data retention policy (glossary) — the period or criteria you have to state under Article 15(1)(d).
• Audit log (glossary) — the record step 6 asks for.
• Chatbot security checklist — the pre-launch controls, including who has export access.
• BYOLLM chatbot guide — the model-provider row of the inventory, and the retention terms you can negotiate.
• Chatbot broadcast (glossary) — the direct-marketing processing an objection stops.
• Chatbot memory guide — long-term memory is another store a deletion has to reach.

Sources

• Regulation (EU) 2016/679 (GDPR), read 6 September 2026 at gdpr-info.eu: Article 4(1) (definition of personal data); Article 5(2) (accountability); Article 11(2) and 12(2) (a controller "not in a position to identify the data subject"); Article 12(1) ("concise, transparent, intelligible and easily accessible form, using clear and plain language"); Article 12(3) (one month, "two further months," reasons within the first month); Article 12(5) (free of charge; "manifestly unfounded or excessive"); Article 12(6) ("reasonable doubts concerning the identity"); Article 15(1)(a) to (h) and 15(3) (the eight items; "commonly used electronic form"); Article 16 ("inaccurate personal data"; "supplementary statement"); Article 17(1)(a) to (f) and 17(3)(e) ("the establishment, exercise or defence of legal claims"); Article 19 ("communicate any rectification or erasure … to each recipient … unless this proves impossible or involves disproportionate effort"); Article 20(1) ("structured, commonly used and machine-readable format"; the consent-or-contract and automated-means conditions); Article 21(2) and (3) (direct marketing; "shall no longer be processed for such purposes"); Recital 59 ("means for requests to be made electronically"); Recital 63 ("rights or freedoms of others"; "should not be a refusal to provide all information"); Recital 64 ("should not retain personal data for the sole purpose of being able to react to potential requests"). gdpr-info.eu
• UK Information Commissioner's Office, Right of access guidance, pages "What should we consider when responding to a request?" and "How do we find and retrieve the relevant information?", each marked "08 December 2025 - the right of access guidance was updated," read 6 September 2026: the calendar-month calculation, the 28-day suggestion, the three-months-from-start extension, the "not complex just because you have to rely on a processor" sentence, the stop-the-clock limit, the "cannot force a person to narrow the scope" sentence, the "Only request formal identification documents if necessary" and "existing username and password" sentences, the "one location or in many different locations" and "no technology exemption" sentences, the "insights about a person's behaviour" passage, and the "committing an offence if you make any amendment to requested information with the intention of preventing its disclosure" warning. ico.org.uk
• California Attorney General, California Consumer Privacy Act (CCPA), "Updated on August 28, 2026," read 6 September 2026: the 45-day and 90-day wording, the twice-a-year rule, the three applicability thresholds, the definition of "share" as cross-context behavioral advertising, the names of the rights, and the service-provider sentence. The statute (Cal. Civ. Code §1798.130) was not read; the AG's wording is quoted. oag.ca.gov/privacy/ccpa
• Manychat Help, Managing User Data / GDPR Compliance, article 14281070595100, "Updated September 01, 2026," read 6 September 2026: the contact-menu options ("Unsubscribe from bot, Unsubscribe from Email, Download Contact Data, and Delete Contact Data"), the ".json file containing all their information" sentence, the deletion scope, "You can't undo this action," the "Unknown with the 'deleted' status" sentence, "This action won't affect your bot stats," and the Page Inbox caveat. help.manychat.com
• Intercom Help, How to export your Intercom data for GDPR (article 1636975, 24 January 2025) and Contacts FAQs (article 8827723, "Updated over 2 weeks ago" on the read date), read 6 September 2026: the per-user CSV/JSON export; the "Delete data" tab and its "Settings > Data > People > Delete Data" route; "contact us within 7 days" and "permanently destroyed"; "CSAT ratings and comments from a user will not be deleted"; the reporting note; the exported-files note; the "intercom-id or intercom-session cookie" sentence; and the same article's "Regional Workspaces" section ("app.intercom.com for US customers," "app.eu.intercom.com for EU customers," "app.au.intercom.com for Australian customers"). intercom.com/help
• Tidio Help Center, Privacy Policy and GDPR Compliance, article 5462910440220, "July 18, 2025 Updated," read 6 September 2026: the Contacts delete path and scope; "All our data is stored on servers located in EEA member counties" (sic); the GDPR article's cookie FAQ stating that most widget data is kept in the visitor's browser localStorage. The absence of a per-visitor export in the GDPR article is our observation. help.tidio.com
• OpenAI, Data controls in the OpenAI platform, read 6 September 2026: "abuse monitoring logs are generated for all API feature usage and retained for up to 30 days, unless longer retention is required by law"; such logs "may contain certain customer content, such as prompts and responses"; Zero Data Retention. platform.openai.com
• Anthropic Privacy Center, How long do you store my organization's data?, dated 1 July 2026, read 6 September 2026: "For Anthropic API users, we automatically delete inputs and outputs on our backend within 30 days of receipt or generation," with the listed exceptions. privacy.anthropic.com
• DataGrail, The $1.5M DSR Problem, Ian Phippen, 9 June 2026: the $1,524 figure referred to in step 6, quoted and sourced in full in the DSAR glossary entry. Vendor research. datagrail.io
• Chatbotscape review corpus (the fifteen platform reviews at /reviews), searched 6 September 2026; the search strings and counts are printed in the sources of /glossary/data-subject-access-request.
• Ahrefs Keywords Explorer, US overview, queried 6 September 2026: the figures in this guide's keyword note.
• Chatbotscape evaluation methodology. /methodology (continuously updated).

About this guide

Chatbotscape launched in 2026 as an independent review site for chatbot platforms. This guide is part of our SMB chatbot Academy and is written for the owner or support lead of a small business that has to answer a customer's request about chatbot data. It reads three vendors' help centers as worked examples of the export and delete mechanisms an operator relies on; it does not rank them, and the affiliate relationship with the reviews it links is disclosed above.

Methodology

The regulation articles, the two ICO pages, the California AG page and the vendor help articles were read in full on 6 September 2026, and every quotation carries its source. The corpus counts are our own and the commands are printed in the glossary sibling. The editorial judgments on this page: treating the five-system inventory as the unit of work, which follows the ICO's "many different locations" reading rather than any vendor's; the deletion order (CRM, platform, analytics, exports), which is our operational inference from sync behavior rather than a regulator's instruction; and the one-hour runbook, which is an estimate for an operator with the inventory built and has not been timed against a real request. See our methodology for how platform facts are verified.

Last updated

7 September 2026.