Use of AI for the Creation of FMEAs - Part 1
A blog post by Dr. Uwe-Klaus Jarosch, July 2026
I had the opportunity to spend an entire day with FMEA experts from across the German-speaking world, learning about different approaches to using AI tools to support the creation of FMEA analyses.
First things first: Today’s AI tools (June 2026) are already capable of remarkable feats.
“Methodically ” is a blog series that’s actually about methods.
One might argue that AI is really just a matter of tools.
But in my view, that’s not the case: When we integrate generative AI into our FMEA methodology, the tasks, priorities, processes, roles, and habits that have traditionally defined a successful workflow undergo massive changes.
This blog will therefore consist of three parts:
Part 1 – Tasks in FMEA Work and Features of the Compared AI-Supported FMEA Tools
Part 2: Completing the Tasks
Part 3: Potential Impacts
In Part 1, I will compile a list of the tasks that need to be completed when developing an FMEA.
And I will provide a description of the different approaches offered by the tools presented—without claiming to be exhaustive regarding the solutions that already exist globally.
In Part 2, I will analyze the seven steps of the FMEA process—as outlined in the 2019 AIAG-VDA FMEA Handbook—more or less in sequence, and identify how AI contributes to the FMEA process.
In Part 3, I’d like to venture a personal outlook on the coming years, focusing not only on today’s methods and new tools but also on the “if-then” conditions for the successful use of AI-supported systems compared to conventional tools.
To that end, I’d like to highlight a few “challenges” that I foresee.
Part 1 – Tasks in FMEA Work and Features of the Compared AI-Supported FMEA Tools
From a methodological perspective, we can use a design FMEA to analyze system considerations, designs, the development of mechatronics, electronics, and software, as well as the development of equipment and tools.
A process FMEA can be used to examine planned workflows, with the focus of its applications on manufacturing processes, although topics such as logistics, customer service, or internal processes can also be analyzed in a very similar manner. The workflows in question simply need to be planned and, as far as possible, repetitive.
Both types of FMEA are worthwhile either when there is only one attempt with high public attention—as is the case with many space projects—or when we support the planning of products or services involving a high number of repetitions, such as automobiles, aircraft, medical devices, or industrial food products.
In all these applications, the FMEA should
- develop a shared understanding within the team of the task at hand, down to the finest details,
o regarding the division of roles,
o development deadlines,
o functional and technical objectives,
o the boundaries of responsibilities,
o the distinction from structural elements and their objectives that have been fully developed and tested and therefore should not be reconsidered,
o the distinction from or interfaces with development content from other development partners, e.g., functional departments or suppliers,
- proactively divide these tasks functionally (structure with functions and associated requirements),
- consider which potential deviations from these development goals could occur and are relevant,
- clarify cause-and-effect relationships by linking the deviations in a failure network across all levels and specify the significance of the failure consequences at the upper end of the relationship chains,
- to plan timely preventive and detection measures in order to either avoid the identified potential deviations or at least detect them during development,
- identify actions that have either been verifiably and effectively completed or are guaranteed to be implemented through other safeguards within the company, but exclude them from further tracking,
- assign responsible parties and target dates for all other actions, agree on the actions with these individuals, and track progress,
- evaluate the actions to determine how well they can prevent or detect the deviations to which they are assigned,
- derive further risk-reduction actions at the root cause level for the failures based on the triad of severity, occurrence, and detection,
- at any time, in accordance with specified reporting requirements, and at the end of the process, results are expected to be reported in terms of identified residual risks, open and pending actions, and the maturity level of the FMEA.
In my view, this long list of activities can only receive the necessary support if
- there is a clear commitment—for example, from customers or the company’s own development process—and clear guidelines for implementation,
- this long list of activities is supported by qualified guidance (-> FMEA moderation),
- if management wants to see the results and uses them to make decisions,
- if the participants see the FMEA as supporting their work rather than hindering it.
All these conditions are coming under pressure to achieve better development performance in ever-shorter time frames and, if possible, with fewer staff.
Conversely, the available tools and methods are evolving rapidly, which supports this acceleration or opens up alternatives for reaching goals more quickly.
The use of artificial intelligence—more specifically, generative AI—combined with the ability to influence the quantity and quality of the data and rules to be applied in the FMEA, now offers support for many of the tasks mentioned above.
However, a clear distinction must be made between content that can be derived from existing information, data, and instructions, and content that arises only through creative work during the development process and has no precedent.
For the former, AI can help; for the latter, AI is overwhelmed and can perhaps serve as a source of ideas based on analogies. Decisions are and will remain, for the time being, the domain of the developers—no matter how many “decision-capable” agents may exist for other issues.
System Comparison
- A conventional FMEA tool that enables access to publicly available, commercially standard Large Language Models (LLMs), mentioning neighboring node elements in the prompt[2] in keyword form and generating suggestions for FMEA content through simple queries drawn from the LLMs’ world knowledge.
[2] Promt = instruction tot he gernaritv AI as a text. According to expert recommendation the prompt shall have 3 topics: 1) the role of the AI for finding answers, e.g. expert for FMEA methods acc to xyz, 2) the task that shall be done, in best way as a step by step approach similar to the procedure you would use yourself, 3) the precise form of export, e.g. as a text answer or as a file for given type and format.
- An FMEA tool that, for any node element in the FMEA, sends a locally specific prompt—along with information about the adjacent node elements—to a selectable LLM in addition to manual input; it then processes the feedback into a list of suggestions for the next entries and embeds the selection directly into the FMEA. The feedback is based on external world knowledge and kept brief.
- An FMEA tool that currently features a heavily table-based user interface also allows users to make manual entries or manually modify existing entries. Unlike the other two tools, however, this one is designed to create a project-specific context in which “all” available planning results, requests, requirements and specifications, system analyses, previous FMEAs, etc., have been collected and pre-processed.
Similar to the second system, suggestions for additional entries can be generated for the scope of analysis, structure, functions, failures, and corrective actions based on the specified context. Extensive prompts specific to each situation ensure that the suggestions are designed to align as precisely as possible—both in content and semantics—with FMEA best practices.
The suggestions are consistently very detailed to unambiguously describe the context (see the 2-3-4 rule[1]), and the content is referenced to the project’s source documents wherever possible. Only in exceptional cases are suggestions generated from the world knowledge of the LLM used; however, these are then marked as AI-generated.
The transition to traditional FMEA tools is implemented using common XML formats for reading and writing.
[3] 2-3-4-Rule – Write it down in a manner that a second can tell it a third person in four years.
Conclusions:
- Artificial intelligence, particularly in large language models (LLMs), is being hyped everywhere and marketed as a jack-of-all-trades.
- In each of the three tools presented, access to LLMs was created via the user interface, with varying degrees of integration.
- It turns out that LLMs are not all-purpose solutions. Support from other tools, such as audio transcription, graph analysis, and graph coders, is helpful overall.
- The prompt used is crucial to success.
- The reliability of the results increases when project-specific data is used via RAG.
Stay curious
Yours
Uwe Jarosch