A customer requests their data: what must you provide when AI handles your customer contact?

What is a customer actually asking for when they request their data?

Article 15 GDPR gives every customer the right to be told whether you process personal data about them. If you do, they may see that data and receive a copy of it. The law calls this the right of access.

There is no prescribed form for such a request. The customer does not have to use the words "access request", does not have to fill in a form, does not have to give a reason and does not have to write to a special address. "Send me everything you have on me" is a valid request. So is a voice note on WhatsApp.

The right also goes beyond the data itself. Article 15(1) lists what you have to explain alongside it: what you use the data for, which categories of data are involved, who you share it with, how long you keep it or how you decide that period, where the data came from if not from the customer, and which other rights they have. That last list is concrete: rectification, erasure, restriction of processing, objection, and the right to lodge a complaint with the Dutch Data Protection Authority. If you take automated decisions about them, you also have to explain the logic involved and what it means for them.

For a business using AI in customer contact, the surprise is rarely the customer record. That is usually found in seconds. The surprise sits in the conversations: the chats, the email threads, the summaries the system wrote by itself and the notes it dropped into your CRM. Those are personal data too, and they fall squarely within the same request.

Access requests arrive through the channel the customer already uses

Most business owners picture an access request as a formal letter. In practice it arrives between the ordinary messages: in the chat widget on your site, in your business WhatsApp, in the shared inbox, or over the phone. Exactly where your AI assistant sits.

That is the first risk. An AI assistant configured to book appointments and send quotes will not automatically recognise "what data do you actually hold on me?" as a legal request. It may answer with a polite stock sentence and close the conversation. The clock is already running at that point.

In practice this means two things. First, define the signals that must route a conversation to a human. Questions about access, deletion, objection, opting out and complaints belong on that list. Second, record the date the message came in, not the date you happened to notice it. The deadline starts on receipt of the request, not when it lands on your desk.

Bear in mind that the request will not always reach you directly. Customers sometimes email the vendor of the chat widget or the company running your telephony. Agree that such messages are forwarded to you immediately, because the customer holds the right against you, not against your supplier.

You have one month, and extending it only counts if you say so in time

Article 12 GDPR puts it briefly: you inform the customer without undue delay and in any event within one month of receiving the request about the action you have taken. The Dutch Data Protection Authority translates this into plain language: the organisation must respond within one month and must then say whether the requested information is coming, or that it is refusing (part of) the request and why.

Two points in there are regularly missed. The first: a "no" also has to arrive within that month, with reasons. Silence is not an answer and not a refusal; it is simply a missed deadline. The second: the month is an outer limit, not a target. "Without undue delay" means you may not sit on a simple request for three weeks because that suits your schedule.

Extending is allowed. Article 12(3) GDPR permits you to extend the period by a further two months where the request is complex or where you are dealing with a number of requests at once. But that is not a choice you make afterwards: you have to tell the customer within the first month that you are extending, and why. If you do not say so in time, you have missed the deadline, even if you later deliver an immaculate file.

When is an AI customer-contact request genuinely complex? When three years of chat and phone conversations have to be reviewed, for example, or when other customers' data appears in the same conversations and has to be carefully separated out. "We are busy" is not complexity.

What do you have to hand over when the AI held the conversations?

The rule of thumb: everything that is about this person and can be traced back to them, whatever system it sits in. The fact that a machine wrote it changes nothing. A summary your AI assistant produced from a phone call is personal data the moment the customer's name or phone number is attached to it.

So map your own chain before the first request arrives. What sits where? A typical AI customer-contact setup holds data in four or five places at once: the chat history at the widget, the transcripts at the telephony provider, the messages in WhatsApp Business, the email threads, and the fields and notes in the CRM. Do not overlook your own devices. The Dutch tax authority points out in its own guidance that communication tools used mainly in private — a personal email address, WhatsApp — can form part of your business records as soon as they are also used for business. What counts as business records can equally contain personal data covered by an access request.

What a customer may request under Article 15 GDPR, and where that lives in an AI customer-contact system

What the customer is entitled to	Where it sits in AI customer contact	Where it commonly goes wrong
Confirmation that you process data about them	Customer record or CRM entry, plus every channel they appear in	Only the CRM is searched, not the chat and call history
A copy of the personal data itself	Chat logs, call transcripts, WhatsApp messages, email threads, form submissions	Only the most recent conversation is supplied; older ones go unmentioned
The purposes of the processing	Your own record of processing activities and privacy statement	It says "customer service" and nothing else; training or analysis of conversations is missing
The categories of personal data	CRM fields plus whatever actually ends up in the conversations	Free text is forgotten, which is where the most sensitive material sits
The recipients or categories of recipients	AI vendor, telephony provider, messaging platform, hosting party, any sub-processors	Only the party you signed with is named, not who sits beneath them
The retention period or how you set it	Retention policy per system, including log files and backups	The business owner does not know how long the vendor keeps logs by default
The source of data not obtained from them	Purchased lists, third-party forms, integrations with other systems	The answer pretends everything came straight from the customer
Whether automated decisions are being taken	Routing, scoring or prioritisation applied by the AI system	The business owner does not know which automatic choices the system makes
Their other rights and how to complain	Standard text in your response letter	The rights are not mentioned, which makes the answer incomplete

Note the difference between the data and the model. You do not have to explain how a language model works internally. You do have to be able to say which data you fed into that system, who else has seen it and where it still sits today. If you cannot answer that question, that is a problem in itself — not only on the day a customer calls.

In what form do you deliver it, and may you charge for it?

The main rule in Article 12 GDPR is that you provide information in a concise, transparent, intelligible and easily accessible form, using clear and plain language. A raw database export with column names like usr_ref and ts_utc does not meet that standard. Add a readable explanation that tells the customer what they are looking at.

If the request comes in electronically, you supply the information in a commonly used electronic form, unless the customer asks otherwise. A PDF or a readable text file per channel works well in practice: one section with the customer data from the CRM, one section with the conversations in chronological order, and one section with the explanations required by Article 15(1). Deliver a chat conversation as a readable transcript, not as a JSON dump.

On cost: the answer is provided free of charge as a starting point. You may not add an administrative charge because it took you time. Article 12 GDPR leaves room to charge a reasonable fee or to refuse only where a request is manifestly unfounded or excessive, and then it is on you to demonstrate that character. Someone asking for their data once a year does not qualify.

Think about the delivery route as well. You are sending a file full of personal data; that does not belong as a loose attachment to an address you are not sure belongs to the customer. Deliver through a channel where the customer is already known to you.

How do you establish that the requester really is the customer?

Businesses tend to make one of two opposite mistakes here. One is not checking at all, so a customer's complete conversation file goes to whoever happened to email. The other is demanding a copy of an identity document as standard — collecting more data, at the very moment you are assessing a data request.

The measure is Article 5(1)(c) GDPR: data must be adequate, relevant and limited to what is necessary for the purpose. The purpose here is narrow: establishing that the requester is the same person the data is about. You need nothing more than that.

Article 12(6) GDPR gives you the room you need: where you have reasonable doubts about the identity of the requester, you may ask for additional information. Note the order. First establish that there is doubt, then ask. Workable approaches, from light to heavy:

• If the request comes from the email address or phone number already attached to the customer file, and used for earlier correspondence, that is often enough on its own.
• If you do have doubts, send a confirmation message to the address you already hold, rather than replying to the address the request came from.
• Ask for a detail you already hold that an outsider would not readily know, such as an order number or the date of an appointment.
• Only where nothing else will do, and for sensitive files, ask for an identity document. Ask for the photograph and the citizen service number to be masked, and do not retain the copy.

Do not fully automate this step. An AI assistant that decides for itself that identity is sufficiently established and then sends out the whole file is a data breach with extra steps. Let the system recognise the request and prepare the package; let a human decide that it may go out.

What do you do when someone else's data appears in the conversations?

In customer contact this is the rule rather than the exception. A chat mentions the partner coming along to the appointment. A call transcript has the customer naming a colleague or a neighbour. An email thread contains the account manager, and a complaint call names a member of staff in full.

Article 15(4) GDPR states that the right to obtain a copy must not adversely affect the rights and freedoms of others. That is not a licence to refuse the request. It is an instruction to weigh things up. In practice that comes down to three things:

1. Do supply what concerns the requester. The fact that a conversation also mentions a third party is no reason to withhold the whole conversation.
2. If you redact, redact narrowly. Remove the third party's name or number and leave the rest intact.
3. Explain that you redacted, and why. A customer looking at a black bar with no explanation is far more likely to complain than one who reads that someone else's data sat there.

Your own employees' names are a separate case. That a particular member of staff handled the conversation is usually something the customer may know. Internal appraisals of that employee do not belong in the package. Remember internal notes about the customer as well: those are the customer's personal data and therefore fall within the request, even when they are less than flattering. That is a good reason to keep the standard for internal notes sharp, including when an AI writes them.

What if the conversations sit with your AI vendor?

With bought-in AI for customer contact, the data almost always sits with someone else. That changes nothing about who is responsible. You determine the purposes and means, so you are the controller; the vendor is usually a processor. The customer comes to you, and you have to deliver.

Article 28 GDPR requires that relationship to be set out in a contract, covering among other things what the vendor does for you and that it assists you in meeting your obligation to respond to data subject requests. That is precisely the clause you need on the day an access request lands. So look at three points in your data processing agreement before that day arrives:

• Does it say the vendor will assist with data subject requests, and within what timeframe?
• Can you export one customer's data yourself, or does every extract depend on their support desk?
• Which sub-processors sit underneath, and can you name them in your answer?

A vendor who replies after three weeks has eaten your statutory month. So test once how long an export takes, using a test customer of your own, before you have to do it under time pressure.

Can you just delete the data now the customer is asking about it?

No, and this temptation is real: the request comes in, someone thinks "then we will just wipe it" and the logs go. That is not a solution, it makes matters worse. The access request has already been made and you have to answer it; destroying data after a request has been received turns an administrative job into an accountability problem.

On top of that, you are not free to erase whatever you would rather lose. Business communication can form part of your statutory records — the Dutch tax authority itself names email and WhatsApp as examples once they are used for business — and legal retention obligations apply to those. A customer asking for access usually wants something quite different from deletion anyway; do not conflate the two requests.

The reverse move is worth making: make sure that before a request arrives you know which retention period applies per system and that you can explain it. Then "how long do you keep this?" is a matter of looking it up rather than improvising.

How to turn an access request into a routine job

The difference between a week of panic and half an hour of work is almost entirely preparation. Five things you can arrange now, without a lawyer:

1. List every place customer data sits: CRM, chat, telephony, WhatsApp, inbox, forms, backups. Note who can export from each.
2. Teach your AI assistant to recognise the trigger words — access, my data, delete, object, GDPR — and to hand over to a human, with the date of receipt attached.
3. Set up one mailbox or address where these requests converge, and agree with your suppliers that requests reaching them are forwarded there.
4. Write one response template containing the fixed elements from Article 15(1), so that all you have to add is the data itself.
5. Rehearse it once on yourself. Request your own data, walk the whole chain and time it. Whatever you run into there is what you will run into with a real customer.

This article is general explanation of what the law says, not legal advice about your specific situation. If you are unsure about a concrete request — because the file contains special category data, because a third party objects, or because the request coincides with a dispute or a claim — put it to a privacy lawyer before you answer.