← All projects

Case study · Privacy & pseudonymisation

Answering customer enquiries with AI without disclosing personal data

A privacy gateway replaces names, numbers and addresses with placeholders before an email reaches the AI, and puts them back into the reply. The AI writes the draft without knowing who it is about.

Area
Privacy & secure operations
Scenario
Customer service of a Swiss SME (demo data)
Technology
Node.js, Claude API, AES-256-GCM
Deployment
Trust zone in Switzerland, approval by staff
Four columns show a customer email with name, age, address, religion and phone number, the same email with placeholders such as [FEMALE_1] and [PHONE_1], the AI reply with placeholders and the reply draft translated back. Below: 8 personal data items detected, leak check passed, 2 replaced, 0 errors, draft ready for approval.
The gateway in four steps: incoming email, what the AI sees, its reply with placeholders and the draft translated back. Proof of concept with demo data.

Starting point

In the reference scenario, the customer service team of a Swiss SME receives emails every day that an AI is meant to pre-sort and answer. These messages contain names, phone and AHV (social security) numbers, IBANs and addresses, and time and again health information or religious reasons for a preferred appointment. Swiss data protection law requires data minimisation and privacy by design, and particularly sensitive data should not reach an AI provider unnecessarily. At the same time, the reply must still go correctly to the right person in the end.

The solution

andyou built a privacy gateway that sits between the mailbox and the AI. It detects personal data in two stages: patterns with check digits for AHV numbers, IBANs and Swiss phone numbers, plus rules for names from salutation, signature and sender. All spellings of a person get the same placeholder, and the gender is kept for the salutation. Age becomes a range; religion and health reach the AI only as a category. The mapping table is stored encrypted in Switzerland and expires. After the AI, the gateway puts the original values back, even when the reply is streamed.

Flow: the mailbox or ticket system passes the email with personal data to the Swiss trust zone (detect, replace, leak check, mapping table with AES-256, translate back, check). Only placeholders go to the AI model (Claude, Azure CH or own model); the draft with original values goes to an employee who reviews and sends it.
Architecture: detection, mapping table and translation back stay in the Swiss trust zone. The AI only sees placeholders.
Table per data type: name becomes [FEMALE_1], phone and email [PHONE_1], AHV and IBAN [AHV_1] with check digit, address [ADDRESS_1], age 37 becomes 30–39 years, religion and health [RELIGION_1]; amounts and dates stay unchanged.
Handling per data type: pseudonymise, generalise or send only as a category.

Security & controls

Before a text goes to the AI, a second, independent control checks whether an original value or a number is still in it. If so, nothing is sent. On the way back, the gateway detects when the AI invents a placeholder or a salutation does not match the gender, and flags the draft for review. Quoted older messages are not sent at all. Only data types and counts are logged, never plain text. Every draft is approved by an employee.

Four controls: leak check before sending (passed), invented placeholders (for review), wrong salutation (for review) and an audit log with types and counts only (active).
Four controls secure the way there and back.
An AI reply with altered placeholders is translated back: name and phone number are filled in, the invented placeholder [FEMALE_7] stays flagged and the draft goes for review.
Translating back tolerates variations by the AI and reports anything unusual.

Result and cost

In a test with ten Swiss emails from insurance, home care, HR, fiduciary, municipality, bank, retail, administration and a law firm, the gateway detected 65 of 66 personal data items. It missed one name without a salutation in a deliberately difficult edge case; an additional local detection model is planned for this in the project. All placeholders were translated back correctly. Detection needs no language model, runs in well under a millisecond per email and adds no AI cost. 13 automated tests cover detection, encryption, streaming and approval.

65 of 66 personal data items detected (98.5 per cent): name 20 of 21, address and town 14 of 14, phone 7 of 7, health 6 of 6, religion 4 of 4, AHV and IBAN 6 of 6, email 3 of 3, age and date of birth 5 of 5.
Personal data detected per type in ten test emails, measured in the proof of concept (demo data).
Overhead per email: processing time under 1 ms (median 0.05 ms), AI cost CHF 0, text length minus 5 per cent because placeholders are shorter.
Gateway overhead per email, measured in the proof of concept on a laptop.

Technology in brief

The gateway is a lean Node.js application without external services for detection. The mapping table is encrypted with AES-256-GCM and expires after a set time. Claude is connected as the AI through the Anthropic API; depending on the risk class, a model in Switzerland or on your own infrastructure can be used. For production, a local detection model for names, the connection to Microsoft 365 or the ticket system and a key in key management are added.

  • Node.js
  • Claude API
  • AES-256-GCM
  • Regex + check digits
  • Streaming
  • revFADP
  • Swiss hosting
  • Human approval

Protect customer data and still use AI?

Using your sample emails, we check which data needs which protection and show you in a proof of concept.

Let’s talk about your project