GDPR and Support AI: Custom Identifiers Count
Your support team uses AI to draft replies and review tickets. Productivity is up. Then your DPO checks the setup.
A typical customer message contains a name, an email address, and an order ID. The name and email are personal data. So is the order ID. It links to Sarah Johnson in your order database. An AI vendor can cross-reference it. If training data leaks, the ID can re-identify her.
Sending any of these to an external AI vendor without a legal basis is a GDPR violation.
Why Order IDs Are Personal Data
GDPR Article 4 defines personal data broadly. The term covers all information relating to an identified or identifiable person. Identifiability includes indirect identification by reference to an identifier.
An order ID like ORD-4521893 is an indirect identifier. Alone, it does not name Sarah Johnson. Paired with your order database, it does.
GDPR Article 4(5) covers pseudonymization. Order IDs are pseudonyms. They need a second source to reveal the person behind them. When you send one to an external AI vendor, you are sharing personal data. A legal basis and a Data Processing Agreement are required.
The vendor may not hold your database. That does not end your duty. You shared personal data. GDPR still applies.
The Standard Anonymization Gap
Support teams often deploy PII detection for GDPR compliance. Standard tools remove common entity types.
Standard detection catches customer names, email addresses, phone numbers, and credit card numbers. These all pass.
Standard detection does not catch order IDs in ORD-XXXXXXX format. It misses account numbers, ticket references, internal user IDs, and subscription IDs. These fail.
The result looks like this: "Hi, I'm [PERSON_1] and my order ORD-4521893 hasn't arrived yet. Please email me at [EMAIL_1]."
The order ID is still there. Anyone with CRM access can find Sarah Johnson at once. The anonymization is incomplete. This is the compliance gap.
Chrome Extension: Detection at the Browser
Support agents who use Claude, ChatGPT, or Gemini work in their browser. The Chrome Extension stops custom identifiers from leaving.
Here is how it works. The agent pastes a customer message into the AI tool. The extension sees that the target is an AI platform. It removes standard PII. It then applies custom patterns. These match your order ID format, your account number format, and any other custom identifier your team uses. The agent sees only the clean message. The raw data never reaches the AI.
The compliance team sets the custom patterns once. They share a preset with all agents. Agents do not need to manage this. They paste the message. The extension handles the rest.
MCP Server: Detection at the API Layer
Some platforms call AI through APIs. Intercom uses AI to draft replies. Zendesk uses AI for response suggestions. The MCP Server adds anonymization at the API layer for these setups.
Here is the flow. A customer message arrives in the support platform. It passes through the MCP endpoint before reaching the AI. The endpoint removes standard and custom entities. The clean message goes to the AI. The AI returns a reply. No personal data was shared. The agent then reads and edits the reply in the support platform.
Agents see no change in how they work. The process looks the same. Custom entities are set once in the MCP config. All API calls use full entity detection from that point on.
DPO Implementation Checklist
1. Map all data flows to AI.
List where agents use AI. Include browser tools, API-based tools, and file uploads.
2. List all identifier types in customer messages.
Standard PII — names, emails, phones — is covered by default. Custom identifiers — order IDs, ticket references, account numbers — need custom patterns.
3. Add custom entity patterns.
Define each format. Test it on sample messages. Save it to the team preset.
4. Deploy at the right layer.
Browser-based AI: use the Chrome Extension with a shared preset. API-integrated AI: use the MCP Server or API-level preprocessing.
5. Update your ROPA.
Record that support AI uses automated anonymization. List the custom identifier types covered. This is your technical safeguard documentation.
6. Test the setup.
Run sample messages with all identifier types. Check that nothing reaches the AI. See the legal compliance guide for document templates.
SaaS Support Team: A Practical Example
A SaaS support team uses Claude through an internal AI platform. Customer messages include names, emails, order IDs, and subscription IDs. Some feature flag names carry internal identifiers too.
Before GDPR review: All content went to the AI. Order and subscription IDs were included.
After custom entity detection:
ORD-XXXXXXX and SUB-XXXXXXXX were added as custom entities. The Chrome Extension was deployed with a shared preset. The DPO ran tests and confirmed all identifiers were removed before AI processing.
Agent workflow change: None. Agents work the same way. The anonymization runs in the background. The DPO has a documented safeguard on file.
Conclusion
GDPR-compliant support AI does more than strip names and emails. Order IDs, account numbers, and ticket references are personal data. Standard tools miss them. Custom entity configuration closes the gap.
The steps are simple. Define your identifier formats. Test them against sample messages. Deploy to the team. A DPO can complete this in an afternoon. After that, all customer data is removed before it reaches external AI systems. The compliance benefit holds from that point on.