Die neue Produkthaftung im Kontext
von KI und digitalen Produkten

Mit der neuen EU-Produkthaftungsrichtlinie und dem Regierungsentwurf zu ihrer deutschen Umsetzung (ProdHaftG-E) verschiebt sich die Haftungslandschaft für Software und KI-Systeme spürbar. Wer heute derart digitale Produkte entwickelt, vertreibt oder in eigene Angebote integriert, sollte die Verzahnung mit dem Cyber Resilience Act (CRA) und der KI-Verordnung (KI-VO) kennen. Denn beide Regelwerke definieren künftig mit, wann ein Produkt als fehlerhaft gilt.

Einführung

Das Produkthaftungsrecht wird durch die neue Produkthaftungsrichtlinie (kurz „Richtlinie“) auf Ebene der Europäischen Union umfangreich modernisiert. Das hat auch das Bundesministerium der Justiz (BMJ) veranlasst, im September 2025 einen ersten Referentenentwurf zu erarbeiten, der seit Dezember 2025 als Regierungsentwurf (BT-Drs. 21/4297) vorliegt (kurz „ProdHaftG-E“). Die darin enthaltenen Änderungen sollen spätestens ab dem 09.12.2026 gelten und das bisherige Produkthaftungsgesetz ablösen.

Diese erste Modernisierung seit 1989 erweitert kurz zusammengefasst die Haftung auf digitale Produkte, insbesondere Software- und KI-Systeme, erschwert den Haftungsausschluss und erleichtert bei Geltendmachung von Haftungsansprüchen die Beweisführung (für weitere Details siehe auch Überblick über die Reform der neuen Produkthaftungsregelungen).

Software und KI werden zum haftungsrelevanten Produkt

Der Produktbegriff erfasst nun ausdrücklich Softwaresysteme wie Betriebssysteme, Firmware, Computerprogramme und KI-Systeme (Art. 4 Nr. 1 Produkthaftungsrichtlinie, § 2 Abs. 1 Nr. 3 ProdHaftG-E). Erfasst sind ebenso deren Komponenten und die damit verbundenen digitalen Dienstleistungen (Art. 4 Nr. 3, 4 der Richtlinie, § 4 Abs. 2 ProdHaftG‑E).

Damit fallen KI-Systeme im Sinne des Art. 3 Nr. 1 KI-VO ebenso unter das neue Recht wie Produkte mit digitalen Elementen nach Art. 3 Nr. 1 CRA.

Der deutsche Gesetzgeber hat den Begriff der Software bewusst offengelassen (RegE ProdHaftG, Seite 24). Der Anwendungsbereich ist dadurch sehr weit. Die einzige nennenswerte Ausnahme ist Open-Source-Software, die außerhalb einer Geschäftstätigkeit entwickelt oder bereitgestellt wird.

Der Fehlerbegriff knüpft direkt an CRA und KI-VO an

Neu ist auch, woran sich die Fehlerhaftigkeit bei diesen Produkten bemisst. Ein Produkt muss die Sicherheit bieten, die nach deutschem oder EU-Recht vorgeschrieben ist oder berechtigterweise erwartet werden darf (Art. 7 Abs. 2 f. der Richtlinie, § 7 ProdHaftG-E). Damit können einschlägige Sicherheitsanforderungen aus CRA und KI-VO unmittelbar in die Fehlerbeurteilung einfließen und, soweit sie produkt- bzw. cybersicherheitsrechtlich einschlägig sind, zum Maßstab der Fehlerhaftigkeit werden. Zu berücksichtigen wären alle relevanten Umstände, insbesondere Design, vernünftigerweise vorhersehbarer Gebrauch, Selbstlernfähigkeit, Wechselwirkungen mit anderen Produkten und die Cybersicherheitsanforderungen (Erwägungsgrund 32 der Richtlinie).

Drei Aspekte sind besonders praxisrelevant:

1) Unterlassene Sicherheits-Updates können einen Produktfehler begründen: Ist ein Sicherheits-Update erforderlich, um das Schutzniveau zu erhalten, und wird es nicht bereitgestellt, so soll das Produkt als fehlerhaft gelten.

2) Schwachstellen und Angriffe Dritter: Es ist unerheblich, ob eine Schwachstelle nur vorliegt oder von einem Dritten ausgenutzt wird (Erwägungsgrund 55 der Richtlinie). Entsteht durch eine Schwachstelle ein Schaden, soll der Hersteller grundsätzlich auch dann haften, wenn der Schaden erst durch einen Hackerangriff eintritt. Entscheidend soll dabei folgende Frage sein: Entsprach die Software dem Stand der Technik und war der Angriff trotzdem möglich, oder wurde er durch unterlassene Schutzmaßnahmen überhaupt erst ermöglicht?

Ab wann ein Produkt als hinreichend sicher gilt, soll das Bundesamt für Sicherheit in der Informationstechnik (BSI) konkretisieren (RegE ProdHaftG, Seite 32). Als Orientierung können in der Praxis die Mindeststandards und der Stand der Technik im IT-Grundschutz, anerkannte Normen wie ISO/IEC 61508 oder aber auch zukünftig die harmonisierten EU-Normen nach CRA oder KI-VO dienen (voraussichtlich die sich gerade in Überarbeitung befindliche Norm ISO/IEC 62443 für Aspekte der Automatisierungstechnik).

Wichtig für die Risikoeinschätzung: Die Richtlinie statuiert eine verschuldensunabhängige Haftung. Ob der Hersteller eine Schwachstelle erkannt und behoben hat, ist im Ausgangspunkt unerheblich. Ob sich die zu § 823 BGB entwickelten Grundsätze zur Verkehrssicherungspflicht (vgl. BGH, Urteil vom 06.02.2007, Az.: VI ZR 247/05) übertragen lassen, wonach eine ordnungsgemäße Erfüllung der CRA-Pflichten (Schwachstellenbehebung nach Art. 13, Meldung nach Art. 14 CRA) haftungsentlastend wirken könnte, bleibt abzuwarten.

3) Verschobener Beurteilungszeitpunkt: Für die Beurteilung der Fehlerhaftigkeit soll grundsätzlich der Moment des Inverkehrbringens maßgeblich sein. Für digitale Produkte soll dieser frühe Zeitpunkt aber nicht gelten, solange der Hersteller (oder ggf. andere relevante Wirtschaftsakteure) weiterhin die Kontrolle über das Produkt hat und Software-Updates oder Sicherheitsmaßnahmen nachliefern kann (Art. 11 Abs. 2 der Richtlinie, § 9 Abs. 2 ProdHaftG-E).

Schaden: Auch Datenverlust zählt

Erstmals werden Daten als ersatzfähige Schadensform anerkannt, sofern sie nicht für berufliche Zwecke verwendet werden (Art. 6 Abs. 1 lit. c der Richtlinie). Werden private Daten durch einen Softwarefehler beschädigt oder vernichtet, begründet das bereits eine Haftung. Eine Kürzung wegen Mitverschuldens (§ 254 Abs. 1 BGB) kommt in Betracht, etwa wenn die geschädigte Person angebotene Updates oder Upgrades nicht installiert hat (Art. 13 Abs. 2 der Richtlinie, § 14 Abs. 2 ProdHaftG-E).

Eine betragsmäßige Haftungsobergrenze sieht die Richtlinie nicht vor. Auch zeitlich ist die Haftung faktisch kaum begrenzt, da wegen des verschobenen Beurteilungszeitpunkts nahezu immer auf den Hersteller zurückgegriffen werden kann. Die absolute Ausschlussfrist soll grundsätzlich zehn Jahre ab Inverkehrbringen oder Inbetriebnahme betragen (Art. 17 Abs. 1 lit. a der Richtlinie, § 17 Abs. 1 ProdHaftG-E).

Bei integrierten Produkten haften mehrere Hersteller nebeneinander. Beispiel: Für ein Fahrzeug mit eingebettetem Navigationsdienst, bei dem Fahrzeug und Dienst von unterschiedlichen Herstellern stammen, haften beide nach dem Produkthaftungsrecht (FAQ zum RegE ProdHaftG, S. 2).

Was das konkret für Unternehmen bedeutet

Die Pflichtenprogramme aus KI-VO und CRA werden über den Fehlerbegriff mittelbar haftungsscharf.

KI-VO: Bei Hochrisiko-KI müssen Genauigkeit, Robustheit und Cybersicherheit gewährleistet (Art. 15 KI-VO) und eine menschliche Aufsicht ermöglicht werden (Art. 14 KI‑VO). Nach dem Inverkehrbringen sind ein Post-Market-Monitoring und die Meldung schwerwiegender Vorfälle sicherzustellen (Art. 72, 73 KI-VO).

CRA: Produkte sind so zu konzipieren, dass sie hinreichend gegen Cyberangriffe geschützt sind (Art. 13, Anhang I CRA). Erforderlich sind ein Schwachstellenmanagement über den gesamten Lebenszyklus (Art. 13 CRA) sowie die Bereitstellung von Sicherheits-Updates und die Behebung von Schwachstellen (Art. 13, Anhang I Teil III CRA). Für Hochrisiko-KI im Anwendungsbereich des CRA verweist Art. 12 Abs. 1 CRA wiederrum auf die Robustheitsanforderungen des Art. 15 KI-VO (für weitergehende Informationen: CRA-Whitepaper "A Practical Reference Architecture for Cyber Resilience Act (CRA) Compliance").

Werden diese Pflichten verletzt und entsteht ein Schaden, der sich bereits im Datenbestand des Nutzers zeigen kann, droht die unmittelbare Haftung. Eine ungepatchte Schwachstelle, die Ausgangspunkt eines Angriffs wird, wird damit zu einem erheblichen Haftungsrisiko.

Hinzu kommt eine prozessuale Verschärfung: Geschädigte erhalten eine Beweiserleichterung. Neue Offenlegungspflichten verpflichten den Beklagten auf Antrag, alle sicherheitsrelevanten Informationen offenzulegen (Art. 9 der Richtlinie, § 19 ProdHaftG-E).

Handlungsempfehlungen: Das sollte Ihr Unternehmen jetzt schon angehen

• Produktportfolio analysieren: Prüfen Sie, welche Ihrer Software-, KI- und vernetzten Produkte künftig als haftungsrelevantes Produkt gelten und wo Sie Komponenten oder Dienste Dritter integrieren.
• Schwachstellenmanagement aufsetzen: Implementieren Sie ein CRA-konformes Schwachstellenmanagement inklusive Meldewegen und dokumentieren Sie den Stand der Technik.
• Update- und Patch-Prozesse verankern: Etablieren Sie verbindliche Prozesse zur zeitnahen Bereitstellung von Sicherheits-Updates über den gesamten Lebenszyklus. Unterlassene Updates begründen einen Fehler.
• Compliance-Nachweise dokumentieren: Halten Sie fest, dass Sicherheitsmaßnahmen dem Stand der Technik entsprechen. Diese Dokumentation wird angesichts der neuen Offenlegungspflichten prozessentscheidend.
• KI-Governance stärken: Gewährleisten Sie bei Hochrisiko-KI Genauigkeit, Robustheit, menschliche Aufsicht sowie Post-Market-Monitoring und Vorfallmeldungen und stellen diese Aspekte auch über den Produktlebenszyklus und Ihre Lieferkette sicher.
• Verträge in der Lieferkette prüfen: Regeln Sie Haftung, Regress und Update-Verantwortung mit Zulieferern und Integrationspartnern, da mehrere Hersteller nebeneinander haften können.
• Versicherungsschutz überprüfen: Bewerten Sie Ihre Deckung neu. Es gibt keine betragsmäßige Haftungsobergrenze, und auch Datenverluste privater Nutzer sind ersatzfähig.