Apply data sensitivity, regulatory, and privacy considerations
Decide what data may enter Claude and in what form by applying your organisation's classification levels, minimising and anonymising personal data, using the approved plan, and respecting regulatory context such as GDPR and HIPAA.
Key points
- 1
Start from the organisation's data classification (for example Public, Internal, Confidential, Restricted) and the policy that maps each level to what may be entered into approved AI tools. Published material is Public; customer records, deal information, health data and pay data are not.
- 2
Minimise: give Claude only the fields the task needs. Remove or pseudonymise direct identifiers (names, emails, account numbers, member IDs) before upload, and keep any re-identification key in your own systems.
- 3
Removing names alone does not de-identify a dataset; dates of birth, account or member IDs, diagnosis codes and free-text notes can still identify people.
- 4
Tokenised templates (for example {{first_name}}) let you draft personalised communications without sending personal data; the approved email or CRM system fills in the real values.
- 5
Consumer plans (Free, Pro, Max) are personal accounts governed by consumer terms and the user's own privacy settings; work data belongs in the organisation's Team or Enterprise workspace, which has admin controls and audit logging.
- 6
On Team and Enterprise plans, inputs and outputs are not used to train Anthropic's models by default. On consumer plans the user controls a model-improvement setting, and incognito chats are never used for training. Training is only one risk, so these defaults do not replace your organisation's approval and minimisation rules.
- 7
Enterprise administrators can set custom data-retention periods for chats and projects; by default data is retained until deleted. Retention is a plan and admin setting, not something a prompt can change.
- 8
Instructing Claude to 'not retain', 'delete after use' or 'ignore the identifiers' is not a data control and does not satisfy policy; the data has already been shared.
- 9
Project knowledge is visible to everyone the Project is shared with, and Project instructions are not access control. Remove or reduce sensitive content in the knowledge itself and share only with people who need it.
- 10
Regulatory context at a business-user level: GDPR emphasises lawful basis, minimisation and purpose limitation for personal data of EU residents; HIPAA governs protected health information in the US. When a dataset is regulated, confirm with the data owner or privacy team before using it, and use the approved workspace with a de-identified extract.
- 11
Interns, contractors and new joiners without workspace access must not fall back to personal accounts; the correct move is to pause and get access or approval.
- 12
The official sample item for this task: when a spreadsheet holds customer names and account numbers and policy restricts regulated personal data, remove or anonymise the identifiers before uploading; uploading as-is, telling Claude not to retain it, and skipping the analysis are all wrong.
Read the source
Test yourself on Apply data sensitivity, regulatory, and privacy considerations
Ten questions, with the answer and explanation after each one.