Pexon Consulting | 10 Min. Lesezeit | 02.06.2026
TL;DR
FMEA Agent OpenAI löst das Update-Problem bei Konstruktions-Änderungen: Aus jedem DRW-Diff wird automatisch ein Delta-FMEA-Vorschlag mit Cross-Check zu Lastenheft (ALR) und Risk-Level-Assessment (ARL). Aus 6-Wochen-Workshops werden 2-Stunden-Reviews. Pexon baut diese FMEA-Agents mit dem OpenAI Agents SDK und Azure OpenAI in EU-Region für deutsche Maschinenbauer.
Warum FMEA-Updates die teuerste QM-Routine im Maschinenbau sind
Eine Design-FMEA für eine mittelgroße Baugruppe (50-150 Einzelteile, 200-400 Fehlerbild-Zeilen) braucht im Erstaufwand 80-160 Personenstunden — verteilt auf Konstruktion, QM, Fertigung und teilweise Lieferanten. Das ist viel, aber einmalig. Das eigentliche Problem ist die Pflege.
Bei jedem Design-Change (DRW-Update, BOM-Änderung, Werkstoff-Wechsel) müsste die FMEA überarbeitet werden. Theoretisch. In der Praxis passiert das selten konsequent — weil ein FMEA-Update-Workshop wieder 4-12 Stunden mit drei bis fünf Personen frisst, und niemand das pro Engineering-Change-Notification machen will. Die Folge: Die FMEA driftet von der Realität ab. Nach 6-12 Monaten ist sie ein Dokument, das nur noch beim nächsten Audit aus dem Schrank geholt wird.
Aus drei Pexon-Discovery-Workshops mit Maschinenbauern (300-2.500 MA) wissen wir: Die durchschnittliche FMEA-Aktualität liegt bei 4-9 Monaten Verzug gegenüber der aktiven Konstruktion. Das ist nicht nur Audit-Risiko nach IATF 16949 oder VDA Band 4 — es ist auch Wirkungslosigkeit. Eine FMEA, die nicht das aktuelle Design beschreibt, hat keinen Risikomanagement-Wert.
Der Workflow vor dem Agent — und wo Stunden verloren gehen
Konkret läuft ein heutiger FMEA-Update-Workflow bei einem typischen Mittelständler in vier Phasen ab:
- Trigger — Konstrukteur ändert eine Zeichnung (DRW) im PLM. Das Engineering-Change-Request-System (ECR) sendet eine Mail an die QM-Verteiler-Liste. Liegezeit bis zur ersten Reaktion: 1-3 Tage.
- Manuelle Sichtung — Ein QM-Mitarbeiter öffnet das alte Drawing, das neue Drawing und die FMEA-Excel-Datei. Vergleicht visuell, sucht betroffene FMEA-Zeilen. Bei mehreren parallelen ECRs gehen die schnell durcheinander.
- Bewertungs-Workshop — FMEA-Moderator lädt Konstruktion, Fertigung und QM ein. Geht zeilenweise durch die betroffenen Punkte. Bewertet B/A/E neu, definiert Maßnahmen.
- Dokumentation und Verteilung — Excel wird aktualisiert, an Lastenheft-Verantwortliche kommuniziert (oder eben nicht), neue PDF-Version im PLM abgelegt.
Die Stunden gehen vor allem in Phase 2 und 3 verloren. Phase 2 ist Detektivarbeit, die Routine ist, Phase 3 ist Workshop-Koordination, die 70 % Wartezeit ist. Die eigentliche fachliche Bewertung — wo Menschen-Hirn unverzichtbar ist — sind vielleicht 30 % des Aufwands.
FMEA Agent OpenAI — die Architektur
Die Idee ist, Phase 2 und 80 % von Phase 3 zu automatisieren. Der Mensch bleibt in der fachlichen Bewertung und in der finalen Freigabe. zoll und exportkontrolle automatisieren: ki klassifiziert warennummern
+------------+ +------------------+ +-------------+
| ECR-System | | FMEA Agent | | Azure |
| (PLM) |--->| (OpenAI Agents) |--->| OpenAI |
| sendet | | - DRW-Diff-Tool | | (GPT-4.1, |
| DRW-Event | | - FMEA-Read-Tool | | EU-Region) |
+------------+ | - ALR-Read-Tool | +-------------+
| - ARL-Read-Tool |
| - Delta-Generator|
+------------------+
|
v
+-----------------+
| FMEA-Moderator |
| - Review-Paket |
| - 1 Session 2 h |
+-----------------+Drei Architektur-Entscheidungen, die in jeder Implementation gleich bleiben:
- Azure OpenAI in EU-Region (sweden-central oder germany-westcentral) als LLM-Backend. Das ist bei den meisten deutschen Maschinenbauern bereits regulatorisch freigegeben, anders als die OpenAI-Standard-API. Schwellenargument deutlich niedriger als bei US-Cloud-LLMs.
- OpenAI Agents SDK als Orchestrator. Seit dem Major-Release ist die SDK robust genug für Produktion. Native Tool-Calling, Tracing eingebaut, Multi-Agent-Handoff-Pattern, sauberes Async-Modell.
- Read-Only-Datenzugriff. Der Agent liest DRW, FMEA, ALR, ARL — er schreibt nirgendwo zurück. Das Delta-FMEA ist ein Vorschlag, nicht ein automatisches Update. Das ist die Compliance-Grundlage.
Die drei Tool-Familien des FMEA Agent OpenAI
Der Agent kommt mit acht Tools aus, gruppiert in drei Familien.
Familie 1 — Engineering-Change-Tools (DRW-Bezug). Lesen die geänderte Zeichnung und vergleichen sie mit der Vorversion. Identifizieren betroffene Bauteile, Maße, Werkstoffe, Toleranzen. Das ist der Vision-Teil der Pipeline — wir nutzen GPT-4o mit Vision für Drawing-Vergleiche, weil die Performance hier deutlich vor allgemeinen Diff-Tools liegt.
Familie 2 — FMEA-Repository-Tools. Lesen die bestehende FMEA aus dem QM-Repo (typisch Excel, manchmal IQ-FMEA oder Plato), filtern auf die betroffenen Funktionen und Fehlerbilder, geben strukturierte Zeilen-Liste zurück.
Familie 3 — Cross-Reference-Tools (ALR + ARL). Lesen das Lastenheft (Anforderungs-Liste/Requirements, ALR) und das Risk-Level-Assessment (ARL) der Baugruppe. Diese Cross-Checks werden manuell fast immer vergessen — der Agent macht sie jedes Mal.
Plus zwei Cross-Cutting-Tools:
generate-delta-fmea— erzeugt aus den vorigen Tool-Outputs den Delta-FMEA-Vorschlag im definierten Formatprepare-review-package— bündelt Delta-Vorschlag, betroffene ALR-Anforderungen und betroffene ARL-Risiko-Klassen in ein PDF/Excel-Paket für den Moderator
Code-Beispiel — Agent mit OpenAI Agents SDK
So sieht der produktive FMEA Agent in seinen Grundzügen aus. Vereinfacht, die echte Implementation hat mehr Edge-Case-Handling.
from agents import Agent, Runner, function_tool
from pydantic import BaseModel
class DeltaFMEAResult(BaseModel):
affected_lines: list[dict]
new_lines_suggested: list[dict]
alr_cross_check: list[str] # Lastenheft-Anforderungen
arl_cross_check: list[str] # Risk-Level-Assessment
review_priority: str # "high" | "medium" | "low"
moderator_questions: list[str]
@function_tool
def get_drw_diff(drw_id: str, version_from: str, version_to: str) -> dict:
"""Vergleicht zwei Versionen einer Konstruktions-Zeichnung."""
return plm_client.get_diff(drw_id, version_from, version_to)
@function_tool
def get_fmea(fmea_id: str, filter_by_components: list[str]) -> list[dict]:
"""Liest FMEA-Zeilen für bestimmte Komponenten."""
return qm_repo.read_fmea_rows(fmea_id, filter_by_components)
@function_tool
def get_lastenheft(product_id: str) -> list[dict]:
"""Liest ALR (Lastenheft-Anforderungen) für ein Produkt."""
return alr_repo.get_requirements(product_id)
@function_tool
def get_risk_level_assessment(product_id: str) -> dict:
"""Liest ARL (Risk-Level-Assessment) für ein Produkt."""
return arl_repo.get_assessment(product_id)
fmea_agent = Agent(
name="FMEA-Refresh-Agent",
instructions="""Du bist Assistent für FMEA-Moderatoren im Maschinenbau.
Aufgabe: Bei DRW-Änderung einen Delta-FMEA-Vorschlag erzeugen, mit
automatischem Cross-Check gegen ALR und ARL. Keine Bewertungen ändern,
nur vorschlagen. Bei Unklarheit Frage an Moderator stellen.""",
tools=[get_drw_diff, get_fmea, get_lastenheft, get_risk_level_assessment],
model="gpt-4.1",
output_type=DeltaFMEAResult,
)
result = await Runner.run(
fmea_agent,
input="DRW-12345 wurde von V2 auf V3 geändert. Erstelle Delta-FMEA.",
max_turns=8,
)Drei wichtige Detail-Entscheidungen:
output_type=DeltaFMEAResultzwingt den Agent in eine strukturierte Output-Form. Kein Halluzinations-Vektor, kein Format-Drift zwischen Läufen.max_turns=8als Hard-Cap. Mehr als 8 Tool-Calls braucht keine sinnvolle FMEA-Analyse. Bei 8 ist klar etwas falsch gelaufen — der Agent geht in einen Eskalations-Pfad.instructionsgeben dem Modell explizit das Mandat, bei Unklarheit Fragen zu stellen statt zu raten. Das ist die Anti-Halluzinations-Klausel.
Cross-Reference Logic — wie der Agent ALR und ARL prüft
Der eigentliche Mehrwert gegenüber einer manuellen FMEA-Aktualisierung sind die zwei Cross-Checks, die in der Routine fast immer untergehen:
Cross-Check 1 — ALR (Lastenheft). Wenn der DRW-Change z.B. eine Wanddicke verändert, prüft der Agent: Steht im Lastenheft eine Anforderung zur Drucktauglichkeit, zur Schwingungsfestigkeit oder zur Lebensdauer, die durch diese Änderung tangiert ist? Wenn ja, wandert die ALR-Anforderung in das Review-Paket. Der Moderator entscheidet, ob die Anforderung weiterhin erfüllt ist.
Cross-Check 2 — ARL (Risk-Level-Assessment). Das ARL klassifiziert das Produkt in Risiko-Klassen (z.B. nach IEC 61508 SIL-Stufen oder ISO 13849 Performance-Levels). Wenn die FMEA-Bewertung einer betroffenen Zeile auf „schwerwiegend“ (B≥9) oder „kritisch“ (A·B≥80) springt, prüft der Agent: Liegt die Komponente in einer SIL-relevanten Funktion? Wenn ja, eskaliert das Review-Paket automatisch in die Sicherheits-Engineering-Schleife.
Diese beiden Cross-Checks sind in einem manuellen Workflow theoretisch vorgesehen, werden aber faktisch in 60-80 % der Updates übersprungen — weil sie pro Update wieder 1-2 Stunden Recherche kosten und unter Zeitdruck wegfallen. Der Agent macht sie zur Standard-Routine, ohne dass jemand sie aktiv anstoßen muss. Das ist der eigentliche Compliance-Gewinn.
Was der Agent NICHT macht — und warum das gut ist
Drei Dinge bleiben bewusst beim Menschen:
- Die Bewertung B/A/E ändern. Der Agent darf eine neue Zeile mit initialer Bewertung vorschlagen, aber niemals eine bestehende Bewertung überschreiben. Das ist Verantwortung des Moderators und seines Teams.
- Die FMEA freigeben. Der Output ist immer Vorschlag, nie Update. Die Excel/IQ-FMEA wird vom Moderator nach Review manuell freigegeben. Das ist Audit-Anforderung und Haftungs-Grundlage.
- Maßnahmen erfinden. Der Agent darf strukturelle Maßnahmen-Kategorien vorschlagen (z.B. „Prüfschritt im EOL-Test erweitern“), aber niemals konkrete Werte oder Verantwortliche festlegen. Das fällt in den Workshop.
Wir raten aktuell davon ab, Agents in den schreibenden Pfad einer FMEA zu legen. Das ist nicht technische Limitation, sondern Compliance- und Vertrauens-Grund. Eine FMEA, die automatisch fortgeschrieben wird, verliert ihren Wert als gemeinsam getragenes Risiko-Verständnis im Team. Der Agent beschleunigt die Vorarbeit — die fachliche Entscheidung bleibt menschlich.
Kosten und Zeitrahmen
Transparent aus zwei laufenden Pexon-Projekten. Für einen ersten produktiven FMEA-Agent OpenAI mit Anbindung an PLM, QM-Repo, Lastenheft und Risk-Level-Assessment:
Laufende Kosten: LLM-Tokens auf Azure OpenAI typisch 200-500 EUR pro Monat bei 30-60 DRW-Changes pro Monat. Hosting (Azure Function oder AKS) ca. 100-300 EUR pro Monat. Wartung 0,5-1 PT pro Monat.
ROI-Rechnung: Wenn der manuelle Aufwand pro FMEA-Update bei 12-20 Stunden liegt und der Agent das auf 3-5 Stunden Review reduziert, sparen Sie pro Update 8-15 Stunden Fachkräfte-Zeit. Bei 40-80 Updates pro Jahr in einem Mittelständler sind das 320-1.200 Stunden — typisch 0,2-0,8 FTE. Amortisation 6-14 Monate.
Häufig gestellte Fragen
Warum OpenAI Agents SDK und nicht Claude Agent SDK?
Zwei Gründe. Erstens: Azure OpenAI ist bei den meisten deutschen Maschinenbauern bereits regulatorisch freigegeben — das spart 3-6 Monate Compliance-Vorlauf gegenüber AWS-Bedrock oder Anthropic-API. Zweitens: Das OpenAI Agents SDK hat in der aktuellen Version (Stand Q2/2026) ein leicht reiferes Multi-Agent-Handoff-Modell, das für komplexere FMEA-Cases (z.B. Cross-Disziplin-Reviews) Vorteile bringt. Wer schon einen Anthropic-Vertrag und AWS-Freigabe hat, kann die gleiche Architektur mit Claude Agent SDK bauen — die Konzepte übertragen sich 1:1.
Funktioniert der Agent auch mit IQ-FMEA, Plato Scio oder APIS IQ-Software?
Ja, sofern eine API-Anbindung möglich ist. IQ-FMEA und Plato Scio haben REST-APIs, APIS IQ-Software hat eine COM-Schnittstelle. Für Excel-basierte FMEAs (was leider immer noch der Mittelstands-Default ist) liest der Agent direkt aus dem File. Wir empfehlen den Wechsel auf eine API-basierte FMEA-Software vor dem Agent-Setup, weil die Datenqualität deutlich höher ist.
Was passiert, wenn der Agent eine falsche FMEA-Zeile vorschlägt?
Das ist normal und im Design vorgesehen. Der Moderator sieht im Review-Paket Vorschläge mit Confidence-Score und Begründung. Falsche Vorschläge werden im Review verworfen — keine FMEA-Zeile wird ohne Moderator-Freigabe in das Quellsystem geschrieben. Über die ersten 30-50 Cases lernt das Pexon-Team die typischen Fehlermuster und verfeinert die Agent-Instruktionen, sodass die Trefferquote von typisch 70-80 % auf 88-94 % steigt.
Wie verhindere ich, dass FMEA-Daten durch den Agent die EU verlassen?
Azure OpenAI in einer EU-Region (sweden-central oder germany-westcentral) hält die Daten vertraglich und technisch in der EU. Zusätzlich konfigurieren wir den Azure-Tenant ohne Data-Retention beim Anbieter (use_for_training=false). FMEA-Daten sind häufig vertraulich (Konstruktions-IP, Lieferanten-Bewertungen) — das saubere Aufsetzen lohnt sich.
Kann ich den Agent für die EU-Maschinenverordnung 2027 als Konformitäts-Nachweis nutzen?
Indirekt ja. Eine durchgängig aktuell gehaltene FMEA ist Voraussetzung für die Risikobeurteilung nach EU-Maschinenverordnung 2023/1230. Der Agent macht diese Aktualität wirtschaftlich machbar. Der Agent selbst wird aber nicht zur Sicherheitskomponente — er steht außerhalb der Maschine und entscheidet keine Schutzfunktion mit.
Nächster Schritt
Wenn Sie aktuell mit Verzug in der FMEA-Pflege kämpfen oder die Aktualisierungs-Workshops zur Engpass-Routine werden: Wir machen das im 6-Wochen-Pilotprojekt für Generative AI konkret — mit Use-Case-Schnitt in Woche 1, PLM/QM-Anbindung in Woche 2-3 und produktivem FMEA Agent OpenAI mit ersten drei Real-Cases bis Woche 6.
Verwandte Themen
→EU-Maschinenverordnung 2027: Wann KI eine Sicherheitskomponente ist
→VDI 2770 Doku-Migration mit Claude Skills
