A volunteer rescue-squad after-action helper must strip patient names and phone numbers from generated summaries. Which layer should do that work?
Select an answer to reveal the explanation.
Short Explanation
Think of stripping patient names and phones from after-action summaries. Do that at the application safety layer with a PII filter. Retraining the model to hide secrets is the wrong shop.
Full Explanation
Volunteer rescue-squad after-action summaries often contain patient names and phone numbers that must not leave the controlled workflow. A PII filter or redaction guardrail at the application safety layer works because it inspects generated text (and optionally inputs) and strips or masks sensitive fields before the summary is stored, emailed, or shared with volunteers. A customization job whose only purpose is to hide those fields in new weights is brittle: models can still emit PII on novel phrasings, and training is the wrong control plane for privacy enforcement. Leaving names and phones in the summary so redaction seems unnecessary violates the privacy requirement outright and expands breach scope. A BI dashboard does not redact phone numbers from free-text generations. Exam caveat: regex or NER-based redaction can miss novel formats, nicknames, or concatenated identifiers, so treat automated PII filters as necessary but not perfect. Operational check: feed summaries that deliberately include names and phones and verify the published artifact shows redaction markers with zero residual identifiers in the final output. Log redaction hits so the squad can audit whether sensitive fields are still appearing upstream in notes.