Claude Team Zero Data Retention: What to Verify
Claude Team’s commercial privacy terms do not make its chat interface a zero-retention service. Check the exact product, agreement, and data path before approving sensitive work.
Updated 5 min read
Standard Claude Team chat is not a zero data retention service. Anthropic’s published ZDR documentation excludes the Team product interface, so a Team subscription alone is not evidence that prompts and responses disappear after processing.
Zero data retention, or ZDR, is a specific data-handling arrangement, not another name for “not used for training.” Tools like fenbs help keep a person’s approved AI-use rules available to connected assistants, but do not turn a service into a zero-retention environment.
What does Anthropic’s ZDR documentation actually cover?
Anthropic’s API and data retention documentation (opens in a new tab) describes an arrangement for eligible API use, meaning requests made by software to Claude. It says Team and Enterprise product interfaces are not eligible under that arrangement. Claude Code on Enterprise has a separate offering for qualified accounts, requiring separate enablement.
The practical question is therefore “Which approved service processes this request?” rather than “Does our company pay Anthropic?” A browser conversation in a Team workspace and an application using an approved API organization are different paths. Approval for one does not establish approval for the other.
Ask the account owner for the specific agreement and configuration that apply to your intended workflow. If the answer is simply a screenshot of a Team subscription, you have established the plan, not a ZDR commitment. Our Claude Team plan guide covers the broader workspace; this review concerns retention eligibility.
How is retention different from training or deletion?
These controls answer different questions. A provider can keep a conversation so you can reopen it while agreeing not to use it to train a model. Likewise, a delete button can start a removal process without meaning that no copy was ever stored.
| Question | What it establishes | What it does not establish |
|---|---|---|
| Is content used for training? | Whether prompts and responses may help improve a model. | Whether content is stored or accessible to the organization. |
| How long is content retained? | Which data stays in which systems, under which policy. | Whether a colleague can open it through a shared project. |
| What happens when I delete it? | How removal is requested and completed. | That the service processed the content without storing it. |
| Who can access it? | Which users or organization roles can obtain the content. | Whether the provider’s storage policy is zero retention. |
Anthropic says commercial inputs and outputs are not used for model training by default (opens in a new tab). It also describes exceptions when people submit feedback or otherwise permit data use. Record training and feedback rules separately from your retention decision so neither becomes an accidental substitute for the other.
What happens to ordinary Team conversations?
Anthropic’s commercial retention policy (opens in a new tab) says products that save and continue conversations retain chats and coding sessions to provide that experience. Removing a chat from visible history and deleting it from backend storage are separate stages; the policy also describes safety, legal, and feedback exceptions.
Its Team and Enterprise deletion guidance (opens in a new tab) confirms that conversations are maintained for history and that Enterprise customers can set custom retention timelines. A shorter configurable timeline is still a retention policy. Do not label it ZDR unless the applicable commitment actually says so.
For a team deciding whether to summarize a confidential document, this distinction comes before convenience. Ask what category of information the policy permits, rather than whether you can delete the conversation afterward. A cleanup step cannot retroactively make an unapproved disclosure approved.
What evidence should your organization request?
Make the review narrow enough to answer. “Is Claude private?” mixes product scope, storage, training, administrator access, and connected services. A useful request identifies the intended work and asks the responsible reviewer to approve that exact combination.
- The product and account: Team browser chat, a desktop workflow, or a specific API organization, with the responsible owner identified.
- The permitted information: for example, public marketing drafts or approved internal specifications. Name excluded categories too.
- The applicable terms: the agreement, documented configuration, and any written confirmation needed to resolve a discrepancy.
- The data covered: prompts, responses, uploaded files, feedback, operational records, and any saved application history.
- The boundaries: which models, features, and connected services the approval covers, and what triggers another review.
Treat the answer as a human approval with evidence, not as a model’s interpretation of a sales phrase. The Enterprise versus Team comparison can help frame the wider plan choice, but a plan comparison is not your organization’s signed agreement.
Keep the resulting permitted-use rule in fenbs Decisions and rules. Save a safe summary and a reference to the evidence in its approved location; do not copy restricted contracts or customer records into another tool merely to document the review.
What if the workflow includes code or other services?
Map each stop separately. Your application might send a request to Claude, save the response in its own logs, and copy the result into a task system. Even an approved arrangement for model processing would not establish how your own application or another service handles its copy.
For a developer workflow, use the Claude Code ZDR guide for that distinct question. For ordinary collaboration, Claude Projects for teams explains the shared working context. Neither connection changes the need to identify the actual account and approved data path.
For example, a studio can permit Team chat for public campaign drafts while holding confidential client material for a separate review. The rule should tell an assistant to use a sanitized brief or ask for approval, rather than guess that every company tool has the same retention terms.
Turn a privacy review into a usable rule
Record which workflow a person approved, which information it may process, and what still needs a decision. Keep follow-up checks as tasks rather than burying them in a chat. The next connected assistant reads the project’s rules before continuing the work.
Create a free accountFree for one person · No credit card · Works with Claude, ChatGPT, Cursor and more
How to do this with fenbs
- Create a free account, then add a project for your team’s approved AI workflows. One person can start free, with no credit card.
- Add tasks for unresolved retention questions. Include the product being reviewed, the person responsible, and the evidence needed to complete the check.
- After a person approves the workflow, record the decision and its scope in Decisions and rules. Leave unanswered questions open.
- Connect a supported assistant through Integrations and ask it to read the project context before handling work governed by the rule.
- Save progress when a review changes the allowed workflow. Keep the current decision clear so a later assistant does not rely on an older approval.
fenbs does not provide Anthropic ZDR, change Claude retention settings, or replace a privacy review. It is not the right fit for storing material that your policy forbids sharing with it. Use it for the approved rules and work record, and consult the AI governance hub for related questions.