Practical guide

How to assess privacy-aware handling in AI-enabled work

Privacy-aware handling limits personal or sensitive data to what a task needs. It uses approved tools and checks AI outputs for needless disclosure before release.

By Two Prune

Privacy-aware handling limits personal or sensitive data to what a task needs. It uses approved tools and checks AI outputs for needless disclosure before release.

Start with the work purpose, not the available data

The ICO explains data minimisation as processing only the personal data needed for a defined purpose and storage limitation as retaining it only as long as necessary. The Government of Canada's generative-AI guide advises users not to enter sensitive or personal information into unmanaged tools and to understand how a system uses inputs. These are jurisdiction-specific sources, not universal legal advice, but they support a practical operating principle: access to data is not permission to send all of it to an AI system.

Privacy-aware handling is not demonstrated by adding a generic warning after the work is finished. The worker must make handling decisions before prompting, minimise the data exposed, inspect outputs for disclosure, and stop or escalate when the tool or purpose is not authorised. A reviewable handling record connects those decisions to the work product.

Before using a tool, write a one-sentence purpose and identify the smallest information set needed to produce the output. Then check four boundaries:

If the worker cannot establish those boundaries, the correct action may be to use a non-AI method, substitute synthetic data, seek approval, or stop the task.

  • data boundary: which fields are needed, which are optional, and which are prohibited;
  • tool boundary: whether the approved environment is suitable for the information classification;
  • people boundary: who may view the prompt, source material, output, and retained record;
  • time boundary: how long inputs, outputs, and working copies should remain available.

Use the MINIMUM route

The MINIMUM route turns privacy awareness into observable work:

The route produces a handling note. It records the purpose, data categories, fields retained or removed, tool approval evidence, output inspection, and final disposition. It does not claim legal compliance. A privacy or security owner may still need to decide whether the use is permitted.

  • Mission: state the task purpose and intended recipient.
  • Inventory: list personal, confidential, commercially sensitive, and public fields in the source.
  • Need: retain only fields required for the task, with a reason for each sensitive field kept.
  • Instance: confirm the exact tool, account, configuration, and approved data class.
  • Mask: replace identifiers or sensitive values where the task can be completed with tokens, ranges, or synthetic examples.
  • Use: submit only the approved minimum and keep the prompt within the stated purpose.
  • Monitor: inspect the output for re-identification, unnecessary reproduction, inference, or new sensitive content.
  • Move or remove: place the final work in the authorised record system and handle temporary material according to the applicable retention rule.

Worked artifact: minimise a service-summary task

Consider an original synthetic exercise. A participant must summarise five customer-support cases for an internal service-improvement meeting. The source export contains names, email addresses, account identifiers, free-text notes, product area, issue category, dates, resolution steps, and satisfaction comments. The participant has access to an approved enterprise assistant, but the task brief does not require discussion of individual customers.

The participant creates this handling note:

| Field or element | Need test | Action | Verification | | --- | --- | --- | --- | | Name and email | Not needed for pattern analysis | Remove before prompting | Search prepared input for names and @ symbols | | Account identifier | Not needed; could link records back to a customer | Replace with Case A to Case E | Confirm no original identifiers remain | | Product area and issue category | Needed to group recurring issues | Retain | Check categories match the source export | | Free-text notes | Some details explain the failure; notes may also contain identifiers | Extract only relevant operational facts and generalise dates | Compare each excerpt with the source and scan for identifying detail | | Satisfaction comment | Useful only as reported feedback, not as a performance measure | Retain a short paraphrase without attribution | Label it as feedback from this small synthetic set |

The prepared prompt uses five minimised case cards. During output review, the participant notices that the assistant infers that one case involved a health condition from a medication-delivery complaint. That inference was not needed for the service analysis. The participant removes it, checks that no similar inference appears elsewhere, and records the removal in the handling note.

The final summary reports recurring workflow issues without naming customers or claiming that five cases represent the full customer population. The participant stores the approved summary in the project record and follows the exercise's deletion instruction for the temporary prompt file.

All people, cases, fields, and procedures in this example are synthetic. They are not customer data, legal conclusions, or evidence that a particular tool configuration is appropriate for real sensitive information.

Build an assessment with real decision points

A useful exercise should require more than obvious redaction. Give the participant a mixed source pack in which some personal information is irrelevant, some sensitive context is necessary for the decision, and some identifiers can be replaced without losing meaning. Include a tool-approval matrix that distinguishes public, enterprise, and restricted environments.

Ask for a task deliverable and the MINIMUM handling note. Introduce a late message that requests an extra analysis using a data field outside the original purpose. The participant should recognise the purpose change and decide whether to reject, minimise, or escalate the request rather than silently expanding the input.

Potential traps include:

  • copying a whole record when two fields would suffice;
  • assuming redaction is complete without testing it;
  • using an approved tool for a data class the configuration does not permit;
  • allowing the output to repeat or infer sensitive details;
  • saving temporary prompts in an unapproved location; and
  • treating a privacy notice or opt-out setting as a substitute for organisational approval.

Assess the handling trail, not a recital of policy

Review observable decisions across the full task:

Do not award full credit because the final document contains no names. The worker may have exposed unnecessary data during prompting and removed it only from the visible output. Conversely, retaining a necessary sensitive field in an explicitly authorised environment may be stronger handling than deleting it and making the deliverable misleading.

  • purpose control: the use remained within the stated task and recipient;
  • classification: relevant data categories and sensitivity were identified;
  • minimisation: each retained sensitive field had a task-specific reason;
  • environment choice: the worker checked the exact tool and configuration rather than relying on a brand name;
  • transformation quality: masking, aggregation, or substitution preserved task meaning without unnecessary detail;
  • output review: reproduction, re-identification, and sensitive inference were checked;
  • retention and escalation: the worker followed the given record rule and stopped when authority was unclear.

Sources

ICO: Guidance on AI and data protection

  • Government of Canada: Guide on the use of generative artificial intelligence
  • Government of Canada: Privacy and security for AI help applications
  • NIST: AI Risk Management Framework Core

Sources: [1] [2] [3] [4]