Is our data ours to license? What a rights check for AI training data covers

A rights check for AI training data is a written review that confirms a dataset is actually yours to license before any licence is drafted. It answers six questions: who owns the data, which contracts touch it, whether it contains personal data, which laws restrict it, which uses will be allowed, and how it will be delivered and deleted. If any of those answers cannot be documented, the data is not licensed until they can be.

This article walks through the six areas Liciva publishes in its rights checklist, the evidence that answers each one, and how to do a first pass inside your own company before you talk to anyone.

What is a rights check, and why is “we hold it” not enough?

A rights check is the step between a sample and a licence. It confirms, in writing, that the company offering the data can grant the rights an AI team needs: to copy, process, train on and evaluate with the data, for a defined term, without a third party being able to object later. It happens before the licence is drafted.

Most companies did not collect their data with licensing in mind. The records were made by employees, contractors and customers, under contracts and privacy notices written for a different purpose. Whether you can hand a copy to an AI team has four possible answers: yes, yes with exclusions, yes after a fix, or no. The rights check finds out which applies and writes it down. It is the third of the five steps in every Liciva deal, after the mutual NDA and the sample, and before the licence.

Why does how you got the data matter as much as what you do with it?

Recent copyright litigation has separated two questions that used to be merged: whether training a model on a work is permitted, and whether the copy used for training was lawfully obtained. A court can answer yes to the first and no to the second. That is why a rights check asks where every record came from, not only what it will be used for.

The clearest example is Bartz v. Anthropic. In June 2025, a federal judge in San Francisco ruled that Anthropic’s use of books to train its Claude models was fair use under US copyright law, but that its copying and storage of more than 7 million pirated books in a “central library” infringed the authors’ copyrights and was not fair use, according to Reuters. The judge doubted any infringer could explain why downloading from pirate sites, when the books could have been bought, was necessary to a later fair use.

The parties then settled. Reuters reported final approval of a 1.5 billion dollar class settlement on 20 July 2026, the largest known copyright settlement in the United States, and NPR put the per-title payout at roughly 3,100 dollars. The use was permitted. The acquisition was not. The bill followed the acquisition.

The EU is pushing the same way from the regulatory side. Under Article 53 of the EU AI Act, providers of general-purpose AI models must have a policy to comply with EU copyright law, including respecting rights reservations, and must publish a sufficiently detailed summary of the content used for training. Article 113 applies those obligations from 2 August 2025, and the Commission’s template FAQ confirms the summary obligation runs from that date. A model provider that must publish where its training data came from will ask its suppliers the same question. The rights memo is the answer you hand them.

What are the six areas a rights check covers?

Liciva’s rights check covers six areas, published on the homepage so nobody has to take a vague promise on trust: chain of title, third-party terms, personal data and consent, restrictions, use limits, and delivery and deletion. Each is reviewed and written up before any licence is drafted. Together they cover ownership, contracts, people, law, scope and logistics.

The order matters. Chain of title comes first because nothing else is worth checking if the company cannot grant the rights at all. Delivery and deletion come last. For each area below: the question, the evidence, and the usual failure.

Chain of title: who created it, who owns it now, and can you grant these rights?

Chain of title is the documented line from whoever created the data to the company that wants to license it today. For data, it has three links: who made each record, under what terms ownership passed to your company, and whether your company can grant AI training rights to a third party. A break in any link is a break in the chain.

Evidence that answers it:

• Employment contracts with an intellectual property clause covering work made in the course of employment.
• Contractor and agency agreements with an assignment of IP, not only a licence to use.
• Acquisition documents, if the data came with a company or a product you bought.
• For user-generated content, the terms of service in force when it was created, and whether they let your company license it onward.

What typically fails: contractor work with no written assignment, so the contractor still owns it; records created jointly with a partner under an agreement that is silent on data; terms of service that cover running the service but say nothing about licensing content to others.

Third-party terms: what did you promise someone else?

Third-party terms are the contracts and licences that limit what you may do with data even though you own or hold it. The question is not who owns the data but what you agreed with other people about it. Open-source licences, vendor terms, customer contracts and reseller agreements all belong here.

Evidence that answers it:

• The licences attached to any code, models, fonts, images or datasets mixed into the collection.
• Your standard customer contract and any negotiated variations, especially confidentiality and data-use clauses.
• Vendor and platform terms for the systems the data lives in, some of which restrict bulk export or secondary use.
• Supplier agreements for any data you bought in rather than created.

What typically fails: a private repository that includes code under a copyleft licence, which travels with the code; customer contracts that promise data will be used only to deliver the service; a bought-in data feed whose terms forbid redistribution.

Personal data and consent: who is in the data, and on what basis?

This area asks whether the data contains information about identifiable people, what legal basis covers using it for AI training, and how any de-identification was done and tested. “We removed the names” rarely clears it on its own.

The European Commission’s guide to data protection defines personal data as any information relating to an identified or identifiable living individual, and notes that different pieces of information which together can identify a person also count. It states plainly that data which has been de-identified, encrypted or pseudonymised but can still be used to re-identify a person remains personal data under the GDPR. Only irreversible anonymisation takes data out of scope.

Evidence that answers it:

• A data map of which fields and free-text areas can contain personal data, including names in email bodies, voices in recordings and faces in footage.
• The privacy notices and consents in force when the data was collected, and whether they cover this use.
• The de-identification method, who applied it, and the results of any re-identification test.
• For recordings, consent to record and any likeness releases.

What typically fails: privacy notices that describe one purpose and would need to stretch to cover another; de-identification applied to structured fields but not to free text; recordings made under a consent that covers quality monitoring, not model training. Buyers now expect a documented answer here. When Google bid for Spirit Airlines’ old business data, a Google spokesperson told Business Insider it was not looking to buy any personal information and that any such data would be excluded or de-identified by an independent third party. If your archive is mostly email and chat, the companion piece on licensing employee emails and chat logs goes further.

Restrictions: which laws and duties limit this data?

Restrictions are the rules outside your contracts that can stop a licence regardless of who owns the data. The main ones are export controls, sector regulation, confidentiality duties owed to clients or regulators, and limits that attach to certain data types such as health, financial or location records.

Evidence that answers it:

• Whether any technical data falls under export control classifications, which matters for engineering and some scientific data.
• The sector rules that apply to the records, such as health, financial services or legal privilege.
• Regulator conditions or grant terms that govern what the organisation may do with its data.
• Professional confidentiality duties, for instance where the data came from clients of a law, accountancy or engineering firm.

What typically fails: CAD files that contain controlled technical data; research data produced under a grant that requires open publication or forbids commercial use; clinical data collected under a protocol that limits reuse.

Use limits: what will the licence allow, and what will it ban?

Use limits translate the findings of the first four areas into the scope the licence will set. They say which uses are permitted, which are banned, and which the owner has chosen to exclude. This is where the owner’s control lives, and it is written into the licence rather than left as an understanding.

Evidence that answers it:

• The permitted uses the owner agrees to, such as pre-training, fine-tuning or evaluation, and no others.
• The standard bans: no redistribution, no publication, no re-identification of any person, no showing the files to end users.
• Any exclusions the owner wants, such as named competitors or whole categories of use.
• The term, the territory and whether the deal is exclusive.

What typically fails: nothing in the legal sense, but owners sometimes find that the only use they would accept is narrower than the use the AI team wanted. Finding that out before the licence is drafted is cheaper than after. The homepage FAQ covers how owners approve each use.

Delivery and deletion: how does the data move, and how does it leave?

This area covers the mechanics: how the data is transferred, where it is held, who can access it, how access is logged, and what happens when the term ends. A licence without a credible deletion clause is a sale with extra steps, so the check confirms that deletion is defined, timed and certified.

Evidence that answers it:

• The delivery method: encrypted transfer into an approved, access-controlled environment, with access logged.
• The deletion timeline at term end, including backups, and the form of the deletion certificate.
• What happens to models trained during the term, which is a separate decision from deleting the files.

What typically fails: delivery into a shared environment with no access list; backups outside the deletion commitment; no agreed form of certificate, so the owner has nothing to put on file.

Which data types usually fail, and on what?

Every field has a usual blocker. The table lists the first thing Liciva checks for each kind of data in its catalogue. It is where a first-pass check should start, not a prediction that your data will fail.

Kind of data	What is checked first	Rights-check areas most often involved
Business records (email, chat, CRM, tickets)	Customer contracts, staff privacy and confidentiality duties	Third-party terms; personal data and consent; restrictions
Code and long-form text	Open-source licences, contractor IP and authorship	Chain of title; third-party terms
Healthcare and clinical data	De-identification method, HIPAA or GDPR basis, and consent	Personal data and consent; restrictions
Engineering and CAD	Client ownership of designs and export controls	Chain of title; restrictions
Robotics and sensor logs	Device terms, location data and bystanders in footage	Third-party terms; personal data and consent
Scientific research	Grant terms, institution policy and co-author rights	Chain of title; restrictions
Audio and video	Recording consent, likeness releases and performer rights	Personal data and consent; chain of title
Geospatial and finance	Provider licences, privacy and financial regulation	Third-party terms; restrictions

Two patterns stand out. Chain of title and third-party terms dominate for data that people created on purpose: code, designs, research, recordings. Personal data and restrictions dominate for data that accumulated as a by-product of running a business: records, logs, clinical files. Knowing which pattern your data follows tells you which documents to pull first.

How do you run a first-pass rights check yourself?

You can do a useful first pass inside your own company in a few days, without sharing anything with anyone. The goal is not a legal opinion. It is to find out whether the six questions have documented answers, and to spot the gaps before a counterparty does.

1. Describe the collection in one paragraph. What systems it comes from, the date range, the rough volume, and the formats. If you cannot describe it, you cannot clear it.
2. List who made it. Employees, contractors, customers, partners, machines. For each group, pull the contract or terms that governed the work. Mark any group with no written IP assignment.
3. List what you promised others about it. Customer contracts, vendor terms, platform terms, open-source licences, supplier agreements. Mark any clause that limits secondary use, export or disclosure.
4. Map the personal data. Which structured fields, which free-text areas, which recordings. Note the privacy notices and consents in force when the data was collected. Mark anything that would need a new basis for this use.
5. Check for external restrictions. Export control, sector regulation, grant terms, professional confidentiality, regulator conditions. Mark anything that applies.
6. Decide what you would allow. Permitted uses, bans, exclusions, term, exclusivity. Write it as a short list. This becomes the brief for the licence.
7. Note how you would deliver and delete. Where the data would be copied from, how, and what deletion at term end would look like, including backups.
8. Write up the gaps. Every item you marked is either fixable, excludable or fatal. Sort them. Fixable means a consent, an assignment or a contract amendment would close it. Excludable means the affected records can be carved out. Fatal means the collection, or a large part of it, cannot be cleared.

Checklist for the end of the first pass:

• Every creator group has a written IP assignment, or is marked as a gap.
• Every contract touching the data has been read for data-use, confidentiality and export clauses.
• Personal data is mapped, and the legal basis for this use is identified or marked as a gap.
• External restrictions are listed.
• Permitted uses, bans and exclusions are written down.
• Delivery and deletion are described, including backups.
• Every gap is sorted as fixable, excludable or fatal.

No fatal gaps means you have something worth taking into an NDA-first conversation. Fatal gaps found now save you and a buyer a great deal of time.

What is the written rights memo for?

The rights memo is the output of the rights check: a short document that records what can be licensed, under what conditions, what was excluded and why. The owner keeps it on file. The AI team’s counsel relies on it when the licence is drafted. It turns a verbal reassurance into evidence both sides can point to later.

A memo records, for each of the six areas, what was reviewed, what was found, and what the licence must therefore say. Where a gap was fixed, it says how. Where records were excluded, it says which and why.

For the owner, the memo shows that the company checked what it was granting before it granted it. For the AI team, it is the provenance record they increasingly have to produce for a regulator, an investor or a court. The companion article on AI training data provenance covers what buyers should expect to see, and the piece on EU AI Act training data requirements covers what model providers now have to publish.

What happens when data cannot be cleared?

It is not licensed. That is the point of running the check before the licence rather than after. Sometimes the answer is partial: a subset can be cleared and the rest excluded. Sometimes a gap can be closed with a consent, an assignment or an amendment. When a gap cannot be closed, the honest outcome is no licence, and a memo that says why.

The market has also attracted people offering data that is not theirs to offer. Business Insider’s reporting on workplace data includes one AI company describing a group that had illicitly obtained a copy of a codebase and was shopping it to data vendors. A rights check stops that data reaching a model, and protects the owner whose data was copied.

An owner who hears “this part cannot be cleared” has not lost a deal. They have learned what can be licensed now and what it would cost to make the rest licensable. Often the fix is modest: a contractor assignment signed late, a privacy notice updated for future collection, one client’s records carved out.

This article is general information, not legal advice. Your own counsel should review any licence before you sign it.

Where to start

Start with the first pass above and keep the specifics inside the company. Then tell us the kind of data you hold, with no confidential detail yet. A named person replies, the mutual NDA comes next, and the rights check comes before anyone drafts a licence. The checklist is published so that you can hold us to it.