Als die europäische Produkthaftung im Jahr 1985 erstmals einheitlich geregelt wurde, sah die Produktwelt noch anders aus. Die Richtlinie 85/374/EWG über die Haftung für fehlerhafte Produkte stammt aus einer Zeit, in der Windows 1.0 gerade erst erschienen war. Das World Wide Web existierte noch nicht. Produkte waren überwiegend körperliche Gegenstände. Ihre Sicherheit ließ sich vor allem anhand von Konstruktion, Herstellung und Gebrauchsanweisung beurteilen. Software, vernetzte Geräte, datenbasierte Dienste oder Systeme künstlicher Intelligenz spielten für das damalige Haftungsverständnis praktisch keine Rolle.
Diese Ausgangslage hat sich grundlegend verändert. Produkte sind heute häufig nicht mehr nur physische Gegenstände. Sie bestehen aus einem Zusammenspiel von Hardware, Software, Daten, digitalen Diensten und fortlaufenden Updates. Ein Fahrzeug, ein medizinisches Gerät, ein Haushaltsroboter oder ein smartes Sicherheitssystem kann seine Funktionalität nach dem Inverkehrbringen verändern. Es kann auf externe Daten angewiesen sein oder durch Cyberrisiken beeinträchtigt werden. Damit geraten klassische Kategorien des Produkthaftungsrechts unter Druck: Wann ist ein Produkt „fehlerhaft“, wenn sein Risiko erst durch ein Softwareupdate entsteht? Wer haftet, wenn ein Schaden auf eine fehlerhafte digitale Komponente zurückgeht? Und wie lässt sich ein Kausalzusammenhang nachweisen, wenn technische Abläufe für Geschädigte kaum nachvollziehbar sind?
Vor diesem Hintergrund hat der europäische Gesetzgeber das Produkthaftungsrecht umfassend reformiert. Die Richtlinie (EU) 2024/2853 vom 23. Oktober 2024 über die Haftung für fehlerhafte Produkte hebt die bisherige Produkthaftungsrichtlinie aus dem Jahr 1985 auf. An ihre Stelle tritt ein neues Regelwerk. Die Reform soll die Haftungsvorschriften an neue Technologien, digitale Geschäftsmodelle und die Kreislaufwirtschaft anpassen. Zugleich soll sie praktische Hürden bei Schadensersatzansprüchen abbauen. Das gilt besonders dort, wo technische oder wissenschaftliche Komplexität den Nachweis eines Produktfehlers oder der Schadensursächlichkeit erschwert.
Software wird zum Haftungsthema
Im Zentrum der Neuregelung steht daher nicht nur eine punktuelle Modernisierung. Es geht um eine strukturelle Erweiterung des Produkthaftungsrechts. Besonders deutlich wird dies daran, dass Software ausdrücklich in den Produktbegriff einbezogen wird. Damit reagiert die Richtlinie auf eine Realität, in der Sicherheit nicht mehr allein von Material, Konstruktion oder Produktion abhängt. Sie hängt zunehmend auch von Programmierung, Datenverarbeitung, Vernetzung und Cybersicherheit ab. Die neue Produkthaftungsrichtlinie markiert damit einen Paradigmenwechsel: Sie überführt ein Haftungssystem aus der analogen Produktwelt in eine digitale, vernetzte und zunehmend KI-geprägte Wirtschaft.
Die neue Produkthaftungsrichtlinie ersetzt das bisherige Haftungsregime allerdings nicht sofort. Nach Art. 2 Abs. 1 Richtlinie (EU) 2024/2853 gelten die neuen Vorschriften nur für Produkte, die ab dem 9. Dezember 2026 in Verkehr gebracht oder in Betrieb genommen werden. Für fehlerhafte Produkte, die bereits zuvor in Verkehr gebracht wurden, bleibt grundsätzlich das bisherige Recht maßgeblich. Wegen der zehnjährigen Ausschlussfrist kann es daher über einen längeren Zeitraum zu einem Nebeneinander von alter und neuer Rechtslage kommen.
Zugleich ist zu berücksichtigen, dass Hersteller auch nach bisherigem Recht nicht in einem haftungsfreien Raum agierten. Neben der verschuldensunabhängigen Produkthaftung bestand und besteht weiterhin die nationale Produzentenhaftung nach § 823 Abs. 1 BGB. Sie ist technikneutral ausgestaltet. Sie knüpft nicht unmittelbar an einen Produktfehler im Sinne des Produkthaftungsrechts an, sondern an die schuldhafte Verletzung einer Verkehrspflicht des Herstellers. Die Reform verdrängt diese nationale Haftung daher nicht vollständig. Außervertragliche Ansprüche nach nationalem Recht bleiben weiterhin relevant. Das gilt insbesondere für verschuldensabhängige Haftungstatbestände.
Der zentrale Paradigmenwechsel der neuen Produkthaftung
Ein zentraler Schritt der neuen Produkthaftungsrichtlinie liegt darin, Software ausdrücklich in den Produktbegriff einzubeziehen. Die Produkthaftungsrichtlinie aus dem Jahr 1985 war noch auf eine überwiegend körperliche Produktwelt zugeschnitten. Art. 4 Nr. 1 Richtlinie (EU) 2024/2853 stellt nun klar: Auch Software ist ein Produkt. Damit beantwortet der europäische Gesetzgeber eine lange diskutierte Frage: ob und unter welchen Voraussetzungen Software Gegenstand der verschuldensunabhängigen Produkthaftung sein kann.
Diese Klarstellung ist mehr als eine begriffliche Modernisierung. Sie berücksichtigt, dass die Sicherheit vieler Produkte heute nicht mehr allein von ihrer physischen Beschaffenheit abhängt. Bei modernen Fahrzeugen, Medizinprodukten, Smart-Home-Geräten oder Industrieanlagen entscheidet häufig gerade die Software, ob ein Produkt zuverlässig und sicher funktioniert. Ein Fehler kann daher nicht nur in Material, Konstruktion oder Herstellung liegen. Er kann ebenso in Programmierung, Datenverarbeitung, Schnittstellen, Updates oder der Interaktion mit anderen digitalen Komponenten entstehen.
Software wird weit verstanden
Die Richtlinie versteht Software dabei bewusst weit. Nach Erwägungsgrund 13 fallen insbesondere Betriebssysteme, Firmware, Computerprogramme, Anwendungen und KI-Systeme unter den Produktbegriff. Unerheblich ist, wie die Software bereitgestellt oder genutzt wird. Erfasst sein kann also nicht nur Software, die fest auf einem Gerät installiert ist. Auch Software, die über ein Kommunikationsnetz, Cloud-Technologien oder als Software-as-a-Service bereitgestellt wird, kann darunterfallen. Für die Haftung kommt es damit nicht mehr entscheidend darauf an, ob die Software körperlich verkörpert ist oder auf einem Datenträger übergeben wird. Maßgeblich ist ihre Funktion als sicherheitsrelevanter Bestandteil eines Produkts oder als eigenständiges digitales Produkt.
Praktisch bedeutsam ist dies vor allem bei eingebetteter Software, also Software, die in ein physisches Produkt integriert ist. Verursacht eine fehlerhafte Softwarekomponente einen Schaden, kann künftig nicht nur der Hersteller des Endprodukts haften. Nach Art. 8 Abs. 1 Unterabs. 1 Buchst. b Richtlinie (EU) 2024/2853 kommt auch eine Haftung des Herstellers der fehlerhaften Komponente in Betracht. Damit rücken Softwarehersteller stärker in den Kreis potenzieller Haftungsadressaten. Für Unternehmen bedeutet das: Wer sicherheitsrelevante Software entwickelt, zuliefert oder in Produkte integriert, wird haftungsrechtlich nicht mehr nur mittelbar über Vertragsketten relevant. Er kann unmittelbar in den Anwendungsbereich der Produkthaftung fallen.
Gleichzeitig bleibt der Anwendungsbereich begrenzt. Art. 2 Abs. 2 Richtlinie (EU) 2024/2853 nimmt freie und quelloffene Software aus, sofern sie außerhalb einer Geschäftstätigkeit entwickelt oder bereitgestellt wird. Der europäische Gesetzgeber will damit vermeiden, nicht-kommerzielle Open-Source-Entwicklung denselben Haftungsrisiken auszusetzen wie gewerbliche Softwarebereitstellung. Wird freie oder quelloffene Software jedoch in einem kommerziellen Zusammenhang genutzt, vertrieben oder in Produkte integriert, kann die Ausnahme an Bedeutung verlieren.
Wo Software endet und Information beginnt
Abzugrenzen ist Software außerdem von bloßen Informationen. Erwägungsgrund 13 stellt klar, dass Informationen als solche nicht als Produkt gelten. Die Produkthaftung soll daher grundsätzlich nicht für den Inhalt digitaler Dateien wie Mediendateien, E-Books oder den reinen Quellcode von Software greifen. Diese Abgrenzung ist konsequent, wirft aber neue Fragen auf. Gerade bei digitalen Systemen ist nicht immer leicht zu bestimmen, wann eine bloße Information endet und ein haftungsrechtlich relevantes Softwareprodukt beginnt. Der reine Quellcode als solcher ist noch keine ausgeführte Software. Erst wenn Code in eine funktionsfähige Anwendung übersetzt wird, kann er sicherheitsrelevante Wirkungen entfalten. Dann kann er als Produkt im Sinne der Richtlinie relevant werden.
Besonders deutlich zeigt sich diese Abgrenzungsproblematik bei KI-Systemen. Erzeugt ein KI-System eine unzutreffende Information, stellt sich die Frage, ob lediglich ein fehlerhafter Inhalt vorliegt oder ob die Software selbst fehlerhaft ist. Der EuGH hatte im Fall „Krone“ entschieden, dass ein fehlerhafter Gesundheitstipp in einer gedruckten Zeitung keine Produkthaftung auslöst. Eine Zeitung ist in diesem Fall lediglich Träger einer Information. Der fehlerhafte Rat haftet dem körperlichen Produkt nicht als Produktfehler an. Diese Wertung lässt sich jedoch nicht ohne Weiteres auf KI-Software übertragen. Ein KI-System gibt Informationen nicht nur wieder. Es erzeugt sie aufgrund eines programmierten oder trainierten Verarbeitungsprozesses.
Gerade bei diagnostischer Medizinproduktesoftware, automatisierten Entscheidungssystemen oder sicherheitsrelevanten KI-Anwendungen kann die Ausgabe Teil der bestimmungsgemäßen Produktfunktion sein. Soll eine solche Software auf Grundlage von Eingabedaten eine Diagnose, Warnung oder Handlungsempfehlung erzeugen, lässt sich eine fehlerhafte Ausgabe nicht ohne Weiteres als bloße Information ausklammern. In diesen Fällen liegt es näher, die Software selbst als fehlerhaftes Produkt einzuordnen. Das gilt jedenfalls dann, wenn sie nicht die Sicherheit bietet, die berechtigterweise erwartet werden darf.
Die Einbeziehung von Software in den Produktbegriff markiert damit einen grundlegenden Perspektivwechsel. Produkthaftung endet nicht mehr bei der physischen Beschaffenheit eines Gegenstands. Sie erfasst künftig auch digitale Funktionen, die für die Sicherheit eines Produkts prägend sind. Für Hersteller, Softwareanbieter und Unternehmen, die digitale Komponenten in ihre Produkte integrieren, steigen dadurch die Anforderungen an Entwicklung, Dokumentation, Risikomanagement und Produktbeobachtung erheblich.
Auch digitale Dienste rücken in den Blick
Neben Software im engeren Sinne nimmt die Richtlinie auch digitale Dienste in den Blick, die für die Funktionsfähigkeit eines Produkts wesentlich sind. Damit reagiert der europäische Gesetzgeber auf die zunehmende Vernetzung moderner Produkte. Viele Geräte funktionieren heute nicht mehr isoliert. Sie sind auf laufende digitale Dienste angewiesen. Ein Navigationssystem benötigt Verkehrsdaten. Ein intelligenter Kühlschrank kann auf eine Temperaturüberwachung zurückgreifen. Smarte Geräte lassen sich häufig nur über Sprachassistenten oder cloudbasierte Dienste vollständig nutzen.
Die Richtlinie erfasst solche Konstellationen über den Begriff des „verbundenen Dienstes“. Nach Art. 4 Nr. 3 Richtlinie (EU) 2024/2853 handelt es sich dabei um einen digitalen Dienst, der so in ein Produkt integriert oder mit ihm verbunden ist, dass das Produkt ohne ihn eine oder mehrere Funktionen nicht ausführen könnte. Art. 4 Nr. 4 stellt klar, dass ein solcher verbundener Dienst als Komponente gelten kann. Haftungsrechtlich ist das bedeutsam. Denn nach Art. 8 Abs. 1 Buchst. a und b kann sich die Verantwortlichkeit auch auf Schäden erstrecken, die durch eine fehlerhafte Komponente verursacht werden.
Der Gedanke dahinter ist überzeugend: Für die Sicherheit eines Produkts können digitale Dienste heute ebenso prägend sein wie physische Bauteile oder integrierte Software. Fällt ein solcher Dienst aus oder arbeitet er fehlerhaft, kann dies die Sicherheit des Gesamtprodukts unmittelbar beeinträchtigen. Die Produkthaftung wird damit an eine Realität angepasst, in der Produkte, Software und digitale Dienste häufig nur noch gemeinsam funktionieren.
Nicht erfasst sind dagegen reine Dienstleistungen ohne hinreichenden Bezug zu einem Produkt. Gerade hier bleiben jedoch Abgrenzungsfragen. Unklar ist insbesondere, wie cloudbasierte KI-Anwendungen einzuordnen sind, die im Abonnement bereitgestellt werden. Einerseits stellt Erwägungsgrund 13 klar, dass Software auch dann als Produkt erfasst sein kann, wenn sie über Cloud-Technologien oder als Software-as-a-Service bereitgestellt wird. Andererseits grenzt Erwägungsgrund 17 Dienstleistungen als solche vom Anwendungsbereich der Produkthaftung ab. Ob und wann insbesondere KI als Dienst unter die neue Produkthaftungsrichtlinie fällt, wird daher voraussichtlich erst die weitere Auslegungspraxis zeigen. Letztlich wird darüber wohl der EuGH entscheiden.
Ausnahme von Open Source Software
Eine wichtige Einschränkung gilt für freie und quelloffene Software, also Open-Source-Software. Nach Art. 2 Abs. 2 Richtlinie (EU) 2024/2853 ist sie vom Anwendungsbereich der Richtlinie ausgenommen, sofern sie außerhalb einer gewerblichen Tätigkeit entwickelt oder bereitgestellt wird. Damit soll verhindert werden, dass nicht-kommerzielle Forschung, gemeinschaftliche Softwareentwicklung und Innovation durch unkalkulierbare Haftungsrisiken gehemmt werden.
Praktisch relevant wird die Abgrenzung jedoch dort, wo Open-Source-Software in kommerzielle Produkte eingebunden wird. Gleiches gilt, wenn sie im Zusammenhang mit entgeltlichen Leistungen angeboten wird. Integriert ein Hersteller freie und quelloffene Software in ein Produkt und bringt dieses anschließend in Verkehr, kann er für Fehler der eingebetteten Software haften. Der nicht-kommerzielle Entwickler der Open-Source-Software bleibt dagegen grundsätzlich privilegiert.
Unklarheiten bestehen vor allem bei Mischformen. Das gilt etwa, wenn Open-Source-Projekte finanziell unterstützt, mit kostenpflichtigem Support verbunden oder als Teil eines umfassenderen Leistungsangebots bereitgestellt werden. Für die Auslegung spricht vieles dafür, an die Wertungen des Cyber Resilience Act anzuknüpfen. Auch dieser unterscheidet zwischen nicht-kommerzieller Open-Source-Entwicklung und gewerblicher Bereitstellung. Das entspricht dem Ziel der Produkthaftungsrichtlinie, Kohärenz mit dem Produktsicherheitsrecht herzustellen und digitale Produkte rechtssicher in den bestehenden Haftungsrahmen einzuordnen.
Haftung, Produktfehler und Produktbeobachtungspflicht bei Software
Mit der Einbeziehung von Software in den Produktbegriff verschiebt sich auch der Kreis der haftungsrechtlich Verantwortlichen. Haftungssubjekte sind künftig nicht mehr nur klassische Hersteller körperlicher Produkte, Importeure oder Lieferanten. Auch Softwarehersteller und Anbieter von KI-Systemen können unmittelbar in die Produkthaftung einbezogen werden. Das gilt insbesondere, wenn die Software selbst fehlerhaft ist. Gleiches gilt, wenn sie als Komponente in ein anderes Produkt integriert wird und dessen Fehlerhaftigkeit verursacht. Neben dem Hersteller des Endprodukts kann daher auch der Hersteller einer fehlerhaften Softwarekomponente haften, sofern diese unter seiner Kontrolle in das Produkt integriert oder mit ihm verbunden wurde. Gerade für Branchen mit stark vernetzten Produkten führt dies zu einer spürbaren Ausweitung des Haftungsrisikos. Das betrifft etwa Automobilindustrie, Medizintechnik, Smart Home und Industrie 4.0.
Die neue Richtlinie knüpft damit an eine Realität an, in der Produkte häufig nicht mehr von einem einzelnen Hersteller vollständig beherrscht werden. Moderne Produkte entstehen arbeitsteilig. Hardware, Betriebssystem, Firmware, Apps, Cloud-Dienste und KI-Komponenten stammen oft von unterschiedlichen Akteuren. Die Richtlinie reagiert darauf, indem sie den Kreis der Haftungsadressaten entlang der Lieferkette erweitert. Neben Herstellern und Komponentenherstellern können unter bestimmten Voraussetzungen auch Importeure, Bevollmächtigte, Fulfillment-Dienstleister, Lieferanten oder Online-Plattformen in Anspruch genommen werden. Für Geschädigte soll dadurch vermieden werden, dass Ansprüche scheitern, weil der eigentliche Hersteller außerhalb der Europäischen Union sitzt oder nicht identifiziert werden kann.
Besonders relevant ist diese Erweiterung für Software- und KI-Anbieter. Wird ein KI-System oder eine Softwarelösung als eigenständiges Produkt bereitgestellt, kommt eine Haftung des Softwareherstellers unmittelbar in Betracht. Wird die Software dagegen in ein anderes Produkt eingebettet, etwa in ein Fahrzeug, ein Medizinprodukt oder ein smartes Haushaltsgerät, kann sie als Komponente haftungsrechtlich relevant werden. Fehlerhafte Software ist damit nicht mehr bloß ein technisches Problem im Hintergrund. Sie kann den Produktfehler des Gesamtprodukts begründen.
Wann Software fehlerhaft ist
Für die Frage, ob ein Produkt fehlerhaft ist, knüpft die Richtlinie weiterhin an die berechtigten Sicherheitserwartungen an. Ein Produkt ist also nicht schon deshalb fehlerhaft, weil es nicht perfekt funktioniert. Entscheidend ist, ob es die Sicherheit bietet, die die Allgemeinheit unter Berücksichtigung aller Umstände berechtigterweise erwarten darf. Bei Software und KI-Systemen wird diese Prüfung jedoch komplexer. Zu berücksichtigen sind nicht nur Darbietung, vorhersehbarer Gebrauch und Zeitpunkt des Inverkehrbringens. Hinzu kommen produktsicherheitsrechtliche Anforderungen, Cybersicherheitsanforderungen, die Fähigkeit eines Produkts zum Weiterlernen sowie nachträgliche Eingriffe wie Updates oder Upgrades.
Gerade bei KI-Systemen wird deutlich, dass der Fehlerbegriff dynamischer wird. Die Richtlinie berücksichtigt ausdrücklich, dass Produkte nach dem Inverkehrbringen weiterlernen oder neue Funktionen erwerben können. Ein lernfähiges System ist nicht schon deshalb fehlerhaft, weil es sich verändert. Der Hersteller muss aber bereits beim Inverkehrbringen absehbare Risiken angemessen berücksichtigen. Er muss technische und organisatorische Vorkehrungen treffen, um unerwartetes oder sicherheitsrelevantes Fehlverhalten zu verhindern. Dazu können etwa Begrenzungen des Lernbereichs, Kontrollmechanismen, Überwachung, Warnhinweise und geeignete Update-Prozesse gehören.
Eine zentrale Rolle spielen außerdem Cybersicherheitsanforderungen. Softwarebasierte Produkte können ihre Sicherheit nicht nur durch Programmierfehler verlieren. Auch Sicherheitslücken, unzureichende Zugriffskontrollen oder fehlende Schutzmechanismen gegen Manipulation können sie unsicher machen. Die neue Richtlinie trägt dem Rechnung. Sie bezieht sicherheitsrelevante Cybersicherheitsanforderungen ausdrücklich in die Fehlerprüfung ein. Damit wird die zivilrechtliche Produkthaftung enger mit dem Produktsicherheitsrecht verzahnt. Für Hersteller bedeutet das: Cybersicherheit ist nicht nur eine technische Nebenfrage, sondern haftungsrechtlich Teil der Produktsicherheit.
Updates als neues Haftungsrisiko
Besonders bedeutsam ist schließlich die Haftung nach dem Inverkehrbringen. Das klassische Produkthaftungsrecht stellte stark auf den Zeitpunkt ab, in dem ein Produkt auf den Markt gelangt. Bei digitalen Produkten entspricht das nur noch bedingt der technischen Wirklichkeit. Softwareprodukte verändern sich häufig nachträglich. Sie erhalten Updates, Upgrades, Sicherheitspatches oder neue Funktionen. Die neue Richtlinie berücksichtigt daher ausdrücklich, dass auch nachträgliche Änderungen einen Produktfehler begründen können. Wird eine Software durch ein Update fehlerhaft oder macht ein Update ein ursprünglich sicheres Gesamtprodukt unsicher, kann Produkthaftung entstehen.
Gleiches gilt, wenn erforderliche Sicherheitsupdates ausbleiben. Gerade bei vernetzten Produkten kann ein Produkt im Zeitpunkt des Inverkehrbringens sicher sein. Später kann es durch neu entdeckte Sicherheitslücken gefährlich werden. Behält der Hersteller weiterhin Kontrolle über das Produkt, endet seine Verantwortung nicht zwingend mit dem ursprünglichen Markteintritt. Das kann etwa der Fall sein, wenn er Softwareupdates, Upgrades oder wesentliche Produktänderungen bereitstellt. Die Richtlinie nähert sich damit einer haftungsrechtlich relevanten Aktualisierungspflicht an: Wer digitale Produkte dauerhaft kontrolliert und aktualisiert, muss auch deren Sicherheit über das Inverkehrbringen hinaus im Blick behalten.
Produktbeobachtung wird zur Daueraufgabe
Hier zeigt sich die enge Verbindung zur Produktbeobachtungspflicht. Schon nach bisherigem deutschem Deliktsrecht endete die Verantwortung des Herstellers nicht zwingend mit dem Inverkehrbringen. Aus § 823 Abs. 1 BGB wurde eine Pflicht abgeleitet, Produkte nach ihrer Markteinführung zu beobachten und auf neu erkannte Gefahren angemessen zu reagieren. Für Software gewinnt diese Pflicht erheblich an Bedeutung. Fehlerberichte, Sicherheitslücken, Kompatibilitätsprobleme oder Angriffe auf Schnittstellen werden häufig erst im praktischen Einsatz sichtbar. Der Hersteller ist regelmäßig am besten in der Lage, solche Informationen zu sammeln, auszuwerten und technische Gegenmaßnahmen zu ergreifen.
Die praktische Folge kann eine Pflicht zu Updates, Sicherheitspatches oder sogar zu einem digitalen Rückruf sein. Eine bloße Warnung wird bei Software nicht immer ausreichen. Gerade bei Sicherheitslücken kann eine öffentliche Warnung sogar problematisch sein. Sie kann Personen erst auf eine ausnutzbare Schwachstelle aufmerksam machen. In solchen Fällen liegt es näher, die Sicherheitslücke durch ein Update zu schließen, bevor oder während Nutzer informiert werden. Die Produktbeobachtungspflicht wird damit im digitalen Kontext zu einer Pflicht zum aktiven Risikomanagement.
Allerdings ist die Reichweite dieser Pflicht nicht grenzenlos. Hersteller können nicht jede denkbare Wechselwirkung ihrer Software mit sämtlichen anderen Produkten, Anwendungen oder Systemumgebungen überwachen. Besonders schwierig ist die Abgrenzung bei Betriebssystemen, Plattformen oder Software mit umfangreichen Schnittstellen. Dort greifen zahlreiche Drittanwendungen auf das System zu. Gleichwohl müssen Hersteller jedenfalls solche Risiken beobachten, die aus der bestimmungsgemäßen Nutzung, aus vorgesehenen Schnittstellen oder aus bekannten Sicherheitsproblemen entstehen können.
Wenn Änderungen das Risikoprofil verschieben
Auch wesentliche Änderungen nach dem Inverkehrbringen gewinnen an Bedeutung. Nimmt der Hersteller selbst ein Update oder Upgrade vor, gelten dafür grundsätzlich dieselben Maßstäbe wie für andere Produktänderungen. Entscheidend ist, ob die Änderung Leistung, Zweck oder Art des Produkts verändert. Ebenso kommt es darauf an, ob sich dadurch das Risikoprofil erheblich verschiebt. Wird ein Produkt durch eine solche Änderung sicherheitsrelevant verändert, kann für die Beurteilung der Fehlerhaftigkeit nicht mehr allein der ursprüngliche Zeitpunkt des Inverkehrbringens maßgeblich sein. Maßgeblich kann vielmehr der Zeitpunkt der Änderung sein.
Nimmt dagegen ein Dritter außerhalb der Kontrolle des ursprünglichen Herstellers eine wesentliche Änderung vor, kann dieser Dritte selbst als Hersteller gelten. Voraussetzung ist, dass er das veränderte Produkt erneut auf den Markt bringt oder in Betrieb nimmt. Das ist insbesondere für professionelle Nutzer von KI-Systemen relevant. Sie können ein System wesentlich anpassen, weitertrainieren oder in einer Weise verändern, die sein Risikoprofil beeinflusst. Die Richtlinie trägt damit dem Umstand Rechnung, dass digitale Produkte nicht statisch bleiben. Durch Updates, Anpassungen und Weiterentwicklung können immer wieder neue haftungsrechtliche Anknüpfungspunkte entstehen.
Insgesamt verschiebt die neue Produkthaftungsrichtlinie den Blick von einem einmaligen Produktzustand hin zu einem fortlaufenden Verantwortungszusammenhang. Bei Software und KI-Systemen entscheidet sich Produktsicherheit nicht nur im Moment des Inverkehrbringens. Sie entscheidet sich auch in der Phase danach: durch Beobachtung, Updates, Sicherheitskorrekturen und den Umgang mit neu erkannten Risiken. Für Unternehmen bedeutet das, dass Produkthaftung künftig stärker mit technischem Lebenszyklusmanagement, Cybersicherheit und dokumentierten Update-Prozessen zusammenwächst.
Produkthaftung wird zum Governance-Thema
Die neue Produkthaftungsrichtlinie macht deutlich: Digitale Produkte lassen sich nicht mehr mit einem rein analogen Haftungsverständnis erfassen. Software ist nicht länger bloß ein technisches Hilfsmittel oder unsichtbares Zubehör. Sie kann selbst ein haftungsrechtlich relevantes Produkt sein. Damit verschiebt sich der Blick auf Produktsicherheit erheblich. Entscheidend ist nicht mehr allein, ob ein Produkt im Zeitpunkt seines Inverkehrbringens physisch ordnungsgemäß konstruiert, hergestellt und instruiert war. Bei vernetzten Produkten, eingebetteter Software und KI-gestützten Anwendungen stellt sich vielmehr die Frage, ob das Produkt über seinen gesamten digitalen Lebenszyklus hinweg sicher bleibt.
Gerade darin liegt der eigentliche Paradigmenwechsel der Reform. Produkte werden zunehmend durch Software geprägt, verändert und fortentwickelt. Updates, Patches, neue Funktionen, Cloud-Anbindungen und KI-Komponenten können die Sicherheit eines Produkts verbessern. Sie können aber auch neue Risiken schaffen. Ein ursprünglich sicheres Produkt kann durch ein fehlerhaftes Update unsicher werden. Ebenso kann ein notwendiger Sicherheitspatch unterbleiben, obwohl eine Schwachstelle bekannt ist. Die Produkthaftung knüpft damit nicht mehr ausschließlich an einen statischen Produktzustand an. Sie rückt dynamische Entwicklungs- und Veränderungsprozesse in den Mittelpunkt.
Updates brauchen Kontrolle
Für Unternehmen bedeutet das: Release-Management, Update-Steuerung und technische Dokumentation werden zu zentralen Compliance-Aufgaben. Wer Software in Produkte integriert oder digitale Funktionen nachträglich verändert, muss diese Änderungen nachvollziehbar steuern. Unternehmen müssen dokumentieren, welche Änderungen vorgenommen wurden, welche Risiken damit verbunden sind und wie sie diese Risiken geprüft und freigegeben haben. Es reicht nicht mehr aus, Updates allein als technische Routine zu behandeln. Sie können haftungsrechtlich relevante Produktänderungen darstellen und müssen deshalb in ein belastbares Kontrollsystem eingebettet werden.
Damit gewinnt auch die Produktbeobachtungspflicht erheblich an Bedeutung. Mit dem Inverkehrbringen endet die Verantwortung des Herstellers nicht. Bei digitalen Produkten beginnt sie in vielerlei Hinsicht erst richtig. Unternehmen müssen Beschwerden, Fehlermeldungen, Sicherheitsvorfälle, Cybersicherheitshinweise, Felddaten und Rückmeldungen aus der Nutzung systematisch erfassen und auswerten. Entscheidend ist, ob sie Risiken frühzeitig erkennen und angemessen reagieren. Die Maßnahmen können von internen Prüfungen über Warnhinweise bis hin zu Updates, Sicherheitspatches oder einem digitalen Rückruf reichen.
Produktbeobachtung als Frühwarnsystem
Die Produktbeobachtung nach dem Inverkehrbringen wird damit zum Schlüssel moderner Produkt-Compliance. Sie ist nicht bloß nachgelagerte Qualitätssicherung, sondern ein fortlaufendes Frühwarnsystem. Gerade bei Software und KI-Systemen entstehen Risiken häufig erst im praktischen Einsatz. Gründe können neue Angriffsmethoden, unvorhergesehene Wechselwirkungen mit anderen Systemen, fehlerhafte Daten, unerwartetes Systemverhalten oder nachträgliche Funktionsänderungen sein. Wer solche Entwicklungen nicht beobachtet, dokumentiert und bewertet, riskiert nicht nur technische Sicherheitslücken. Er riskiert auch haftungsrechtliche und regulatorische Konsequenzen.
Zugleich zeigt die Reform, dass klassische Compliance-Strukturen an Grenzen stoßen können. Viele Prüf- und Freigabeprozesse sind noch immer auf statische Produkte zugeschnitten: Ein Produkt wird entwickelt, geprüft, freigegeben und anschließend vertrieben. Dieses Modell passt nur bedingt zu Produkten, die durch Softwareupdates, Datenverbindungen und KI-Funktionen laufend verändert werden. Digitale Produkte benötigen daher dynamische Governance-Strukturen. Verantwortlichkeiten müssen nicht nur für Entwicklung und Markteinführung klar geregelt sein. Das gilt ebenso für Updates, Überwachung, Schwachstellenmanagement und nachträgliche Produktänderungen.
Besonders herausfordernd ist dabei die arbeitsteilige Realität digitaler Produkte. Hardwarehersteller, Softwareentwickler, Anbieter verbundener digitaler Dienste, Cloud-Dienstleister und KI-Anbieter wirken häufig gemeinsam an einem Produkt mit. Die neue Produkthaftungsrichtlinie trägt dem Rechnung. Sie erweitert den Kreis der Haftungsadressaten und bezieht auch Komponentenhersteller sowie weitere Wirtschaftsakteure stärker ein. Für Unternehmen erhöht das den Druck, Verantwortlichkeiten entlang der Liefer- und Entwicklungskette abzusichern: vertraglich, technisch und organisatorisch. Compliance endet damit nicht an der eigenen Unternehmensgrenze.
Sicherheit endet nicht am Werkstor
Im Ergebnis führt die neue Produkthaftungsrichtlinie nicht nur zu einer Modernisierung einzelner Haftungsregeln. Sie zwingt Unternehmen, Produktsicherheit als fortlaufenden Prozess zu verstehen. Wer digitale Produkte entwickelt, vertreibt oder betreibt, muss Sicherheit, Cybersicherheit, Softwarepflege und Dokumentation zusammendenken. Die entscheidende Frage lautet künftig nicht nur: War das Produkt beim Verkauf sicher? Sondern auch: Wurde seine Sicherheit nach dem Inverkehrbringen angemessen beobachtet, bewertet und erhalten?
Damit wird Produkthaftung endgültig zum Compliance-Thema. Unternehmen, die digitale Produkte weiterhin mit analogen Governance-Modellen steuern, schaffen vermeidbare Lücken bei Sicherheit, Dokumentation und Verantwortlichkeit. Wer dagegen Update-Prozesse, Produktbeobachtung nach dem Inverkehrbringen und klare Verantwortlichkeitsstrukturen frühzeitig etabliert, reduziert nicht nur Haftungsrisiken. Er stärkt auch das Vertrauen in digitale Produkte. Die Reform ist daher mehr als eine Reaktion auf neue Technologien. Sie fordert Unternehmen auf, ihre Produkt-Compliance an die Realität einer vernetzten, softwarebasierten und KI-geprägten Wirtschaft anzupassen.
Dieser Beitrag erschien zuerst in der gedruckten Ausgabe Produkt. Das Heft können Sie hier bestellen.
