Method-safe FMEA@AI: why the method belongs before the model
Ask three providers what AI costs in the FMEA, and you get three answers, none of which tells you what you will really pay at the end of the year. Attention focuses on the language model, on its size, its speed, its price per query. The real cost question stays unanswered: where does the technical work sit? As long as the model re-derives the FMEA logic on every request, you are renting the thinking, and the bill keeps running with every run. Anyone who wants to make the risk predictable has to decide first where the method lives: in the model or before it.
This article carries a proven DC benchmark into a field that is just emerging: Method Mastery in FMEA practice becomes method-safe FMEA@AI. It shows why the order, method before model, decides predictable cost, reproducible results and the human's authority to evaluate. Afterwards, you can check in your own organisation whether your AI approach rents the thinking or owns it, and whether the evaluation stays where it belongs.
From Method Mastery to method-safe FMEA@AI
At Dietz Consultants, one term has stood for the core of good FMEA work for many years: Method Mastery. It means that a team reliably masters the methodology and justifies its judgments instead of guessing. In the seminar field, Method Mastery is an established benchmark. With AI, the same question arises one level higher: does the system stay method-safe, or does the model now guess instead of the human? So far, the market discusses AI in the FMEA as a tool question, which model, which provider, which price per query. That is the wrong level. The real question is an architecture question: does the method lead the model, or the other way around? We call the approach in which the method leads and the model is only the interface to language method-safe FMEA@AI. Anyone who thinks this way no longer evaluates AI offerings by the model, but by the method behind it.The LLM is the commodity, not the value
A large language model (LLM) is an interchangeable commodity today. It phrases fluently, it summarises, it translates language. For the FMEA, this is valuable exactly where language is involved: consolidating existing data, harmonising wording, relieving the team of documentation work. What an LLM alone does not deliver is the technical reasoning that a robust FMEA rests on. It produces plausible sentences, not assured methodology. The commercial value does not come from a larger model, but from the structure that sits before the model.Where the method sits decides what you pay
There are two fundamentally different places for the FMEA logic, and they lead to opposite cost curves. If the method sits in the model, it is re-derived on every request. Every failure chain, every cause, every judgment is recalculated per run. You rent the reasoning, and you rent it again every time. In a demo, this goes unnoticed; there, consumption eats through a set credit balance over an afternoon. In production, it eats through it every day.If, on the other hand, the method sits before the model, in a structured, maintained rule base, then the model only handles the phrasing and the matching against this rule base. You own the reasoning once. The cost stays manageable, because not every technical statement is bought anew. The difference is not gradual, it is structural: ongoing consumption cost versus a once-built, reusable structure.
Method before model: the order is the point
The core is an order. First the knowledge is structured, then the model speaks. A maintained rule base and a curated knowledge base form the foundation. On top of that sits a structured knowledge representation. The model comes last, as the interface to language, not as the source of technical substance. This makes the model the variable, replaceable part. The defensible value is the method in front, not the model behind. Anyone who only tweaks the model builds on sand, because the next, better model makes that work worthless. Anyone who owns the method swaps the model and keeps the value.
Reproducibility is not a convenience, but a standard's requirement
An FMEA has to hold up in review. The same input must lead to the same traceable result, otherwise the evaluation is not reproducible. What is meant is the reproducibility of the AI proposal, not of the human judgment: reproducible is what the AI derives from the rule base. A rule base is reproducible, a fresh model run is not. Two requests to a pure language model can deliver two different failure ratings without anything about the matter having changed. It is exactly this drift that does not hold up in an audit. The method before the model provides the traceability that an FMEA needs: every statement carries a reference to the rule base, not to a random wording of the day.
The evaluation stays with the human
There is a boundary that no AI may cross, and it is not a technical one, but a methodological one. The evaluation of a risk, the judgment on Severity, Occurrence and Detection, belongs to the engineer's responsibility. A well-built AI prepares this decision: it structures the input, keeps the reference to the method traceable, and relieves the burden of busywork. The human makes the judgment, the AI makes proposals. Anyone who delegates the evaluation to a language model gives away exactly the responsibility that an FMEA carries at its core, and loses it in the audit anyway. Method-safe FMEA@AI therefore also means: the machine computes, the human decides.
The real gain lies not in eliminating the busywork itself, but in what it frees up: time for system understanding. Anyone who hands off the mechanical work gains room to penetrate the system. This leads to better judgments, to higher efficiency in development and thus, if rather indirectly, to a cost advantage.
Three questions before introducing AI into the FMEA
Before you introduce an AI approach for the FMEA, clarify three points. First, the cost: is it capped predictably, or is it measured per inference? Second, the stability: does the same input deliver the same traceable result, or are you guessing anew on every run? Third, the authority to evaluate: does the AI prepare the decision and let the engineer evaluate, or does it presume to make the judgment itself? The first two answers depend on the location of the method. The third is a question of attitude, and it is non-negotiable.
Example
The difference shows not in the demo, but in operation and in the audit. An approach that leaves the technical evaluation to the model looks convincing in the demo, yet the running cost scales with usage, and two identical requests can turn out differently. An approach that places the method before the model shifts the weight: the cost stays manageable, the same input leads to the same traceable result, and the justification points to the method, not to a daily fluctuation. The decisive practical test is simple: ask the same thing twice and compare the answers. If they diverge without any factual reason, the method sits in the model and not before it. That is exactly what surfaces in the review at the latest.
Result
A language model can phrase an FMEA. Only a method can defend it, and only a human can evaluate it. Put the method before the model, and the cost becomes predictable, the results reproducible, and the evaluation stays in your responsibility. That is the core of method-safe FMEA@AI.
Where does the method live in your AI approach, in the model or before it?
Talk to the FMEA experts at Dietz Consultants: www.dietz-consultants.comAuthor: Winfried Dietz, CEO Dietz Consultants GmbH
Winfried Dietz is the CEO of Dietz Consultants GmbH and has been supporting development organisations worldwide in introducing and maturing the FMEA methodology for over 30 years. He is a trainer, author and speaker for FMEA according to AIAG-VDA. Find more from the FMEA Quick Tip series on LinkedIn.