Onboarding a New Data Supplier

Where onboarding starts and stops

Onboarding begins the day the license is executed and ends when the first delivery passes acceptance. Everything before that point, such as shortlisting, sampling, the security review of the supplier and the privacy review, is approval work and belongs on other pages. Everything after it, such as quarterly reviews and renewals, is supplier management.

Keeping the boundary sharp matters because onboarding failures look like delivery failures. A dataset that lands in an S3 bucket nobody can decrypt, or that arrives before legal has filed the data processing addendum, usually traces back to a setup step that was skipped. Licensors that document their own inquiry-to-delivery process show the same hand-off between signature and file transfer [2]. For the full lifecycle, see the AI training data procurement hub.

File the contract set and diligence record first

The first onboarding task is filing every signed document and diligence answer in one record keyed to the dataset, not to the email thread where they arrived. Auditors, counsel and future renewal owners will look for them there, often years later and after the original buyer has moved on.

A complete contract set for a data license usually contains:

• Executed license or order form with the schedule that defines records, fields, permitted uses, term and delivery.
• Data processing addendum if any personal data survives preparation, plus the supplier's description of the de-identification method used.
• Chain-of-title evidence: the documents showing the supplier owns or may license the records; see chain of title for AI training data.
• Diligence questionnaire responses, ideally on a recognized template such as the FISD Alternative Data Council DDQ, whose 2024 edition adds generative AI questions [1]; the due diligence questionnaire guide explains what to ask.
• Signed attestations: consent and notice basis, absence of scraped content, subcontractor disclosure and any sector-specific statement (for example, HIPAA de-identification for health records).
• Evaluation-stage NDA and sample terms, kept so you can show which records were seen before purchase.

Record the version and execution date of each document. If a schedule is amended later, the register entry below should point to the amendment, not just the original.

Register the dataset in the central license register

A license register is the single table that answers "what may we do with this data, and until when," and every new supplier relationship should add a row before data moves. Without it, permitted-use limits live only in a PDF, and engineers discover them after a model has shipped.

The register entry should mirror the license schedule field by field. It also feeds disclosure work, because California AB 2013 documentation and the EU training-content summary both draw on the same source facts; see AI training data disclosure requirements compared.

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

license_register_entry:
  register_id: LR-2026-0412
  dataset_name: "Field service work orders, HVAC, 2019-2025"
  supplier_legal_entity: "Example Supplier LLC"
  license_ref: "MLA-0412 + Schedule A v2 (executed 2026-09-30)"
  permitted_uses: ["fine-tuning", "internal evaluation"]
  prohibited_uses: ["redistribution", "re-identification attempts"]
  territory: "worldwide"
  term_end: "per Schedule A"
  deidentification_method: "names, phones, account numbers replaced with tokens; method note on file"
  delivery_channel: "S3 cross-account bucket, SSE-KMS, SHA-256 manifest"
  refresh_mode: "incremental monthly"
  internal_owner: "data-procurement@buyer.example"
  storage_location: "s3://buyer-licensed-data/LR-2026-0412/"
  downstream_models: []
  disclosure_ready: false

Leave downstream_models empty at onboarding and require teams to append to it when they train. That single field makes later takedown, deletion or disclosure requests answerable.

Agree the delivery channel, keys and integrity checks

The delivery channel should be agreed, tested and documented before any production records move, including who holds which keys and how integrity is verified. Never accept email attachments or consumer file-sharing links for licensed training data.

Common patterns include:

• Cloud bucket transfer (S3, GCS or Azure Blob) with cross-account access scoped to one prefix. S3 can compute and validate checksums on upload and download, so ask the supplier to supply SHA-256 values in a manifest and verify them on receipt [4].
• SFTP with file-level encryption. Exchange OpenPGP public keys under RFC 9580, the current OpenPGP standard as of October 2026 [3], and confirm key fingerprints by a second channel such as a video call, not by the same email that carried the key.
• Table sharing protocols such as Delta Sharing, an open REST protocol in which the recipient reads shared tables with a bearer-token credential [5]. Agree token expiry and rotation up front.

Whatever the channel, require a manifest with file path, byte size, record count, SHA-256 hash and schema version for every file. For columnar files, a cheap first check is structural: a valid Parquet file starts and ends with the 4-byte magic number PAR1, with metadata in the footer, so truncated transfers fail immediately [6]. Your data supplier security review should already have approved the supplier's side of this channel.

Name contacts and an escalation path

Every onboarding should end with a contact matrix that names a person, not a mailbox, for each type of problem, plus a second-level escalation. Most first-delivery delays come from questions that sit unanswered because nobody knows who owns them.

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

Agree the response windows in writing, and store the matrix with the register entry so it survives staff turnover. If you work through an intermediary, record which issues go to the intermediary and which go to the data owner directly.

Write the acceptance plan before the first file arrives

An acceptance plan states, before delivery, the tests a batch must pass and what happens if it fails. Writing it afterward invites disputes because both sides can argue about thresholds once they see the numbers.

A practical acceptance plan covers four layers:

1. Integrity: every file in the manifest present, hashes match, files open (for example, Parquet magic bytes and footer readable) [6].
2. Conformance: schema matches the agreed version, required fields populated above an agreed rate, record counts within tolerance of the manifest, date range as licensed.
3. Privacy: a sampled scan for names, emails, phone numbers and account numbers that should have been replaced; any hit stops the batch and triggers the privacy escalation row.
4. Fitness and overlap: distribution checks against the evaluated sample, and a cross-dataset overlap check against data you already hold.

Ask for documentation alongside the data: a datasheet covering composition, collection process and recommended uses [7], and, where the supplier can produce it, Croissant metadata describing files, record sets and fields in machine-readable form [8]. Compare the delivered batch with the sample you reviewed under your sample request; large shifts are an acceptance question, not just a quality note.

Confirm the first-delivery date and refresh mode

The final onboarding step is a dated first delivery, preceded by a small dry run, and an agreed refresh mode for any ongoing purchases. A dry run of a few hundred records through the real channel exercises keys, manifests, scanners and storage permissions without risking the full batch.

For recurring supply, agree whether later deliveries are full refreshes, which replace the whole dataset, or incremental, which carry only new or changed records [9]. Incremental feeds need a stable record key, a change timestamp and a convention for deletions, or your copy will drift from the supplier's. Record the choice in the register and tie it to the supplier performance scorecard you will use at quarterly reviews. For running several suppliers at once, see managing many data suppliers.

Onboarding checklist for a new data supplier

Use this checklist as the gate between "approved" and "first delivery accepted."

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

How SourceX fits into supplier onboarding

SourceX sources operational datasets from US companies on request and manages the commercial process, including licensing agreements and ongoing purchases. Each dataset is rights-reviewed for ownership and consents, comes with diligence materials covering source, rights, preparation and allowed use, and is delivered under a license that defines records, uses, term and delivery. Personal details such as names, emails, phone numbers and account numbers are removed or replaced before delivery, the method is recorded and a sample is checked, though no method is perfect. Delivery runs through private, access-controlled workflows, never email attachments, and only after an executed agreement and supplier approval. If your team is preparing its register and acceptance plan for a new source of operational data, describe the data you need to SourceX.

Set up your next data supplier

Buyers describe the data they need, and SourceX looks for US businesses that hold it; every release is approved by the supplying company, and nothing is contracted until a supplier agrees. Data is sourced on request rather than held in stock, so a request does not guarantee a match. Start by describing the data your team needs.