Sprachassistent im Fahrzeug und in eingebetteten Geräten

Die klassische Sprachsteuerung im Auto versteht einige Dutzend feste Befehle und scheitert, sobald Fahrer natürlich sprechen. Hybride Assistenten aus eingebetteter Technik und Cloud verbinden Spracherkennung auf dem Gerät mit großen Sprachmodellen, die freie Anfragen verstehen, Fahrzeugfunktionen als Werkzeuge aufrufen, Fragen zur Betriebsanleitung beantworten und mit Kontext Gespräche führen. Der Gewinn ist eine sicherere, weniger ablenkende Bedienung und ein Markenerlebnis, das sich abhebt; die schwierigen Teile sind Latenz, Offline-Verhalten, Sicherheit und Datenschutz.

Problem & Nutzen

• Heute: Touchscreens verlangen beim Fahren visuelle Aufmerksamkeit. Ältere Sprachsysteme decken nur eine begrenzte Menge vordefinierter Aufgaben ab und versagen bei Formulierungen außerhalb des Skripts; viele Nutzer hören deshalb auf, sie zu nutzen, oder weichen auf die Smartphone-Spiegelung aus (Apple CarPlay, Android Auto), die dem Hersteller keine Kontrolle über das Erlebnis und die Daten lässt.
• KI-Nutzen: natürlicher Dialog über mehrere Runden („Den Kindern hinten ist es zu kalt, und such eine Ladesäule mit Café auf dem Weg"), Anfragen aus mehreren Bereichen in einem Satz, Antworten aus der Betriebsanleitung und zur Fehlersuche ohne Blättern im Handbuch, proaktive Vorschläge und mehrsprachige Unterstützung.
• Belege: Mercedes-Benz beschreibt, dass das frühere MBUX etwa 20 vordefinierte Aufgaben bewältigte, und ist auf einen generativen, agentischen virtuellen Assistenten umgestiegen, der zuerst im CLA gezeigt wurde; Cerence liefert die Sprachein- und -ausgabe in etwa 25 Sprachen, und der Automotive-Agent von Google Cloud ergänzt dialogbasierte Navigation auf Basis von Google-Maps-Daten [1][2][3]. Unabhängige Zahlen zur Unfallreduzierung gibt es nicht; betrachten Sie den Nutzen bei der Ablenkung als plausibel, aber unbewiesen.

Varianten

• Pkw: vollständiger Assistent mit Fahrzeugsteuerung, Navigation, Laden, Medien und Fragen zur Betriebsanleitung.
• Nutzfahrzeuge & Lkw: freihändige Disposition, Abfragen zu Tachograf/Lenk- und Ruhezeiten, Ladungsinformationen.
• Zweiräder, Boote, Land- und Baumaschinen: laute Umgebungen, Handschuhe und Helme, oft nur Befehlssätze ohne Verbindung.
• Andere eingebettete Geräte: Haushaltsgeräte im Smart Home, Kaffeemaschinen, medizinische und industrielle Bedienoberflächen, E-Bikes, smarte Lautsprecher ohne Cloud-Abhängigkeit.
• Private Nutzung / Nachrüstung: Assistenten für die Nachrüstung und smartphonebasierte Assistenten (CarPlay, Android Auto, Gemini oder Siri); selbst gebaute Open-Source-Sprachsatelliten für Bastler.

So funktioniert es

1. microphone array (multi-zone, echo/noise cancellation, wake word)
2. on-device ASR (embedded) ⇄ cloud ASR (when connected)
3. intent routing: embedded NLU for safety-relevant/offline commands | LLM for open requests
4. LLM agent with tool calls (vehicle-function API, navigation, charging, calendar, RAG over manual)
5. policy/guardrail layer (what may be actuated while driving, confirmation rules)
6. response generation
7. on-device or streaming TTS
8. speaker zone
9. logging with consent; feedback to OEM backend

• Hybride Architektur: Weckwort und einfache Befehle laufen vollständig im Steuergerät (Head Unit), sodass sie in Tunneln und ohne Einwilligung in die Cloud-Verarbeitung funktionieren; das LLM läuft in der Cloud oder, zunehmend, übernimmt ein kleines Modell auf dem Gerät einfache Fälle. Das Routing entscheidet je Äußerung.
• Werkzeugnutzung: Das LLM spricht nie direkt mit dem CAN-Bus. Es setzt Aufrufe gegen eine freigegebene, versionierte Fahrzeugfunktions-API ab; das Gateway prüft Fahrzustand, Nutzerberechtigung und Sicherheitsklasse. Sicherheitskritische Funktionen (Lenkung, Bremsen, Fahrmodi während der Fahrt) sind ausgeschlossen.
• Echtzeit-Sprache: Durchgängige Sprache-zu-Sprache-Modelle sowie Streaming-ASR/-TTS senken die Latenz und ermöglichen natürliches Ins-Wort-Fallen; die kaskadierte Pipeline bleibt die besser kontrollierbare und zertifizierbare Option.
• Mensch-in-der-Schleife (Human-in-the-Loop): Bestätigung bei folgenreichen Aktionen (Käufe, Anrufe, Nachrichten), eine sichtbare Rückfallebene auf Touch und physische Tasten sowie Eskalation an Werkstatt/Service.

Datenaufbereitung

Die Daten kommen aus mehreren Welten: die Betriebsanleitung und das Servicewissen (PDFs, Redaktionssysteme, DMS), Fahrzeugsignale und Funktionskataloge (Konstruktionsspezifikationen, Signaldatenbanken), Navigations- und POI-Daten von Zulieferern sowie Sprachaufnahmen zur Abstimmung. Typische Lücken: Handbücher, die für den Druck statt für die Suche geschrieben wurden, uneinheitliche Funktionsnamen über Modellvarianten hinweg, fehlende Synonyme und Dialektformulierungen, wenig echte Sprache im Innenraum mit Geräuschen und unklare Einwilligung für Sprachdaten.

Schritte der Aufbereitung: Handbücher in kurze, nach Variante gekennzeichnete Abschnitte umstrukturieren (PREP-014, PREP-010), ein Glossar der Funktionen und umgangssprachlichen Synonyme pflegen (PREP-015, PREP-012), den Katalog der Befehle und Anliegen (Intents) festlegen (PREP-019), mit Fachleuten Testäußerungen über Dialekte, Altersgruppen und Geräuschbedingungen hinweg sammeln (PREP-018) und Aufnahmen vor der Verwendung pseudonymisieren (PREP-022). Dokumentieren Sie Rechtsgrundlage und Aufbewahrung für Sprachdaten (PREP-025). Werkzeuge: Dokumentkonverter, eine Vektordatenbank, Sprachdatensätze, Simulationsaufbauten. Grober Anteil am Aufwand: etwa 30 Prozent, mit Funktionskatalog und Testdaten als Hauptteilen.

Umsetzungswege

Welcher Weg für wen

• Unternehmen (Fahrzeughersteller, Tier-1-Zulieferer): Weg B, weil das Spracherlebnis ein Markenunterscheidungsmerkmal ist, mit Fahrzeugsignalen und eigenen Backends integriert werden muss und eine Mischung aus Cloud-LLM und Rückfallebene auf dem Gerät die Kontrolle über Daten und Kosten je Fahrzeug erhält.
• Entwickler (Gerätehersteller und Entwickler eingebetteter Systeme): Weg C, weil offene ASR-, TTS- und kleine Modelle auf Edge-Hardware (HW1) offline laufen, bei Flottenvolumen keine Gebühren je Anfrage anfallen und die Sprachdaten im Gerät bleiben.
• Privat (Fahrer, E-Bike-Besitzer, Bastler): Weg A, weil der Assistent im Fahrzeug oder in einer zertifizierten App bereits eingebaut ausgeliefert wird; Bastler können lokale Open-Source-Sprach-Stacks nutzen.

Weg A — Kaufen (Standardsoftware)

• Sprachplattformen für Fahrzeuge: Cerence (xUI / CaLLM-Familie; treibt Mercedes-Benz MBUX an), SoundHound (OEM-Sprach-KI), Amazon Alexa Custom Assistant / Alexa Built-in, Google Gemini und Google built-in (Android Automotive OS), Apple CarPlay für die Smartphone-Projektion. Für die EU relevante Optionen: Cerence (Hauptsitz in den USA, großer Entwicklungsstandort in Aachen), hauseigene Stacks der Hersteller wie MB.OS und Mistral-basierte Sonderlösungen; chinesische Stacks (Baidu, iFlytek) sind für Exportmärkte wichtig.
• Sprache für eingebettete Geräte: Picovoice (Weckwort und Sprache-zu-Intent auf dem Gerät, Kanada), Sensory, Fluent.ai (offline), DSP Concepts für Audio-Frontends.
• Wählen Sie A, wenn: Sie produktionsreife mehrsprachige Abdeckung, ein zertifiziertes Audio-Frontend und eine Roadmap brauchen; prüfen Sie Datenspeicherung in der EU, wem die Daten und die Trainingsrechte gehören und die Markenkontrolle des Herstellers.

Weg B — Auf Cloud-KI-Diensten aufbauen

• Modelle: Mistral (EU) oder andere LLMs mit Function Calling; Azure OpenAI oder Google Vertex AI in EU- Regionen; Claude über Cloud-Endpunkte in EU-Regionen; Echtzeit-Sprach-APIs (z. B. OpenAI Realtime, Gemini Live) oder Deepgram/ElevenLabs/Azure Speech für kaskadierte Pipelines.
• Orchestrierung: Agenten-Framework mit strikten Werkzeugschemata, ein Gateway für die Fahrzeug-API, RAG über die Betriebsanleitung (siehe Familie KNOW), Telemetrie über die Cloud des Herstellers. Nutzen Sie die eingebauten Sprachinteraktionsdienste von Android Automotive OS als Integrationspunkt ins System [4].
• Wählen Sie B, wenn: Sie Fahrzeughersteller oder Tier-1 mit einem Entwicklungsteam sind und die Kontrolle über das Dialogdesign wollen; behalten Sie eine eingebettete Rückfallebene für die Offline-Nutzung.

Weg C — Selbst betreiben (Open Source)

• Auf dem Gerät/am Edge: whisper.cpp oder Whisper-turbo-Varianten, Vosk, sherpa-onnx, Piper TTS, openWakeWord; kleine LLMs (Qwen 3 small, Llama 3.2 1-3B, Phi, Gemma 3n, Mistral Ministral), quantisiert über llama.cpp, ExecuTorch oder ONNX Runtime auf Automotive-SoCs (Qualcomm Snapdragon Cockpit, NVIDIA DRIVE/Jetson Orin, Ambarella, Renesas).
• Serverseitig: vLLM mit einem offenen Modell von 7-30B für schwierigere Anfragen; Assist / das Wyoming-Protokoll von Home Assistant ist eine praxistaugliche offene Referenz für private eingebettete Sprach-Pipelines.
• Hardware: HW1 für die eingebettete Inferenz; HW2/HW3 für das Modell im Backend.

Weg D — Eigenes Training

Lohnt sich für herstellerspezifisches Vokabular, Dialekte, die Akustik im Innenraum und Tool Calling über proprietäre Fahrzeug-APIs: ein kleines Modell für Function Calling und Routing feintunen und die ASR an Innenraumgeräusche und Akzente anpassen. Dafür braucht es Tausende annotierter Äußerungen aus dem Innenraum sowie synthetische Dialoge; erheben Sie sie mit ausdrücklicher Einwilligung und Datenschutz durch Technikgestaltung.

Stand der Technik (2026)

• Von Befehlen zu Agenten: Hersteller liefern LLM-gestützte Assistenten aus (Mercedes-Benz MBUX mit Cerence und Google, dazu Ankündigungen anderer europäischer und globaler Hersteller), die Fahrzeug- funktionen und externe Dienste als Werkzeuge aufrufen [1][2][3].
• Hybride Inferenz: kleine Modelle auf dem Gerät für Latenz und Offline-Betrieb, große Cloud-Modelle für Wissen und Schlussfolgern; dynamisches Routing ist das zentrale Ingenieursthema.
• Sprache-zu-Sprache und Proaktivität: natürliche Unterbrechungen und kontextbezogene Vorschläge kommen auf; reine Sprachbedienung liegt bei Aufgaben, die Präzision verlangen, weiter hinter Touch zurück.
• Grenzen und Fehlerbilder: erfundene Antworten zum Fahrzeug (falsche Reifendrücke oder Sicherungsdaten), Fehlerkennung bei Lärm oder mit Akzent, Latenzspitzen bei schlechter Mobilfunkabdeckung, Prompt Injection über Webinhalte oder die Sprache von Mitfahrern, ungewollte Auslösung durch andere Insassen oder Medienton und kognitive Belastung durch ausführliche Antworten. Halten Sie Antworten kurz und stützen Sie Antworten zur Betriebsanleitung auf abgerufenen Text.

Gemeinsame Bausteine & Kombinationen

• Gleicher Stack: CONV-002 (Voicebot-ASR/-TTS und Dialogsteuerung), SPEECH-003 (Echtzeitübersetzung), SPEECH-006 (TTS), CONV-015 (persönlicher Assistent: Kalender, Mail, Aufgaben), Familie KNOW (RAG über die Betriebsanleitung).
• Kombinieren mit: CONV-001 (Service-Chat nach der Fahrt), CONV-024 (Sprache für Kinder auf den Rücksitzen), vorausschauende Wartung auf Telemetriedaten (siehe Familie PRED) für proaktive Werkstattbuchung.
• Hardware: Das eingebettete SoC (HW1) wird von Fahrassistenz- und Cockpit-Lasten gemeinsam genutzt; die Bereitstellung im Backend wird mit anderen Sprachprodukten geteilt.

Aufwand, Kosten & Kennzahlen

• Weg A: 6-18 Monate in einem Fahrzeugprogramm (Integration, Homologation, Sprachpakete); Lizenz üblicherweise je Fahrzeug plus Cloud-Nutzung.
• Weg B: 6-12 Monate für eine produktionsreife Pipeline; Kosten für Cloud-Token/Audiominuten wachsen mit der Flottengröße.
• Weg C: 9-18 Monate; die Optimierung für eingebettete Systeme und die Validierung bestimmen die Kosten.
• Kennzahlen: Aufgabenabschlussquote, Wort-/Intent-Fehlerrate unter Innenraumbedingungen, Ende-zu-Ende-Latenz (Sprachende bis zum ersten Ton), Offline-Abdeckung, Anteil der Sprachnutzung gegenüber Touch, Nutzerzufriedenheit, sicherheitsrelevante Übersteuerungen, Kosten je aktivem Fahrzeug.

Menschen & Veränderung

Beziehen Sie zuerst Geschäftsleitung und Produktverantwortliche ein, dann Entwicklung/IT, IT-Sicherheit (Sicherheit von Fernbefehlen), die Datenschutzbeauftragte bzw. den Datenschutzbeauftragten und Recht (Produkthaftung, UNECE-Vorschriften, Ablenkung des Fahrers) sowie die Zulieferer für ASR, Karten und Head Units. Die Nutzer sind Kunden; führen Sie daher früh Kliniken und Feldtests mit echten Fahrern durch.

Betriebsrat: abhängig vom Einzelfall. Das Produkt selbst richtet sich an Kunden, aber interne Testfahrten, Flottendaten und die Aufzeichnung der Sprache von Beschäftigten können das Verhalten überwachen; dann greift § 87 Abs. 1 Nr. 6 BetrVG. § 90 Abs. 1 Nr. 3 erfasst auch KI im Entwicklungsprozess. Eine Datenschutz-Folgenabschätzung (DSFA) ist bei Sprach- und Standortdaten wahrscheinlich; schließen Sie mit jedem Auftragsverarbeiter einen Auftragsverarbeitungsvertrag (AVV). Bieten Sie ein Opt-in für die Speicherung von Sprache an und machen Sie die lokale Verarbeitung zum Standard.

KI-Kompetenz: Unterstützen Sie Entwickler, Tester und Servicepersonal mit Schulungen (KI-Verordnung (AI Act) Art. 4; GUIDE-006). Kommunizieren Sie transparent, dass Nutzer mit einer KI sprechen (Art. 50) und dass sicherheitskritische Funktionen unter deterministischer Kontrolle bleiben. Starten Sie den Pilot mit einer kleinen Fahrzeugflotte oder einer Gerätelinie. Typische Sorgen: Privatsphäre („hört das Auto mit?") und Ablenkung; begegnen Sie ihnen mit Weckwort-Design, sichtbaren Anzeigen und klaren Dateneinstellungen. Siehe GUIDE-005, GUIDE-008 und GUIDE-013.

Risiken, Regulierung & Compliance

• KI-Verordnung (AI Act): typischerweise begrenztes Risiko: Nutzer müssen informiert werden, dass sie mit einem KI-System interagieren, und synthetische Sprache muss erkennbar sein, wo Art. 50 gilt; Pflicht zur KI-Kompetenz (Art. 4). Der Assistent selbst ist kein Sicherheitsbauteil. Vorsicht bei Art. 5: Fügen Sie keine Emotionserkennung von Fahrern hinzu, die aus Stimme oder Gesicht abgeleitet wird, im Beschäftigungskontext (z. B. Firmenflotten) — am Arbeitsplatz verboten; Fahrerüberwachung für die Sicherheit ist gesondert geregelt, und biometrische Kategorisierung oder Identifizierung von Insassen per Stimme braucht eine eigene rechtliche Bewertung [5]. Steuert KI Sicherheitsfunktionen, können stattdessen das Fahrzeug- Typgenehmigungsrecht und die Hochrisiko-Regeln über Anhang I gelten.
• DSGVO / ePrivacy: Sprachaufnahmen, Standort, Fahrverhalten und Kontaktdaten sind personenbezogene Daten; Fahrzeughalter, Mitfahrer und Vorbesitzer sind jeweils eigene betroffene Personen. Die Leitlinien des EDSA zu vernetzten Fahrzeugen verlangen, wo möglich, lokale Verarbeitung, klare Einwilligung für jeden Zweck und einfache Löschung; Art. 5 Abs. 3 der ePrivacy-Richtlinie gilt für den Zugriff auf Endeinrichtungen [6]. Die ständig mithörende Weckworterkennung muss auf dem Gerät bleiben.
• Fahrzeugregulierung: UNECE R155 (Cybersicherheitsmanagement) und R156 (Software-Updates) sind Bedingungen der EU-Typgenehmigung; die EU-Verordnung über die allgemeine Fahrzeugsicherheit 2019/2144 enthält Vorgaben zur Fahrerablenkung [7]. Der EU Data Act gibt Nutzern Zugang zu fahrzeuggenerierten Daten.
• Gegenmaßnahmen: Whitelist für die Fahrzeug-API, Sperren je nach Fahrzustand, Bestätigungsabfragen, Filter gegen Injection, begründete Antworten mit Quelle, Verarbeitung zuerst auf dem Gerät, Aufbewahrungsgrenzen, Red-Team-Tests.

Erste Schritte

1. Legen Sie den Umfang fest: Welche Funktionen dürfen während der Fahrt per Sprache gesteuert werden, welche offline.
2. Sammeln Sie je Sprache 200-500 echte Äußerungen aus dem Innenraum (mit Einwilligung) und messen Sie die Ausgangsfehlerraten.
3. Bauen Sie einen hybriden Prototyp: Weckwort und ASR auf dem Gerät, Cloud-LLM mit einer simulierten Fahrzeugfunktions-API.
4. Führen Sie eine Sicherheits-/Datenschutzbewertung durch (DSFA, TARA nach R155), bevor Sie im Fahrzeug testen.
5. Starten Sie einen Pilot mit einer kleinen Flotte und verfolgen Sie die Kennzahlen; erweitern Sie den Werkzeugzugriff erst nach einer Prüfung.

Quellen

1. Cerence — Cerence AI powers in-car experience in Mercedes-Benz's new electric sedan — https://www.cerence.com/newsroom/press-releases/cerence-ai-powers-in-car-experience-in-premier-german-automakers-new-electric-sedan
2. Voicebot.ai — Mercedes-Benz will keep using Cerence to run revamped MBUX Virtual Assistant — https://voicebot.ai/?p=21059
3. eWeek — Mercedes adds conversational navigation with Gemini AI — https://www.eweek.com/news/mercedes-gemini-ai-navigation/
4. Android Developers — Android Automotive OS — https://source.android.com/docs/automotive
5. Regulation (EU) 2024/1689 (AI Act) — https://eur-lex.europa.eu/eli/reg/2024/1689/oj
6. EDPB — Guidelines 01/2020 on connected vehicles — https://www.edpb.europa.eu/our-work-tools/our-documents/guidelines/guidelines-012020-processing-personal-data-context_en
7. UNECE — UN Regulations 155 (cybersecurity) and 156 (software updates) — https://unece.org/transport/vehicle-regulations
8. Home Assistant — Assist voice control — https://www.home-assistant.io/voice_control/