PII — personally identifiable information — is any data that identifies a person: names, contact details, government ID numbers, account numbers, and so on. In a Claude application, PII arrives from two directions. Users type or paste it into prompts, and the model may repeat or reconstruct it in responses. Amazon Bedrock Guardrails includes a sensitive information filter policy type designed for exactly this: per AWS's documentation, it can detect PII and either block the content or mask it, and it supports custom regex patterns for identifiers of your own.
Block or mask: two different promises
Blocking rejects the offending content outright — the request (or response) does not go through. It is the right choice when PII should categorically never enter the application: an internal code assistant, say, has no legitimate reason to process customer social-security numbers, so any appearance is an error worth stopping loudly.
Masking replaces the detected data and lets the rest of the content through. It is the right choice when the workflow is legitimate but the identifiers are not needed: a support-ticket summarizer works exactly as well on "customer [masked] reports a billing error" as on the real name — so why send the real name to the summary at all? Masking preserves utility while shrinking the personal-data footprint, which is the general shape of what privacy reviews ask for.
You will often want different treatment for different data types in one guardrail: mask names and email addresses in a support workflow, but hard-block payment card numbers everywhere. Consult the current AWS documentation for the supported PII entity types and per-type configuration options rather than assuming coverage — the built-in list is finite, which is exactly why custom patterns exist.
Custom regex for your own identifiers
Built-in detectors target common PII. Your organization also has identifiers that are sensitive by policy but invisible to any generic detector: employee IDs, customer account numbers, claim numbers, internal ticket references. The sensitive-information policy accepts custom regular-expression patterns, so if your account numbers look like ACCT-\d{10}, you can have the guardrail treat them exactly like built-in PII — blocked or masked, on input, output, or both. In practice this is where much of the policy's enterprise value lives: generic PII detection is table stakes, while "our claim numbers never leave the boundary unmasked" is a control specific to you.
Where this screen sits — and what it does not cover
Guardrails evaluate the input prompt and the model's completion on invocations that reference the guardrail's ID and version. Three boundary facts worth engineering around:
It is a screen at the model boundary, not in your data layer. PII in your databases, logs, and RAG document stores is untouched. Note the interaction with Bedrock's model invocation logging in particular: invocation logs capture full request and response data, so decide deliberately what your logging pipeline should retain and who can read those log groups — the broader picture is in PII handling and data privacy basics.
Detection is probabilistic. Formats vary, contexts mislead, and no detector catches everything — treat the guardrail as risk reduction that complements data minimization upstream (do not send fields the model does not need), not as a guarantee. Build a test set of realistic records and probe both misses and false positives via the standalone ApplyGuardrail API before production, per the approach in guardrail testing.
It does not settle compliance questions. Whether masked transcripts satisfy your obligations under a given privacy regime is a determination for your counsel, and your deployment inherits your cloud provider's compliance posture — confirm specifics with your provider.
Where to go next
See the rest of the policy bundle in the Guardrails overview, and how enforcement is attached to calls in the setup walkthrough. For the platform-neutral privacy picture, start with data privacy basics.