The dataset passed acceptance. Can you use it as planned?

Can a dataset pass acceptance and still be wrong for the intended use?

Yes. Acceptance testing can tell you whether the delivered files match the agreed format, coverage and quality rules. It cannot, by itself, tell you whether the source, permissions and agreements allow your planned training, evaluation, product use or onward transfer. A technically useful file and a cleared use are different decisions.

That distinction matters to the buyer who signs off a purchase. If another team later asks why a dataset may be used in a particular product, a passing quality report answers only part of the question. The AI data collection consent and reviewer QA checklist covers the collection and review questions in more detail; this article follows the source-to-use chain across a purchase.

What do you know about the original source?

Start with the type of material and the route by which it entered the dataset. Was it recorded from contributors, supplied by a rights holder, licensed from a third party, or drawn from another permitted source? Which source record connects an item or batch to that route? If a supplier cannot distinguish those routes, a general statement that the data was “sourced responsibly” cannot answer a use-specific question.

Ask what the person or organisation providing the material was told or agreed to where that matters. For personal data, identify the applicable privacy rules and the basis relied on for the stated processing. For licensed material, ask what the licence permits. For both, identify any collection or supplier-contract restrictions that affect the planned use. The required answer depends on data type, source, jurisdiction and use; a contributor consent form is not a universal substitute for those checks.

For speech data, review voice rights, consent scope where consent is the chosen route, and the recording specification side by side: the first two concern permitted use, while the last concerns whether the recording meets the task.

Which use was permitted, and where is that recorded?

Describe the use before judging the evidence: internal evaluation, model training, fine-tuning, a customer-facing product, redistribution or a different activity. A record covering one purpose may not cover another. Ask the supplier to show the relevant permission, lawful-basis analysis where applicable, licence or contract term, and the scope it actually supports. If the plan has changed since collection, identify that change rather than treating the nearest earlier description as approval.

For data involving people, the buyer's privacy and legal owners should decide which rules apply and whether consent is required or another lawful basis is appropriate. If consent is the route used, ask how its scope and any applicable withdrawal terms are recorded and connected to the material. That is a narrower and more useful request than asking whether “consent was obtained” for the dataset as a whole.

What survives each handoff?

Delivery transfers a file. The right to use it for every downstream purpose does not follow from delivery alone. Map each supplier or rights-holder handoff and ask what licence, permission and contract restrictions continue through it. Does the agreement cover your organisation, your intended use, any derivative use and any onward sharing? Who has authority to grant those rights, and what happens if a third-party source was licensed only for a narrower purpose?

Keep the source and rights records attached to a batch identifier without exposing private contributor details to people who do not need them. The speech data collection buyer guide applies these questions to recordings and speakers; its speech-specific assumptions should not be imposed on every data type.

What should sign-off mean when one link is still open?

Use two sign-offs. One accepts the artifact against technical criteria. The other records whether the proposed use has been reviewed against source history and the applicable permissions, licences and terms. Name the owner of each decision and leave a visible exception when evidence is missing or the intended use is outside the documented scope. Documentation makes the decision inspectable; its existence does not guarantee that the use is lawful or unrestricted.

The supplier question before the next purchase is: “For this specific dataset and intended use, what source-history records and applicable permissions, licences or contract terms support each handoff, and which gaps still need our decision?” A clear answer lets your procurement, privacy, legal and model teams resolve the same question before it becomes a delivery surprise.

What to request before purchase sign-off

Use this as a request list, then let the accountable owners decide whether the evidence is sufficient for the particular use.

• The intended uses, data types, source classes, jurisdictions and any planned onward transfer
• A source-to-batch record that identifies collection or acquisition route without unnecessary personal detail
• The applicable permission or lawful basis, licence and supplier-contract terms for each material source
• The technical acceptance criteria and a separate owner for source-and-use review
• An exception record for any missing evidence, narrower licence or changed downstream purpose

Where to stop and clarify

These are prompts for a scoped follow-up, not a conclusion that a supplier or dataset is non-compliant.

• “Consent obtained” is the entire answer, with no indication that consent is the applicable route or what it covers
• A delivery receipt or passed QA report is offered as the only evidence of usage rights
• The supplier cannot connect the source or licence record to the delivered batch
• Rights are described for the original project but not for the proposed model or product use
• A third-party handoff has no identified terms, grantor or restriction owner

What to send for a useful scope discussion

Bring the intended use and the open evidence question to a scope discussion. The buyer's accountable privacy and legal teams still decide the applicable requirements and approvals.

• The data type, source category, target markets and intended model or product use
• The collection, licence or rights records already available, with private details withheld until an appropriate review route exists
• Any downstream customer, redistribution or derivative-use requirement
• Technical acceptance criteria and the specific source-or-use gap holding your sign-off