--- title: "In-Cabin Voice, Wake-Word and Driver-Monitoring Data | YPAI" url: https://ypai.ai/solutions/automotive/ description: "In-cabin voice, wake-word, intent and driver-monitoring audio in 150+ languages, recorded in real cabin noise, with supporting ADAS perception annotation." source: "src/copy/routes (route /solutions/automotive/)" --- # Wake-word, intent and driver-monitoring audio, recorded in the cabin in 150+ languages. > In-cabin voice, wake-word, intent and driver-monitoring audio in 150+ languages, recorded in real cabin noise, with supporting ADAS perception annotation. 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 What the cabin adds: engine, HVAC, road, overlap. A named human decision on every batch. ## 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. ### 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. ### 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. ## 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. - **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 - **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. ## 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 - processing by default, with Article 10 evidence at delivery ### Nordic ### Western Europe ### Eastern Europe ### Asia Pacific 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. ### Cerence AI ### Hyundai ### BYD ### Honda ### Kia ### NIO ### Nexdata ## 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. driver · seat 1 · native speaker · consent on file ### 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. Accepted material moves into versioned batches, manifests and secure delivery. ## 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. - **wake word · motorway**: signal. positive · accept - **near-miss variant**: noise. negative · reject - **radio speech · media bleed**: noise. negative · reject - **false accept / false reject**: human. 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. start route guidance to the office - **intent**: signal. navigation.start - **slot · destination**: signal. "the office" - **context**: noise. 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. - **sourcing**: signal. native speaker · professional voice - **prosody**: signal. style set with the brand - **rights**: human. 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. - **drowsiness cue**: signal. severity tiers · gaze-paired - **distraction event**: noise. speaker + seat position - **protocol**: human. 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. - **word errors**: noise. by market · speaker · condition - **intent errors**: noise. against your NLU schema - **gaps**: human. targeted collection brief Capture · Annotation · Native review · Acceptance ## 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. ## Norwegian jurisdiction, by corporate structure. YPAI is a Norwegian Aksjeselskap with no US parent and no US corporate entity. Data residency, subprocessors and international-transfer controls for automotive data are defined per project, with EEA processing by default. - **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 ## Three engagement types we run. ### 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. ### 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. ### 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. ## 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 #### [Automotive AI data across voice, perception and evaluation](https://ypai.ai/automotive/) #### [Speech data for automotive voice recognition](https://ypai.ai/voice-recognition-for-automotive/) #### [Audio and speech annotation](https://ypai.ai/annotation/audio-speech-annotation-services/) #### [Speech data collection](https://ypai.ai/speech-data/) ### Data infrastructure and services #### [Data collection](https://ypai.ai/data-collection/) #### [AI data annotation](https://ypai.ai/ai-data-annotation/) #### [Video annotation services](https://ypai.ai/annotation/video-annotation-services/) #### [Image annotation](https://ypai.ai/annotation/image-annotation/) ### Autonomous vehicle technologies #### [LiDAR and 3D point cloud annotation](https://ypai.ai/annotation/lidar-3d-point-cloud-annotation-services/) #### [Sensor fusion annotation](https://ypai.ai/annotation/sensor-fusion-annotation-services/) #### [Semantic segmentation](https://ypai.ai/annotation/semantic-segmentation-annotation-services/) ### Fleet and operations #### [Telematics annotation](https://ypai.ai/ai-data-annotation/) #### [Fleet dashcam video annotation](https://ypai.ai/annotation/video-annotation-services/) ## 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. Brief · Feasibility · Scoped pilot · Master DPA ### 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. ### 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. ### Run controlled production at scale - A defined brief, rights model and acceptance criteria become qualification, calibration, production, QA, rework and accepted batches. ### 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. Modality, markets, volumes, QA and commercial terms, defined from your brief. We reply inside one EU business day with a feasibility read for automotive programs. Sensor-fusion and validation specs ship with the first reply. Norwegian Aksjeselskap. EEA residency by default. GDPR Article 7 consent on every contributor. EU AI Act Article 10 evidence pack at delivery. ## 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.