Produkthaftung, CRA, Maschinenverordnung und AI Act: Marktzugang und Haftung auseinanderhalten

Problem in der Praxis

In Compliance-Programmen wird die Produkthaftung gern als Anhängsel der Konformitätsarbeit behandelt: Das CRA-Programm läuft, die CE-Kennzeichnung kommt, also sei auch die Haftungsseite erledigt. Umgekehrt erwarten manche Teams im Text der Produkthaftungsrichtlinie eine saubere Verweiskette auf CRA und Maschinenverordnung und wundern sich, dass sie fehlt.

Beides führt in die Irre. Wer Konformität mit Haftungsfreiheit verwechselt, übersieht, dass die Fehlerhaftigkeit an der berechtigten Sicherheitserwartung hängt und nicht am CE-Zeichen. Wer die fehlende Verweiskette als fehlende Relevanz liest, übersieht, dass Verstöße gegen verbindliche Anforderungen im Haftungsprozess als Vermutungsauslöser wirken. Und wer im Haus zwei Programme ohne gemeinsame Datenbasis führt, Konformität bei Regulatory Affairs und Haftung bei Legal, bezahlt doppelt und übersieht die Wechselwirkungen an den Nahtstellen.

CISO-Einordnung

Was die Richtlinie selbst sagt und was nicht. Am verifizierten Volltext gilt: Die Produkthaftungsrichtlinie nennt weder den Cyber Resilience Act noch die Maschinenverordnung noch NIS2 (Negativbefund per Volltextsuche); der AI Act (Verordnung (EU) 2024/1689) erscheint namentlich an genau einer Stelle, in Erwägungsgrund 13, der Anbieter von KI-Systemen als Hersteller einordnet. Die Richtlinie definiert auch keine einzige technische Sicherheitsanforderung. Stattdessen importiert sie das Produktsicherheitsrecht an zwei Stellen als Maßstab: Bei der Beurteilung der Fehlerhaftigkeit sind die einschlägigen Anforderungen an die Produktsicherheit einschließlich sicherheitsrelevanter Cybersicherheitsanforderungen zu berücksichtigen (Art. 7 Abs. 2 Buchst. f), und der nachgewiesene Verstoß gegen verbindliche Produktsicherheitsanforderungen, die gerade vor dem eingetretenen Schadensrisiko schützen sollen, löst die Vermutung der Fehlerhaftigkeit aus (Art. 10 Abs. 2 Buchst. b).

Dieser Artikel beschreibt damit ein Verhältnis, das die Richtlinie selbst nicht ausformuliert. Dass CRA- oder Maschinenverordnungs-Anforderungen "einschlägige sicherheitsrelevante Cybersicherheitsanforderungen" oder "verbindliche Produktsicherheitsanforderungen" in diesem Sinne sind, ist Ergebnis der Auslegung dieser Merkmale im Einzelfall, kein Zitat aus der Richtlinie. Für die Planung ist diese Unterscheidung wichtig: Belastbar ist die Systematik (das Marktzugangsrecht liefert den Maßstab, das Haftungsrecht die Folgen), nicht eine angebliche Verweisnorm, die bei der ersten juristischen Prüfung zerfällt.

Die Arbeitsteilung im Überblick:

• CRA (Verordnung (EU) 2024/2847): horizontale Cybersicherheitsanforderungen für Produkte mit digitalen Elementen, Schwachstellenbehandlung, Supportzeitraum, Meldepflichten, CE-Kennzeichnung (Grundzüge und Fristen im cra-Track). Aus Haftungssicht der wichtigste Kandidat für den Fehlermaßstab nach Art. 7 Abs. 2 Buchst. f und die Vermutung nach Art. 10 Abs. 2 Buchst. b.
• Maschinenverordnung (Verordnung (EU) 2023/1230): Maschinen-Produktrecht mit Sicherheitsanforderungen und Konformitätsbewertung (Grundzüge im mvo-Track). Beide Regime kennen die Figur der wesentlichen Veränderung, aber mit je eigener Definition und Rechtsfolge: Produktrechtlich löst sie Konformitätspflichten aus (im Maschinenkontext mvo-005), haftungsrechtlich macht sie den Verändernden zum Hersteller (Art. 4 Nr. 18, Art. 8 Abs. 2) und startet die Ausschlussfrist neu (Art. 17 Abs. 1 Buchst. b; vertieft in pld-003).
• AI Act (Verordnung (EU) 2024/1689): Anforderungen an KI-Systeme nach Risikoklassen (Grundzüge im ai-governance-Track). Haftungsseitig stellt Erwägungsgrund 13 klar, dass Anbieter von KI-Systemen Hersteller im Sinne der Produkthaftung sind, also verschuldensunabhängig haften. Die Fähigkeit eines Produkts, nach dem Inverkehrbringen weiterzulernen, ist Umstand der Fehlerbeurteilung (Art. 7 Abs. 2 Buchst. c), und eine wesentliche Änderung kann auch durch kontinuierliches Lernen eintreten (Erwägungsgrund 40).
• RED (Richtlinie 2014/53/EU mit Delegierter Verordnung (EU) 2022/30): Cybersicherheitsanforderungen für Funkanlagen (Grundzüge im red-Track). Auch hier gilt: verbindliche Anforderungen können im Haftungsprozess als Maßstab und Vermutungsauslöser wirken.
• NIS2 (Richtlinie (EU) 2022/2555): organisationsbezogene Pflichten für Einrichtungen, kein Produktrecht; die Produkthaftungsrichtlinie nennt NIS2 nirgends. Die Betroffenheit als NIS2-Einrichtung und die Haftung als Hersteller sind getrennt zu prüfen und nicht ineinander umrechenbar.

Dass die Richtlinie das Produktsicherheitsrecht als Nachbarsystem voraussetzt, zeigt sich daran, dass die allgemeine Produktsicherheitsverordnung (GPSR, Verordnung (EU) 2023/988) in den Erwägungsgründen referenziert wird (unter anderem Erwägungsgrund 37 zum Zusammenspiel mit Produktsicherheits- und Marktüberwachungsrecht). Die einzelnen Security-Rechtsakte zählt sie dagegen nicht auf; genau deshalb bleibt ihre Einordnung Auslegungsarbeit.

Konformität schützt nicht automatisch. Fehlerhaft ist ein Produkt, wenn es nicht die Sicherheit bietet, die eine Person erwarten darf oder die nach Unionsrecht oder nationalem Recht vorgeschrieben ist (Art. 7 Abs. 1). Die berechtigte Sicherheitserwartung ist ein eigenständiger Maßstab neben den vorgeschriebenen Anforderungen; ein Produkt kann alle Marktzugangsanforderungen erfüllen und trotzdem fehlerhaft sein. Umgekehrt macht ein Konformitätsverstoß das Produkt nicht automatisch haftungsauslösend: Die Vermutung nach Art. 10 Abs. 2 Buchst. b setzt voraus, dass die verletzte Anforderung gerade vor dem Risiko des eingetretenen Schadens schützen soll, und sie bleibt widerleglich. Sie verschiebt aber die Beweislast, und das ist im Prozess oft entscheidend.

Unberührt bleiben schließlich andere Anspruchsgrundlagen: Die Richtlinie lässt vertragliche Ansprüche und außervertragliche Haftung aus anderen Gründen als der Fehlerhaftigkeit ebenso unberührt wie das Datenschutzrecht (Art. 2 Abs. 4). Die Produkthaftung ist ein zusätzlicher Kanal, nicht der einzige.

Umsetzungsperspektive

• Ein Datenbestand, zwei Sichten: Dieselben Artefakte (Risikoanalysen, Konformitätsnachweise, Schwachstellen- und Update-Historie, technische Dokumentation) tragen die Konformitätsarbeit und sind zugleich das Beweismaterial der Haftungsseite (vertieft in pld-004). Wer sie doppelt führt, erzeugt Widersprüche; wer sie einmal sauber führt, bedient beide Schichten.
• Anforderungslandkarte je Produkt: festhalten, welche verbindlichen Anforderungen für jedes Produkt gelten (CRA, Maschinenverordnung, RED, AI Act, sektorales Recht; Inhalte in den Nachbar-Tracks). Nicht um sie hier zu erklären, sondern weil ihre Verletzung die teuerste Beweisposition erzeugt.
• Haftungsperspektive in Konformitätsentscheidungen einziehen: Abweichungen, Ausnahmen und Risikoakzeptanzen auf der Marktzugangsseite sind auf der Haftungsseite potenzielle Vermutungsauslöser oder Beweisnachteile. Solche Entscheidungen brauchen eine Governance-Schleife zwischen Regulatory, Security und Legal.
• KI-Produkte doppelt einordnen: Die Rollen nach AI Act betreffen den Marktzugang; für die Haftung zählt die Herstellerrolle nach der Produkthaftungsrichtlinie. Lernverhalten und funktionale Änderungen nach dem Inverkehrbringen gehören dokumentiert, weil sie in Fehlerbeurteilung und Fristenlauf eingehen.
• Rollen klären: Wer verantwortet Marktzugang, wer Haftungsvorsorge, und wo ist die definierte Schnittstelle? Ohne benannte Zuständigkeit fällt die Haftungsseite zwischen Regulatory und Legal durch.

Typische Fehler

1. CE-Kennzeichnung oder ein bestandenes Konformitätsverfahren wird intern als Haftungsschutz kommuniziert; die berechtigte Sicherheitserwartung bleibt aber eigenständiger Fehlermaßstab.
2. In Schulungen oder Vorlagen wird behauptet, die Produkthaftungsrichtlinie "verweise" auf CRA oder Maschinenverordnung; die angebliche Fundstelle existiert nicht, und die Argumentation bricht bei der ersten Prüfung.
3. Konformitäts- und Haftungsdokumentation laufen getrennt und widersprechen sich in Details; im Prozess fällt genau das auf.
4. NIS2-Compliance der eigenen Organisation wird mit Produkthaftungsvorsorge verwechselt, obwohl NIS2 organisationsbezogen ist und in der Richtlinie nicht vorkommt.
5. Bei KI-Systemen wird die Herstellerrolle nach der Produkthaftung übersehen, weil sich das Unternehmen nur als Anbieter nach AI Act einordnet.
6. Die wesentliche Veränderung wird nur produktrechtlich geprüft; ihre haftungsrechtliche Parallelwirkung (Herstellerrolle, Fristneustart) bleibt unbeachtet.

Risiken und Trade-offs

Der erste Trade-off liegt zwischen Integration und Trennschärfe. Werden Konformitäts- und Haftungsprogramm zu eng verschmolzen, entsteht der Eindruck, das eine erledige das andere, und genau die Pflichten ohne Gegenstück bleiben liegen. Werden sie zu getrennt geführt, entstehen doppelte Dokumentation und Widersprüche zwischen den Strängen, die im Offenlegungsfall teuer werden.

Der zweite ist das Auslegungsrisiko. Weil die Richtlinie die Verzahnung nicht ausformuliert, bleibt im Einzelfall offen, welche Anforderung "verbindlich" ist und "gerade vor dem eingetretenen Schadensrisiko schützen soll"; das werden erst Gerichte klären. Planung sollte sich auf die Systematik stützen und Puffer für Auslegungsunsicherheit lassen, statt auf scheinbar exakte Verweisketten zu bauen.

Drittens laufen die Zeitachsen auseinander. Die Haftungsseite greift für Produkte, die ab dem 9. Dezember 2026 in Verkehr gebracht oder in Betrieb genommen werden (Art. 2 Abs. 1 in der Fassung der Berichtigung ABl. L, 2026/90364 vom 07.05.2026); die Stichtage von CRA, Maschinenverordnung und RED laufen davon unabhängig (Termine in den Nachbar-Tracks). Ein Produkt kann also in das neue Haftungsregime fallen, bevor einzelne Marktzugangspflichten für es voll anwendbar sind, und umgekehrt. Wer beide Achsen in einen einzigen Plan zwingt, übersieht solche Zwischenzustände.

Entscheidungspunkte

• Führen wir Konformitäts- und Haftungsvorsorge als zwei Sichten auf einen gemeinsamen Datenbestand, und wer verantwortet die Schnittstelle?
• Welche verbindlichen Sicherheitsanforderungen gelten je Produkt, und wie schnell könnten wir im Streitfall belegen, dass sie eingehalten wurden?
• Wie stellen wir sicher, dass Aussagen zur Produktsicherheit in Dokumentation, Werbung und Advisories zur Konformitätslage passen, damit im Prozess keine Widersprüche entstehen?
• Sind KI-Produkte sowohl in den AI-Act-Rollen als auch in der Herstellerrolle nach der Produkthaftung erfasst?
• Wer beobachtet, wie Gerichte und Aufsicht die Merkmale "verbindlich" und "Schutzzweck" konkretisieren, und wie fließt das in unsere Prioritäten ein?

Praktische Empfehlungen

1. Behandeln Sie Marktzugang und Haftung als zwei Rechtsschichten mit eigener Logik: Konformität ist Zugangsbedingung, Haftungsvorsorge ist Beweis- und Schadensvorsorge. Planen Sie beide; keine ersetzt die andere.
2. Formulieren Sie intern präzise: Die Produkthaftungsrichtlinie verweist nicht auf CRA, Maschinenverordnung oder NIS2, sondern knüpft abstrakt an verbindliche Sicherheitsanforderungen an. Streichen Sie erfundene Fundstellen aus Schulungen und Vorlagen.
3. Bauen Sie je Produkt eine Landkarte der verbindlichen Anforderungen (Inhalte in den Nachbar-Tracks) und behandeln Sie Lücken dort als prioritäre Haftungsrisiken, weil sie die Fehlerhaftigkeitsvermutung auslösen können.
4. Nutzen Sie die vorhandene Konformitätsdokumentation als Grundlage der Beweisvorsorge und halten Sie beide Stränge widerspruchsfrei (vertieft in pld-004).
5. Ordnen Sie KI-Systeme doppelt ein: AI-Act-Rollen für den Marktzugang, Herstellerrolle nach der Produkthaftungsrichtlinie für die Haftung; dokumentieren Sie Lernverhalten und Änderungen nach dem Inverkehrbringen.
6. Prüfen Sie wesentliche Veränderungen immer in beiden Welten: produktrechtliche Folgen (Nachbar-Tracks) und haftungsrechtliche Folgen (Herstellerrolle, Fristneustart; vertieft in pld-003).

Relevante Normreferenzen

• Richtlinie (EU) 2024/2853 (neue Produkthaftungsrichtlinie), ABl. L, 2024/2853, 18.11.2024, berichtigt durch Berichtigung ABl. L, 2026/90364 vom 07.05.2026: Fehlermaßstab (Art. 7), Vermutungen (Art. 10), wesentliche Änderung (Art. 4 Nr. 18, Art. 8 Abs. 2, Art. 17 Abs. 1 Buchst. b), KI-Anbieter als Hersteller (Erwägungsgrund 13). Nennt CRA, Maschinenverordnung und NIS2 an keiner Stelle (Negativbefund am Volltext, Stand 03.08.2026).
• Cyber Resilience Act (Verordnung (EU) 2024/2847): Cybersicherheits-Marktzugangsrecht für Produkte mit digitalen Elementen; Inhalte und Fristen im cra-Track.
• Maschinenverordnung (Verordnung (EU) 2023/1230): Maschinen-Produktrecht; Inhalte im mvo-Track, wesentliche Veränderung im Maschinenkontext in mvo-005.
• AI Act (Verordnung (EU) 2024/1689): KI-Marktzugangsrecht; Inhalte im ai-governance-Track.
• RED (Richtlinie 2014/53/EU) mit Delegierter Verordnung (EU) 2022/30: Funkanlagen-Cybersicherheit; Inhalte im red-Track.
• NIS2 (Richtlinie (EU) 2022/2555): organisationsbezogene Pflichten; von der Produkthaftungsrichtlinie nicht genannt.
• Produktsicherheitsverordnung GPSR (Verordnung (EU) 2023/988): in den Erwägungsgründen der Produkthaftungsrichtlinie referenziert (unter anderem Erwägungsgrund 37).