Responsible Data Mining: Provenance, Privacy and Fair Use

A review that happens before ingestion

This lesson gives you a practical provenance and impact review. It is not legal advice. Its purpose is to expose questions that require the organisation’s privacy, security, legal or domain specialists.

• Trace a dataset to an owner, collection method, licence or permission and review date.
• Separate direct identifiers, quasi-identifiers and sensitive attributes.
• Apply data minimisation, access control and retention thinking to a mining plan.
• Recognise that removing names does not automatically make records anonymous.

Provenance is part of model quality

Provenance records how data was created, changed and transferred. Without it, you cannot tell whether a field means the same thing across years or whether labels came from a reliable process. A dataset card should describe collection, intended uses, known limitations and licensing. These details support technical debugging as well as governance.

Direct identifiers such as an email address point to a person. Quasi-identifiers such as age, postcode and job title can identify someone when combined. Sensitive information can cause serious harm even when it does not identify a person by itself. Classify fields based on the real environment, not a short universal list.

Data minimisation asks which fields are genuinely required for the stated purpose. Keeping every column ‘in case it helps’ expands breach impact, increases spurious patterns and makes access harder to justify. Retention has the same discipline: define when raw, intermediate and output data should be reviewed or removed under the organisation’s policy.

Fairness cannot be reduced to deleting protected attributes. Other fields can act as proxies, and historical labels may encode unequal treatment. Compare performance across relevant groups where lawful and appropriate, document sample limitations, and involve affected domain experts. A metric is evidence for a discussion, not a certificate of fairness.

Publishing results can leak information too. Small group counts, memorable examples and detailed model outputs may expose individuals. Apply aggregation thresholds and review any external release separately from internal analysis.

Generate a field-level risk register

The example classifies a simple schema and flags fields that should not flow into a general modelling table without review. It creates a review queue, not an automatic legal decision.

Classify purpose and exposure

fields = [
    {"name": "customer_id", "class": "direct_identifier", "needed": False},
    {"name": "postcode", "class": "quasi_identifier", "needed": True},
    {"name": "support_text", "class": "unstructured_sensitive", "needed": True},
    {"name": "monthly_orders", "class": "behavioural", "needed": True},
    {"name": "favourite_colour", "class": "general", "needed": False},
]

high_review = {"direct_identifier", "quasi_identifier", "unstructured_sensitive"}

for field in fields:
    actions = []
    if not field["needed"]:
        actions.append("exclude from modelling copy")
    if field["class"] in high_review:
        actions.append("privacy and access review")
    if field["class"] == "unstructured_sensitive":
        actions.append("scan and redact before use")
    print(f"{field['name']}: {', '.join(actions) or 'standard controls'}")

Risk queue produced by the script

customer_id: exclude from modelling copy, privacy and access review
postcode: privacy and access review
support_text: privacy and access review, scan and redact before use
monthly_orders: standard controls
favourite_colour: exclude from modelling copy

The script never claims that postcode or support text must always be excluded. It makes review visible. A proper decision depends on purpose, jurisdiction, consent or another lawful basis, safeguards and organisational policy.

Privacy shortcuts that create false confidence

These mistakes often survive because the resulting CSV no longer looks sensitive. Treat transformation as one control among several.

• Hashing a stable customer identifier usually leaves records linkable. It is pseudonymisation, not proof of anonymity.
• Free text can contain names, addresses, health details and credentials that a fixed schema never declared.
• Public availability does not automatically grant permission for any reuse, combination or publication.
• A fairness average can hide a small group with too few examples for a reliable estimate. Report counts and uncertainty.

Audit one dataset you can lawfully inspect

Choose a public dataset with a clear source page. Do not download personal data merely for this exercise. Produce a short dataset card and a field-level risk register.

• Record the source URL, publisher, collection method, licence and the date you checked them.
• State intended and unsuitable uses in your own words.
• Classify the fields and justify every field kept for a proposed task.
• Name access, retention and release controls, plus the specialist decisions still required.

Review artefacts to save

• A dataset card that another analyst could update.
• A field register with purpose, classification and control columns.
• A one-paragraph impact note that names people who might be affected.

Official references and further reading

• NIST Privacy Framework (Official privacy risk-management framework)
• Hugging Face dataset cards (Primary documentation for transparent dataset descriptions)
• OECD AI Principles (International principles for trustworthy AI)

Review note for Responsible Data Mining: Provenance, Privacy and Fair Use: recheck the linked documentation after a dependency changes the relevant API, metric or modelling assumption, then record the tested version beside your result.