How Enterprises Procure Custom AI Training Data

Procuring custom AI training data follows the same general shape as other enterprise vendor purchases, with one structural difference: the thing being bought does not exist yet at the time the contract is signed. An enterprise is not purchasing a fixed, inspectable product off a shelf — it is purchasing a documented process that will produce a dataset against a written specification, which means the procurement has to do more work up front to define what "done" and "acceptable" mean before any capture happens.

In practice this means the procurement path runs through five checkpoints: internal requirements and a vendor shortlist, a written skill spec that both sides agree captures the task, a small proof-of-process pilot, the contract documents that govern the engagement, and a written set of acceptance criteria that determines when a delivered batch is signed off. None of these steps is unique to data procurement on its own — what is unique is that the spec and the pilot exist specifically because the deliverable cannot be fully specified in words alone before someone has actually tried to capture it.

This page walks the procurement process end to end. For a scoring checklist to use when comparing vendor proposals, see /guides/robotics-data-rfp-checklist. For what to put in the actual agreement once a vendor is chosen, see /guides/robotics-data-collection-sla. For a narrower evaluation framework, see /guides/how-to-evaluate-a-robotics-data-vendor.

A custom data purchase typically touches more functions than a model team expects when it first identifies a coverage gap. The research or robotics team that needs the data owns the task definition and the technical acceptance bar, because only that team knows what the model is failing at and what evidence would prove the gap is closed. Legal or contracts review owns the data processing agreement, the licence terms, and the consent-chain warranty, because those are the documents that determine what the organization is actually allowed to do with the delivered footage and any model trained on it.

Procurement or vendor management, where the function exists as a separate team, typically owns the vendor shortlist and the commercial terms, while security or privacy review — where an organization runs one — reviews the anonymization method and the consent chain rather than taking a vendor’s description of it at face value. Smaller engagements often collapse several of these roles into one person; larger ones keep them separate specifically so that the technical bar, the legal terms, and the privacy review are each checked by someone with the standing to say no.

The practical effect for a vendor relationship is that the people who negotiate a contract and the people who evaluate whether a delivered batch actually solves the model’s problem are frequently not the same people. A procurement process that keeps the technical acceptance criteria written down and shared with legal and procurement — rather than left as an informal understanding inside the research team — is what keeps those two groups aligned once footage starts arriving.

Before reaching out to any provider, the requesting team should be able to state the task by verb and noun — "stock a shelf" or "torque a bolt to spec," not "retail manipulation" or "assembly work" — because a vague task category cannot be priced, scheduled, or scoped into a spec. Alongside the task, the requirements should name the environments or condition cells the capture needs to span, the embodiment or camera setup the downstream model expects, and roughly how much volume (hours or episodes) the team believes it needs, understanding that the real number is often set after a pilot rather than guessed up front.

The requirements should also state, in writing, what counts as a failure the new data is meant to fix. A specific failure mode — a task the current model drops, a condition it has never seen, an object category it mishandles — turns into a specific capture brief much more directly than a general request for "more data." Teams that start with the failure mode rather than an aggregate hour target tend to end up with a tighter, more defensible skill spec once they reach the vendor conversation.

For the full checklist of what to ask a vendor to commit to once you reach this stage, see /guides/robotics-data-rfp-checklist.

A custom data engagement generally sits under a master agreement or order form that sets the general commercial terms, a statement of work or spec document that defines the specific task and deliverable, a data processing agreement that governs how personal data in the footage is handled, and a licence covering what the buyer may do with the delivered dataset and any model trained on it. Each document answers a different question, and conflating them — for example, treating the licence terms as settled because the commercial contract is signed — is a common source of confusion once delivery starts.

On the licensing side specifically, the delivered dataset should come under a perpetual, buyer-owned commercial licence, stated explicitly rather than left to a later negotiation. That licence terminology is documented on this site at /provenance, which lays out the grant, permitted use, derived-weights ownership, and exclusivity terms in plain language, and references the executed order form as the document that controls once signed.

The data processing agreement covers how personal data that appears in the footage — bystander faces, license plates, identifying speech — is handled, detected, and removed before delivery. This site’s own data processing agreement is published at /dpa, and its general terms of service are published at /terms; both documents, not a verbal description of them, are what should be reviewed before signing anything, and a vendor’s executed agreement controls over any summary on a marketing page.

Reviewing consent and provenance means checking two separate things: whether every person who appears in the footage, including anyone caught in frame incidentally rather than contracted to perform the task, has given a documented basis for being recorded, and whether anyone who did not consent has actually been made unidentifiable in the delivered footage rather than merely described as anonymized. This site’s own consent chain, published at /provenance, documents six checkpoints running from the written release signed before capture through the consent-artefact IDs listed per episode in the batch data card.

The anonymization method itself — detecting and removing faces, licence plates, and screens, with human review confirming the result rather than trusting automated detection alone — is also documented on that same page, alongside a comparison of how this licensing and consent standard differs from several commonly cited public egocentric datasets. A procurement reviewer’s job is to read that documentation against the actual delivered artefacts for a real batch, not just the policy description, before relying on it in a contract review.

For a deeper walkthrough of what a consent chain needs to cover, see /guides/consent-requirements-for-ai-training-data. For how provenance records fit together more broadly, see /guides/dataset-provenance-explained.

A Spec Pilot is a small first batch, run against the same written skill spec the full engagement will use, that exists to prove the process at low cost before the organization commits to the full volume. In a procurement timeline, the pilot sits between the written spec and the full contract commitment: it is the step that turns a paper spec into evidence — a real reject rate, real coverage against the stated condition cells, and real delivered footage the technical reviewer can inspect — rather than a vendor’s description of what it intends to deliver.

Because the pilot and the production run are meant to share one spec and one accept/reject rule, a procurement process should treat the pilot as a gate rather than a formality: full-volume commitment follows a pilot that meets the written bar, and a pilot that does not meet it is a reason to revise the spec or the vendor relationship before any further spend, not a reason to proceed anyway on the assumption that quality will improve at scale.

For the fuller checklist of what a pilot should prove before scaling to production, see /guides/scaling-a-robotics-data-pilot-to-production.

Acceptance criteria should be written down before capture starts, not negotiated after a batch arrives: a specific, testable rule for what counts as a pass and what counts as a reject, applied consistently across the pilot and every production batch that follows it. Billing against validated hours — footage that has already cleared the accept criteria — rather than raw capture hours keeps the commercial terms aligned with the technical bar, and a reject log delivered with every batch, not just an aggregate pass count, is what lets the technical reviewer audit that the bar held constant.

Delivery itself should be specified by named format — this site documents RLDS, LeRobot, WebDataset, HDF5, zarr, and Rerun .rrd as available delivery structures — plus a batch data card recording provenance, jurisdictions of capture, and the consent and anonymization records behind the batch. A rolling batch cadence rather than one delivery at the very end lets a technical team start integrating data into training while the remaining volume is still being captured, and gives procurement and legal a running record of what has actually been delivered and accepted rather than a single end-of-contract handoff.

Timelines vary by the scope of the engagement and by how quickly an enterprise can move internal requirements and contract review through its own approval process, which is usually the longer variable rather than the vendor’s own capture timeline. On the vendor side, this site states a 48-hour median to a first validated batch and a 3–4 week range for a full custom collection to begin production delivery once a spec is agreed — figures that assume the spec and contract are already settled, not figures that include an enterprise’s own internal procurement cycle.

The practical implication for a procurement timeline is to separate the two clocks explicitly: the internal clock (requirements, shortlist, legal review, signature) and the vendor clock (spec finalization, Spec Pilot, first production batch). Running the vendor’s spec-drafting conversation in parallel with legal’s review of the contract documents, rather than sequencing them strictly, is usually what keeps the overall timeline closer to the vendor’s stated figures rather than adding the two clocks end to end.