PII redaction — strip personal data from stored messages

When on, Wilow runs a regex-based redactor over every user message before it's persisted to the database. Emails, phone numbers, and credit-card-shaped digit sequences get replaced with neutral placeholders: {{email}}, {{phone}}, {{card}}.

One thing this setting does not control: what the language model sees. The model always receives the redacted form of the message — on the current turn and in conversation history — regardless of this setting. Raw contact data never enters a model prompt. The setting only decides whether the stored transcript keeps the original or the placeholder. The raw text is used in-process for lead-capture extraction, then discarded.

Why it's on by default

Transcripts are for review — you want to see what the visitor asked, not who they are. A transcript that contains raw credit-card numbers is a compliance risk; the same transcript with [REDACTED_CARD] is audit-safe.

Lead records are separate from transcripts. They keep the contact details — you need the email to actually respond. The redaction only affects the conversation archive, not your leads.

When to turn it off

Rarely. One case: you run a support business where the whole point is to resolve issues tied to account numbers, IBANs, or phone IDs. Without that data in the transcript, reviewing conversations is useless. If you disable it, make sure your data-retention policy accounts for personal data in archived chats.

What it catches

• Email addresses (standard format)
• Phone numbers (international +… and common national formats, 8–15 digits)
• Credit-card numbers (13–19 digits with or without spaces/dashes, validated with a Luhn check so random digit strings aren't false-flagged)

What it doesn't catch

• IBANs and other bank account formats.
• Names typed free-form ("This is John Smith from Acme…"). Names are context-dependent; a regex doesn't know the difference between "John" the person and "John" the brand.
• Physical addresses. Too variable to pattern-match reliably without false positives.
• Ad-hoc ID strings your own business uses (order numbers, ticket IDs). If those are sensitive, talk to us — we can add a custom rule for your account.