A community print-coop knowledge base still contains workshop rosters with emails. A public kiosk can retrieve them. Which problem is that, and what is the fix?
Select an answer to reveal the explanation.
Short Explanation
Think of workshop rosters with emails sitting in the knowledge base, retrievable from a public kiosk. That is insecure RAG. Scrub or restrict the store, not just the prompt template.
Full Explanation
Workshop rosters with emails sitting in the print-coop knowledge base and reachable from a public kiosk are insecure RAG: personally identifiable information in the retrieval corpus is a leak path. Fix the store—scrub emails, restrict documents by audience, or move sensitive rosters out of the public index—rather than only editing the prompt template. Prompt wording cannot reliably stop retrieval of content that still lives in the searchable pile.
A prompt-template tweak only fails by concept: roster emails do sit in the retrieved store, and models will surface retrieved PII despite polite instructions. Calling kiosk retrieval of emails a successful public feature fails because public exposure of workshop contact lists is an unintended disclosure, not an intended product behavior. Amazon Quick fails because a charting service does not scrub or ACL a knowledge base.
Exam caveat: securing RAG requires both corpus hygiene and retrieval authorization; output filters help but should not be the only defense for known PII in the store. Operational check: query the public kiosk for roster-like prompts, confirm emails no longer return, review index ACLs for public versus staff collections, and document the scrub or restriction in the change log.