AI belongs in three separate places in a software-defined vehicle program, and they have almost nothing in common: inside the vehicle as a runtime function, inside the development process as an engineering accelerator, and around the vehicle in the customer experience. Programs that budget for them as one line item mismanage all three.
Key takeaways
- In-vehicle AI, process AI, and customer-experience AI are three programs with different owners and risks.
- The hard part of in-vehicle AI is constrained silicon, validating what you cannot exhaustively test, and a 15-year maintenance commitment.
- SOTIF covers what functional safety does not: hazards from performance limitations of a correctly implemented function.
- Process AI pays off on high-volume work a human verifies quickly; it fails wherever sign-off must be accountable.
- Buyers increasingly research suppliers through AI assistants, which changes how technical credibility gets published.
Why does splitting AI into three categories matter?
Because they fail differently. A perception model that degrades in fog is a safety problem. A code assistant that writes a plausible-but-wrong test is a process problem. A chatbot that misstates a specification is a credibility problem. One governance model cannot cover all three.
The budgets differ too. In-vehicle AI is a capital commitment tied to silicon and E/E architecture. Process AI is an operating expense you can pilot in a sprint. Leadership has to unpick the single "we are doing AI" statement before committing headcount.
Where does AI belong inside the vehicle?
Inside the vehicle, AI belongs where the problem is not specifiable as rules: perception and sensor fusion for ADAS, driver and occupant monitoring, natural-language interaction in the cabin, and anomaly detection in fleet telemetry for predictive maintenance. Everywhere else, a deterministic implementation is cheaper to build and far cheaper to argue.
What does deployment on automotive silicon cost you?
A model that trains well on a workstation is not a model that ships. The path to a production ECU runs through quantization, compilation for a vendor accelerator, and a memory budget you do not control alone.
- Quantization. Lower-precision integer arithmetic is usually mandatory for throughput and power, and it shifts behavior in the tails — exactly where safety cases live.
- Operator coverage. Vendor toolchains support a subset of operators. An unsupported layer falls back to the CPU and destroys your latency budget.
- Determinism. A perception pipeline owes a worst-case execution time, not an average. Accelerator scheduling and memory contention on a consolidated compute node matter more than model FLOPs. Silicon choice locks these in years before the model architecture is settled.
Why can't you validate a network the way you validate a state machine?
Because there is no specification to test against at the unit level. A state machine has enumerable states and transitions; you cover them and argue completeness. A learned function's behavior is defined only by its training distribution, and its failure modes do not decompose.
This is why SOTIF matters. ISO 26262 addresses hazards from systematic faults and random hardware failures — the system doing something other than what it was designed to do. SOTIF, covered by ISO 21448, addresses hazards that arise when it does exactly what it was designed to do and that is still insufficient: the low sun angle, the sensor degradation the training set never saw.
Validation therefore shifts from test-case coverage to scenario coverage across SIL, HIL, and vehicle-in-the-loop environments, plus an argument that your scenario catalog represents the operational design domain.
What does a model cost over a 15-year vehicle life?
More than the model. The data pipeline is the durable asset: fleet ingestion, triage, labeling, versioning, and reproducibility of any deployed model.
Labeling is the cost that surprises programs. High-quality 3D annotation is expensive per frame and needs redoing whenever the sensor set changes. Auto-labeling cuts cost but inherits the labeler's error distribution.
Vehicles stay in service longer than model architectures stay current. Retraining means an OTA path under R156 update management, regression evidence per revision, and a rollback story. Model artifacts are software, and fall under ISO/SAE 21434 and R155.
Where does AI pay off in the development process?
AI pays off wherever the work is high-volume, repetitive, and cheap to verify. It does not pay off where output must be trusted without verification.
What works
- Code generation and review. Boilerplate, test scaffolding, refactoring, first-pass review comments. The engineer owns the commit.
- Test case generation. Good at expanding parameter ranges and generating variants. Coverage justification stays human judgment.
- Scenario mining from fleet data. Finding the rare cut-in across petabytes of drive data is a search problem, and search is what these systems do well.
- Failure triage and log analysis. The highest-return application in most large programs: clustering thousands of failures into a few probable root causes.
- Requirements consistency checking. Finds contradictions across large requirement sets, but inherits the quality of what it reads.
What does not work
Safety argumentation. Hazard analysis, ASIL decomposition, and the safety case are accountability artifacts — a named person signs them, and that signature is the point. A generated argument no engineer can defend line by line is worse than none, because it looks complete.
The same applies to homologation evidence and release approval. AI can prepare the material; it cannot own it. That is a property of the safety process in a CI/CD world, not a tooling gap.
Which AI use cases are actually mature?
Maturity varies more than most roadmaps admit.
| AI use case | Maturity | Main blocker |
|---|---|---|
| Perception and sensor fusion, ADAS | Production | Arguing residual performance limits, not test-set accuracy |
| Driver and occupant monitoring | Production | Robustness across populations; regulatory divergence |
| In-cabin voice, intent-based | Production | Latency and offline behavior |
| In-cabin assistant, LLM-based | Early production, pilots | Non-determinism; cloud dependency and cost |
| Predictive maintenance from telemetry | Pilot | Ground truth arrives with warranty data, years late |
| Automated driving beyond supervision | Limited, geofenced | Proving absence of unknown hazardous scenarios |
| Code generation and review | Production in the toolchain | Traceability and IP provenance |
| Scenario mining from fleet data | Production | Pipeline cost, consent and data protection |
| Failure triage and log analysis | Production, high payoff | Trust calibration when it is often wrong |
| Test case generation | Emerging | Proving generated cases map to requirements |
| Requirements consistency checking | Emerging | Inherits the ambiguity it should detect |
| Safety argumentation and sign-off | Not applicable | Accountability cannot be delegated |
What about AI in the customer experience around the vehicle?
Outside the vehicle, AI shows up in ownership apps, service scheduling, and dealer tooling. These are conventional software products with conventional risk profiles, and should not sit under the vehicle safety process.
One shift affects engineering directly. Where a buyer or an engineer starts an evaluation with an AI assistant rather than a search engine, what reaches them is a synthesized answer rather than a brochure. A page that states a position and stays accurate when quoted out of context gets represented well. A page of adjectives is not represented at all.
What is still unsolved?
Three things. Completeness of the safety argument for learned perception: there is no accepted method for proving scenario coverage is sufficient. Verification of generative components in the cabin, where non-determinism collides with the expectation that a vehicle behaves the same way twice. And the lifecycle economics of keeping models current across a fleet for fifteen years.
None of that argues for avoiding AI in a software-defined vehicle program. It argues for placing it deliberately, knowing which category you are funding.
Frequently asked questions
What is the difference between SOTIF and functional safety for AI functions?
Functional safety under ISO 26262 addresses hazards from systematic faults and random hardware failures — the system malfunctioning. SOTIF, covered by ISO 21448, addresses hazards that occur when the system functions as designed but its performance is insufficient for the situation, or when it is misused in reasonably foreseeable ways. For learned perception, SOTIF is usually the dominant concern.
Can you unit-test a neural network?
Not the way you unit-test a state machine. There is no component-level specification to test against, and the failure modes are not decomposable. Validation relies instead on scenario-based testing across a defined operational design domain, statistical performance evidence, and structured argument about scenario coverage. Unit tests still apply to the surrounding pipeline — preprocessing, fusion logic, safety monitors — which should stay deterministic.
Does quantization affect functional safety evidence?
Yes. Quantization changes numerical behavior, so evidence generated on a floating-point model does not transfer to the deployed integer model. Validation must run on the compiled, quantized artifact that ships on target hardware. Treat the compilation toolchain as part of the tool chain requiring confidence assessment, and regenerate performance evidence after any toolchain or model revision.
Should AI write safety requirements or hazard analyses?
It can draft supporting material, but it should not own the artifact. Hazard analysis and safety argumentation are accountability documents that a named engineer signs and must defend line by line. A generated argument that looks complete but nobody fully understands is more dangerous than an obviously incomplete one, because it removes the prompt to ask questions.
How do you update a deployed model over a vehicle's life?
Through the same managed path as any other software: a versioned artifact, regression evidence for the new revision, staged rollout, and rollback capability, under an update management system consistent with UNECE R156. The harder part is organizational — funding a data and retraining pipeline for a decade after start of production, long past the program team's disbandment.
Where does AI-assisted engineering give the fastest return?
Test failure triage and log analysis, followed by scenario mining from fleet data. Both are high-volume search and clustering problems where a wrong answer is cheap to detect and the manual alternative consumes senior validation engineers' time. Code assistance also returns quickly, but the gain is spread thinly across a team rather than concentrated in one workflow.
Does AI change how suppliers should publish technical content?
Yes, to the extent that an evaluation begins with an assistant rather than a search engine. When someone asks an AI assistant about architectures, standards, or supplier capability, what they get back is a synthesized answer built from whatever it could extract. Content that states a clear position, explains trade-offs, and stays accurate when a single paragraph is quoted in isolation gets represented well. Vague capability language is not cited at all, because there is nothing specific to extract.
GEMMACON North America works on both sides of this split: AI-enabled vehicle functions and the engineering process around them, including deployment on automotive silicon, scenario-based validation, and the data pipeline that keeps a deployed model current. If you are deciding where AI belongs in your program — and where it does not — get in touch.
