E-commerce

AI Support and GDPR: Data Residency for an EU Customer Base

September 2026 · ISTRALLEN Team

The question is where the customer's words go

For an EU customer base, AI support and GDPR data residency come down to one question asked at every step: where does the customer's message travel. A support message is personal data, and it leaves your own database the moment it is sent to a model. This is general orientation, not legal advice — a DPO or privacy counsel is the right source for what applies to you.

The path is mechanical and has to be mapped before anything else: a customer message enters through chat or voice infrastructure, then the model call and the vector store, using regional or EU-based processing where a provider offers it, with the vector index and database kept in the same region — every hop here is a processor, documented with its own agreement, and some are transfers outside the EEA that need a transfer mechanism. Redaction runs before the transcript is ever written, not as a cleanup pass afterward — a filter sitting between the live conversation and the transcript store strips card numbers, national identifiers, and health terms before they land in storage — the model itself still sees the live message to do its job; minimisation applies to what gets written down, not to what the conversation needed to happen. What reaches the transcript store — Postgres and logs, kept in the same region — carries a retention period that gets enforced, not left to grow by accident, and it stays in scope for data-subject access and erasure requests exactly like the order record does.

Map the data path first

Before choosing tools, draw the path: customer text enters through chat or voice infrastructure, goes to the model API, is matched against your vector store, is written to Postgres, and is captured in logs. Each hop is a processor, and some may be transfers outside the EEA. You cannot make residency decisions about a flow you have not mapped.

Data residency for the model call

Where a provider offers regional or EU-based processing for the model endpoint, that is the option to use for an EU customer base. Keep the datastores — the vector index, the transactional database, the transcript store — in the same region, and be precise about what, if anything, still leaves it.

Sub-processors and contracts

Every hop belongs in your records of processing, with a data processing agreement in place and an appropriate transfer mechanism wherever data leaves the EEA. The model provider is a sub-processor like any hosting or messaging vendor, and its terms need the same review.

Data minimisation at the transcript boundary

Redact payment details and special-category data before they reach the transcript store, and do not log fields you do not need. This is the same discipline as keeping card numbers out of a voice transcript — the logging that our support agent project relies on for auditability has to be designed with minimisation as a constraint, not bolted on later.

Retention is a decision, not a default

Transcripts should not live forever by accident. Set a retention period, justify it, and delete on that schedule. An unbounded conversation archive is a growing liability with no operational benefit past a certain age.

Data-subject rights reach the logs too

Access and erasure requests have to cover conversation history, not just the order record. If your process can export and delete a customer's orders but not their support transcripts, the process is incomplete.

Where redaction happens in the flow

Redaction has to run before the transcript is written, not as a cleanup job afterwards, because a cleanup job means the raw data sat in storage in the meantime. The practical pattern is a filter on the path between the live conversation and the transcript store that strips known-sensitive patterns — card numbers, national identifiers, health terms in a pharmacy context — so what lands in the log is already minimised.

Purpose limitation on transcripts

Support conversations are collected to provide support and, narrowly, to review quality. Using them to train a model is a different purpose that needs its own basis and notice. Verify the provider's API data-use terms — most do not train on API traffic by default, but confirm it rather than assume.

Where this stops being right

This is orientation, not a compliance programme. Involve a DPO or privacy counsel before launch; the specifics decide your obligations.
Transfer mechanisms and adequacy decisions change — what is acceptable this year may need revisiting; build the review in.
Sector rules can add requirements on top of GDPR for regulated retail categories — check whether any apply to your catalog.

FAQ

Does using an LLM API for support mean transferring EU data abroad? It can, depending on where the provider processes the request. Use regional or EU processing options where offered, and document what still leaves the EEA.

What has to be in scope for a data-subject request? Everything — order records and support conversation history. An erasure process that misses transcripts is incomplete.

Can support transcripts be used to improve the model? Only with a proper basis and notice; it is a separate purpose from providing support. Check the provider's terms — API traffic is usually not used for training, but confirm it.

ISTRALLEN builds support agents for EU customer bases with a mapped data path, in-region storage, and minimisation at the transcript boundary — see AI for E-commerce.

See it in production

AI for E-commerce → Support agent case study →

← All articles