Produkthaftung für Software ab Dezember 2026: wer haftet
Ab dem 9. Dezember 2026 gilt Software ausdrücklich als Produkt – samt Updates, SaaS und KI. Wer bei einer Auftragsentwicklung haftet, warum fehlende Sicherheitsupdates zum Produktfehler werden und weshalb reine B2B-Schäden meist gar nicht erfasst sind.
Was sich am 9. Dezember 2026 ändert – und was noch nicht beschlossen ist
Am 9. Dezember 2026 endet die Frist, bis zu der alle EU-Staaten die neue Produkthaftungsrichtlinie, die Richtlinie (EU) 2024/2853, in nationales Recht umgesetzt haben müssen. Sie ersetzt die Regeln von 1985, auf denen das deutsche Produkthaftungsgesetz von 1989 beruht, und bezieht erstmals ausdrücklich Software ein. Für Produkte, die bis einschließlich 8. Dezember 2026 in Verkehr gebracht werden, gilt das bisherige Recht weiter.
In Deutschland liegt dafür ein Regierungsentwurf vor, die Bundestagsdrucksache 21/4297 vom 25. Februar 2026. Die erste Lesung fand am 4. März 2026 statt, der Rechtsausschuss hörte am 13. April 2026 Sachverständige an. Anfang September 2026 standen die abschließenden Lesungen im Bundestag und die Befassung des Bundesrats noch aus; geplant ist das Inkrafttreten zum 9. Dezember 2026.
Viele Darstellungen schreiben deshalb, das neue Gesetz „tritt in Kraft", als sei es bereits beschlossen. Genauer ist: Die EU gibt den Stichtag fest vor, der deutsche Wortlaut kann sich bis zur Verabschiedung noch ändern. Die Grundzüge – Software als Produkt, Haftung für Updates, keine Haftungsobergrenze – stehen in der Richtlinie selbst und hängen nicht vom Ausgang der Beratungen ab.
Software ist jetzt ein Produkt: Download, App, SaaS und KI
Software gilt nach der neuen Richtlinie als Produkt, und zwar unabhängig davon, wie sie bereitgestellt wird. Das Bundesjustizministerium fasst es so zusammen, dass die Produkthaftung künftig „für jegliche Art von Software gelten" soll, „also auch bei Cloud- und KI-Software". Ob eine Anwendung als Download, als App, eingebettet in ein Gerät oder als Software-as-a-Service über den Browser läuft, spielt keine Rolle mehr.
Bisher war umstritten, ob Software überhaupt eine „bewegliche Sache" im Sinne des Produkthaftungsgesetzes ist. Dieser Streit ist für neue Produkte erledigt. Nicht als Produkt gelten nach den Erwägungsgründen dagegen reine Informationen und der Quellcode als solcher – haftungsrelevant ist die lauffähige Software, nicht der Text, aus dem sie entsteht.
Fehlerhaft ist ein Produkt nach Artikel 7, wenn es nicht die Sicherheit bietet, die man erwarten darf oder die rechtlich vorgeschrieben ist. Dazu zählen ausdrücklich auch Anforderungen an die Cybersicherheit. Hier berührt sich die Produkthaftung mit dem Cyber Resilience Act: Wer dessen Sicherheitsanforderungen verfehlt, liefert einem Geschädigten ein starkes Argument für einen Produktfehler. Welche Meldepflichten der CRA selbst auslöst, steht im Beitrag zur CRA-Meldepflicht.
Wer haftet: Hersteller, Auftraggeber oder Agentur?
Haftbar ist in erster Linie der Hersteller – und Hersteller ist nicht nur, wer eine Software selbst entwickelt, sondern auch, wer sie entwickeln lässt und unter eigenem Namen oder eigener Marke anbietet. Bei einer Auftragsentwicklung kommen damit grundsätzlich beide Seiten in Betracht: die Agentur, die den Code schreibt, und der Auftraggeber, der die Anwendung als seine eigene an Kunden ausliefert.
Haften mehrere Beteiligte für denselben Schaden, kann sich ein Geschädigter an jeden von ihnen halten. Wer am Ende zahlt, entscheidet sich im Innenverhältnis – und genau dort hilft ein Vertrag, der Rückgriff, Verantwortung für Updates und Dokumentationspflichten klar regelt. Gegenüber dem Geschädigten lässt sich die Haftung dagegen nicht vertraglich ausschließen oder begrenzen.
Eine weitere Rolle kommt hinzu: Wer ein Produkt nach dem Inverkehrbringen wesentlich verändert und das außerhalb der Kontrolle des ursprünglichen Herstellers tut, gilt für diese Änderung selbst als Hersteller. Für Agenturen, die fremde Software erweitern, umbauen oder ein bestehendes System übernehmen, ist das der relevantere Fall. Wie deutsche Gerichte die Grenze zwischen Anpassung und wesentlicher Veränderung bei Software ziehen, ist noch nicht entschieden.
Fehlende Sicherheitsupdates als Produktfehler
Hersteller haften künftig auch für Updates und Upgrades und dafür, dass notwendige Sicherheitsupdates ausbleiben. Bisher konnte sich ein Hersteller entlasten, wenn ein Fehler beim Inverkehrbringen noch nicht bestand. Nach Artikel 11 Absatz 2 der Richtlinie greift diese Entlastung nicht, wenn der Fehler auf eine Software-Aktualisierung oder auf ein fehlendes Sicherheitsupdate zurückgeht, das unter der Kontrolle des Herstellers steht.
Unter Kontrolle steht ein Update dann, wenn der Hersteller es selbst bereitstellt oder der Bereitstellung durch einen Dritten zustimmt. Damit verschiebt sich der Blick vom Auslieferungstag auf den gesamten Lebenszyklus: Eine Anwendung, die beim Start sicher war und später eine bekannte, ungepatchte Lücke trägt, kann ab dann als fehlerhaft gelten.
Die Grenze dieser Pflicht liegt bei der Kontrolle. Die Richtlinie verlangt nicht, jede Software unbegrenzt zu pflegen. Wer aber Updates anbietet oder anbieten müsste, weil er das Produkt weiter betreut, sollte festlegen und dokumentieren, wie lange und in welchem Takt Sicherheitsupdates kommen – und Abhängigkeiten wie Frameworks und Bibliotheken in diesen Plan einbeziehen.
Welche Schäden ersetzt werden – und warum B2B-Schäden meist nicht darunterfallen
Ersetzt werden Tod und Körperverletzung einschließlich medizinisch anerkannter Schäden an der psychischen Gesundheit, Schäden an anderen Sachen als dem fehlerhaften Produkt und – neu – die Vernichtung oder Beschädigung von Daten. Die bisherige Höchstgrenze von 85 Millionen Euro entfällt ebenso wie der Selbstbehalt von 500 Euro bei Sachschäden.
Entscheidend für Softwareanbieter ist die Ausnahme: Artikel 6 Absatz 1 nimmt Sachen aus, die ausschließlich beruflich genutzt werden, und erfasst Datenverluste nur, wenn die Daten nicht für berufliche Zwecke verwendet werden. Die neue Produkthaftung schützt damit vor allem Verbraucher. Fällt eine Fachanwendung aus und vernichtet die Kundendatei eines Betriebs, ist das in aller Regel kein Fall für die Produkthaftung.
Für reine B2B-Software bleibt der Vertrag die maßgebliche Haftungsgrundlage – Gewährleistung, vereinbarte Haftungsregeln und Service-Level. Eine Ausnahme sollte man nicht übersehen: Personenschäden sind immer erfasst, auch im Geschäftskundenbereich. Steuert eine Software Maschinen, Fahrzeuge oder medizinische Abläufe, ist die B2B-Grenze kein Schutz.
Beweiserleichterung und Offenlegungspflicht vor Gericht
Geschädigte müssen Fehler, Schaden und Ursachenzusammenhang weiterhin beweisen, bekommen dafür aber deutlich mehr Hilfe. Das Gericht kann den Hersteller verpflichten, relevante Beweismittel offenzulegen – das Bundesjustizministerium nennt als Beispiel Sicherheitsdokumente. Geschäftsgeheimnisse bleiben dabei schutzfähig, verhindern die Offenlegung aber nicht grundsätzlich.
Hinzu kommen Vermutungen nach Artikel 10: Ein Fehler wird etwa vermutet, wenn der Hersteller die angeordnete Offenlegung verweigert, wenn das Produkt verbindliche Sicherheitsanforderungen verletzt oder wenn es bei normaler Verwendung offensichtlich versagt. Ist ein Fall technisch so komplex, dass der Nachweis übermäßig schwer wäre, können Gerichte ebenfalls Erleichterungen gewähren – bei KI-Systemen ein naheliegendes Szenario.
Praktisch heißt das: Die eigene Dokumentation wird zum wichtigsten Verteidigungsmittel. Testprotokolle, eine nachvollziehbare Update-Historie und eine Liste der verbauten Komponenten belegen, was zu welchem Zeitpunkt bekannt und behoben war. Wer nichts dokumentiert hat, kann eine Vermutung kaum widerlegen.
Open Source im eigenen Produkt: wann die Ausnahme nicht hilft
Freie und quelloffene Software ist nach Artikel 2 von der Richtlinie ausgenommen, wenn sie außerhalb einer Geschäftstätigkeit entwickelt oder bereitgestellt wird. Das schützt die Autorin einer Bibliothek, die ihren Code unentgeltlich veröffentlicht – nicht aber das Unternehmen, das diese Bibliothek in ein verkauftes Produkt einbaut.
Wer Open-Source-Komponenten in eine kommerzielle Anwendung integriert, haftet als Hersteller des Gesamtprodukts auch für Fehler, die aus einer dieser Komponenten stammen. Bei modernen Web-Anwendungen mit hunderten Paketen aus Composer oder npm ist das der Normalfall. Ein Rückgriff auf die ehrenamtlichen Autoren scheidet praktisch aus.
Zeitlich reicht die Haftung weit: Ansprüche verjähren drei Jahre nach Kenntnis von Schaden, Fehler und Haftendem und erlöschen grundsätzlich zehn Jahre nach dem Inverkehrbringen, bei erst später erkennbaren Personenschäden nach bis zu 25 Jahren. Wer heute ausliefert, sollte also wissen, welche Komponenten er in welcher Version verbaut hat.
Was Softwareanbieter bis Dezember 2026 regeln sollten
Der erste Schritt ist eine Rollenklärung je Produkt: Wer bringt die Software unter welchem Namen in Verkehr, wer stellt Updates bereit, und erreicht sie Verbraucher oder nur Geschäftskunden? Diese drei Antworten entscheiden, ob und wie stark die neue Produkthaftung überhaupt greift.
Danach folgen vier praktische Punkte. Erstens einen Update-Zeitraum festlegen und kommunizieren. Zweitens die verbauten Komponenten inventarisieren, etwa als Software-Stückliste, die der Cyber Resilience Act ohnehin verlangt. Drittens Verträge zwischen Agentur und Auftraggeber um Regelungen zu Rückgriff, Update-Verantwortung und Dokumentation ergänzen. Viertens prüfen, ob die bestehende Haftpflichtversicherung Software als Produkt überhaupt abdeckt.
Sinnvoll ist außerdem, das Datum des Inverkehrbringens für jede Version festzuhalten, weil der Stichtag zwischen altem und neuem Recht daran hängt. Dieser Beitrag ersetzt keine Rechtsberatung: Für die konkrete Einordnung eines Produkts, vor allem bei Personenschadensrisiken, gehört ein Anwalt für Produkthaftung an den Tisch.
Rechtsgrundlagen
- Richtlinie (EU) 2024/2853 über die Haftung für fehlerhafte Produkte(öffnet in neuem Tab)Erfasst Software und fehlende Sicherheitsupdates, ab 09.12.2026
- Produkthaftungsgesetz (ProdHaftG)(öffnet in neuem Tab)Verschuldensunabhängige Haftung, die keine AGB begrenzen kann
- Verordnung (EU) 2024/2847 (Cyber Resilience Act)(öffnet in neuem Tab)Erwägungsgründe 17 bis 19 zur Ausnahme für nicht monetarisierte Open Source