Personally identifiable information (PII) is any data that identifies a person: names, emails, phone numbers, government IDs, account numbers, and in many jurisdictions much more. If your Claude use case touches customer or employee text, PII will flow through your prompts. Privacy teams do not expect zero PII; they expect a defensible answer to three questions. What personal data do we send? Why is each element necessary? What happens to it afterward? This article gives you patterns for answering all three.
Start with minimization, not redaction
The cheapest PII to protect is PII you never send. Before building redaction machinery, look at what the task actually requires. A model classifying support tickets by topic does not need the customer's email address or account number; it needs the ticket body. A model summarizing a contract's payment terms does not need the signatories' home addresses. Trim the input to the fields the task uses, and you have removed most of the risk with a few lines of ordinary code.
Minimization also improves quality. Shorter, more focused prompts cost fewer input tokens and give the model less irrelevant material to be distracted by. Privacy and engineering incentives point the same direction here, which makes this the easiest control to get funded.
Redaction and pseudonymization patterns
When the personal data is woven into free text, redact before sending. Two levels are common. Redaction replaces identifiers with placeholders like [EMAIL], fine when the model does not need to track who is who. Pseudonymization replaces them with consistent tokens like CUSTOMER_1, and your application maps the tokens back after the response, useful when the model must reason about specific people without seeing real identifiers.
Simple pattern-based redaction catches the structured identifiers (emails, phone numbers, ID-number formats) and is a reasonable first layer:
import re
from anthropic import AnthropicBedrockMantle
def redact(text: str) -> str:
text = re.sub(r"[\w.+-]+@[\w-]+\.[\w.-]+", "[EMAIL]", text)
text = re.sub(r"\b\+?\d[\d\s().-]{7,}\d\b", "[PHONE]", text)
return text
client = AnthropicBedrockMantle(aws_region="us-east-1")
response = client.messages.create(
model="anthropic.claude-sonnet-5",
max_tokens=400,
messages=[{"role": "user",
"content": f"Classify this ticket:\n{redact(ticket_text)}"}],
)Regexes will not catch names or addresses in free prose. For higher-stakes flows, teams add a dedicated PII-detection step (cloud providers offer such services, or a fast model like Claude Haiku 4.5 can flag likely identifiers for a deterministic scrubber to remove). Keep the actual removal deterministic and testable; use models to find, code to delete.
Know your data flow and put it in writing
Whatever you send, be able to describe its path. On the third-party platforms, requests go to the Claude endpoint on your chosen cloud in your chosen region; running inside your existing cloud boundary means the workload largely inherits that provider's compliance posture. Retention and data-use commitments are set by your platform's terms, and they differ between providers, so have your privacy team read the current data-processing documentation for the specific platform you use and confirm specifics with the provider. If your legal basis for processing depends on residency, pin the region deliberately rather than accepting a default.
Review patterns that keep privacy teams comfortable
Three lightweight practices turn "trust us" into evidence. First, a data map per use case: one short table listing each input field, whether it can contain PII, and the minimization or redaction applied. Second, sampled human review: periodically inspect a random sample of outgoing prompts (in a controlled environment, by cleared staff) to verify the redaction actually works on real traffic, since regexes rot as data changes. Third, tests that fail loudly: unit tests that feed known PII patterns through your redaction layer and fail the build if any survive. When the privacy team asks "how do you know?", these three artifacts are the answer.
Finally, handle the response side too. Model outputs can restate or infer personal details from the input, so outputs that will be stored or shown broadly deserve the same logging and retention decisions as inputs.
Where to go next
For the full picture of what leaves your network, read Claude 3P Data Flow Basics. To encode these practices as policy for your whole organization, see Writing an Internal Acceptable-Use Policy for Claude.