AI restrictions in protective orders: the new e-discovery battleground

Why are protective orders suddenly addressing generative AI?

Sidley Austin reported in April 2026 that protective orders have become an emerging point of dispute in discovery, with courts requiring contractual no-training safeguards, deletion capability, and onward-disclosure limits before produced material may touch AI tools ^[1]. That is a significant shift. Historically, a protective order governed people and paper: who could see designated documents, how they were stored, and what happened at the end of the case. The new disputes are about software supply chains. A single produced document routed through an AI-assisted workflow may pass through a review platform, a hosted model, and one or more sub-processors, each with its own retention behavior.

The producing party's concern is straightforward: if confidential material is used to train or improve a third-party model, no clawback provision can retrieve it. Deletion at matter end becomes meaningless if the information has already influenced model weights or persists in vendor logs. Courts responding to these disputes are effectively asking the receiving party to prove, contractually and operationally, that the AI pipeline is a closed loop ^[1]. That is why the fight now happens at the protective order stage, before a single document is produced, rather than after a problem surfaces.

It helps to see why the older protective order machinery does not stretch to cover this. A clawback provision works because a misdirected document is a discrete object that can be identified, sequestered, and returned. An attorneys' eyes only designation works because a human being can be instructed and, if necessary, held accountable. Both mechanisms assume that confidentiality is recoverable, that a mistake can be walked back. Generative AI breaks that assumption in a specific way: the harm the producing party fears is not that a document is seen by the wrong person but that its content is absorbed into a system where it can no longer be located as a discrete object. Once that has happened, there is nothing left to claw back. The protective order therefore has to prevent the exposure rather than remedy it, and prevention has to be negotiated in advance because it cannot be improvised after the fact.

This reframing also explains the timing. The tooling that makes AI-assisted review attractive, hosted models reachable through an ordinary review platform, arrived faster than the standard forms that govern discovery could adapt. Counsel who inherited a protective order template from a prior matter are working from language that predates the risk, and the emerging disputes reported in 2026 are, in part, the friction of old forms meeting new pipelines ^[1]. The practical lesson is not that AI is disqualifying in discovery. It is that the protective order is now the place where the parties decide, deliberately, what the AI pipeline is allowed to be.

What did the court require in the Morgan case?

Kirkland & Ellis analyzed the leading example in May 2026: a District of Colorado decision, referred to as Morgan, that charted a path on AI, protective orders, and work product in discovery ^[2]. The court required that AI tools processing confidential discovery material carry three concrete protections: no-training safeguards, so produced material cannot be used to train or improve the underlying models; onward-disclosure limits, so the material does not flow to additional parties or processors beyond those contemplated; and deletion capability, so the material can actually be removed when the obligation to destroy it arises ^[2].

Morgan matters because it converts abstract anxiety about AI into a checklist a court was willing to enforce. Litigants on both sides can now anchor negotiations to a judicially articulated baseline: if you want AI tools to touch produced documents, come to the table with training, disclosure, and deletion answers. It also signals that courts will engage with the technical architecture of AI vendors rather than treating "no AI" or "any AI" as the only options. A receiving party that can satisfy the Morgan-style conditions has a credible route to using modern tooling; one that cannot may face categorical restrictions.

Read closely, the three requirements are not arbitrary. Each one closes off a distinct path by which confidential material could escape the closed loop the producing party is trying to build. No-training safeguards address the most irreversible exposure, the possibility that produced content is used to adjust a model in ways that cannot be undone. Onward-disclosure limits address propagation, the tendency of modern software pipelines to fan material out to sub-processors and downstream services that were never named in the negotiation. Deletion capability addresses persistence, the reality that material can outlive its authorized purpose in logs, caches, and retained copies unless the workflow is built so that it can actually be removed. Taken together, the three requirements describe the lifecycle of a produced document inside an AI pipeline and place a control at each stage where it could otherwise leak.

The framing of Morgan as a path rather than a rule is worth holding onto ^[2]. The decision gives negotiators a shared vocabulary and a defensible starting position, which is genuinely useful in a field where first-impression questions leave counsel improvising. But a path charted by one court is an invitation to reason from, not a national standard that binds the next judge. The value of Morgan is that it lets both sides argue from a concrete, court-tested set of conditions instead of trading abstractions about whether AI is safe.

Where are federal courts diverging on AI, privilege, and work product?

Morgan is not the whole picture. Akin reported in February 2026 that federal courts are issuing diverging first-impression rulings on generative AI in the context of privilege, work product, and protective orders ^[3]. These are questions of first impression in most districts, which means individual judges are reasoning from analogy, and their analogies differ. The result is a genuinely unsettled landscape: the treatment your AI workflow receives may depend heavily on which courthouse you are standing in, and a favorable ruling in one district is no assurance of the same outcome in the next.

For practitioners, divergence changes strategy in two ways. First, silence is risk. If the case law does not reliably supply an answer on whether AI processing is permissible, waives protection, or requires safeguards, the protective order itself must supply one. Second, precedent from another district is a negotiating aid, not a safety net. Citing Morgan may persuade, but a party that builds its entire AI workflow on the assumption that every court will follow it is making a bet the current case law does not support ^[2][3]. Negotiated, explicit terms remain the only dependable protection.

Divergence at the first-impression stage is not surprising when you consider what the judges are actually being asked to do. Privilege and work product doctrines were built around human conduct: what a lawyer knew, what a lawyer prepared in anticipation of litigation, whom a communication was shared with. Applying those doctrines to a generative model requires an analogy, and there is no settled consensus about which analogy fits. Is routing a privileged document through a hosted model more like handing it to an outside vendor, more like storing it on a cloud server, or more like disclosing it to a third party in a way that risks waiver? Reasonable judges can land in different places, and until appellate courts or rulemakers supply a common framework, the reports of divergence describe a field that will stay uneven ^[3].

The strategic implication is that counsel should treat the case law as weather rather than climate. It tells you the conditions in a particular district at a particular time; it does not give you a stable rule you can build a repeatable workflow around. That is precisely why the emphasis keeps returning to the negotiated instrument. When the background law is unsettled, the protective order is the one document whose terms the parties actually control, and the surest way to reduce the uncertainty divergence creates is to resolve it explicitly on the page rather than hope a court resolves it the way you would prefer.

Which AI clauses should you negotiate into your next protective order?

The emerging disputes and the Morgan framework point to a concrete negotiating agenda ^[1][2]. Rather than arguing about AI in the abstract, counsel can propose specific provisions that allocate risk and make compliance testable. The goal is a protective order that permits efficient, modern review while giving the producing party enforceable assurances about where its material can and cannot go. Five clauses recur across the current disputes:

Each clause maps to a failure mode the courts have already confronted: unknown tooling, irreversible training, uncontrolled vendor sprawl, undeletable copies, and unverifiable promises ^[1][2]. Parties will reasonably disagree on scope, for example whether restrictions cover all AI-assisted tools or only generative models, and on how audit rights are exercised. But a protective order that addresses all five topics, in either direction, is far less likely to generate motion practice later than one that never mentions AI at all.

• Disclosure of which AI tools will touch produced material, so the producing party knows the actual pipeline rather than a generic category.
• No-training and no-retention contractual safeguards, ensuring produced documents cannot be used to train or improve third-party models.
• Onward-disclosure limits covering sub-processors, so material does not silently propagate down the vendor chain.
• Deletion capability and a certification of deletion at matter end, making destruction obligations operationally real.
• Audit or verification rights, so compliance representations can be tested rather than merely accepted.

These five topics are a negotiating agenda, not a form to drop into every order. Scope, definitions, and enforcement mechanics are matter-specific and should be worked out with counsel who know the record and the venue. This is informational, not legal advice.

How do the five clauses map to the risks courts have already seen?

The five clauses are not five ways of saying the same thing. They defend the produced document at five different points in its journey through an AI pipeline, and a gap at any one point can undo the protection the others provide.

It is worth pausing on why these particular five clauses keep recurring rather than some other list. Each one exists because it neutralizes a failure the current disputes have surfaced, and reading the clauses against their failure modes shows that they are not redundant. A tool-disclosure clause and a no-training clause sound related, but they defend against different problems: disclosure defeats the risk that the producing party never learns what pipeline its material actually entered, while a no-training safeguard defeats the risk that, once the material is in the pipeline, it is used in a way that cannot be reversed ^[1][2]. You can have one without the other, and a producing party that secures only one has left the other gap open.

The table below lines up each negotiating topic with the concrete risk it addresses. The pattern is that the clauses move in sequence with the lifecycle of a produced document: first you establish what tools are in play, then you constrain how they may use the material, then you constrain where the material may travel, then you ensure it can be removed, and finally you make the whole arrangement testable rather than aspirational. A protective order that covers the first four topics but omits verification has described a closed loop without providing any way to confirm the loop is actually closed, which is a weaker position than it looks.

Why is a clause on paper different from isolation in practice?

A negotiated clause records an obligation; it does not, by itself, describe what happened. This is the gap that turns a well-drafted protective order into a source of later dispute. A no-training clause states that produced material will not be used to train a model. Whether the receiving party's actual workflow honored that promise is a separate, factual question, and the answer lives in how the tooling was configured and operated over the life of the matter, not in the language of the order. The clause tells you what was supposed to happen. It does not tell you what did.

That gap is manageable when nobody asks, and acute when someone does. As long as the workflow runs quietly, the difference between a promise and a practice is invisible. The moment a dispute arises, or the moment a protective order's audit or verification rights are invoked, the difference becomes the whole case: the party that made the representation is now asked to show that its operations matched its words. Marketing pages, vendor terms of service, and an after-the-fact declaration are all still representations. They restate the promise; they do not independently establish the fact. The stronger position is to have generated evidence of the practice while the practice was happening, so that the record does not depend on anyone's willingness to take the promise on faith.

This is also why the audit or verification clause is doing more work than it appears to. It is the clause that converts the other four from statements of intent into commitments that can be checked, and a party that agrees to verification rights without building the ability to satisfy them has taken on an obligation it may not be able to meet. Anticipating verification is therefore not a compliance afterthought; it is part of designing the workflow in the first place, so that if the question is ever asked, the answer already exists in a form someone who does not trust your infrastructure can evaluate.

How do you demonstrate compliance after the order is entered?

Signing the order is the easy part. The operational question arrives months later, when opposing counsel, or the court, asks whether the confidential material produced in the case ever entered a retraining-capable model. A contractual no-training clause tells you what was promised; it does not tell anyone what actually happened inside your workflow. Vendor terms of service, marketing pages, and after-the-fact declarations are representations. If the protective order includes audit or verification rights, the receiving party needs something stronger than assertions: contemporaneous records showing which tool processed which material, under which policy, with what isolation.

This is where verifiable attestation earns its place in litigation workflows. A signed attestation that binds each AI interaction to the approved tool, the governing policy, and the isolation method turns a compliance representation into a verifiable record that can be checked by someone who does not trust your infrastructure. RankShield produces those attestations: signed, independently verifiable evidence that confidential material was architecturally isolated from third-party AI models and handled under informed consent controls. That demonstrates a compliance posture; it does not guarantee how any court will rule, and courts and parties decide what satisfies a given order. But when the question is asked, the firm holding verifiable records is in a categorically better position than the firm holding assurances.

It is important to be precise about what an attestation can and cannot do, because overstating it would be its own kind of risk. An attestation is evidence about architecture and handling: it can show that a given interaction was routed to an approved tool, governed by a stated policy, and isolated from third-party models under consent controls. It is not a ruling on privilege, and it does not preserve work product protection by itself; those are legal determinations that a court makes on the full record. RankShield is a technology vendor, not a law firm, and its records are inputs a party can offer, not substitutes for the judgment of counsel. The claim is bounded on purpose: attestation proves isolation and consent were in place, which is exactly the factual question a verification clause tends to raise, and it leaves the legal conclusions where they belong.

Practically, the value shows up as a change in posture rather than a promise of outcome. When the field is unsettled and the burden can shift to the party that used AI tools, being able to produce contemporaneous, independently verifiable records converts a defensive scramble into a straightforward disclosure. The firm that planned for verification answers the question by pointing to evidence it already holds. The firm that did not is left assembling declarations after the fact and hoping they are believed. Neither posture dictates how a court will rule, but the difference in position is real, and it is available to any party willing to treat verification as part of the workflow rather than an afterthought.

What should litigation teams do before the next matter?

The threads above converge on a short, practical readiness list. None of it requires predicting how the case law will settle, which is fortunate, because the reports of diverging first-impression rulings suggest it will not settle quickly ^[3]. Instead, the readiness posture is about controlling the variables a litigation team actually controls: the terms it negotiates and the records it keeps.

First, treat the protective order as the primary control surface for AI, and raise it early rather than discovering the issue mid-review. Second, know your own pipeline before you represent anything about it, because a tool-disclosure obligation is only as good as your understanding of which systems actually touch produced material. Third, negotiate for the ability to prove what you promised, and build the workflow so that proof is generated contemporaneously rather than reconstructed under pressure. The steps below sketch that sequence.

1. Raise AI at the protective order stagePut AI handling on the negotiating table before production begins, so the pipeline is defined deliberately rather than contested after a problem surfaces ^[1].
2. Map your actual toolingIdentify which AI systems and sub-processors would touch produced material, so any disclosure or no-training representation reflects the real pipeline rather than a generic category.
3. Anchor to the Morgan conditionsUse no-training safeguards, onward-disclosure limits, and deletion capability as a concrete, court-tested starting point for negotiation, while remembering it is one court's ruling, not a national standard ^[2][3].
4. Build verification in from the startIf the order carries audit or verification rights, generate contemporaneous, independently verifiable records of tool, policy, and isolation as the work happens, so the answer exists before the question is asked.