The setting everyone tells firms to ask for
If a law firm asks how to use AI on matter data without creating a confidentiality problem, the answer almost always lands on zero data retention. Configure the account so the provider does not store your prompts or the model's responses once the request is finished. Nothing sits on a vendor's disk waiting to be subpoenaed, breached, or reviewed by a contractor.
That advice is correct, and we give it. We have written about where zero data retention actually lives across the Claude surfaces, and about the three architectural tiers a firm can pick from. Zero data retention plus a business associate agreement plus a connector into the practice management system is the shape we build for most firms.
Then we went to configure it for a firm that wanted the most capable model available, and the request failed.
What actually happens
On the Anthropic API, an organization whose data retention is configured to zero gets a 400 invalid_request_error on every request to Claude Fable 5. Not a warning in the response. The request does not run. The model requires 30-day retention, and an organization that has turned retention off is structurally incompatible with it. There is nothing wrong with the request body, which is what makes it confusing the first time you see it.
On AWS Bedrock the same constraint appears in a different shape. Bedrock's default posture is strong, and AWS states it plainly in its own documentation:
"Amazon Bedrock uses a zero operator access (ZOA) data security model. This means no operators of the service can access model input or output. Also, Amazon Bedrock uses a zero data retention (ZDR) data security model. This means that by default, Amazon Bedrock does not store model inputs or outputs."
Two sentences later, the exception:
"For Anthropic Claude Fable 5, inputs and outputs will be retained for up to 30 days. In order to use Claude Fable 5, as required by Anthropic, you must opt in to sharing retained traffic with Anthropic for abuse detection and potential human review."
Read that second quote as a lawyer would, not as an engineer would. To use that model you agree to 30 days of retention, and you agree that the retained traffic may be shared with the model provider and looked at by a person. For a firm whose entire reason for configuring zero data retention was to keep privileged material out of third-party hands, that is the opposite of the thing it was trying to buy.
The same page adds one more detail worth knowing: "If cross-region inference is enabled for these models, retained inputs and outputs are stored in destination regions." So a firm with a data residency requirement that has also enabled cross-region routing can end up with retained privileged content sitting in a country it never chose.
Why this exists, and why it will keep happening
It is worth being fair to the providers here, because the reason matters for how you plan around it.
The retention is there for abuse detection. Frontier models carry more misuse potential in areas like cybersecurity and biology, and a retention window plus review is how a provider monitors for that. This is a safety mechanism, not a pricing tactic or an oversight. AWS notes that eligible customers can request full zero data retention through their account team, so there is a conversation to be had, but the default exists for a reason and it is not going to be waived casually.
The practical consequence is that this is unlikely to be a one-off. If the pattern holds, the newest and most capable model at any given moment will tend to be the one with the strictest monitoring attached, and the models that fall under clean zero data retention will tend to be the generation behind. A firm that wants both frontier capability and zero retention is asking for two things that currently point in opposite directions.
What this means when you pick a model
Model selection stops being a performance question and becomes a compliance question. That is the whole shift, and it changes who should be making the decision.
As of July 2026, Claude Opus 4.8, Claude Opus 4.7, Claude Sonnet 5 and Claude Haiku 4.5 all sit under the standard zero-data-retention posture and under Bedrock's default no-storage model. Claude Fable 5 is the current exception. That list will change, which is exactly the point: it needs rechecking every time a provider ships something new, and the check belongs in your deployment process, not in someone's memory.
Two failure modes follow from this, and they hit different firms.
The first is a firm that configures zero data retention correctly, then picks the best model off the pricing page, and quietly ends up with 30 days of retention and an opt-in to human review that nobody read. They believe they have a posture they do not have.
The second is a firm that gets the hard error, cannot work out why a valid request is failing, and starts loosening its retention configuration to make the error go away. That firm debugs its way out of its own compliance posture without ever deciding to.
Neither firm gets told. The behaviour is documented, but it sits several levels down a vendor documentation tree on a page about abuse detection, and you only find it if you go looking or if you hit the error in production.
The distinction underneath all of this
There is a deeper point that this whole situation surfaces, and it is the one most vendor evaluations skip.
Retention and access are different exposures. Retention governs what happens to your content after the request finishes. Access is whether the model processed the content at all. Zero data retention is a strong control over the first and does nothing about the second. Under any hosted configuration, including the strictest one, the model read the matter content in order to answer the question.
For privileged material, access is the exposure. That is why "nothing leaves your firm" is only an honest claim for a model running on hardware the firm controls, which we covered in the on-premise privilege stack. Everything else is a question of who can reach the content, under what terms, and for how long. Those are answerable questions with good answers. They are just not the same question as "is it stored."
A test you can run on any vendor
This gives you a short diagnostic that works on any legal AI product, including ours.
- Which model version are you calling on my behalf, by name?
- What does that specific version do with my inputs and outputs?
- Is retention on it zero, or is it a window, and if it is a window how long?
- Can a human at the model provider ever read my content, and under what conditions?
- What happens when you switch models, and will you tell me before you do?
That last one matters more than it looks. A packaged legal AI product that upgrades its underlying model to improve quality can move a firm from a zero-retention posture into a retention-and-review posture without the firm ever being asked. If the vendor cannot tell you which model they call, they cannot tell you what happens to privileged material, and the polish of the interface is not evidence about the pipeline behind it.
Where this leaves a firm
The honest summary is that for privileged work you are choosing a capability ceiling, and for most legal work that ceiling is high enough not to matter. Document drafting from firm precedent, contract review, matter summarisation and chronology building all sit well within the capability of models that support zero data retention. We build against those models and the output quality is not the constraint on those tasks.
What changes is that the choice has to be deliberate. Pin the model version, write down why that version was chosen, and recheck when the provider ships a new one. If a specific class of matter genuinely cannot tolerate any third-party processing, the answer is on-premise hardware, which is a real option carrying a real cost.
The firms that get burned here are not the ones that made the wrong choice. They are the ones that never knew a choice was being made.
Working out what your firm can actually run
We build the connector layer into Clio, MyCase and Filevine, configure the model and retention posture, and put the audit logging in place, owned by your firm, not rented from us. If you want the current model position checked against your own setup, that is what a discovery call is for.
Legal AI integrationVerified 22 July 2026 against Anthropic's API documentation and the Amazon Bedrock abuse detection page. Model availability and retention terms change. Check the vendor's current documentation before relying on any of it, including this page.
Frequently Asked Questions
Can a law firm use zero data retention with any Claude model?
No. As of July 2026, zero data retention covers most current Claude models but not all of them. On the Anthropic API, an organization whose retention is configured to zero receives a 400 invalid_request_error on every request to Claude Fable 5, because that model requires 30-day retention. On AWS Bedrock the same model is available only if you opt in to 30 days of retention and to sharing that traffic with Anthropic for abuse detection and potential human review. Every other current model runs under Bedrock's default no-storage posture.
Which Claude models can a law firm use under zero data retention?
As of July 2026, Claude Opus 4.8, Claude Opus 4.7, Claude Sonnet 5 and Claude Haiku 4.5 all run under the standard zero-data-retention posture on the Anthropic API and under Bedrock's default no-storage model. Claude Fable 5 is the exception and requires retention. Model availability changes, so confirm the current position against the vendor's own documentation before you rely on it. That includes trusting this page.
Why does the newest model require data retention when older ones do not?
Retention on that model exists for abuse detection. More capable models carry more misuse risk in areas like cyber and biology, and the retention window plus human review is how the provider monitors for it. That makes it a safety mechanism, which is worth understanding because it means the requirement is unlikely to be negotiated away, and it will probably apply to future frontier releases too.
Does zero data retention mean the AI never sees my client data?
No, and this is the distinction most evaluations miss. Retention governs what happens to content after the request. Access is whether the model processed the content at all. Under zero data retention the content is not stored after the response, but the model still read it in order to answer. For privileged material, access is the exposure. The only configuration where the content is never disclosed to a third party is a model running on hardware the firm controls.
Is a firm giving up capability by choosing zero data retention?
Yes, and it should be a deliberate decision instead of an accident. Choosing zero data retention today means choosing from the models that support it, which excludes the current frontier release. For most legal work the difference is small, because document drafting, summarisation and contract review are well within the capability of models that do support zero data retention. The point is to make the trade knowingly, and to check it again each time a vendor ships a new model.
