Key takeaways

• AI in the automotive industry now sits in three distinct places: inside the product, inside the development pipeline, and inside the decisions engineers make. Each carries a different risk profile.
• Established, narrow-scope AI, such as driver monitoring, has been managed safely for years. The harder problem is broad, unbounded AI whose behavior cannot be fully modeled in advance.
• AI code assistants differ from older code generators in a way that matters for safety: they are probabilistic and can produce different output from small changes to a prompt, so human review cannot be a rubber stamp.
• Accountability for an AI-assisted decision rests with the person who made it. Addressing that is partly a process and user experience design problem, and largely unsolved.
• The same discipline applies to security. You cannot outsource to a tool the assurance that your software is actually hardened. That has to be built in and verifiable.

 

The use of AI in the automotive industry now spans the threat model, the regulatory conversation through the EU AI Act, and the daily work of building vehicles. Automotive security teams are being asked to govern something that is moving into their products, their pipelines, and their judgment at the same time.

That tension was the throughline of a recent Automotive World panel hosted by RunSafe Security. The panel featured Tyson Benson, Process Owner and Cybersecurity Engineer at Clarios, and Dr. Joachim Fox, who recently led safety and cybersecurity governance for ZF’s automotive products and now chairs &ai, a foundation focused on the ethics of AI. RunSafe founder and CEO Joe Saunders moderated. 

The conversation separated the question, “What do we do about AI,” into three problems that need different answers.

Listen to the full webinar here.

AI in Automotive Products: Bounded Scope Is the Safety Lever

The first place AI shows up is in the vehicle itself, and the panel was careful not to treat it as one thing. Fox pointed out that the industry has safely shipped AI in narrow roles for a long time. Cameras that read traffic signs, and driver attention monitoring systems now required in Europe, are AI that have been in the field for years with a limited job and a limited scope of action.

 “AI is not only LLMs,” he said, and the distinction matters because those bounded systems can be reasoned about.

The hard case is the unbounded one. End-to-end models that run from camera and sensor input straight to actuator control, the kind used in higher levels of autonomy, cannot be exhaustively specified the way a traffic-sign classifier can. 

Fox’s guidance was to push AI toward roles you can contain. Give it a limited scope, wrap it in a safety mechanism to catch it when it runs wild, or restrict it to non-safety-critical functions. The amount of trust you extend should track how tightly you can bound what the system is allowed to do.

AI in Automotive Development: Why Review Can’t Be a Rubber Stamp

The second place AI appears is in how the product gets built, often without any AI reaching the product at all. Code assistants are already generating large amounts of software inside development environments. The instinct on some teams is to wave this off by analogy: automotive engineers have run automatic code generators for years, the panel noted, producing hundreds of thousands of lines that no human reviewed by hand, so why is AI different?

Fox noted that a traditional generator operates on predefined patterns that were thoughtfully developed and unit-tested. If one pattern has a defect, it repeats predictably, gets caught, gets fixed, and the generator is sound again. AI code generation does not behave that way. The output is “unstable if you slightly change the prompt,” he explained, so a defect is not a repeatable, fixable property of a known pattern. 

Benson made the same point from the user’s side, noting that an assistant is “just a probabilistic model that’s generating tokens,” even when it does a convincing job of anticipating where you were going.

The practical consequence is that human review of AI-generated code in safety-critical work cannot be the same review you would give to pattern-based output. It has to actually verify, not approve by reflex. That is a heavier lift than most pipelines are currently designed for, and pretending otherwise is how unreviewed risk enters the build.

AI in Automotive Decisions: The Part Most Likely to Go Wrong

The third place, and the one the panel treated as most dangerous, is decision-making. Increasingly, AI is not just producing artifacts but also shaping choices, recommending priorities, summarizing a document so someone can sign off, or evaluating a safety case. It is fast and persuasive, and Fox noted that it generates proposals far faster than a person can properly assess them. That speed is exactly what makes it tempting to let the tool decide.

Benson offered a thought experiment that should stay with any engineer. Imagine using AI to produce a hazard analysis and risk assessment, the HARA required under ISO 26262 functional safety. It looks thorough and reads convincingly, so it gets presented and accepted. A year later, a gap in that analysis surfaces, forcing a redesign. Now the engineer has to explain to a manager why the work presented twelve months ago missed it. “But the AI generated it” is not an answer that transfers the consequences anywhere. The liability stayed with the person the whole time. 

Benson framed the underlying habit in terms many people will recognize: the hypothetical engineer had started offloading judgment to the fast, automatic “system one” that an assistant trains you to trust, and has been working to pull back to the slower, critical “system two” that the work demands.

Fox said, “The responsibility lies never with the machine.” If an AI review informs a release decision, the human who released it owns that decision in full.

An audience poll during the discussion suggested that most organizations believe they are on top of this, with many reporting that they have a formal AI governance program in place. Fox pressed on what those programs actually contain. Much of the current effort, he observed, goes toward the EU AI Act: building an AI register, sorting each tool into one of four risk categories, and demonstrating bias controls and transparency. That work is necessary, but it can amount to legislative box-checking. 

Benson, who practiced law before moving into automotive security, recognized the pattern. Teams ask the attorney what the regulation requires, get back a list of items that safeguard the company from liability, and under time pressure do exactly those and no more. The deeper question, whether the program keeps people able to make conscious, accountable decisions, often goes unasked.

Human Accountability and the Future of AI in the Automotive Industry

Saying the human is responsible is necessary but not sufficient. If a process forces a person to tick off whatever the AI produced, with no real view into the reasoning and no time to weigh the impact, then accountability exists on paper and nowhere else. Fox was clear that this is not mainly a technical challenge but a process and user experience design challenge. 

How do you present AI assistance in a critical workflow so that the human can actually exercise responsible judgment rather than approve at the speed at which the tool generates? He called it “the big challenge of the future,” and acknowledged it is, in many cases, still unsolved. Simply telling people to read the output and confirm it, he said, “is not going to solve the problem.”

Saunders connected the point back to a constraint that the automotive industry cannot wave away. Functional safety depends on determinism, on systems whose behavior in a given state is known and repeatable. Probabilistic tools sit in tension with that requirement, which is why human judgment and verifiable controls have to stay in the path rather than be designed out of it.

The same logic carries into security. An assistant can quickly and convincingly suggest that code is secure or that a control is in place. The assurance that a shipped binary is genuinely hardened is not something to take on faith from a tool. It has to be built in and provable, which keeps both the responsibility and the evidence with people and with verifiable engineering rather than with the model. That is the discipline RunSafe advocates, and it mirrors what the panel described on the safety side.

For the engineers managing legacy constraints, tight deadlines, and now a wave of AI tooling arriving across their teams, the takeaway is not that AI should be kept out. It is that accountability cannot be handed over with the work. The responsibility stays with humans. The job is to design processes that let people carry it out.

The full conversation, including the panel’s discussion of what actually reduces risk in deployed vehicle software, is available on demand from Automotive World.