How Do You Preserve AI Training for Copyright Litigation?

Many of the copyright cases involving generative AI eventually reach a deceptively simple factual question: Was the plaintiff's copyrighted work used to train this model?

Answering that question can require reconstructing a technical process that occurred months or years earlier. An AI developer may acquire enormous collections of data and then subject them to filtering, deduplication, formatting, tokenization, mixing, and other preprocessing before training begins. Different versions of those datasets may feed different training runs. Models may later undergo fine-tuning or other post-training. Intermediate files and checkpoints may be deleted as part of ordinary engineering practice.

By the time a copyright lawsuit arrives, the model in production may bear a different version number, use a different training corpus, and sit several training runs removed from the model the plaintiff actually cares about. That makes preservation unusually difficult. Saving a copy of the current model will rarely answer the central question. The real task is preserving enough of the model's lineage to reconstruct what happened during the relevant training run.

Training Data Is Not One Thing

Lawyers discussing AI litigation often refer to "the training data" as though it were a single database. The actual process can be considerably more complicated. A copyrighted work might appear in an initial source collection, move into a curated corpus, survive one filtering process but not another, appear in a deduplicated dataset, be incorporated into a particular training mixture, and ultimately be consumed during one training run but not another. Those distinctions can matter in litigation because there is a difference between showing that a company possessed a copy of a work and showing that the work survived preprocessing and was actually included in data used to train a particular model.

Courts are beginning to recognize that distinction. In the Google generative AI copyright litigation, plaintiffs sought source code in an effort to determine whether their works had been used to train Google's models. The court denied that request after Google represented that the relevant evidence was in the training datasets rather than the source code, then approved a protocol for inspection of those datasets. The OpenAI copyright MDL has likewise adopted a specific Training Data Inspection Protocol defining training data as data used to train relevant OpenAI large language models.

Training data is developing into a distinct category of technical evidence, with discovery practices of its own.

The Discovery Question Is Really About Lineage

For preservation purposes, possession of the individual artifacts may be less important than the ability to connect them.

Suppose a company still possesses three enormous datasets, five versions of its training code, several model checkpoints, and years of development records. That sounds like extensive preservation. But if the company cannot establish which dataset was used with which code to produce which checkpoint, the evidence may be far less useful than its volume suggests.

A meaningful preservation record might need to connect a particular training run to the relevant source corpus or dataset version, the resulting training mixture, preprocessing and deduplication steps, the code commit used for the run, material configuration information, the resulting checkpoint, and later fine-tuning that changed the model. Depending on the architecture, useful lineage evidence may include dataset manifests, object identifiers or hashes, run IDs, job metadata, preprocessing logs, configuration files, checkpoint identifiers, tokenizer versions, and records showing when particular artifacts were created or replaced.

The appropriate list will vary by system. What matters is preserving the relationship among the records. Several terabytes of preserved information do little good if nobody can later establish which pieces belong to the training event at issue.

A Model Snapshot Does Not Reconstruct the Training Run

Software litigators are accustomed to preserving source-code versions and builds. The analogy is helpful, but AI training introduces additional layers. A particular software release can often be tied to a source-code commit, dependencies, build configuration, and release artifact. Version-control and build systems are designed in part to preserve those relationships. A trained model is also an artifact produced by a technical process, but the final weights generally do not provide a convenient inventory of the works used to produce them.

Preserving the model checkpoint alone may therefore leave the central copyright question unanswered. A better analogy is preservation of a reproducible build, including the important inputs and the records connecting them to the resulting product.

Even that analogy has limits. Modern training runs may use enormous datasets distributed across complex infrastructure. Exact bit-for-bit reproduction of a large training run may be impractical or unnecessary. Litigation preservation may instead require enough reliable evidence to establish what data was used, how it was processed, and which model resulted. The goal is evidentiary reconstructability, not necessarily the ability to rerun the entire training job.

Some of the Most Important Evidence May Normally Be Temporary

The hardest preservation questions may involve records that engineering systems were never designed to retain for years.

Training pipelines can generate temporary shards, transformed datasets, intermediate checkpoints, logs, cached data, failed-run information, and other artifacts that are routinely overwritten or deleted. Some may have little independent business value after the training run finishes. Once litigation is reasonably anticipated, however, counsel needs to know which of those transient records could bear on the claims.

That requires more than sending a conventional litigation-hold notice to the engineering department. Counsel needs someone who understands the actual training architecture to explain what exists, what is persistent, what rolls off automatically, what can be recreated from other records, and what would be lost permanently if ordinary retention policies continue.

Rule 37(e) asks whether ESI that should have been preserved was lost because a party failed to take reasonable steps to preserve it. The Advisory Committee Notes recognize both that perfect preservation is often impossible and that proportionality matters. They also contemplate intervention in the routine operation of electronic systems when litigation requires it. AI training presents a particularly difficult application of that framework because routine operation may itself involve overwriting enormous quantities of potentially relevant technical information.

Preservation Should Follow the Training Events That Matter

The phrase "continuously changing AI model" can obscure how many systems are actually developed. Large models often undergo identifiable pretraining, fine-tuning, or other post-training events. A deployed model does not necessarily rewrite its weights every time a user submits a prompt.

That distinction makes a more targeted preservation regime possible. Once a preservation duty arises, the company can identify the model versions and training runs reasonably implicated by the dispute. Later preservation decisions can focus on materially relevant events, such as another training run using the disputed corpus, a significant change in preprocessing, an important fine-tune, or deployment of a new model version bearing on the claims.

That may be more defensible than either extreme of preserving every temporary training artifact indefinitely or taking one snapshot of whatever model happens to be running when the complaint arrives. The preservation plan should also be revisited as the case develops because discovery may identify additional relevant training runs or eliminate others from contention.

Counsel Needs to Distinguish Acquisition, Processing, and Actual Training Use

Copyright litigation may put several stages of the pipeline in issue. Counsel may need to determine where the work came from, when the company acquired it, which upstream corpus contained it, whether it survived filtering or deduplication, whether it was present in the dataset or mixture prepared for the relevant training run, whether that dataset was actually used in training the model at issue, and whether the work was also used in later fine-tuning or other post-training.

These distinctions are especially important after decisions such as Bartz v. Anthropic, where the court separately analyzed acquisition and retention of pirated books and their use in model training.

The preservation problem therefore cannot always begin and end with the final training dataset. Upstream records may bear on acquisition claims, while downstream records may be necessary to prove or disprove actual training use. For an AI company facing copyright claims, knowing which stage of the pipeline a particular record proves may become as important as finding the record itself.

Training-Data Discovery Is Starting to Look Like Source-Code Discovery

Courts and parties are already borrowing procedures familiar from software litigation. Rather than requiring unrestricted production of extremely sensitive technical information, AI cases increasingly use dedicated inspection protocols.

OpenAI's consolidated copyright litigation has a separate court-approved Training Data Inspection Protocol. Anthropic has used a protocol governing inspection of both training data and source code in Bartz. The reason is obvious: training data, model weights, preprocessing methods, and training infrastructure may contain valuable trade secrets, licensed material, personal information, or confidential third-party data.

Preservation and production therefore need to be treated separately. A company may need to preserve technical evidence broadly enough to satisfy its litigation obligations while negotiating much narrower procedures for what opposing lawyers and experts may inspect, where they may inspect it, what tools they may use, and what information may leave the secure environment.

Patent and software litigators will recognize the architecture. The difference is the object of inspection.

Scale Will Force Courts to Make Proportionality Decisions

AI systems also create preservation volumes that can make ordinary litigation instincts unreliable.

A useful example comes from a different category of AI evidence. In July 2026, a federal court addressing Anthropic's preservation of prompt and output records confronted a dataset that was growing rapidly under a short retention cycle. Rather than requiring preservation of the entire universe, the court ordered preservation of a deduplicated random sample of 500 million records plus records containing specified terms.

Prompt and output logs are not training datasets, but the order illustrates the preservation problem AI litigation will repeatedly present. The relevant systems may generate information at a scale where "keep everything" is neither a serious technical instruction nor necessarily a proportionate litigation position.

Training evidence will raise similar questions. Does every intermediate checkpoint need to survive? Every failed run? Every temporary transformed copy of the corpus? Every log generated by preprocessing? The answer should depend on the issues in the case, whether the information exists elsewhere, the burden of preservation, and the evidentiary value of the particular artifact.

Those decisions are much easier to defend if counsel and engineers make them consciously and document the reasoning before information disappears.

Good Lineage Records Can Be Defense Evidence

Preservation is easy to think about as something done for the plaintiff. For an AI developer, good lineage records may be equally important to the defense.

A plaintiff may identify a copyrighted work that appeared in a large corpus acquired by the company. That does not necessarily establish that the work was used to train the model at issue. Reliable records may show that the work was filtered out, removed as a duplicate, excluded from a later dataset, or included only in training a different model.

Without those records, the company may have to reconstruct events years later from partial evidence and employee recollection. Provenance and lineage therefore have litigation value independent of compliance. They can narrow claims, resolve factual disputes, and sometimes establish that the factual premise of an infringement theory is wrong.

Building AI Systems That Can Be Reconstructed Later

Most AI development infrastructure was built to make models better and training faster, not to make future copyright discovery easier. That may need to change.

A company developing commercially significant models should know whether it can connect major deployed versions to the data and training events that produced them. That does not require preserving every intermediate artifact forever, but it does require enough durable metadata and version information to reconstruct the relevant history when necessary.

Once litigation is reasonably anticipated, the preservation inquiry becomes more specific. Counsel should identify the training runs at issue, work with technical personnel to understand what records exist and which are ephemeral, preserve the material artifacts and lineage evidence, and decide deliberately which ordinary deletion or overwrite processes need to be suspended.

The question worth asking is more precise than "Did we save the model?"

Can we reconstruct what data was used in the training run that produced this model, and can we prove the lineage?

As AI copyright cases move deeper into discovery, the companies that can answer that question should be in a much better position than those trying to reconstruct their training history after the systems that created it have moved on.