148 KI-Tools für FMEA checken: Tool-Zoo oder System?

VonThomas Luft

Setup-KI, Struktur-KI, AP-Priorisierungs-KI: der FMEA-Tool-Zoo 2026

Tim Bendzko sang 2011, vor dem Weltretten müsse er erstmal 148 Mails checken. 2026 macht man das in der FMEA-Praxis. Setup-KI. Anforderungsanalyse-KI. Strukturanalyse-KI. AP-Priorisierungs-KI. Eine nach der anderen, jede ein separater Tab im Browser.

Für Ihre FMEA gibt es jetzt auch: eine Setup-KI, eine Anforderungsanalyse-KI, eine Strukturanalyse-KI, eine AP-Priorisierungs-KI. Und jemanden, der die alle zusammenhält: noch nicht.

Diesen Satz habe ich vor wenigen Wochen auf LinkedIn gepostet. Die Reaktionen waren eindeutig. Genauso erleben es die meisten, die KI ernsthaft in die FMEA-Arbeit reinlassen.

Warum jedes einzelne Tool funktioniert und das Ganze trotzdem Flickwerk bleibt

So habe ich auch angefangen. Custom GPTs in OpenAI für einzelne Phasen. Prompts, optimiert in der Claude Console. Einzelne Workflows in n8n für Anforderungs-Extraktion und Bewertung. Jeder Baustein für sich: ganz ordentlich. Zusammen: Flickwerk.

Schon besser war ein Multi-Agent-Assistent, der die FMEA-Software direkt bedient. Aber auch der hat einen Engpass. Er ist eine geschickte Klammer um einzelne Fähigkeiten, kein gemeinsames Gedächtnis.

Das Ergebnis war dasselbe wie bei den meisten, die ich heute sehe. Werkzeuge, die nebeneinander existieren, aber nicht miteinander arbeiten.

Der Unterschied: Tool vs. System, wer hält den Kontext?

Der Unterschied zwischen einem Tool und einem System ist nicht die Anzahl der Funktionen. Er liegt darin, ob irgendetwas den Kontext hält.

Felix Schlenther bringt es auf den Punkt: KI ist kein Tool, kein Mitarbeiter, KI ist ein Betriebssystem. Florian Baader von SelectCode, dem Hersteller hinter meinGPT\*, ergänzt aus der Praxis: erst Use, dann Case.

Für die FMEA bedeutet das: Solange jede Teilaufgabe in einem eigenen KI-Werkzeug läuft, ohne gemeinsame Datenbasis, ist jedes neue KI-Tool nur ein weiterer Fenster-Tab. Es gibt keinen Ort, an dem die FMEA als Ganzes lebt. Die Liste der KI-Tools für FMEA wächst monatlich. Die Liste der Architekturen, die diese Tools zu einem System verbinden, eher nicht.

Das ändert sich erst, wenn die Werkzeuge auf eine gemeinsame Schicht zugreifen. Genau dort beginnt ein echtes Engineering-Betriebssystem.

Was im Tool-Zoo konkret kaputt geht: drei Szenarien

Drei Beispiele aus der Praxis, in denen das Nebeneinander-Existieren Schaden anrichtet.

Szenario 1: Strukturanalyse schlägt System-Elemente vor, das Funktionsnetz erfindet eigene.

Eine Strukturanalyse-KI liefert eine saubere Hierarchie der System-Elemente. Eine zweite KI baut das Funktionsnetz auf. Sie kennt die Elemente aus der ersten KI nicht und benennt neue. Im Workshop muss das Team manuell zuordnen. Eine halbe Stunde Vorbereitung wird zu zwei Stunden Aufräumen, jedes Mal.

Szenario 2: AP-Bewertung passt nicht zur erkannten Maßnahme.

Eine AP-Priorisierungs-KI bewertet Risiken auf Basis einer älteren Fehleranalyse. Parallel hat eine Maßnahmen-KI bereits Maßnahmen ergänzt. Die AP-Bewertung kennt sie nicht. Das Ergebnis: bewertet wird ein Zustand, den es nicht mehr gibt. Im nächsten Audit fällt das auf, wenn der Auditor fragt, warum die AP von B nach C gewandert ist, ohne dass eine Maßnahme die Wirksamkeit belegt.

Szenario 3: Nächste FMEA-Sitzung, niemand weiß, was die vorige KI vorgeschlagen hat.

Vier Wochen später, neuer Termin. Wer hat damals welchen Prompt benutzt? Welche Version des Custom GPT war aktiv? Welche Wissensdatenbank hängt dran? Keine Versionierung, keine Nachvollziehbarkeit. Damit ist die KI-gestützte FMEA für einen AIAG/VDA-Audit ein Problem statt eine Entlastung.

Was hier scheitert, ist die Architektur.

Vom Custom GPT zum Engineering-Betriebssystem: mein Weg

Als ich mit KI-Unterstützung in der FMEA angefangen habe, war mein Werkzeugkasten voll. Custom GPTs in OpenAI für jede Phase. Prompts, optimiert in der Claude Console. Einzelne n8n-Workflows für Anforderungs-Extraktion. Jeder Baustein hat funktioniert. Zusammen waren sie ein Flickenteppich aus Tabs, Logins und Copy-Paste.

Ich habe drei Dinge gelernt.

Erstens, der Wert entsteht nicht in der Einzel-KI. Er entsteht im Übergang von einer Phase in die nächste, dort, wo die Daten weitergereicht werden.

Zweitens, ein KI-Tool ohne gemeinsame Datenschicht ist eine Suchmaschine mit Chatbot-Anstrich. Es kann gute Antworten geben, aber keine Erinnerung an die letzte Sitzung.

Drittens, eine Engineering-Fähigkeit muss fünf Eigenschaften haben, bevor sie produktiv ist. Eine davon: persistenter Zustand. Eine andere: Rückverfolgbarkeit, also ein Audit-Trail, der zeigt, welcher Vorschlag von welcher KI mit welchem Prompt zu welchem Zeitpunkt kam.

Was ein FMEA-Betriebssystem konkret leistet

Heute sieht mein Aufbau anders aus. meinGPT\* als Frontend, ISO 27001 zertifiziert, Hosting bei Hetzner in Deutschland, AVV nach Art. 28 DSGVO abgeschlossen. Self-hosted n8n im Hintergrund als „Skills“, die Automatisierungsschicht, die Workflows, Wissensdatenbank und bestehende FMEAs verbindet.

Das System hat einen gemeinsamen Datenraum. Eine Datenbank, die die FMEA-Struktur (Strukturanalyse, Funktionsnetz, Fehlernetz, Maßnahmen) so abbildet, dass jeder Workflow weiß, was die anderen gerade tun. Die einzelne KI ist austauschbar. Die Datenbasis ist der Anker.

Konkret heißt das:

  • Ein neuer Strukturanalyse-Vorschlag landet als Vorschlag in der Datenbank, nicht als Text im Chat.
  • Eine AP-Bewertung weiß, auf welcher Strukturversion sie aufsetzt.
  • Eine Maßnahme bleibt mit der Fehlerursache verknüpft, auch wenn die Sitzung dazwischen zwei Wochen dauert.
  • Bestehende Installationen müssen nicht ersetzt werden. APIS IQ und Plato e1ns können mit derselben KI-Schicht erweitert werden, wenn ihre Schnittstellen das hergeben.

Ein FMEA-Plausibilitäts-Bot prüft im Hintergrund, ob die Strukturanalyse zur Funktionsanalyse passt und ob die Maßnahmen zu den Fehlerursachen gehören. Das ist nichts, was eine einzelne Setup-KI leisten kann. Das geht nur, wenn der Kontext erhalten bleibt.

Was das in eurer FMEA-Praxis ändert

Wer als Q-Manager oder Engineering-Leiter heute KI in die FMEA bringen will, sollte vor der Tool-Auswahl die Architektur-Frage stellen. Wer hält den Kontext? Wo werden Strukturen, Funktionen, Fehler, Maßnahmen so abgelegt, dass die nächste Sitzung darauf aufsetzt? Welcher Workflow stellt sicher, dass die Methodik-Treue zu AIAG/VDA 2019 gewahrt bleibt, auch wenn eine KI Vorschläge macht?

Wer diese Fragen vor dem Einkauf nicht beantworten kann, kauft Lizenzen für Tools, die in sechs Monaten in einem Reiter unter „Sonstiges“ verschwinden.

Nächste Schritte

Drei Wege, je nach Tiefe des Interesses:

Wer meinGPT als KI-Plattform für eigene Tests anschauen will: meinGPT testen\*.

—

\* Anzeige

Hinweis: Mit * gekennzeichnete Links sind Werbung (Affiliate-Links).

Thomas Luft ist PCC-zertifizierter FMEA-Experte und AGILean Coach. Er berät Engineering-Unternehmen beim Aufbau KI-gestützter Prozesse. Kontakt und weitere Infos: fmea-ki.de.

Ähnliche Beiträge