Anti-regurgitation clauses: stopping models reproducing your records

What is regurgitation, and why does it matter for business records?#

Regurgitation is a model reproducing text it memorized during training, word for word or close to it, in response to a prompt. Text that appears many times in the training data is especially likely to be memorized, and distinctive strings such as account numbers or codenames are the easiest reproductions to spot.

For licensed business records the risk is specific. A support ticket can carry a customer's account details that survived preparation, an email thread can hold pricing language, and a standard operating procedure can contain distinctive wording a competitor would recognize. If a public model repeats that text, the supplier faces confidentiality, privacy and relationship problems that no payment term covers.

An anti-regurgitation clause moves that risk back to the party that controls the model. The buyer trains, tests and deploys, so it is the only party able to prevent reproduction at the output stage. Outputs are also treated as a separate category of exposure in AI copyright disputes: the release in the final Bartz v. Anthropic class settlement covers only past conduct and expressly does not release claims about AI outputs.

Sample anti-regurgitation wording#

Sample wording, for discussion with counsel and not for use as drafted: Licensee shall not, and shall ensure that no Model trained in whole or in part on the Licensed Data will, generate any Output that reproduces a Licensed Record, or a substantial portion of a Licensed Record, verbatim or in near-verbatim form, as determined under the Matching Standard in Schedule C. Licensee shall maintain the Output Controls and Testing Program in Schedule C for as long as any such Model is used.

The operative promise is short on purpose. The work sits in the schedule, which defines what counts as a match, how testing runs and what happens when a test fails. A clause without that schedule tends to collapse into an argument about what near-verbatim means after an incident has already happened.

Two drafting choices shape the clause. An absolute obligation is stronger for the supplier but harder for a buyer to accept; a commercially reasonable efforts standard is easier to sign but weaker unless the testing and remedy terms are specific.

Definitions that decide whether the clause works#

The definitions decide whether an output can be tested against the clause at all. Each term below is a place where buyer drafts commonly stay vague.

Testing terms that make the clause enforceable#

Testing terms turn the promise into something both sides can verify. The supplier cannot inspect model weights, so its protection comes from agreed tests, agreed reports and a way to run checks of its own.

Keep the canary list and the Protected Strings list with a small group on the supplier side, such as the general counsel and the person who prepared the delivery. If the buyer learns which records are canaries, it can filter those strings alone and pass every test while the rest of the records remain exposed.

• 1Canary records: the supplier seeds a small number of unique, harmless records before delivery and keeps the list private, so any reproduction is detectable.
• 2Pre-release extraction testing: the buyer prompts the model with record openings and Protected Strings and measures matches under the Matching Standard before each release.
• 3Re-testing after material changes: new fine-tunes, retraining or new products that expose the model trigger a fresh test.
• 4Reports to the supplier: a short summary of tests run, matches found and fixes applied, delivered on an agreed schedule.
• 5Supplier test rights: the supplier, or an independent tester it names, may submit prompts through an agreed channel.
• 6Logs: the buyer keeps enough output logs to investigate a reported reproduction.

Remedies when a model reproduces your records#

Remedies should match the seriousness and frequency of the failure. A single reported output calls for a fast fix, while a pattern found in testing or a repeat after remediation calls for stronger steps. Fixed deadlines should be agreed in the schedule rather than left to reasonable time.

Illustrative: an industrial distributor protects its pricing exceptions#

Illustrative: a fictional industrial distributor plans to license order exception records from NetSuite and the customer service email threads that resolved them. Its concern is that customer names and negotiated pricing language could surface in a public model.

Before delivery, the company removes customer and contact identifiers, replaces contract numbers, deduplicates repeated email signatures and disclaimers, and seeds a handful of canary records. Its counsel adds a Protected Strings list of customer name formats and internal pricing codes to Schedule C.

During the buyer's pre-release testing, one canary record is reproduced in response to a prompt built from its opening line. The buyer traces it to duplicated copies in a training shard, removes them, adds an output filter and reports the fix. The distributor's counsel reviews the report and accepts the remediation under the agreed process.

Limits of the clause and how SourceX approaches them#

No clause can promise that a model will never reproduce any training text, and buyers will resist wording that suggests otherwise. The clause works best as a backstop to preparation: records with identifiers removed, duplicates reduced and boilerplate stripped are much less likely to surface in the first place.

SourceX puts most of the effort upstream. Identifiers, repeated signatures and confidential details are dealt with in Preparation, and the supplier approves the release before Delivery, the last of the five steps in a SourceX transaction. Any output restrictions the supplier negotiates are listed under permitted use in the SourceX Evidence Packet, so the testing schedule and remedies sit beside the records they protect.