Interview with Shivam Bahedia, Mercedes-Benz
“AI-defined vehicles separate intent from implementation”
Before joining the German OEM in 2021, Shivam Bahedia worked as a data science researcher at Procter & Gamble.
Shivam Bahedia
Cockpits are becoming more intelligent, contextual and personalised as assistants, displays and driver interfaces converge. Mercedes-Benz AI specialist Shivam Bahedia explains what it takes to bring generative AI into production vehicles.
Vehicle interiors are evolving from control surfaces into context-aware interaction spaces. The question is no longer only whether a vehicle can host an assistant, but how AI can become part of the vehicle software architecture, act on context and still meet automotive requirements for safety, latency and reliability.
Shivam Bahedia, AI & Data Science Specialist and Program Manager for AI-Defined Vehicles at Mercedes-Benz, works on next-generation in-car technology, including large language models, on-device inference, multimodal assistants, embedded intelligence and personalised user experiences.
At the Automotive Computing Conference Germany, he will give a keynote titled “AI in Motion: Reinventing the In-Car Experience with Generative AI”. Ahead of the event, we spoke with Bahedia about where the AI-defined vehicle differs from today’s software architectures, which functions belong on-device or in the cloud, and what OEMs should never outsource.
Is the AI-defined vehicle genuinely the next architectural step after the software-defined vehicle, or mainly an AI layer on top of today’s E/E and software architecture? What would prove the difference?
The distinction is real, but only when you go beyond deploying a model on existing infrastructure. A software-defined vehicle separated the function from the hardware; you could update behaviour over the air. An AI-defined vehicle goes further: it separates intent from implementation. Instead of engineers hand-coding each feature, AI infers intent from context and generates behaviour dynamically. The proof is architectural: can the system create a function that was never written by a developer? Can it merge signals across domains — calendar, biometrics, road conditions, cabin state — into a unified decision without a prespecified rule? When that is the norm rather than the exception, you have crossed the threshold. What does not qualify is taking an LLM and using it as a better voice trigger on top of an otherwise unchanged HMI and domain architecture.
As on-device models improve, where will cloud AI lose relevance, and which functions will remain structurally cloud-dependent?
The on-device shift is real and accelerating. Real-time interaction, safety-relevant inference and anything requiring sub-200 ms latency will migrate to edge silicon. Personalisation models that need to act privately and instantly — anticipating your temperature preference, adjusting your seat before you ask — cannot afford a round trip. Where cloud remains structurally irreplaceable is in fleet-level learning, aggregating anonymised patterns across millions of vehicles to improve models no single car could train; complex multi-step reasoning that exceeds on-device compute budgets; and integration with live external services such as traffic, maps, scheduling and commercial ecosystems. The architectural question is not “cloud versus edge”, but which inference has to happen before the latency window closes.
How do you decide which functions run locally, which rely on the cloud and which need a hybrid architecture?
Four criteria drive that decision simultaneously. Latency determines whether an interaction must run on-device if it fails above around 300 ms. Privacy means anything tied to biometrics, location history or personal context should not leave the vehicle by default. Connectivity determines whether safety-relevant and core comfort functions can degrade gracefully without a network, because they cannot be cloud-dependent. Compute cost also matters, as running a large model locally on a constrained power budget has thermal and cost implications that shape the split. In practice, most sophisticated in-car AI ends up hybrid: a lightweight on-device model handles real-time interaction and context, while a more capable cloud model handles open-ended reasoning and content generation. The orchestration layer that decides which model to invoke, and when, is where most of the engineering complexity lives.
Large language and multimodal models evolve far faster than vehicle hardware. How can an AI architecture remain upgradeable when compute and power budgets are effectively fixed for years?
This is arguably the central architectural challenge of the decade. Three principles help: model–hardware decoupling, where the vehicle defines an inference capability contract covering latency, precision and power envelope, rather than a specific model; quantisation and distillation, where next-generation models fit into the same memory and compute footprint through compression; and cloud offload for complexity, where the on-device model handles real-time context while heavy reasoning runs in the cloud when connectivity permits. The capability gains in smaller, more efficient models have consistently outpaced hardware constraints over recent years. The risk to avoid is designing around a specific model checkpoint rather than around a capability interface; that is how you end up with locked-in obsolescence.
If personalisation becomes a core AI capability, which asset is the real OEM differentiator: models, contextual data, orchestration, compute architecture or user experience?
The honest answer is that models are rapidly commoditised; the frontier is accessible to all players. Compute architecture matters at the margins but is largely determined by silicon suppliers. The durable OEM differentiator is the intersection of contextual data and orchestration: the proprietary, consented data generated inside the vehicle, such as driving behaviour, cabin state, preference history and multimodal sensor fusion, combined with an orchestration layer that knows how to apply it in real time. No external AI provider has access to that signal. The user experience is the expression of that advantage, but it is downstream of the data and orchestration capability, not a standalone moat. OEMs that treat the car as a data source for fleet learning while preserving individual privacy will hold a structural lead over pure software players.
Generative AI outputs are probabilistic, not deterministic. What safeguards are required before such systems can interact with safety-relevant vehicle functions?
The transition from infotainment to vehicle actuation requires a fundamental change in how AI outputs are handled. Several principles are non-negotiable. The AI should never have unconstrained access to vehicle functions, and every action must map to a prevalidated, safety-certified API with defined operating envelopes. For any action beyond the driver’s established preferences, the system should confirm intent before executing, especially for anything that affects vehicle dynamics. The AI layer must sit above, and never bypass, the ISO 26262/SOTIF safety architecture. A probabilistic model makes a request; a deterministic safety monitor decides whether it is permissible. Probabilistic systems also require statistical validation at scale through extensive scenario testing and red teaming, not just pass/fail functional tests. The industry is converging on a position where AI can propose and prepare vehicle actions, while actuation paths remain under formal certification discipline.
Which part of the AI architecture should an OEM never outsource if it wants to preserve strategic differentiation?
The contextual data layer and the orchestration logic. These are the two assets that convert raw AI capability into a differentiated experience. The contextual data layer — the real-time fusion of vehicle state, driver behaviour, environment and personal preferences — is unique to the OEM. It cannot be replicated by a supplier or a tech partner because it exists only inside the vehicle relationship. The orchestration logic — the intelligence about which AI capability to invoke, when, at what confidence threshold and how to sequence multi-step tasks — defines the personality and reliability of the assistant. An OEM that outsources both ends up as a hardware integrator for someone else’s AI product. Foundation models, voice engines and specific inference runtimes can be licensed or co-developed. The integration brain should not be.
