A fictional history museum wants an AI assistant to summarize a donor’s recollection for an exhibit website. The source interview also includes a private phone number and home address. Amazon Bedrock Guardrails can detect certain personally identifiable information in text prompts and responses, and a sensitive information policy can mask or block it. The critical editorial question is not whether the demo summary looks tidy. It is whether every path carrying the original information is protected before anyone posts the story.
Inventory where the donor information travels
Draw the complete flow before creating a guardrail: interview transcript, upload staging, text extraction, model prompt, generated summary, staff review copy, diagnostic traces, and publication. Each is a different data store or exchange. Mark the donor’s address and phone number as restricted even if the same document contains facts the museum may publicly quote. Staff must identify permission to publish the recollection separately from permission to use contact details. A machine-readable name or number alone is not evidence of that permission.
Use fictional examples in testing, such as a placeholder phone number and an obviously fabricated street address. Do not paste a real donor record into a sandbox merely to demonstrate anonymization. Decide whether the model even needs contact fields: often the best design removes them with deterministic preprocessing before invoking a model. Limit each workflow component to the minimum content required, record who can export the original interview, and agree on a retention policy before enabling verbose logging.
Configure masking and blocking for different purposes
AWS describes sensitive information filters using built-in PII entity categories and optional regular expressions for organization-specific patterns. A mask policy replaces detected details with type labels; a block policy can stop the request or response. Configure behavior separately for inbound and outbound content where the supported interface allows it. For an exhibit-summary draft, masking an address in the input may preserve enough context for editing, while blocking an unexpected payment-card string could be safer than proceeding with the text.
Choose test cases that include names of places, a donor’s name when permission differs by use, a catalog accession code, an email address, and a phone number. A custom regex for accession IDs may be inappropriate if those codes must remain searchable in the public catalog. Compare the resulting policy against an annotated expected outcome table rather than assuming every number is sensitive or every apparent person name is genuine. Record the guardrail revision and reason for each chosen action.
Understand what the text filter does not cover
Amazon’s documentation explicitly limits sensitive-information filtering to text content in specified model input and output pathways. In tool-use workflows, PII passed as tool-call arguments, returned as tool results, or included in tool definitions may not be masked by that policy. That is important for an assistant that sends a private telephone number to a contact lookup tool while presenting a redacted answer to staff. A safe-looking answer does not prove the underlying tool interaction is safe.
Do not route donor data through tool calls until those calls have their own input validation, authorization, and log protection. Apply access controls at storage and at the export endpoint, because a guardrail is not a permissions engine. Create a prohibited-path test in which a fake restricted field appears in a tool result, then confirm that the application blocks its public display. If the application cannot reliably protect that path, keep the feature out of the donor workflow.
Compare original and masked passages honestly
A teaching diagram can show one fictional draft with a telephone number, a second version with a {PHONE} marker, and a third with the telephone field entirely removed before processing. These are alternative handling states, not measured Bedrock outputs. A replacement marker makes the editorial intent visible, but it can also remove context needed to distinguish two interviews. Preserve a restricted original for authorized staff, and avoid silently substituting a guessed identity into a public narrative.
When the story mentions a neighborhood or local institution, check whether removing a home address changed the factual meaning of a sentence. A model might smooth the prose and accidentally imply a different event location. Compare the published paragraph against the consented source transcript, not only against the masked draft. If anonymization would make an attribution ambiguous, ask a collection manager to decide whether the line should be rewritten or withheld.
Protect invocation logs and inspection traces
AWS cautions that model invocation logs can contain the original input even when guardrail masking affects what is passed to inference, and guardrail trace information may include an original matched value. Therefore treat operational telemetry as another sensitive dataset. Avoid raw prompt logging when not required; if it is required, restrict readers, protect it in storage, set short retention where appropriate, and review who can download traces. Never assume the public-facing redacted passage proves CloudWatch or exported debugging data is redacted too.
Create an operational checklist covering log destination, service account permissions, backup retention, support access, and any incident-notification process. It is a governance design rather than a claim of compliance with a particular privacy statute. If an event is investigated, staff should be able to identify which guardrail revision ran without circulating the original donor details in a ticket. Hashes and synthetic reproduction examples can sometimes help troubleshoot without copying restricted text.
Test misses and false positives before public use
Run a small approved evaluation set containing realistic formatting variation: a phone number with spaces, a named building that resembles an address, quoted catalog descriptions, an accession number, and deliberately unrelated numeric strings. Include a multilingual passage if the intended service supports one, and verify current language coverage before asserting that the filter works in that language. Record both information missed and information removed unnecessarily; the policy is probabilistic, not an infallible identity detector.
A missed address in a short snippet may be a consequence of missing context. A falsely masked catalog reference can make the exhibit meaningless. Do not solve both by making every setting maximally restrictive without testing usefulness. Establish a staff review rule for uncertain content and block publishing if the reviewer cannot open the permission record. No accuracy rate is claimed here, because the example has not been run against an AWS account or real donor archive.
Publish only after source and privacy sign-off
The final release packet should contain the approved narrative, a reference to the permitted transcript excerpt, the contact-field exclusion checklist, and an acknowledgement that no sensitive values remain in alt text, captions, file names, or page metadata. A public editor should not require read access to the unredacted address to publish the approved paragraph. Keep separate sign-off for fact accuracy and privacy: a correct quote may still reveal private information, while a private-safe paragraph may still be inaccurate.
Recheck the published page rather than relying on a preview. CMS revisions, search snippets, automated email notifications, and downloadable media metadata may preserve material that is no longer visible in the main article. Provide a takedown route for mistakes and document who can revoke access quickly. The system is ready only when the whole editorial chain, not just the model reply, respects the permission boundary.
How We Research
For this November 2026 editorial review, we consulted official vendor materials: AWS: Remove PII with sensitive information filters; AWS: Create your guardrail; AWS: Guardrail handling options. We checked the named feature, input/output scope, documented limitations, and the points where software results must be reviewed against an authoritative record. The project is a hypothetical instructional design; the graphics, source cards, time marks, sample identifiers, and decision states are original explanatory illustrations, not captured screenshots or measured service results. We did not upload real archival data, conduct a production API evaluation, obtain permissions on behalf of an institution, or measure an accuracy or latency result. Before deployment, verify current feature availability, regions, quotas, prices, data protection terms, licensing, and the latest developer documentation. A qualified human must review permissions, factual accuracy, accessibility, and any publication or high-impact changes.
Frequently Asked Questions
No. Masking can change text on supported model input and response paths, but original source files, logs, traces, backups, and tools must be controlled separately.
A custom regex can detect an appropriate textual pattern, but test carefully: catalog IDs may be public and an overly broad rule can remove legitimate references.
AWS documents important exclusions for tool arguments, tool results, and tool definitions. Add application-side protection for those paths.
No. Staff must check permissions, factual fidelity, remaining identifiers, metadata, and the actual CMS page.
No. It is an instructional design. The museum needs its own privacy, consent, storage, and legal review.