AI reps and warranties in software acquisitions: what sellers now promise

What are AI reps and warranties in a software deal?#

AI reps and warranties are statements in a purchase agreement about how the target company builds, uses and supplies artificial intelligence, and about the data behind it. Buyers added them because the standard IP and privacy reps never asked the questions that now matter: what trained the model, which tools wrote the code, and who else holds a copy of the data.

Each rep is backed by a disclosure schedule. The rep states a general promise, and the schedule lists the exceptions the seller is disclosing, such as a specific data license or a model fine-tuned on a licensed dataset. If a rep proves untrue, the buyer's remedy usually runs through the indemnity provisions, an escrow or holdback, or a representations and warranties insurance policy.

For a seller, the practical point is simple. What you disclose on the schedule is generally not a breach; what you leave off may become one.

Which AI rep categories show up in purchase agreements?#

AI rep packages tend to cover the same handful of categories, although drafting varies widely between buyers and law firms. The table lists the categories software sellers see most often and the schedule or evidence that usually sits behind each one.

What does a training data representation cover?#

A training data representation is the seller's promise about the origin and permitted use of every dataset that trained or fine-tuned its models. Buyers press hardest here because a provenance problem cannot be patched after closing; a model trained on data the company had no right to use may need to be retrained or withdrawn.

Case law explains the concern. In Thomson Reuters v. Ross, the district court rejected a fair-use defense for copying Westlaw headnotes to build a competing AI legal-research tool, and a Third Circuit panel affirmed that result in late September 2026, as reported by LawNext. The case involved a non-generative tool, so its reach into generative AI training is still debated, but buyers read it as a reason to ask for a source-by-source account.

Disclosure laws add a second reason. California AB 2013 requires developers of generative AI systems to post documentation about their training data, including whether datasets were purchased or licensed and whether they include copyrighted material or personal information. A target within that law needs the same records a buyer will request in diligence.

• 1Which datasets trained or fine-tuned each model, and over what date range?
• 2Was each source created internally, licensed, purchased, scraped or supplied by customers?
• 3Which license or contract permits the training use, and does it allow commercial models?
• 4Did any source include customer personal data, and under what notice or consent?
• 5Has any data owner asked for deletion, objected or threatened a claim?

How data licenses you granted show up in diligence#

Data licenses the seller has granted to AI developers appear on the material contracts and IP schedules, and buyers read them line by line. A license of support tickets or code review records can keep earning for the company, but it can also limit what the buyer may do with the same records later.

Sellers who documented each license when it was signed, with a clear record of what was delivered and who approved it, answer these questions quickly. Sellers who did not often end up rebuilding the history from email threads while the buyer waits.

Schedules to prepare before the data room opens#

The schedules a seller prepares before diligence shape how the AI reps get negotiated. Building them early also surfaces problems while there is still time to fix them, such as a contractor who never signed an IP assignment or an old customer template that is silent on AI use.

• 1AI feature and system register: every product feature and internal workflow that uses a model, with the model provider and where it is hosted.
• 2Training source register: each dataset, its origin, rights basis, date range and any restrictions.
• 3Customer contract matrix: which template versions and negotiated agreements allow, restrict or say nothing about AI use.
• 4AI tool register: coding assistants and writing tools staff use, the plan or license tier, and the policy that governs them.
• 5Outbound data license log: licensee, records licensed, scope, exclusivity, term and approval record.
• 6Notice history: each version of the privacy notice and terms of service, with effective dates and how customers were told.
• 7Incident and complaint log: anything involving models, prompts, training data or AI outputs.

How sellers narrow AI reps in negotiation#

Sellers narrow AI reps with definitions, qualifiers and time limits rather than flat refusals. A precise definition of AI system keeps a rep from sweeping in every spreadsheet macro, and a defined list of laws is easier to stand behind than a promise of compliance with every AI law in every jurisdiction.

Knowledge qualifiers limit a rep to what named officers actually knew. A lookback period limits how far into the company's history the promise reaches, and a survival period limits how long after closing a claim can be brought. Buyers push back on each, so decide in advance which matter most to you.

Watch for special indemnities. Some buyers ask for a separate indemnity for AI or training data claims that sits outside the general cap and basket. If a representations and warranties insurance policy excludes AI risk, the buyer may ask the seller to cover that gap directly.

Illustrative: a construction software vendor prepares its AI schedules#

Illustrative: a fictional vendor of submittal and RFI software for general contractors is preparing for a sale. Its product uses a hosted language model to summarize RFI threads, and the company previously licensed a de-identified package of its own support tickets and engineering issue histories to an AI developer.

The buyer's first draft included a flat rep that no customer data had ever been used to train any model. The general counsel and CTO built a training source register and an outbound license log. They showed that the summarization feature used a third-party model under terms that excluded training on customer content, and that the licensed package held company support records with customer details removed under a documented approval.

With those schedules attached, the parties replaced the flat rep with a disclosure-based rep, and the special indemnity the buyer had requested was limited to the one disclosed license. The sale proceeded on that basis.

How SourceX approaches deals where records were licensed#

SourceX documents each completed license with a SourceX Evidence Packet covering provenance, licensing rights, permitted use, the privacy record and release authorization. Those are the facts a training data or outbound license schedule needs, so a seller can point to the packet instead of reconstructing history during diligence.

Each license runs through the SourceX five-step transaction of Supply, Rights, Preparation, Approval and Delivery, and the supplier approves every step. Data is licensed, not sold outright, so the company keeps ownership of its records and a future buyer acquires them intact. This is general information; deal terms are assessed with your own counsel.