Software ist ein Produkt: Was die neue Produkthaftung ab 9. Dezember 2026 ändert

Am 9. Dezember 2026 läuft eine Frist ab, über die dieses Jahr weit weniger geschrieben wurde als über den AI Act. Bis dahin müssen die Mitgliedstaaten die Richtlinie (EU) 2024/2853 vom 23. Oktober 2024 umsetzen — die neue Produkthaftungsrichtlinie. Ihr entscheidender Satz ist kurz: Software ist ein Produkt — lokal installiert, aus der Cloud bezogen oder als SaaS genutzt. KI-Systeme erfasst sie als Unterfall von Software.

Interessanter als diese Einordnung ist, was sie auslöst. Produkthaftung ist verschuldensunabhängig: Nicht die Sorgfalt zählt, sondern ob das Produkt fehlerhaft war. Das verschiebt die Risikoverteilung zwischen Entwickler, Auftraggeber und Einkäufer — bei der Beweisführung, bei den Pflichten nach der Auslieferung, bei der Berufung auf den Stand der Technik. Betroffen ist jeder, der Software oder KI in Verkehr bringt, auch kleine Entwickler und Systemhäuser.

Auf einen Blick

• Was gilt: Richtlinie (EU) 2024/2853, in Kraft, umzusetzen bis zum 9. Dezember 2026. Software ist ein Produkt, KI-Systeme ein Unterfall davon.
• Was folgt: verschuldensunabhängige Haftung für jeden, der Software in Verkehr bringt; Beweiserleichterungen für Geschädigte; Update-Verantwortung nach der Auslieferung.
• Der Haken: Das Umsetzungsgesetz ist nicht verabschiedet; verifiziert ist ein Regierungsentwurf vom 25. Februar 2026. Feste Frist, beweglicher Gesetzestext.

Was sich für Software ändert

Das deutsche Produkthaftungsgesetz stammt von 1989 und wurde seither nicht grundlegend neu gefasst. Der Regierungsentwurf vom 25. Februar 2026 — das „Gesetz zur Modernisierung des Produkthaftungsrechts“ — soll das ändern. Die Richtung gibt die Richtlinie vor:

Frage	Bisherige Lage	Richtlinie (EU) 2024/2853
Software ein Produkt?	umstritten, bei unkörperlicher Lieferung meist verneint	ja — lokal, Cloud und SaaS gleichgestellt
KI-Systeme erfasst?	nicht eigens geregelt	ja, als Unterfall von Software
Beweislast	im Kern beim Geschädigten, auch für die Ursache	Erleichterungen bei technisch sehr schwierigem Nachweis
Nach der Auslieferung?	Zustand bei Inverkehrbringen	Aktualisierungen des Herstellers erfasst
Einwand „nicht erkennbar”	klassischer Entlastungsgrund	bleibt — offen, wie weit bei fortlaufend kontrollierter Software

Die letzte Zeile ist die unbequemste. Der Entwicklungsrisiko-Einwand ist auf ein Produkt zugeschnitten, das die Fabrik verlässt und so bleibt. Software verlässt nichts; sie wird weiter gebaut, während sie läuft — und wer sie weiter baut, kann schlechter behaupten, er habe den Stand der Technik nur für den Tag der Auslieferung kennen müssen. Wie Gerichte das auflösen, ist offen; mir ist dazu keine Entscheidung bekannt.

Drei Einwände, die man mitdenken muss

Erstens: Die Frist steht, das Gesetz nicht. Die Richtlinie ist in Kraft, der 9. Dezember 2026 ist der Umsetzungstermin; das deutsche Gesetz ist im Verfahren. Ob und mit welchem Inhalt es verabschiedet wurde, habe ich nicht gegengeprüft und stelle es deshalb nicht dar. Wer heute Klauseln auf ein Umsetzungsgesetz hin formuliert, formuliert auf einen Text hin, den er nicht kennt — vernünftig ist, an der Mechanik der Richtlinie zu arbeiten.

Zweitens: Produkthaftung ersetzt Ihr Vertragsrisiko nicht, sie kommt daneben. Sie ist gesetzliche Haftung gegenüber dem Geschädigten, nicht Vertragshaftung gegenüber dem Auftraggeber, und sie zielt auf Personen- und Sachschäden — nicht auf den entgangenen Gewinn Ihres Kunden, weil eine Schnittstelle drei Tage stillstand. Das bleibt ein Werkvertragsthema. Der Unterschied liegt in der Gestaltbarkeit: Vertragliche Haftung können Sie begrenzen, gesetzliche nicht — der Geschädigte ist an Ihrem Vertrag nicht beteiligt.

Drittens: Inverkehrbringen ist bei laufend aktualisierter Software kein Zeitpunkt. Bei einer Maschine ist es ein Datum auf einem Lieferschein. Bei Software mit zweiwöchigem Release ist es eine Serie, und bei durchgehend betriebener SaaS ist zweifelhaft, ob es diesen Moment überhaupt gibt. An der Zuordnung hängen aber Fristen und der maßgebliche Stand der Technik. Wer sich darauf verlässt, sein Produkt sei „vor dem Stichtag” auf dem Markt gewesen, verlässt sich auf eine wackelige Einordnung.

Die Übergabe ist die Zäsur, nach der bisher gerechnet wurde. Der Faden dahinter ist das Neue: Update-Verantwortung, deren Ende so wenig zu sehen ist wie im offenen Gesetzestext.

Was das für Ihr Unternehmen heißt

Regeln Sie die Aktualisierungspflicht, bevor sie Ihnen zugeschrieben wird. Reicht die Verantwortung über die Auslieferung hinaus, lautet die Vertragsfrage nicht mehr nur, was geliefert wird, sondern wie lange nachgeliefert wird. Drei Punkte gehören ausdrücklich hinein: der zugesagte Zeitraum für Sicherheitsaktualisierungen, die Pflicht des Auftraggebers, sie einzuspielen, und die Rechtsfolge, wenn er es nicht tut. Wie lang er rechtlich sein muss, ist bei offener Umsetzung ungeklärt — planbar ist nur, was Sie selbst festlegen. Die übrigen Bausteine stehen in KI-Verträge: Was wirklich rein muss.

Führen Sie eine versionierte Software-Stückliste — sie bekommt eine haftungsrechtliche Funktion. Die Liste aller Fremdkomponenten mit Version und Herkunft war bisher ein Sicherheitsthema. Jetzt ist sie die Grundlage dafür, überhaupt zuordnen zu können, ob ein Fehler aus Ihrem Code oder aus einer Zulieferung stammt — und damit Voraussetzung für jeden Regress. Wer das nicht dokumentiert, steht für Software ein, die er nicht geschrieben hat, ohne sie jemandem zurechnen zu können. Das gehört in die Build-vs-Buy-Rechnung.

Prüfen Sie Versicherung und Release-Dokumentation, bevor das nächste Produkt herausgeht. Deckt Ihre Haftpflicht Produkthaftung aus Softwarelieferung ab, oder endet sie bei Beratungsfehlern? Das klärt man vorher, schriftlich. Und können Sie für jedes Release belegen, was wann herausging und was geprüft wurde? Wo der Geschädigte Beweiserleichterungen hat, ist Ihre eigene Dokumentation das, was Ihnen bleibt — und was in einer MVP-Phase daran gespart wird, fehlt genau dann, wenn es gebraucht wird.

Fazit

Die Einordnung von Software als Produkt ist sachlich überfällig; die Trennung zwischen körperlicher und unkörperlicher Lieferung hatte längst keine Überzeugungskraft mehr. Überzeichnen sollte man die Wirkung nicht: Der Schaden, der die meisten Softwareprojekte trifft, bleibt ein Vertragsthema.

Was sich real verschiebt, ist die Dokumentationslast. Beweiserleichterungen und Update-Verantwortung führen dazu, dass ein Streit über Software stärker daran entschieden wird, wer aufgeschrieben hat, was er wann ausgeliefert und geprüft hat. Das ist kein juristisches, sondern ein handwerkliches Thema — und der Teil, den Sie unabhängig vom Umsetzungsgesetz erledigen können.

Wenn Sie wissen wollen, welche Ihrer Verträge die Aktualisierungsfrage offen lassen, sprechen wir darüber. Ich schreibe solche Klauseln als Wirtschaftsjurist und liefere die Software, um die es darin geht, im Werkvertrag selbst aus.

FAQ

Gilt die neue Produkthaftung für Software schon?

Noch nicht. Die Richtlinie (EU) 2024/2853 vom 23. Oktober 2024 ist in Kraft, umzusetzen ist sie bis zum 9. Dezember 2026. In Deutschland läuft dazu ein Gesetzgebungsverfahren; verifiziert ist ein Regierungsentwurf vom 25. Februar 2026. Ob es abgeschlossen ist, war zum Stand dieses Beitrags offen.

Bin ich als kleiner Entwickler oder Systemhaus betroffen?

Ja, wenn Sie Software oder KI in Verkehr bringen. Die Haftung knüpft daran an, nicht an die Unternehmensgröße; auch kleine Entwickler und Systemhäuser sind erfasst. Lokal, Cloud oder SaaS macht keinen Unterschied. Die Frage ist nicht, ob Sie betroffen sind, sondern ob Verträge und Versicherung passen.

Kann ich die Produkthaftung im Vertrag ausschließen?

Gegenüber dem Geschädigten nicht. Produkthaftung ist gesetzliche Haftung; der Geschädigte ist an Ihrem Vertrag nicht beteiligt. Gestalten können Sie das Innenverhältnis: Regress gegen Zulieferer, Mitwirkung beim Einspielen von Updates, Zusicherungen zur Einsatzumgebung. Der Vertrag verlagert das Risiko, er beseitigt es nicht.

Was sollte ich bis Dezember 2026 konkret tun?

Vier Dinge, die auch ohne den endgültigen Gesetzestext tragen. Erstens den Zeitraum für Sicherheitsaktualisierungen vertraglich festlegen, samt Mitwirkungspflicht des Auftraggebers. Zweitens eine versionierte Software-Stückliste führen, um Fehler zuordnen und Regress nehmen zu können. Drittens die Versicherungsdeckung klären, viertens Release-Daten und Prüfschritte belegbar dokumentieren.

---

Quellen — Stand 19.09.2026

• BMJ, Gesetzgebungsverfahren Produkthaftung — https://www.bmjv.de/SharedDocs/Gesetzgebungsverfahren/DE/2025_Produkthaftung.html
• PwC Legal, Produkthaftung für Software — https://legal.pwc.de/de/news/fachbeitraege/einfuehrung-der-produkthaftung-fuer-software
• Ferner, Reform des Produkthaftungsrechts — https://www.ferner-alsdorf.de/reform-des-produkthaftungsrechts-software-und-ki/
• IHK Hannover, was sich ab Dezember ändert — https://www.ihk.de/hannover/hauptnavigation/recht/wirtschafts-und-wettbewerbsrecht2/wettbewerbsrecht/neues-produkthaftungsgesetz-ab-dezember-was-aendert-sich—6966802

Zur Belastbarkeit: Inhalt und Frist der Richtlinie sind gut belegt, das Entwurfsdatum stützt sich auf Sekundärquellen. Der Verfahrensstand wurde nicht gegengeprüft und ist deshalb nicht dargestellt; Artikel der Richtlinie werden bewusst nicht zitiert.

Dieser Beitrag ist allgemeine Information und keine Rechtsberatung im Einzelfall. Stand 19. September 2026 — prüfen Sie vor Entscheidungen den aktuellen Verfahrensstand.