A parks membership bot summarizes support tickets that sometimes include payment card numbers. What should the pipeline do before any foundation-model summarization?
Select an answer to reveal the explanation.
Short Explanation
Card numbers do not belong in the model’s scratchpad any more than they belong on a sticky note at the front desk. Redact PANs first, then summarize—so parks support gets the story without feeding payment data to the FM.
Full Explanation
Redacting payment card data from support tickets before the text enters the foundation-model context window is what the parks membership pipeline must do before any FM summarization. Tickets that may contain PANs should pass through PCI-aware redaction or tokenization so card numbers never become prompt tokens, embeddings, or model outputs. That keeps summarization useful for membership ops while preventing payment data from entering GenAI systems that are rarely in PCI scope.
Asking the model to memorize card numbers so renewals are faster next season intentionally stores payment data in model state or logs and amplifies PCI exposure. Forwarding raw ticket bodies to a public GenAI playground for free summarization sends PANs to an uncontrolled third party. Embedding full PAN data in vector indexes “for relevance” persists card numbers in retrieval corpora long after the ticket is closed.
Exam caveat: sensitive data should be removed before FM context whenever possible—redact-then-summarize beats detect-after-echo. Payment card content is a classic minimization case distinct from generic PII masking in logs.
Operational check: run tickets with synthetic PANs through the parks pipeline, confirm redaction before Bedrock/FM invoke, verify vector indexes and prompt logs contain no PAN patterns, and align the control with PCI scoping documentation for the membership bot.