Using AI with less customer-data exposure: tokenisation in practice

A frequent concern is where customer information goes when AI summarises orders, checks invoices or answers enquiries. A model needs relevant context, but many tasks need structure rather than real identities. Tokenisation preserves relationships while reducing exposed identifiers.

What reaches the provider?#

An assistant retrieves ERP or CRM records, sends selected context to a model and receives an answer or proposed next action. Without filtering, that context can include names, emails, addresses and account details. Training exclusions do not remove the privacy significance of the transfer itself.

A gateway between system and model#

A Privacy Gateway filters system responses before they reach the model. Each field receives a rule:

For example, a source record:

{
  "name": "Example AG",
  "mail": "purchasing@example.ch",
  "phone": "+41 44 123 45 67",
  "city": "Zurich",
  "postcode": "8005",
  "total_net": 12480.00
}

can become:

{
  "name": "Customer_8f31",
  "mail": "[REDACTED_EMAIL]",
  "phone": "[REDACTED_PHONE]",
  "city": "Zurich",
  "postcode": "80**",
  "total_net": 12480.00
}

The model can still compare orders and amounts. Your infrastructure holds the mapping to the real customer.

Why stable tokens help#

Removing every identifier can make multiple customers indistinguishable. A session-stable token lets the model refer to the same customer consistently. Your system restores authorised identifiers before displaying a response or carrying out a permitted action.

Scan free text too#

Field names are insufficient: addresses, names and IBANs can appear in descriptions, subjects and templates. A second layer scans content for relevant patterns. Rules should reflect the process and tolerate false positives appropriately. Pattern matching is imperfect and requires representative tests.

Audit transformations#

Log the tool, timestamp, fields and transformation decisions. Avoid placing sensitive raw values in the log itself. This supports the practical question: exactly which information was sent?

Legal and practical limits#

• Tokenisation is pseudonymisation, not anonymisation. Mappings and residual context can keep data identifiable.
• Processing contracts, notices, transfer safeguards and documented purposes remain relevant.
• Some tasks require identity and need explicit, controlled exceptions.
• Writes must resolve tokens to real IDs within the controlled layer.
• No scanner guarantees perfect removal. Combine field rules, content scanning, tests and audit review.

The FADP checklist explains organisational foundations.

Our approach#

Configure rules per customer and role, independent of ERP and model, as part of ERP and API integration. Our interactive privacy demo compares fictitious raw data with the filtered model context. Build protection into the flow from the beginning and verify actual behaviour.