Carmakers spent a decade making sure their vehicles were connected. The AI-defined vehicle asks a harder question: what is that connection for, and what happens when it drops? This post sets out what changes for connectivity and which decisions OEMs are locking in now.
In a new article for the Forbes Business Development Council, I argue that the next shift in automotive will test connectivity in ways the industry has yet to price in. Here is my argument and what it means for the teams specifying vehicle platforms today.
What the AI-defined vehicle asks of connectivity
The software-defined vehicle (SDV) gave carmakers something they never had before: a relationship with the vehicle that carried on after the sale. Over-the-air (OTA) updates became routine, and revenue began to depend on a car staying useful for years.
The AI-defined vehicle builds on that foundation. Full self-driving is one possible end point, but the term covers the AI features drivers already meet in connected cars and advanced electric vehicles: driver assistance, route optimisation, in-cabin personalisation, predictive maintenance and energy management. Each of these runs on a decision-making model, and models age. A system trained on last year’s road conditions behaves differently from one updated last week, and drivers feel that gap even if they could never name it.
Connectivity becomes a question of priority
In the SDV era, connectivity was a box to tick and a utility to keep running. The hard engineering sat in the software. With AI on board, one connection has to carry jobs with very different tolerances for delay. A safety intervention cannot wait for the network, while fleet analytics can wait for hours.
Deciding where each stream of vehicle data gets processed, on board or further up the network, now takes coordination from the vehicle all the way to the backend. Get the architecture wrong and cloud and connectivity costs can climb fast enough to cancel out the value the AI was meant to create.
Why the update loop is the product
My central point is that an AI-defined vehicle is never finished. There is a thought I keep coming back to about this era: The update loop is the product.
An SDV was, in most respects, complete the day it was delivered. The model running in an AI-defined vehicle on delivery day will be out of date 18 months later, by which point its safety functions will have met edge cases the original training data never contained. Whether the vehicle keeps pace depends on the connectivity underneath it.
Two directions, and both have to hold
The loop runs both ways. Model updates go out to the vehicle and telemetry comes back to train the next version. That asks far more of the infrastructure than a standard update channel ever did, and dependability matters more here than raw speed.
Lose the outbound path and the vehicle falls behind on its model. Lose the inbound path and the retraining cycle has nothing to learn from. Turning that returning telemetry into decisions is the job of connected vehicle analytics such as Explore3. Over a vehicle’s lifetime, the carmakers whose fleets stay current will pull steadily ahead of those whose vehicles drift.
Architecture decisions OEMs are making now
Carmakers and fleet equipment manufacturers are choosing their connectivity and compute architectures at the moment fixed assumptions carry the most risk. Those choices will decide which AI capabilities an OEM can offer and how far it can scale them safely across markets.
Where the intelligence sits
5G made it sensible to keep some intelligence close to the vehicle, either on board or at the nearby network edge, where decisions can be made quickly and reliably. Faster networks also make it practical to move other tasks off the vehicle into the cloud, where larger models are easier to train and improve. Most AI-defined vehicle programmes will need both, with a clear rule for which job goes where. That rule has to be enforced in the connectivity layer, which is the role of a platform like Cubic3 Cloud.
Data sovereignty at every border
Autonomous driving runs on data at enormous scale. McKinsey’s analysis of end-to-end driving models points to millions of hours of real-world driving data for training, and to the high bandwidth cost of moving petabytes of sensor data across networks.
Collecting that data, owning it, and feeding it back into training must satisfy regional data sovereignty and telecoms rules in every market where the vehicle is sold. In Europe, the Data Act has applied since 12 September 2025, and the European Commission has published specific guidance on vehicle data. Infrastructure chosen today has to be compliant across jurisdictions and commercially viable at wholesale network level, or the AI-defined vehicle will stall at the border.
Coverage, the problem faster networks won’t fix
Rural roads and underground car parks stay out of reach, however quick the network becomes.
Anything that cannot tolerate uncertainty has to run on the vehicle itself. That makes coverage the deciding factor in where each function lives, and a far harder problem to solve than bandwidth. Fleets face the same test, where performance is often set by the least-connected vehicle.
The questions that replace “is it connected?”
The industry learned to ask whether a vehicle was connected. The AI-defined vehicle needs sharper questions. Connected to what? Running which job? At what cost? And with what fallback when the network isn’t there?
The answers differ for every function on the vehicle. Working them out, then building infrastructure that can act on them, is the central connectivity challenge of the decade ahead.
Plan for the vehicle that keeps learning
See how Cubic3 Cloud keeps connectivity ahead of the models it carries
