AI in your webshop: what consumer law demands of your sales conversation

Why is AI in a webshop mainly a consumer law question?

When it comes to AI and customer contact, most business owners think of privacy first. You do need a lawful basis and an arrangement with your vendor, but you settle that once and it sits apart from your selling. In a webshop something else comes on top, something many other sectors do not have: the AI stands exactly where the sale is formed. It answers the last question before someone clicks to order. It confirms the price. It says when the parcel will arrive.

That shifts the centre of gravity of the rules. What your assistant may say here is not governed by privacy law but by consumer law in Book 6 of the Dutch Civil Code: the rules for distance selling. Those rules know only two parties, the trader and the consumer. A chat window is not a third party and a language model is not a legal person. Everything your AI says in that window, you say.

That sounds strict, but it also makes the question simple. You do not have to work out what a bot is allowed to promise. You only have to know what you would be allowed to promise, and then put that into the bot. The rest of this article is about that translation: which legal duties sit inside a sales conversation, and where an AI most often breaks them.

What has to be in the conversation before the customer is bound?

Article 6:230m of the Civil Code places the information duty for distance selling before the moment of contracting. The law says it literally: before the consumer is bound by a distance contract or by an offer to that effect, the trader provides the information in a clear and comprehensible manner. Afterwards is therefore too late. That word "before" is exactly what an AI assistant can upset, because it usually talks in the final minute before the order.

The list covers, among other things:

• who you are, where you are established and how the customer can reach you;
• the main characteristics of the product or service;
• the total price, including taxes and all additional charges such as shipping;
• the method of payment, delivery and performance, and when you deliver;
• whether there is a right of withdrawal, how the customer uses it, and the model form for it;
• the duration of the contract and how it ends, if it is a subscription;
• where the customer can go with a complaint.

In a classic webshop that list is spread across the product page, the checkout page and the terms and conditions. Put an AI next to it and two situations arise that you have to keep apart.

The AI only refers

If your assistant answers questions and then sends the customer to the normal checkout page, that page remains the carrier of the information duty. The risk then is not what the AI leaves out, but what it contradicts. If the chat says "shipping is free" while the checkout page shows shipping costs, you have a problem that stands apart from whether the page itself was complete.

The AI puts the offer together itself

If your assistant composes the offer — "I will take that size for you, shipping included, I will set it aside" — then that conversation is the moment before the customer is bound. The mandatory information has to sit in that conversation or hang off it in a clear way. A reference to a page the customer never opens is weak at that point.

Article 6:230v of the Civil Code adds a requirement about form: the information must be provided in a way that suits the means of distance communication used, and in clear, comprehensible language. That is exactly the provision you need when you run AI across several channels. A WhatsApp conversation is a different means than an email, and a phone call is different again. The substance of the duty does not change, the form does. The same article requires, for telephone selling, that the trader states at the start of the call who he is and that the call is about selling. An AI phone assistant that opens with "how can I help you?" and only reveals three minutes later on whose behalf it is calling does not meet that.

The practical rule that follows: never let an AI summarise mandatory information in its own words. Have it retrieve the fixed text and show it. A language model that "explains the returns policy in plain language" is rewriting a legal obligation, and that is not a task you hand to a generator.

Why does the AI have to state the cooling-off period exactly right?

Article 6:230o of the Civil Code gives the consumer the right to dissolve a distance contract without giving reasons until a period of fourteen days has passed. It is the most looked-up piece of consumer law there is, and it is also the piece an AI assistant gets wrong most often. Not because the rule is complicated, but because the way you word it is itself subject to supervision.

The Dutch Authority for Consumers and Markets is unusually direct about this. The cooling-off period is a legal right and not a service from the shop, and you should not present it as one either. A line like "we give you fourteen days to think it over" does exactly that: it sells an obligation as a favour. The regulator calls that unfair trading. The problem is that such a sentence almost always sits in marketing material, and marketing material is precisely where an AI assistant picks up its tone. Feed the bot your own sales pages and it will copy that phrasing.

There are more traps inside this single topic:

• Dissolving is not exchanging. An AI that says "you may exchange it within fourteen days" shrinks the right. The customer may walk away from the purchase, not merely swap it for something else.
• The starting moment differs. Article 6:230o runs the period from a different moment for services than for the delivery of goods. An assistant that uses one standard sentence says something inaccurate on half the orders.
• There are exceptions. Article 6:230p names cases in which the right does not apply, for instance products made to the customer's specification. An AI that does not know this makes one of two mistakes: it promises a right that does not exist, or it denies a right that does. Both cost money.
• Informing badly extends the period. Article 6:230o ties the length of the cooling-off period to whether you informed the consumer properly about that right. Look up the second paragraph of that article and put the outcome in your script; this is not a part you let a model estimate.

So treat the cooling-off period as fixed text with a few variables, not as a topic your assistant is free to phrase. In practice that means one approved paragraph per product type, and a bot that picks which paragraph to show rather than a bot that writes a new one.

What happens if the AI promises something you cannot deliver?

This is the biggest risk of AI in a webshop, and it is not a privacy risk. Article 6:193c of the Civil Code says a trading practice is misleading if information is provided that is factually incorrect, or that misleads or may mislead the average consumer. It says nothing about intent. It says nothing about whether you knew. Incorrect is enough.

That is precisely a language model's weak spot. A model that does not know the delivery time rarely invents "I do not know". It produces a plausible-sounding sentence: "then you will have it on Wednesday". If that is wrong, legally you do not have a bot that made a mistake, you have a trader who provided incorrect information.

The consequences run along two lines. The regulator sums up the first line briefly: with an unfair trading practice consumers may walk away from the contract and can claim damages, and that applies to all customers in the European Union. That is the private-law side, customer by customer. The second line is enforcement by the regulator itself, which does not look at one conversation but at a pattern. An AI that makes the same mistake a thousand times is more attractive material for a supervisor than an employee who misspeaks once, because the pattern is neatly logged in your own system.

The topics where this goes wrong are always the same: delivery time, stock, price and discounts, whether a product fits something else, and how long the warranty runs. They are all facts that live in some system and that a model must not infer from text. So the fix is not a better prompt but a hard boundary: on a date, an amount, a quantity or a period, the assistant says something only if it has retrieved the value from a source. If it has no source, the answer is that it will check. That is a duller answer and it is the only defensible one.

Which customer question calls for which answer?

Most webshop conversations consist of a handful of recurring questions. That is good news, because it means you can write out their legal weight once and then lock it down. The table below puts the question as a customer asks it next to what the answer legally has to contain.

Common question in a webshop chat, next to what the answer must legally contain

What the customer asks	What the answer must contain	Where it goes wrong
"Can I send this back?"	The legal right to dissolve within fourteen days, when that period starts, whether an exception applies, and how the customer notifies you.	Presenting the right as your own service, or saying "exchange" where "dissolve" belongs.
"What does it cost in total?"	The total price including taxes and all additional charges, shipping among them.	Quoting the bare product price and letting shipping costs surface only at checkout.
"When will I have it?"	A delivery period you can meet, retrieved from the system that knows the real lead time.	Inventing a date because the question asks for a date.
"Is this still in stock?"	The current stock level from your own system, or an honest statement that the assistant cannot see it.	Suggesting scarcity that does not exist; untrue urgency is on the blacklist in article 6:193g.
"Is there a warranty?"	That the customer is entitled to a product that performs as expected anyway (conformity, article 7:17), and separately what a manufacturer or commercial guarantee adds.	Naming a period that comes from nowhere, or trading the legal entitlement for the commercial guarantee.
"I have a complaint"	Recognition of what the customer is legally invoking, the complaints route, and a route to a human.	Handling the complaint as a request for information and letting the matter hang in a loop.
"Am I talking to a robot?"	An honest answer, and preferably a notice that was already there before the question came.	Dodging, or admitting it only when the customer presses.

The useful thing about this table is that it can be tested. Put the seven questions in a test set, run them again after every change to your assistant, and read the answers with the middle column beside them. That is half an hour of work per release and it catches exactly the mistakes that are expensive.

How do you handle a complaint when the first line is an AI?

A complaint in a webshop is rarely just a complaint. Usually the customer is invoking a right without naming it. "It does not work" is a conformity claim. "I want out after all" is a dissolution. "I never ordered this" is something else entirely. Those three call for three different responses, so the first job of an AI in the complaints flow is not solving but recognising.

That is also where the deadline problem sits. The cooling-off period keeps running while your assistant asks questions. A bot that asks three times for an order number and then offers "to pass it on to a colleague" eats days off a period that belongs to the customer, not to you. If you let such a period lapse because your own first line did not recognise the message as a dissolution, that is your problem. The consumer reported in time; the fact that it landed with a bot is a choice you made.

Also watch what your assistant itself says about timing. The law prescribes no fixed response time for an ordinary complaint, but the moment your bot says "you will hear from us within 24 hours", you have created that deadline yourself. That is a promise about your service, and a promise you structurally fail to keep falls back under the misleading-practice rules of article 6:193c. So let the assistant name only response times your organisation also meets on a busy Monday.

Three design choices make the difference:

1. Classify before answering. Have the assistant first determine what type of message this is, and only then form a reply. Dissolutions, conformity claims and disputed orders go straight to a human.
2. Stamp a date. Record when the message arrived, not when someone picked it up. In an argument about a deadline that is the only thing that counts.
3. An exit that always works. One sentence from the customer must be enough to reach a human. An assistant without an emergency exit produces the loop complaints get stuck in all by itself.

If a request to access or delete data comes in through the same mailbox, an entirely different regime applies to it, with its own deadline. Do not treat that as a complaint; that subject sits elsewhere in this knowledge base.

What does the regulator look at?

On the webshop side that is the Authority for Consumers and Markets. It looks at the information duties and at unfair trading practices, and therefore at what happens inside the sales conversation. On the data side there is a different regulator with its own agenda; the two tracks run alongside each other and one does not shield you from the other.

Two tracks of supervision over an AI assistant in a webshop

Track	What it is about	What the customer can do
Consumer law	Information up front, the cooling-off period, the accuracy of what you promise.	Annul the contract and claim damages in case of an unfair trading practice.
Data protection	What you do with the conversations and how long you keep them.	Exercise rights over the data; a separate route with its own deadline.

In practice there are four places where a chat assistant visibly goes wrong. The wording around the cooling-off period, because it comes out of marketing copy. The completeness of the price, because additional charges fall away easily in a conversation. The accuracy of claims about stock and delivery time, because a model likes to fill those in. And untrue urgency, since a line like "only two left" that is not true is not a slight exaggeration but falls under the blacklist in article 6:193g.

What makes this different from a human employee is the evidential position. Conversations with an AI are logged, complete, with a timestamp. That cuts both ways: it proves you did it right, or it proves a thousand times over that you did it wrong. For that reason logging conversations is not a side issue but part of your defence — and immediately a reason to read a sample yourself now and then, before someone else does.

What do you settle before putting the AI on your webshop?

An AI assistant on a webshop is a sales employee without a memory whom you give no induction period. Everything a new employee would learn in their first week has to be on paper up front. This is the short list.

1. Fixed text for the mandatory subjects. Cooling-off period, returns procedure, warranty, shipping costs and delivery times each get an approved wording per product type. The assistant picks, it does not write.
2. Facts from systems, not from text. Price, stock and delivery time come from the source. If the source is missing, the assistant says it will check.
3. A list of what it never says. No granting discounts, no promising delivery dates, no confirming an exception to the cooling-off period, no naming a warranty period.
4. A notice up front that this is AI. One line at the start of the conversation is enough, and it saves you the argument afterwards.
5. An escalation rule that is not negotiable. Dissolutions, complaints about a defect, disputed orders and every angry customer go to a human.
6. Logging with a timestamp and a retention agreement. What was said, when, to whom, and how long you keep it.
7. A test set you run after every change. The questions in the table above are a fine starting point.

Finally, the point most often forgotten when signing a contract with an AI vendor. That agreement governs the relationship between you and the vendor. It does not move your position towards the consumer. You are and remain the trader in the sense of consumer law, even if the model belongs to someone else and the fault sits in a system you did not build. So pick your vendor partly on whether you can hold its assistant back, not only on what it can say.