Use of AI for the Creation of FMEAs - Part 2
A blog post by Dr. Uwe-Klaus Jarosch, July 2026
This is the follow up of the blog post on “Tasks and Features of the Compared AI Tools.”
In the first part, I compiled the tasks that facilitators and team members must perform when creating a FMEA in order to effectively support a development project, whether it involves product or process development.
AI tools are intended to assist with these tasks, saving time and improving the quality of the results.
In addition, in Part 1, I compared the features of three AI-supported FMEA tools.
Part 2 of the blog series focuses on the 7 steps according to AIAG-VDA.
Each of these steps is necessary to progress from the initial assignment to the—at least preliminary—completion of the FMEA.
In addition, I examine the maintenance of the FMEA, which involves updates for various reasons.
The evaluation of FMEAs will not be discussed in detail.
It should also be noted that the example discussed concerned a product that has been available on the market in a wide variety of versions for many years. Therefore, the example cannot be considered representative of the development of something new.
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 2 – Completing the Tasks in 7 Steps
Step 1 covers the preparation of the FMEA.
There was consensus among the experts that the preparatory work is a key factor in the success of the entire FMEA process.
Regardless of the tool used, this involves gathering all available preliminary information.
The first two tools presented use the world knowledge of large language models to derive suggestions. The third tool features a type of RAG[1]. The project data is entered and processed in advance. This process initially provides the foundation for starting the work and can be updated as the project progresses.
[1] RAG = Retrieval-Augmented Generation: Large language models are fed specific data, which they process in a way that enables targeted access to and use of that data. The data is broken down into segments, indexed, and thus prepared for targeted access. In addition to the LLMs’ general knowledge, this approach allows for the use of specific data or factual information from reliable sources.
Regardless of the FMEA tool used, it is necessary to hold an initial kickoff meeting with the team for coordination.
It is recommended to do this using a clear kickoff checklist.
Such a team meeting does not have to be time-consuming. A series of checklist questions can be answered in advance of the team meeting. This information should be shared with all team members during the meeting.
For minute-taking, AI tools are available both to record the team event audio and automatically transcribe it, and to generate a comprehensive set of minutes from the transcript of the spoken words—one that captures all content and also identifies any gaps that need to be clarified afterward.
With the appropriate selection of AI tools from a fairly diverse range AND suitable prompts, a verbatim transcript and an evaluated summary can be created in just a few minutes.
Both are important for cross-checking the AI-generated summary against the spoken words and approving it with confidence.
The FMEA document in the tool typically contains header fields. At least some of the checklist entries are transferred to fields in the FMEA header. This, too, is easily conceivable when creating the FMEA using a prepared prompt, but it is not demonstrated today.
An important point here is the scope of analysis. Since this is a decision made by the client in collaboration with the stakeholders, it makes sense to discuss and decide on the scope of analysis during the kickoff meeting and then transfer it from the written summary into the FMEA. The general recommendation is to use a “is/ is not” description. Graphical representations, such as a block-boundary diagram or a process flowchart illustrating the process steps, can be used to supplement the “Is/Is not” description in a consistent manner.
Step 2: Structural Analysis
The clear scope in Step 1—what is to be considered, what is not to be considered, which external and internal interfaces must be taken into account, and to what level of detail in the system structure the analysis should extend—also serves as the groundwork for Step 2: Structural Analysis.
In the design phase, it is recommended to use a block-boundary diagram for this purpose, in which the root element, its subelements, the external interfaces, and the internal interfaces between the subelements are clearly shown.
Using AI tools, code can be generated from both available images of the development object and existing boundary diagrams; this code identifies, on the one hand, the elements and designations within the scope of analysis and, on the other hand, their connections, and can be used for automatic conversion into diagrams and as encoded information for the FMEA structure.
In all three tools, this external preparatory work can be used for import, so that the structure tree is complete in the first draft.
In the process FMEA, the comparable reference document is a process flowchart.
This lists the process steps to be analyzed in their sequence, including sub-steps where applicable.
Depending on the specifications, steps such as goods receipt, incoming inspection, logistical transfers, or inspection steps may be included or excluded from the analysis.
Similar to product design, specialized AI applications enable the conversion of graphics into code that can then be used to build the FMEA structure.
Manual intervention is possible in all tools.
Step 3: Functional Analysis
The functional analysis is the most challenging step in creating a FMEA.
Each element of the structure must contain at least one function; otherwise, that system element is not needed.
Exception 1: Although the system element is named, it has been decided not to analyze it within the scope of the analysis.
Exception 2: The system element is named but serves primarily as an organizational aid. In process FMEA analyses, I have frequently used this to distinguish between equipment and the integrated sub-steps without having to deviate from the equipment development nomenclature.
All three tools offer the option to generate suggestions for functions for a selected system element and to adopt them as desired.
As explained in Part 1 for the three alternatives, the seamless integration of AI into the tool varies in depth and performance.
In the first example, general knowledge from an LLM is utilized. To assist the AI, a small excerpt from the structure tree is provided, and the element for which suggestions are sought is identified. The task for which the AI is to find an answer is formulated in a prompt. In the simplest case, the connection between the FMEA tool and the AI tool consisted solely of the aforementioned excerpt.
The result is then more of a concise list of keywords. From this list of keywords, the team can make a selection and import it into the tool. In the example, node elements of the “Function” type were created under the system element according to the selection and populated with the text generated by the AI.
In the second example tool, the immediate context of the structure is also transmitted to the AI. Additionally, however, a prompt for querying functions is predefined; this does not need to be entered manually but is specifically stored within the tool.
Here, too, the query returns a list of suggestions that, in the selected example, appeared to be a meaningful list of purposes for which this subsystem or component is needed. The selection function is integrated into the tool, and after confirmation, the selection is added to the correct location in the structure without the need for copy-pasting.
In the third example tool, the element or level for which function suggestions need to be generated is selected from the tabular overview of available content—in this case, the structure tree.
The request to the AI is triggered and processed in the background. In principle, the procedure is identical to that of the second example tool. The main differences, however, are that here, world knowledge from the LLM is used only in exceptional cases; instead, priority is given to the knowledge base that was previously fed into the system as verified and project-relevant from the company’s knowledge repository.
The AI’s results now consist of three parts:
- a short text in which functions are described semantically correctly and in relation to physics, chemistry, and logic,
- a comment, supplement, or note of approximately 100 words describing the proposed function in its project context. This is intended to aid in the later understanding of the entries (2-3-4 rule[2]).
- An additional button breaks down results in the title and comment into sub-information, and their references are cited. If no answer could be derived from the reference data, the result is identified as AI-generated.
[2] 2-3-4 rule: Write it down in a manner that a second person can tell it a third person in 4 years.
This result is based, on the one hand, on the aforementioned RAG and, on the other hand, on sophisticated prompting.
As with the other two integration solutions, the results must be read, evaluated, and selected. This can be tedious, if only because of the extensive result texts. However, the quality of the results in the examples shown is remarkably good from both a methodological and an engineering perspective.
Here, too, validated proposals are correctly integrated directly into the structure, and connections are generated in the functional network.
Step 4: Failure Analysis
Regarding failure analysis, I would like to note that, in my view, meaningful entries generally do not consist of negating the functional result. More meaningful—and more appropriate to the reality of product and process development—are failure scenarios that differ significantly depending on
- whether the system, product design, or process is being analyzed,
- whether the design involves mechanics, mechatronics, or software,
- whether we are examining failures in terms of consequences, at the focus level, or in terms of causes,
- whether applicable boundary conditions or specifications lead to specific failure cases and should be included in the FMEA.
Accordingly, an AI must be provided with this information in order to generate usable failure descriptions as suggestions.
The failure scenarios also lead to potentially ambiguous links between failures at the root cause level, focus failures, and consequences.
We must take into account the fact that AI does not possess the kind of understanding that we, as developers, have acquired over the years. The suggestions are therefore either derived from previously structured relationships (see RAG and knowledge graphs[3]) or based on statistics.
[3] Knowledge graphs illustrate relationships between elements, such as cause-and-effect relationships between functions or potential errors. These relationships can then be retrieved and utilized as needed.
Step 5: Current Actions and Their Evaluation
With Step 5, the FMEA method shifts from analysis to action.
Step 5 could be populated with ations that have already been reliably implemented within the scope of the project, e.g., decisions adopted from previous projects for specific subsystems, assemblies, components, or connections, or the establishment of rules for the project.
Some companies list practically everything that is ever mentioned in the FMEA as a development action. In such cases, there is no tracking of these actions, even though this no longer has much in common with the intent of the FMEA methodology.
During the event, no examples were shown of whether, how, or how to retrieve and integrate such measures from the linked AI systems.
The interface configuration was visible in the tools. And I assume that the three example applications can generate similar feedback for such actions as they were able to do for structural elements, functions, and failures.
What took place in all three examples without AI was the creation of ratings.
As you surely know, the classic FMEA methodology requires three ratings:
- Severity (DE: B, EN: S) is rated on a scale of 1–10 to indicate how high up the failure tree the potential consequences could be in the worst-case scenario.
The assessment therefore takes place at the very top, at the level of impacts on the end customer, the customer in the supply chain, the internal customer, the manufacturing process at the plant, or the company itself. This assessment is then top-down trickling through the (uninterrupted) failure tree down to the causes.
- Occurrence (DE: A, EN: O) is rated on a scale of 1–10 to indicate how effectively the specified preventive actions jointly prevent the failure at the root cause level.
The combined effect of all preventive actions for this failure is expressed as a probability of occurrence. The criteria may vary from industry to industry. O=3, 2, or 1 indicates highly effective actions and generally signifies that the development goal has been achieved.
- Detection (DE: E, EN: D = Detection) is rated on a scale of 1–10 to assess how well the specified detection actions can detect and report the specific error at the root cause level or the consequential error at the focus level. Here, the assessment does not focus on how often the failure actually occurred (that is the observed O), but “only” on how effectively the listed D actions, taken together, can detect this failure.
All three values are consolidated at the very “bottom” of the FMEA, at the root cause level. From this, further action items can be derived in Step 6.
The evaluation in Step 5 will always be subjective. The evaluation must usually be estimated for the future based on assumptions. Concrete results—specifically for Occurrence O, but also for Detection D—are not yet available in the early planning phase. At best, there are empirical values from previous projects. In many cases, however, the numbers are simply hopes and wishes.
In the examples of AI-supported FMEA presented here, the evaluation was clearly the domain of humans and was not generated by AI.
Step 6: Optimization and Mitigation of Identified Risks, Re-evaluation
Based on the evaluation of the interaction between S, O, and D, local risks can be estimated for the specific causes. The FMEA method refers to recommendations for action and traditionally combines the three values via multiplication (SxOxD) to produce a risk priority number (RPN). Two to three decades ago, methods were introduced that place a higher value on prevention than on detection. Using SxO, AxD, and OxD matrices, a combination of two values could be placed at the center of the assessment.
The AP matrix[5] is currently preferred.
[5] AP = Action Priorities: The 10 × 10 × 10 = 1,000 combinations of S, O, and D values are typically assigned a value from red, yellow, or green on a case-by-case basis. Green: All essential measures have been taken, but there is always room for improvement; Yellow: The team is advised to take further measures to mitigate the local risk; if not, they must provide justification; Red: The team is required to define further measures to mitigate the identified local risk. If not -> justification and, for example, management approval.
Here, too, in all three examples, AI suggestions were not used—or were used only for corrective actions. The decision regarding further actions, reassessment, and the tracking of actions remains with the humans on the FMEA team.
Step 7: Communicating Results
This step draws on information that was previously entered into the FMEA system. It requires neither creative input nor a new evaluation. This is one of the areas where large language models excel. Give me data, and I’ll turn it into a concise, well-written, and to-the-point summary. Tell me who the audience is, and I’ll tailor it to be easy to digest for that specific audience.
To do this, the AI needs three things:
- The existing FMEA content.
- The task specifying what should be summarized and presented, and how.
- The presentation format, e.g., a template document to be used.
In most of the examples shown here, the content was exported in a neutral format that’s easily readable by AI. Typically, this isn’t Excel or Word—with their graphical formats designed for human readers—but rather a structured text file (e.g., XML[6]).
[6] XML = Extensible Markup Language. It is plain ASCII text, written by machines for machines. For people who understand programming code, XML is certainly readable, but relationships—which we tend to visualize graphically—are established there through references (numbers, names) that must reappear elsewhere in the text.
Here, too, the AI results are impressive and save the facilitator a great deal of time that would otherwise be spent on manual creation. However, FMEA tools are already equipped with algorithmic features to format the available content into a report.
FMEA Maintenance
Automatic maintenance of the content is not included in the 7 steps. And it was not discussed during the workshop.
Such maintenance could be conceivable in the future for
- Changes to the development object
- Incorporation of improvements and customer complaints
- Automatic evaluation of the O-value based on real data, whether it be test results from design verification and validation or scrap and rework figures from ongoing production for the P-FMEA.
All such external influences could be applied to the current state of the FMEA and displayed as a delta relative to the latest update. What the FMEA team, the product or process expert, or the plant team responsible for ongoing production does with this information is another matter. But the changes would at least be recorded.
Although this question was raised during the event, it was not considered part of the FMEA creation process.
Conclusions:
- Both offline preparatory work and active team time can be effectively supported and accelerated by a combination of different AI applications.
- What was demonstrated does not yet constitute a fully integrated AI-for-FMEA solution in my view. Specifically, at the beginning and end of the process, there is too heavy a reliance on tools outside the FMEA tool’s user interface.
- If specific project data is provided to the AI language models in a targeted manner, and if queries via the language model are executed with precise, case-specific instructions, surprisingly reliable and high-quality results can be achieved—provided that only previously stored knowledge elements are used.
- However, we are most likely only at the beginning of this development.
Stay curious
Yours
Uwe Jarosch