Claude privacy update: why personal accounts and connected apps need governance
Anthropic published a new Privacy Policy on June 8, 2026, with an effective date of July 8, 2026. It is not the kind of AI news that sounds exciting like a new model release. But it matters for any company where people use personal Claude Free, Pro, or Max accounts next to company data, Claude Code, Google Drive, Slack, Notion, GitHub, or other connected apps.
The short version: Anthropic says this change applies to consumer accounts. It does not apply to Claude Team, Enterprise, the Developer Platform/API, or other services covered by commercial terms. That distinction is the practical point. A managed Team/Enterprise account or API setup is not the same operational environment as a developer’s, marketer’s, or consultant’s personal Pro account.
What changed
Anthropic groups the update into several areas. The most important one is multi-step tasks and connected apps. The Privacy Policy now gives more detail about the data involved when Claude performs longer tasks, uses connected services, or follows a user’s instruction to read, send, modify, or retrieve information from an external application.
In practice, this means Claude is no longer just a chat box in many workflows. It can work with documents, content from connected services, and in some cases actions outside Claude itself. The policy therefore talks explicitly about inputs, outputs, agentic sessions, connected services, and the fact that third-party services process data under their own rules.
Other parts cover age or identity verification, research participation, clearer explanations of sharing with third parties, legal bases for processing, and recommendations or service communications. Anthropic also repeats that it does not sell user data, Claude remains ad-free, and users can control whether conversations are used to improve models.
Why this is a company issue
Formally, this is about consumer accounts. Practically, it is a company issue because many teams adopt AI before they have account governance in place.
Typical scenarios:
- a developer has a personal Claude Pro account and connects a repository or local project through Claude Code,
- a sales person drops a CRM export into a personal chat,
- marketing connects personal Claude to Google Drive with internal documents,
- a consultant uses a personal account to summarize customer emails,
- someone enables a connector that keeps access beyond one specific session.
None of this automatically means there is a problem. It does mean the company needs to know which account, which plan, and which contractual terms are being used. A personal AI account is not the same as a managed business environment.
What I would change in practice
1. Separate personal and company use
First, I would write a simple rule: personal Claude Free/Pro/Max is fine for public research, learning, generic writing drafts, and experiments without sensitive data. It is not fine for customer records, internal documents, source code, invoices, contracts, HR material, or production incidents.
If AI is supposed to work with real company data, it belongs in a Team/Enterprise account, an API account with a clear owner, or another approved environment.
2. Audit connected apps
I would treat connected apps like Oauth applications:
- who connected what,
- which folders, repositories, or workspaces AI can access,
- whether the access is one-off or continues until disconnected,
- whether the third-party service may receive inputs, outputs, and instructions,
- who approves new integrations.
This is more useful than a long training session telling people to be careful. An integration is a more persistent risk than a one-off prompt.
3. Set rules for Claude Code
Claude Code is a strong tool, but with personal accounts the boundaries need to be explicit. In a company, I would not run personal Claude Code over private repositories, customer exports, or production logs.
A more sensible process is: company account, limited permissions, audit trail, sandbox, explicit approval for destructive actions, and a rule that sensitive files are not sent to the agent without a reason.
4. Update the internal AI policy
A good internal policy does not have to be long. One page can be enough:
- which AI accounts are approved,
- which data can and cannot be used there,
- who approves connectors,
- how CRM exports, support data, invoices, and emails are handled,
- what developers and internal agents should do,
- where people ask when they are unsure.
I would add concrete examples: lead triage in CRM, support classification, invoice extraction from email, internal knowledge bases, document extraction, and code review. People understand the boundary faster through real workflows than through legal wording.
Where there is no need to panic
It would be wrong to turn this into a headline like “Claude will take all company data.” The official update says something narrower: the consumer Privacy Policy is changing, it explains agentic and connected-app scenarios in more detail, and it explicitly does not apply to Team, Enterprise, Developer Platform/API, and other commercial services.
For companies, this is a reminder that AI governance is not only about model choice. It is also about account ownership, connectors, permissions, retention, training, and audit steps.
My recommendation
If your company already uses Claude, I would do three quick things now:
- Find out how many people use personal Claude accounts for work.
- Prohibit or restrict company data in personal accounts, especially connected apps and Claude Code.
- Move real workflows to managed Team/Enterprise/API environments with clear rules.
This is not administrative busywork. Once an AI agent reads folders, pulls data from a CRM, classifies support tickets, or works inside a repository, it is no longer just a prompt. It is a system with access. Systems with access need governance.