EU AI Act und FMEA — was Mittelständler 2026 wissen müssen • Thomas Luft

Worum es hier geht

Eine klassische FMEA mit KI-Unterstützung ist im EU AI Act in der Regel nicht als Hochrisiko-KI einzustufen — die konkrete Klassifikation hängt aber vom Zweck, Einsatzkontext und Funktionsumfang ab. Im Standard-Fall (Moderator und Team setzen Bewertungskriterien, KI liefert Vorschläge zur Diskussion) greift die Mensch-vor-KI-Auslegungslinie der EU-Kommissions-Draft-Guidelines vom 19.05.2026 — die ist allerdings nicht bindendes Recht, sondern Auslegungsmaßstab für Marktüberwachungsbehörden.
Es gibt aber vier Prüffragen für die Einzelfall-Klassifikation, die im Auge zu behalten sind: HR-Zweck-Erweiterung, direkte Steuerung kritischer Infrastruktur, embedded KI als Sicherheitsbauteil im Produkt (Medizin/Maschinen) und die Anbieter-Frage bei Re-Branding.
Die epistemische Falle bei B=10 und B=9 ist methodisch und produkthaftungsrechtlich relevant: KI ist gut bei häufigen Fehlerbildern und systematisch schwach bei Black-Swan-Szenarien — genau dort, wo FMEA eigentlich Wert stiftet.
Eine Hinweis-Sektion zu DSGVO und CLOUD Act: die formale AVV/SCC-Kette zu Anthropic, OpenAI, Google, Microsoft ist vorhanden, aber das US-Konzern-Problem bleibt — Pseudonymisierung vor LLM oder souveräner EU-Anbieter sind die belastbaren Antworten.
Drei Adressaten — Moderator (Verantwortungs-Rolle bleibt), Anwender (Quellen-Prüfung Pflicht, Haftungsverschiebung beachten), Kunde/Beschaffung (im Lastenheft KI-Einsatz, Datenfluss, On-Premise-Anforderung regeln).

Stand: Mai 2026. Dieser Beitrag ist eine fachliche Einordnung mit Quellenangabe — keine Rechtsberatung. Für konkrete Compliance-Entscheidungen ist anwaltliche Begleitung mit Schwerpunkt AI Act/DSGVO angebracht.

Anlass und Geltungsbereich

KI-Assistenten halten Einzug in die FMEA-Praxis — als Brainstorming-Hilfe, als Plausibilitäts-Checker, als Maßnahmen-Vorschlag-Generator, bis hin zu Pilotprojekten mit weitgehend automatisierter Erstellung kompletter FMEAs. Parallel hat die EU mit der Verordnung (EU) 2024/1689 (AI Act) das weltweit erste umfassende KI-Regelwerk geschaffen, das gestaffelt seit August 2024 in Kraft tritt. Die DSGVO flankiert das Ganze, der Trilog-Stand Mai 2026 zum Digital Omnibus IV verschiebt Teile der Anwendungsdaten.

Dieser Beitrag ordnet ein, was das für drei Gruppen heißt: FMEA-Moderatoren in ihrer fachlichen Verantwortung, Anwender (Konstrukteure, Qualitäter, Projektleiter), die mit KI-Vorschlägen umgehen, und Kunden (OEM-Einkäufer, Beschaffungs-Compliance), die KI-FMEA-Leistungen einkaufen oder ihren Lieferanten erlauben.

Das zentrale Prinzip: Der Moderator entscheidet

Die EU-Kommissions-Draft-Guidelines vom 19.05.2026 (Auslegung Art. 6 + Anhang III AI Act) entwickeln im Beschäftigungs-/HR-Kontext (Anhang III Nr. 4) eine Auslegungslinie, die in ihrer Logik auch auf andere Einsatzkontexte übertragbar wirkt — rechtlich bindend ist sie nur im HR-Kontext und auch dort nur als Auslegungsmaßstab, nicht als finale Verordnung:

Wenn der Mensch die Bewertungs-Kriterien erstellt und die KI nur ausformuliert, paraphrasiert oder prüft, gilt das System als Indiz gegen Hochrisiko-Einstufung. Wenn die KI die Kriterien selbst generiert, gilt es als starkes Indiz für Hochrisiko.

Wichtig: Das ist kein Automatismus, sondern ein Indiz — die endgültige Einstufung ergibt sich aus der Gesamtprüfung (Zweck, Einsatzkontext, Anhang-III-Eintrag, Art. 6 Abs. 3-Ausnahme).

Übertragen auf FMEA: Die Bewertungstabellen für B/A/E (Bedeutung/Auftreten/Entdeckung) nach AIAG/VDA 2019 stammen aus jahrzehntelanger Industrie-Erfahrung. Solange ein qualifizierter Moderator und das interdisziplinäre Team diese Tabellen anwenden und die KI nur Vorschläge zur strukturierten Diskussion liefert, bleibt die FMEA methodisch klassisch — die KI ist Werkzeug, kein Entscheider.

Der Moderator-Auftrag — moderieren, hinterfragen, Konsens herbeiführen, Entscheidungen dokumentieren — ist durch KI nicht ersetzbar, weil er nicht primär eine Wissens-Funktion ist, sondern eine Verantwortungs-Funktion.

Die epistemische Falle bei Themen zu Leib und Leben (typisch B=10) sowie Recht und Gesetz (typisch B=9)

Hier liegt der kritischste Punkt — methodisch und sicherheitstechnisch, unabhängig vom AI Act. Eine FMEA ist nur so wirksam wie ihre Vollständigkeit. Gefährlich sind die Fehler, die nicht gesehen werden, weil man nicht vermeiden kann, was man nicht erkannt hat.

KI-Systeme — egal ob klassische ML-Klassifikatoren oder LLMs mit RAG — arbeiten ausschließlich mit dem, was in ihren Trainingsdaten und ihrer Wissensbasis vorhanden ist. Sie sind gut bei häufigen und gut dokumentierten Fehlerbildern und systematisch schwach bei:

Neuartige Designs, für die keine vergleichbare Erfahrungsbasis existiert
Emergente Fehler aus dem Zusammenwirken mehrerer Subsysteme
Material- oder Lastgrenzbereiche, die in Standard-Anwendungen nicht vorkommen
Fehler an Schnittstellen zu Subsystemen, deren Spezifikationen die KI nicht kennt
Black-Swan-Szenarien — gerade die, die historisch zu Major Accidents geführt haben

Historische Großschäden — Tacoma Narrows (aerodynamisches Flattern), Hyatt Regency (Lastpfad-Änderung), Therac-25 (Software-Race-Condition), 737 MAX MCAS (emergentes Subsystem-Verhalten) — wurden nicht entdeckt, weil sie zum Zeitpunkt der Entwicklung in keiner verfügbaren Wissensbasis vorkamen. Eine KI, hätte es sie gegeben, hätte diese Fehler aus demselben Grund übersehen wie die menschlichen Teams — sie sind erst durch das Ereignis selbst in den Wissens-Korpus eingegangen.

Eine FMEA, die in den oberen Bedeutungsklassen wesentlich auf KI-Vollständigkeit vertraut, hat ein systematisches Sicherheits-Defizit. Das Team bekommt eine breite, glaubwürdig wirkende Liste — und genau diese Plausibilität ist das Problem. Sie senkt die kritische Aufmerksamkeit, die nötig ist, um nach dem zu suchen, was die Liste nicht enthält.

Methodisch belastbar ist nur die umgekehrte Reihenfolge:

Team erarbeitet Funktions-, Struktur- und Fehleranalyse auf Basis der Konstruktions- und Prozess-Kenntnis
KI wird als Vollständigkeits-Challenge eingesetzt: „Welche Fehler-Kategorien fehlen?“
Team prüft KI-Vorschläge gegen das konkrete Design, übernimmt mit Begründung oder verwirft mit Begründung
Bei B=10/B=9: explizite Dokumentation, welche Fehler-Kategorien das Team aus eigener Expertise ergänzt hat (das ist der unersetzliche Wertbeitrag)

Eine Auto-Approve-Funktion auf Maßnahmen-Ebene bei B=10/B=9 ist methodisch und produkthaftungsrechtlich nicht vertretbar. Die novellierte EU-Produkthaftungsrichtlinie 2024/2853 erfasst KI-Outputs ausdrücklich; die Beweislast verschiebt sich bei komplexen KI-Systemen zugunsten Geschädigter (Art. 9).

Klassifikation unter dem EU AI Act

Der AI Act unterscheidet vier Risikoklassen: unzulässig (Art. 5), Hochrisiko (Art. 6 + Anhänge I/III), begrenztes Risiko mit Transparenzpflicht (Art. 50), minimales Risiko (keine spezifischen Pflichten).

Klassische FMEA-Assistenz ist typischerweise nicht Hochrisiko

Eine KI, die FMEA-Moderator und -Team bei Funktions-, Fehler- und Maßnahmen-Analyse unterstützt, fällt im Standard-Fall nicht unter die Hochrisiko-Kategorien — die konkrete Klassifikation ist je Projekt zu prüfen:

Anhang I (Sektoral-Produkte mit Konformitätsbewertung) greift nur, wenn das KI-System selbst Sicherheitsbauteil eines Produkts wird — eine Maschine, ein Medizinprodukt, ein Fahrzeug. Ein FMEA-Werkzeug ist Entwicklungs-Werkzeug, nicht Bauteil. Es geht nicht mit dem Produkt zum Kunden.
Anhang III listet acht Anwendungsbereiche: Biometrie, kritische Infrastruktur, Bildung, Beschäftigung, essenzielle Dienste, Strafverfolgung, Migration, Justiz. Engineering-Methodik-Beratung ist in keiner dieser Listen enthalten.
Art. 6 Abs. 3 liefert zusätzlich eine Ausnahme auch innerhalb Anhang III, wenn das System eine eng begrenzte verfahrenstechnische Aufgabe erfüllt oder eine zuvor durch Menschen abgeschlossene Tätigkeit verbessert.

Praktische Pflichten für ein FMEA-KI-System bleiben damit:

Hinweis zu den Stichtagen: Der AI Omnibus IV (Trilog-Stand Mai 2026) verschiebt einige Anwendungsdaten. Die unten genannten Daten geben den Trilog-Stand wieder; falls der Omnibus-Kompromiss nicht final verabschiedet wird, gelten die Original-Daten aus VO 2024/1689 weiter. Für Compliance-Planung beide Zeitleisten parallel führen.

Pflicht	Rechtsgrundlage	Anwendbar seit/ab
AI Literacy für Personal (Moderatoren, Anwender)	Art. 4	02.02.2025
Chatbot-Offenlegung im UI	Art. 50 Abs. 1	02.08.2026
Watermarking/Labeling KI-generierter Inhalte	Art. 50 Abs. 2	Dezember 2026 (Trilog-Vorschlag, ursprünglich 02.08.2026)
Selbsteinschätzung Nicht-Hochrisiko dokumentieren	Art. 6 Abs. 4	bei Inverkehrbringen
DSGVO-Pflichten bei Verarbeitung personenbezogener Daten	DSGVO Art. 5 ff.	dauerhaft

Vier Prüffragen für die Einzelfall-Klassifikation

Prüffrage 1 — HR-Zweck-Erweiterung. Wird die FMEA-Logik im Anwendungsfall auf Personalbewertung übertragen (Mitarbeiter-Risiko, Bewerber-Auswahl, Performance-Prognose)? Falls ja, ist Anhang III Nr. 4 (Beschäftigung) zu prüfen. Klassische Produkt- und Prozess-FMEA ist davon typischerweise nicht erfasst.
Prüffrage 2 — Direkte Steuerung kritischer Infrastruktur. Fließen FMEA-Ergebnisse automatisch in Schalt-, Steuer- oder Abschalt-Aktionen einer kritischen Infrastruktur (Energie, Wasser, Verkehr, Telekommunikation)? Falls ja, ist Anhang III Nr. 2 zu prüfen.
Prüffrage 3 — Embedded-Sicherheitsbauteil. Ist die KI noch Entwicklungs-Werkzeug oder bereits Teil des entwickelten Produkts (z. B. selbstlernende Diagnose-Funktion in einer Maschine)? Im zweiten Fall ist Anhang I AI Act zu prüfen, derzeit mit doppelter Konformitätsbewertung. Im Omnibus-Trilog Mai 2026 wurde verhandelt, den Maschinen-Sektor aus der direkten AI-Act-Anwendung herauszulösen und über die Maschinenverordnung (VO 2023/1230) zu regeln — falls verabschiedet, würde das die Konformitätsbewertung vereinheitlichen. Aktuell ist beides parallel zu berücksichtigen (AI Act Anhang I ab 02.08.2027 anwendbar, Maschinenverordnung ab 14.01.2027).
Prüffrage 4 — Anbieter-Frage bei Re-Branding. Wird ein FMEA-Bot, der auf einem Foundation-Modell basiert, unter eigenem Markennamen weiterverteilt („OEM-X-GPT“, „FirmaName-KI“)? Falls ja, ist je nach konkreter Ausgestaltung (Branding-Tiefe, Vertragsgestaltung, Funktionsumfang) zu prüfen, ob nach Art. 25 Abs. 1 lit. a AI Act eine Einstufung als Anbieter iSv Art. 3 Nr. 3 in Betracht kommt. Eine Einzelfallprüfung ist regelmäßig nötig; die Auslegungs-Praxis ist 2026 noch in Entwicklung. Praktische Empfehlung der Draft Guidelines: Fantasie-Namen verwenden („FaultFinder“, „RiskHelper“) — der Bot bleibt damit erkennbar ein Dritt-Modell. Anwaltliche Begleitung bei nicht-trivialen Re-Branding-Konstellationen empfohlen.

Hinweis: DSGVO und CLOUD Act bei großen LLM-Anbietern

Eine häufige Vereinfachung: „Anbieter X ist DSGVO-konform, weil EU-US Data Privacy Framework (DPF) oder Standardvertragsklauseln (SCC).“ Das deckt den vertraglichen Aspekt — den Auftragsverarbeitungs-Vertrag (AVV) nach Art. 28 DSGVO und den Drittland-Transfer nach Art. 46 DSGVO. Es entschärft den CLOUD-Act-Konflikt allerdings nicht vollständig: Der US-Anbieter bleibt im Zweifel auskunftspflichtig gegenüber US-Behörden.

Der CLOUD Act (Clarifying Lawful Overseas Use of Data Act, USA 2018) verpflichtet US-Unternehmen, weltweit gespeicherte Daten auf Anforderung einer US-Behörde bereitzustellen — unabhängig vom Speicherort. Wer auf einen US-Cloud-Anbieter setzt, dessen Daten können Behörden auch dann beschafft werden, wenn sie auf Servern in der EU liegen. DPF und SCCs ändern daran nichts.

Der EDPB hat in den Recommendations 01/2020 kundenseitige Verschlüsselung mit ausschließlich im EWR verwalteten Schlüsseln als die wirksame Zusatzmaßnahme identifiziert. Standard-Cloud-Verschlüsselung, bei der der Anbieter die Schlüssel verwaltet, erfüllt diesen Standard nicht — der Anbieter hat technischen Zugriff auf den Klartext und bleibt CLOUD-Act-pflichtig.

Zweistufige Frage bei Tool-Setup-Anbietern

Bei Plattform-Anbietern wie meinGPT*, Langdock, TextCortex oder Open-Source-Lösungen wie Open WebUI / AnythingLLM / Onyx ist die CLOUD-Act-Frage zweistufig. Die Plattform-Wahl allein entscheidet nicht — die LLM-Auswahl entscheidet mit.

Plattform-Schicht (Frontend, RAG-Logik, Workflow-Engine, eigener Speicher, Authentifizierung, eigene Knowledge-Base) — sitzt bei meinGPT/Langdock/TextCortex in Deutschland, bei Open-Source-Lösungen wahlfrei wo gehostet. Kein CLOUD Act, wenn EU-gehostet von EU-Anbieter betrieben.
LLM-Schicht (der eigentliche Modell-Aufruf) — hängt davon ab, welches LLM der Nutzer im Tool auswählt:
- EU-LLMs (Mistral, Aleph Alpha Luminous, lokale Open-Source-Modelle via Ollama/vLLM) → kein CLOUD Act, voll souverän
- US-LLMs (Anthropic Claude, OpenAI GPT, Google Gemini) → CLOUD Act gilt für die LLM-Verarbeitung, selbst wenn die Plattform in DE/EU sitzt

meinGPT löst das über vier Privacy Levels als sichtbare Wahl im UI: Level 1 schaltet ausschließlich EU-LLMs frei, höhere Levels öffnen US-Backends mit Auftragsverarbeitung. Langdock (Berlin) bietet ähnliche Modi mit getrennten Workspaces, je nachdem ob auch GPT/Claude erlaubt sein soll. Bei Open-Source-Plattformen ist das eine Frage der Provider-Whitelist und der Default-Konfiguration für die Endanwender.

Konsequenz: Wer das CLOUD-Act-Risiko möglichst gering halten möchte, kombiniert eine EU-Plattform mit einer EU-LLM-Auswahl (oder einem lokalen Modell). Wer Cloud-Vorteile bei der LLM-Wahl mitnehmen will (z. B. die starke Claude-/GPT-Reasoning-Performance bei niedriger Datensensitivität), bleibt formal über DPA/SCC abgesichert, übernimmt aber für die LLM-Strecke das Restrisiko aus dem CLOUD-Act-Mechanismus. Eine vollständige Eliminierung des Risikos durch vertragliche Mittel ist nach heutigem Verständnis nicht möglich; technische Zusatzmaßnahmen (Pseudonymisierung, kundenseitige Verschlüsselung mit EWR-Schlüsseln) reduzieren den Hebel. Die in der Tabelle unten gezeigten Anbieter-Zeilen für meinGPT / Aleph Alpha / Mistral beziehen sich auf die Plattform-Schicht. Bei meinGPT/Langdock wird die zweite Schicht durch die LLM-Auswahl entschieden.

Anbieter-Vergleich (Stand Mai 2026)

Anbieter	Sitz	AVV/SCC vorhanden	CLOUD Act anwendbar	EU-Daten-Residency möglich	Für sensible FMEA-Daten geeignet
Anthropic (Claude)	USA (Kalifornien)	DPA mit SCCs Module 1/2/3, ab Tier Team und API automatisch	Ja (US-Konzern)	EU-Residency-Flag möglich (Direct-API), AWS Bedrock Frankfurt/Dublin/Paris	Maschinenbau-Standard: ja mit Pseudonymisierung. Med/Defence: nein.
OpenAI (ChatGPT, GPT-4/5)	USA (San Francisco)	DPA mit SCCs, Enterprise und API ab Business-Tier	Ja (US-Konzern)	EU Data Residency Enterprise-Tier seit 2024	Wie Anthropic. Free/Plus-Tier: nein (kein DPA).
Google Gemini / Vertex AI	USA (Mountain View)	Cloud DPA mit SCCs, Workspace-/Cloud-Kunden	Ja (US-Konzern)	EU-Regionen (Frankfurt, Dublin) wählbar	Wie oben. Privates Gemini im Google-Account: nein.
Microsoft (Azure OpenAI, M365 Copilot)	USA (Redmond)	OST + DPA, EU Data Boundary seit 2024 für M365	Ja (US-Konzern)	EU Data Boundary umfassend; Claude-Integration in M365 Copilot ab Januar 2026 explizit ausgenommen	EU Data Boundary mildert, eliminiert CLOUD Act nicht. Pseudonymisierung empfohlen.
meinGPT* (selectcode GmbH)	Deutschland (München)	AVV nach Art. 28 DSGVO, kostenfrei in 2–3 Werktagen	Plattform: Nein. LLM-Schicht: abhängig von Privacy Level (Level 1 nur EU-LLMs → kein CLOUD Act; höhere Levels mit US-LLM → CLOUD Act für LLM-Strecke)	Hosting bei Hetzner in Deutschland, ISO 27001; LLM-Wahl steuerbar	Ja — auch für sensible Daten, wenn Privacy Level 1 (EU-LLMs) gewählt wird
Aleph Alpha (Luminous)	Deutschland (Heidelberg)	AVV nach Art. 28 DSGVO	Nein	EU-Hosting, on-premise möglich	Ja — souverän, auch für regulierte Branchen
Mistral La Plateforme	Frankreich (Paris)	AVV/SCC, EU-Unternehmen	Nein	EU-Region default	Ja — souverän, gute Modelle

Konsequenzen für FMEA-Datenkategorien

Personendaten der FMEA-Team-Mitglieder (Name, Jobtitel, Abteilung) — klassisch personenbezogen, Risiko-Profil niedrig bis mittel. Pseudonymisierung vor Prompt entschärft den CLOUD-Act-Punkt für diese Kategorie weitgehend.
FMEA-Inhalt selbst — meist Kundengeheimnis (NDA), selten Personenbezug. NDA-Vertraglich ist die wichtigere Frage als DSGVO. Wenn der OEM kein US-Cloud-Verbot im Lastenheft hat, ist die Standard-Konstellation EU-Cloud + AVV vertretbar — mit Pseudonymisierung als technischer Verstärkung.
Medizinprodukt-FMEA — sensible Daten möglich (Patientenklassen, klinische Bezüge). EU-souveräner Anbieter dringend empfohlen.
Defence-FMEA — Verschlusssachen, Exportkontrolle. Cloud-LLM faktisch ausgeschlossen, unabhängig vom Anbieter. On-premise mit lokalem Modell ist die einzige Option.

Drei praktische Empfehlungen für die meisten Mittelstand-FMEAs:

AVV-Kette dokumentieren bis zum Foundation-Model-Anbieter. Wer meinGPT* nutzt, hat AVV mit selectcode (Deutschland); selectcode hat DPA mit dem Foundation-Model-Anbieter — die Kette ist geschlossen.
Transfer Impact Assessment (TIA) für die US-Strecke bei Anthropic/OpenAI/Google/Microsoft. Ehrliche Frage: Sind die konkreten FMEA-Inhalte so sensibel, dass CLOUD-Act-Zugriff ein realistisches Schadensszenario ist? Für Maschinenbau-Standard meist nein. Für Med/Defence ja.
Pseudonymisierung als technische Lösung. Wenn der Prompt nur „Konstrukteur_A“ statt „Weber Klaus“ enthält, ist das CLOUD-Act-Problem für Personen-Kategorien weitgehend entschärft. Die Auflösung erfolgt erst im DB-Insert im eigenen, EU-gehosteten Kontext.

Medizintechnik-FMEA: Doppelregime mit Aussicht auf Vereinfachung

FMEA ist in der Medizintechnik integraler Bestandteil des Risikomanagements nach ISO 14971 und der Medizinprodukteverordnung (MDR, VO 2017/745). Software als Medizinprodukt (SaMD) wird in Risikoklassen IIa bis III eingestuft; KI-Funktionalität tendiert systematisch zu höheren Klassen.

Die Doppelregulierung MDR + AI Act ist nach aktuellem Stand bis voraussichtlich August 2027 die Realität. Die Bertelsmann-Studie 2025 weist auf eine fachliche Schwachstelle hin: Die AI-Act-Metrik „Accuracy“ ist in medizinischer Diagnostik irreführend — entscheidend sind klinische Endpunkte aus der MDR-Bewertung, nicht statistische Treffergenauigkeit. Im Trilog Mai 2026 ist ein separates MDR-Update angedeutet, das Medizinprodukte aus der direkten AI-Act-Anwendung herauslösen würde (Pushback aus dem Europäischen Parlament wird erwartet). Stand 26.05.2026 ist das nicht final beschlossen — Original-Doppelregulierung gilt weiter, bis Trilog-Kompromiss ratifiziert ist.

Für FMEA-Moderatoren im Medizintechnik-Kontext: Patienten-Sicherheit liegt nahezu durchgängig bei B=10. Hier verschärft sich die epistemische Falle: Eine KI-erweiterte FMEA an einem neuartigen Medizinprodukt kann genau jene Subpopulationen-Risiken übersehen, die in den Trainingsdaten unterrepräsentiert waren.

KI-Vorschläge zur Fehlermöglichkeit explizit als „KI-generiert“ kennzeichnen und im FMEA-Audit-Trail führen
Bei B=10 zwingende Team-Diskussion jeder KI-vorgeschlagenen Risikobewertung
Klinische Bewertung (MDR) und KI-Robustheit (AI Act Art. 15) als verbundene Nachweise führen
Subpopulationen-Bias der Trainingsdaten kritisch hinterfragen

Defence-FMEA: Sonderregime und Vertraulichkeits-Konflikt

Art. 2 Abs. 3 AI Act nimmt KI-Systeme aus, die ausschließlich für militärische Zwecke, Verteidigung oder nationale Sicherheit entwickelt oder in Verkehr gebracht werden. Eine reine Defence-FMEA an einem militärischen Produkt fällt damit formal nicht unter den AI Act.

Diese Ausnahme ist eng zu lesen. Drei praktische Vorbehalte:

Dual-Use-Produkte — typisch bei Sensorik, Kommunikation, Antrieben, autonomen Plattformen. Die Ausnahme greift nur für militärische Anteile. Trennung sauber dokumentieren.
DSGVO bleibt anwendbar — Personendaten im FMEA-Team unterliegen weiterhin der DSGVO. Die Defence-Ausnahme ist sektoral KI-spezifisch, nicht datenschutzrechtlich umfassend.
Vertraulichkeits-Konflikt mit Cloud-KI. Defence-Projekte unterliegen typisch Verschlusssachen-Klassifikationen (GEHEIM, VS-NfD, NATO RESTRICTED), Exportkontrolle (BAFA, ITAR/EAR bei US-Anteilen). Cloud-LLM-APIs sind für solche Daten in aller Regel unzulässig — unabhängig vom AI-Act-Status.

KI-Assistenz in Defence-FMEAs erfordert daher:

Strikt on-premise-Betrieb des Sprachmodells (lokales LLM auf isolierter Hardware, keine externe API)
Modell-Auswahl mit klarer Herkunft und Trainingsdaten-Transparenz — Open-Source-Modelle mit dokumentierter Trainingsbasis sind oft die einzige praktikable Option
Strikte Air-Gapping des FMEA-Tool-Stack gegenüber dem Unternehmens-Internet
Klare Trennung der Wissensbasen — keine Vermischung von Verschlusssachen mit kommerziellem RAG-Inhalt
Klärung mit dem Auftraggeber (BAAINBw, Bundeswehr, OEM mit Defence-Zulieferung), welche KI-Unterstützung im Lastenheft zulässig ist

NATO STANAG-Standards (STANAG 4404, STANAG 4174 etc.) haben eigene FMEA- und Sicherheitsanalysen-Vorgaben, die unabhängig vom EU-Recht zu beachten sind und im Zweifel restriktiver wirken.

Praktische Konsequenzen für die drei Adressaten

Für FMEA-Moderatoren

Die berufliche Rolle wird durch KI nicht abgewertet, sondern in ihrem Kern bestätigt. Die Moderator-Verantwortung — Team führen, kritisch hinterfragen, Konsens dokumentieren, methodische Disziplin sichern — ist die Stelle, an der das EU-Recht die Hochrisiko-Schwelle festschreibt. Bei B=10/B=9 ist die KI-Vollständigkeitsfalle die größte praktische Sicherheitsbedrohung.

Operative Empfehlung: KI-Vorschläge im FMEA-Tool als solche markieren, Team-Entscheidungen separat dokumentieren, AI-Literacy-Schulung für das Team gemäß Art. 4 AI Act (seit 02.02.2025 verpflichtend).

Für Anwender (Konstrukteure, Qualitäter, Projektleiter)

KI-Output ist Diskussions-Material wie ein Lieferanten-Vorschlag — fachlich zu prüfen, nicht zu übernehmen. Halluzinations-Risiko ist real; insbesondere bei vermeintlichen Referenzen auf Normen, technische Daten und „typische Fehler“ ist Quellen-Prüfung Pflicht. Wer auf KI-Vorschläge mit Sicherheits-Bezug ohne eigene fachliche Prüfung vertraut, übernimmt das Haftungsrisiko persönlich.

Operative Empfehlung: Wenn eine KI eine Fehlerursache vorschlägt, prüfen ob sie physikalisch oder prozesstechnisch begründbar ist, ob sie in den verfügbaren Konstruktions-/Prozess-Unterlagen anzeigbar ist, und ob sie zu den anderen Fehlerursachen konsistent ist.

Für Kunden und Beschaffung

Wer KI-FMEA-Leistung einkauft oder seinen Lieferanten erlaubt, muss klären: welche KI, welche Datenflüsse, welche Vertraulichkeits-Stufen, welche Trainings-Datenbasis. Die Auftraggeber-Rolle entscheidet, ob KI-FMEA im Projektkontext überhaupt zulässig ist (Defence: meist nein, Medizintechnik: mit MDR-Audit-Trail, Maschinenbau Standard: in der Regel ja).

Konkreter Risikopunkt: Wer einem Lieferanten erlaubt, einen extern gebrandeten KI-Bot unter eigenem Namen einzusetzen, schiebt dem Lieferanten unbeabsichtigt die Anbieter-Haftung nach Art. 25 zu — was den Lieferanten zur Ablehnung des Auftrags zwingen kann.

Operative Empfehlung: Im Lastenheft KI-Einsatz, Datenfluss, On-Premise-Anforderung und Audit-Trail explizit regeln. AVV-Kette bis zum Foundation-Model-Anbieter dokumentieren lassen. Bei Medizintechnik die Benannte Stelle frühzeitig zu KI-Einsatz im Risikomanagement befragen.

Zusammenfassende Übersicht: Hochrisiko-Klassifikation FMEA-KI

Anwendungskontext	AI-Act-Klassifikation	Begründung
Klassische D-/P-FMEA Maschinenbau, KI als Vorschlags-Generator, Team entscheidet	Minimal-Risiko + Art. 50 Transparenz	Methodik-Beratung, nicht in Anhang III, Mensch-vor-KI erfüllt
FMEA für Maschinen mit KI-Sicherheitsbauteil im Produkt	Anhang I via Maschinenverordnung 2023/1230	Nach Trilog Mai 2026 in MV statt AI Act direkt geregelt
Medizinprodukt-FMEA, KI als Methodik-Hilfe	Minimal-Risiko + Art. 50, aber MDR voll anwendbar	KI ist Werkzeug, Produkt unter MDR mit ISO 14971
Medizinprodukt mit KI-Funktion im Produkt	Anhang I A AI Act + MDR bis vsl. 2027, danach MDR-only	Doppelte Konformitätsbewertung
FMEA für kritische Infrastruktur mit direkter Steuer-Aktion	Anhang III Nr. 2 (Hochrisiko)	KI in Sicherheitsentscheidung der Infrastruktur
FMEA-ähnliches Tool im HR-Kontext (Personal-Risikobewertung)	Anhang III Nr. 4 (Hochrisiko)	Beschäftigungs-Bewertung
Defence-FMEA	Art. 2 Abs. 3 ausgenommen	Aber: Exportkontrolle + Vertraulichkeit machen Cloud-KI faktisch unzulässig
Auto-Akzeptanz von Maßnahmen bei B=10/B=9 ohne Review	unabhängig von AI-Act: produkthaftungsrechtlich problematisch	PLD 2024/2853 Art. 7+9

Quellen und Stand

Verordnung (EU) 2024/1689 (AI Act), EUR-Lex L 202401689 vom 12.07.2024
Verordnung (EU) 2016/679 (DSGVO)
Verordnung (EU) 2017/745 (MDR)
Verordnung (EU) 2023/1230 (Maschinenverordnung, anwendbar ab 14.01.2027)
Verordnung (EU) 2024/2853 (überarbeitete Produkthaftungsrichtlinie)
ISO 14971 (Risikomanagement Medizinprodukte)
AIAG/VDA FMEA Handbook 2019
EU-Kommissions-Draft-Guidelines zu Art. 50 (Transparenz) vom 08.05.2026
EU-Kommissions-Draft-Guidelines zu Art. 6 + Anhang III (Hochrisiko) vom 19.05.2026
Hacker/Kilian/Costas, Simplifying European AI Regulation, Bertelsmann-Studie 2025
Trilog-Stand AI Omnibus (Digital Omnibus IV), Mai 2026 — nicht final verabschiedet
AI-Haftungsrichtlinie 2022 — von der Kommission 2025 zurückgezogen
EDPB Recommendations 01/2020 zu ergänzenden Maßnahmen für Drittland-Transfers
CLOUD Act (Clarifying Lawful Overseas Use of Data Act, USA 2018)
EuG Urteil vom 03.09.2025 zur Klage Latombe gegen DPF (DPF bestätigt)

Der Beitrag spiegelt den Stand Mai 2026. Die EU-Verhandlungen zum AI Omnibus IV sind nicht abgeschlossen; einzelne Anwendungsdaten (Anhang III, Watermarking) können sich noch verschieben. Für konkrete Compliance-Entscheidungen ist eine aktuelle Prüfung — und bei nicht-trivialen Fällen anwaltliche Begleitung mit Schwerpunkt AI Act / DSGVO — angebracht.

Nächster Schritt

Erstgespräch — kostenfrei, 30 Minuten, sortiert deine konkrete Situation (welcher Produktkontext, welche Datenflüsse, welcher Adressat). Kontaktformular.
Pillar vertiefen — der breitere Zusammenhang im Engineering-Betriebssystem für FMEA und KI.
Frontend-Wahl — wenn du gerade über den Anbieter entscheidest: Frontend-Optionen: meinGPT, Open WebUI, Copilot Studio.
Wissens-Konservierung — wenn der Anlass ein Rentner-Effekt ist: Engineering-Wissen konservieren.

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.

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