Warum euer KI-Einsatz in der FMEA so oft im Tool-Zoo endet

Für eine FMEA gibt es 2026 für jede Phase eine eigene KI: Setup-KI, Anforderungsanalyse-KI, Strukturanalyse-KI, AP-Priorisierungs-KI. Jedes Werkzeug funktioniert für sich. Zusammen sind sie ein Flickenteppich aus Tabs, Logins und Copy-Paste.

Der Engpass ist nicht die einzelne KI. Der Engpass ist die fehlende Klammer. Es gibt keinen Ort, an dem die FMEA als Ganzes lebt, kein gemeinsames Gedächtnis, keine Versionierung der Vorschläge, keine Audit-Spur für eine spätere Wirksamkeitsprüfung. Wer KI in der FMEA-Arbeit ernsthaft nutzen will, muss vor der Tool-Auswahl die Architektur-Frage stellen.

Vertiefung: Was im Tool-Zoo konkret kaputt geht.

Was ein Engineering-Betriebssystem ist – und was nicht

Ein Engineering-Betriebssystem ist die Architektur-Schicht, die einzelne KI-Fähigkeiten zu einem zusammenhängenden System verbindet. Es ist:

• Kein einzelnes Tool — sondern eine Klammer um mehrere
• Kein Custom GPT — sondern eine Plattform mit eigenem Datenraum
• Keine FMEA-Software — sondern die KI-Schicht, die bestehende FMEA-Software bedient
• Kein Tool-Zoo — sondern ein Zustand, der zwischen Sitzungen, Phasen und Werkzeugen erhalten bleibt

Der Begriff folgt der Logik, die Felix Schlenther geprägt hat: KI ist kein Tool, kein Mitarbeiter, KI ist ein Betriebssystem. Übertragen auf Engineering und FMEA heißt das: ein System, das eure Methodik, eure Daten und eure Werkzeuge zusammenführt.

Die fünf Eigenschaften jeder Engineering-Fähigkeit

Den Begriff KI-Betriebssystem hat Felix Schlenther im allgemeinen B2B-Kontext geprägt. Übertragen auf Engineering wird daraus etwas Spezifischeres. Eine Fähigkeit, die Teil eines Engineering-Betriebssystems ist, braucht fünf Eigenschaften — jeweils mit dem Engineering-Anker, der sie über einen Office-Generalisten hinaushebt:

• Selbstbeschreibung mit Methoden-Kontext — sie erklärt, was sie tut und gegen welche Methodik (AIAG/VDA 2019, ISO 26262 und so weiter) sie arbeitet
• Standardisierte Schnittstellen mit Domain-Schema — sie nimmt FMEA-strukturierten Input (Strukturanalyse, Funktionsnetz, Maßnahmen) und gibt strukturierten Output, nicht freien Text
• Gedächtnis mit FMEA-Versionierung — sie kennt die früheren Zustände der FMEA und kann erklären, was sich wann geändert hat
• Orchestrierbarkeit aus dem Engineering-Workflow — sie ist aus anderen Fähigkeiten aufrufbar, nicht nur per Chat
• Rückkopplungsschleife aus Reviews — Feedback aus FMEA-Sitzungen und Reviews fließt zurück und verbessert die Fähigkeit

Wenn eine Fähigkeit drei davon erfüllt, ist sie ein Custom GPT. Mit allen fünf wird sie ein produktiver Teil des Engineering-Betriebssystems.

Vertiefung: Die fünf Eigenschaften jeder Engineering-Fähigkeit.

Die fünf Schichten der Architektur

Das System besteht aus fünf Schichten:

• Frontend — austauschbar je nach Kundenkontext. Default: meinGPT* mit Projektdateien als RAG, Microsoft-365-Konnektoren (SharePoint, OneDrive, Outlook im Lesemodus), eigenen Skills und Workflows, Custom-MCP-Einbindung für n8n; ISO 27001, Hosting bei Hetzner in Deutschland, AVV nach Art. 28 DSGVO, vom Anbieter auch on-premise installierbar. Alternativen: Open WebUI als LLM-agnostisches Self-Hosted-Frontend (spricht Anthropic, OpenAI, Google, Mistral oder lokale Modelle), oder Microsoft Copilot Studio mit FMEA-Copilot für M365-Häuser. Die Wahl folgt der Datenschutz-Anforderung und der bestehenden Infrastruktur, nicht umgekehrt
• Skills-Schicht — self-hosted n8n als Automatisierungs- und Workflow-Layer
• Datenraum — PostgreSQL mit pgvector für Embeddings und JSONB für FMEA-Strukturen (Strukturanalyse, Funktionsnetz, Fehlernetz, Maßnahmen)
• LLMs — Wahl ist Deployment-Entscheidung, abhängig von Datenschutz-Anforderung, Reasoning-Anspruch und Hardware-Verfügbarkeit. Die Modelle sind austauschbar; die Architektur bleibt
• FMEA-Domäne — Anbindung an euer bestehendes FMEA-Tool (APIS IQ, Plato e1ns, andere) über deren Datenmodell

Die einzelne KI ist austauschbar. Die Datenbasis ist der Anker. Genau das ist der Unterschied zu einem Tool-Stack.

Vertiefung: Architektur des Engineering-Betriebssystems und Frontend-Optionen im Vergleich.

Was das System in eurer FMEA-Arbeit konkret leistet

Ein laufendes Engineering-Betriebssystem für FMEA liefert im Kern vier Fähigkeiten:

• Plausibilitätsprüfung — passt die Strukturanalyse zum Funktionsnetz? Sind die Maßnahmen mit Fehlerursachen verknüpft? Vertiefung: FMEA-Plausibilitäts-Bot.
• Wissen konservieren – der Rentner-Effekt — wenn erfahrene Mitarbeiter das Unternehmen verlassen, bleibt ihr implizites Wissen abrufbar. Universell für jeden Funktionsbereich (Engineering, Einkauf, Akquise, HR, Finanzen); im FMEA-Kontext besonders relevant für Konstruktions-Sonderfälle und Lessons Learned. Vertiefung: Engineering-Wissen konservieren.
• Methodik-Wache nach AIAG/VDA 2019 — das System prüft KI-Vorschläge gegen die offiziellen Regeln, bevor sie in der FMEA-Datenbank landen.

Eure FMEA-Software bleibt – wir setzen darauf auf

Eure bestehende FMEA-Software bleibt. PeakAvenue hat seit 2023 den größten Teil des deutschsprachigen FMEA-Software-Marktes konsolidiert (Plato e1ns, APIS IQ, iqs Software, Isograph, OSSENO). Wer eine dieser Lösungen installiert hat, will sie nicht ersetzen, sondern um KI-Fähigkeiten erweitern. Das Engineering-Betriebssystem setzt darauf auf:

• Es liest aus eurer FMEA-Datenbank, ohne Schemen zu erfinden
• Es schreibt Vorschläge zurück als nachvollziehbare Datensätze, nicht als Chat-Text
• Es respektiert eure Berechtigungen, Workflows und Audit-Anforderungen

PeakAvenue selbst bietet KI-Funktionen im Requirements-Management an. Eine Drittanbieter-Erweiterung um KI-Assistenten gibt es dort nicht — das ist die Lücke.

Dasselbe Prinzip gilt für eure Wissensmanagement-Systeme. Wer bereits Empolis, Elunic oder vergleichbare Lösungen nutzt, integriert sie als zusätzliche RAG-Datenquelle — sie werden eingebunden, nicht abgelöst.

Vertiefung: PeakAvenue und APIS IQ mit KI-Assistenten erweitern.

Methodik-Treue zu AIAG/VDA 2019 – KI ohne Methodik-Verfall

KI darf in der FMEA nicht zu beliebigen Ergebnissen führen. AIAG/VDA 2019 verlangt eine spezifische Methodik: sieben Schritte, Aufgabenpriorität (AP) statt RPZ, Strukturanalyse vor Funktionsanalyse, Bewertung gegen definierte Kriterien. Ein Engineering-Betriebssystem prüft KI-Vorschläge gegen diese Methodik, bevor sie in der FMEA-Datenbank landen.

Konkret: Wenn die Strukturanalyse-KI ein System-Element vorschlägt, das im AIAG/VDA-Sinne keine Funktion erfüllen kann, wird der Vorschlag als Hinweis markiert, nicht automatisch übernommen. Die Methodik bleibt menschlich gesteuert. Die Vorbereitung wird beschleunigt.

Vertiefung: AIAG/VDA 2019 — Methodik-Treue trotz KI-Einsatz.

Souveränität: eure FMEA-Daten bleiben in Europa

Eure FMEA-Daten sind oft Teil von OEM-Projekten unter NDA. Sie dürfen nicht in US-Cloud-Diensten landen. Ab Februar 2026 verlangt der EU AI Act zusätzliche Transparenz-Pflichten für Hochrisiko-Anwendungen — und FMEA kann je nach Produktkontext in diese Kategorie fallen. Das Engineering-Betriebssystem ist von Beginn an europäisch konzipiert:

• Hosting bei Hetzner in Deutschland oder vergleichbarem EU-Anbieter
• ISO 27001 für die genutzten Frontend-Komponenten
• LLM-Wahl mit Datenverarbeitung in der EU oder lokal
• Vollständige Audit-Spur für jede KI-gestützte Änderung

Souveränität ist hier kein Marketing-Argument, sondern eine Architektur-Eigenschaft.

Vertiefung: EU AI Act und FMEA — was Mittelständler 2026 wissen müssen.

Zusammenarbeit: Tagessatz, Festpreis oder Hybrid

Der Aufbau eines Engineering-Betriebssystems ist kein Lizenzkauf, sondern ein Beratungs- und Engineering-Projekt. Drei Preismodelle sind je nach Phase sinnvoll:

• Tagessatz — für die Discovery-Phase, wenn der Scope noch offen ist, und für laufende Erweiterungen
• Festpreis-Sprint — für klar abgegrenzte Bauteil-FMEAs mit überschaubarer Sitzungszahl, wenn die Methodik geklärt ist
• Hybrid — Festpreis-Kick-off plus Stundenrahmen für die offene Phase danach

Das Modell wird vor dem ersten Termin gemeinsam festgelegt. Es gibt kein Pauschalpreis-für-alles-Versprechen, weil FMEA-Tiefe selten vorher messbar ist.

Vertiefung: Externer FMEA-Moderator — Tagessatz, Festpreis oder Hybrid?.

Drei Wege, um anzufangen

• Erstgespräch — kostenfrei, 30 Minuten, sortiert eure aktuelle Tool-Situation und benennt die nächsten Architektur-Entscheidungen. Kontaktformular.
• Tief einsteigen — startet beim Spoke über den Tool-Zoo, wenn ihr selbst gerade in dieser Situation seid.
• Methodik zuerst — startet beim Spoke zur AIAG/VDA-Treue, wenn euch die Methodik-Frage als Erstes umtreibt.