Claude and company data: personal accounts, 30-day retention, and ZDR

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.

August 22, 2026 update: a commercial account no longer automatically means ZDR

Since June, Anthropic has applied a separate regime to its most capable ’covered models’. Claude Fable 5, Mythos 5, and future models in the same class require at least 30 days of prompt and response retention so that abuse patterns can be investigated. Anthropic’s official documentation explicitly says Zero Data Retention is unavailable for these models. Other models and standard API rules are not automatically affected.

On August 20, Bloomberg Law reported, citing a person familiar with the plan, that Anthropic expects to let enterprise customers keep the required 30-day logs in their own cloud later this year instead of on Anthropic infrastructure. That would change data custody, not remove retention. For now, it is a reported plan rather than a released public feature; Anthropic’s current documentation still describes the existing 30-day policy.

OpenAI is taking a different route. On August 19, it announced a preview of Private Safety Processing for eligible API and enterprise customers. Automated systems are intended to detect risky patterns across interactions and return limited safety signals without giving OpenAI personnel access to the underlying prompts and responses. The goal is to preserve ZDR for frontier models. This is still an early preview with initial customers, not a universal guarantee for every account and product.

Companies therefore need a better procurement matrix than “we have Enterprise, so the data question is solved”:

is the prompt and response stored, or only a narrow safety signal,
where does the data remain and who controls the encryption keys,
how long is it retained and what incident exceptions apply,
who can read it and how access is audited,
does the rule apply to the exact model, API, Claude Code, Bedrock, Vertex AI, or another deployment path.

For invoice email processing, CRM enrichment, support tickets, production logs, or private repositories, do not select only by benchmark. Verify the data regime of the exact model and deployment first. An approved vendor does not mean every model has the same retention policy.

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. But for covered models, a commercial setup does not automatically mean ZDR; retention must be checked for the exact model and cloud.

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.