Wann Softwarehersteller nicht haften (Art. 11 RL 2024/2853)

Kurz beantwortet: Die neue Produkthaftungsrichtlinie kennt einen Katalog von Haftungsausschlüssen, etwa dass der Hersteller das Produkt nicht in Verkehr gebracht hat, dass der Fehler bei Inverkehrbringen noch nicht bestand oder die Entwicklungsrisiko-Einrede. Für Software entfällt die Einrede, der Fehler sei erst nach dem Inverkehrbringen entstanden, wenn er auf Software, Updates oder fehlende Sicherheitsaktualisierungen zurückgeht, die der Kontrolle des Herstellers unterliegen. Die Entwicklungsrisiko-Einrede bleibt möglich, bei kontrollierter Software kommt es dafür aber auf den Stand von Wissenschaft und Technik während des gesamten Kontrollzeitraums an. Die Ausschlüsse sind deshalb keine Sicherheitsnetze, sondern eng begrenzte Ausnahmen, die der in Anspruch genommene Wirtschaftsakteur jeweils selbst beweisen muss.

Wer haftet, will auch wissen, wann er nicht haftet. Die neue EU-Produkthaftungsrichtlinie (Richtlinie (EU) 2024/2853) enthält einen Katalog von Haftungsausschlüssen. Für Software- und KI-Hersteller ist entscheidend, dass die Einrede des später entstandenen Fehlers gerade bei Software durchlöchert ist. Auch die Entwicklungsrisiko-Einrede misst sich bei vernetzten und updatefähigen Produkten an dem gesamten Zeitraum, in dem Sie die Kontrolle behalten.

Welche Befreiungsgründe zählt Artikel 11 auf?

Art. 11 Abs. 1 RL 2024/2853 zählt die Umstände auf, bei deren Nachweis ein Wirtschaftsakteur nicht haftet. Dazu gehören unter anderem: dass er das Produkt nicht in Verkehr gebracht hat (lit. a); dass die Fehlerhaftigkeit zum Zeitpunkt des Inverkehrbringens wahrscheinlich noch nicht bestand (lit. c); dass die Fehlerhaftigkeit darauf beruht, dass das Produkt zwingenden rechtlichen Anforderungen entspricht (lit. d); und, die praktisch wichtigste, die Entwicklungsrisiko-Einrede: dass der Fehler nach dem objektiven Stand von Wissenschaft und Technik zum maßgeblichen Zeitpunkt nicht erkennbar war (lit. e). Hinzu kommen zwei Gründe für die Lieferkette: Der Hersteller einer Komponente haftet nicht, wenn der Fehler auf die Gestaltung des Produkts, in das sie integriert wurde, oder auf Anweisungen von dessen Hersteller zurückgeht (lit. f), und wer ein Produkt wesentlich verändert hat, haftet nicht für Fehler in einem Teil, den die Änderung nicht betrifft (lit. g). Die Beweislast für diese Umstände trägt jeweils der in Anspruch genommene Wirtschaftsakteur.

Warum trägt die Einrede des später entstandenen Fehlers bei Software nicht?

Für Softwareunternehmen ist Art. 11 Abs. 2 RL 2024/2853 der eigentliche Kern. Danach wird ein Wirtschaftsakteur abweichend von Abs. 1 lit. c nicht von der Haftung befreit, wenn die Fehlerhaftigkeit zurückzuführen ist auf einen verbundenen Dienst, auf Software einschließlich Updates oder Upgrades, auf das Fehlen sicherheitsrelevanter Updates oder auf eine wesentliche Änderung des Produkts, sofern diese Umstände der Kontrolle des Herstellers unterliegen. Wer die Software und ihre Updates kontrolliert, kann sich damit nicht darauf berufen, der Fehler sei erst nach dem Inverkehrbringen entstanden. Die dynamische Natur von Software wird zum Haftungsverstärker, nicht zur Entlastung. Die Entwicklungsrisiko-Einrede nach lit. e bleibt von Abs. 2 unberührt; bei Software, die Sie weiter kontrollieren, kommt es dafür aber auf den Stand von Wissenschaft und Technik während des gesamten Kontrollzeitraums an. Mitgliedstaaten dürfen nach Art. 18 RL 2024/2853 bestehende Ausnahmen von dieser Einrede beibehalten oder unter engen Voraussetzungen für bestimmte Produktkategorien neu einführen. Das vom Bundestag beschlossene deutsche Gesetz sieht den Entwicklungsrisiko-Ausschluss weiterhin vor.

Wie wird das Fehlen von Updates zur Haftungsquelle?

Besonders folgenreich ist der Ausschluss für das Fehlen sicherheitsrelevanter Updates. Ein Produkt, das zum Zeitpunkt der Auslieferung sicher war, kann durch eine unterlassene Sicherheitsaktualisierung fehlerhaft werden, wenn das Update zur Aufrechterhaltung der Sicherheit erforderlich war und in der Kontrolle des Herstellers lag. Eine eigene Pflicht zu Updates schafft die Richtlinie nicht (Erwägungsgrund 51); installiert der Nutzer ein bereitgestelltes Update nicht, liegt das außerhalb Ihrer Kontrolle. Das Haftungsrisiko verzahnt sich aber mit den Vorgaben des Cyber Resilience Act. Wer den Support zu früh einstellt, öffnet ein Haftungsfenster. Wie dieses Update-Risiko bereits während der laufenden Kontrolle des Herstellers wirkt, ordnet der Beitrag zu Updates und Cybersecurity ein.

Was sollten Sie daraus für Ihre Praxis ableiten?

• Entwicklungsrisiko neu bewerten: Die Einrede misst sich bei kontrollierter Software am gesamten Kontrollzeitraum, dokumentieren Sie deshalb den jeweiligen Erkenntnisstand fortlaufend.
• Update-Strategie absichern: Sicherheitsupdates über den gesamten Unterstützungszeitraum planen und dokumentieren.
• Kontrolle abgrenzen: Vertraglich und technisch klären, welche Komponenten und Dienste Ihrer Kontrolle unterliegen.
• Konformität nachweisen: Die Einrede der Rechtskonformität (lit. d) greift nur, wenn gerade die Einhaltung einer rechtlichen Vorgabe den Fehler verursacht hat; dokumentieren Sie diesen Zusammenhang.
• Vorgaben festhalten: Als Zulieferer einer Softwarekomponente stützen Sie die Einrede nach lit. f, wenn Sie Spezifikationen und Anweisungen Ihres Abnehmers nachvollziehbar dokumentieren.

Die Richtlinie gilt für Produkte, die ab dem 9. Dezember 2026 in Verkehr gebracht oder in Betrieb genommen werden. Die Haftungsausschlüsse sollten Sie also nicht als Sicherheitsnetz, sondern als eng begrenzte Ausnahme verstehen. Die Gesamtübersicht bietet der Leitfaden zur Produkthaftung für Software & KI.

Wie das in der Praxis aussieht

Ein Beispiel, wie es in dieser Form häufig vorkommt: Ein Hersteller von E-Bike-Antrieben mit rund 200 Mitarbeitenden bringt 2027 eine neue Generation mit App und Funk-Updates auf den Markt. Das Produktmanagement will den Support je Generation nach einigen Jahren beenden und hält spätere Fehler dann nicht mehr für ein Herstellerthema. Die neue Produkthaftungsrichtlinie gilt für Produkte, die ab dem 9. Dezember 2026 in Verkehr gebracht werden. Die Einrede, der Fehler sei erst nach dem Inverkehrbringen entstanden, trägt nicht, wenn er auf Software, Updates oder fehlenden Sicherheitsupdates beruht, die der Hersteller kontrolliert. Jeden Befreiungsgrund muss er selbst beweisen.

Danach trennen sich die Wege. Für Firmware und App wird ein Unterstützungszeitraum festgelegt, in dem sicherheitsrelevante Updates geplant und dokumentiert werden; für die Entwicklungsrisiko-Einrede zählt bei kontrollierter Software der Stand von Wissenschaft und Technik während des gesamten Kontrollzeitraums. Stellt der Hersteller ein Update bereit und installiert der Nutzer es nicht, liegt das außerhalb seiner Kontrolle; Bereitstellung und Hinweis werden belegbar festgehalten. Am Ende stehen ein Supportkonzept und eine belastbare Dokumentation. Wo Verträge und Update-Abläufe dazu noch nicht passen, zeigt das Rechtliche Audit.

Häufige Fragen

Welche Haftungsausschlüsse kennt die Produkthaftungsrichtlinie?

Art. 11 Abs. 1 RL 2024/2853 nennt unter anderem, dass der Wirtschaftsakteur das Produkt nicht in Verkehr gebracht hat, dass die Fehlerhaftigkeit zum Zeitpunkt des Inverkehrbringens wahrscheinlich noch nicht bestand, dass das Produkt zwingenden rechtlichen Anforderungen entspricht, die Entwicklungsrisiko-Einrede sowie Befreiungsgründe für Komponentenhersteller und wesentlich Verändernde. Die Beweislast trägt jeweils der in Anspruch genommene Wirtschaftsakteur.

Was bedeutet die Entwicklungsrisiko-Einrede?

Die Entwicklungsrisiko-Einrede nach Art. 11 Abs. 1 lit. e RL 2024/2853 befreit den Hersteller, wenn der Fehler nach dem objektiven Stand von Wissenschaft und Technik zum maßgeblichen Zeitpunkt nicht erkennbar war.

Warum trägt die Einrede des später entstandenen Fehlers bei Software oft nicht?

Nach Art. 11 Abs. 2 RL 2024/2853 kann sich der Wirtschaftsakteur abweichend von Art. 11 Abs. 1 lit. c nicht darauf berufen, der Fehler sei erst später entstanden, wenn die Fehlerhaftigkeit auf einen verbundenen Dienst, auf Software einschließlich Updates, auf das Fehlen sicherheitsrelevanter Updates oder auf eine wesentliche Änderung zurückgeht, sofern diese Umstände der Kontrolle des Herstellers unterliegen. Die Entwicklungsrisiko-Einrede nach lit. e bleibt davon unberührt.

Haftet der Hersteller für fehlende Sicherheitsupdates?

Ein Produkt, das zum Zeitpunkt der Auslieferung sicher war, kann durch eine unterlassene Sicherheitsaktualisierung fehlerhaft werden, wenn das Update zur Aufrechterhaltung der Sicherheit erforderlich war und in der Kontrolle des Herstellers lag. Eine eigene Pflicht zu Updates begründet die Richtlinie nicht (Erwägungsgrund 51), wer den Support zu früh einstellt, öffnet aber ein Haftungsfenster.

Worauf sich Ihr Unternehmen bei einem Softwarefehler noch berufen kann, hängt auch an Verträgen und Update-Abläufen, die selten jemand gemeinsam prüft. Das Rechtliche Audit prüft Vertragsdokumente und Abläufe und zeigt, wo sie zur neuen Produkthaftung noch nicht passen. Rechtliches Audit: Verträge und Abläufe zur neuen Produkthaftung

Sie wollen wissen, worauf Sie sich bei Softwarefehlern noch berufen können? In einem 60-minütigen Strategiegespräch klären wir die Haftungsausschlüsse für Ihr Produkt. Für die vertragliche Umsetzung begleitet Sie die Rechtsberatung im IT-Recht.