County IT builds RAG corpora from building-code PDFs and from resident complaint emails. What inventory action is most appropriate?
Select an answer to reveal the explanation.
Short Explanation
Building codes are public; tenant complaints are private. Keeping both on the building-code schedule won't work since you'll treat private emails like public rules. Sort them by sensitivity so you apply the right safeguards.
Full Explanation
Classifying each corpus by content sensitivity so building codes and complaints can be governed according to their distinct sensitivity profiles is the action that protects privacy and enables appropriate retrieval. A RAG system that combines building-code PDFs and resident complaint data must distinguish them: building codes are public and can be cited and retrieved openly; resident complaints contain PII, dispute history, and personal details that require authorization and anonymization before retrieval. Different sensitivity means different governance: public corpora can be indexed fully; sensitive corpora must have access controls, query logging, and de-identification steps before the RAG system returns results. Retaining both corpora under building-code schedule so code purpose sets lifecycle for complaint emails too is wrong because a records schedule doesn't determine sensitivity; building codes are public while resident complaints contain PII, so one lifecycle rule risks exposing private data in public RAG queries.
Documenting embedding version and chunk size for each corpus as the primary inventory handling classification is wrong because configuration details are mistaken for governance; those technical settings don't classify sensitivity or control retrieval, so sensitive complaint data could still be returned to unauthorized users. Classification must precede operation. Assigning both corpora to vector platform team for ownership since the ingestion service manages storage operations is wrong because storage operations don't assess content sensitivity; PDFs and emails need distinct privacy governance based on what they contain, not on which team operates storage. RAG systems must be built with privacy classification from inception, not added as a patch afterward. The sensitivity boundaries should influence RAG design (which corpora are combined, what access controls are enforced, how queries are logged).
Operational check: before the RAG system goes live, confirm: (1) each corpus is classified (public or sensitive), (2) sensitive corpora have access-control rules (who can retrieve, what redaction is applied), (3) query logs distinguish public vs. sensitive retrievals, and (4) sensitive-corpus retrieval includes a human-review step before results are shown to the end user.
Prefer to study offline? Printable PDF study book + test engine ($7.50, unofficial). These questions stay free here.