Wenn Software ein Produkt wird: Warum ein nicht ausgeliefertes Sicherheitsupdate ab dem 9. Dezember 2026 ein Haftungsfall ist – und weshalb deine Observability-Architektur plötzlich eine juristische Funktion hat

Der Aufhänger: Das Update, das nie kam

Stell dir ein Gerät vor, das es tausendfach gibt. Eine vernetzte Heizungssteuerung, verkauft an Privathaushalte, mit einer App, einem Cloud-Backend und einer Firmware, die über eine Update-Funktion verfügt. Das Gerät wurde 2027 in Verkehr gebracht, es funktionierte einwandfrei, es erfüllte alle Normen, und der Hersteller hat im Produktionsprozess nichts falsch gemacht.

Zwei Jahre später wird in einer Bibliothek, die in der Firmware steckt, eine Schwachstelle veröffentlicht. Der Hersteller erfährt davon. Ein Patch der Bibliothek existiert. Aber die Update-Pipeline für diese Produktlinie ist seit dem Weggang des zuständigen Entwicklers nicht mehr gepflegt, das Signaturzertifikat ist abgelaufen, und die Geräteserie ist kommerziell ohnehin ein Auslaufmodell. Also passiert nichts. Achtzehn Monate später nutzt jemand die Schwachstelle, übernimmt die Steuerung, lässt die Heizung im Januar ausfallen, und in einer Wohnung platzt eine Leitung. Der Wasserschaden kostet dreißigtausend Euro. Im selben Vorfall werden die lokal gespeicherten Verbrauchsdaten und Automatisierungsprofile der Nutzerin unwiederbringlich zerstört.

Nach dem Produkthaftungsrecht, das in Europa von 1985 bis 2026 galt, wäre die Lage für den Hersteller erstaunlich komfortabel gewesen. Software war dort nach verbreiteter Auffassung gar kein Produkt. Der Fehler bestand im Zeitpunkt des Inverkehrbringens noch nicht – er entstand erst später durch die Veröffentlichung der Schwachstelle. Die zerstörten Daten waren kein Sachschaden, weil Daten keine Sache sind. Beim Sachschaden hätte die Geschädigte eine Selbstbeteiligung von 500 Euro getragen. Und den Nachweis, dass genau die unterlassene Aktualisierung einer Bibliothek in einer Firmware zum Wasserschaden führte, hätte sie als Privatperson gegen einen Hersteller mit exklusivem Zugang zu Logs, Quellcode und Telemetrie praktisch nicht führen können.

Ab dem 9. Dezember 2026 dreht sich fast jeder dieser Punkte. Die Richtlinie (EU) 2024/2853 ist keine Reparatur am Rand. Sie ist die erste vollständige Neufassung der europäischen Produkthaftung seit 41 Jahren, sie bezieht Software ausdrücklich in den Produktbegriff ein, sie erklärt Datenverlust zum ersatzfähigen Schaden, sie schließt die Haftungsbefreiung für nachträglich entstandene Fehler ausgerechnet dort, wo Software im Spiel ist, und sie verlagert einen erheblichen Teil der Beweislast auf den Hersteller. In Deutschland geschieht das durch ein vollständig neues Produkthaftungsgesetz, das die Bundesregierung am 25. Februar 2026 in den Bundestag eingebracht hat.

Dieser Artikel ist der Versuch, das Regelwerk nicht als juristische Textexegese zu lesen, sondern als Anforderungsdokument an eine Softwarearchitektur. Denn das ist es im Ergebnis geworden.

Teil 1: Das Kernkonzept – Gefährdungshaftung ohne Verschulden

Was Produkthaftung von Vertragsrecht unterscheidet

Produkthaftung ist weder Vertragshaftung noch klassische Verschuldenshaftung. Sie ist eine Gefährdungshaftung: Wer ein Produkt in Verkehr bringt, haftet für Schäden, die durch dessen Fehlerhaftigkeit entstehen – unabhängig davon, ob er sorgfältig gearbeitet hat. Der Geschädigte muss keinen Vorwurf beweisen. Er muss drei Dinge beweisen: dass das Produkt fehlerhaft war, dass ihm ein Schaden entstanden ist und dass zwischen beidem ein Kausalzusammenhang besteht (Art. 10 Abs. 1 der Richtlinie).

Dieses Konstrukt hat zwei Eigenschaften, die für Softwareanbieter unbequem sind. Erstens: Es gibt keinen Vertrag, den man gestalten könnte. Anspruchsberechtigt ist nach Art. 5 Abs. 1 jede natürliche Person, die einen Schaden erlitten hat – nicht nur der Käufer, sondern auch der Besucher, der Nachbar, das Kind. Zweitens: Nach Art. 15 kann die Haftung gegenüber dem Geschädigten weder durch Vertrag noch durch nationales Recht beschränkt oder ausgeschlossen werden. Jede Haftungsbeschränkung in AGB, EULA oder Rahmenvertrag ist gegenüber dem Geschädigten wirkungslos. Die vertraute Praxis, das eigene Risiko über Klauseln zu deckeln, funktioniert hier nicht.

Die Lücke, die 41 Jahre offen stand

Die Richtlinie 85/374/EWG definierte „Produkt" als bewegliche Sache. Das war 1985 eine naheliegende Formulierung und wurde mit jedem Jahr unpassender. Ob Software eine bewegliche Sache ist, war über Jahrzehnte umstritten: Eine CD-ROM mit einem Programm ließ sich noch als Sache begreifen, ein Download kaum, ein über das Netz erbrachter Dienst gar nicht. Die Folge war eine Rechtslage, in der dasselbe Steuerungsprogramm je nach Vertriebsweg haftungsrechtlich unterschiedlich behandelt wurde – ein Ergebnis, das sich sachlich nicht begründen ließ.

Art. 4 Nr. 1 der neuen Richtlinie beendet das in einem Halbsatz. „Produkt" ist jede bewegliche Sache, auch wenn sie in eine andere Sache integriert oder mit ihr verbunden ist; und ausdrücklich gilt: unter „Produkt" sind auch Elektrizität, digitale Konstruktionsunterlagen, Rohstoffe und Software zu verstehen.

Drei Konsequenzen daraus sind sofort greifbar:

Software ist Produkt, unabhängig von der Bereitstellungsform. Der Erwägungsgrund zur Produktdefinition stellt klar, dass es nicht darauf ankommt, ob Software auf einem Gerät gespeichert, über ein Netz heruntergeladen oder über Cloud-Technologien bereitgestellt wird. Betriebssysteme, Firmware, Anwendungen, Treiber und KI-Systeme fallen darunter. Der Anbieter eines KI-Systems ist nach der Systematik der Richtlinie Hersteller.

Digitale Konstruktionsunterlagen sind Produkt. Eine STL- oder STEP-Datei, aus der ein Bauteil gefertigt oder gedruckt wird, haftet selbst. Wer eine fehlerhafte 3D-Druckvorlage für eine tragende Halterung verbreitet, haftet für die Folgen des Bruchs, auch wenn er nie ein physisches Teil berührt hat.

Reine Information bleibt draußen. Quellcode als solcher, Datensätze, Dokumentation und wissenschaftliche Erkenntnisse sind nach den Erwägungsgründen keine Produkte. Die Grenze läuft dort, wo aus Information eine Funktion wird: Ein Algorithmus in einem Aufsatz ist Information, derselbe Algorithmus kompiliert und in einem Gerät ausgeführt ist Produkt.

Zwei neue Grundbegriffe: verbundener Dienst und Kontrolle

Die Richtlinie führt zwei Begriffe ein, die das gesamte Regelwerk zusammenhalten.

Ein verbundener Dienst ist nach Art. 4 Nr. 3 ein digitaler Dienst, der so in ein Produkt integriert oder mit ihm verbunden ist, dass das Produkt ohne ihn eine oder mehrere seiner Funktionen nicht ausführen könnte. Das Cloud-Backend, ohne das die Heizungssteuerung keine Zeitprogramme kennt, ist ein verbundener Dienst. Nach Art. 4 Nr. 4 ist eine Komponente jeder körperliche oder nicht-körperliche Gegenstand, jeder Rohstoff und jeder verbundene Dienst, der in ein Produkt integriert oder mit ihm verbunden ist. Damit ist eine eingebundene Bibliothek eine Komponente, und ihr Hersteller haftet nach Art. 8 Abs. 1 Buchst. b unmittelbar gegenüber dem Geschädigten – nicht nur im Innenverhältnis gegenüber dem Integrator.

Der zweite Begriff ist der Hebel, an dem alles hängt. Kontrolle des Herstellers liegt nach Art. 4 Nr. 5 vor, wenn der Hersteller die Integration, Verbindung oder Bereitstellung von Komponenten einschließlich Software-Updates vornimmt oder Dritten dafür die Zustimmung erteilt – und auch dann, wenn er Updates selbst oder über Dritte bereitstellen kann. Dieses Wort „kann" ist die juristisch folgenreichste Stelle der ganzen Richtlinie. Wer eine Update-Fähigkeit eingebaut hat, behält Kontrolle. Und Kontrolle ist das, was die zentrale Haftungsbefreiung aushebelt.

Teil 2: Der Anwendungsbereich – wer drin ist und wer draußen bleibt

Die Stichtagslogik

Art. 2 Abs. 1 bestimmt den Anwendungsbereich nicht über den Schadenszeitpunkt, sondern über das Inverkehrbringen: Die Richtlinie gilt für Produkte, die nach dem 9. Dezember 2026 in Verkehr gebracht oder in Betrieb genommen werden. Nach Art. 21 wird die alte Richtlinie 85/374/EWG mit Wirkung vom 9. Dezember 2026 aufgehoben, gilt aber für früher in Verkehr gebrachte Produkte weiter. Der deutsche Gesetzentwurf spiegelt das in einer Übergangsvorschrift für Produkte, die bis zum 8. Dezember 2026 in Verkehr gebracht wurden.

Für Softwareanbieter ist diese Logik gefährlich einfach zu unterschätzen. Software wird nicht einmal in Verkehr gebracht, sondern fortlaufend. Jede neue Version, jedes Release, jede SaaS-Instanz, die nach dem Stichtag erstmals bereitgestellt wird, fällt in das neue Regime. Wer im Dezember 2026 ein Produkt mit zweiwöchigem Release-Zyklus betreibt, ist nach wenigen Wochen vollständig im neuen Recht – unabhängig davon, wann die erste Version entstand. Die Vorstellung einer langen Übergangsphase ist für kontinuierlich ausgelieferte Software eine Illusion.

Die Open-Source-Ausnahme und ihre scharfe Kante

Art. 2 Abs. 2 nimmt freie und quelloffene Software vom Anwendungsbereich aus, die außerhalb einer Geschäftstätigkeit entwickelt oder bereitgestellt wird. Das ist eine bewusste und begrüßenswerte Entscheidung: Niemand soll für ein Wochenendprojekt auf einer Code-Plattform nach Gefährdungshaftungsgrundsätzen haften.

Die Ausnahme ist aber enger, als viele Projekte annehmen. Sie knüpft nicht an die Lizenz an, sondern an die Geschäftstätigkeit. Nach den Erwägungsgründen entfällt die Ausnahme, wenn die Software gegen Entgelt bereitgestellt wird – und ebenso, wenn sie gegen personenbezogene Daten bereitgestellt wird, die zu anderen Zwecken als ausschließlich zur Verbesserung der Sicherheit, Kompatibilität oder Interoperabilität verwendet werden. Damit stehen typische Mischmodelle auf unklarem Grund: das Open-Core-Projekt mit kommerzieller Enterprise-Edition, der Anbieter, der dieselbe Codebasis als Dienst monetarisiert, das Projekt mit einer Telemetriefunktion, deren Daten ins Produktmarketing fließen. Ich bin der Meinung, dass sich die Reichweite dieser Datenklausel erst durch Rechtsprechung klären lässt; der Richtlinientext allein trägt keine verlässliche Abgrenzung. Wer ein Projekt mit kommerziellem Arm betreibt, sollte nicht davon ausgehen, dass die Open-Source-Ausnahme trägt.

Wichtig ist der Gegenschluss: Wer eine freie Komponente in ein kommerzielles Produkt integriert, kann sich nicht hinter der Ausnahme verstecken. Die Ausnahme schützt den nicht-geschäftlichen Entwickler, nicht den geschäftlichen Integrator. Die Haftung für eine fehlerhafte Open-Source-Bibliothek landet dort, wo sie kommerziell verwendet wird – und das ist, nach Jahren der Debatte über die Unterfinanzierung kritischer Bibliotheken, eine ökonomisch nicht uninteressante Verschiebung.

Der strittige Punkt: SaaS

Ob Software-as-a-Service erfasst ist, wird unterschiedlich beurteilt. Ein Teil der Literatur hält SaaS für ausdrücklich erfasst, weil es auf die Bereitstellungsform nicht ankommt. Andere weisen darauf hin, dass die Richtlinie Dienstleistungen als solche nicht reguliert und zu SaaS keine klare Aussage trifft. Beide Positionen stützen sich auf denselben Text.

Ich bin der Meinung, dass sich die Streitfrage durch die Komponenten- und Dienstedefinition in der Praxis weitgehend auflöst: Wo ein Cloud-Dienst für die Funktion eines Produkts erforderlich ist, ist er ein verbundener Dienst und damit über Art. 4 Nr. 4 als Komponente erfasst – unabhängig davon, ob man ihn selbst als Produkt qualifiziert. Haftungsfrei wäre allenfalls der reine, von keinem Produkt benötigte Dienst. Für die Architekturpraxis heißt das: Die Frage, ob dein Dienst „ein Produkt" ist, ist weniger entscheidend als die Frage, ob irgendein Produkt ihn zum Funktionieren braucht.

Teil 3: Der Fehlerbegriff – was die Richtlinie unter Sicherheit versteht

Erwartete, nicht vereinbarte Sicherheit

Art. 7 Abs. 1 definiert ein Produkt als fehlerhaft, wenn es nicht die Sicherheit bietet, die eine Person erwarten darf, oder die nach Unionsrecht oder nationalem Recht vorgeschrieben ist. Der Maßstab ist also nicht, was vereinbart wurde, und nicht, was technisch üblich ist, sondern was berechtigterweise erwartet werden darf. Ein dokumentierter Mangel bleibt ein Fehler, wenn die Dokumentation die Erwartung nicht wirksam verschiebt.

Art. 7 Abs. 2 listet die Umstände auf, die dabei zu berücksichtigen sind. Die Liste ist für Software bemerkenswert, weil mehrere Punkte erst in dieser Fassung hinzugekommen sind:

Buchstabe f verdient besondere Aufmerksamkeit. Er verknüpft die Haftung mit dem gesamten produktbezogenen Sicherheitsrecht. Erfüllt ein Produkt die Anforderungen des Cyber Resilience Act nicht – etwa die Pflicht, Schwachstellen über den Supportzeitraum zu behandeln –, dann ist das nicht nur ein Verstoß gegen Marktzugangsrecht. Es ist ein Argument für Fehlerhaftigkeit im Haftungsprozess. Und nach Art. 10 Abs. 2 Buchst. b wird die Fehlerhaftigkeit bei Verstoß gegen verbindliche Produktsicherheitsanforderungen sogar vermutet. Compliance und Haftung sind damit nicht länger getrennte Welten: Dieselbe Pflichtverletzung erscheint zweimal, einmal als Ordnungswidrigkeit und einmal als Vermutung gegen dich.

Art. 7 Abs. 3 enthält die Gegenbegrenzung: Ein Produkt ist nicht allein deshalb fehlerhaft, weil später ein besseres Produkt auf dem Markt ist. Das ist für Software wichtig. Ein ausgeliefertes Update beweist nicht, dass die Vorgängerversion fehlerhaft war. Andernfalls würde das Recht bestrafen, was es eigentlich erzwingen will.

Teil 4: Der Schaden – Daten werden ein Rechtsgut

Art. 6 Abs. 1 benennt drei Schadensarten:

Buchstabe a: Tod oder Körperverletzung, ausdrücklich einschließlich medizinisch anerkannter Beeinträchtigungen der psychischen Gesundheit. Das ist neu und für digitale Produkte relevant: Ein nachweisbarer psychischer Gesundheitsschaden, etwa infolge eines Datenlecks oder einer manipulativen Gestaltung, ist ersatzfähig, wenn er medizinisch anerkannt ist.

Buchstabe b: Beschädigung oder Zerstörung von Sachen, mit drei Ausnahmen: das fehlerhafte Produkt selbst, Produkte, die durch eine vom Hersteller selbst integrierte fehlerhafte Komponente beschädigt wurden, und Sachen, die ausschließlich beruflich genutzt werden.

Buchstabe c: Vernichtung oder Beschädigung von Daten, die nicht für berufliche Zwecke verwendet werden. Dieser Punkt ist der eigentliche Systembruch. Erstmals ist Datenverlust als solcher ein ersatzfähiger Schaden der Produkthaftung – ohne dass ein Sachschaden oder eine Körperverletzung hinzukommen müsste. Zerstörte Fotos, gelöschte private Dokumente, korrumpierte Konfigurationen, verlorene Spielstände: Das sind jetzt Schadensposten. Nach Art. 6 Abs. 2 umfasst der Ersatz Vermögensschäden und, soweit das nationale Recht ihn gewährt, auch immaterielle Schäden.

Zwei weitere Punkte verschärfen die wirtschaftliche Dimension erheblich. Die alte Richtlinie kannte eine Selbstbeteiligung von 500 Euro bei Sachschäden; sie entfällt. Und sie erlaubte den Mitgliedstaaten eine Haftungshöchstgrenze für Personenschäden aus gleichartigen Produkten, von der Deutschland mit 85 Millionen Euro Gebrauch gemacht hatte; auch sie fällt weg. Bei einem Softwarefehler, der sich definitionsgemäß in jeder Instanz identisch reproduziert, war diese Höchstgrenze die stille Versicherung gegen das Massenschadensrisiko. Sie ist weg, und zugleich erlaubt die europäische Verbandsklagenrichtlinie, solche Ansprüche gebündelt geltend zu machen.

Die Grenze des Regimes bleibt dort, wo es rein beruflich zugeht: Ausschließlich beruflich genutzte Sachen und beruflich genutzte Daten sind nicht erfasst, und anspruchsberechtigt sind nach Art. 5 nur natürliche Personen. Der klassische B2B-Ausfallschaden bleibt also Vertrags- und Deliktsrecht. Wer aber ein Produkt baut, das in gemischten Umgebungen läuft – Smart Home, Fahrzeug, Medizingerät, Endgerätesoftware –, kann sich auf diese Grenze nicht verlassen.

Teil 5: Wer haftet – die Kaskade des Art. 8

Art. 8 benennt die Haftungsadressaten in einer Kaskade, die sicherstellen soll, dass immer jemand in der Union erreichbar ist:

1. Der Hersteller des fehlerhaften Produkts (Abs. 1 Buchst. a).
2. Der Hersteller einer fehlerhaften Komponente, wenn sie unter seiner Kontrolle integriert oder verbunden wurde (Abs. 1 Buchst. b). Das ist die Direkthaftung des Bibliotheks- und Modulanbieters.
3. Importeur, Bevollmächtigter und – wenn keiner von beiden in der Union sitzt – der Fulfilment-Dienstleister, wenn der Hersteller außerhalb der Union ansässig ist (Abs. 1 Buchst. c).
4. Wer ein Produkt außerhalb der Herstellerkontrolle wesentlich verändert und bereitstellt, gilt selbst als Hersteller (Abs. 2).
5. Der Lieferant, wenn kein in der Union haftender Akteur feststellbar ist und er nicht innerhalb eines Monats nach Aufforderung einen solchen Akteur oder seinen eigenen Lieferanten benennt (Abs. 3).
6. Betreiber von Online-Plattformen, die Fernabsatzverträge ermöglichen, unter den Bedingungen des Art. 6 Abs. 3 der Verordnung (EU) 2022/2065 – also dann, wenn die Plattform den Eindruck erweckt, das Produkt selbst anzubieten (Abs. 4).

Punkt 4 ist für Software unterschätzt. Wer ein fremdes Produkt wesentlich verändert und weiterverteilt, haftet wie ein Hersteller. Ein Fork mit substanziellen Eingriffen, ein stark angepasstes Container-Image, ein mit eigenen Patches versehenes Gerät beim Systemintegrator: Das kann die Herstellerrolle begründen. Die Grenze zwischen Konfiguration und wesentlicher Veränderung ist unscharf und wird eine der ersten Streitfragen der Praxis sein.

Nach Art. 12 Abs. 1 haften mehrere Akteure gesamtschuldnerisch, und Art. 14 regelt den Rückgriff untereinander. Art. 12 Abs. 2 enthält dazu eine Besonderheit: Ein Hersteller, der eine fehlerhafte Softwarekomponente integriert hat, hat keinen Rückgriff gegen deren Hersteller, wenn er vertraglich darauf verzichtet hat; die Vorschrift nimmt dabei besonders Kleinst- und Kleinunternehmen als Komponentenhersteller in den Blick. Für kleine Softwareanbieter ist das eine der wenigen wirklich nutzbaren Gestaltungsmöglichkeiten des Regimes – aber sie wirkt nur im Innenverhältnis. Gegenüber dem Geschädigten bleibt die Direkthaftung aus Art. 8 Abs. 1 Buchst. b unberührt, und Art. 15 verbietet jede Beschränkung ihm gegenüber.

Teil 6: Die prozessuale Revolution – Offenlegung und drei Vermutungen

Materiell ist die Richtlinie streng. Prozessual ist sie das, was den Unterschied in der Praxis ausmacht. Denn das alte Recht war für Geschädigte vor allem deshalb wirkungslos, weil der Beweis eines Softwarefehlers ohne Zugang zu Code, Logs und Telemetrie faktisch unmöglich war.

Art. 9: Offenlegung von Beweismitteln

Nach Art. 9 Abs. 1 muss der Beklagte relevante, in seiner Verfügungsgewalt befindliche Beweismittel offenlegen, wenn der Kläger die Plausibilität seines Anspruchs ausreichend stützt. Nach Abs. 2 gilt das umgekehrt auch zugunsten des Beklagten. Die Absätze 3 bis 5 begrenzen das auf das Erforderliche und Verhältnismäßige, verpflichten die Gerichte zur Berücksichtigung der Interessen aller Beteiligten – insbesondere des Schutzes von Geschäftsgeheimnissen – und erlauben Vertraulichkeitsmaßnahmen.

Das ist kein US-amerikanisches Discovery, aber es ist für kontinentaleuropäisches Zivilprozessrecht ein beachtlicher Schritt. Gegenstand einer Offenlegungsanordnung kann alles sein, was zur Beurteilung der Fehlerhaftigkeit relevant ist: Quellcode, Buildartefakte, Testergebnisse, Code-Review-Protokolle, Ticketsysteme, SBOM-Daten, Schwachstellenbewertungen, Telemetrie – und, in der Praxis wohl am heikelsten, interne Kommunikation über bekannte Risiken.

Art. 10: Die drei Erleichterungen

Art. 10 Abs. 1 bleibt beim Grundsatz: Der Kläger beweist Fehlerhaftigkeit, Schaden und Kausalität. Dann folgen drei Durchbrechungen:

Die Fehlerhaftigkeit wird vermutet (Abs. 2), wenn der Beklagte relevante Beweismittel entgegen Art. 9 Abs. 1 nicht offenlegt (Buchst. a), wenn das Produkt verbindliche Produktsicherheitsanforderungen nicht erfüllt (Buchst. b) oder wenn der Schaden durch eine offensichtliche Funktionsstörung des Produkts bei normaler Verwendung entstanden ist (Buchst. c).

Der Kausalzusammenhang wird vermutet (Abs. 3), wenn das Produkt fehlerhaft ist und der eingetretene Schaden seiner Art nach typischerweise auf diesen Fehler zurückzuführen ist.

Das Gericht nimmt Fehlerhaftigkeit und/oder Kausalität an (Abs. 4), wenn der Beweis für den Kläger wegen technischer oder wissenschaftlicher Komplexität übermäßig schwierig ist und er die Wahrscheinlichkeit beider Umstände nachweist.

Nach Abs. 5 sind alle Vermutungen widerleglich. Genau darin liegt die eigentliche Botschaft an die Technik: Widerlegen kann nur, wer belegen kann. Absatz 4 ist dabei fast maßgeschneidert für Machine-Learning-Systeme – kaum ein Gericht wird einem Privatkläger den Beweis der Fehlerhaftigkeit eines neuronalen Netzes zumuten. Die realistische Erwartung ist, dass in Softwarefällen regelmäßig eine der Vermutungen greift und der Hersteller in die Rolle gerät, seine eigene Korrektheit zu belegen.

Damit erhält die Observability-Architektur eine juristische Funktion. Reproduzierbare Builds, lückenlose Versionsherkunft, signierte und auditierbare Update-Pipelines, eine aktuelle SBOM, dokumentierte Schwachstellenentscheidungen samt Begründung, nachvollziehbare Telemetrie über Gerätezustand und tatsächlich installierte Versionen: Das ist ab Dezember 2026 nicht nur Betriebsqualität, sondern Beweismaterial. Wer die Verteilung einer Firmwareversion über die installierte Basis nicht belegen kann, kann die Vermutung aus Art. 10 Abs. 2 Buchst. c nicht entkräften. Und wer auf eine Offenlegungsanordnung nichts Belastbares liefert, bekommt die Fehlerhaftigkeit nach Buchst. a vermutet – Schweigen ist hier die teuerste Option.

Teil 7: Die Haftungsbefreiungen und das Loch in ihrer Mitte

Art. 11 Abs. 1 zählt die Befreiungsgründe auf, die der Wirtschaftsakteur beweisen muss: dass er das Produkt nicht in Verkehr gebracht (Buchst. a) oder nicht bereitgestellt hat (Buchst. b); dass der Fehler zum maßgeblichen Zeitpunkt nicht bestand oder erst danach entstand (Buchst. c); dass der Fehler auf die Einhaltung rechtlicher Anforderungen zurückgeht (Buchst. d); dass der Fehler nach dem objektiven Stand der Wissenschaft und Technik nicht erkennbar war (Buchst. e – die Entwicklungsrisiko-Einrede); dass der Fehler einer Komponente auf die Gestaltung des Endprodukts oder auf Anweisungen des Produktherstellers zurückgeht (Buchst. f); und dass bei einem Veränderer der Fehler einen nicht veränderten Teil betrifft (Buchst. g).

Buchstabe c war über Jahrzehnte die wichtigste Verteidigung bei Software. Ein Programm, das bei Auslieferung dem Stand der Technik entsprach, wurde nicht dadurch fehlerhaft, dass drei Jahre später ein neues Angriffsverfahren veröffentlicht wurde.

Art. 11 Abs. 2 beendet das. Abweichend von Absatz 1 Buchstabe c tritt keine Befreiung ein, wenn die Fehlerhaftigkeit auf einem der folgenden Umstände beruht, sofern dieser der Kontrolle des Herstellers unterliegt: einem verbundenen Dienst, Software einschließlich ihrer Updates, dem Fehlen von Software-Updates oder -Upgrades zur Aufrechterhaltung der Sicherheit, oder einer wesentlichen Änderung des Produkts.

Der dritte Punkt ist die Vorschrift, die die Eingangsgeschichte entscheidet. Das Fehlen eines sicherheitsrelevanten Updates ist ein eigenständiger Haftungsgrund. Und weil „Kontrolle" nach Art. 4 Nr. 5 schon dann besteht, wenn der Hersteller Updates bereitstellen kann, entsteht eine Pflicht, die weit über das Inverkehrbringen hinaus wirkt. Patch-Management ist damit keine Servicefrage und kein Kulanzthema mehr, sondern eine haftungsbewehrte Pflicht.

Wie lange sie besteht, lässt die Richtlinie offen – und das ist ihre größte praktische Unsicherheit. Zwei Fristen begrenzen das Risiko zeitlich: Nach Art. 16 verjähren Ansprüche in drei Jahren ab dem Zeitpunkt, zu dem der Geschädigte von Schaden, Fehlerhaftigkeit und Identität des Haftenden Kenntnis hatte oder hätte haben müssen. Nach Art. 17 erlischt der Anspruch zehn Jahre nach dem Inverkehrbringen oder der Inbetriebnahme – bei wesentlich veränderten Produkten gerechnet ab der Bereitstellung nach der Veränderung – und bei spät auftretenden Personenschäden erst nach 25 Jahren. Das ergibt für ein Softwareprodukt einen Risikohorizont von mindestens einem Jahrzehnt. Wer Supportzeiträume definiert, definiert damit nicht seine Haftungsgrenze, sondern lediglich sein Serviceversprechen; die Zehnjahresfrist läuft unabhängig davon.

Ich bin der Meinung, dass die praktisch wirksamste Antwort darauf nicht in längeren Supportversprechen liegt, sondern in der bewussten Reduktion der eigenen Kontrollfläche: weniger Fernwirkmöglichkeiten, klarer dokumentierte Produktgrenzen, ein definiertes und kommuniziertes Ende der Update-Fähigkeit. Belegbar ist das nicht – es ist eine Einschätzung, die erst durch die ersten Entscheidungen zu Art. 11 Abs. 2 bestätigt oder widerlegt werden kann.

Ergänzend erlaubt Art. 18 den Mitgliedstaaten, von der Entwicklungsrisiko-Einrede abzuweichen und für bestimmte Produktkategorien strenger zu haften, unter Notifizierungspflichten gegenüber der Kommission bis zum 9. Dezember 2026. Und Art. 19 verpflichtet die Mitgliedstaaten, rechtskräftige Urteile der Berufungs- und Revisionsgerichte zu veröffentlichen; die Kommission führt eine öffentliche Datenbank. Für die Praxis ist das eine der wichtigsten Vorschriften überhaupt: Die Auslegungsfragen, die dieser Artikel offenlassen muss, werden ab 2028 öffentlich nachlesbar beantwortet.

Teil 8: Die deutsche Umsetzung – ein neues Produkthaftungsgesetz

Deutschland setzt die Richtlinie nicht durch Änderungen am bestehenden Gesetz um, sondern durch ein neues Stammgesetz gleichen Namens. Der Entwurf eines Gesetzes zur Modernisierung des Produkthaftungsrechts wurde am 25. Februar 2026 als Bundestagsdrucksache 21/4297 eingebracht; der Bundesrat hatte am 30. Januar 2026 Stellung genommen. Es ist die erste umfassende Reform des deutschen Produkthaftungsrechts seit 1989.

Die Struktur des Entwurfs folgt der Richtlinie: § 1 regelt die Haftung für Tötung, Körper- und Gesundheitsverletzung, Sachbeschädigung und die Vernichtung oder Beschädigung nicht beruflich genutzter Daten. Die §§ 4 und 5 behandeln die Haftung für fehlerhafte Komponenten und verbundene digitale Dienste sowie die Haftung des Veränderers. Die §§ 7 bis 9 enthalten den Fehlerbegriff, den Beurteilungszeitpunkt einschließlich der Software-Updates bei fortbestehender Herstellerkontrolle und die Haftungsausschlüsse. Die §§ 10 bis 13 bilden die Haftungskaskade mit Importeuren, Bevollmächtigten, Fulfilment-Dienstleistern, Lieferanten und bestimmten Online-Plattformen ab. Die §§ 14 bis 18 regeln Schadensersatz, Verjährung von drei Jahren, Erlöschen nach zehn bzw. bei Latenz bis zu 25 Jahren und die Unabdingbarkeit. Die §§ 19 und 20 setzen Offenlegung und Vermutungen um, die §§ 21 bis 23 enthalten die Arzneimittelausnahme, die Urteilsveröffentlichung und die Übergangsregelung für Produkte, die bis zum 8. Dezember 2026 in Verkehr gebracht wurden.

Bemerkenswert ist eine Zahl aus dem Entwurf selbst: Der erwartete Erfüllungsaufwand für Wirtschaft und Bürger wird mit „keine Veränderung" angegeben; bezifferte Mehrkosten entstehen nur bei Gerichten und Urteilsveröffentlichung, rund 66.000 Euro bei den Ländern und 3.000 Euro beim Bund. Ich bin der Meinung, dass diese Einschätzung die tatsächlichen Kosten in softwareproduzierenden Unternehmen deutlich unterschätzt, weil die Richtlinie zwar keine neuen Dokumentationspflichten anordnet, über Art. 10 aber faktisch eine Beweisvorsorge verlangt, die aufzubauen Geld kostet. Belegbar ist das nicht – es ist eine Prognose.

Teil 9: Ein Framework für die Praxis

Wer ab Dezember 2026 Software in der EU bereitstellt, kann die Richtlinie auf sieben überprüfbare Fragen reduzieren:

Die unangenehme Pointe dieser Liste: Keine der sieben Fragen ist eine Rechtsfrage. Alle sieben sind Fragen an Build-, Release-, Monitoring- und Dokumentationsarchitektur. Die Richtlinie verlagert Compliance aus der Rechtsabteilung in die Entwicklungsorganisation, ohne das ausdrücklich zu sagen.

Erkenntnis zum Mitnehmen

Die neue Produkthaftung verändert weniger, was Software darf, als was ein Hersteller beweisen können muss. Materiell wirkt vieles vertraut: Gefährdungshaftung, Fehlerbegriff, Befreiungsgründe. Die Wirkung entsteht aus der Kombination von drei Stellen, die einzeln harmlos aussehen – dem Wort „kann" in der Kontrolldefinition des Art. 4 Nr. 5, dem Ausschluss der Befreiung für fehlende Sicherheitsupdates in Art. 11 Abs. 2 und den Vermutungen des Art. 10. Zusammen ergeben sie eine Pflicht, Software über ein Jahrzehnt hinweg sicher zu halten, und die Beweislast dafür, dass man es getan hat.

Der praktische Handlungsanstoß ist deshalb nicht juristisch, sondern technisch, und er ist in einem Satz formulierbar: Geh davon aus, dass du in zehn Jahren für eine Version, die du heute ausliefert, belegen musst, was in ihr steckte, wer darüber entschieden hat und welche Geräte das Update tatsächlich erhalten haben. Wenn dein aktueller Stack diese drei Fragen nicht aus Protokollen beantworten kann, dann ist das ab dem 9. Dezember 2026 kein Reifegradproblem mehr, sondern ein offenes Haftungsrisiko. Der konkrete erste Schritt, der sich in einer Woche tun lässt: Nimm eine beliebige produktive Version und versuche, nur aus vorhandenen Artefakten und Logs zu rekonstruieren, welche Abhängigkeiten in welcher Fassung enthalten waren und auf wie vielen Installationen sie heute noch läuft. Was dabei fehlt, ist deine Lückenliste.

Reflexionsfrage

Die Richtlinie knüpft die Haftung an Kontrolle – und schafft damit einen Anreiz, Kontrolle abzugeben: Wer keine Fernupdates ermöglicht, haftet nicht für ihr Ausbleiben. Gleichzeitig ist die Update-Fähigkeit das wirksamste Mittel, Produkte über ihre Lebenszeit sicher zu halten, und der Cyber Resilience Act verlangt sie.

Wie würdest du diesen Widerspruch für ein konkretes Produkt auflösen, das du heute verantwortest – und an welcher Stelle würdest du die Grenze zwischen „so viel Kontrolle, dass ich Sicherheit herstellen kann" und „so wenig Kontrolle, dass ich nicht unbefristet dafür hafte" ziehen? Und wäre diese Grenze dieselbe, wenn du sie nicht als Hersteller, sondern als Nutzerin des Produkts ziehen müsstest?

Querverweise im Vault

• Sicherheit ab Werk: Der EU Cyber Resilience Act und das Ende des unsicheren Produkts – die Vorderseite derselben Münze: Der CRA schreibt die Sicherheitspflichten vor, deren Verletzung über Art. 7 Abs. 2 Buchst. f und Art. 10 Abs. 2 Buchst. b zur Haftung führt.
• Die Pyramide des Risikos: Wie der EU AI Act künstliche Intelligenz bändigt – und warum das die ganze Welt betrifft – das Pendant für KI-Systeme: Der AI Act regelt den Marktzugang, die Produkthaftung die Folgen des Scheiterns, und Art. 7 Abs. 2 Buchst. c verbindet beide über die Lernfähigkeit.
• Die Hintertür im Herzen von Linux: Der XZ-Backdoor und die Anatomie eines Supply-Chain-Angriffs – der Realfall zur Komponentenhaftung aus Art. 8 Abs. 1 Buchst. b und zur Frage, wen die Open-Source-Ausnahme wirklich schützt.
• Der Ausgang aus der Wolke: Warum dir die Daten deiner Maschinen gehören, was eine Cloud-Migration ab Januar kosten darf – und weshalb das eine juristische Frage mit sehr technischen Konsequenzen ist – dieselbe Geräteklasse aus der Datenperspektive, und die zweite europäische Vorschrift, die Daten als eigenständiges Schutzgut behandelt.
• NIS2 und was sie für mittelständische IT-Beratungsunternehmen in Deutschland wirklich bedeutet – die organisatorische Seite des Schwachstellenmanagements, dessen Versäumnisse hier haftungsrelevant werden.
• Der Algorithmus als Richter: Artikel 22 DSGVO, das SCHUFA-Urteil und das Recht auf eine menschliche Entscheidung – das gleiche regulatorische Muster: Beweis- und Erklärungslasten werden dorthin verschoben, wo die technische Information liegt.
• Das Ende des Passworts: Passkeys, WebAuthn und die Anatomie phishing-resistenter Anmeldung – ein Beispiel für „Sicherheit, die eine Person erwarten darf" im Sinne des Art. 7 Abs. 1.
• Wenn der Prozessor zu viel rät: Spectre, Meltdown und die Sünde der spekulativen Ausführung – der Musterfall für die Entwicklungsrisiko-Einrede des Art. 11 Abs. 1 Buchst. e und ihre Grenzen.

Quellen

1. Richtlinie (EU) 2024/2853 des Europäischen Parlaments und des Rates vom 23. Oktober 2024 über die Haftung für fehlerhafte Produkte und zur Aufhebung der Richtlinie 85/374/EWG des Rates, ABl. L vom 18.11.2024; in Kraft seit 8. Dezember 2024, anwendbar auf Produkte, die nach dem 9. Dezember 2026 in Verkehr gebracht werden. EUR-Lex, deutsche Fassung; englische Fassung
2. Deutscher Bundestag, Drucksache 21/4297 vom 25.02.2026: Entwurf eines Gesetzes zur Modernisierung des Produkthaftungsrechts (Gesetzentwurf der Bundesregierung, federführend BMJV; Stellungnahme des Bundesrates vom 30.01.2026). Neues Stammgesetz, Inkrafttreten 9. Dezember 2026. dserver.bundestag.de
3. Bundesministerium der Justiz und für Verbraucherschutz: Gesetz zur Modernisierung des Produkthaftungsrechts – Gesetzgebungsverfahren mit Referenten- und Regierungsentwurf. bmjv.de
4. Christina Kiefer / Laure Herlitz (reuschlaw): Liability for software under the new European Product Liability Directive, International Bar Association, 30. April 2025 – Analyse zu Produktbegriff, Open-Source-Ausnahme, Update-Pflichten und den Vermutungen der Art. 9 und 10. ibanet.org
5. Dr. Oliver Wolff-Rojczyk / Dominik Rosemann (FPS): Die neue EU-Produkthaftungsrichtlinie – Risiken auch für Softwarehersteller, 21. Januar 2025 – Einordnung von SaaS, Komponentenhaftung, Wegfall der 500-Euro-Schwelle und der Haftungshöchstgrenze sowie Verhältnis zu CRA und AI Act. fps-law.de
6. GvW Graf von Westphalen: Alles neu?! Produkthaftungsrichtlinie (EU) 2024/2853 der EU in Kraft getreten sowie Reform des Produkthaftungsrechts: Der Referentenentwurf zur EU-Richtlinie im Überblick – Überblicksdarstellungen zum Richtlinien- und Umsetzungsstand. gvw.com

Hinweis: Dieser Artikel ist eine fachliche Darstellung des Regelungsstands und keine Rechtsberatung. Die Angaben zur deutschen Umsetzung beziehen sich auf den Gesetzentwurf in der Fassung der Bundestagsdrucksache 21/4297 vom 25. Februar 2026; das parlamentarische Verfahren kann den Text noch verändern.

← All articles