PII in a cache: scrub, isolate, erase, prove
Users put personal data in prompts whether you like it or not. The cache's job is a full lifecycle: keep it out of shared entries, find it on demand, erase it provably.
LLM inputs are a PII firehose by nature — users paste emails, order numbers, and medical details into anything with a text box. A cache that stores responses verbatim becomes an accidental PII database with the best query interface in your company. Pretending otherwise is how privacy reviews end careers.
Crowkis treats the lifecycle explicitly. Scrubbing keeps identifiers out of shared cache entries — the template engine's slot abstraction does double duty here, lifting the personal specifics out of the stored skeleton. The PII index tracks where personal data lives, so 'what do you hold about X?' is a query, not an archaeology project.
Five stages score every write before it can ever be served.
Erasure is workflow-grade: API-driven deletion with reports, built for the GDPR right-to-erasure clock rather than for a best-effort grep. Logs stay clean by default — CROWKIS_LOG_QUERY_PREVIEWS=0 ships as the default, so prompt text doesn't leak into your logging pipeline as a side effect of debugging convenience.
The bottom line
Enterprise's Privacy Vault adds the strict tier: designated-sensitive entries under tighter handling, and compliance modes preset the whole posture per regime. Privacy in a cache is achievable; it just has to be load-bearing architecture instead of a paragraph in the DPA.