Skip to content
Privacy 6 min read · September 2026

How Teamdock keeps customer data out of AI prompts

When Teamdock drafts a reply to a customer, an AI provider reads the question. That is how these features work. What it doesn't need to read is who the customer is. Here is what we send, what we replace first, and what we can't promise.

What leaves your workspace, and when

Your workspace runs on its own server space in Germany. Data only goes to an AI provider (Mistral, on models hosted in the EU, through a gateway Teamdock runs for your workspace) when you use an AI feature. These are the features that can involve customer data, and what happens to it:

FeatureWhat it readsPersonal data
Ticket analysis and reply draftsThe message, the customer's record and their recent ordersReplaced, then put back in the draft
The assistantYour question and what its tools look up (orders, customers)Replaced, then put back in the answer and in tool lookups
Order from an e-mailThe forwarded e-mailReplaced, then put back in the order fields
FAQ suggestionsClosed ticketsReplaced, and removed from the suggestion
Product copy and translationsProduct fields and your notesNothing to replace: no customer data

Placeholders instead of people

Before a request leaves the workspace, Teamdock looks for personal data and swaps each value for a placeholder: names, e-mail addresses, phone numbers, street addresses, postcodes, company names, IBAN and VAT numbers, and links. This is the actual output for a typical e-mail (the person is made up):

In your workspace
From: Jan de Vries <jan.devries@example.nl>
Subject: Question about order 10482

My order 10482 hasn't arrived. Can you send it to
Dorpsstraat 12, 1234 AB Utrecht? Call me on 06 12345678.

Kind regards,
Jan de Vries
What the AI provider receives
From: [NAME_1] de [NAME_2] <[EMAIL_1]>
Subject: Question about order 10482

My order 10482 hasn't arrived. Can you send it to
[ADDRESS_1], [POSTCODE_1] Utrecht? Call me on [PHONE_1].

Kind regards,
[NAME_1] de [NAME_2]

Three details make this work in practice:

  • The same value always gets the same placeholder. The model can still tell that the sender and the customer on order 10482 are the same person, or that a message mentions two different addresses. It just can't tell who they are.
  • Structured data is replaced by field, not by guessing. When the request includes the customer's record from your shop, the name, e-mail, phone, address and company fields are always replaced, whatever they contain. The names found there are then also replaced wherever they appear in the message text.
  • The real values come back inside your workspace. The model writes "Dear [NAME_1]", and Teamdock turns that into "Dear Jan" before you see the draft. The list that links placeholders to real values stays in the workspace's memory for that one request. It is never sent anywhere, and it is not stored.

Order numbers, amounts, dates, products and the town or city are not replaced. Without them the AI can't answer "where is my order?", and on their own they don't identify anyone.

FAQ suggestions are the exception

Teamdock can suggest new FAQ entries based on questions your team has answered. An FAQ is public text, so a customer's details should never appear in it, not even correctly. For this feature, placeholders in the answer are deleted instead of filled back in.

What this doesn't catch

The replacement is automatic. It works from patterns, from the fields in your shop's records, and from where names usually appear (greetings, sign-offs, the sender line). That catches most personal data in a typical support e-mail. It does not catch everything:

A name that appears nowhere else

"My neighbour Kees took the parcel in." Kees is not the sender, not in a field and not in a greeting, so nothing marks him as a name.

Address formats we don't recognise yet

Street addresses are matched on Dutch patterns ("Dorpsstraat 12"). "12 rue de la Paix" or "Hauptstr. 5" can get through.

What the message is about

The town or city, the products, and the question itself are sent as written, because the AI needs them. A complaint about a medical product still says so.

Your own staff

The assistant is told who is signed in, so that "send it to me" works.

Pseudonymised, not anonymous

We call this pseudonymisation, and not anonymisation, on purpose. Under the GDPR, data is pseudonymised when it can no longer be linked to a person without extra information that is kept separately (Article 4(5)). We hold that extra information: it's how the draft gets the customer's name back. Recital 26 is clear that pseudonymised data is still personal data.

That is why nothing else changes on paper. The AI providers are still listed as sub-processors in Annex A of our data processing agreement, transfers outside the EU still run under Standard Contractual Clauses, and the replacement is described as a security measure in Annex B. What does change is how much a provider can see about your customers: in a normal request, their name, e-mail address, phone number and street address no longer reach it at all.

What you control

  • Where AI runs. On models hosted in the EU, through your workspace's own gateway. There are no provider keys to enter.
  • What you add. Two optional services outside the EU, Claude and Jev, stay off until an administrator switches them on under Settings → AI.
  • Per ticket. Staff can switch AI analysis off for a single ticket.
  • What gets sent to customers. A draft is a draft. Staff read and approve every AI-written reply before it goes out.

The full list of companies that process data for Teamdock, and where, is on our security page.

Questions about your data?

Ask us before you sign up. We'll tell you exactly what is sent where, including for features you're not sure you'll use.