Skip to content
Chatbotscape
Editorial flat-vector illustration for How to Redact Personal Data Before Your Chatbot Sends It to an LLM
Published 8 min read

How to Redact Personal Data Before Your Chatbot Sends It to an LLM

Quick answer: Put a small filter in front of the model call. List the kinds of personal data your customers actually type, replace each one with a labeled placeholder, restore the real values only in the reply your own server sends back, and keep the raw text out of logs. Then measure on 100 real messages how much still slips through, because no detector finds everything.

Step 1: List the personal data your chatbot really sees

Start from real conversations, not a textbook list. Pull 100 recent messages (with permission and under your own access rules) and mark every item that identifies a person or could be used to reach them: names, emails, phone numbers, street addresses, order and account numbers, dates of birth, payment details. Add anything unique to your business, such as a booking reference format.

Then decide for each kind whether the model needs it at all. A refund bot needs to know that an order number exists, but not whose name is on it. Data you never send is safer than data you send and mask. The PII handling guide covers the wider question of what to collect in the first place.

Step 2: Choose placeholders the model can still reason about

Replace, do not delete. A label that keeps the type lets the model understand the sentence.

Original: "Hi, I'm Dana Ortiz, my email is dana.ortiz@example.com and order 48213 never arrived."

Redacted: "Hi, I'm <PERSON_1>, my email is <EMAIL_1> and order <ORDER_1> never arrived."

Number the labels (<PERSON_1>, <PERSON_2>) so the model can tell two people apart in one conversation. Presidio's anonymizer documentation lists several operators: replace (by default with the entity type, such as <PHONE_NUMBER>), redact, mask, hash, encrypt, keep and custom. For a chatbot, replace with numbered labels is the usual choice; plain redact makes sentences hard to follow and hash gives the model nothing to read.

Step 3: Add a detector

Detection is the hard part, and the best setups combine methods. Presidio's documentation names the main ones: named entity recognition, regular expressions, rules, checksum validation and context from nearby words. Patterns work well for emails and card numbers, which have fixed shapes. Names and addresses need a language model or an entity-recognition step because they have no fixed shape.

You can build on an open-source library, use a cloud provider's sensitive-data service, or write patterns for the few kinds you have. Pick by testing on your messages (Step 6), not by reading a feature list. A few design points:

  • Run it on every path, including the first message, attachments converted to text, and tool results that come back into the conversation.
  • Run it on the model's input only if you also run it on what you log; see Step 5.
  • Put it in one place. An LLM gateway or a single wrapper function means no code path forgets it.
  • Add business patterns. A custom pattern for your order format costs minutes and often closes the biggest gap.

Step 4: Restore values in the reply, on your server

Sometimes the answer must contain the real value: "We sent your receipt to dana.ortiz@example.com." Keep a lookup table for the life of the conversation, mapping each placeholder to its real value. When the model's reply comes back with <EMAIL_1>, your code swaps in the real address before the customer sees it. The model never saw it.

Three rules keep this safe:

  1. Store the table on your server only. It is personal data. Give it the same access limits and an expiry; the data retention policy entry explains why.
  2. Restore only what the reply is allowed to show. If the model invents <PERSON_9>, leave it unresolved and treat it as an error.
  3. Do not restore inside tool arguments blindly. If the model asks a tool to look up <ORDER_1>, your code can resolve it, but check that the tool call is permitted for this customer. Redaction does not replace permission checks.

Presidio documents an encrypt operator with a matching decrypt, which is another route to reversibility. NIST describes pseudonymization as replacing an identifier with a pseudonym to conceal who someone is; that is what this table implements, and it is weaker than true anonymization, because the table can undo it.

Step 5: Fix the logs, caches and analytics

Redaction before the model does nothing if the raw message is saved earlier. Check each place text lands: your chat database, application logs, error tracker, analytics events, a semantic cache, and any transcript sent to a helpdesk. Decide for each whether it stores the raw text, the redacted text or neither, and set a retention period. The monitoring guide shows what to record without keeping more customer text than necessary.

Also read your provider's terms. OpenAI's data-controls guide says data sent to its API is not used to train its models unless you opt in, and that abuse-monitoring logs are kept for up to 30 days by default; zero data retention needs prior approval. Other providers differ, and terms vary by plan and endpoint, so read the current page for yours. Redaction means less personal data sits in those logs to begin with. On a hosted platform, ask the vendor the same questions.

Step 6: Measure what slips through

Take the 100 messages from Step 1 with every personal item hand-marked. Run the detector and count how many marked items it caught (recall) and how many replacements it made that were not personal data (false alarms). Presidio's own documentation says detection is automated and cannot guarantee that all sensitive information is found, so expect misses and plan for them.

Look at which kinds slip through, fix those first, and re-test. Set your bar before you test: for example, no email or phone number should ever pass, while some free-form address fragments may need a second layer. Re-run the test after any change to the detector, the prompt or the languages you support; a detector tuned on English may do worse on other languages.

Add a safety net behind the filter: an output check that scans model replies for patterns like emails before they are sent, plus the wider guardrails you already run. OWASP's LLM02:2025 entry lists sanitization, input validation and redaction among its mitigations and warns that rules placed in a system prompt may not always be honored, so removal beforehand is stronger than asking the model to stay quiet.

Check the arithmetic

An invented example, not a measurement. The 100 sampled messages contain 160 personal items. The detector catches 136.

  • Recall: 136 ÷ 160 = 0.85, so 24 items (15%) pass through.
  • At 1,000 messages a month, assuming the sample is typical: 1,000 × 1.6 = 1,600 items, and 1,600 × 0.15 = 240 reach the model.
  • After adding a custom pattern for the order format, the detector catches 148 of 160: 148 ÷ 160 = 0.925. Misses are 7.5%, so 1,600 × 0.075 = 120 items a month.

That is half the exposure from an afternoon's work, and a clear list of what remains. Your numbers will differ; the method is to measure on your own messages.

Common mistakes

  • Trusting a vendor's accuracy figure instead of testing your own messages.
  • Deleting instead of replacing, which leaves the model guessing.
  • Logging the raw message before the filter runs.
  • Storing the lookup table forever.
  • Redacting English only while customers write in other languages.
  • Treating redaction as compliance. It is one measure among several.

FAQ

How do I remove personal data from chatbot messages before sending them to an LLM?

Detect names, emails, phone numbers and similar items, replace each with a numbered placeholder, send the redacted text to the model, and restore real values only in your own server's reply.

Can the model still answer with names and emails replaced?

Usually, if placeholders keep the type. Test your common questions on redacted text.

Do I need redaction if my provider does not train on my data?

It can still help. Text may be logged for a period, reach another provider, or sit in your own transcripts.

Is a regular expression enough?

For emails and card numbers, often yes. Names and free-form addresses usually need entity recognition too.

Is this the same as anonymization?

No. A restore table makes it pseudonymization, which can be reversed. See the glossary entry.

Does this make my chatbot GDPR compliant?

No. Compliance also covers legal basis, notices, retention and rights requests; see the GDPR chatbot guide and ask a qualified adviser.

Sources

About this guide

Chatbotscape launched in 2026 as an independent review site for chatbot platforms. This guide is editorial guidance built from the sources above; the steps, the test method and the worked example are our own practice with invented numbers, and we have not benchmarked any detector, provider or gateway.

Last updated

29 October 2026 — first published.