AI-Assisted Safety Analysis Is Coming to ISO 26262 Programs — Here’s What’s Actually Happening
Functional safety programs in automotive development have always operated under a specific constraint: the analysis must be both thorough and defensible. Thorough means you found the failure modes that matter. Defensible means you can show an assessor exactly how you found them and why you addressed them the way you did. These two requirements have historically pulled in opposite directions — thoroughness takes time, and time is the one thing automotive programs consistently run short of.
AI tooling is beginning to change that dynamic. Not dramatically, not yet, and not without real complications. But the shift is underway. OEMs and Tier 1 suppliers at the leading edge are piloting AI-assisted workflows in Hazard Analysis and Risk Assessment (HARA), Failure Mode and Effects Analysis (FMEA), and Fault Tree Analysis (FTA). The use cases are specific, the benefits are measurable in limited contexts, and the regulatory questions are genuinely unresolved. This is a field in motion.
What Early Adopters Are Actually Doing
The narrative circulating in supplier engineering organizations — that AI will “automate” safety analysis — does not match what serious programs are deploying. The actual use cases are narrower and more useful.
Candidate failure mode generation. This is the most common starting point. Given a system function description, a component boundary, and a relevant operating environment, AI tools can generate a candidate list of failure modes for engineer review. The output is not a finished FMEA. It is a structured prompt to the safety engineer: have you considered these? In practice, experienced engineers report that well-configured AI tools surface roughly 70–80% of the failure modes they would have identified themselves, plus some that would have required a second pass or a design review to catch. The value is not in replacing the engineer’s judgment — it is in not requiring the engineer to generate every candidate from scratch before applying that judgment.
Completeness checking. FMEAs degrade over time. A system evolves, a supplier changes a component specification, or an integration test surfaces a behavior that was never analyzed. AI tools running against a connected model of requirements, system functions, and FMEA records can flag gaps: requirements that have no associated failure mode analysis, FMEA rows that reference component states no longer present in the current architecture, or hazard-cause chains that are missing a mitigation link. This kind of continuous completeness checking is operationally different from a point-in-time review. It is closer to a persistent audit.
Cross-referencing FMEA findings with requirements coverage. This is where the productivity gains are most concrete and most immediately verifiable. The task — checking whether every identified failure mode has a corresponding safety requirement, and whether every safety requirement traces back to at least one analyzed failure mode — has historically been done manually in spreadsheets or through labor-intensive navigation of linked documents in requirements management tools. In programs with mature system architectures, this cross-reference work can consume weeks of a senior safety engineer’s time during each product generation. Early AI-assisted deployments report this being done in hours, not because the AI makes the determination but because it surfaces the gaps for human review rather than requiring humans to search for them.
HARA scenario generation. Hazard analysis begins with identifying hazardous events — the combination of a vehicle-level hazard and an operational situation. Generating a comprehensive set of operational situations for a given hazard requires systematic thinking about vehicle use cases, edge cases, and interaction scenarios that can be genuinely difficult to do exhaustively from memory. AI tools trained on automotive system ontologies and incident data can generate plausible scenario candidates that safety engineers use as a starting checklist. The final HARA judgment — what ASIL to assign, how to bound the analysis — stays with the engineer.
The ISO 26262 Regulatory Question
ISO 26262 does not prohibit AI assistance in safety analysis. The standard is clear that the safety engineer is responsible for the analysis, not the tools used to conduct it. But that framing does not make AI tools regulatory-neutral.
Part 8 of ISO 26262 addresses supporting processes, and tool qualification is explicitly addressed. The relevant question is whether a software tool’s output could directly cause or fail to prevent a safety failure in the developed system. Tools used to generate or review safety analysis outputs sit in a range where tool confidence level (TCL) determinations are not straightforward. A tool that generates candidate failure modes that an engineer then reviews independently carries lower TCL risk than a tool that flags an FMEA as “complete” in a way that an engineer accepts without independent verification. The difference is in how the tool output is used, not just what it generates.
Several Tier 1 suppliers who spoke with Hardware AI Review described their current posture as “using AI as a reviewer’s assistant, not as a record producer.” Their tool qualification strategy treats AI-generated outputs as informal inputs to the safety case rather than formal records within it. The formal records — the FMEA worksheets, the HARA tables, the FTA diagrams — are generated and owned by the engineer. AI findings are documented as engineering notes or review inputs, not as safety artifacts that assessors will scrutinize under Part 8.
This is a pragmatic approach that works under the current absence of explicit regulatory guidance, but it has a ceiling. As AI tools become more deeply integrated into safety workflows, the question of when an AI output becomes a formal safety artifact is going to require explicit answers. Standards bodies including ISO TC22/SC32 and SOTIF working groups are monitoring deployments, but published guidance specific to AI tool use in safety analysis does not yet exist. Early adopters who are documenting their usage methodologies, tool validation approaches, and human oversight structures now will be better positioned when that guidance arrives — whether it comes as an ISO 26262 amendment, a supplementary technical report, or pressure from automotive cybersecurity and SOTIF working groups.
The Speed-to-Market Tension, Reframed
Automotive safety engineering leadership has been navigating the speed-versus-rigor tension since ISO 26262 was first published. The standard’s intent is to make safety analysis thorough, not to make it slow. In practice, the two have often moved together because thoroughness requires time, and time is allocated by programs that are always late.
AI tooling is beginning to reframe this tension in a way that matters for engineering leadership decisions. The question is no longer purely “how much time can we spend on safety analysis?” It is becoming “what tasks in safety analysis require trained human judgment, and which tasks are fundamentally information retrieval and cross-referencing that AI can do faster without compromising quality?”
The answer emerging from early deployments is that a significant fraction of safety engineering labor — estimates from practitioners range from 30 to 50 percent — falls into the second category. Not the judgment calls, not the ASIL assignments, not the safety architecture decisions. But the setup work: generating candidate failure mode lists, building initial HARA scenario tables, checking traceability matrices, flagging requirements without analysis coverage. These are tasks where AI assistance does not compromise rigor; it removes the conditions that lead engineers to cut corners because they are out of time.
The risk, and it is real, is that programs use AI-generated speed gains to compress safety timelines rather than to improve analysis quality. A program that previously took eight weeks to complete a system-level FMEA and now takes four weeks using AI assistance has not achieved twice the quality — it has a choice between four weeks of equivalent quality or eight weeks of higher quality. How programs make that choice will be one of the defining safety culture questions of the next generation of automotive development.
What Connected Requirements Models Enable
One pattern distinguishes programs that are capturing real value from AI safety assistance from those that are struggling: the quality of the underlying requirements model.
AI tools that cross-reference FMEA findings against requirements coverage can only do so if requirements are structured, linked, and current. Programs still operating primarily in document-based requirements management — where requirements live in Word-exported PDFs or flat spreadsheets with manual IDs — cannot take advantage of AI completeness checking because there is nothing structured to check against. The AI has no graph to traverse.
This is where modern requirements management tooling becomes a prerequisite, not a nice-to-have. Tools like Flow Engineering, which model requirements and their relationships as a connected graph rather than a document hierarchy, make the kind of AI-assisted cross-referencing described here tractable. When an AI tool can query the requirements model as a structured object — asking which FMEA rows reference this requirement ID, or which safety goals have no connected mitigation — it returns actionable findings rather than suggestions to “check the requirements document manually.” Flow Engineering’s graph-based architecture is designed for this kind of query, and automotive teams using it in safety-relevant programs have found it significantly reduces the setup cost of deploying AI analysis assistants on top.
The broader point is that AI-assisted safety analysis is not a bolt-on capability. Its value scales with the quality of the systems engineering foundation underneath it. Programs that have invested in structured requirements, maintained live traceability, and kept their system models current will get more out of AI safety tooling than programs that treat requirements management as a documentation exercise completed at program milestones.
What Honest Assessment Looks Like Right Now
AI-assisted safety analysis tools are useful, limited, and appropriate to deploy carefully. Practitioners using them are getting real productivity benefits on well-defined subtasks. No responsible deployment is using AI to make safety decisions or to produce formal safety artifacts without independent human review.
The regulatory posture is caution, not prohibition. ISO 26262 gives safety teams room to use AI tools responsibly if they understand the tool qualification framework and design their workflows accordingly. The teams that are proceeding without documenting their AI usage methodology are taking on risk that will be difficult to manage when assessors start asking questions — and assessors will start asking questions.
The speed-to-market tension is real, but it is not the right frame. The real question is whether automotive organizations are going to use AI-driven efficiency gains to do safety analysis better or simply faster. The answer to that question is a leadership decision, not a technology question. The technology enables both outcomes with roughly equal ease.
What will separate the automotive programs that benefit from this shift from those that are burned by it is not which AI tools they choose. It is whether they have the requirements infrastructure, the safety culture, and the engineering discipline to use AI outputs as inputs to human judgment rather than substitutes for it. That is the same discipline that makes any safety program work. AI tools do not change what good safety engineering looks like. They change how much of it is possible within the time and budget that programs actually have.