311 engineering caches embeddings of every ticket indefinitely, including resolved sensitive cases. What retention control should security require?
Select an answer to reveal the explanation.
Short Explanation
Closing the 311 ticket in the CRM but keeping the embedding forever is like shredding the paper and filing the photocopy. Put retention clocks on the vectors too.
Full Explanation
Applying retention limits and purge policies to vectorized civic case content—not only to the ticket database—is the retention control security should require. Caching embeddings of every 311 ticket indefinitely, including resolved sensitive cases, keeps personal and case details searchable long after the CRM closes the record. Vectors are still personal data in practice when chunks or metadata retain case content. Align vector retention with ticket retention schedules and purge embeddings when cases age out or residents exercise deletion rights.
Keeping embeddings forever because vectors are “anonymized by construction” fails by concept: chunk text and metadata often remain identifying, and embeddings can support re-identification or nearest-neighbor leakage. Replicating ticket embeddings to a public demo cluster fails by expanding exposure of sensitive case content. Disabling ticket closure so embeddings stay aligned only with open cases fails operationally and does not implement lawful retention limits.
Exam caveat: Retention and deletion obligations apply to RAG indexes. Closing the ticket without purging vectors leaves a shadow case file.
Operational check: Map CRM retention tags into the vector store, schedule purge jobs for closed sensitive cases, verify a closed fixture ticket’s vectors disappear from similarity search, and include vector stores in records-retention audits.