Masking shrinks the damage, not the duty. Names, accounts and phone numbers stay in house, but the legal basis and the data processing agreement apply exactly as before.
A complaint leaves the building with bank details
A prompt is an export. Paste a customer email into a chat window, ask for a draft reply, and in the same keystroke you hand a vendor the name, the customer number, the phone number and the bank account, on servers whose retention periods and review processes your company does not control.
Most firms then pick one of two extremes. Either AI is banned outright in customer contact, which pushes the tools into staff members' private accounts, or everyone looks away, which produces the same leak without a record. There is a third route: four text patterns replace the sensitive parts before you hit send, the model works on placeholders, and the finished reply is filled back in on your own machine.
Four patterns cover four kinds of data
Names follow no pattern. They come from an export of first and last names out of your customer database, one name per line, replaced longest line first, because otherwise the entry "Berger" cuts the name "Berger-Schmitt" in half and leaves a fragment behind.
Everything else is text search. These four regular expressions, search patterns that describe classes of characters instead of fixed letters, cover email address, IBAN, phone number and customer number, which together account for four of the five kinds of data a service request ever holds:
- Email address: [\w.+-]+@[\w-]+(?:\.[\w-]+)+
- IBAN: \b[A-Z]{2}\d{2}(?:\s?[A-Z0-9]){10,30}\b
- Phone number: (?:\+49|0)[\d\s/()-]{8,}\d
- Customer number in the form KD-12345: \bKD-\d{4,}\b
A lookup table makes the masking reversible
Every hit gets a number. The name becomes [NAME_1], the account becomes [IBAN_1], and the same value keeps the same placeholder throughout a case, because otherwise the model loses the link between sender, signature and callback number and invents three separate people.
The table stays in memory. In Python it is two functions and roughly 25 lines: the first replaces the name list and then the four patterns, the second swaps the placeholders in the returned draft back for the originals. To take the vendor out of the chain altogether, run the model locally on your own machine instead. To see the flow on one of your own texts first, open our free prompt masking tool in the browser; it runs exactly these patterns and sends nothing to a server.
One run shows what actually goes out
Input, with invented data: "Dear Ms Berger, regarding your complaint KD-10482: the refund goes to DE99 1234 5678 9012 3456 78. Questions on 0331 1234567. Mr Özdemir in the workshop has confirmed the damage."
This is what reaches the model: "Dear Ms [NAME_1], regarding your complaint [KDNR_1]: the refund goes to [IBAN_1]. Questions on [TEL_1]. Mr Özdemir in the workshop has confirmed the damage." The sender address in the message header goes through the first pattern in exactly the same way.
This comes back and is filled in locally: "Dear Ms Berger, we have reviewed complaint KD-10482 and will refund the amount to DE99 1234 5678 9012 3456 78." The draft is complete, and neither the account nor the phone number ever left the building.
The colleague in the subordinate clause survives
One name slipped through. Mr Özdemir in the workshop stands untouched in the masked version, because he is a colleague rather than a customer and therefore never made it onto the name list, and this is precisely the gap described by the German data protection authorities in their guidance of 6 May 2024: stripping names and addresses from an input is regularly not enough to avoid submitting personal data.
The second mistake was ours. In our own test run, an IBAN pattern that counts groups of four left the last two digits of a German IBAN sitting in the text; the pattern above therefore counts characters rather than groups. Run the whole flow across 20 real cases and read every masked version line by line: whatever surfaces belongs on the name list or in a fifth pattern for file numbers, staff numbers or licence plates.
Masking shrinks the damage, not the duty
The technique is called pseudonymisation. The GDPR defines it in Article 4(5) as processing in which the data can no longer be attributed to a person without the use of additional information, and in this workflow that additional information is simply your lookup table in memory.
Recital 26 draws the conclusion: data that can be attributed to a person by use of such additional information still counts as information about an identifiable person. Legal basis, transparency obligations and the data processing agreement all stay exactly where they were before you masked anything.
What changes is the blast radius. If something at the vendor is exposed or stored badly, what sits there is [NAME_1] and [IBAN_1] rather than a name and an account number. For half an hour of work, that is a decent exchange rate.
The pricing tier decides more than the script
No script answers the training question. The German data protection authorities call applications preferable when they do not use input and output data for training purposes, and whether that holds is written in the vendor's terms and in the tier you booked, never in your code.
OpenAI states for its API that data is not used for training unless the customer explicitly opts in; abuse monitoring logs are kept, according to the vendor, for up to 30 days as a rule, while zero data retention, meaning operation with no storage at all, and processing outside the United States both require approval by OpenAI.
Google draws a sharper line in the Gemini API terms: on the free tier, Google uses submitted content and responses to provide and improve its products, with human review possible; on the paid tier it does not, and logging is time limited. One house rule follows: customer data never touches a free tier, masked or otherwise.
Yes for daily customer texts, no for personnel files
We would set this up anywhere customer texts pass through a cloud model every day: support, accounting, order processing. Half an hour buys the first version, the rest of half a day buys the run across 20 real cases, and after that only the name list grows, because the four patterns hold steady.
Two situations argue against it. If AI at your company only writes general copy with no customer reference, there is nothing to mask; for health data, job applications and personnel files, masking falls short, because identity follows from the context there, so the model belongs on your own hardware or the task stays away from AI.
Four questions come up every time
Is find and replace in Word enough? For a single letter, yes. By the tenth case someone forgets, and that is exactly when the mistake happens.
Can the model scramble the placeholders? It happens. Because the restore function only replaces markers it knows, a scrambled placeholder stays visible in the draft; anyone who reads the draft before sending spots it immediately.
Does the procedure have to be documented? Record it as a technical measure in your data protection documentation, with a date and the kinds of data it covers. The authorities explicitly name training and written guidance for staff, and the same briefing counts towards the AI literacy duty under Article 4 of the AI Act.
What about attachments? The procedure only reaches text. A PDF has to be read out first, along the lines of the flow for preparing incoming invoices with AI.
This week you write the first version
Four half days cover the first pass:
- Day 1: export first and last names from the customer database as a text file, one name per line, sorted longest first.
- Day 2: put the four patterns and the two functions into one file, and keep the lookup table in memory only, never on disk.
- Day 3: run 20 real cases through it, read every masked version in full, and add each gap to the name list or to a fifth pattern.
- Day 4: check in your contract that inputs and outputs stay out of training, and write a one page usage rule: what gets masked and what never goes into the tool at all.
- If it stays unclear whether masking is enough for your documents, we work through it in a free first call; the wider frame sits under services for internal AI workflows.
Sources and status
Sources last checked: 20 September 2026. Vendor statements and our own reading of them are kept apart in the text.
- DSGVO: Begriffsbestimmungen und Erwägungsgrund 26
- Datenschutzkonferenz: Künstliche Intelligenz und Datenschutz
- OpenAI: Umgang mit API-Daten
- Google: Nutzungsbedingungen der Gemini-API
Corrections: [email protected].
What does this mean for your business?
We go through one concrete workflow with you and check whether AI can help.
Book a free first call →