Ab Dezember 2026 haftet Software wie jedes andere Produkt

Bei Medizinsoftware stehen MDR, Risikoklasse und Benannte Stelle meist im Vordergrund. Die Produkthaftung beantwortet eine weitere zentrale Frage: Wer trägt die Verantwortung, wenn Software einen Schaden verursacht? Ab dem 9. Dezember 2026 gilt dafür ein modernisierter EU-Rahmen für Produkte, die ab diesem Tag in Verkehr gebracht oder in Betrieb genommen werden [1].

Die Richtlinie (EU) 2024/2853 stellt klar: Software ist ein Produkt. Das gilt unabhängig davon, ob sie auf einem Gerät installiert, über ein Netzwerk genutzt, aus der Cloud abgerufen oder als Software as a Service bereitgestellt wird [1]. Für Medizinsoftware rücken dadurch Updates, Beweisführung und Haftungsvorsorge noch enger zusammen.

Executive Summary

1. Eine neue Richtlinie mit festem Stichtag

Die Richtlinie (EU) 2024/2853 ersetzt die Produkthaftungsrichtlinie von 1985. Sie gilt für Produkte, die ab dem 9. Dezember 2026 in Verkehr gebracht oder in Betrieb genommen werden. Für frühere Produkte bleibt die bisherige Richtlinie maßgeblich. Bis zu diesem Stichtag müssen die Mitgliedstaaten die Vorgaben in nationales Recht umsetzen [1] [3].

Der Kern bleibt eine verschuldensunabhängige Haftung. Die geschädigte Person muss Fehler, Schaden und Kausalzusammenhang darlegen. Ein Verschulden des Herstellers muss sie nicht beweisen. Ersatzfähig sind Tod und Körperverletzung, einschließlich medizinisch anerkannter psychischer Beeinträchtigungen. Erfasst werden außerdem Schäden an nicht beruflich genutzten Sachen sowie die Zerstörung oder Beschädigung nicht beruflich genutzter Daten [1].

Die Richtlinie harmonisiert den Rahmen grundsätzlich vollständig. Vertragliche Haftungsausschlüsse gegenüber geschädigten Personen sind unwirksam. Auch nationale Haftungshöchstgrenzen sind in diesem Rahmen nicht vorgesehen [1].

2. Software ist ein Produkt, auch in der Cloud

Artikel 4 nennt Software ausdrücklich als Produkt. Erwägungsgrund 13 stellt klar, dass der Bereitstellungsweg keine Rolle spielt. Die Einordnung reicht von Firmware und Apps bis zu KI-Systemen. Sie umfasst Cloud-Dienste und SaaS-Modelle. Entwickler oder Anbieter von Software werden für diesen Zweck als Hersteller behandelt [1].

Die Abgrenzung ist wichtig. Reiner Quellcode und bloße Inhalte digitaler Dateien gelten nicht als Produkt. Nicht gewerblich entwickelte oder bereitgestellte freie und quelloffene Software ist ebenfalls ausgenommen. Wird solche Software im Rahmen einer Geschäftstätigkeit in ein Produkt integriert, bleibt der Hersteller des Gesamtprodukts für dessen Sicherheit verantwortlich [1].

Auch die Lieferkette rückt stärker in den Blick. Eine Komponente kann ein physischer oder digitaler Bestandteil sein. Dazu gehört ein verbundener digitaler Dienst, wenn das Produkt ohne ihn Funktionen nicht ausführen kann. Hersteller des Produkts und Hersteller einer fehlerhaften Komponente können nebeneinander haften. Wer ein Produkt außerhalb der Kontrolle des ursprünglichen Herstellers wesentlich verändert und danach bereitstellt, kann selbst als Hersteller gelten [1].

3. Was für Medizinsoftware besonders zählt

Updates werden zur Haftungsfrage. Schon die alte Richtlinie kannte eine Entlastung, wenn ein Fehler bei Inverkehrbringen nicht bestand oder erst später entstand [3]. Die neue Richtlinie schränkt diese Einrede ein. Sie greift nicht, wenn ein Fehler auf einem verbundenen Dienst, auf Software einschließlich Updates oder Upgrades, auf fehlenden sicherheitsnotwendigen Updates oder auf einer wesentlichen Änderung beruht. Voraussetzung ist jeweils, dass dies in der Kontrolle des Herstellers liegt [1].

Kontrolle kann auch bestehen, wenn ein Hersteller Updates durch Dritte bereitstellen lässt, sie autorisiert oder als Teil des Produkts darstellt. Liegt die Installation eines bereitgestellten Sicherheitsupdates außerhalb der Herstellerkontrolle, etwa weil ein Nutzer das Update nicht installiert, ist der Einzelfall anders zu bewerten. Die Richtlinie begründet keine eigenständige Update-Pflicht. Sie regelt die Haftungsfolgen, wenn eine für die Produktsicherheit maßgebliche Pflicht nicht erfüllt wird [1].

Die Beweislage wird zugänglicher. Nationale Gerichte können bei plausibel begründeten Klagen die Offenlegung relevanter Beweismittel anordnen. Unterbleibt eine angeordnete Offenlegung, kann die Fehlerhaftigkeit vermutet werden. Das gilt auch bei Verstößen gegen verbindliche Sicherheitsanforderungen oder bei einer offensichtlichen Fehlfunktion [1].

Bei übermäßigen Schwierigkeiten durch technische oder wissenschaftliche Komplexität können Gerichte Fehler, Kausalität oder beides vermuten. Anspruchsteller müssen dafür die jeweilige Wahrscheinlichkeit belegen. Alle Vermutungen bleiben widerlegbar. Geschäftsgeheimnisse sind durch geeignete gerichtliche Maßnahmen zu schützen. Für medizinische Software erhöht das die Bedeutung einer klar aufgebauten und abrufbaren Technischen Dokumentation [1].

Die MDR verweist auf finanzielle Vorsorge. Nach Artikel 10 Absatz 16 MDR müssen Hersteller, angemessen zu Risikoklasse, Produktart und Unternehmensgröße, eine ausreichende finanzielle Deckung für ihre potenzielle Haftung vorhalten [2]. Zugleich verlangt die MDR dokumentiertes Risikomanagement, technische Dokumentation, ein Qualitätsmanagementsystem, ein Verfahren für Änderungen und Marktbeobachtung. Die Produkthaftungsrichtlinie macht diese Nachweise nicht zu einer automatischen Haftungsfreistellung. Sie stärken jedoch die Fähigkeit, Lifecycle, Entscheidungen und Verantwortlichkeiten nachvollziehbar darzustellen [2].

4. Beispiel: Dosierungssoftware mit Update im Jahr 2027

Eine nach MDR zertifizierte Medizinsoftware berechnet Dosierungen. Version 3 kommt im Januar 2027 auf den Markt. Ein späteres Update führt einen Rechenfehler ein. Alternativ bleibt eine bekannte Sicherheitslücke offen, obwohl ein notwendiges Sicherheitsupdate in der Kontrolle des Herstellers liegt. Wird eine Patientin dadurch geschädigt, kann der Hersteller sich nicht allein darauf berufen, dass der Fehler erst nach der ursprünglichen Auslieferung entstanden sei [1].

Ein Update, das ein Produkt wesentlich verändert, ist auch für Fristen relevant. Die zehnjährige Ausschlussfrist beginnt für das wesentlich geänderte Produkt grundsätzlich erneut, wenn die Änderung bereitgestellt wird. Die Bewertung einer wesentlichen Änderung bleibt eine Einzelfallfrage und wird sich mit der nationalen Umsetzung und Rechtsprechung weiter konkretisieren [1].

5. Was Hersteller jetzt vorbereiten können

Eine nach Anhang I Abschnitt 17.2 MDR geführte Dokumentation zu Software-Lifecycle, Risikomanagement, Verifizierung und Validierung bietet dafür eine belastbare Basis [2]. Sie ersetzt keine rechtliche Einzelfallbewertung. Sie sorgt jedoch dafür, dass Sicherheits- und Entwicklungsentscheidungen über den Lifecycle hinweg nachvollziehbar bleiben.

Einordnung

Konformität mit der MDR verhindert Haftungsfälle nicht automatisch. Ein Hersteller kann sich entlasten, wenn der Fehler gerade auf der Einhaltung verbindlicher rechtlicher Anforderungen beruht. Auch die Entwicklungsrisikoeinrede bleibt grundsätzlich vorgesehen. Die Mitgliedstaaten können hierzu innerhalb der Richtlinie besondere Regelungen treffen [1].

Die Richtlinie ersetzt nationale Umsetzungsgesetze nicht. Wie Gerichte wesentliche Softwareänderungen oder übermäßige Beweisschwierigkeiten bewerten, wird sich erst in der Anwendung zeigen. Schäden an ausschließlich beruflich genutztem Eigentum oder ausschließlich beruflich genutzten Daten fallen nicht in den geregelten Schadenskatalog. Vertragliche Ansprüche und Datenschutzrecht bleiben daneben bestehen [1]. Dieser Beitrag dient der fachlichen Einordnung und ersetzt keine Rechtsberatung.

Fazit

Ab dem 9. Dezember 2026 erfasst die EU-Produkthaftung Medizinsoftware ausdrücklich. Wer Updates kontrolliert, trägt auch Verantwortung für Fehler aus Updates oder fehlenden sicherheitsnotwendigen Korrekturen innerhalb dieser Kontrolle. Hersteller schaffen eine belastbare Grundlage, wenn sie Update-Prozess, technische Dokumentation, Lieferkette und finanzielle Vorsorge jetzt gemeinsam ausrichten.