Getting AI voice assistants to production: ISO 26262 functional safety and ISO/SAE 21434 cybersecurity requirements

Last year we helped a Tier 1 cabin supplier finish a voice assistant project. During the demo, the driver said 'I'm cold' and the climate control raised the temperature two degrees; said 'find the nearest fast charger' and navigation plotted the route. The customer's executive approved the demo. Three months later, at the pre-production safety review, the functional safety team blocked the system.

Not because the system performed poorly. The issue was simpler: when the voice assistant misheard a command and triggered a driving-related function, no one could identify who was accountable.

What stops smart cabin AI: not the model, but two compliance checkpoints

Smart cabin AI voice assistants are not just chat interfaces. Once they control vehicle functions, connect to the cloud, and receive OTA updates, they must address two automotive regulatory frameworks: functional safety (ISO 26262) and cybersecurity (ISO/SAE 21434). Functional safety addresses 'will a broken system harm people'; cybersecurity addresses 'will an attacked system harm people'. Voice assistants must satisfy both.

Teams often treat all voice commands the same way. They should classify them first.

Functional safety: classify voice commands by ASIL level

ISO 26262 centers on Hazard Analysis and Risk Assessment (HARA), which derives ASIL levels for each function (QM through ASIL D). For voice assistants, map what each command can trigger:

For any ASIL B or higher function, voice must not be the only activation path. False wake-up rates and speech recognition error rates, normally described as performance metrics, function as safety parameters here. A 5% false activation rate that triggers a drive mode switch is not a user experience problem; it is a safety event.

The voice assistant's HMI can itself cause distraction. Flashing screens, interrupting voice, or verbose responses can pull the driver's eyes from the road. This requires human factors testing, not just a single numerical threshold.

Cybersecurity: once voice data hits the cloud, ISO/SAE 21434 applies

Once voice data goes to cloud large language models and models receive OTA updates, the attack surface opens. ISO/SAE 21434 requires Threat Analysis and Risk Assessment (TARA). For voice assistants, focus on these areas:

The microphone and wake word are the primary entry point. Defend against malicious audio injection and cross-vehicle broadcast attacks; research has demonstrated that ultrasonic commands inaudible to humans can be exploited. Voice upload paths must use end-to-end encryption. Document where the driver's voice is stored, how long it is kept, and who can access it. Model OTA updates need signature verification and rollback capability; a single compromised update affects the entire fleet. Design graceful degradation when cloud connectivity drops: losing internet should not break safety functions or cause false triggering, but should fall back safely to local baseline mode.

Both frameworks require the same approach: determine the worst-case scenario for each command before writing code. Do not wait until after the demo succeeds to prepare documentation.

Our approach

When Tenten works on AI cabin integration, we do not start by asking how smart the model is. We work with the customer's functional safety and cybersecurity teams to map voice commands to that table above: which go into QM, which cross ASIL thresholds, which trigger TARA items; and connect each to specific interlocks, confirmations, and degraded modes. Our engineers integrate into your verification process and advance the voice assistant from a working demo to a system ready for production certification. Demos get approvals easily. What counts is getting a system to market and having people confidently use it while driving day to day.