GDPR and AI in E-Commerce: What You Actually Have to Get Right
Almost every shop owner I talk to has the same worry: am I even allowed to send customer data through an AI? The question is a good one, and it is put too broadly.
The answer does not hang on "AI yes or no". It hangs on which fields you hand over, to whom, where they land, for how long, and whether you can prove it. We use AI at nano, mate and MUSTAX in day-to-day operations. Here is what we clarified for that, and in which order.
One thing up front: this article is not legal advice. I am an entrepreneur, not a lawyer. For concrete questions about your setup, an IT lawyer or a data protection officer is the right person to ask, and beforehand rather than after the first incident. What follows is our own practice and a list of points you can walk through with that person.
The one question that simplifies almost everything
Before you think about contracts and server locations, ask yourself a single question: which fields does this step actually need?
For us that question has solved more data protection problems than any tool. An example from support at nano.
A customer writes that her parcel has not arrived. The naive implementation sends the entire email plus the full order record to the language model. So name, address, phone number, payment method, order history.
What the step actually needs is the text of the enquiry and the tracking status. Nothing else. The name gets added when the answer is assembled, and that happens in our own system rather than at the model provider.
This is data minimisation, and it is the cheapest data protection there is. Less data means less risk, less to explain, and lower costs on the side, because shorter requests cost less.
Which data never leaves our house
We have a fixed list. It lives in preprocessing, in the step that prepares an enquiry before it goes to the model.
- Payment data. Card details, IBAN, payment provider references. Never.
- Full addresses. A postcode is enough for a status enquiry, and often not even that.
- Dates of birth and customer account passwords. Never in any case.
- Free text from complaints with a health angle. In cosmetics that comes up more often than you would think. Those cases go straight to a human.
Everything else we replace with placeholders before sending. "Mert Gönensay, Musterstraße 3" becomes "[CUSTOMER]". The model works with the placeholder, our system puts the real value back afterwards. What this pre-sorting looks like technically is in Pre-sorting support emails with AI.
Data processing agreements: the contract you need
When a service provider processes personal data on your behalf, that requires a contract. GDPR calls it a data processing agreement; in Germany it is known as the AVV, short for Auftragsverarbeitungsvertrag.
That applies to the model provider just as much as to your shop, your newsletter service or your fulfilment partner. AI is no special case here, it is one more recipient.
In practice that means:
- For every AI service that sees customer data, you need this contract. The big providers make it available, usually in your account under legal or compliance.
- The service has to go into your record of processing activities. That is the list stating who processes which data for what purpose in your company.
- Your shop's privacy policy has to reflect the use. One sentence nobody cares about until it is missing.
The point almost everybody overlooks: if you use an automation tool like n8n, that is a processor too, as soon as it is hosted. With a self-hosted installation the contract falls away, because the data never leaves your house.
Hosting location: a decision, not a detail
Where the data sits is the question with the biggest leverage. And it usually gets decided in passing, through the choice of tool.
Three routes, as we see them:
| Setup | Where the data sits | Effort | What we use it for |
|---|---|---|---|
| Cloud tool, US provider | at the provider, often outside the EU | low | internal copy with no customer reference |
| Cloud tool with an EU region | in the EU, at the provider | medium | support with placeholders |
| Own server | with us | high | anything with real customer data |
Our n8n runs on our own server in Germany. This is a practical choice rather than an ideological one. It removes a whole stack of questions: the workflow itself, the intermediate results and the logs never leave our house. Only the one step that calls a language model goes out, and that step only ever sees placeholders.
We worked through the trade-off between your own server and the cloud in n8n self-hosting or cloud, with costs and effort.
Training: your customer conversations do not belong in a model
This is the point that cost us the longest discussion. Some providers use inputs to improve their models, some do not, some only on certain plans.
Our rule is simple: if a service does not clearly commit that inputs are excluded from training, it gets no customer data. Full stop. For internal experiments it stays allowed, for support it does not.
That commitment usually sits in the business terms rather than the consumer terms. Free access and API access are often governed differently. It is a difference that costs real money, which is why it gets overlooked so happily.
Deletion periods: automation creates copies
This is the point that surprised us most.
An automation makes copies constantly. The trigger stores the raw data. The intermediate step stores the result. The log stores both, so you can trace errors. One support email quickly turns into four places where data sits.
If you have deletion periods sorted in your shop and not in your automation tool, you are not deleting. You are deleting the most visible of four copies.
What we did:
- Execution data in n8n is removed automatically after 30 days. That is a setting, not a project.
- Logs with customer references are deleted after 90 days. What we need permanently are metrics with no personal reference, so "number of status enquiries" rather than "who asked".
- We removed two caches we had set up for speed. They saved seconds and created a fifth copy.
Access requests: can you answer the question within an hour?
A customer is entitled to know which of her data you process. That is not an edge case, it is everyday business as soon as the shop grows.
The test I recommend to everyone: take a real email address from your shop and try to name, within one hour, every place where data on it sits. Shop, newsletter, support inbox, automation tool, logs, analytics.
On our first attempt we forgot two places. That is exactly what the test is for. Anyone who cannot answer the question within an hour has a tidiness problem that becomes a data protection problem eventually.
Employee data is the blind spot
Everybody talks about customer data. Almost nobody talks about their own people.
As soon as AI runs alongside operations, data about employees appears. Who handled which case, for how long, with what correction rate. That is performance data, and it is particularly sensitive. In companies with a works council, co-determination comes on top.
Our line: we evaluate at the process level, not at the person level. We know how many drafts were corrected. We do not build any analysis showing who corrected how many. We do not need it to improve the agent, and for anything else we do not want it.
Second point: if employees use an AI tool themselves, what they are allowed to paste into it has to be governed. With us that fits on one page. One page that gets read is worth more than twenty that do not.
The limits
So that nobody gets the wrong impression here.
- This article does not replace a legal review. It is a list of points, not an assessment of your case. For the assessment you need a lawyer or a data protection officer.
- The legal situation is moving. A lot is changing around AI right now. What looks settled today can look different in a year. Plan for revisions.
- Data minimisation has a price. A model that sees less sometimes answers worse. We have cases where the agent has to ask a follow-up question because it lacks context. We accept that.
- There is no state called "done". Every new workflow is a new data flow. The questions above come up again every time, though faster.
Conclusion
Data protection is no obstacle to using AI. It is an order of operations.
First clarify which fields a step actually needs. Then decide where the data sits. Then follow up with the contracts and the record of processing. Then set deletion periods, everywhere, not only in the shop. Work in that order and you end up with less effort than someone who builds first and repairs afterwards.
For us this pass took two days, spread over two weeks. The most expensive part was cleaning up the copies, which nobody had on their radar beforehand. If you want to see what a setup like this looks like in support specifically, that is in the guide to customer service automation. And what the whole thing costs, we work through in What automation really costs.
Want to set this up properly for your shop before you build? Get in touch at Flowhouse, we will go through the list with you. The legal assessment we deliberately leave to your lawyer.