Protective Orders to Restrict AI Training on Produced Data: Artificial Intelligence Best Practices

A Protective Order Won't Stop AI Training on Your Evidence — Only Architecture Will

On September 10, 2026, Doug Austin at eDiscovery Today flagged a post from Cimplifi, "Stepping Up to the Plate: Protective Orders to Restrict AI Training on Produced Data," arguing that litigants should stop trying to ban AI outright in protective orders and instead write language that separates permissible uses — review, summarization, organization, drafting — from the one that actually matters: whether produced material can train or improve a model. The post draws the line between "closed" AI systems, run inside secured, contractually and technically restricted environments, and "open" public AI tools, and points to sample clause language and prior court rulings on the topic. No new rule or ruling accompanies it; it's guidance aimed at litigators drafting the next protective order.

What's the real distinction between a "closed" and an "open" AI system?

A closed system runs in a controlled environment with contractual and technical limits on data use; an open one is a public tool with no such guarantees.

That's the framework Cimplifi proposes, and it's the right axis — but it's also a framework any vendor can claim to satisfy just by saying so. "Closed" is not a certification, it's a description, and the post itself concedes protective orders should require "a reasonable basis to conclude" that confidential material won't be used for training. Reasonable basis is a legal standard, not a technical one. It gets satisfied by a declaration, a contract clause, or an actual architecture — and those are not interchangeable.

Why has a blanket AI ban stopped being good enough?

Because banning AI outright also blocks the review, summarization and coding efficiencies both sides now rely on in practice.

Cimplifi's point is that AI is already doing document review and drafting work across matters, so a protective order that pretends otherwise just gets ignored or renegotiated. The more useful order distinguishes uses, not tools — which pushes the real question down a level, to what technical controls back up the "closed system" label counsel is relying on.

What should a protective order actually require — and how do you check it?

It should require verifiable controls — tenancy, key ownership, no model training on client data — not just a vendor's written assurance.

A clause promising confidential material "will not be used to train models" is only as good as what a firm can audit. Single-tenant deployment, data staying inside the producing party's own cloud account under its own encryption keys, and a fail-close design that blocks processing rather than silently falling back to a shared model are the kind of specifics that make a protective order enforceable rather than aspirational. Sample clause language is a starting point; the deployment diagram is the evidence.

What should buyers ask their e-discovery vendor now?

Ask exactly where processing happens, who holds the encryption keys, and what "no training" means in the contract's actual terms.

Push past "we don't train on your data" to specifics: is the environment single-tenant or shared, does the firm or the vendor control the keys, and what happens on a system failure — does it stop, or does it quietly route to a less-restricted model? Those answers are what a protective order's language should be able to point to, rather than a vendor's marketing page.

Frequently asked questions

Did a court actually rule on this in September 2026?

No. This is practitioner guidance from Cimplifi, relayed by eDiscovery Today, drawing on existing case law and sample language — not a new decision or order.

Does "closed AI system" mean the same thing across vendors?

No. The term describes an approach, not a standard; firms should confirm tenancy, key control and training exclusions contractually and technically, not assume the label covers it.

Is this relevant beyond litigation drafting?

Yes. Any firm evaluating an e-discovery or review platform is implicitly answering the same question a protective order asks: can this vendor prove, not just promise, that produced data won't train a model.

Sources: eDiscovery Today, "Protective Orders to Restrict AI Training on Produced Data", discussing Cimplifi's post "Stepping Up to the Plate: Protective Orders to Restrict AI Training on Produced Data."