How do you run the legitimate interests test for AI in customer contact?

Legitimate interests is the only legal basis in the GDPR with a set of scales built into it. With the other bases it is yes or no: either there is a contract or there is not, either there is a legal obligation or there is not. Here you have to do the weighing yourself, and the outcome of that weighing decides whether you may process at all. That makes this basis usable where no other fits, and at the same time the easiest one to get wrong.

This article is only about that test, applied to an AI assistant in customer contact. What the law actually says. How you substantiate each step. When the test comes out negative and what you can do about it. And what a documented assessment looks like in practice. We assume you have already landed on this basis.

What does Article 6(1)(f) GDPR actually say?

The wording is a single sentence and it is full of conditions. Processing is lawful where it is necessary for the purposes of the legitimate interests pursued by the controller or by a third party, except where such interests are overridden by the interests or fundamental rights and freedoms of the data subject which require protection of personal data, in particular where the data subject is a child.

That one sentence produces three requirements. There has to be an interest. The processing has to be necessary for that interest. And your interest must not be overridden by the customer's interests and fundamental rights. Meet two out of three and you have nothing. It is not an average; it is all three or no legal basis.

Two details are often missed. The interest does not have to be yours: the law expressly mentions the interest of a third party as well. If you deploy an AI assistant that also serves the interest of a partner, that can count, provided you name that interest and weigh it just as strictly. And the final paragraph of Article 6(1) rules this basis out for public authorities in the performance of their tasks. If you are an ordinary business that does not apply; if you work as or on behalf of a public body, it does.

Europe's data protection authorities have taken that sentence apart into three conditions you have to satisfy cumulatively. Cumulatively means all three at once. And they add something at least as important: you have to carefully assess and document whether those conditions are met, and that has to happen before the processing starts. An assessment you only make once a complaint has landed is no longer an assessment; it is a defence.

The three steps of the test, with the question you answer at each step and the mistake that is made most often.

Step	The question you answer	The mistake made most often
1. Interest	What concrete, present and lawful interest does this processing serve, and whose interest is it?	Writing the interest so broadly that everything fits under it: "innovation", "better service", "efficiency".
2. Necessity	Is this processing genuinely needed to serve that interest, or would less data achieve it too?	Confusing convenience with necessity. Something being easier does not make it necessary.
3. Balancing	Do the interests, rights and freedoms of the customer override yours?	Filling in your own side only and skipping what the customer expects.

Step 1: how do you word an interest you can build on?

The authorities ask for an interest that is real and present, articulated clearly, and not contrary to the law. That sounds like a formality, but it is the step that governs the rest of your test. Everything you do in steps two and three is measured against the interest you set down here. Write something vague here and you will not be able to prove anything afterwards.

A commercial interest counts perfectly well. The Court of Justice confirmed this in 2024 in the case brought by the Royal Dutch Lawn Tennis Association against the Dutch Data Protection Authority. So you do not have to invent an idealistic or statutory motive in order to use this basis. But the fact that a commercial interest can be legitimate does not mean it always is: it remains an assessment case by case, and the other two steps stand in full.

The difference between a usable and an unusable interest is precision. "More revenue" is not an interest whose necessity you can explain, because you cannot show which data it requires and which it does not. "Preventing customer questions from sitting unanswered overnight and at weekends" is: it tells you what information the assistant needs and what it does not, and why a call-back note the next morning does not achieve the interest.

A practical measure: an interest is sharp enough if you can immediately derive from it which piece of data is needed and which is not. If you cannot, it is worded too broadly. Split it up. Often one sentence hides two interests that are better weighed separately, because they do not need the same data. Note down whose interest it is and why it matters now; that is exactly what you have to be able to show if the question comes later.

Step 2: what does "necessary" mean, and why is convenience not it?

Necessary is a legal term in the GDPR, and it is stricter than the everyday word. It does not mean "handy", it does not mean "efficient", and it does not mean "this is how we work". The core of the test is this: could you reasonably achieve the interest by a means that intrudes less on the customer's privacy? If you could, your processing is not necessary, however reasonable your interest may otherwise be.

What matters is where you draw the comparison. The question is usually not "could this be done without AI". The question is whether the interest is also achieved with less data, with fewer people able to read along, with a shorter retention period, or through a narrower channel. Necessity is rarely an on-off switch; it is almost always a slider.

So work through four dials and put your answer on paper for each:

• What data does the assistant get? Does it need the full customer file, or only the order number, the status and the appointment date? An assistant that only sees the latest order is a different processing operation from one that can read the whole history.
• Who can read along? How many staff have access to the conversations, and is that limited to those who need it for their work?
• How long does it stay? A retention period nobody ever set is in practice indefinite. Keeping data indefinitely is almost never necessary.
• What else happens to it? Do the conversations also go to analytics, to training a model, or to marketing? That is a different processing operation and it cannot ride along on the necessity of answering the question itself.

Record which less intrusive alternative you considered and why it does not achieve the interest. That one sentence is the heart of step two. If, while writing, you find that all you can put down is "this is easier for us", you have not passed step two, and the answer is: give the assistant less data, or do not do this part at all.

Step 3: what does a customer reasonably expect?

In the third step you set your interest alongside the interests, rights and freedoms of the customer. The hinge of that weighing is reasonable expectation: at the moment they handed over their data, what could the customer expect would happen with it? That expectation is set by the context in which they gave it, not by what is technically possible in your system.

Someone who messages you about a broken boiler expects you to read that message, store it and use it to help them. The fact that an AI assistant answers them does not fundamentally change that expectation. What they do not expect is that the same message is used to profile their buying behaviour, to approach them unsolicited months later, or to train a model you also sell to other companies. The further you move from the original context, the heavier their side of the scales becomes.

Situations in which the customer's interest usually wins:

• The conversation touches sensitive subjects: health, debt, a legal dispute. Where special categories of personal data such as health data are involved, legitimate interests will not get you far anyway, because Article 9 GDPR sets out a separate prohibition regime for those.
• The customer cannot reasonably avoid it. If the AI channel is the only way to reach you, their position is weaker and that counts against you.
• The data goes to a party the customer does not know or expect, or to a country outside the European Economic Area.
• The processing leads to a decision about them: whether they get a discount, whether they may buy on account, whether their complaint is rejected. The greater the consequences, the heavier their side weighs.
• Data is kept longer than needed. A chat log sitting there for three years because nobody set up a clean-up shifts the balance with no interest left on the other side.
• The customer is in a dependent position, for example because they are midway through a treatment or an ongoing process and cannot simply walk away.

The outcome of step three does not have to be black and white. Often the conclusion is: allowed, provided that. And those provisos are not a side note, because they are the reason the weighing comes out positive.

Which safeguards push the scales back?

Safeguards are measures that reduce the risk to the customer and therefore add weight to your side of the scales. They are not decoration on an assessment that was going to be positive anyway: they are part of the weighing itself. If a safeguard falls away later, the weighing changes and the legal basis can fall away with it. That is why they belong in your documentation as commitments, not as good intentions.

Safeguards that push the scales back, with the risk each one softens and how you can tell the safeguard genuinely exists.

Safeguard	Which risk it softens	How you can tell it genuinely exists
Passing on less data	The assistant cannot leak or reuse what it never saw.	A list of the fields the assistant does receive, and a system that does not supply the rest.
A fixed, short retention period	Conversations nobody needs any more do not stay available for years.	A configured period that clears data automatically, not an intention to tidy up some day.
A human within one step	The customer is not forced to settle everything with a machine.	A handover route you have tried yourself, including outside office hours.
No reuse for other purposes	Conversations do not end up in marketing or model training without their own weighing.	An agreement with your supplier in writing, plus a technical separation.
Limited access, with logging	Not every member of staff can read conversations that are none of their business.	Roles in the system and a log showing who viewed what.

Two things decide whether a safeguard carries weight. It has to be verifiable: you must be able to point at where it is configured. And it has to address the risk you yourself identified. A short retention period does nothing about the risk that the assistant sees too much data; only passing on less data does that. So set safeguards next to the risks you wrote down in step three, rather than as a separate list underneath.

Why does a child's interest weigh more heavily?

Because the law says so in as many words. Article 6(1)(f) GDPR expressly names the case where the data subject is a child. The legislator did not single that group out by accident: children are less able to grasp what happens to their data, they do not read explanations, and they are more susceptible to being steered.

For a business owner the first question is not legal but factual: do minors end up in my channel? You do not have to guess. Look at what you sell, at your marketing, and at the conversations you are already having. A webshop selling to teenagers, a gym, a driving school, a food delivery business and a clinic all regularly have a minor on the other end, even when the invoice is in a parent's name.

If that is the case, you run step three more strictly. Concretely that means: give the assistant less data, keep it for less time, no profiling, no commercial follow-up based on that conversation, and a fast route to a human. It also means the outcome will more often be "do not do this". That is a valid outcome. A test that can never come out negative is not a test.

What happens when a customer objects?

This is the tail end that comes with this basis and that most businesses forget to set up. If you process on the ground of legitimate interests, the customer may object under Article 21 GDPR. That right always exists, even if your assessment is neatly written down and substantively correct. A good assessment makes the processing lawful; it does not switch off the right to object.

What happens next depends on the situation. Where someone objects to ordinary processing you have to stop, unless you have compelling legitimate grounds that override the interests, rights and freedoms of the customer. That is a heavier test than the ordinary balancing exercise: you have to put more on the table than you did the first time, and the burden of proof is on you. Where the objection concerns direct marketing there is no counter-argument available. Then you stop, full stop.

In practice it comes down to three things:

1. Make sure objections actually reach you. A customer objects in plain language, in the middle of a conversation: "I don't want you keeping this." Your assistant and your staff have to recognise that as a request, not brush it aside as a remark.
2. Make sure you can act on it. If an objection means someone has to be taken out of a particular processing operation, your system has to be able to do that technically. A channel from which you cannot exclude anyone is a problem you solve before go-live.
3. Make sure you record it. Who objected, when, to what, and what you did about it. Without that trail you cannot later show that you handled it properly.

Treat objections as a signal too. If you receive several about the same element, that is an indication that in step three you judged the customer's expectations too optimistically. Then the assessment needs revisiting, not just the individual request.

What does a documented assessment look like in practice?

Not a thick report. One document of a page or two, in plain language, with a date and a name at the bottom. One assessment belongs to one purpose; if the purpose changes, you write a new one. This order works:

1. The purpose in one sentence, without jargon.
2. The interest: whose it is, why it matters now, and why it is sharp enough to attach data to.
3. The data the assistant receives, and the data you deliberately withhold.
4. The retention period, and who has access.
5. The less intrusive alternative you considered and why it does not achieve the interest.
6. What the customer reasonably expects, and what it means for them if something goes wrong.
7. The safeguards, each with the risk it softens.
8. The conclusion: go ahead, go ahead adjusted, or do not proceed.

Update it when something changes about the system, about the data going into it, or about the retention period. An assistant that in March could only look up opening hours and in November can read the whole customer file is a different processing operation from the one you assessed in March. Keep the old versions, because the question afterwards is always what you knew at the moment you started. Finally, put a reference to this document in your record of processing activities, next to the processing it relates to, so you are not searching around when a question comes in.

If you cannot fill in point five or point six, that is your answer: your reliance on legitimate interests is not finished yet. That is no disaster. Writing it out often reveals that part of the data was not needed at all, or that a shorter retention period solves the problem. The test is not only an obligation; it is also the moment you discover how much less you actually needed.

Who ultimately decides whether your reliance holds up?

You make the assessment, and you carry the burden of proof. The Dutch Data Protection Authority says itself that it is your own responsibility to assess what applies to your situation and that it cannot advise you on it in advance. So you cannot phone up for a stamp of approval. Scrutiny comes afterwards, usually only once a complaint has been filed or questions are asked about an incident.

Above that sit the courts, and ultimately the Court of Justice. The Dutch tennis association case shows how that works: a regulator read the standard strictly, and years later a ruling shifted that reading on one point. That is not an argument for waiting and seeing, but for having an assessment you can show. A dated document setting out what you weighed and why is exactly the difference between a discussion about substance and a discussion about whether you thought about it at all.

Your supplier cannot do the weighing for you, but it does provide the building blocks. Ask about retention periods, sub-processors, the countries where data is held, and whether conversations are reused to improve models. Without those answers you cannot fill in steps two and three honestly. If you do not get them, that in itself is information for your assessment.

This page is general information about what the law says and is not legal advice. For your own situation, and certainly where special categories of personal data or customers who are minors are involved, it is wise to have a lawyer look over it.