What Comes After the Software-Defined Vehicle?

August 10, 2026

For the past several years, automakers and semiconductor companies have been working toward the software-defined vehicle (SDV), an architecture designed to separate vehicle functions from the individual electronic control units (ECUs) that traditionally controlled them.

The transition is still underway, but the industry is already talking about what comes next.

For example, back in January, at CES 2026, Qualcomm introduced the term “AI-defined vehicle” (AIDV) to describe vehicles in which AI models and agents have a larger role in shaping vehicle functions and interactions.[1] NVIDIA is using the term as well. Xinzhou Wu, NVIDIA’s vice president of automotive, recently described the move from software-defined to AI-defined vehicles as the next phase in a progression that has taken the car from a largely mechanical machine to one whose capabilities can be changed through software.[2]

The distinction is worth examining because vehicles have used artificial intelligence for years. Machine learning is already involved in object detection, driver monitoring, voice recognition, predictive maintenance and advanced driver-assistance systems (ADAS).

Putting more AI into a vehicle does not necessarily make it AI-defined.

What could make this next step different is where AI sits in the decision-making process. Software-defined architectures made it possible to change vehicle functions without replacing the hardware responsible for them. An AI-defined architecture could go further, allowing models to interpret information from across the vehicle and decide how multiple functions should respond.

That sounds like a subtle difference. Inside the vehicle, it could be a significant one.

From Following Commands to Interpreting Intent

Consider something as simple as adjusting the temperature.

A conventional electronic climate-control system responds to specific inputs. Set the cabin temperature to 70°F and the controller works toward that target.

Voice control changed the interface but not necessarily the underlying relationship. A driver might say, “Set the temperature to 70 degrees,” instead of pressing a button.

Generative and agentic AI introduce another possibility. A driver says, “I’m cold.”

The vehicle now has to interpret what that means and determine what to do about it. Depending on the information available, an AI agent could adjust cabin temperature, turn on the heated seat or steering wheel, account for which seats are occupied and perhaps make different choices depending on available battery energy.

The distinction is not the voice command. It is the coordination behind it.

Qualcomm’s Snapdragon Chassis Agents are being developed around this idea. The company describes agents that combine on-device AI inference with access to vehicle systems and information from inside and outside the vehicle. Rather than operating only as an infotainment assistant, an agent could coordinate functions across traditionally separate vehicle domains.[1]

Qualcomm has offered examples ranging from recognizing vehicle occupants to monitoring vehicle health, responding to road conditions and assisting during emergencies.

Some of those capabilities already exist individually. Bringing them together is where the architecture begins to change.

The Car Has More to Tell the AI

An AI agent is only as useful as the information available to it.

Modern vehicles already generate enormous amounts of information through cameras, radar, ultrasonic sensors, microphones, battery-management systems, wheel-speed sensors, inertial sensors and other devices. ADAS processors use some of that information to understand the environment outside the vehicle, while cockpit systems use another set of information to understand the driver and passengers.

Those systems have traditionally been developed as separate domains.

Software-defined architectures are beginning to break down some of those boundaries through centralized compute and zonal electrical architectures. AI gives automakers another reason to do it.

An agent that knows a driver is getting tired, for example, could theoretically combine information from an interior driver-monitoring camera with navigation data, vehicle speed and information about nearby charging or rest locations. A system concerned about range could look beyond battery state of charge and consider route, traffic, outside temperature, cabin energy use and driving behavior.

The interesting part is not whether every vehicle will perform those exact tasks. It is that information collected for one function could become useful to another.

That makes the data moving around the vehicle increasingly valuable.

AI Moves the Compute Problem Into the Car

More capable models also require considerably more processing.

This is one reason the transition toward centralized automotive computing is happening alongside the development of AI-defined vehicles. Instead of distributing processing among dozens of ECUs designed around individual functions, automakers are moving more workloads onto high-performance computing platforms.

These processors are becoming heterogeneous systems themselves.

Qualcomm’s current automotive architecture, for example, combines CPUs, GPUs and NPUs so different workloads can run on the type of compute best suited to them.[3] NVIDIA is similarly developing centralized automotive computing platforms intended to support AI, automated driving and other vehicle workloads.

Memory is becoming part of this equation as well. In July 2026, Micron announced long-term supply agreements with Qualcomm and several major automotive suppliers for memory and storage used in AI-enabled vehicle platforms. The agreements include DENSO, Hyundai Mobis, Harman, Visteon and Astemo.[4]

That is an indication of where automotive computing is heading. Running increasingly large models does not only require more processing performance. The system needs enough memory capacity and bandwidth to keep that processing hardware supplied with data.

It also has to do it within an automotive power and thermal budget.

A data center can add racks, cooling and electrical infrastructure as AI workloads grow. A vehicle has a finite amount of space and energy, and every watt consumed by computing eventually becomes heat that has to be removed.

For an electric vehicle, it also comes from the same stored energy used to move the car.

Some Decisions Cannot Wait for the Cloud

Cloud computing will remain part of this architecture. Automakers already use cloud infrastructure for software development, fleet data, simulation, model training and over-the-air updates.

The harder question is where inference takes place.

As AI models grow more capable, sending every problem to the cloud becomes tempting because the cloud has far greater computing resources than the vehicle. It also introduces network availability and latency into the decision.

That is acceptable for some applications. It is not acceptable for others.

A request to find a restaurant can tolerate a delay. Recognizing that a pedestrian has entered the vehicle’s path cannot.

Research published in 2026 illustrates how quickly this becomes a systems problem. One recent study examining cloud offloading for autonomous-driving models separated vehicle decisions into a 100-millisecond reactive tier and a 300-millisecond deliberative tier. The researchers found that communication bandwidth alone does not solve the problem. Compute latency, network loading and the type of AI model all determine whether cloud inference is practical.[5]

That suggests the AI-defined vehicle is unlikely to be entirely edge-based or cloud-based.

It will have to decide where intelligence belongs.

Fast, safety-critical perception and control will continue to favor processing inside the vehicle. Larger models performing less time-sensitive reasoning could make greater use of cloud resources. Other workloads could move between the two depending on connectivity, cost and available onboard compute.

In that sense, where the AI runs could become almost as important as what the AI does.

What Happens When the Model Changes?

Software-defined vehicles introduced another important idea: the vehicle does not have to leave the factory with every capability it will ever have.

Over-the-air updates allow software to change during the vehicle’s operating life.

AI complicates that model.

A conventional software update replaces code that engineers have written and validated. Updating an AI capability might mean changing the model itself. The new model could have different memory requirements, require more processing performance or behave differently when it encounters the same inputs.

Automakers also have to support more than one hardware configuration.

A vehicle platform could remain in production for years, with different models and price levels using different amounts of computing performance. Vehicles already on the road could remain there for another decade or longer.

Qualcomm identifies AI model portability across vehicle tiers and model years as one of the practical challenges facing AI-defined vehicle development. If every new model has to be separately redesigned and optimized for every processor and vehicle configuration, development complexity grows quickly.[3]

That makes hardware scalability important before anyone knows exactly what AI models those vehicles will be running several years from now.

Who Defines the Vehicle Next?

The term “AI-defined vehicle” will inevitably invite some skepticism. The automotive industry has barely settled on a definition of the software-defined vehicle, and adding AI to the name does not automatically create a new architecture.

But there is a useful distinction hiding underneath the terminology.

Software-defined vehicles changed the relationship between vehicle hardware and software. Functions that once remained closely tied to a particular ECU can increasingly move onto centralized computing platforms, communicate through shared networks and change after the vehicle leaves the factory.

AI could change the relationship again.

Software still tells a vehicle what it is capable of doing. AI increasingly determines how information is interpreted, which information matters and, within carefully established limits, what the system should do next.

That raises questions that extend well beyond computing performance.

If two versions of an AI model respond differently to the same situation, how should that change be validated? How much authority should an agent have to coordinate vehicle functions? Which decisions must remain deterministic? How does an automaker support an AI model in a 12-year-old vehicle when the models used in its newest cars require several times the computing performance?

There is also a larger possibility.

The software-defined vehicle was built around the idea that a car could continue to gain new capabilities after production. The AI-defined vehicle could make those capabilities less uniform.

Two identical vehicles might leave the same factory with the same hardware and software. Years later, differences in models, updates, available compute, regional regulations and perhaps even learned preferences could make their behavior increasingly different.

That would represent a more fundamental change than putting a better voice assistant in the dashboard.

For most of automotive history, engineers determined what a vehicle could do when they designed it. Software-defined architectures loosened that boundary by allowing the vehicle to change later.

AI could make the boundary less obvious still.

The question might no longer be only what comes after the software-defined vehicle, but how much of the vehicle will still be defined before it ever reaches the road.