Your AI Review Vendor Can Swap Models Mid-Matter. Check Your Contract

The model-update clause sits in the vendor agreement, not in the review screen.

GenAI review has moved into daily eDiscovery work while pricing frameworks have not kept pace, and contract structure remains an unresolved question that buyers must settle before a vendor settles it.

The Winter 2026 eDiscovery Pricing Survey, run by ComplexDiscovery OÜ with the Electronic Discovery Reference Model and drawing 53 completed responses across 25 questions, found buyers weighing the promise of AI efficiency against "unresolved questions around exception handling, quality control, and contract structure." Law firms made up 43.4% of its respondents. The uncertainty, in other words, belongs to the people who sign.

Contract structure is where I would begin, because it conceals the question that matters most in litigation. Ask the vendor, in writing, which model will read these documents at the first production, and who decides whether the same model is still reading them at the last. The documents will not have changed. The reader will have.

Courts do not ask for a motionless machine. They ask for transparency, and some have gone so far as to expect the producing party to name the software and describe how its results were validated, which is a reasonable demand until one realizes that a validation performed against one model says very little about the model that replaced it, so the first document worth reading is not the vendor's brochure but the change clause folded quietly into its terms.

What does your AI review agreement actually say about model updates?

Most agreements fix the price, which can run cents per document against roughly $19K/GB for manual review, yet leave the choice of model to the vendor.

I would read the modification clause first, because it is usually the shortest paragraph in the agreement and the one with the longest reach. Pull the master agreement, the order form and any AI addendum, and check four things:

1. Find the language that lets the vendor modify, update or replace the service, and see whether it mentions models at all.
2. Confirm which service tier you bought, since AI terms can shift from one tier to the next.
3. Look for any promise to warn you before a change takes effect.
4. See whether the rate is tied to a named model or only to a document count.

Tier matters more than most buyers suppose. Even vendors concede, in their own presentations, that AI terms differ from provider to provider and from one tier of service to the next, so that two firms on the same platform may hold quite different rights over what the machine does with their documents and when it may be changed beneath them.

The platforms are changing shape as well. A commenter on the r/ediscovery forum reported in November 2025 that Relativity's aiR was scheduled to be integrated into Relativity's hosting environment beginning in April 2026, making it effectively a "free" part of the platform rather than a potentially expensive add-on. A feature you did not buy separately is a feature you cannot easily refuse. Its upgrade schedule becomes the host's schedule. There is something almost feudal in the arrangement, for the tenant pays a settled rent while the lord keeps the right to rebuild the house around the tenant, who learns of the new staircase only by falling down it.

Pricing tells the same story from the other side. The Winter 2026 eDiscovery Pricing Survey by ComplexDiscovery OÜ and the Electronic Discovery Reference Model found that hybrid models and per-document billing each account for roughly 28% of reported primary GenAI review pricing models, with $0.11 to $0.50 per document emerging as the competitive zone. Conventional wisdom treats a locked rate as a locked service. The rate fixes what each document costs and says nothing about which model reads it.

In our analysis, the gap between cents and dollars per document is a delta a buyer can see on their own matter, which is exactly why the cheaper reviewer has become worth guarding. A review of 4 sources suggests the pattern is structural rather than accidental: tiered terms, bundled features and per-document prices all move the upgrade decision toward the vendor. Anyone weighing per-matter against annual platform pricing should read the model clause beside the rate card, as one reads the small print of a treaty beside its preamble, and should ask, before the first batch is coded, what becomes of a review already validated when the vendor throws the switch.

Why does a mid-review model change threaten a validated AI review?

Validation describes one model's coding, so a later swap leaves the numbers vouching for a reviewer that has gone, and an append-only audit trail is what shows where the seam fell.

Validation, in this setting, means testing a review's output against human judgment on samples and reporting how often the two agree. Quinn Emanuel's March 2026 publication on AI in defensive discovery explains that generative AI review is trained with written prompts closely resembling a human review protocol, and that it "is not an iterative process once the prompts have been run over the corpus." The prompts are tested, revised and validated with standard metrics before the full run. Then the run happens once.

Every figure that comes out of that validation is a statement about a particular model reading a particular corpus under particular instructions. Sirion's vendor guide to document review describes quality control as senior attorneys sampling batches of reviewed documents to find inconsistencies in coding, and after a swap the practical step is to draw those samples from both sides of the change date, since that seam is where any inconsistency will gather. The very title of an article in the Journal of Technology Law & Policy, on statistically defending artificial intelligence in document review, tells you where the defense of such a review lives. It lives in the numbers. So ask the vendor, before the first batch runs, whether its logs will tie every coding call to the model version that made it.

Contrary to a widely held view, the danger is not change itself. Continuous active learning refines its model in real time as reviewers code, and courts accepted it all the same; in Rio Tinto PLC v. Vale S.A., the Southern District of New York called permission to use TAR "black letter law." What courts have never been asked to bless is a change that nobody designed, measured or wrote down, which is the precise character of a vendor upgrade landing in the middle of rolling productions, like a new clerk taking over a ledger halfway down the page without initialing a single entry.

The practitioners who handle this best keep the record close to the document. One describes a workflow in which the reviewer opens and cites the underlying document before marking anything responsive or privileged, routes low-confidence or novel items to an exception queue, and requires human sign-off before production; the characteristic failure, in that account, is a fluent summary that drops its qualifiers. A model swap can multiply that failure quietly. Fluency survives an upgrade. Qualifiers may not.

Our own approach rests on immutable originals with content hashing, append-only audit trails and a documented chain of custody, so that the process holds up if opposing counsel challenges it, and that is the same discipline a firm should demand of any vendor whose model might move. I have come to think the question worth asking is not whether a model changed but whether anyone can prove when it did. As models converge, a theme taken up in what happens when every legal AI has a good model, a vendor will feel less and less hesitation in exchanging one for another, and the contract is the only place where that hesitation can be manufactured, which brings us to the clauses themselves.

Which contract clauses keep an AI review reproducible?

Before signing, bring a messy collection and a hard question to the demo, then ask in writing for a pinned model, advance notice and the right to revalidate.

I ask for three things, and I ask for them before the first prompt is written, because a clause negotiated after the coding has begun is a clause negotiated from weakness:

1. Pin the model version for the life of the matter. The order form should name the version that will code your documents and bind the vendor to run it until the matter closes or you release it.
2. Require advance written notice before any change, with the right to stay on the current version or to revalidate, at the vendor's expense, before the new version touches a single document of yours.
3. Preserve the record of every coding decision: the model version, the prompt or configuration, the inputs, the outputs, the timestamps and the human decisions that accepted or overrode them.

The third clause is where the usual advice stops, and the common assumption is that preservation is enough. It is not. A perfect log of a model you can no longer run is an epitaph, not a reproduction; it tells the court what the reviewer said and cannot make the reviewer say it again.

The economics of reruns sharpen the point. In a July 2025 thread on r/ediscovery, practitioners explained that nobody fed a whole collection to the machine at the outset; they tested and refined prompts on small sets of about 50 documents, and one described AI review as "pay per play," unlike general assistants that allow unlimited retries. A tuned prompt is tuned to one reader. Change the reader and the tuning becomes folklore. If a vendor's upgrade forces that work to be redone, the contract should say who pays, and the answer ought to be the party that chose to change.

Set side by side, the gap between a silent agreement and a negotiated one looks like this:

Before: a general clause that, in substance, lets the provider modify or update the services from time to time. After: For each matter, the provider will run the model version named in the matter order, will not substitute another version without advance written notice, and will, at the client's election, either continue the named version or revalidate the new one at its own expense before applying it. The first sentence governs a subscription. The second governs a case.

Two further terms deserve a place, and on both I can speak for our own design. At Relevant, processing runs single-tenant or inside your own AWS account under your own keys, with no vendor retention and no model training, so nothing you feed it trains anyone's model or waives privilege; ask any vendor to put the equivalent in writing. And because our outputs link back to the exact exhibit they came from, an attorney can verify each answer in one click before filing, which is the habit a records clause should make contractual rather than optional. Ask, too, how the vendor reports the documents its pipeline could not process, a question taken up in the processing exceptions your vendor isn't showing you, because a version log that omits them is a log with a hole in it.

The demonstration is the natural moment to raise all of this. A buyer who watches a tool read, code and cite their own evidence, rather than a case study about someone else's, has every reason to ask whether the reader at work that afternoon will still be at work in June, when the second production goes out and the first is already in opposing counsel's hands.

How do you defend an AI review when opposing counsel learns the model changed?

Answer with validation, not with the model's name: show the coding was tested before and after the update, and that the contract let you pause, compare and revalidate.

Volume is about to make the question unavoidable. A reviewer posting on Reddit in September 2026 wrote: "Our company reviewed 1M documents a month last year at this time. Now we are averaging more than 1M per day." The same commenter added, "The floodgates are opening." When one provider codes in a day what it once coded in a month, any update to the model will land in the middle of somebody's matter, and the forecast I draw from that figure is a plain one: within the next year or two, the date on which a vendor changed its model will become a fact a litigator must be ready to explain, as surely as the date a custodian was interviewed.

The reported decisions ask for candor rather than for a frozen model. Disclosing the AI's use to the opposing party has been treated as the minimum, and some courts have gone further, requiring the producing party to name the specific software and describe how its results were validated. Predictive models had already been coding documents for more than a decade by 2024, retraining as reviewers fed them new calls, and their acceptance never rested on their standing still. It rested on the numbers. Apiko, a software developer, praises one legal AI tool in its buyer's guide because each answer shows the agent's decision path, so you can "audit or tweak logic mid-stream"; a firm that accepts that invitation has made a model change of its own, and should date and validate it as carefully as any vendor's. And yet a model swapped between March and June is a witness replaced by a sibling between direct examination and cross, the face familiar and the voice close, with nobody left in the room who can vouch for the testimony.

Were I the one standing up to answer the challenge, I would want the record to show three moves, made in this order, after the vendor's notice arrived:

1. Pause new coding on the matter, leaving every document already coded under the old version exactly as it was.
2. Compare the updated model against the old one on documents the old version already coded, and keep every disagreement, since the disagreements are what opposing counsel will ask about.
3. Roll back or revalidate: return to the pinned version if the calls diverge, or rerun the validation if you adopt the new one, and log the date, the version and the result either way.

None of that sequence can begin until someone tells you the model changed. Under standard terms, the telling is left to the vendor's discretion, which makes the next renewal, rather than the next meet-and-confer, the moment to ask for it in writing.