Model Releases for AI Training Data: A Buyer Due-Diligence Checklist

In this guide, model release means a release or permission signed by a human participant—not a release of a machine-learning model.

A participant release may be important evidence of authorization, but it does not answer every buyer question by itself. A buyer also needs to understand what was recorded, which permissions apply, who can use the files, which AI activities the buyer license permits, whether third-party material appears in the recordings and which package version the records cover.

The practical goal of due diligence is not to collect a folder of signatures. It is to establish a traceable rights path from the person who was recorded to the specific data package and intended use under review.

Start with a four-record chain

A useful review connects four different records. This is a practical due-diligence structure, not a claim that every jurisdiction prescribes the same four documents:

1. Participant permission or release. What the participant agreed could be recorded and how the resulting material may be used.
2. Internal rights record. How the supplier maps that permission to a pseudonymous participant ID, captured assets, document version, limitations and current status.
3. Dataset license and order. What the supplier actually permits the buyer and its approved users to do with the delivered data.
4. Delivery and version record. Which files, metadata and package version were delivered under that order and license.

These records serve different purposes. A broad participant release does not automatically give a buyer every possible use. A buyer receives only the rights stated in the applicable dataset license and order. Conversely, a buyer license cannot grant rights the supplier does not have authority to pass on.

Ask the supplier to explain how the four records connect. The answer should identify the coverage and exceptions without exposing participants' legal names, signatures or identity documents.

1. Confirm what the participant permission covers

The release should match the material actually captured. Depending on the package, that can include:

• face, body, hands, movement, actions and performance;
• still images and video;
• recorded speech, non-verbal vocalizations or other audio;
• prompts, drawings, writing or other participant-created material;
• public previews or samples, if any, as distinct from private buyer delivery;
• editing, annotation, transformation and creation of technical features or derived metadata;
• commercial research and product-development contexts described with enough specificity for the participant to understand them.

Do not treat one permission as an automatic clearance for everything visible or audible. A participant generally cannot clear third-party music, artwork, trademarks, confidential screens or another person's likeness merely by signing their own release. Ask how the capture protocol excludes, controls or separately documents such material.

The same principle applies to voice. Permission to record speech is not necessarily permission to synthesize or clone the speaker's voice. If voice synthesis, impersonation or a realistic digital replica is relevant, it should be addressed expressly and reviewed for the intended jurisdiction and product. The U.S. Copyright Office's digital-replicas report is one official illustration of why voice and appearance replication require separate attention.

2. Match permissions to the intended AI lifecycle

“AI use” is too broad to function as a complete buyer requirement. State which operations matter to your project and check them against the applicable license and rights coverage.

Relevant operations may include:

• model training or fine-tuning;
• evaluation, benchmarking and internal comparison;
• annotation and quality assurance;
• extraction of features, embeddings, landmarks or other derived metadata;
• retention of learned parameters or weights after raw-media access ends;
• generation and deployment of outputs;
• use by employees, affiliates, contractors, annotators or cloud providers;
• sharing with a named customer or project partner;
• publication of examples or outputs;
• redistribution, resale, public upload or sublicensing of the raw dataset.

Do not assume that permission for one operation implies all the others. Training does not by itself answer whether raw media can be redistributed. Internal evaluation does not necessarily permit a public demo. Permission to create annotations does not necessarily permit biometric identification or a digital replica.

For a custom capture, place these requirements in the initial brief. For a ready dataset, compare them with the published specification and request the applicable license before accepting the order.

3. Separate core ML uses from sensitive or restricted uses

Some intended uses require a separate legal and ethical review even when the supplier has a signed participant release. Examples include:

• biometric identification or identity verification;
• tracking or surveillance;
• emotion inference or sensitive-trait inference;
• voice synthesis, cloning or impersonation;
• realistic digital replicas;
• decisions that materially affect people.

Contractual permission does not make an otherwise unlawful use lawful. Applicable privacy, biometric, AI, publicity, consumer-protection and sector rules still matter to the buyer's processing and deployment.

It is also important to use the word biometric precisely. Face photographs and videos can be personal data without automatically being special-category biometric data in every workflow. Under the EU GDPR, biometric data is defined by specific technical processing related to physical, physiological or behavioural characteristics that allows or confirms unique identification. GDPR Recital 51 says photographs should not systematically be treated as special-category data; the technical processing and purpose matter. See the official GDPR text, including Article 4(14), Article 9 and Recital 51.

Processing personal data under the GDPR requires an applicable basis under Article 6. Where a workflow also processes special-category biometric data, Article 9 requires a separate applicable condition. A participant release or commercial contract does not replace that privacy-law analysis. The UK Information Commissioner's Office describes the same two-part structure for biometric-recognition processing under UK law. Consent can be relevant, but it is not the only possible basis in every context and must meet the applicable validity requirements. See the ICO's official biometric data guidance.

The intended downstream system matters too. The EU AI Act restricts or prohibits certain AI practices, including specified biometric categorisation, emotion-inference and facial-recognition-database practices. A dataset release cannot override those rules. Review the official EU AI Act against the actual use case and deployment context.

4. Ask for evidence without collecting participant PII

Buyer due diligence usually does not require copies of signed releases, passports or legal-name lists. Those records contain personal information and should not be placed in the media package or circulated by default.

Instead, ask for a rights-coverage summary that can be checked without exposing participants. Useful evidence can include:

• the release or permission template identifier and version;
• the category of captured material covered;
• a pseudonymous mapping between accepted media and release status;
• confirmation that the applicable participant records were completed before buyer delivery;
• disclosed limitations, exclusions or participant-specific exceptions;
• the identity and authority of the party licensing the dataset to the buyer;
• the process for handling a rights-status change or a valid participant request;
• the package, manifest or delivery version to which the statement applies.

This is evidence of process and coverage, not an invitation to publish private paperwork. If deeper review is justified for a particular transaction, agree a controlled review method and purpose rather than copying identity records into a general procurement folder.

5. Check who may access the raw data

The buyer license should make the access boundary clear. Ask:

• Which buyer entity is licensed?
• May the buyer's employees and controlled affiliates access the raw data?
• May contractors, annotators, hosting providers or cloud services process it on the buyer's behalf?
• Are those parties limited to the buyer's project and subject to equivalent controls?
• Can the raw package be shared with customers, research partners or investors?
• What security, retention and deletion obligations apply?
• What happens to working copies and backups when access ends?
• Are public upload, raw-data redistribution and resale prohibited unless separately agreed?

Operational access and sublicensing are not the same thing. A contractor may need limited access to annotate data without receiving the right to reuse or redistribute it independently. The license should distinguish those situations.

6. Connect rights evidence to a specific delivery version

Rights due diligence is weaker when it refers only to a product name. The review should identify the actual package version under consideration.

At minimum, connect the rights statement to:

• the SKU or custom-project identifier;
• the package and metadata version;
• the accepted media inventory or manifest;
• any disclosed exclusions or removed files;
• the applicable license and order;
• the date or status of the review.

If files are added, replaced or removed, ask whether the change affects the manifest, release mapping or rights summary. A new media version may require a new evidence snapshot even when the commercial product name stays the same.

7. Understand withdrawal and change handling

Avoid two opposite assumptions: that a participant can always erase every effect of past licensed use, or that a signed release can never be questioned or changed. The answer depends on the agreement, applicable law, processing basis, facts and timing.

Ask the supplier for the operational procedure where a valid request or rights-status change applies:

1. How is the affected participant or asset located without exposing identity data to the buyer?
2. Can affected files be quarantined or removed from future package versions?
3. How are customers notified if an already delivered version is materially affected?
4. What do the license and applicable law say about prior delivery, retained raw files, derived artifacts and trained systems?
5. Which record documents the decision and package change?

Do not promise “retroactive untraining” as a universal remedy. The technical and legal consequences for an already trained system require case-specific analysis.

Buyer checklist before accepting human training data

Use this list to structure the commercial and technical review:

• The supplier distinguishes participant releases from the buyer dataset license.
• The licensing party can explain its authority to grant the offered rights.
• Release coverage matches the recorded face, body, hands, performance, speech and other relevant material.
• Voice synthesis, impersonation or digital-replica uses are expressly addressed if required.
• Third-party music, artwork, branding, screens and bystanders are controlled or disclosed.
• The intended AI operations are stated rather than grouped under a vague “AI use” label.
• Training, evaluation, annotation, derived features, outputs and raw-data sharing are considered separately where relevant.
• Sensitive uses such as biometric identification, tracking, emotion inference or voice cloning receive separate review.
• The license identifies the buyer entity and permitted employee, affiliate, contractor and cloud access.
• Redistribution, resale, public upload and sublicensing rules are explicit.
• Security, retention and deletion obligations are understood.
• Rights evidence uses pseudonymous IDs and does not require participant identity documents in the delivery tree.
• Exceptions and participant-specific limitations can be surfaced without disclosing identity.
• The release status and rights summary are linked to the actual media package and metadata version.
• The supplier has a documented process for valid requests or rights-status changes.
• Public samples and marketing previews have their own appropriate coverage.
• The buyer has reviewed applicable privacy, biometric, AI, publicity and sector rules for the intended use.
• The sample, metadata, known limitations and QA evidence also meet the technical requirement.

What a release does not prove

Even a well-documented release does not by itself prove:

• that every intended use is lawful in every jurisdiction;
• that the buyer has satisfied its own privacy or AI-governance duties;
• that third-party intellectual property is cleared;
• that labels, annotations or participant attributes are accurate;
• that the files meet the required technical quality;
• that the dataset will improve a particular model;
• that no project-specific restriction applies.

Review rights, technical evidence and the intended deployment together. Our guide to capture, QA and dataset versioning explains the package-evidence side. If you are defining new data, use the custom human video dataset brief to state the intended use and permission requirements before capture.

Selected official references

• EU General Data Protection Regulation
• EU Artificial Intelligence Act
• UK ICO biometric data guidance
• U.S. Copyright Office: Copyright and Artificial Intelligence, Part 1 — Digital Replicas

This article is an educational procurement checklist, not legal advice. The binding documents for a transaction are the applicable participant records, dataset license, order and delivery record. Buyers should obtain qualified advice for their jurisdiction and intended use.

Review the data and permission fit together