Right of access to chat data under the GDPR

A request for access rarely arrives as a form. It arrives as a sentence in a chat window: what exactly have you stored about me? From that sentence onwards a deadline is running, and it runs even if the sentence was typed on a Saturday evening into a dialogue window that nobody in the company regards as an inbox. Article 15 GDPR gives every data subject the right to learn whether data about them is being processed, what that data is, where it came from and who received it. For an AI assistant this is an uncomfortable question, because a conversation is not a single record: messages, session data, tool calls and derived attributes sit in different places and often in different systems. This article shows what a visitor may ask for, what belongs in the copy, how a request without a customer account is handled, how identity can be checked without collecting fresh data for the purpose, and what is redacted before handover.

Enlarge graphic

Labels in the illustration

• 1
• Receipt
• no form, no reason needed
• clock starts on arrival
• 2
• Identity
• only on real doubt
• no extra data collection
• 3
• Collect
• check every store
• not just the chat window
• 4
• Review
• respect rights of others
• redact, do not delete
• 5
• Handover
• commonly used format
• prepared to be readable
• What the copy contains (Article 15(3))
• Messages with timestamps
• Contact details from the chat
• Tool calls and their results
• Session and connection data
• Attachments and ratings
• Derived attributes
• Deadline under Article 12(3)
• Standard case: one month from receipt
• Extension: two more months
• Receipt
• one month
• three months
• Notice of the extension: within one month of receiving the request
• Doubts about identity: additional details only where necessary (Article 12(6))
• Rights of others limit the copy, they do not remove the right of access (Article 15(4))

Access request about a chat transcript

What Article 15 actually requires

The right of access consists of three layers that in practice tend to shrink into one. The first layer is confirmation: are you processing data about this person, yes or no? A no is an answer too, and it has to be given within the deadline. The second layer is access to the data itself and to eight items of information that the text of the Regulation lists individually. The third layer is the copy. Anyone who merely sends a file of messages has skipped the second layer, and that is where most answers fail, not for want of goodwill.

• The purposes of the processing (point a) - for an assistant, for instance answering the enquiry, handling a case and reviewing answer quality
• The categories of personal data concerned (point b)
• The recipients or categories of recipient to whom the data have been or will be disclosed (point c)
• Where possible, the envisaged storage period, otherwise the criteria used to determine it (point d)
• The existence of the right to rectification, erasure or restriction of processing and of the right to object (point e)
• The right to lodge a complaint with a supervisory authority (point f)
• Where the data were not collected from the data subject, any available information as to their source (point g)
• The existence of automated decision-making including profiling, and meaningful information about the logic involved as well as the significance and the envisaged consequences (point h)

The one-month deadline and what extends it

The deadline is the part that most often breaks, and it breaks at the start, not at the end. It begins when the request is received, not on the day somebody reads it, forwards it or recognises it as a request for access. A sentence in a chat window, a message to the general contact address, a remark in a feedback form: each of those is receipt. If the channel is not monitored, the first weeks are lost without anyone noticing.

Extension is possible, but it is not a licence to work on quietly. The period may be extended by two further months where necessary, taking into account the complexity and number of the requests; the controller informs the data subject of that within one month of receipt, together with the reasons for the delay (Art. 12(3) GDPR). Anyone who does not act at all must likewise say so within one month, including a reference to the right to lodge a complaint with a supervisory authority and to a judicial remedy (Art. 12(4) GDPR). And access is free of charge: a fee or a refusal only comes into play for manifestly unfounded or excessive requests, and the controller bears the burden of demonstrating that character (Art. 12(5) GDPR).

The copy of a chat transcript

The copy is where it shows whether a company knows its own data. Technically, a conversation with an assistant is not a document but a set of entries across several stores. Anyone who pulls the copy from the message table delivers the part that was on screen anyway and leaves out precisely what the data subject could not see: the connection data, the tool calls, the derived attributes and the case that grew out of the conversation.

What copy means was interpreted by the Court of Justice of the European Union in its judgment of 4 May 2023 in Case C-487/21: what is required is a faithful and intelligible reproduction of the personal data, and where necessary to make the context intelligible this may include reproducing extracts from documents or whole documents. For a chat transcript this means: an excerpt without the assistant question it belongs to is not intelligible, and a table of identifiers without the field names resolved is no better. The copy may be technical, but it has to stay readable. On the storage period to be stated under point (d), a properly reasoned set of stages helps, as described in the article on retention periods for chat logs.

• The message transcript with timestamps, including the assistant replies
• Contact details and other information handed over during the conversation
• The session identifier and the technical connection data stored alongside it
• Tool calls and their results, insofar as they concern the data subject
• Attachments, uploaded images and the information derived from them
• Ratings, thumbs and free-text feedback on individual answers
• Derived attributes such as detected language, assigned intent or a classification of the conversation
• The case that grew out of the conversation, including internal notes about this person

Naming the origin and the recipients

Two of the eight items are regularly overlooked because they do not appear in the chat window. The first is the origin: where the data were not collected from the data subject, any available information as to their source must be provided (Art. 15(1)(g) GDPR). For an assistant this is no side issue, because part of the conversation record is not created by typing at all: the order status comes from the ERP system connected in the Custom package, the name from the customer account, the device category from the window width. Every one of those sources is an origin and needs to be named.

The second overlooked item is the recipients. What must be provided are the recipients or categories of recipient to whom the data have been or will be disclosed (Art. 15(1)(c) GDPR). In its judgment of 12 January 2023 in Case C-154/21 the Court of Justice of the European Union held that the data subject must in principle be told the identity of the actual recipients; only where those are not yet known, or the request is excessive, do categories suffice. For an assistant this means: a service provider processing on your behalf is a recipient too, and so are the ticket system, the data centre and every place the transcript is passed on to. Whoever has mapped that chain properly in their contracts can also name it in the answer; the article on data processing agreements shows how that list comes about.

The request without an account

The most common case in chat is also the least clear-cut: somebody asked anonymously, left nothing behind and gets in touch two weeks later by email. There is a dedicated provision for this situation. If the purposes for which a controller processes personal data do not or do no longer require identification of the data subject, the controller is not obliged to maintain, acquire or process additional information in order to identify the data subject for the sole purpose of complying with the Regulation (Art. 11(1) GDPR). Where the controller can demonstrate that it is not in a position to identify the data subject, it informs the data subject accordingly if possible, and Articles 15 to 20 do not apply - unless the data subject provides additional information enabling identification (Art. 11(2) GDPR).

Two misunderstandings attach to this provision. The first: it is not an invitation to store more as a precaution. Creating an identifier specifically so that access can be granted later means processing more data, not less - that inverts the idea. The second: it is not a convenient excuse. Being unable to identify means genuinely unable, not unwilling. If a conversation can be matched unambiguously via the order number mentioned in the transcript, identifiability is not lacking. The clean answer is then: we found your conversation using that detail, here is the copy. How much an assistant retains about a visitor at all is covered in the article on conversation memory.

• The conversation identifier shown in the window or contained in a transcript that was sent
• A detail named in the conversation such as an order, customer or case number
• The email address a transcript or a reply from the conversation was sent to
• The time frame of the conversation together with content only the person involved can know
• A case created later that refers back to the conversation, such as a quote or a ticket
• The sign-in to the customer account, where the conversation was held from the signed-in area

Verifying identity without collecting new data

Identity verification is the point where well-meant caution tips over into a breach of its own. The rule is narrow: where the controller has reasonable doubts concerning the identity of the natural person making the request, it may request the provision of additional information necessary to confirm the identity of the data subject (Art. 12(6) GDPR). Three words carry that rule. Reasonable doubts means there has to be a trigger in the specific case, not a general unease. Necessary means the mildest suitable check is enough. And additional information does not automatically mean a copy of an ID document - such a copy contains far more than is needed for confirmation and creates a new store of data that you then have to protect and delete.

What is redacted and what is not

The right of access ends where the rights of others begin: the right to obtain a copy shall not adversely affect the rights and freedoms of others (Art. 15(4) GDPR). Recital 63 names trade secrets, intellectual property rights and in particular copyright in software as examples - and adds in the same breath that this must not result in refusing to provide all information to the data subject. That sets the direction: you redact the individual passage, not the document.

• Information about other people named in the conversation, such as a colleague name or somebody else's order number
• Internal staff identifiers, where the handling of the case remains traceable without them
• The assistant system prompt and parts of the knowledge base, insofar as genuine trade secrets attach to them
• Abuse detection rules and thresholds whose disclosure would devalue the defence
• Credentials, keys and tokens that ended up in free text by accident
• Content from other people's conversations that technically sits in the same export, for instance in a shared log

What is not redacted is anything concerning the data subject themselves, however awkward. An internal note about how the conversation went, a classification as a difficult case, a remark about a goodwill gesture: all of that is data about this person and belongs in the answer. The German exceptions to the right of access in Section 34 BDSG are narrow and do not cover the ordinary case; the exception for data serving solely for backup purposes, for example, only applies in combination with further conditions and justifies no blanket trimming. So record, for every redaction, what it rests on. That note is later the difference between a decision you can explain and an accusation you cannot rebut.

The process in practice

An access request is a case with a start, a deadline and a record. What makes it fail is almost never the legal assessment but ownership and the search across systems. The following order has proven itself because it pulls the two time-critical steps to the front: logging the request on the day it arrives, and asking about its scope while there is still time to act on the answer.

What you can prepare in advance

The difference between a calm and a frantic access request is created months earlier. Write down once, after an assistant goes live, which stores a conversation touches, and the answer is essentially in place. Everything else is routine: a template, an owner, a dry run. The groundwork on where the data sits and who processes it is covered in the article on data protection and hosting for an AI chatbot.

• An inventory naming, per system, which fields belong to a conversation and how they can be matched
• An export that queries all of those stores in one run instead of asking five people individually
• A template for the covering letter with the eight items from Article 15(1), ready to be filled in
• A rule in the assistant that flags a recognised access request and opens a case with the date of receipt
• A named owner and an inbox that is read daily, including over holiday periods
• A dry run using a test account created for the purpose, with the time it takes measured and written down

That leaves the wider view. An access request is uncomfortable as long as you read it as an attack. Above all, though, it is an audit of your own house: anyone who can hand over a complete, intelligible copy within four weeks knows where their data sits, who receives it and how long it stays. Anyone who cannot has no access problem but an inventory problem - and that surfaces sooner or later somewhere else, during an erasure, during a system migration, or at the next review by a supervisory authority. In XICBOT a single conversation can be exported, and you set retention periods per data type in the admin area; the documentation shows where both are. Which places at XICBOT hold data from a conversation at all is described on the privacy and hosting page.

Frequent questions