The Profitability Path of Automotive AI

Not exactly — agentic AI goes beyond prediction. Predictive AI forecasts outcomes (e.g., anticipating maintenance needs). Agentic AI autonomously executes multi-step tasks on behalf of the user: booking appointments, managing charging schedules, completing purchases.

As Stefano Marzani (AWS) framed it in his slides, agents are ""the abstraction layer IoT promised but never delivered"" — they don't just predict, they act.

For personalization specifically, agentic AI can learn user patterns AND act on them autonomously (e.g., pre-ordering coffee on a familiar route).

Trust is indeed a critical barrier, and regulation could help — but not in the way most people expect.

Why NCAP/NHTSA haven't regulated in-car AI yet: Their mandates focus on safety-critical systems (ADAS, crash avoidance, occupant protection). In-car AI features like voice assistants and recommendation engines sit in a regulatory gray zone — not safety-critical enough for NCAP scoring, but they do influence user trust across the entire vehicle ecosystem.

The privacy-trust-monetization link (from our Panel Topic 3): SBD's consumer research shows that when users perceive their data is being exploited, willingness-to-pay drops across the ENTIRE AI feature portfolio — not just the offending feature. One ""Grudge"" experience on privacy can poison every ""Hero"" feature's P&L.

Regulatory roadmap outlook:
• EU AI Act (2025–2026 enforcement) is the closest framework, classifying AI by risk tier
• China has a separate, rapidly evolving regulatory approach
• The US remains fragmented with no unified in-car AI regulation on the horizon

SBD's view: OEMs should not wait for regulation to build trust. The ones treating ""your data never leaves your car"" as a premium value proposition — not a compliance footnote — are already pulling ahead. Edge-first architectures (as Dani Cherkassky / Kardome presented) become a trust asset, not just a cost play. As we argued in the panel: ""Privacy isn't a constraint on monetization. It's a monetization variable."

Absolutely correct — and this is precisely where SBD's Triangulation Model applies.

In our Hero/Zombie framework, predictive maintenance is classified as a ""Utility"": high user value, but low direct willingness-to-pay. Users value it, but won't pay a separate subscription for it. The strategic recommendation: keep it free/standard, let it carry your brand.

However, the indirect value is captured in our classification — specifically in the Revenue leg of the Triangulation Model. As stated in Andy's Slide 3 script: ""Not just subscription dollars. Indirect value, too — what does this feature do to residual value, to trim up-sell, to churn?""

For predictive maintenance specifically, the indirect revenue streams include:
1. Workshop traffic — driving customers to OEM-authorized service centers (exactly as you suggest)
2. Service revenue uplift — proactive repairs vs. reactive breakdowns
3. Improved residual value — a well-maintained vehicle retains higher resale value
4. Reduced warranty costs — early detection prevents expensive failures
5. Brand loyalty & retention — users who trust the car's intelligence are more likely to repurchase

The strategic implication: Utilities like predictive maintenance should be kept free/standard, but their indirect P&L contribution must be quantified to justify the ongoing inference cost. That quantification is exactly what ""Feature Lifecycle Margin"" is designed to capture.

1. AI features on the Monroney Label / Window Sticker:
We don't expect to see AI-specific line items on the Monroney Label in the near term — and the reason is more fundamental than labeling conventions. Today's in-car AI features are still maturing rapidly across multiple dimensions: privacy safeguards, reliability, user interaction design, and edge-cloud orchestration. They are, in many respects, still in their early innings.

Before AI can appear as a standard equipment callout, two things need to happen. First, individual AI capabilities need to stabilize to the point where OEMs and consumers alike recognize them as proven, expected functionality — not experimental add-ons. Second, AI-driven features require deep software-hardware integration (dedicated compute, sensor fusion, on-device models) to become a true platform capability rather than a cloud-dependent service layer.

That maturation process — from experimental feature to industry-standard configuration — will take considerable time. Realistically, we see this as a post-2030 development at the earliest. In the interim, most AI capabilities will continue to live under Connected Services subscriptions or bundled software packages.

2. BMW's 22 AI features — context and strategic reading:
This data comes from SBD's Automotive AI research, and it tells a compelling story about BMW's positioning:

R&D investment and readiness: BMW is one of the earliest and most committed OEMs in automotive AI. They entered this space ahead of most competitors, which means they have a significant head start in technology validation, application testing, and — critically — talent and organizational capability.

Breadth of experimentation: The 22 AI features we tracked reflect a deliberate strategy of broad exploration. BMW is systematically testing where AI adds value across a wide range of in-cabin scenarios — from voice interaction to personalization to predictive functions. This breadth is itself a signal of strategic commitment.

Strategic conviction: According to BMW's own public communications, they have identified over 600 distinct AI use cases internally. It's important to note that a significant portion of these relate to internal operations — R&D processes, manufacturing optimization, supply chain management — rather than customer-facing in-vehicle features. But the scale of investment signals that BMW views AI as a core capability, not an incremental feature set.

In short, BMW's high feature count reflects early-mover advantage and deliberate experimentation rather than a race to pad the spec sheet. Whether those 22 features are all ""Heroes"" in our framework — or whether some are ""Zombies"" awaiting rationalization — is exactly the kind of question our Feature Lifecycle Margin analysis is designed to answer.

For a more detailed competitive comparison of BMW's AI portfolio against other OEMs — including subscription structures, feature engagement, and cost positioning — we'd be happy to share further from our research. Please don't hesitate to reach out.

This is an exceptionally well-articulated concern, and it aligns directly with our core thesis. The attendee is describing — in precise architectural language — the exact P&L problem we presented: complexity scaling faster than robustness, with cost overhead (compute, data pipelines, validation, OTA infra) that compounds with every new AI feature added.

Our response addresses each dimension:

1. The cost visibility gap (from Andy's presentation):
The ""foresight on probable cost"" this attendee calls for is exactly what the industry lacks. Most OEMs today see only an aggregate cloud bill — they have no mechanism to attribute spend back to individual AI features or measure cost-per-user at the feature level. The leading OEMs are just now building their first internal dashboards to map cloud cost against feature-level usage. Until that measurement infrastructure exists, the cost risks described here — margin compression, profit volatility — remain invisible until they're catastrophic. As we stated: ""You cannot manage what you cannot see.""

2. The architectural answer (from Dani Cherkassky / Kardome):
Dani's System 1 / System 2 architecture directly addresses the ""interface density and dependency chain"" concern. By running fast, always-on tasks at the edge (System 1) and reserving cloud for complex reasoning (System 2), you reduce both the dependency chains and the attack surface. The Jeep Cherokee hack reference is apt — cybersecurity exposure is a particularly severe form of what we call ""hidden liabilities"" in the Zombie framework.

3. The commercial structure answer (from Andy's Panel Topic 2):
Outcome-based pricing — where suppliers share the downside risk tied to actual usage and engagement — is how you prevent runaway cost from invisible Zombie features. When a supplier only gets paid if the feature is actually used and valued, both parties have an incentive to kill what doesn't work.

The attendee's instinct is correct. The biggest risk isn't the technology — it's deploying it without the measurement infrastructure to know what it's actually costing you per feature, per user, per vehicle. That's exactly the gap our Feature Lifecycle Margin framework is designed to close.

We currently have pilots underway with two German OEMs (across the U.S. and EU markets) as well as a leading TV manufacturer in the U.S. A broader commercial rollout across vehicle fleets is planned for later this year, so we’re not able to share partner names just yet. 

This is an emerging and commercially promising intersection. Generative AI can impact car insurance across several dimensions:

On the underwriting side, AI-driven vehicle telemetry and usage data can enable far more granular risk profiling — moving from static demographic models to dynamic, behaviour-based pricing. OEMs with rich in-vehicle data (driving patterns, ADAS engagement, maintenance compliance) are increasingly well-positioned to partner with insurers on usage-based insurance (UBI) products.

On the claims side, generative AI is being deployed for automated damage assessment from photos, natural-language claims processing, and fraud detection. Several insurers are piloting LLM-based systems that can handle first notice of loss (FNOL) conversations end-to-end.

From SBD's perspective, the most interesting monetisation angle is the data exchange between OEMs and insurers. A vehicle that can certify its own maintenance history and driving behaviour via AI creates a trust layer that benefits both parties. This is an example of what we call "indirect value" in our Triangulation Model — the AI feature itself may not generate subscription revenue, but it creates measurable value for adjacent business models.

The challenge remains data privacy and regulatory compliance, which varies significantly by region — a point we explored in depth during our panel discussion on privacy as a monetisation variable.

This was one of the central themes of our webinar. The core argument: the industry needs to move from measuring AI success at the vehicle level (one aggregate margin) to measuring it at the feature level (individual P&L per AI capability).

We recommend a three-dimensional measurement framework — what we call Feature Lifecycle Margin — built on three pillars:

1. Cost: Not just the chip BOM, but true operational cost — inference cost per query, retraining cycles, data pipeline maintenance, and cloud spend attributed to the specific feature. Most OEMs today only see an aggregate cloud bill; the leading organisations are building dashboards to attribute cost at the feature level.

2. Revenue: Both direct (subscription, transaction fees) and indirect (impact on residual value, trim up-sell, churn reduction, workshop traffic). Many AI features that appear unprofitable on a direct-revenue basis are actually net-positive when indirect value is properly quantified.

3. Consumer engagement: Daily active usage, session depth, and — critically — willingness-to-pay by region and segment. Press-release adoption rates are not the same as genuine engagement. Our research shows significant gaps between "feature awareness" and "daily active use."

Success, then, is not "did we launch an AI feature?" but "does this feature sit in the Profitability Zone where cost, revenue, and engagement all intersect positively?" Features outside that zone need to be reclassified as brand plays (Utilities), rationalised (Zombies), or fixed (Grudges).

What can in-vehicle AI do that the phone cannot:
The honest answer is that the bar is high. Consumers already have powerful AI on their phones, and any in-vehicle AI that merely replicates phone functionality will lose. The defensible advantages of in-vehicle AI lie in three areas: (a) sensor integration — the vehicle has access to data the phone does not (vehicle speed, drivetrain state, occupancy, exterior environment, ADAS inputs), enabling truly contextual AI; (b) safety-critical interactions — voice-first interfaces while driving, where the phone's touch-based UX is inadequate; and (c) vehicle control — AI that can act on the vehicle itself (adjusting HVAC, routing, charging, pre-conditioning) rather than just providing information.

As Dani Cherkassky (Kardome) presented, the key architectural insight is that effective in-vehicle AI needs an edge-first "System 1" layer that is fast, private, and always-on — qualities that a cloud-dependent phone relay cannot match in latency-sensitive driving scenarios.

What will increase willingness to pay:
Our consumer research consistently shows the highest willingness-to-pay for AI features that remove a genuine chore or solve a real friction point. Specific high-confidence candidates include: AI navigation that demonstrably outperforms phone-based options for complex trips (multi-stop, EV charging optimisation), proactive vehicle health management that prevents breakdowns, and agentic commerce that completes transactions (parking, tolls, fuel/charging) without driver intervention. The common thread: these are "Hero" features in our framework — high user value AND viable unit economics.

Investment levels vary significantly by OEM scale and strategic posture, but the trajectory is clear: AI is becoming one of the largest single line items in automotive R&D budgets.

On the technology side, the cloud and software-defined vehicle market supporting AI is projected to grow from approximately $71 billion to $161 billion by 2035, with semiconductors and E/E architecture adding another $103 billion — figures referenced in Stefano Marzani's (AWS) presentation. OEM-level AI investment is a meaningful share of this total.

What we observe at SBD across our client base is that the investment is shifting in composition:
- Early phase (2023–2025): Heavy spend on foundational infrastructure — cloud partnerships, compute hardware, data pipelines, and initial feature development. This is largely CapEx-style investment.
- Current phase (2025–2027): Growing OpEx burden as deployed AI features generate ongoing inference costs. This is the "trap" we highlighted in the webinar — the more successful your features, the higher your recurring cost.
- Next phase (2027–2030): Investment increasingly focused on AI operations — cost optimisation, feature-level P&L management, and organisational capability (the "who owns the feature P&L" question we raised in the panel).

The education and organisational investment is often underestimated. BMW, for example, has publicly stated it has identified over 600 AI use cases internally — spanning not just in-vehicle features but manufacturing, supply chain, R&D processes, and sales. Building the talent base and cross-functional governance to manage this portfolio is itself a multi-year, multi-hundred-million-dollar commitment for a major OEM.

This concern is well-founded and directly connected to the profitability challenge we discussed. As vehicles become software-defined and AI-dependent, the attack surface expands in several dimensions: more cloud endpoints, more OTA update channels, more third-party API integrations, and more persistent data connections.

From a monetisation perspective, cybersecurity has a dual impact:

First, it is a cost multiplier. Every AI feature that connects to the cloud adds security obligations — encryption, authentication, intrusion detection, incident response. These costs must be factored into the feature-level P&L. In our Triangulation Model, cybersecurity overhead is part of the "true cost" that most OEMs underestimate when they only look at inference costs.

Second, a cybersecurity incident is the most extreme form of what we call a "Grudge" — it doesn't just fail to generate revenue, it actively destroys trust and willingness-to-pay across every feature on the vehicle. The 2015 Jeep Cherokee remote exploit is a well-documented case where a single vulnerability reshaped an entire brand's security investment trajectory.

The architectural response, as Dani Cherkassky (Kardome) presented, is to move as much processing as possible to the edge — reducing the data that traverses the cloud, minimising dependency chains, and limiting the attack surface. "Your data never leaves your car" is both a privacy proposition and a security proposition.

OEMs that treat cybersecurity as a standard cost of doing business — rather than as a feature-level investment that protects the entire portfolio's monetisation potential — are the ones best positioned to scale AI safely.

The Alexa integration question highlights a broader strategic tension: when an OEM integrates a third-party platform (Alexa, Google Assistant, ChatGPT), who captures the monetisation value?

In the current model, the platform provider owns the user relationship and the commerce layer — the OEM provides the hardware endpoint. This creates what Stefano Marzani (AWS) described as the "agentic control plane" question: whoever owns the layer that talks to the driver owns the revenue potential.

For OEMs to monetise third-party integrations, there are several viable approaches:
1. Revenue sharing on commerce transactions — when Alexa completes a purchase through the vehicle, the OEM takes a share. This requires contractual leverage and integration-level visibility into transaction flows.
2. Data value exchange — the vehicle provides contextual data (location, occupancy, driving state) that makes the assistant smarter; this data has commercial value that should be priced into the partnership.
3. Layering proprietary features on top — using the third-party platform for commodity tasks (music, weather) while reserving vehicle-specific AI (navigation, vehicle control, predictive maintenance) for the OEM's own monetisable stack.

As Stas Matviyenko (SoundHound) argued, the shift from voice assistants to commerce agents is what unlocks real revenue. A voice assistant that answers questions is a cost centre. An agent that completes transactions — ordering food, paying for parking, booking services — generates per-transaction revenue.

Timeline: We expect the first meaningful revenue from in-vehicle AI commerce to materialise in 2027–2028 for early movers, with broader adoption by 2030. The constraint is less technological than commercial — the business model and partnership structures need to mature alongside the technology.

Environmental data — encompassing weather, road surface conditions, traffic patterns, air quality, and terrain — is a high-value input layer for several AI applications with demonstrated operational impact:

1. Predictive route optimisation: AI that integrates real-time and forecast weather data with traffic patterns to optimise routing. For EV fleets, this extends to range prediction adjusted for temperature, elevation, and headwind — directly impacting operational efficiency and reducing range anxiety.

2. Predictive maintenance: Environmental exposure data (salt, humidity, temperature extremes, UV) combined with vehicle sensor data enables more accurate degradation modelling for components like batteries, tyres, and brake systems. This shifts maintenance from calendar-based to condition-based, reducing downtime and warranty costs.

3. ADAS calibration and performance: Environmental conditions significantly affect sensor performance (LiDAR in rain, cameras in low sun). AI systems that dynamically adjust ADAS behaviour based on environmental context improve both safety outcomes and user trust.

4. Fleet operations: For commercial and logistics fleets, environmental AI that optimises departure timing, load planning, and route selection based on weather forecasts has shown measurable fuel savings and delivery reliability improvements.

From SBD's classification perspective, these applications tend to fall into the "Utility" or "Hero" quadrants — they deliver real operational value. The monetisation question is whether this value is captured directly (through subscription or licensing) or indirectly (through reduced operational costs, improved residual value, and competitive differentiation). Our Triangulation Model is designed to quantify both dimensions.

AI is reshaping traditional powertrain and chassis control in ways that go well beyond the cabin-focused AI features we discussed in the webinar. Several areas are seeing material impact:

Powertrain optimisation: AI-based energy management systems — particularly for hybrid and BEV architectures — are replacing rule-based control strategies with learned models that adapt to driver behaviour, route conditions, and battery state in real time. This can yield 5–15% efficiency improvements over calibrated lookup tables.

Chassis and dynamics control: Predictive suspension systems (e.g., active damping tuned by AI using road preview data from cameras or connected infrastructure) and AI-enhanced stability control that anticipates rather than reacts to loss-of-grip scenarios represent a shift from reactive to anticipatory vehicle dynamics.

Software development process: This is where the impact may be largest. AI is accelerating the traditional V-model development cycle through automated test case generation, simulation-based validation, and AI-assisted calibration. What previously required months of physical testing and hand-tuned parameters can increasingly be handled through AI-driven digital twins and reinforcement learning.

The P&L implication — connecting back to the webinar's theme — is that these engineering-side AI applications often don't face the same monetisation challenge as customer-facing features. They reduce development cost, shorten time-to-market, and improve product quality without requiring consumer willingness-to-pay. In BMW's reported 600+ AI use cases, a significant portion falls into this category — internal operational AI that improves the business without appearing on a feature list.

In brief — two converging trends define the current landscape:

Trend: The automotive industry is moving from deploying AI as isolated features to building AI as a platform capability. The number of AI features per vehicle is growing rapidly (BMW leads with 22 tracked AI features, with others accelerating), and the scope is expanding from voice assistants into agentic AI — systems that autonomously execute tasks on behalf of the driver. Simultaneously, the architecture is splitting between edge processing (fast, private, always-on) and cloud reasoning (complex, costly, powerful).

Cost: This is the central challenge we addressed in the webinar. Generative AI broke the traditional software cost model almost overnight. Legacy software was CapEx — built once before SOP, cost locked in. AI features are perpetual OpEx — every user interaction generates inference costs, and those costs scale with success. Current inference costs for agentic AI (multi-step reasoning, tool calling, persistent memory) are 5–10x higher than simple request-response AI, and this multiplier will grow as agent capabilities expand.

The cloud FinOps market supporting cost management has grown to $14.4 billion in 2025, projected to reach $22.4 billion by 2030 — a signal of how seriously industries are taking cost attribution and optimisation.

SBD's recommendation: OEMs must build feature-level cost visibility now. The aggregate cloud bill is not sufficient. Without knowing the cost-per-user of each AI feature, it is impossible to distinguish Heroes from Zombies — and impossible to make rational investment decisions.

Cost management for AI in two-wheelers presents a distinct challenge because the per-vehicle margin and price point are fundamentally lower than passenger cars, yet consumers increasingly expect connected, intelligent experiences.

Several principles from our webinar framework apply, with adaptation:

1. Edge-first is not optional — it is essential. For two-wheelers, cloud-dependent AI features are economically unviable at scale due to the thin margin structure. The System 1/System 2 architecture that Dani Cherkassky (Kardome) presented — where fast, always-on tasks run on-device and only complex reasoning goes to the cloud — is particularly critical for 2W. The goal: minimise per-ride inference cost to near zero for routine interactions.

2. Focus ruthlessly on Utilities and Heroes. The 2W feature portfolio must be leaner than a car's. Prioritise AI capabilities with clear, measurable value: predictive maintenance (critical for markets like India where service networks are dispersed), intelligent navigation optimised for 2W (lane filtering, fuel station routing), and safety alerts. These are either Utilities (keep free, build brand) or Heroes (users will pay).

3. Leverage the fleet scale advantage. Two-wheeler OEMs often have much larger unit volumes than car OEMs. This means the per-unit cost of developing an AI platform can be amortised across millions of vehicles — but only if the platform architecture is shared across models.

4. Explore indirect monetisation. Rather than asking 2W riders to pay subscriptions (willingness-to-pay is typically lower in this segment), consider data-driven insurance partnerships, fleet management services for commercial 2W operators, and maintenance ecosystem revenue — all areas where AI-generated data creates value without direct consumer payment.

Consumer willingness-to-pay (WTP) for on-demand AI features is one of SBD's core research areas, and the picture is nuanced:

Overall assessment: WTP varies dramatically by feature type, not just by price. Features that remove a genuine chore or friction (agentic commerce, intelligent charging management, proactive maintenance) command significantly higher WTP than features that provide information or entertainment — which consumers increasingly expect to be free or bundled.

By vehicle segment:
- Premium/luxury: Higher absolute WTP, but also higher expectations. Premium buyers expect AI features to "just work" — they are less tolerant of imperfect experiences (our "Grudge" risk is highest here).
- Mass market: Lower absolute WTP but larger volume. The viable model here is typically bundled subscriptions or indirect monetisation rather than per-feature pricing.
- Commercial/fleet: WTP is driven by ROI calculation rather than emotion — fleet operators will pay for AI that demonstrably reduces cost or improves uptime.

By region:
- China: Highest willingness to adopt and pay for in-vehicle AI, driven by tech-forward consumer expectations and competitive pressure among domestic OEMs.
- Europe: More cautious, with privacy concerns significantly depressing WTP for data-intensive features. As we discussed in the panel: poor privacy perception can reduce WTP across the entire feature portfolio, not just the offending feature.
- North America: Moderate WTP, heavily influenced by comparison with phone-based alternatives. If the in-vehicle AI doesn't clearly beat the phone experience, WTP collapses.
- Japan/Korea: High quality expectations and willingness to pay for reliability, but conservative adoption curves.

The critical insight from our research: WTP is not static. It is shaped by the quality of every AI interaction the user has had previously. One Grudge experience — a voice assistant that repeatedly fails — can suppress WTP for every other feature on the vehicle. Portfolio-level quality management is therefore a monetisation strategy, not just a UX strategy.

This is perhaps the most important question in the set, because it challenges the assumption that AI monetisation will succeed where previous waves failed. The scepticism is well-earned.

Why services and apps failed:
The first wave (telematics services, ~2005–2015) failed because the value proposition was weak relative to the friction of subscription management, and the phone rapidly overtook the car as the connected device of choice. The second wave (app ecosystems, ~2015–2022) failed because OEM app stores could never match the breadth, quality, or update speed of iOS/Android — and consumers saw no reason to use an inferior app platform just because it was in the car.

What is structurally different about AI:
Three things have changed that make the current wave fundamentally different from its predecessors:

1. AI can act, not just inform. Previous waves offered information and content — things the phone already did better. Agentic AI can execute tasks that require vehicle integration: completing transactions while driving, managing charging schedules based on energy prices and route, adjusting the vehicle's behaviour to the driver's learned preferences. As Stas Matviyenko (SoundHound) argued: "Voice assistants don't make money. Commerce agents do." The monetisation is in the transaction, not the subscription.

2. AI creates data that has value beyond the vehicle. Driving behaviour data, environmental sensing, maintenance prediction — these data streams are valuable to insurers, fleet operators, city planners, and energy providers. The monetisation model shifts from "consumer pays for a feature" to "data creates value in adjacent ecosystems." This was not possible with services or apps.

3. The cost structure demands discipline that previous waves lacked. Paradoxically, the fact that AI is expensive (perpetual OpEx, usage-based cloud costs) may be what forces the industry to finally build the measurement and accountability infrastructure that was missing in previous waves. You cannot afford to run Zombie features when every interaction costs money. This economic pressure is a forcing function for the kind of rigorous feature P&L management we advocated in the webinar.

That said, SBD's honest assessment is that success is not guaranteed. The OEMs who will succeed are the ones who learn from the failures of the service and app eras: don't try to replicate the phone, don't assume consumers will pay subscriptions for convenience, and build measurement into the product from day one. The framework we presented — Feature Lifecycle Margin, the Hero/Zombie classification, the Triangulation Model — exists precisely because we share your concern that without disciplined execution, this wave could fail too.