Privacy, Data Governance, and Retention

Goal

Track why data is collected, who may use it, how long it should exist, and how the system proves those rules are followed.

Collect only what the task needs

Imagine a school club collecting information for a field trip. It may need each student's name and emergency contact, but it probably does not need every old message the student has ever sent. After the trip, some records may no longer have a reason to remain.

Privacy engineering begins with that simple discipline: Why do we need this field, who needs it, and how long should it exist? Data minimization means collecting or keeping no more than the declared purpose requires. Retention is the rule for how long data remains. Governance is the larger set of ownership and review rules that makes those decisions enforceable instead of merely written down.

AI systems can accumulate data quickly. Prompts, retrieved documents, tool results, conversation history, traces, human ratings, and incident records may all be useful for debugging or evaluation. “Useful” does not mean “keep forever.”

Start from purpose and minimization

Start with purpose. For each data field, ask why the product needs it. A support assistant may need an order ID to answer a request, but it may not need a user's full payment history. An evaluation pipeline may need an error category but not the original sensitive message.

Applying data minimization also reduces privacy exposure, security impact, storage cost, and the number of places that require deletion later.

{"field":"order_id","purpose":"answer support request","classification":"internal","retention_days":30}

Classify data and control access

Classification makes rules explicit. A simple scheme might label data public, internal, confidential, or restricted. The exact labels vary by organization, but each label should connect to access, logging, retention, and sharing rules. A label without behavior is only decoration.

Access control should follow purpose and role. A production service may need to use a record to answer a user, while an offline evaluator may only need a de-identified summary. Copying production data into an evaluation folder can create a new data flow with different risks even when the original access was legitimate.

Define retention and deletion propagation

Retention defines how long data remains available. Some evidence may need a short debugging window; other records may be required longer for security, legal, or audit reasons. The important engineering property is that the retention rule is explicit and enforceable rather than “we usually delete old logs.”

Deletion also needs propagation. If a record exists in a primary store, analytics export, vector index, cache, and evaluation fixture, deleting only the primary copy may not satisfy the intended policy. Map derived stores and document which ones are covered by each deletion workflow.

Make privacy claims precise

Privacy claims should be specific. “We do not train on your data” answers only one question. It does not say whether prompts are logged, used for abuse monitoring, reviewed by people, retained for debugging, copied into evaluations, or shared with a service provider. Good governance separates those uses.

NIST AI RMF and the Generative AI Profile treat governance as an ongoing organizational function and include data privacy among important generative-AI risk areas. In engineering practice, governance becomes concrete through owners, approved purposes, access policies, retention rules, incident processes, and reviewable evidence.

Turn governance into executable checks

A retention checker can be simple. Store created_day, retention_days, classification, and legal-hold state. A record is eligible for deletion when its retention period has passed and no overriding hold applies. The function is small, but the difficult work is deciding and documenting the policy inputs.

Do not encode local law or organizational policy as a universal course rule. Privacy obligations depend on jurisdiction, sector, contracts, and context. This Lesson teaches technical governance patterns: minimize, classify, control access, define retention, propagate deletion, and preserve evidence for review.

The evaluation system should test governance rules too. Include fixtures for expired data, restricted data sent to a disallowed destination, and records under a valid hold. A governance policy that exists only in prose can drift away from running systems.

Predict

An evaluation needs only an error category and task type, but the pipeline copies complete user conversations. What design issue is most direct?

The pipeline is collecting more data than its stated evaluation purpose requiresThe evaluation cannot work unless it stores every original message foreverThe model should decide which privacy policy applies after reading the data

Run the local Lab

Run:

python3 labs/notebooks/level-15/l15-08-retention-governance.py

The Lab evaluates retention timing and access policy as separate controls.

1. Run it unchanged with current_day = 10, retention_days = 30, and no legal hold. Record deletion_eligible: false and the restricted-access result.
2. Before editing, predict whether the same record becomes deletion-eligible after day 31 while the access-control result stays fixed.
3. Change only current_day = 10 to current_day = 31, then rerun.
4. Confirm deletion eligibility becomes true while restricted_analyst_access remains false. Restore the day, then reason separately about why setting legal_hold to true would block deletion even after retention expires.

Loading lab…

Quick Check

1. What does data minimization require?

Collect and retain only data needed for the declared purposeLet the model decide which fields are sensitiveDelete every record right after creating it

2. Why map derived copies such as indexes and evaluation exports?

Because deletion rules may apply beyond the main storeBecause derived copies are usually public dataBecause a vector index satisfies every retention rule

3. Which statement is a complete retention rule?

Keep logs for a while in case the team needs them laterPeriod, exceptions, owner, and deletion evidenceDelete data when it seems old, using personal judgment

0 of 3 questions answered.

Explain it back

Take one AI data flow from input to logs and evaluation. State the purpose of each copy, its classification, who may access it, and what event or time limit should end its retention.

Key Takeaways

• Data collection should be tied to a declared purpose.
• Minimize data before relying on downstream cleanup.
• Classification must connect to access, sharing, logging, and retention behavior.
• Retention and deletion need explicit, testable rules across derived stores.
• Governance decisions should be reviewable and should not be delegated to model-generated text.

Next Lesson

Next, L15.9 — Red Teaming and Abuse Testing turns threat paths into structured adversarial evaluation.

References

• NIST, AI Risk Management Framework (AI RMF 1.0).
• NIST, AI RMF Generative AI Profile (NIST AI 600-1).