Buy AI Training Data

Price per hour is the wrong unit

Almost every training data quote is expressed in cost per hour, and almost every buyer eventually learns that this number tells them very little.

Two datasets at the same price per hour can differ enormously in value. One has 200 distinct speakers, native-speaker transcription, and a documented annotation guideline. The other has 12 speakers recorded repeatedly, transcription of unknown provenance, and no guideline. The second is not cheaper. It is a dataset you will end up re-buying.

The unit that actually predicts value is cost per usable hour after you have subtracted the portion that does not fit your requirement.

Two datasets at the same price per hour

Identical price per hour. The difference does not show up until you have already paid for both.

What you are paying for

Production cost breaks into parts, and knowing them makes quotes comparable.

• Speaker recruitment. The dominant cost for uncommon languages, where finding qualified speakers is the bottleneck rather than recording time.
• Recording: studio time and equipment for clean data, or field coordination for in-the-wild collection.
• Annotation: usually the largest line item, and the one that scales steeply with annotation depth. Transcription alone is a fraction of transcription plus intent plus diarization.
• Quality control: pilot review, cross-checking, and re-work. Providers who quote without this line are either not doing it or hiding it.
• Compliance: consent collection and documentation. Small in cost, but its absence makes everything else worthless.

Questions to ask before you commit

These are the questions that most often change a buyer's mind about a quote.

• How many distinct speakers, and how is that enforced?
• Will I see the annotation guideline before production starts?
• Can I review a pilot batch and reject it?
• What is the re-work policy if the delivery misses spec?
• What exactly does the consent documentation cover, and does it cover my intended use?

Buying from us

We do not publish prices because every project is quoted from its specification. Submit the requirement (language, hours, speaker count, conditions, annotation), and you will get a real number with a real timeline rather than a range.

If the requirement is not something we can source well, we will say so. That has cost us orders and it is still the right way to run this.

What a purchase actually involves

Buying training data is closer to commissioning work than to ordering a product. The sequence below is what a project looks like from the first message to the delivered dataset.

The stages matter because skipping one moves its cost to a later stage, where it is more expensive. Most disputes trace back to a step that was compressed.

• Specification. Volume, languages, recording conditions, annotation depth and delivery format, written down. This document is what everything afterwards is measured against.
• Feasibility. The requirement is checked against producer capability. The answer may be that part of it is not realistic, and it is cheaper to hear that now.
• Pilot batch. A small sample is produced and reviewed against the specification before the full run starts.
• Production. The full volume is collected and processed, with the same checks applied to every batch rather than only the first.
• Delivery and review. Data arrives with the documentation that makes it usable, and there is a defined window to raise issues.

The mistakes that cost the most

These are the recurring ones. Each has cost a buyer a full re-run at some point, and each is avoidable at the specification stage.

None of them require technical knowledge to avoid. They require deciding things in advance rather than during production.

• Buying on price per hour alone. It compares volume and ignores everything that decides whether the data is usable.
• Leaving the annotation depth vague. Transcription, phonetic alignment and diarisation are different products at different prices.
• Not checking the rights position first. A dataset that cannot be licensed to your own customer is not an asset, whatever it cost.
• Skipping the pilot to save time. It is the cheapest possible way to find out that the specification was ambiguous.
• Changing the specification mid-run. Everything already produced has to be judged against the old version or re-done.
• Treating delivery as the end. The review window exists because problems surface when the data meets a real training pipeline.

What to put in the contract

The purchase order is not the agreement. What protects you is a small number of clauses that decide what happens when the delivery does not match the description.

These are the ones worth spending negotiation time on. Everything else can usually be standard.

• The delivery specification as an annex. Volume, languages, recording conditions, annotation depth, file format and metadata schema, written down and attached. Everything is measured against this document.
• Acceptance criteria and a review window. Define what counts as conforming, and how long you have to check. A short window with no criteria is not acceptance, it is a formality.
• The remedy for a failed batch. Rework at the supplier's cost should be the default. A refund is the fallback, but it does not recover your schedule.
• Rights warranties, and who carries the risk. The supplier should warrant that the data can be licensed to you for your stated use, and should stand behind that if it turns out not to be true.
• Delivery of the consent records. Not a summary and not a promise. The records themselves, in a form you can keep and query.
• What to leave out. Exclusivity you do not need, extended terms you will not use, and territory restrictions that do not match how you operate all raise the price for no benefit.