AI Is Changing Functional Safety — But Not the Way You Think

Khizer Hammad KhanFounder & Chief Engineer, Voltguard · 10 June 2026 · 8 min read

There are two conversations happening about AI in functional safety, and most people only hear one of them. The first is loud and optimistic: AI will automate the tedious parts of ISO 26262. The second is quieter and more important: the AI we're putting inside the vehicle has broken the assumptions our entire safety framework was built on. Both are true. Here is how I see them from the workbench.

The framework was built for systems that don't change their minds

ISO 26262 is, at its heart, a discipline for deterministic systems. You define an item, you analyse how it can fail, you assign each hazard an ASIL based on severity, exposure, and controllability, and you build evidence that the system behaves the way you specified. The whole V-model rests on one quiet assumption: that a given input produces a knowable output, every time. Verify it once under defined conditions and it stays verified.

Machine-learning systems do not honour that assumption. An ML model learns its behaviour from data rather than from a specification an engineer wrote. It can encounter an input it was never trained on and respond in a way no one anticipated. As one recent analysis put it plainly, AI is not software in the traditional sense — it learns, adapts, and behaves differently based on data, and that single difference, data dependency, changes everything about managing risk. When a perception model misclassifies a stopped truck as open road, there is no faulty line of code to point at. The logic did exactly what its weights told it to. The weights were simply wrong for that moment.

This is not a reason to distrust AI in vehicles. It is a reason to extend the framework — which is exactly what the standards bodies have done.

The standards caught up: SOTIF, then ISO/PAS 8800

Two pieces now sit alongside ISO 26262 to cover what it cannot. ISO 21448 (SOTIF — Safety of the Intended Functionality) addresses hazards that arise not from a malfunction but from the limitations of a correctly-functioning system: the sensor that can't see in fog, the perception function that fails on a scenario its designers never imagined. Nothing broke; the function simply wasn't capable enough for the situation. That's a category ISO 26262 was never designed to catch.

Then in 2025 came ISO/PAS 8800, the first standard written specifically for the safety of AI in road vehicles. It complements ISO 26262 and SOTIF by defining the requirements and work products for AI components — crucially, it connects the dataset lifecycle to system-level safety requirements, analysis, verification, and validation. It treats the training data as a safety-critical artefact in its own right, because for an ML system, the data is the design.

The other direction: AI as a tool for safety work itself

While the standards grapple with the safety of AI, a quieter shift is happening in how we do the work. The most labour-intensive parts of functional safety — hazard analysis, requirements tracing, documentation — are exactly the kind of structured, language-heavy tasks that large language models are surprisingly good at assisting with.

The early research is genuinely encouraging. In one comparative study on autonomous-driving HARA, an AI-augmented process identified, on average, around 20% more hazards than the conventional manual approach — not by being smarter than the engineers, but by being tireless at enumerating scenarios a human team, late in a long day, might skip. AI is a superb brainstorming partner for the combinatorial sprawl of "what could go wrong, in which situation, with what exposure."

But — and this is the part the loud conversation skips — every serious study reaches the same conclusion: expert review remains essential. The researchers who automated HARA with LLMs were explicit that, despite their best efforts to automate, human expert validation of the results could not be removed. An LLM will confidently produce a hazard analysis that is fluent, well-formatted, and subtly wrong. It hallucinates failure modes that don't apply and, more dangerously, omits ones that do. For a document that an assessor signs and a life depends on, fluent-but-wrong is the worst possible failure mode.

How we use it at Voltguard — and where we draw the line

My position as an engineer is neither hype nor refusal. AI is a power tool in the workshop, and like any power tool it makes a skilled person faster and a careless person dangerous. Here is the discipline we hold to:

• AI accelerates the first draft, never the final word. We use it to widen the net in early hazard brainstorming and to draft routine documentation — then every output passes under an experienced safety engineer's review before it touches a work product.
• Traceability is non-negotiable. Structured analysis methods make it feasible for AI to contribute because each step can later be interrogated for validity. If we can't trace and justify a claim, it doesn't go in the safety case — regardless of how it was generated.
• When AI is in the product, we change frameworks. A vehicle function that uses ML is not an ISO 26262 problem alone. It is an ISO 26262 plus SOTIF plus ISO/PAS 8800 problem, and we treat the training data as a safety artefact from day one.

The companies that win the next decade of electric and automated vehicles won't be the ones that adopt AI fastest or resist it longest. They'll be the ones that understand precisely which safety question each tool answers — and which questions still require a human who has read every clause and seen what failure looks like.

That combination — modern tools, old-fashioned rigour — is the whole reason Voltguard exists.

Have thoughts on this piece?

I read every message — reach me directly.

Email me at khizerhammad845@gmail.com  ·  Call or message +90 533 884 0871
Or use the enquiry form on the Voltguard site for project work.