A student emails the service desk: "What information does your chatbot have about me? Please delete it." The one-month clock started when that email arrived, and it does not pause while you work out where chatbot data actually lives.
A few terms first, because the rest of this depends on them. GDPR is the General Data Protection Regulation, the EU law governing personal data. A DSAR, or data subject access request, is a person exercising their rights over their own data, most often the Article 15 right to a copy or the Article 17 right to erasure. A controller decides why and how personal data is processed, which is your organization; a processor acts on the controller's instructions, which is the chatbot vendor.
One more. A DPA, or Data Processing Agreement, is the Article 28 contract between controller and processor. It is where the processor's duty to assist you with these requests is written down. If those obligations are new territory, start with what GDPR requires of a chatbot deployment and come back; this page is the operational half.
iShort answer
The request lands with you, the controller, and GDPR Article 12 gives you one month, extendable by two further months for complex or numerous requests if you say so within the first month. A person's chatbot data can live in four places: conversation transcripts, captured leads, trained content, and analytics. On SiteGPT you are the controller of all four; conversations export as CSV from Chat History, leads export and bulk-delete from the Leads page, and everything is kept until you delete it, so your retention schedule is a routine you run, not a default you inherit. Erasure does not automatically reach lead copies already forwarded to your CRM or inbox, and an anonymous transcript you cannot link to the requester may fall outside the request entirely under Article 11.
Four stores, checked in this order. An access or erasure response is complete when all four have been considered, plus any downstream copies your integrations made.
Conversation transcripts
Personal data if the person is identifiable. Exportable as CSV from Chat History (current filtered view). Deletable: the security docs state conversations are deletable by you, and API v2 documents delete-conversation.
Captured leads
Always personal data: name, email, phone, custom fields. Exportable as CSV; deletable one by one or in bulk. Kept until you delete them, and copies may already sit in your CRM, Slack, or inbox via notifications and webhooks.
Trained content
Usually your own site and docs, not the requester's data. Only in scope if you trained the bot on content containing their personal data; then the fix is deleting or editing that document in the knowledge base.
Analytics
Aggregated counts, funnels, and AI-classified topics derived from conversations. Not a per-person record, so there is nothing to export for one individual; the lever is deleting the underlying conversation.
Who owes the answer
You do. For everything the chatbot ingests and collects, the organization running the widget is the controller and the vendor is a processor acting on documented instructions. SiteGPT's privacy policy states the split plainly: for trained content, end-user conversations, and captured leads, "SiteGPT acts as a Data Processor on your behalf: you are the controller of that data."
That settles two things at once. The person is owed a response from you, not from the vendor, so forwarding the email to support and considering it handled is not a response. And the vendor's role is assistance: the DPA lists data subject rights procedures among its contents, which is the contractual hook if you need help completing a request. A fuller walkthrough of that contract is in the Article 28 checklist for a chatbot DPA.
The four places a person's chatbot data can live
Answer the request store by store, because each behaves differently.
| Store | Personal data? | Export | Erasure |
|---|---|---|---|
| Conversation transcripts | Yes, when the person is identifiable | CSV from Chat History, filtered view | Deletable; API v2 documents delete-conversation |
| Captured leads | Yes, by design | CSV from the Leads page | Delete individually or in bulk; persists until you do |
| Trained content | Only if you put it there | It is your own content | Delete or edit the source document |
| Analytics | Aggregated, not per-person | No individual record to export | Follows from deleting the underlying conversation |
Transcripts are the obvious store. On SiteGPT the Chat History page lists every conversation and filters by date, feedback, status, model, and tags, and the download button exports the current view as CSV.
Leads are the store people forget, and the most sensitive one: names, emails, phone numbers, and whatever custom fields you configured. Trained content is usually your own website and help docs rather than anyone's personal data, but if you trained on exported tickets or a staff directory, it is in scope. Analytics are aggregates and AI-classified topics derived from conversations; there is no per-person analytics record to hand over.
Handling an access request, what to export and what to redact
Article 15 entitles the person to a copy of their personal data plus context: purposes, categories, recipients, retention, and their other rights. Most of the context can be written once and reused; the copy is the per-request work.
- Verify identity first. SiteGPT's own privacy policy describes verifying identity before acting on a request, and you should do the same before releasing transcripts to a stranger.
- Find the conversations. The reliable route is through the lead record, which links contact details to the conversation transcript. For requests that arrive with only a name and a date range, filter Chat History by date and work through candidates.
- Export. Filter the view to the person's conversations and use the CSV download. Export their lead record the same way.
- Redact before sending. Article 15(4) says the copy must not adversely affect the rights of others. Strip other people's personal data: a colleague's name in a transcript, another customer mentioned by the agent who replied.
If the person chatted anonymously and left nothing that links them to a transcript, Article 11 applies: a controller that can demonstrate it cannot identify the data subject is not obliged to collect extra information just to satisfy the request, and Articles 15 to 20 do not apply to data that cannot be attributed. Say so in your response and document the reasoning. Guessing which anonymous transcript is theirs, and sending it, is how an access request becomes a data breach.
Handling an erasure request, and what erasure does not reach
Article 17 gives the person the right to erasure when the data is no longer necessary, when they object and no overriding grounds exist, or when the processing was unlawful. For chatbot transcripts of a resolved service conversation, there is rarely a strong ground to refuse.
The deletion itself is the short part. SiteGPT's security documentation states that conversations and leads "are exportable and deletable by you", the Leads page supports deleting several leads at once, and the Agent API v2 documents delete-conversation and delete-lead endpoints for doing it programmatically. Deleting the whole chatbot or account triggers the deletion cascade described in the privacy policy.
What erasure does not automatically reach is the honest half of the answer:
- Downstream copies you made. Lead notifications already emailed to your team, webhook payloads in your CRM, tickets created in your helpdesk. Those are yours to chase, and your response should say you did.
- The other stores. Deleting the transcript does not delete the lead record, and the reverse is also true. Check both.
- Aggregated analytics. Counts and topic clusters are not a record about the person; they are not "their data" to erase once truly aggregated.
- Data you must keep. Article 17(3) preserves retention needed for legal claims or legal obligations. If you keep a lead because of an active dispute, say so with the ground named, rather than silently declining.
Article 28(3)(e)
The processor's duty to assist the controller with data subject requests is not a favor, it is a required term of the DPA. SiteGPT's DPA lists data subject rights procedures among its contents, and DPAs are executed for Enterprise customers during onboarding, with baseline processing terms for all plans in the Terms and Conditions.
Source: SiteGPT DPA pageLeads are not conversations, and why that changes your answer
A transcript and a lead look like one interaction to the visitor, but they are two records with two lifecycles, and requests fail on the difference.
Leads persist until the customer deletes them. There is no automatic expiry, which is exactly what you want for sales follow-up and exactly what trips up an erasure response written as "we deleted your chat." Leads also travel: SiteGPT can email each lead to your team as it arrives and send it by webhook to your CRM, so the record you delete in the dashboard has often already been copied somewhere you administer.
So split every request in two. For access: export the transcript and the lead record. For erasure: delete the conversation, delete the lead, then delete the copies your notifications and integrations created. The response template below has a line for each.
Retention to configure before the first request arrives
GDPR does not hand you a number. Article 5(1)(e), the storage limitation principle, says personal data is kept no longer than necessary for the purpose, and makes you the one who decides what that means and defends it.
On a standard SiteGPT workspace, conversations and leads are kept until you delete them. There is no auto-delete timer to set and forget, so a defensible retention posture is a routine, and it is worth building before the first request rather than after:
| Scenario | Best pick | Why |
|---|---|---|
| Pick a retention period you can defend | Decide once | Common practice for service transcripts is months, not years. Write the period and its reasoning into your privacy notice and your records of processing. |
| Put a recurring deletion pass on the calendar | Monthly or quarterly | Filter Chat History by date, export anything you must keep, delete the rest. Bulk actions on the Leads page handle lead cleanup in the same pass. |
| Automate it if you have engineering time | API v2 or the CLI | The Agent API v2 documents list, get, and delete endpoints for conversations and leads, so a scheduled script can enforce the period without anyone remembering to. |
| List your downstream destinations | Before the first request | CRM, helpdesk, Slack, notification inboxes. Erasure responses have to cover the copies your own integrations made, and the list is much easier to write calmly in advance. |
| Keep training content free of personal data | At every content addition | Nothing scans it for you. Content the bot retrieves from is reachable, indirectly, by anyone who can chat with the bot, and it is the one store a deletion routine will not touch. |
One distinction to keep straight: HIPAA-covered SiteGPT workspaces get automatic redaction of conversation content on the schedule in the Business Associate Agreement, 7 days after last activity by default. That is a contract behavior for US healthcare deployments, not a GDPR feature, and it does not exist on a standard workspace. Do not cite it in a GDPR retention policy.
EU universities juggling both student DSARs and admissions season have a dedicated walkthrough in the data protection checklist for EU university chatbots.
The clock, one month, and when you can extend it
Article 12(3) sets the deadline: information on action taken "without undue delay and in any event within one month of receipt of the request."
The same article allows an extension of up to two further months where requests are complex or numerous, with a condition attached: you must inform the person of the extension, and the reasons for it, within the first month. An extension you did not announce inside month one is not an extension, it is a missed deadline.
Three practical notes. The clock starts at receipt, wherever the request lands, including a chat message typed into the widget itself. Requests are free of charge unless manifestly unfounded or excessive, per Article 12(5). And if you refuse, Article 12(4) requires telling the person why, within the month, along with their right to complain to a supervisory authority.
A response template you can adapt
Subject: Your data request, reference [REF] Dear [NAME], Thank you for your request received on [DATE]. We have verified your identity and completed our review of the data our website chatbot holds about you. WHAT WE FOUND - Conversation transcripts: [N] conversation(s) between [DATE RANGE], attached as CSV. - Contact (lead) record: [attached / none found]. - Content used to train the chatbot: contains no personal data relating to you [or: contained X, which we have removed]. - Analytics: our chatbot analytics are aggregated statistics and contain no record about you individually. [FOR ACCESS REQUESTS] The attached export is your copy under Article 15 GDPR. We have redacted personal data relating to other individuals, as Article 15(4) requires. Our privacy notice at [URL] describes the purposes, recipients, retention periods, and your other rights. [FOR ERASURE REQUESTS] We have deleted the conversation transcripts and your contact record from our chatbot platform, and removed the copies our internal notifications and integrations created in [CRM / helpdesk / other]. [If anything is retained: We have retained X because Y, under Article 17(3) GDPR.] If you have questions, or wish to complain, you may contact us at [PRIVACY EMAIL] or lodge a complaint with your supervisory authority. [NAME, ROLE]
Fill the brackets from the four-store check above. The template deliberately reports trained content and analytics even when the answer is "nothing there", because a response that accounts for every store reads as diligence, and a response that mentions only the transcript invites a follow-up question you could have preempted.
Frequently asked questions
Who responds to a DSAR about a chatbot conversation, the company or the chatbot vendor? The company. For end-user conversations, captured leads, and trained content, the organization running the chatbot is the controller and the vendor is a processor acting on its instructions. SiteGPT's privacy policy states this split explicitly: for the data your chatbots ingest and collect, SiteGPT acts as a processor on your behalf and you are the controller. The one-month deadline under Article 12 runs against you. The processor's job, set by the DPA, is to assist you, not to answer the person directly.
How long do you have to respond to a data subject request? One month from receipt, under GDPR Article 12(3). That can be extended by up to two further months where requests are complex or numerous, but you must tell the person about the extension, with reasons, within the first month. The clock runs whether or not you know where the data is, which is why the export and deletion route is worth rehearsing before the first request arrives.
Can you delete a single chatbot conversation in SiteGPT? Yes. SiteGPT's security documentation states that conversations and leads are exportable and deletable by you, and the Agent API v2 documents a delete-conversation endpoint alongside delete-lead. Conversations can also be exported from the Chat History page as CSV using the download button on the current filtered view. Deleting the chatbot or the account removes its data through the deletion cascade described in the privacy policy.
What if the person chatted anonymously? If they never identified themselves in the conversation and left no contact details, you may be unable to link any transcript to the requester. GDPR Article 11 covers this: where the controller can demonstrate it is not in a position to identify the data subject, Articles 15 to 20 do not apply, and the controller is not obliged to collect additional information just to identify them. Tell the requester that, and document the reasoning. Do not guess which anonymous transcript might be theirs.
Does deleting a conversation also delete the captured lead? Treat them as separate records. A lead is a distinct object with its own contact fields, and SiteGPT keeps leads until the customer deletes them; there is no automatic expiry. An erasure response that removes the transcript but leaves the lead record, or a copy of the lead already forwarded to a CRM by webhook or email notification, has not finished the job. Check conversations, leads, and every downstream tool the lead was routed to.
Does GDPR set a retention period for chatbot transcripts? No. Article 5(1)(e), the storage limitation principle, requires that personal data be kept no longer than necessary for the purpose, and leaves the number to the controller. You choose a period you can defend, write it into your privacy notice and records, and enforce it. On SiteGPT, conversations and leads are kept until you delete them, so enforcing your period is an operational routine you run rather than a toggle you set once.
Does SiteGPT delete conversation data automatically after a set period? Not on a standard workspace. The privacy policy states that chatbot content, conversations, and leads are kept until you delete them or delete the chatbot or account. The automatic redaction that HIPAA-covered workspaces get, where conversation content is redacted on the schedule in the Business Associate Agreement, is a contract behavior specific to those deployments, not a GDPR retention mechanism. For GDPR, the retention schedule is yours to run.
Sources
- GDPR Article 12 for the one-month deadline, the two-month extension, and refusal duties, read 14 August 2026
- GDPR Article 15 for the right of access and the rights-of-others limit in 15(4)
- GDPR Article 17 for the right to erasure and its Article 17(3) exceptions
- GDPR Article 11 for processing which does not require identification
- EDPB guidelines on the right of access for how regulators read Article 15 in practice
- SiteGPT privacy policy for the controller and processor split, retention until deletion, the deletion cascade, and the identity verification and response deadline language, verified 14 August 2026
- SiteGPT security page for "Export or delete your data anytime", verified 14 August 2026
- SiteGPT security and compliance docs for "conversations and leads ... are exportable and deletable by you" and the processor statement, verified 14 August 2026
- SiteGPT chat history docs for the filters and the CSV export of the current view, verified 14 August 2026
- SiteGPT leads docs for bulk star, archive, and delete, CSV download, and lead notifications, verified 14 August 2026
- SiteGPT DPA page for data subject rights procedures and Enterprise execution, verified 14 August 2026
Last updated: August 2026. All SiteGPT pages and docs cited were read directly on 14 August 2026.