A speech data RFP is not a volume order. It is a technical specification that determines whether the corpus you receive can actually train a production ASR system. Most enterprise procurement teams underspecify requirements and overfocus on price, which produces exactly the wrong outcome: a corpus that looks complete on paper and fails in deployment.
This framework covers what to specify in each section of a speech data vendor RFP, in enough detail that vendors cannot respond with vague claims about quality and coverage.
Why a structured RFP changes the vendor pool
An open-ended request attracts bulk providers. A requirements-based RFP filters for vendors with actual methodology.
When an RFP specifies that responses must include a documented IAA methodology, a speaker recruitment protocol for each target dialect, and a sample consent record, vendors who operate without those processes cannot respond credibly. That filtering happens before you read a single proposal. The shortlist arrives pre-qualified.
There is also a commercial benefit. Vendors who know your requirements upfront price to those requirements. Vendors who discover them mid-project request change orders. A detailed RFP reduces scope disputes.
Section 1: Scope definition
The scope section must be specific enough that two different vendors reading it produce comparable responses. Ambiguity here produces incomparable bids.
Languages and dialects
List each language variant separately. Do not write “Norwegian” if you need Bokmal and Nynorsk treated as distinct targets. Do not write “German” if you need Austrian and Swiss German alongside Hochdeutsch. Each variant should have its own line with a target volume, speaker count, and demographic requirements.
For European enterprise ASR, standard regional variants to specify include:
- Norwegian: Bokmal (Eastern, Western), Nynorsk, Northern dialects
- German: Standard (Hochdeutsch), Austrian, Swiss German
- French: Standard (Parisian), Belgian, Canadian (if relevant)
- Spanish: Castilian, Latin American if multi-region deployment is intended
A vendor who collapses these into a single language category is not capable of producing dialect-balanced data.
Speaker demographics
Define the demographic profile for each language. Minimum requirements for a production corpus include age range distribution (at minimum: under 30, 30-60, over 60), gender balance, and L2 speaker percentage if the deployed system will encounter non-native speakers. Include the native language status requirement: whether L1 speakers only are acceptable, or whether L2 speakers with a specific language background are also in scope.
Recording conditions
List the acoustic environments required, not just the dominant use case. A voice assistant deployed on mobile devices needs recordings from mobile handsets in quiet rooms and mobile handsets in ambient noise. A call center ASR system needs telephone-quality recordings. An in-cabin automotive system needs recordings with engine noise and music. Specify each condition with its target volume.
Speaking styles and volume
Distinguish scripted read speech from prompted responses from spontaneous conversational speech. Each produces different acoustic characteristics and requires different collection and annotation approaches. Specify what percentage of total volume you need from each style.
For conversational ASR, define the scripted and spontaneous mix from the target interaction pattern. Include that mix in the RFP so vendors allocate collection resources correctly.
Section 2: Quality requirements
Quality requirements are the most important and most frequently underspecified section of a speech data RFP. Vague quality language produces vendor responses with vague quality claims.
Transcription accuracy
Require vendors to demonstrate word error rate on a reference test set, not self-reported accuracy on internal data. Run your own WER evaluation on a representative pilot and set the acceptance threshold from the target system and downstream error cost.
Inter-annotator agreement
Specify a task-specific IAA threshold and require vendors to report it by language and recording condition. Require the methodology: which annotation pairs were compared, how samples were drawn, and how the score was computed.
Single-annotator workflows without IAA measurement should be disqualified. Single annotation introduces systematic bias that is invisible until the model fails on specific speaker groups or recording conditions.
QA pass/fail thresholds
Ask vendors to describe what triggers re-annotation. A vendor with a documented QA gate, where a defined percentage of randomly sampled annotations failing a quality check triggers full re-annotation of that batch, is operating at production quality. A vendor who describes quality as “reviewed by a senior annotator” is not.
Style guide requirement
Require vendors to deliver their annotation style guide as part of the proposal response. The style guide is the specification for how annotators resolve ambiguous cases: how to transcribe disfluencies, how to handle overlapping speech, how to label non-lexical sounds. A vendor without a written style guide does not have consistent annotation. Read it before shortlisting.
Pilot requirement
Require a pilot before any volume commitment. It must cover the target languages, difficult recording conditions, and material annotation decisions using the vendor’s production process. Evaluate it against your own references and disclose the pass criteria in the RFP.
Section 3: Compliance and legal requirements
Compliance requirements should be defined before the RFP goes out, not negotiated after award. Including them in the RFP surfaces vendors who cannot meet them early in the process.
GDPR consent framework
Require vendors to provide a sample consent record covering: what the speaker agreed to, the purpose of collection, the data controller identity, the retention period, and the process for exercising the right to erasure under GDPR Article 17. If the vendor cannot produce a sample consent record, they are not operating a GDPR-compliant collection process.
When the vendor acts as a processor, require an Article 28 Data Processing Agreement before processing begins. The agreement should identify processing locations, subprocessors, security controls, and any transfer mechanism relied upon.
Data residency
Choose processing locations from the system’s risk, contracts, and transfer assessment. If EEA-only processing is required, state that explicitly and require the vendor to identify every processing location and subprocessor.
EU AI Act Article 10 documentation
If the voice AI system being trained falls under Annex III of the EU AI Act as a high-risk application, your training data procurement must support Article 10 data governance obligations. This means requiring vendors to document the demographic representativeness of their speaker population, the bias audit methodology applied to the corpus, and the consent documentation chain.
For more detail on which systems are high-risk and what Article 10 requires, see our guide to EU AI Act high-risk AI training data requirements.
Data ownership and licensing
Specify in the RFP whether you require full ownership of the delivered corpus or a usage license. Full ownership is standard for custom collection projects and allows unrestricted use across training runs, model versions, and derived products. Licensing arrangements are acceptable for some use cases but must define what is permitted: specific model versions, specific deployment regions, or time-limited usage.
Include a clause requiring vendors to document speaker erasure obligations. If a speaker exercises their right to erasure, you need to know which recordings are affected and have a process for removing them from training data and any derived models that were trained on them.
Section 4: Technical delivery requirements
Delivery format requirements are often left to the vendor when they should be specified by the buyer. A corpus delivered in the wrong format, with incomplete metadata, costs weeks of post-processing to make usable.
Audio format
Specify the required format. For ASR training, WAV (PCM, 16-bit) at 16 kHz mono is a common standard for telephone and mobile audio. Higher sample rates (24 kHz or 48 kHz) may be appropriate for high-fidelity speech synthesis or voice biometrics. FLAC is acceptable where lossless compression is needed to reduce transfer size. Do not accept MP3 or other lossy formats for ASR training data.
Metadata schema
Specify the required metadata fields, not just the audio files. A minimum schema for production speech data includes: speaker ID, language and dialect, age range, gender, native language status, recording environment, microphone type, sample rate, and transcription confidence score. For compliance use cases, add consent record reference ID, collection date, and geographic region.
Require the metadata to be delivered in a machine-readable format (JSON or CSV) and to be field-indexed so you can filter by any attribute. A corpus delivered as a flat archive without structured metadata is not usable for production training.
Versioning and reproducibility
Require vendors to provide versioned delivery manifests. Each delivery should have a manifest file that lists every audio file, its metadata, the annotation version applied, and a hash for integrity verification. This is the minimum requirement for reproducibility: the ability to trace which data went into which training run and reproduce any historical model if needed.
Section 5: Evaluation criteria and scoring
The scoring model should make rights, governance, and quality non-negotiable. Use priority levels before assigning organization-specific weights:
| Criterion | Priority |
|---|---|
| Quality methodology (IAA, QA gates, human review process) | Must pass |
| Rights and governance documentation | Must pass |
| Language and dialect coverage | High |
| Timeline and delivery logistics | Medium |
| Price | Compare after gates |
This sequence prevents a cheap but unusable proposal from advancing. A vendor that clears quality and governance gates at a higher price may still offer lower total risk than a proposal that creates rework and model failure.
Include a pilot evaluation gate in the scoring process. Vendors who advance past the written proposal stage should complete the required pilot and be scored on pilot output quality before final award.
YPAI
YPAI scopes speech collection across more than 150 languages with a contributor network of more than 40,000 people in more than 50 countries. Projects can include documented consent, provenance, human QA, and EEA processing options according to the buyer’s requirements.
Nordic projects can distinguish Bokmal, Nynorsk, and regional dialect variants in recruitment and metadata. The collection and annotation plan defines verification, agreement measurement, and the evidence needed for the buyer’s intended regulatory use.
If you are writing a speech data RFP and want to discuss how to specify your requirements before the document goes out, contact our data team.
Related articles
- Audio annotation pipeline for speech data labeling - how human-verified annotation pipelines are built and where they fail
- EU AI Act high-risk AI training data requirements - what Article 10 means for speech data procurement under Annex III
- Speech corpus collection services for enterprise ASR - what separates production-grade corpus collection from bulk audio
- Custom speech corpus collection
- GDPR-compliant speech data
- Evaluation program
Sources:
Frequently Asked