Has the corpus ever been in a cabin?
A highway cabin runs at about 70 dB SPL: engine drone, HVAC, tyres, a passenger talking over the wake word. Booth-recorded corpora flatter the model in evaluation and ship false rejects to the driver on day one.
Automotive voice and audio data
We record in-cabin voice. In the cabin, in 150+ languages.
Wake-word, command, conversational and driver-monitoring audio, recorded by native speakers against real engine, HVAC and road noise, and annotated on the same engagement.
DPA per engagement · EEA processing by default
Signal What ships: accepted, labelled speech.
Noise What the cabin adds: engine, HVAC, road, overlap.
Native review A named human decision on every batch.
CH 01Why in-cabin voice fails
The demo passes in the showroom. The product is judged at 110 km/h.
Three questions decide whether a voice programme survives contact with the road.
Does coverage survive the sixth market?
Nordic dialects, accent drift and code-switched cabin conversations are the long tail that breaks the corpus built for the first five. We record them in-region with native speakers, not with synthetic accent transfer.
Will the evidence exist when the auditor asks?
In-cabin voice classifies as high-risk under the EU AI Act, and Article 10 comes down to lineage, representativeness and bias examination. We ship the evidence pack at delivery, not on subpoena.
CH 02One session, end to end
One accepted minute, and everything it carries.
Session 0412, from a live programme shape: captured in motion, annotated to your taxonomy, reviewed by a native speaker, accepted into a versioned batch.
- 00:02.1 HVAC band rises
- 00:08.4 wake word detected
- 00:09.8 intent: start route guidance
- 00:11.3 passenger overlap
ASR reference
Native review Accepted · batch 14
Accepted material moves into versioned batches, manifests and secure delivery.
Captured in motion
Drivers and passengers in real cabins. Engine load, road surface, HVAC and passenger overlap are part of the recording, not an afterthought.
Annotated to the taxonomy
Wake-word ground truth, intent and entities, speaker and seat-position metadata, labelled against the programme's schema.
Reviewed by native speakers
Native human review is platform core. Failed recordings return for re-recording, rework or replacement according to the project rules.
CH 03The capture protocol
The cabin is a specification, not a backdrop.
We scope the people, vehicles and conditions that decide whether voice works outside the lab. Every session carries the metadata to prove where it was made.
What the cabin adds
- Engine and road
- engine load, road surface, motorway drone
- Climate
- HVAC on the settings drivers actually use
- Windows and media
- open windows, music and device variation
- Passengers
- overlap and cross-talk between seats
What the corpus must carry
- Speakers
- native, recruited in the target market
- Language
- dialects, accents and code-switching
- Metadata
- speaker and seat position on every turn
- Consent
- GDPR Article 7, tracked per contributor
Protocol, participant profile and review criteria are locked before production begins.
CH 04Language coverage
From Nordic dialects to Mandarin, recorded in-region.
Native speakers, recruited where your buyers drive. The exact language list is set with the programme at scoping.
- languages available through the contributor and specialist network
- 150+
- languages with productionised in-cabin voice coverage
- 50+
- processing by default, with Article 10 evidence at delivery
- EEA
Nordic
Swedish Norwegian Finnish Danish Icelandic
Western Europe
French German Spanish Italian Dutch Portuguese
Eastern Europe
Polish Romanian Czech Hungarian Bulgarian
Asia Pacific
Mandarin Japanese Korean Thai
Regional varieties are in scope where the market needs them: Swiss German and regional German varieties, French variants for Belgium, Switzerland and Quebec, and Scottish, Welsh and Irish English accents.
Evaluation engagements, data-collection programs and active annotation work across OEM and Tier-1 suppliers.
CH 05Programme shapes
Five programme shapes. One specification.
Market, speaker, cabin, rights and acceptance requirements turn scope into a programme specification before anything is recorded.
Wake-word and command recognition
Positive and negative wake-word examples, in-domain commands and market-specific pronunciation, with false-accept and false-reject sets built to the product spec.
Ground-truth set · per market
- wake word · motorway
- positive · accept
- near-miss variant
- negative · reject
- radio speech · media bleed
- negative · reject
- false accept / false reject
- measured per market
Intent, entities and conversational voice
Intent taxonomies aligned to your NLU schema, slot and entity extraction, multi-turn interaction and code-switched cabin conversations.
Annotated turn
start route guidance to the office
- intent
- navigation.start
- slot · destination
- "the office"
- context
- multi-turn · code-switch
TTS and branded voice
Native-speaker and professional-voice sourcing, style and prosody requirements, with project-specific model-training and deployment rights.
Voice specification
- sourcing
- native speaker · professional voice
- prosody
- style set with the brand
- rights
- training + deployment · project-scoped
Driver-monitoring and in-cabin audio
Speaker and seat-position metadata, overlapping cabin events and audio-event annotation, paired with gaze ground truth where the DMS spec requires both.
Audio-event classes
- drowsiness cue
- severity tiers · gaze-paired
- distraction event
- speaker + seat position
- protocol
- can follow Euro NCAP 2026
Speech evaluation and remediation
ASR output review, word and intent error analysis, and gap collection for underperforming markets or conditions.
Error analysis
- word errors
- by market · speaker · condition
- intent errors
- against your NLU schema
- gaps
- targeted collection brief
CH 06How delivery runs
Mobilisation follows the specification.
One controlled operating record. Reviewers and operations teams see the same task status and version history.
The forecast uses the unit that matters to the programme: accepted speaker-hours, recordings, sessions or assets.
- Qualification
- Planning
- Collection
- Verification
- Native review re-recording · rework · replacement
- Acceptance
- Delivery
- Home jurisdiction
- Norway (Oslo)
- Processing
- EEA by default
- Corporate structure
- No US parent or US entity
- Evidence
- EU AI Act Article 10 pack at delivery
- Consent
- GDPR Article 7 on every contributor
- Type approval
- UNECE WP.29 data-side artefacts per engagement
CH 08Delivery record
Shapes we have already delivered.
- Batch 01 50+ languages · GDPR consent Delivered
In-cabin multilingual voice corpus build
Native-speaker recording across 50+ target-market languages in real cabin noise, captured by a vetted contributor network under GDPR-tracked consent. Wake-word ground truth and intent labels delivered with the audio. Output is a reusable corpus for in-cabin assistant fine-tuning, not a one-shot dataset.
- Batch 02 Per-OEM wake word · NLU-aligned Delivered
Wake-word and intent dataset for a branded in-cabin assistant
Per-OEM branded wake word with false-accept and false-reject sets, an intent taxonomy aligned to the buyer's NLU schema, and command classification across target-market languages. Ground truth versioned alongside your on-device model so retrain cycles do not lose lineage.
- Batch 03 Euro NCAP 2026 · multi-modal Delivered
DMS audio cues paired with gaze ground truth
Drowsiness, distraction and emergency audio classes captured and labelled with severity tiers, paired with gaze and eyelid ground truth where the DMS spec requires both modalities. Project taxonomies can follow Euro NCAP 2026 in-cabin protocols and defined edge-case coverage.
CH 09The full automotive surface
Voice-led, perception-ready. One vendor, one contract.
The full automotive data surface in one engagement: in-cabin voice corpora, wake-word and DMS audio, perception annotation, real-world capture. EEA jurisdiction across all of it.
Voice and user experience
Data infrastructure and services
Autonomous vehicle technologies
Fleet and operations
CH 10Scope a programme
Tell us the modality, markets and volumes. We reply with a scoped pilot.
Share the actual modalities, target markets, participant profile, capture environment, output schema and acceptance criteria. The pilot and production path are defined around those requirements.
Build
Build a new market or cabin corpus
Cabin scenarios, speaker profiles, scripts and audio requirements become a capture and annotation plan, delivered as an accepted corpus.
Remediate
Evaluate and remediate an existing system
Model outputs and failure cases isolate gaps by market, speaker profile or cabin condition, then drive targeted evaluation or collection.
Produce
Run controlled production at scale
A defined brief, rights model and acceptance criteria become qualification, calibration, production, QA, rework and accepted batches.
- Brief
- Feasibility
- Scoped pilot
- Master DPA
-
A project lead reads your brief
A named EU-resident project lead replies with feasibility, language coverage and a first read on Article 10 risk classification.
-
Scope and cabin-noise spec returned
Target languages, capture profile, wake-word spec and the Article 10 evidence-pack manifest, as an indicative scope.
-
Scoped pilot delivered
The actual modality, markets, participant profile, cabin conditions, output schema and acceptance criteria agreed for the programme.
-
Master DPA, production locked
Processing locations, sub-processors, delivery plan and production acceptance gates agreed before scale-up.
Start with a scoped pilot Modality, markets, volumes, QA and commercial terms, defined from your brief.
Norwegian Aksjeselskap. EEA-resident operations. GDPR Article 7 consent on every contributor. EU AI Act Article 10 evidence pack at delivery.
CH 11Questions
Frequently asked questions
The questions an automotive voice or data lead asks before scoping a programme.
What automotive AI workloads does YPAI support?
YPAI supports in-cabin voice and conversational HMI, driver-monitoring and occupant-monitoring perception, ADAS and autonomous-vehicle perception (multi-camera, LiDAR, radar fusion), and scene-understanding for fleet operations. Production reference points: BYD and Cerence AI are named clients in the automotive segment. Engagements span data collection, annotation, and the documentation needed for type approval and EU AI Act compliance.
What governance evidence does YPAI provide for automotive data?
YPAI delivers versioned annotation specifications, traceability of changes, reviewer-qualification records, dataset documentation, and project-specific acceptance evidence. Personal data is handled under GDPR, processing is scoped in the DPA, and Article 10 evidence is structured for the customer audit trail.
How does YPAI compare to Scale AI for autonomous-vehicle data?
YPAI is EU/EEA-native: data lives under EU jurisdiction by corporate structure, not by contract terms. YPAI is a Norwegian AS with no US parent and no US corporate entity, so it is not a US-domiciled provider under the CLOUD Act. Annotation is run by in-house teams with automotive specialists rather than a crowd marketplace. Pricing is per-project after a feasibility scope. For EU OEMs and tier-1 suppliers concerned about cross-border data transfer rules, this is a structural difference, not a marketing position.
Can YPAI support UNECE WP.29 type-approval evidence?
Yes. Datasets and annotation bundles can be structured to support the evidence chain that UNECE WP.29 type approval (cybersecurity, software-update, automated lane-keeping) requires. The specific scope is confirmed per engagement because type-approval evidence is regulator-facing and the customer compliance team owns the audit. YPAI provides the data-side artefacts that slot into that audit.
Does YPAI deliver datasets for in-cabin driver monitoring?
Yes. Driver-monitoring datasets (eye-gaze, head-pose, occupant-detection, distraction events, drowsiness markers) are collected with consented drivers across cabin lighting conditions and demographic distributions. Synthetic-only datasets are avoided because deployed driver-monitoring systems must perform on real cabin variance, not idealised renders.
Where is automotive data stored and processed?
EU regions by default, anchored on Norway (Oslo) as the home jurisdiction. Annotation and project metadata sit in EU data-centre infrastructure. For OEM engagements that require a specific region or sovereign on-prem handling, the feasibility is confirmed at scoping and the controls are written into the DPA. See automotive voice recognition for the in-cabin specialty.