Which legal basis do you need to let AI process customer data?

You bring in an AI assistant to answer your email, keep up with your WhatsApp or pick up your phone. The moment that system sees a name, a phone number, an address or a description of a complaint, you are processing personal data. From that moment the General Data Protection Regulation, the GDPR, applies. The first question you need to be able to answer is not "is it properly secured" and it is not "is it in my privacy statement" either. The first question is: what is my legal basis for doing this?

That sounds formal, but it is a very practical question. The legal basis is your legal reason for using the data. If you do not have one, everything that comes after it — the security, the contract with your supplier, the polished text on your website — is not enough. This page is the overview: which six bases Article 6 GDPR sets out, which ones remain for customer contact, how the usable ones work out in practice, why you choose separately for each purpose, and what you have to record and disclose afterwards.

Without a legal basis, the processing is unlawful

Article 6 GDPR is short and strict. It opens with the statement that processing is lawful only if at least one of six conditions is met. Two words do the work there. "Only" means there is no residual category, no "it isn't sensitive anyway", no "the customer probably doesn't mind". "At least one" means you do not need several, but you must be able to point to one — and that one has to hold up.

Note as well what "processing" covers. It is not just storing something in a database. It is also sending data to a language model, having it summarised, having it labelled, having it read in order to draft a reply, keeping it as conversation history, and using it to improve the system. Each of those actions is a processing operation. An AI assistant for customer contact usually performs all of them, often within a single conversation.

Many business owners believe they tick off the legal-basis question with a contract. That is a misunderstanding worth clearing up explicitly. A data processing agreement with your AI supplier (Article 28 GDPR) governs how that supplier handles the data: that it only does what you instruct, that it secures the data, that it deletes it when the work ends. It does not govern whether you may process that data at all. That remains your question, and you answer it with Article 6.

The same goes for security. Excellent encryption does not make a processing operation without a legal basis lawful; it merely makes it well secured and still unlawful. The order is: first whether you may, then how.

The six legal bases, briefly

Article 6(1) GDPR lists six bases, lettered (a) to (f). In plain terms:

1. Consent (a). The customer has explicitly agreed to this specific purpose.
2. Performance of a contract (b). You need the data to deliver what you agreed, or to take steps at the customer's request before a contract is concluded — a quote or an appointment, for instance.
3. Legal obligation (c). Another law compels you to process the data, for example the tax rules on keeping your business records.
4. Vital interests (d). It is necessary to protect someone's life or health, in situations where that person cannot decide for themselves.
5. Public interest task (e). You carry out a public task or exercise official authority.
6. Legitimate interests (f). You have a genuine interest of your own, the processing is necessary for it, and the customer's interests do not outweigh yours.

The order is not a ranking: basis (a) is not "better" than basis (f). What is true is that some of these bases will almost never apply to an ordinary small or medium-sized business.

Which of the six fit AI in customer contact?

It helps to lay all six alongside your own situation once. For an installer, a webshop, a clinic or a consultancy, half of them drop away immediately.

The six legal bases of Article 6(1) GDPR set against typical AI customer contact in a small business

Legal basis	Fits AI customer contact?	Why
a. Consent	Sometimes	Usable for extras the customer can genuinely decline, such as marketing or keeping a call recording. Unsuitable when the answer to the customer's question depends on it, because then the consent is not freely given.
b. Performance of a contract	Yes, usually	The customer asks about their order, appointment or fault. Answering that is performance of what you agreed, or a step immediately preceding it.
c. Legal obligation	Limited	Covers keeping invoices and business correspondence for your records. Does not cover an AI system analysing the content of conversations.
d. Vital interests	Almost never	Intended for emergencies where someone's life or health is at stake. Not for a customer service channel.
e. Public interest task	No	For government bodies and organisations with a public task. A commercial business cannot rely on it.
f. Legitimate interests	Yes, if documented	Usable for things that are not strictly necessary for the contract but are reasonable, such as fraud prevention or quality control. Requires a written assessment in advance.

In practice, three remain

That table produces the picture that holds for almost every small business: you work with (b), (f) and occasionally (a). Vital interests and public interest can be set aside. Legal obligation is real, but only covers the part the law actually compels.

What remains is performance of a contract, legitimate interests and consent. The Dutch data protection authority names performance of a contract as the basis that usually applies to business owners, and advises against leaning on consent without good reason if you want a stable footing.

That advice is meant practically. Consent is the only basis the customer can withdraw. If they withdraw it, your footing disappears and you have to stop — even if you are halfway through an ongoing process. That cannot happen with performance of a contract, because as long as the agreement runs you simply need the data.

On the third one, legitimate interests, only this here. That basis comes into play for things you reasonably want to do but that are not strictly needed to carry out the agreement with the customer: fraud prevention, for example, or quality control. You cannot simply tick it: it comes with a balancing exercise between your interest and the customer's, and that exercise has to be in place before you start. How that test works exactly and how you write it down has its own article in this knowledge base. The rest of this page is about the other bases and about the choice itself.

The contract is the workhorse of customer contact

Basis (b) is by far the most important one for customer contact, and it consists of two halves that often get lumped together. The first half: the processing is necessary for the performance of a contract to which the customer is a party. The second half: the processing is necessary in order to take steps at the customer's request before there is a contract. That second half covers the quote request, the contact form and the appointment still to be booked — exactly the traffic an AI assistant is put on first.

Note the word "necessary". It is narrower than "handy" and narrower than "fits our service". The test you set yourself is simple: could I deliver what I agreed without processing this data? If a customer reports a fault, you need their address, the appliance and their description of the problem to do anything at all with it. An AI system reading those three things and turning them into an answer or an appointment sits neatly under (b).

It is just as useful to know where this basis stops. Analysing the tone of conversations in order to assess staff: not necessary to deliver. Building a customer profile so you can sell more precisely later: not necessary to deliver. Using conversations to make the model better: not necessary to deliver. Those are all purposes you are allowed to have, but they lean on something other than the contract.

Two things you keep sharp with this basis. First, the customer must have taken the step themselves. "At the request of the data subject" means they came to you. A list of leads you gathered yourself and let an AI approach does not fall under this; that is something else and needs a different justification. Second, when the contract ends, the reason for continuing to process the data for that purpose ends with it. If you want to keep the conversation after that, you need a new reason — and that reason is usually your business records.

Finally, one caveat that is often forgotten. The fact that a customer has a contract with you does not automatically make everything that happens in that channel lawful. The basis attaches to what is processed and what for, not to the relationship in general. An ongoing service agreement is not a standing licence for every new feature you switch on in the system.

Legal obligation covers less than you think

Basis (c) only works where a law compels you. Not your insurer, not your trade association, not your own internal policy, and not an agreement with a customer either. You must in principle be able to point at the rule that forces your hand. For a small business the best known is the tax retention duty: you keep your business records for seven years, and for data relating to immovable property a longer period applies.

For AI customer contact that has one clear consequence. Correspondence that forms part of your records — a quote, an order confirmation, a dispute about an invoice — may and must be kept, even if a customer asks you to erase everything. The right to erasure gives way to a statutory retention duty. That is one of the few places where you may refuse a customer's request, and it is good to know that place exists.

But a duty to retain is not a right to retain everything. A message saying "can you call me tomorrow?" is not part of your records. And more importantly: retaining is one processing operation, analysing is another. The fact that you have to keep an invoice dispute in your archive for years does not give your AI system the right to search those messages, summarise them, label them or use them to improve itself. Those are new purposes, so a new legal basis is required.

In practice it comes down to this: keep separate, inside your system, what you retain because you must and what you retain because it is convenient. For the first, (c) is enough, and that basis also sets your retention period. For the second you have to be able to name something else. Anyone who does not draw that line ends up keeping everything forever — precisely the opposite of what the GDPR asks of you.

Why consent is often the wrong choice

There is a second problem with consent. The GDPR sets requirements for what consent is: under Article 4(11) it must be freely given, specific, informed and unambiguous, and it must be shown by an affirmative action. If you pre-tick a box, or make the answer to a customer's question conditional on that box, the consent is not freely given and therefore not valid. And if the consent is invalid, you have no legal basis at all — exactly the situation you were trying to avoid.

That does not mean consent is never right. For an AI that sends a commercial newsletter after a conversation ends, or for keeping a call recording to train on later, consent is often precisely the clean choice — because the customer can genuinely say no without losing their answer. The rule of thumb: use consent for what is optional, not for what is the core of your service.

If you do go for consent, bear in mind that it brings paperwork with it. Article 7 GDPR requires you to be able to demonstrate that the customer consented, and that withdrawing must be as easy as giving. So you record when somebody said yes, what exactly for, and with what wording in front of them — and you make sure there is a button to undo it. With the contract basis you need none of that administration. That is a second reason to save consent for what is genuinely optional.

A separate basis for every purpose — not one blanket tick

This is the mistake that occurs most often and can cost the most. Business owners pick one basis for "our AI customer service" and assume they are done. It does not work that way. The regulator is explicit about it: you need a separate legal basis for every purpose for which you process data, and you cannot lump all your processing together under one.

The temptation is understandable. The system feels like one thing: one supplier, one inbox, one switch that is either on or off. But the GDPR does not look at systems, it looks at purposes. And one basis for everything goes wrong in three ways.

The first way: your choice gets tested against your heaviest purpose. If you name one basis for the whole system, that basis also has to carry the most intrusive thing the system does. If it does not hold there, it falls for everything — including the innocent business of answering a question, for which you would effortlessly have had a solid basis.

The second: retention periods blur together. Every purpose has its own period, because you do not keep data longer than that purpose requires. Under one blanket basis that distinction disappears and in practice you keep everything as long as the component that may stay longest.

The third: withdrawal becomes needlessly complicated. If you have pushed everything under consent and a customer withdraws it, you also have to stop processing that you could simply have continued on the contract. You have locked yourself into a stricter rule than the law asked for.

Take an AI assistant on your inbox. Within that one system, four different purposes quickly run alongside each other:

• Answering customer questions. Performance of a contract, or a step preceding it.
• Keeping conversation history for your records. Legal obligation, for the part the law imposes on you.
• Sending a commercial newsletter or offer. Consent, or possibly legitimate interests for existing customers — with the separate anti-spam rules of the Dutch Telecommunications Act on top.
• Using conversations to assess the model or your staff. A purpose of its own with its own justification, and where staff are involved, employment law rules apply as well.

Four purposes, so potentially four legal bases. The good news: this is usually a one-off piece of thinking. List the purposes, assign a basis to each, write one sentence on why, and you are there. When something changes — you switch on a new feature, you connect a new channel — you take that list out again.

While you are at it, remember Article 5(1)(c) GDPR: data must be limited to what is necessary for the purpose. Having a basis for answering a question does not mean you may push the entire customer file into the AI system.

You choose — your supplier does not choose for you

Who decides which basis applies? You do. The Dutch data protection authority puts it plainly: you must assess for yourself which basis applies, that is your own responsibility, and the regulator cannot advise you on it.

That is worth knowing, because it corrects two habits. The first is calling the regulator to ask whether something is allowed. That will not get you an answer. The second is pushing the question onto the AI supplier, with a line like "they are GDPR compliant". Your supplier is normally a processor: it processes on your instructions. You are the controller: you determine the purposes and means, and therefore the legal basis too. If something goes wrong with lawfulness, the regulator looks at you.

What you can reasonably ask your supplier for are the building blocks: which data goes where, what is retained and for how long, where the servers are, who has access. Without that information you cannot make a proper choice. But the choice and the reasoning stay yours.

There is a procurement tip hidden in this. At a demo, do not only ask what the system can do, but ask per feature what happens to the data. A supplier who cannot break that down feature by feature is pushing you back into the blanket basis you were trying to get away from.

You must actively disclose the basis (Article 13 GDPR)

Recording the choice is not enough. Article 13 GDPR provides that when you collect personal data from the customer themselves, you must tell them, among other things, the purposes for which the data is intended and the legal basis for the processing. So your basis does not belong only in your own folder, but in your privacy statement as well — in comprehensible language, and not only once somebody asks.

For AI customer contact that means, concretely, that the customer must be able to find in the normal way that you have their message processed by an AI system, for what purpose, and on what basis. A privacy statement that only says "we take privacy seriously" does not meet that. One line per purpose is enough, provided that line is accurate.

Two things often get muddled here. Disclosing the legal basis under Article 13 is a different obligation from telling someone they are talking to a machine: that second one follows from the AI Act and stands apart from the GDPR. And make sure that what your privacy statement says actually matches what the system does. A statement that names "consent" while you are in fact relying on the contract is not merely sloppy — it makes it harder to show that you knew what you were doing.

From purposes to paper, without a lawyer

The practical route is shorter than it looks. An afternoon gets you a long way:

1. Write down the purposes. Not "AI customer service", but the separate things the system does: answering, escalating, storing, following up, analysing.
2. Assign a basis to each purpose from the six in Article 6. If you cannot point to one, you do not do that particular thing for now.
3. Justify it in one or two sentences. If you land on legitimate interests, that comes with an assessment of its own; that is set out in the separate article about it in this knowledge base.
4. Put a retention period next to it. Per purpose, because they differ. You will see straight away where you keep things too long.
5. Put it in your record of processing activities next to the purpose, the data and the recipients. Then it sits in one place.
6. Update the privacy statement with both the purpose and the legal basis, as Article 13 requires.
7. Repeat on every change. New channel, new feature, new supplier: run down the list again.

If during that exercise you find a purpose you cannot assign a basis to, that is not a failure but exactly the point. You have found on paper where the problem sits, before a complaint or an access request arrives.

Where it goes wrong in practice

Four patterns keep coming back. The first is the blanket basis: one choice for the whole system, while four purposes sit inside it. The second is consent as a reflex: a tick box everywhere, including where the customer has no real choice, which makes the consent not freely given and therefore invalid.

The third is the stale list. It was written down properly once, then a channel was added, a feature switched on and a supplier swapped, and nobody took the list out again. On paper it is correct; in the system it has not been for six months.

The fourth is the basis that exists on paper only. The privacy statement says "consent", while nothing in the system ever asks for it and you are in fact relying on the contract. That is not a small piece of sloppiness. It is also the first thing a regulator notices, because it can be checked without seeing a single line of code.

All four are avoided by the same single action: write out the purposes once and put a legal basis next to each one. That document is also what you will need if you ever have to show that you thought it through.

This page is general information about Dutch and European legislation, not legal advice. Whether a particular basis is correct in your situation depends on your purposes, your data and your agreements with customers. If in doubt, consult a lawyer or privacy specialist.