We build AI integrations for regulated firms. Two of the things we ship are open-source MCP connectors that let Claude work directly inside Clio and MyCase. Building those, and scoping the workflows on top of them, forced us to get specific about a question that comes up on nearly every call: how do I run privileged client data through Claude without it being retained?
The answer most people start with is wrong, and it's wrong in a way that wastes weeks. So let's be precise.
Can you get zero-data-retention on Claude Team? No.
Zero-data-retention is not a setting on Claude Team or Claude Pro. Those are chat products. Team is the small-business chat tier, and it retains conversation data under its own policy (commonly cited at around 90 days). You can email Anthropic and ask them to enable ZDR on your Team workspace, and the request will go nowhere, because you're asking the wrong product to do something it isn't built to do.
This trips up technically sharp founders constantly. They reason: "Anthropic clearly supports zero-retention, I've seen it in the enterprise docs, so it must be a flag they can set for me." The flag exists. It's just on a different product.
The one-sentence version: ZDR is not available on Claude Team chat. It is available on the Anthropic API, granted at the API-organization level, which a small firm can obtain. If you've been chasing ZDR on Team, you've been asking the wrong product.
Where ZDR actually lives: the Anthropic API
Anthropic offers zero-data-retention on the API, and it's granted at the level of an API organization, not by seat count. That distinction is the whole game for a small firm. You don't need to be big to qualify. You need an API org and a ZDR arrangement on it. A four-person practice can apply for the same control that a large enterprise gets.
Two things are worth separating here, because people conflate them:
- Training opt-out is the default on the API. Anthropic does not train its models on your API inputs and outputs unless you opt in. You get this without doing anything special.
- Zero-data-retention is a stronger, separate control. It governs whether your prompts and responses are stored at rest after the request completes, not just whether they're used for training. This is the one you arrange explicitly.
For privileged or regulated content you want both: training off (you already have it) and retention off (you arrange it). The mental model that helps: training opt-out answers "will my data shape the model?" ZDR answers "will my data still exist on a server tomorrow?"
Why not just buy Enterprise?
Claude Enterprise chat does come with zero-retention by default, so it's a legitimate option. The problem is the floor. Enterprise carries a seat minimum, roughly 20 on self-serve and 50 sales-assisted depending on how you buy. A firm of four to fifteen people would be paying for seats it doesn't have just to get a retention property it can get another way.
We've watched small firms talk themselves into a six-figure Enterprise commitment to solve a problem the API solves for the cost of usage. If your real need is "run a defined workflow through Claude with nothing retained," the API under a ZDR arrangement is almost always the right-sized answer. Buy Enterprise when you actually want enterprise chat for a real headcount, not as a backdoor to ZDR.
Where each Claude surface stands on retention
| Surface | ZDR available? | Granted at | Right-sized for |
|---|---|---|---|
| Claude Pro / Team chat | No (retention policy applies) | — | Everyday chat, not privileged pipelines |
| Claude Enterprise chat | Yes (default) | Plan level | Real headcount (seat minimum applies) |
| Anthropic API (Messages) | Yes (arranged) | API organization | Defined workflows, firms of any size |
The residency wall: Claude has no Canadian region
Here's where it gets harder, and where we've spent real time. ZDR controls whether data is stored. It does not control where a request is processed. Those are different questions, and regulated practices, family law in Canada, anything under PIPEDA, anything touching PHI, care about both.
As of mid-2026, Anthropic has no Canadian data region. The API processes in the United States. There is no setting that keeps a Canadian firm's Claude calls inside Canada at rest. If your obligation is strict data residency, you can't make that obligation disappear by buying a different Claude tier, because the region doesn't exist to buy.
What you can do is make the cross-border step controlled, minimal, and documented:
- Pin inference to a known region. The API lets you constrain where processing happens. Pinning to the US means the location is known and stated rather than ambiguous.
- Layer ZDR on top. Pinning answers "where," ZDR answers "for how long." Together: processed in a known place, retained nowhere.
- Keep your records in-country. Your practice-management data does not have to follow the AI call across the border. Clio runs a Canadian region (ca.app.clio.com, PIPEDA-aligned). Your matters, notes, and documents can sit in Canada while a single API call briefly crosses to the US and leaves nothing behind.
- Write the cross-border step into your own record. For lawyers, professional-conduct guidance (the Law Society of Ontario's 2024 generative-AI white paper, conceptually aligned with ABA Formal Opinion 512) leans on confidentiality, competence, and supervision. Documenting that one US-processed, zero-retention step is part of meeting that duty.
We'll say the uncomfortable part plainly, because pretending otherwise is how firms get burned: if your rule is "data may never leave Canada at any instant," then routing through Claude is not compliant today, full stop. ZDR plus US-pinning is the honest mitigation for "data may not be stored outside Canada and any transit must be controlled and documented." Know which rule you're actually bound by before you architect anything.
ZDR only covers some API surfaces. This is the trap.
This is the gotcha that doesn't show up until you're building. A ZDR arrangement applies cleanly to plain Messages API calls. It does not automatically extend to every adjacent feature, and several of the most convenient ones carry their own retention behavior.
Surfaces to keep a privileged pipeline off unless you've confirmed their retention terms for your account:
- Files API — uploaded files persist by design; that's the point of it.
- Batch API — asynchronous jobs hold results for retrieval over a window.
- Code execution — the sandbox environment has its own lifecycle.
- Server-side MCP connector — the hosted connector path is a different surface than a local stdio MCP server running on your own machine.
The practical rule we follow: if privileged content is in the request, it goes through plain Messages and nowhere else. The convenience features are fine for non-sensitive work. They are not free passes for client data. We learned this the hard way scoping a document-handling workflow, where the obvious "just use the Files API" path quietly broke the retention guarantee we'd promised.
The architecture we actually recommend: local-first on a shared firm ZDR org
Once you internalize that ZDR is an organization-level API property and not a per-machine setting, a clean pattern falls out. The ZDR guarantee lives on a single firm-level Anthropic API organization, one shared credential, independent of where the code runs. So you can run the workflow locally on each person's machine and still get the same retention guarantee, because every local install calls the same ZDR-enabled key.
For a small firm that wants minimal data on third-party servers, this is the sweet spot:
- Run local. Each user's machine runs the integration. Practice data is pulled from your systems, used, and not parked on someone else's server.
- Point every install at one ZDR org key. The retention property is centralized in the API org even though execution is distributed. No hosted middle-tier required to get ZDR.
- Keep a human gate. Whatever the AI drafts goes to a person before it counts. For lawyers this isn't optional polish; mandatory human verification of AI output is what LSO guidance and ABA Opinion 512 are built around.
A hosted middle-tier is a real option, not the default. It earns its keep when you genuinely need central audit logging or real-time event handling across many users. If you don't, it's a server full of privileged data you didn't have to stand up. When a hosted tier is justified, host it in a Canadian region, keep it zero-persistence and in-memory, and put a central audit log on it. But start by asking whether you need it at all.
A note on the rest of your stack
Claude is rarely the only place data flows. The same residency-and-retention thinking applies to every vendor in the chain. If you're piping a Zoom consult transcript into Claude, for example, Zoom's AI-generated content (its meeting summaries) isn't guaranteed to stay in a Canadian data center either, and those summaries can auto-expire, so the reliable pattern is to pull the recording's VTT transcript and store it fast in your own Canadian systems rather than trusting it to live where you'd like. Practice-management platforms differ too: Clio and MyCase both have regional hosting choices; PracticePanther and others vary. Audit the whole path, not just the model.
This is also why we're cautious about no-code automation glue like n8n or Zapier for privileged workflows. The convenience is real, but every hop is another place data can rest or cross a border you didn't intend. For regulated work, fewer hops and known retention beats a slick automation that no one can fully account for.
The short version
- ZDR is not on Claude Team or Pro chat. Stop asking for it there.
- ZDR is on the Anthropic API, granted at the org level, obtainable by a firm of any size.
- Training opt-out (default) and ZDR (arranged) are different controls. For privileged data, get both.
- Enterprise chat has ZDR by default but a seat minimum. Don't over-buy it just for retention.
- There's no Canadian Claude region. Mitigate with ZDR plus US-pinned inference plus documentation, and keep records in-country.
- ZDR covers plain Messages API. Keep privileged pipelines off the Files API, Batch, code execution, and the hosted MCP connector unless terms are confirmed.
- Local-first on one shared firm ZDR org gives small firms strong retention control without a hosted server.
Frequently asked questions
Can I get zero-data-retention on Claude Team?
No. ZDR is not a feature of Claude Team or Claude Pro. Those are chat products with their own retention policies (Team chat commonly retains conversation data for around 90 days). ZDR is offered on the Anthropic API and granted at the API-organization level, which a firm of any size can apply for. Asking Anthropic to enable ZDR on a Team account is asking the wrong product.
Is zero-data-retention available to small firms?
Yes, through the Anthropic API. ZDR is granted per API organization, not by seat count, so a four-person firm can obtain it. That's different from Enterprise chat, which has a seat minimum (roughly 20 self-serve, 50 sales-assisted). Build the workflow on the API under a ZDR arrangement rather than over-buying Enterprise just to get retention control.
Does Claude have a Canadian data region?
No. As of mid-2026 Anthropic has no Canadian region; the API processes in the US. For a Canadian firm, the practical mitigation is ZDR plus pinning inference to the US so the processing location is known, plus documenting the cross-border step for your professional-conduct obligations. Records can still stay in Canada (for example, Clio's Canadian region, ca.app.clio.com) while a single API call briefly crosses the border with nothing retained.
Which Anthropic API features does ZDR cover?
ZDR applies cleanly to plain Messages API calls. Adjacent features can fall outside a basic ZDR arrangement or carry their own retention, including the Files API, Batch API, code execution, and the server-side MCP connector. If retention guarantees matter, keep the privileged pipeline on plain Messages and avoid routing client content through those surfaces unless their terms are confirmed for your account.
Is Claude on the API trained on my data by default?
No. Anthropic does not train its models on API inputs and outputs by default, even before a ZDR arrangement. ZDR is a separate, stronger control governing whether prompts and responses are stored at rest after the request. For privileged or regulated data you generally want both: training off (default) and ZDR (retention off).
Building an AI workflow on privileged data?
We build Claude integrations for legal and healthcare firms, and we maintain open-source MCP connectors for Clio and MyCase. If you're trying to run client data through Claude without it being retained, and you want to know what's actually possible versus what the marketing implies, we'll give you a straight technical answer.
Book a 30-minute architecture call →
Or read more from our legal-tech practice: