Sensitive data: anonymize properly and send only what is needed

A project manager wants to upload a spreadsheet with customer names and account numbers so Claude can find trends. Company policy restricts sharing regulated personal data. She has three possible impulses: upload it anyway because “it’s internal,” upload it and ask Claude not to keep it, or drop the analysis.

None of them is right. The way out is to prepare the data before uploading it.

The rule

With personal data, the question isn’t “can Claude read this?” but “does this task need this data?” You almost never need to know who each person is to find trends, themes or totals. So:

1. Minimize. Data minimization means sending only the fields the task needs. To see purchasing trends you don’t need the account number or the address.
2. De-identify. To anonymize or de-identify is to remove the direct identifiers (name, ID number, account number, employee number) and the indirect ones too.
3. If it’s enough, aggregate. Sometimes the safest thing is not to send individual records at all: aggregated data, such as totals by month and department, lets you analyse trends without data about any person.

Removing the name isn’t enough

The most common mistake is half-anonymizing. A people analyst deletes the names from exit interviews but keeps the employee number, the branch, the job title and the exact leaving date. In a six-person branch, with a single “warehouse supervisor” who left on 14 March, anyone can tell who it is: that is re-identification.

Indirect details worth removing or generalizing:

• employee numbers or any internal code that can be cross-referenced;
• job titles held by a single person;
• very small offices or teams;
• exact dates (month or quarter is better);
• witnesses, relatives or third parties mentioned in the text.

Replacing names with initials doesn’t anonymize either: in a small team, initials identify people.

What isn’t a control

What gets proposed	Why it doesn’t protect
“I’ll ask Claude not to store or reuse the file”	An instruction in the chat isn’t a control; the controls are which data gets uploaded and how the organization’s account is configured
“It’s an approved workspace, so I can upload everything”	The tool being approved doesn’t change what the policy says about certain data
“It’s for internal use”	The policy doesn’t distinguish internal from external analysis if it prohibits the data
“I’ll delete the conversation afterwards”	The data has already been shared

Don’t drop the task

The other extreme is also a trap: “since there’s health data, we won’t use Claude at all.” If the policy allows aggregated statistics, a benefits coordinator can build counts of leave by month and department and ask Claude for help with the trends and the commentary. The task goes ahead; the sensitive data stays out.

Common traps

• Uploading the file as is because the analysis is internal.
• Asking Claude to “forget” the data.
• Removing the name and leaving everything else.
• Replacing names with initials.
• Stopping the analysis when anonymizing or aggregating would have solved it.

On the exam

If the scenario mentions customer, employee or patient data and a policy that restricts it, the answer is almost always to prepare the data before uploading: remove direct and indirect identifiers, send only what the task needs or work with totals. In “choose two” questions, look for full de-identification and minimization together. Rule out instructions to Claude presented as a control, “it’s approved, upload everything” and dropping the task.