LLM Data Anonymizer
Mask the sensitive parts of a text before it leaves your premises.
What it does
Reads a text from memory, asks an AI to identify sensitive content (names, emails, phone numbers, addresses, …), and writes back a version where each sensitive item has been replaced by a placeholder. The mapping between original values and placeholders is preserved so that a later step can restore them — see LLM Data Deanonymizer.
The classic pattern is anonymize → process → deanonymize: customer data goes into the anonymizer, the anonymized text goes to an external AI, the AI's response gets deanonymized, the result is shown to the user. The external AI never sees the personal data.
What you configure
| Field | What it controls | Required | Notes |
|---|---|---|---|
| Input text (memory input) | The text to anonymize. | required | Comes from a previous step. |
| Output text (memory output) | Where the anonymized version is written. | required | Use this as the input for the next step. |
| Anonymize names | Replace personal names (e.g. "John Doe") with placeholders. | optional | On by default. |
| Anonymize emails | Replace email addresses. | optional | On by default. |
| Anonymize phone numbers | Replace phone numbers. | optional | On by default. |
| Anonymize postal addresses | Replace street/city/postcode combinations. | optional | On by default. |
| Anonymize locations | Replace places (cities, countries). | optional | Off by default — turn on only when even places are sensitive. |
| Anonymize social handles | Replace @-mentions and social links. | optional | Off by default. |
| Custom pattern description | Plain-language description of anything else to mask. | optional | Example: "Replace any internal project codename like 'Project Aurora' with a placeholder." |
📷 SCREENSHOT: The Anonymizer step with all toggles visible and a custom pattern description filled in.
Example scenario
Customer support triage that uses an external AI. A workflow receives a ticket containing the customer's name and email. The anonymizer replaces both. The external AI categorizes the (anonymized) text. A later deanonymizer step restores the original values so that the agent's response can address the customer by name.
Recommendations
- ✅ Keep the mapping (the link between placeholder and original value) inside the workflow's memory. The platform does this automatically — you do not have to wire it up.
- ✅ Use this in combination with LLM Data Deanonymizer. Anonymizing without later restoring is rarely what you want.
- ✅ Add a custom pattern description for anything domain-specific. Internal codenames, account numbers, product IDs — none of these are caught by default.
- ⚠️ The anonymizer relies on an AI model. It is very good, but not perfect. For regulated data, treat it as a strong assist, not a guarantee.
- ❌ Do not use the anonymizer in place of proper access controls. It is one layer in a defense-in-depth strategy.
What to do next
- The reverse: LLM Data Deanonymizer.
- The bigger picture: Best Practices → Pseudonymization.