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
Wake-word, intent and driver-monitoring audio, recorded 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.
Why 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.
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.
One session, end to end
One accepted minute, and everything it carries.
An example session, modelled on a live programme: 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.
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
Every batch is reviewed by a native speaker. Failed recordings return for re-recording, rework or replacement according to the project rules.
The 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.
Language 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+
- 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.
We run evaluation engagements, data-collection programmes and active annotation work for OEMs and Tier-1 suppliers.
Programme types
Five programme types. 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
- Euro NCAP 2026 where required
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
How delivery runs
Mobilisation follows the specification.
Reviewers and operations teams work from one shared record of 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 (Lysaker)
- 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 evidence datasets and documentation, per engagement
Engagement types
Three engagement types we run.
- 150+ languages · GDPR consent
In-cabin multilingual voice corpus build
Native-speaker recording across 150+ 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.
- Per-OEM wake word · NLU-aligned
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.
- Euro NCAP 2026 · multi-modal
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 follow Euro NCAP 2026 in-cabin protocols and defined edge-case coverage where the engagement requires them.
The 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 processing by default across all of it.
Voice and user experience
Data infrastructure and services
Autonomous vehicle technologies
Fleet and operations
Scope 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.
Looking for work on AI projects? This form is for companies. Apply as a freelancer
Norwegian Aksjeselskap. EEA residency by default. GDPR Article 7 consent on every contributor. EU AI Act Article 10 evidence pack at delivery.
Questions
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. BYD and Cerence AI are YPAI clients in automotive. 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 is YPAI's annotation model different for autonomous-vehicle data?
YPAI is a Norwegian AS with no US parent and no US corporate entity. Data residency, subprocessors and international-transfer controls are defined per project, and SCCs are available for any customer-directed transfer outside the EEA. Annotation is run by in-house teams with automotive specialists. Pricing is per-project after a feasibility scope. For EU OEMs and Tier-1 suppliers working under cross-border data transfer rules, those controls are written into the DPA before data moves.
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 datasets and documentation that audit needs.
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 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.