CLLMSP · Domain 6
LLM Data Protection & Privacy
About 12% of the exam
Where personal data ends up
- Prompt
- whatever the user pastes in
- System context
- records the app injects
- Retrieval
- documents pulled at query time
- Tool results
- records fetched from other systems
- Training corpus
- data baked into the weights
- Fine-tuning set
- transcripts reused as examples
- Logs and traces
- copies kept for debugging
- Vector index
- embeddings of the source text
- Client storage
- copies you cannot reach
Every hop makes another copy, so a data map that stops at the model misses most of the personal data you are now holding
Minimization at each hop
Before the model
- Send only fields the task needs
- Redact direct identifiers at ingest
- Tokenize account numbers before sending
- Never ship whole customer records
Inside the pipeline
- Filter retrieval to the caller's scope
- Truncate documents to relevant passages
- Avoid free-text notes where possible
- Keep context windows deliberately small
After the answer
- Screen output for personal data
- Redact before logs and analytics
- Aggregate prompts kept for insight
- Expire transcripts on a schedule
De-identification and its limits
- Removing names is not anonymization
- Quasi-identifiers still single people out
- Rare attributes re-identify small groups
- k-anonymity ignores sensitive value diversity
- l-diversity addresses that missing variety
- Paraphrased leakage survives exact-match tests
Training data and deletion
- Fine-tuned data is entangled in weights
- Deletion may require retraining without it
- Unlearning methods remain hard to verify
- Retrieval keeps records deletable at source
- De-duplicate before any fine-tuning run
- Test extraction with planted canary strings
Retrieval and tenant isolation
- Mirror source permissions at retrieval time
- Similarity search needs a tenant filter
- Shared indexes leak without hard partitions
- Deleted documents leave live vectors behind
- Offboarding must purge the index too
- Model trust never replaces access control
Embeddings are personal data
- Inversion recovers much of the text
- Membership inference reveals who was included
- Numbers are still a recoverable copy
- A leaked index can be reportable
- Encrypt and access-control the vector store
- Include embeddings in the data map
Privacy-preserving techniques
- Differential privacy
- noise bounds one record's influence
- Privacy budget
- cumulative loss across released queries
- Federated learning
- updates travel, raw records stay
- Secure aggregation
- server sees only combined updates
- Synthetic data
- useful but can memorize outliers
- Machine unlearning
- removing influence without full retraining
- Pseudonymization
- reversible with the mapping table
- Confidential computing
- processing inside an attested enclave
- Watermarking
- marks output, protects no input
Vendors, transfers and residency
- The processing agreement governs vendor handling
- Check whether prompts train their models
- Retention and deletion terms in writing
- Residency needs contract plus region evidence
- Sub-processor list and change notice
- Independent audit beats a vendor attestation
- Successor use needs its own basis
- Reassess at renewal, not never
A deletion promise is worth exactly the evidence behind it, so ask for the audit scope and the contract clause rather than the marketing page
Data subject rights
- Access, rectification, erasure, restriction, objection
- Rights reach prompts, logs and embeddings
- Deletion must propagate to every store
- Track requests against the data map
- Profiling with real effects needs safeguards
- Answer within the statutory window
Retention and logging
- Redact secrets before the log store
- Security events kept longer than routine traffic
- Age out prompt content on schedule
- Debug impersonation gated and fully audited
- Client-side copies escape your retention policy
- Retention differs per store, document each
Notice, consent and purpose
- Tell people the assistant reads this
- A new purpose needs a fresh basis
- Silent reuse of transcripts breaks notice
- Consent must be refusable without penalty
- Special category data raises the bar
- Children's data needs stricter handling
Responding to a privacy incident
- Detect
- Scope copies
- Assess harm
- Notify
- Purge
- Fix the path
- Review
- Scope means every store holding copies
- Embeddings and caches count as exposure
- Reportability turns on recoverability and harm
- Preserve evidence before any purge
- Tell affected tenants what was reachable
- Close the ingestion path, not the ticket
Glossary
- Data map
- every store holding personal data
- Minimization
- only what the task needs
- Pseudonymization
- identifiers replaced, mapping kept separately
- Anonymization
- re-identification no longer reasonably possible
- Membership inference
- was this record in training
- Model inversion
- reconstructing inputs from model behavior
- Processing agreement
- contract governing a vendor's handling
- Legitimate interest
- basis needing a balancing test
Quick rules
- Map the copies before the controls
- Embeddings are personal data too
- Retrieval is deletable, weights are not
- Permissions at retrieval, not at prompt
- Redact before the log, not after
- Contracts and evidence, not vendor claims
Reference strip: copies, minimize, isolate, techniques, obligations
Copies
- Prompt, context, logs, vectors, weights
- Client storage escapes your purge
- Caches hold personal data too
- Map every store, then control
Minimize
- Send only fields the task needs
- Redact and tokenize at ingest
- Truncate to the relevant passage
- Aggregate what analytics really uses
Isolate
- Tenant filters on similarity search
- Mirror source permissions at retrieval
- Purge vectors when documents die
- Never share an unpartitioned index
Techniques
- Differential privacy bounds single-record influence
- Federated learning keeps records local
- Unlearning is hard to verify
- Synthetic data can memorize outliers
Obligations
- Access, rectification, erasure, restriction, objection
- Processing agreement governs the vendor
- Residency needs contractual and technical proof
- Report when recovery and harm plausible
Quick exam traps
- Trap: Embeddings are only numbers, so a leaked index cannot be a breach
- Trap: Deleting the source document removes that data from the fine-tuned model
- Trap: Stripping names from a transcript makes the dataset anonymous
- Trap: The model can be trusted to withhold documents the user may not see
- Trap: A vendor promise of thirty day deletion is sufficient evidence
- Trap: Prompts are transient, so they fall outside data subject rights
- Trap: Sending whole customer records is acceptable because the model needs context
cybercertprep.com · original revision sheet written from the public body of knowledge