„Das AIDV entkoppelt die Intention von der Implementierung“

Fahrzeuginnenräume entwickeln sich von reinen Bedienflächen zu kontextsensitiven Interaktionsräumen. Die Frage lautet längst nicht mehr nur, ob sich ein Assistent ins Fahrzeug integrieren lässt. Entscheidend ist vielmehr, wie KI ein optimaler Teil der Fahrzeugsoftwarearchitektur werden kann.

Genau an dieser (Schnitt-)Stelle kommt Shivam Bahedia ins Spiel, sein Jobtitel bei Mercedes-Benz lautet AI & Data Science Specialist and Program Manager for AI-Defined Vehicles. Im Fokus seiner Arbeit stehen Large Language Models, On-Device-Inferenz, multimodale Assistenten und KI-gestützte Personalisierung.

Auf der Automotive Computing Conference Germany hält Bahedia die Keynote „AI in Motion: Reinventing the In-Car Experience with Generative AI“. Im Vorfeld der Veranstaltung sprachen wir mit ihm darüber, worin sich das AI-Defined Vehicle von heutigen Softwarearchitekturen unterscheidet.

Herr Bahedia, ist das AIDV tatsächlich der nächste Architekturschritt nach dem SDV oder vor allem eine KI-Schicht auf den heutigen Architekturen? Und woran ließe sich der Unterschied erkennen?

Der Unterschied ist real, allerdings nur dann, wenn man über das Bereitstellen eines Modells auf bestehender Infrastruktur hinausgeht. Ein SDV hat die Funktion von der Hardware entkoppelt; das Verhalten konnte Over-the-Air aktualisiert werden. Ein KI-definiertes Fahrzeug geht einen Schritt weiter: Es entkoppelt die Intention von der Implementierung. Statt dass Entwickler jede einzelne Funktion von Hand programmieren, leitet die KI die Intention aus dem Kontext ab und erzeugt das Verhalten dynamisch. Der Nachweis liegt in der Architektur: Kann das System eine Funktion erzeugen, die nie von einem Entwickler programmiert wurde? Kann es Signale aus unterschiedlichen Domänen – Kalender, biometrische Daten, Straßenbedingungen, Innenraumzustand – zu einer einheitlichen Entscheidung zusammenführen, ohne dass dafür vorab eine Regel definiert wurde? Wenn dies zum Normalfall und nicht zur Ausnahme wird, ist diese Schwelle überschritten. Nicht darunter fällt hingegen, ein LLM lediglich als besseren Sprachbefehl auf eine ansonsten unveränderte HMI- und Domänenarchitektur aufzusetzen.

Alles zur Automotive Computing Conference Germany

Die Automotive Computing Conference geht den technischen Grundlagen moderner Fahrzeugrechner auf den Grund. Im Fokus stehen High-Performance-Computing im Fahrzeug, moderne E/E-Architekturen, Chiplets, Sicherheitskonzepte, funktionale Sicherheit, Cloud-Anbindung und die wachsende Komplexität softwaredefinierter Fahrzeuge.

Am 18. und 19. November 2026 diskutieren internationale Expertinnen und Experten in München, wie sich klassische Fahrzeugarchitekturen zu leistungsfähigen Computing-Plattformen weiterentwickeln lassen. Keynotes, Panels und Q&A-Sessions zeigen, welche Hardware- und Softwaretrends das Automotive Computing prägen, wie OEMs und Zulieferer mit steigenden Anforderungen umgehen und welche Rolle moderne Halbleiterarchitekturen für künftige SDVs spielen.

Weitere Infos zur Automotive Computing Conference gibt es hier oder auf dem LinkedIn-Kanal.

Wenn On-Device-Modelle leistungsfähiger werden: Wo wird Cloud-KI an Bedeutung verlieren und welche Funktionen werden strukturell von der Cloud abhängig bleiben?

Die Verlagerung auf das Gerät selbst ist real und beschleunigt sich. Echtzeitinteraktionen, sicherheitsrelevante Inferenz und alles, was Latenzen von weniger als 200 ms erfordert, werden auf Edge-Hardware wandern. Personalisierungsmodelle, die privat und unmittelbar reagieren müssen – etwa indem sie die bevorzugte Temperatur antizipieren oder den Sitz einstellen, bevor der Nutzer danach fragt –, können sich keinen Umweg über die Cloud leisten. Strukturell unersetzlich bleibt die Cloud beim Lernen auf Flottenebene, indem anonymisierte Muster aus Millionen Fahrzeugen aggregiert werden, um Modelle zu verbessern, die kein einzelnes Fahrzeug selbst trainieren könnte; bei komplexen mehrstufigen Schlussfolgerungen, die die Rechenbudgets im Fahrzeug übersteigen; sowie bei der Integration externer Live-Dienste wie Verkehrsdaten, Karten, Terminplanung und kommerzieller Ökosysteme. Die architektonische Frage lautet nicht „Cloud oder Edge“, sondern welche Inferenz stattfinden muss, bevor sich das verfügbare Latenzfenster schließt.

Wie Cloud und Edge die KI-Architektur im Fahrzeug bestimmen

Wie entscheiden Sie, welche Funktionen lokal ausgeführt werden, welche auf die Cloud angewiesen sind und welche eine hybride Architektur benötigen?

Vier Kriterien bestimmen diese Entscheidung gleichzeitig. Die Latenz entscheidet darüber, ob eine Interaktion auf dem Gerät ausgeführt werden muss, wenn sie oberhalb von etwa 300 ms nicht mehr ausreichend funktioniert. Aus Datenschutzgründen sollten Daten zu Biometrie, Standortverlauf oder persönlichem Kontext das Fahrzeug standardmäßig nicht verlassen. Die Konnektivität entscheidet darüber, ob sicherheitsrelevante Funktionen und zentrale Komfortfunktionen auch ohne Netzwerkverbindung kontrolliert mit eingeschränkter Funktion weiterarbeiten können, denn sie dürfen nicht von der Cloud abhängig sein. Auch die Rechenkosten spielen eine Rolle, da der lokale Betrieb eines großen Modells bei einem begrenzten Leistungsbudget thermische und kostenseitige Auswirkungen hat, die die Aufteilung beeinflussen. In der Praxis ist anspruchsvolle KI im Fahrzeug meist hybrid: Ein leichtgewichtiges On-Device-Modell übernimmt Echtzeitinteraktion und Kontext, während ein leistungsfähigeres Cloud-Modell offene Schlussfolgerungen und die Generierung von Inhalten übernimmt. Der größte Teil der technischen Komplexität liegt in der Orchestrierungsschicht, die entscheidet, welches Modell wann aufgerufen wird.

„Physische End-to-End-Validierung darf niemals entfallen“

Zentralisierte E/E-Architekturen verändern auch die ECU-Entwicklung. Dr. Florian Baumann von STMicroelectronics erklärt, welche Aufgaben virtuelle MCUs bereits übernehmen können und wo reale Hardware unverzichtbar bleibt.

Benjamin Müller

LLMs und multimodale Modelle entwickeln sich deutlich schneller als Fahrzeughardware. Wie kann eine KI-Architektur upgradefähig bleiben, wenn Rechenleistung und Leistungsbudgets faktisch über Jahre festgelegt sind?

Das ist wohl die zentrale architektonische Herausforderung dieses Jahrzehnts. Drei Prinzipien helfen dabei: die Entkopplung von Modell und Hardware, bei der das Fahrzeug eine Spezifikation für die erforderliche Inferenzfähigkeit hinsichtlich Latenz, Genauigkeit und Leistungsaufnahme definiert, statt ein bestimmtes Modell festzulegen; Quantisierung und Distillation, durch die Modelle der nächsten Generation mittels Kompression in denselben Speicher- und Rechenrahmen passen; sowie die Auslagerung komplexer Aufgaben in die Cloud, wobei das On-Device-Modell den Echtzeitkontext verarbeitet und rechenintensive Schlussfolgerungen bei verfügbarer Verbindung in der Cloud stattfinden. Die Leistungsfortschritte kleinerer und effizienterer Modelle haben in den vergangenen Jahren die Einschränkungen der Hardware kontinuierlich schneller überwunden. Vermeiden sollte man das Risiko, die Architektur auf einen bestimmten Modell-Checkpoint statt auf eine Fähigkeitsschnittstelle auszulegen; genau dadurch entsteht eine fest eingebaute technologische Obsoleszenz.

Wenn Personalisierung zu einer zentralen KI-Fähigkeit wird: Welches Asset ist der eigentliche Differenzierungsfaktor für OEMs – Modelle, Kontextdaten, Orchestrierung, Rechenarchitektur oder User Experience?

Die ehrliche Antwort lautet: Modelle werden sehr schnell zur Commodity; die fortschrittlichsten Modelle stehen grundsätzlich allen Marktteilnehmern zur Verfügung. Die Rechenarchitektur spielt für die Differenzierung eine Rolle, wird jedoch weitgehend von den Halbleiterherstellern vorgegeben. Der nachhaltige Differenzierungsfaktor für OEMs liegt an der Schnittstelle zwischen Kontextdaten und Orchestrierung: proprietäre, mit Einwilligung erzeugte Daten aus dem Fahrzeug – etwa Fahrverhalten, Innenraumzustand, Präferenzhistorie und multimodale Sensorfusion – kombiniert mit einer Orchestrierungsschicht, die weiß, wie diese Daten in Echtzeit eingesetzt werden müssen. Kein externer KI-Anbieter verfügt über Zugang zu diesem Signal. Die User Experience ist Ausdruck dieses Vorteils, entsteht jedoch nachgelagert aus den Daten- und Orchestrierungsfähigkeiten und bildet für sich allein keinen dauerhaften strategischen Schutzwall. OEMs, die das Fahrzeug als Datenquelle für das Lernen auf Flottenebene nutzen und zugleich die Privatsphäre des Einzelnen schützen, werden gegenüber reinen Softwareanbietern einen strukturellen Vorsprung besitzen.

Wie OEMs Sicherheit und Kontrolle über Fahrzeug-KI behalten

Der Output generativer KI ist probabilistisch, nicht deterministisch. Welche Schutzmechanismen sind erforderlich, bevor solche Systeme mit sicherheitsrelevanten Fahrzeugfunktionen interagieren können?

Der Übergang vom Infotainment zur tatsächlichen Fahrzeugaktuation erfordert einen grundlegenden Wandel im Umgang mit KI-Ausgaben. Mehrere Prinzipien sind dabei nicht verhandelbar. Die KI darf niemals uneingeschränkten Zugriff auf Fahrzeugfunktionen erhalten, und jede Aktion muss auf eine vorab validierte, sicherheitszertifizierte API mit definierten Betriebsgrenzen abgebildet werden. Bei jeder Aktion, die über die bereits bekannten Präferenzen des Fahrers hinausgeht, sollte das System vor der Ausführung die Absicht bestätigen – insbesondere bei allem, was die Fahrdynamik beeinflusst. Die KI-Schicht muss oberhalb der Sicherheitsarchitektur nach ISO 26262 und SOTIF liegen und darf diese niemals umgehen. Ein probabilistisches Modell stellt eine Anfrage; ein deterministischer Sicherheitsmonitor entscheidet, ob diese zulässig ist. Probabilistische Systeme erfordern außerdem eine statistische Validierung in großem Maßstab durch umfangreiche Szenariotests und Red Teaming und nicht lediglich funktionale Pass/Fail-Tests. Die Branche bewegt sich auf einen Ansatz zu, bei dem KI Fahrzeugaktionen vorschlagen und vorbereiten kann, während die eigentlichen Aktuierungspfade weiterhin einer formalen Zertifizierungslogik unterliegen.

Hohe Leistungsdichten: Stromversorgung für KI-Server neu gedacht

KI-Server treiben Leistungsaufnahme und Wärmedichte in neue Dimensionen. Effiziente Leistungshalbleiter, digitale Regelung und intelligentes Wärmemanagement werden damit zum Schlüssel für skalierbare und zuverlässige Stromversorgungen im Rechenzentrum.

Josue Navarro

Welchen Teil der KI-Architektur sollte ein OEM niemals auslagern, wenn er seine strategische Differenzierung erhalten will?

Die Kontextdatenschicht und die Orchestrierungslogik. Diese beiden Assets verwandeln reine KI-Fähigkeiten in ein differenziertes Nutzererlebnis. Die Kontextdatenschicht – also die Echtzeitfusion von Fahrzeugzustand, Fahrerverhalten, Umgebung und persönlichen Präferenzen – ist für den jeweiligen OEM einzigartig. Sie kann weder von einem Zulieferer noch von einem Technologiepartner repliziert werden, da sie ausschließlich innerhalb der Beziehung zwischen Fahrzeug und Nutzer entsteht. Die Orchestrierungslogik – also die Intelligenz darüber, welche KI-Fähigkeit wann, bei welchem Konfidenzschwellenwert und in welcher Reihenfolge bei mehrstufigen Aufgaben aufgerufen wird – bestimmt Persönlichkeit und Zuverlässigkeit des Assistenten. Ein OEM, der beides auslagert, wird zum Hardwareintegrator für das KI-Produkt eines anderen Unternehmens. Foundation Models, Sprach-Engines und konkrete Inferenz-Runtimes können lizenziert oder gemeinsam entwickelt werden. Das Integrationsgehirn sollte es nicht sein.