A technology partner can help an OEM move faster today. The harder question is what the architecture will cost to unwind later.
When an HMI or platform leader evaluates a technology partner, the questions usually center on launch: capabilities, integration time, cost, and roadmap.
One question tends to arise much later: what would have to change if the OEM replaced that partner?
It matters because the cockpit is now a series of connected layers. A change in one layer can pull several others with it.
General Motors’ next vehicle architecture gives a useful reference point. GM says its centralized platform separates vehicle-specific hardware from core software so components such as displays, cameras and actuators can change without forcing the core software to be rewritten. The value goes beyond development speed. That separation preserves options later.
For the HMI or platform owner, that is the decision worth making early: how much future switching cost is being designed into today’s partner choice?
Replacing a component is one sourcing exercise. Replacing a partner whose software shapes the architecture can trigger changes across tools, interfaces, validation and release processes.
Stage four is not hypothetical. It has already happened.
Ford’s move from Microsoft Auto to QNX for Sync 3 shows what that switch can look like in practice. The replacement system took about 18 months to develop, and Ford said nearly everything was different.
The Hidden Cost is in the Connections
Most companies don’t measure exit costs because they get buried in the connections between systems.
A provider is easy to replace when it provides one feature. It becomes difficult when the provider also holds the user’s identity, route history, charging recommendations, and the interfaces the assistant uses.
The same issue is with AI. Replacing one AI model with another is straightforward, but moving the permission, context, telemetry, and fallback logic built around it is not.
A useful audit has five control points:
- interaction logic,
- vehicle permissions,
- update authority,
- customer and vehicle data,
- and failure behavior when an external service is unavailable.
This is an analytical framework, not a claim that every OEM should own all five.
Now, the question is: what else has to move when this partner changes?
An OEM can source most of the stack and still preserve room to switch suppliers if those boundaries are clear. A largely in-house stack can also become dependent on one external platform if core interfaces and data flows are built around it.
Architecture exit cost starts with coupling, not with the percentage of software written internally.
And the cost does not stay fixed. After production starts, validation libraries, telemetry schemas, customer histories, support processes, and release tooling accumulate around the deployed stack. The cheapest time to design the exit is before those operating assets harden around the partner.
A Partner Becomes Hard to Replace When it Owns More than One Layer
Volkswagen’s joint venture with Rivian shows what a deep software partnership can look like. The venture is developing zonal electrical architecture and software for future vehicles, and Volkswagen said more than 1,500 people were involved by late 2025.
There are good reasons to make that kind of commitment. A deep partner can eliminate duplicate engineering and reduce the number of interfaces different teams must integrate.
The trade-off is that the supplier relationship becomes more closely tied to the vehicle architecture itself. Replacing a component is one sourcing exercise. Replacing a partner whose software shapes the architecture can trigger changes across tools, interfaces, validation and release processes.
Ford’s move from Microsoft Auto to QNX for Sync 3 shows what that switch can look like in practice. The replacement system took about 18 months to develop, and Ford said nearly everything was different. Because Sync 3 also ran on different hardware, owners of earlier MyFord Touch vehicles could not simply upgrade to it.
The example is older, but the lesson is current: changing the software platform can become a vehicle-program change rather than a supplier swap.
Supplier platforms are also trying to preserve portability. QNX Cabin, for example, is designed so cockpit software can be developed in the cloud and moved across compatible hardware.
That kind of technical portability matters, but it is not the same as operational portability. Code may move while customer identity, fleet data, regression assets, security permissions, and release tooling remain tied to the old stack.
Before awarding a major HMI layer, the HMI or platform owner should therefore test both: can the code move, and can the operating system around the code move with it?
If several dependencies have to migrate together, the supplier decision belongs in the architecture review, not only in sourcing.
AI Assistants Could Become the Next Lock-in Point
AI brings the issue into sharper focus because the assistant is starting to connect services that used to sit apart.
GM is bringing Google Gemini to roughly 4 million eligible US vehicles while also developing a more deeply integrated assistant that uses proprietary vehicle and OnStar intelligence.
A conversational model is only one layer. The more difficult assets to move are the interfaces and permissions around it.
Take a charging request. A useful answer may require route data, state of charge, predicted consumption, charger availability, payment information, and the driver’s previous choices. If those connections are built directly around one AI provider, changing the model later becomes a vehicle-integration program.
The safer boundary is fairly clear. The AI model can interpret intent. An OEM-controlled layer should decide what vehicle data the model can see, which actions it can request, when the driver must confirm an action, and how the system behaves when confidence is low.
The learning data deserves the same treatment. BMW says it developed Panoramic iDrive using operating system data from more than 22 million connected vehicles. Fleet behavior is already feeding HMI development at scale. If a partner holds the evidence needed to improve the interface, technical portability will not be enough.
For the HMI owner, the asset to protect is the bundle of permissions, context, and learning data around the assistant.
The Counterargument: Deep Integration is Cheaper for a Reason
There is a strong case for deep integration. A tightly integrated stack can be cheaper to build, require fewer interfaces to validate, and put one partner in charge of more of the failure chain. Breaking every layer into replaceable modules would add its own cost.
For some layers, accepting lock-in may be the economically sensible choice. The goal is not maximum modularity. The goal is to decide, in advance, where lock-in is acceptable.
Safety-related interaction is one boundary worth protecting.
Euro NCAP’s 2026 framework now assesses the usability of essential controls and more closely links driver monitoring to assistance behavior. An OEM may source the sensor, operating system, or AI service, but it still needs authority over the rules that decide what the driver sees and what the vehicle can do.
The release process is another. If a partner owns the telemetry, regression environment, and fallback logic needed to improve the cockpit after launch, replacing that partner affects how the OEM learns from the fleet and how safely it can ship the next update.
Deep integration is often the right choice. It should be a conscious one, with the future switching cost visible before the architecture hardens around it.
What the HMI Owner Should Do Before the Next Partner Decision
Map the exit path before awarding the architecture. For each major partner, write down what must change if that supplier is replaced: APIs, customer identity, vehicle permissions, telemetry, validation assets, and fallback logic.
Volkswagen’s partnership with Rivian shows what an architecture-level commitment can look like. If a supplier touches several architectural layers, map the exit path before treating the choice as a normal sourcing decision.
Separate conversation from vehicle authority. An external AI model can interpret intent, while vehicle permissions and execution sit behind an OEM-controlled interface.
GM’s two-track approach to Gemini and deeper vehicle intelligence is a useful prompt for this design question. The aim is to preserve the option to change models without reopening every vehicle-control interface.
Keep the learning loop portable. Retain access to the telemetry, failure data, and behavioral evidence needed to improve the cockpit.
BMW’s use of data from more than 22 million connected vehicles shows that this evidence is already part of HMI development. If a partner controls the learning data, moving the software alone will not restore control.
Price the switch, not just the integration.
The integration quote tells you the cost of entering the relationship. Add the estimated cost of leaving it: reintegration, revalidation, data migration, customer retraining, and temporary loss of functionality. Ford’s Sync 3 migration reminds us that a platform change can require new hardware and a full redevelopment cycle, not just a new license.
The build-versus-partner decision is only half the job. The other half is knowing whether the OEM can change its mind later. That belongs in the architecture, before it becomes a contract problem.
Evaluate Automotive HMI Partners Before Switching Costs Become Architecture Costs
Choosing an automotive HMI technology partner requires more than comparing current capabilities, integration timelines, and pricing. OEM teams also need to understand where a supplier could become difficult to replace as software, data flows, AI services, validation systems, and vehicle interfaces become connected.
Slate helps R&D and innovation teams investigate these dependencies before major technology decisions are made. Teams can use the platform to assess technology providers, compare competing approaches, track supplier capabilities, study emerging HMI and AI technologies, and identify alternative solutions across the automotive ecosystem.
The cost of a technology partnership is not limited to integration. Slate helps teams examine the wider technology ecosystem so they can assess both the value of entering a partnership and the options available if the architecture needs to change later.
Explore automotive HMI technologies, suppliers, and alternatives with Slate.
