A county bot uses multi-hop retrieval that chains across departments without purpose limitation. What privacy principle should constrain the design?
Select an answer to reveal the explanation.
Short Explanation
Each hop is another door into someone's files. If the bot can wander from permitting into HR 'just because,' you've lost purpose limitation—fence the graph to the job at hand.
Full Explanation
Purpose limitation across multi-hop civic retrieval so each hop stays within authorized, necessary scope is the privacy principle that should constrain the design. Multi-hop graphs that chain across departments without purpose bounds let a county bot wander from the original business purpose into HR or unrelated case files “because the next hop looked similar.” Each hop needs an authorized purpose, allowed corpus, and stopping rules; automation does not waive minimization or purpose limitation.
Claiming multi-hop retrieval is exempt from purpose limitation because hops are automated fails by concept: automation increases the need for encoded purpose bounds. Always expanding hops to every department to maximize completeness fails by design against least privilege and purpose limitation. Saying purpose limitation applies only to human clerks, not RAG graphs, fails because the same privacy principle governs machine access to municipal personal and case data.
Exam caveat: Multi-hop RAG is still a series of access decisions. Encode purpose and department scope per hop for county assistants.
Operational check: Define allowed hop graphs per use case, block cross-purpose edges (e.g., permitting → HR), simulate a multi-hop query and confirm it cannot enter disallowed collections, and review hop logs in privacy impact assessments.