A school-district RAG stores student names as plain metadata fields used as retrieval keys. What minimization control should privacy and security require?
Select an answer to reveal the explanation.
Short Explanation
Putting real student names in searchable metadata is like writing them on the outside of every folder. Use opaque IDs and lock the lookup table—don't make PII the retrieval handle.
Full Explanation
Minimizing direct identifiers in vector metadata and using opaque keys with strict access controls is the privacy control privacy and security should require. Storing student names as plain metadata retrieval keys turns PII into a searchable handle across the school-district RAG stack. Compromised indexes, overly broad debug access, or mis-scoped queries then expose student identity systematically. Prefer opaque internal IDs in metadata, keep name resolution in a tightly controlled directory, and apply least privilege to any join that re-identifies.
Duplicating student names into every chunk body to improve recall fails by concept: that multiplies PII exposure across the corpus. Publishing metadata keys to the district open-data catalog fails by broadcasting identifiers. Replacing similarity search with unrestricted full-table scans of student records fails by abandoning retrieval controls and maximizing bulk access to student data.
Exam caveat: Metadata is in scope for minimization. Opaque keys plus controlled lookup beat using real student names as RAG retrieval handles.
Operational check: Replace name metadata with opaque IDs, remove names from chunk bodies where not educationally necessary, verify FAQ and tutoring bots cannot filter-by-name without an authorized break-glass path, and review FERPA-aligned access logs for metadata queries.