Skip to content

Provenance, rights and permitted use

Consent and Notice Records for AI Training Data: What to Request and How to Check Them

Quick answer

Consent records for AI training data are the artifacts that show what each data subject was told and agreed to when the data was collected: signed forms, timestamped click-through logs, call disclosure scripts, versioned privacy notices and opt-out logs. A supplier's assurance that "users consented" is not evidence. Ask for the record types that fit how the data was collected, then trace a sample of records to the exact consent or notice version that covered them, and confirm the purpose they disclose is compatible with training.

By SourceX Editorial · Updated

This page is general information, not legal advice. Confirm requirements with counsel for your jurisdiction and use case.

The consent basis belongs in the dataset's provenance record because it determines what the data may lawfully be used for. Research-data dictionaries list consent basis next to source and licensing as a core element of training-data provenance [1], and the industry Data Provenance Standards include privacy and protection as a required metadata category [3]. If consent lives only in a warranty clause, you have a promise, not documentation you can test.

A useful frame is three questions per collection context: was there consent or another valid legal basis, what notice was given, and is AI training compatible with the purpose disclosed [2]. Under the GDPR, consent is only one of six lawful bases in Article 6, Article 6(4) sets out factors for whether a further purpose is compatible with the original one, and Article 7(1) requires a controller relying on consent to be able to demonstrate it [4]. That last point is the buyer's lever: if the supplier relies on consent, records should exist. For the wider picture of source and rights checks, start at the provenance hub.

Many operational datasets were never collected on consent, and asking for consent records that cannot exist wastes a diligence cycle. Support tickets, CRM histories and invoices are usually processed under contract or legitimate interest, so the relevant evidence is the customer contract, the DPA and the privacy notice, not a consent log. See customer contracts and DPAs and the glossary entry on lawful basis.

For EU personal data, EDPB Opinion 28/2024 discusses when legitimate interest can support developing an AI model and what follows if personal data was processed unlawfully during development [5]. In California, the CCPA requires notice at collection of the categories of personal information and the purposes of use, and bars using it for additional incompatible purposes without notice [7]. Some regimes use other conditions alongside or instead of consent: health data held by HIPAA covered entities generally needs patient authorization or de-identification by Safe Harbor or Expert Determination under 45 CFR 164.514 [10], and financial data received under a Regulation P exception may be reused only for the purpose it was received for [11].

Where consent is the required basis, it is usually because of a specific statute. Illinois BIPA requires written notice and a written release before collecting biometric identifiers such as voiceprints and face geometry [8], and Texas requires informing the person and obtaining consent before capturing a biometric identifier for a commercial purpose [9]. Commissioned recordings and research-style collections also tend to rely on consent; see consent language for commissioned collection.

Record types by collection context

The records you request should follow the channel through which data was collected, because each channel produces different evidence. A web sign-up flow leaves click-through logs; a contact center leaves call disclosure scripts and recording flags; a study leaves signed forms. The table below maps contexts to records and the fields that make them testable.

Illustrative example: invented to show structure; it does not describe an available dataset.

Collection contextRecords to requestFields that make it testableCommon failure mode
Web or app sign-upClick-through consent log; terms and privacy notice version archiveuser_id, consent_event_id, timestamp (UTC), notice_version, checkbox or button text, IP or session refLog shows "accepted terms" but not which version
Contact-center callsDisclosure script versions; IVR prompt recordings; per-call disclosure flagcall_id, script_version, played_at, recording_consent flag, state of callerScript changed mid-period with no effective date
Support chat and emailPrivacy notice versions; chat widget banner text; DPA with business customersticket_id, created_at, channel, account_id, notice_version_at_creationNotice mentions "service improvement" only
Commissioned recordings or studiesSigned consent forms (wet or e-signature); participant information sheetparticipant_id, form_version, signed_at, scope checkboxes, withdrawal dateForm allows "research," not commercial training
Biometric capture (voice, face)Written release; retention schedule; BIPA or Texas noticesubject_id, release_signed_at, purpose text, retention end dateRelease obtained after first capture
Any channelOpt-out and withdrawal log; suppression listsubject_id, request_type, received_at, processed_at, systems affectedOpt-outs honored in CRM but not in the export

Ask for the notice archive as dated, versioned documents, not today's policy. Matching each record's collection date to the notice in force at that time is covered in notice version at collection. Consent receipts in a structured format are helpful where they exist, but most operational systems store consent as fields on the customer or event record, so expect exports rather than receipts.

Verification means picking records from the delivered sample and walking each one back to the specific consent event or notice that covered it. Supplier attestations describe the policy; the trace tests whether the policy was applied to these rows. Run it on a sample sized to the error rate you can tolerate, using the approach in how many records to check.

Illustrative example: invented to show structure; it does not describe an available dataset.

Consent and notice trace worksheet (one row per sampled record)

record_id:            TKT-2023-0418-7731
collected_at:         2023-04-18T14:02:11Z
channel:              support_chat
subject_ref:          acct_55120 (pseudonymized)
basis_claimed:        contract + privacy notice
notice_version:       privacy-notice v4.2 (effective 2023-01-09)
notice_text_on_use:   "to provide and improve our services, including
                       training machine-learning models"
consent_event_id:     n/a (not consent-based)
opt_out_check:        suppression list searched 2026-09-30, no match
biometric_present:    no
result:               PASS (purpose disclosed; no opt-out)
reviewer / date:      governance lead / 2026-10-02

Score each sampled record as pass, fail or cannot trace. "Cannot trace" is the important outcome: it usually means the supplier cannot link records to notice versions, which is a gap in record-level provenance rather than in a single row (see record-level provenance). Decide in advance what failure rate triggers exclusion of a date range or channel, and record the outcome in your training data use register.

Notice changes, retroactivity and opt-outs

A notice that added AI training after the data was collected generally does not reach back to cover older records. The FTC has warned that quietly changing terms of service or privacy policies to permit AI training on previously collected data could be unfair or deceptive [6]. When the trace shows records collected before the training language appeared, treat those records as a separate cohort that needs its own basis, or exclude them.

Opt-outs and withdrawals must flow through to the extract, not just the source CRM. Ask the supplier how the suppression list was applied to the export, on what date, and whether withdrawals received after delivery will be passed on under the license. Check that do-not-sell or do-not-share flags under the CCPA and GDPR Article 21 objections were respected where relevant [4][7].

What changes when records are de-identified

De-identification reduces, but does not remove, the need for consent and notice evidence. GDPR Recital 26 places truly anonymous information outside data protection rules, but the test considers all means reasonably likely to be used to re-identify someone [4]. HIPAA de-identified data under Safe Harbor or Expert Determination is not individually identifiable health information [10], so authorization records matter less there than the de-identification documentation.

Even after identifiers are removed, the original notice still shapes reputational and contractual risk, and some statutes attach to collection itself, as BIPA does [8]. For de-identification methods and their limits, see the privacy guide. Keep both sets of records: the consent or notice evidence and the de-identification method record.

Regulatory documentation that depends on these records

Downstream obligations often require you to describe the origin and collection of training data, which you cannot do without these records. For high-risk AI systems, AI Act Article 10 requires data governance covering data collection processes, the origin of data and, for personal data, the original purpose of collection [12]. As of October 2026, the Article 10 obligations for Annex III systems are reported to start on 2 December 2027 after Regulation (EU) 2026/1744.

In practice, file the notice versions, the consent log export and the trace worksheet with the dataset's diligence pack. The due diligence checklist asks whether consents allow the use; this evidence is how you answer it. The glossary entry on consent management defines the underlying systems.

Questions to put to a supplier

The fastest diligence comes from a short, specific request at the start. Send these before reviewing any sample:

  • Which lawful basis applies to each collection channel, and which document states it?
  • Provide every privacy notice and terms version in effect during the collection window, with effective dates.
  • For consent-based data, export the consent events with notice or form version and timestamp.
  • For calls, provide disclosure script versions and the per-call disclosure flag.
  • How were opt-outs, withdrawals and suppression lists applied to this extract, and on what date?
  • Does any field contain biometric identifiers, health information or financial account data?
  • Can each record be linked to a notice version? If not, which date ranges cannot be linked?

When the data comes from a business that holds records about its own customers, also check the customer contracts; when it comes from a service provider holding client data, see client data held by service providers. If you would rather describe the data and have the sourcing and rights review handled, you can send a data request to SourceX.

SourceX sources operational datasets from US companies on request, and every dataset is rights-reviewed for ownership and consents and delivered under a license that defines records, uses, term and delivery. Personal details are removed or replaced before delivery, the method is recorded and a sample is checked (no method is perfect), and diligence materials on source, rights and preparation are prepared per dataset. Describe the data you need at sourcex.si/buyers.

Sources

  1. CASRAI, "Training data provenance". https://casrai.org/dictionary/term/training-data-provenance
  2. Claru, "Data provenance (glossary)". https://claru.ai/glossary/data-provenance
  3. IAPP, "Leading corporations' proposed data provenance standards aim to enhance quality of AI training data". https://iapp.org/news/a/leading-corporations-proposed-data-provenance-standards-aims-to-enhance-quality-of-ai-training-data
  4. European Parliament and Council of the European Union (Official Journal of the EU, via EUR-Lex), "Regulation (EU) 2016/679 (General Data Protection Regulation)" (2016). https://eur-lex.europa.eu/eli/reg/2016/679/oj/eng
  5. CMS, "EDPB Opinion 28/2024: key takeaways on processing personal data in the context of AI models" (2024). https://cms.law/en/int/legal-updates/edpb-opinion-28-2024-key-takeaways-on-processing-personal-data-in-the-context-of-ai-models
  6. U.S. Federal Trade Commission, "AI (and other) Companies: Quietly Changing Your Terms of Service Could Be Unfair or Deceptive" (2024). https://www.ftc.gov/policy/advocacy-research/tech-at-ftc/2024/02/ai-other-companies-quietly-changing-your-terms-service-could-be-unfair-or-deceptive
  7. California Privacy Protection Agency, "California Consumer Privacy Act of 2018 (statute text)". https://cppa.ca.gov/regulations/pdf/ccpa_statute.pdf
  8. Illinois General Assembly, "Biometric Information Privacy Act (740 ILCS 14/)". https://www.ilga.gov/legislation/ilcs/ilcs3.asp?ActID=3004
  9. Texas Legislature, "Texas Business and Commerce Code Section 503.001: Capture or Use of Biometric Identifier". https://statutes.capitol.texas.gov/Docs/BC/htm/BC.503.htm
  10. eCFR / U.S. Department of Health and Human Services, "45 CFR 164.514: de-identification and limited data sets". https://www.ecfr.gov/current/title-45/subtitle-A/subchapter-C/part-164/subpart-E/section-164.514
  11. Consumer Financial Protection Bureau, "12 CFR 1016.11: Limits on redisclosure and reuse of information (Regulation P)". https://www.consumerfinance.gov/rules-policy/regulations/1016/11/
  12. European Commission, AI Act Service Desk, "AI Act Article 10: Data and data governance". https://ai-act-service-desk.ec.europa.eu/en/ai-act/article-10

Tell us what your models need

Share scope, volume, language, format, timing and licensing requirements.

Request data