Intelligent vehicle systems rarely fail because the intelligence was wrong. They fail because something that worked on a test bench in Munich behaves differently on a motorway in Poland, on a network the engineering team never validated against, in a vehicle whose owner switched the feature off in week one.
The distance between a working prototype and a production system running across millions of vehicles is where most programmes lose time and budget. Four things account for most of that distance: where the model runs, how much data you move, what the driver actually notices, and what happens when the system meets scale.
Intelligent vehicle systems live or die at the edge
Every OEM building one of these systems has to answer a question early, and answer it deliberately: how much of the work happens inside the car, and how much happens in the cloud.
Where the model actually runs
Cloud inference is quick to prototype and hard to depend on. Latency moves with coverage. A driver-monitoring feature that needs a round trip to a data centre stops being useful the moment the vehicle enters a tunnel. Anything with a safety or real-time dependency belongs on the vehicle.
The cloud still earns its place for training and for work that compares one vehicle against millions of others. What matters is treating that split as a design decision rather than inheriting it from whichever team built the first demo. On-vehicle inference brings its own constraints: silicon cost per unit, thermal headroom, model size, and a five-year production run with no hardware refresh.
The cost of moving data
The second-order effect of that decision is volume, and the trajectory is only going one way. Berg Insight’s latest connected car forecast puts average data consumption per car rising from an estimated 6.5GB to 10.1GB by 2030, with data-heavy infotainment and app ecosystems adding to the load alongside over-the-air updates.
Cubic3 carries roughly one billion data transmissions a day across around 23 million vehicles. At that scale, an extra kilobyte per vehicle per hour becomes a budget line of its own.
Most programmes end up filtering at the edge and sending summaries rather than raw streams. That works, provided the filtering logic is itself updatable. Teams that hard-code what gets sent home usually discover 12 months later that the one signal they need for a new feature has been discarded at source since day one. Building the pipeline so the questions can change later is what turns telemetry into usable adoption data in Explore3.
Design decisions the driver notices
Most of the engineering here is invisible. The surface a driver experiences is far smaller: how fast something responds, whether it asks permission, how it explains itself, and whether it does anything worthwhile in the first 30 seconds of ownership.
Consumer research keeps landing in the same place. Deloitte’s 2026 study of more than 28,500 drivers across 27 markets found that people value connected features improving safety and security above all others, that concerns about data sharing remain high, and that many are still open to AI-driven personalisation and to over-the-air enhancements extending a vehicle’s usefulness over time. The appetite is real. So is the suspicion, and it sits in the same person.
That has a practical consequence. Features requiring setup get used less than features already running when the car is handed over. Features asking for consent without explaining the benefit get declined, and a declined consent is difficult to win back later. A system that quietly learns a driver’s routine and offers something useful on day three will beat a more capable system buried behind a settings menu.
This is also where AI ambition and product reality tend to part company. Personalisation only works if the vehicle knows who is driving, and that means an identity and consent model designed before the feature rather than bolted on during integration testing.
Why intelligent vehicle systems break at scale
A system that works across one model line in one market is a different engineering problem from one that works across a full range in dozens of markets. Network coverage varies. Roaming agreements expire. Regulatory requirements diverge. Model years fragment the software estate until a single feature has six live versions in the field.
Regulation is now part of the build
UN R156 requires manufacturers to operate a certified software update management system as a condition of type approval, and it came into force as an annex to the 1958 Agreement on 22 January 2021. Any OTA pipeline feeding an intelligent vehicle system now has to produce evidence, not just packages. You can read the full regulation on the UNECE site.
In practice a production update pipeline has to prove:
- which software version is on which vehicle, at any point in its service life
- that the update reached the correct target and nothing else
- that integrity and rollback were verified before and after delivery
- that the change was assessed against existing type approvals
None of that is exotic engineering. All of it is expensive to retrofit onto a platform designed without it. The teams shipping fastest built their connectivity, identity, update and consent layers once, then reused them across every programme instead of rebuilding per model line.
Common questions about intelligent vehicle systems
What are intelligent vehicle systems?
Intelligent vehicle systems are the combination of in-vehicle software, sensors, connectivity and cloud services that let a vehicle interpret what is happening around it and act on that interpretation. The term covers driver monitoring, predictive maintenance, adaptive in-cabin experiences and anything else where the vehicle makes a judgement rather than following a fixed rule.
Should AI run in the vehicle or in the cloud?
Anything with a real-time or safety dependency should run on the vehicle. Cloud inference introduces latency that moves with network coverage, which rules it out for features a driver depends on second by second. Training and any workload that compares one vehicle against millions of others belongs in the cloud. Most production systems split the two rather than choosing one.
How much data does a connected vehicle actually send?
Less than the sensor hardware is capable of producing, because most of it is filtered on the vehicle before it leaves. Berg Insight expects average data consumption per connected car to rise from an estimated 6.5GB to 10.1GB by 2030, with infotainment and app ecosystems adding load alongside over-the-air updates. The volume is a product of design choices rather than of raw sensor capability.
Does UN R156 apply to AI features in a vehicle?
Yes, where an AI feature is delivered or changed by a software update to a type-approved vehicle. Manufacturers have to operate a certified software update management system and demonstrate which version reached which vehicle and whether the change affects an existing type approval. Model updates are software updates as far as the regulation is concerned.
Why do intelligent vehicle systems fail after launch?
Usually because the connectivity, identity, update and consent layers were built for a single programme and then rebuilt for the next one. Coverage varies by market, roaming agreements change, and model years fragment the software estate until one feature has several live versions in the field. The problem is architectural, and it surfaces long after the launch that appeared to go well.
Build once, ship everywhere
Cubic3 Cloud gives OEMs a single connectivity and software management layer that scales across markets without a per-programme rebuild. See what changes when the plumbing stops being the hard part.
