Eine Wortverschiebung, die alles ändert
Jahrelang hatte ich das Gefühl, dass Software in einer Art Blase lebte. Nicht im romantischen Sinn, eher in einer bequemen, fast schützenden Grauzone. Wenn ein physisches Produkt jemandem schadete, war Verantwortung eine unmittelbare und konkrete Frage. War es „nur“ Software, glitt das Gespräch oft auf Bugs, Patches, Workarounds und auf jene leicht nachsichtige Annahme, „ist normal, lässt sich ja updaten“.
Die Richtlinie 85/374/EWG zur Produkthaftung sprach im Grunde von beweglichen Sachen, von Greifbarem. Software, definitionsgemäß ungreifbar, passte schlecht hinein. Und wenn eine Norm schlecht passt, passt sie am Ende oft gar nicht.
Ab dem 9. Dezember 2026 schließt sich diese Mehrdeutigkeit mit der Richtlinie (EU) 2024/2853. Die neue Product Liability Directive (PLD) sagt ausdrücklich: Software ist ein Produkt. Und nicht nur Software „in“ einem Gegenstand, sondern alles: standalone, embedded, Firmware, Apps, Cloud, SaaS, KI-Systeme. Unabhängig davon, wo sie läuft und wie sie verteilt wird.
Das ist keine Fußnote. Es ist ein Paradigmenwechsel — und das Interessante daran ist vielleicht, dass es nicht nur jene betrifft, die Code schreiben. Es betrifft, wer entscheidet, was zu bauen ist, wer es verkauft, wer es released, wer es wartet und wer entscheidet, wann Schluss ist.
Verschuldensunabhängige Haftung: der Punkt, an dem sich die Perspektive ändert
Die PLD stützt sich auf ein Konzept, das in der Softwarewelt leicht zu unterschätzen ist, bis es einem auf die Füße fällt: die verschuldensunabhängige Haftung (strict liability).
Praktisch heißt das: Wer einen Schaden durch ein fehlerhaftes Produkt erleidet, muss nicht nachweisen, dass du fahrlässig warst. Er muss deine Entscheidungskette nicht rekonstruieren, muss nicht beweisen, dass du „es besser hättest machen können“. Er muss drei Dinge zeigen: dass das Produkt fehlerhaft war, dass es einen Schaden gab, und dass ein Kausalzusammenhang besteht.
Wer gewohnt ist, in Begriffen wie „wir haben das Möglichste getan“, „es war ein Edge Case“, „es war eine Drittanbieter-Abhängigkeit“ zu denken, vollzieht eine spürbare mentale Verschiebung. Sorgfalt zählt weiterhin, klar — aber nicht mehr als automatischer Schild.
Und es gibt ein Stück, das alles konkreter macht: die Richtlinie führt Vermutungsmechanismen ein.
Wenn es dem Geschädigten „übermäßig schwierig“ ist, den Defekt oder den Kausalzusammenhang zu beweisen — was bei komplexer Software oder KI-Systemen fast die Regel ist —, kann das Gericht Defekt und Kausalität vermuten. Es kann den Hersteller auch anweisen, die technische Dokumentation vorzulegen, die in „zugänglicher und verständlicher“ Form präsentiert werden muss. Wenn du nicht kooperierst, kann diese fehlende Kooperation zu deinem Nachteil werden.
Ohne Umschweife: In vielen Fällen wirst du nachweisen müssen, dass die Software nicht fehlerhaft war. Und dafür braucht es Beweise. Spuren. Begründete Entscheidungen. Daten.
Wer Produkt macht: die Verantwortung beginnt lange vor dem Code
Wenn von Verantwortung die Rede ist, schaut der Instinkt auf die Entwicklung. Aber die PLD nimmt auch das, was davor liegt, unter die Lupe — die Produktentscheidungen.
Fehlerhaftigkeit wird an den vernünftigen Erwartungen an Sicherheit gemessen. Ein Produkt ist fehlerhaft, wenn es nicht das Sicherheitsniveau bietet, das eine Person berechtigterweise erwarten darf. Dieses Urteil hängt davon ab, wie du das Produkt präsentierst, vom vernünftigerweise vorhersehbaren Gebrauch, vom Zeitpunkt der Inbetriebnahme. Aber auch von sehr modernen Elementen, etwa der Vernetzung mit anderen Systemen, der Konformität mit Cybersecurity-Anforderungen und sogar der Lernfähigkeit.
Hier denke ich daran, wie oft eine Roadmap aus Trade-offs entsteht, die rein „business“ wirken: früher liefern, ein Sicherheits-Feature streichen, die Hardening-Phase verschieben, eine KI-Komponente integrieren, weil „es schick ist“ und die Konkurrenz sie schon hat.
Mit der PLD sind das nicht nur Produktentscheidungen. Es sind Entscheidungen, die in einem Streitfall relevant werden können.
Wenn du in den kommerziellen Spezifikationen eine bestimmte Zuverlässigkeit oder einen bestimmten Sicherheitsstandard versprichst, schaffst du eine Erwartung. Wenn du eine KI-Komponente integrierst, die ihr Verhalten mit der Zeit ändert, übernimmst du auch die Verantwortung für dieses künftige Verhalten. Und die Unvorhersehbarkeit der KI ist nach Anlage der Richtlinie keine Verteidigung.
Die praktischste Konsequenz, finde ich: das Risk Assessment zieht ins Produktmanagement ein. Nicht als Dokument, das man einmal macht und vergisst, sondern als Gewohnheit.
Und vor allem zieht die Dokumentation der Entscheidungen ein. Nicht aus Bürokratie, sondern weil in einigen Jahren erklärt werden muss, warum eine bestimmte Wahl zu jenem Zeitpunkt vernünftig war. Architecture Decision Records, die heute viele Teams nutzen, um nicht den Faden zu verlieren, beginnen, wie ein Stück deiner Verteidigung auszusehen.
Wer verkauft: der Vertrag ist kein Schild mehr
Es gibt einen verbreiteten Reflex in der Software: wenn das Risiko steigt, fügt man eine Klausel hinzu. Haftungsbeschränkung, Cap, Freistellung, Disclaimer in den AGB.
Die PLD ist hier ziemlich brutal: Die in der Richtlinie vorgesehene Haftung kann nicht vertraglich ausgeschlossen oder begrenzt werden, wenn der Schaden eine natürliche Person betrifft. Das gilt im B2C, und es trifft dich praktisch auch im B2B, sobald es Endnutzer-Personen gibt.
Das heißt nicht, dass Verträge nutzlos werden. Es heißt, dass sie ihre Funktion ändern müssen.
Insbesondere müssen im B2B-Verhältnis die Verantwortlichkeiten entlang der Supply Chain geklärt werden. Wenn du für einen Kunden entwickelst, der das Produkt unter eigener Marke vermarktet — wer ist „Hersteller“ im Sinne der PLD? Wenn deine Software Komponente in einem größeren System ist — wie regelt sich der Regress zwischen den Parteien? Du kannst die Verantwortung nach außen nicht eliminieren, aber du kannst und musst klären, was zwischen euch geschieht.
Dann gibt es ein oft von Sales und Marketing unterschätztes Stück: die kommerziellen Versprechen.
Demos, Broschüren, Claims wie „höchste Sicherheitsstandards“, Slides mit „Zero Downtime“, Pricing-Seiten, die bestimmte Garantien implizieren. All das trägt dazu bei zu definieren, was der Nutzer berechtigt war zu erwarten. Und fließt damit indirekt in die Bewertung der Fehlerhaftigkeit ein.
Schließlich Versicherung und Pricing. Die klassische Berufshaftpflicht deckt Fahrlässigkeit, nicht zwangsläufig die Strict Liability. Wahrscheinlich werden viele Unternehmen Deckungen und Höchstgrenzen überarbeiten müssen, einschließlich Cybersecurity, Datenverlust und immaterieller Schäden. Diese Kosten landen im Preis. Mit einem interessanten Nebeneffekt: Wer sich früh gut aufstellt, kann Compliance in ein glaubwürdiges Wettbewerbsargument verwandeln.
Wer released: jeder Deploy hinterlässt Spuren
Wenn du an Releases, DevOps, QA arbeitest oder die Person bist, die am Ende sagt „okay, geht in Produktion“, ist das vielleicht der konkreteste Teil.
In moderner Software ist das Release nicht das Ende. Es ist der Anfang. Denn fast immer behält der Hersteller Kontrolle über Updates, Remote-Zugriff, Feature Flags, Patches, Sicherheits-Updates.
Die PLD im Zusammenspiel mit dem Normumfeld macht einen „erst releasen, dann sehen wir weiter“-Ansatz sehr riskant. Das Ausbleiben von Sicherheits-Updates für bekannte Schwachstellen kann selbst als Defekt gelten. Und ein Update, das ein Problem einführt, kann als wesentliche Änderung gewertet werden — mit Auswirkungen auch auf die Fristen.
Die Grundhaftung läuft 10 Jahre, bei latenten Personenschäden bis zu 25. Wenn ich diese Zahlen lese, frage ich mich immer, ob wir wirklich die Kultur haben, Beweise über einen solchen Horizont zu bewahren. Denn es reicht nicht, die Dinge gut gemacht zu haben — man muss es auch belegen können.
Hier kommt die Nachverfolgbarkeit ins Spiel.
Wissen, was eine bestimmte Version zu einem bestimmten Datum enthielt. Welche Abhängigkeiten. Welche bekannten Schwachstellen. Welche Tests durchgeführt wurden. Wer freigegeben hat. Was entschieden wurde und warum.
Der SBOM (Software Bill of Materials) wird zentral. Auch weil der Cyber Resilience Act ihn in vielen Fällen verpflichtend macht, und die CI/CD-Pipeline wird de facto zur Compliance-Infrastruktur: automatische SBOM-Generierung (CycloneDX oder SPDX), Vulnerability-Scanning, Audit-Trail der Deploys, Aufbewahrung der Artefakte.
Und ein Detail, das banal scheint, bis man es erlebt: auch die Entscheidung, einen Patch nicht zu veröffentlichen, ist eine Entscheidung. Wenn du heute aus vernünftigen Gründen verschiebst, ist das wahrscheinlich okay. Aber in fünf Jahren wirst du erklären müssen, warum es vernünftig war. Besser, du hast diese Erklärung schriftlich, solange die Erinnerung frisch ist.
Wer entwickelt: Dokumentieren ist keine Bürokratie, sondern verteidigbares Gedächtnis
Für Entwicklerinnen verlangt die PLD keine Magie. Sie sagt nicht „schreib perfekten Code“, denn den gibt es nicht. Sie verlangt im Kern, den Pfad rekonstruierbar zu machen.
Automatisierte Tests, die das erwartete Verhalten zeigen. Nachvollziehbare Code Reviews. Integrierte Sicherheitsscans. Commit-Nachrichten, die nicht „fix“ lauten. Tickets, die den Kontext erzählen.
Vieles davon tun Teams bereits, oft unregelmäßig. Der Unterschied: Aus „Best Practice“ wird auch ein Stück Schutz.
Und hier ist die Verbindung zum Cyber Resilience Act direkt: Wenn du Anforderungen wie Secure by Design, Schwachstellenmanagement und SBOM nicht erfüllst, kann diese Nichtkonformität eine Defektbehauptung im Sinne der PLD verstärken. Normen leben nicht mehr in luftdichten Schubladen.
Der Mythos B2B als Freizone
Die Versuchung verstehe ich: „Wir verkaufen nur an Unternehmen, also betrifft uns das nicht.“
Aber schau einen Moment auf die realen Nutzer.
Software für die Verwaltung: Bürgerinnen. HR-Systeme: Beschäftigte. E-Learning: Studierende. Parkhäuser: Autofahrerinnen. Gesundheit: Patientinnen. In all diesen Fällen ist der Kunde eine Organisation, aber die Wirkung trifft natürliche Personen.
Hinzu kommt: Die PLD denkt auch in Komponenten. Wenn du ein Modul, eine API, einen Microservice lieferst, der im Produkt eines anderen landet, kannst du als Hersteller der Komponente gelten.
Und es gibt die Erweiterung der ersatzfähigen Schäden: Zerstörung oder Korruption von Daten, die nicht zu beruflichen Zwecken genutzt werden, ohne Mindestschwelle und ohne Höchstgrenze. Ein Punkt, den viele Unternehmen noch nicht verarbeitet haben.
Open Source: geschützt, aber kein Schlupfloch
Die Richtlinie schließt Open-Source-Software aus, die außerhalb einer kommerziellen Tätigkeit entwickelt oder bereitgestellt wird. Aber wenn es eine Gegenleistung gibt, auch in Form personenbezogener Daten, ändert sich die Lage.
Und vor allem: Wenn du Open Source in ein kommerzielles Produkt integrierst, fällt die Verantwortung für eventuelle Defekte auf jenen, der integriert und vermarktet.
Das verschiebt den Schwerpunkt: Es ist nicht mehr nur Lizenz-Compliance. Es wird technisches und rechtliches Risikomanagement. Auswahl der Abhängigkeiten, Vetting-Prozesse, ernsthaftes Vulnerability Management — und wieder SBOM.
Die PLD steht nicht allein: ein Ökosystem, das ineinandergreift
Mit Blick auf das europäische Bild entsteht der Eindruck: Die EU baut eine präzise Idee von „Software als Produkt“ auf und stützt sie von mehreren Seiten ab.
Die PLD greift mit dem Cyber Resilience Act ineinander (Cybersecurity by Design, SBOM, Vulnerability Management), mit dem AI Act (der KI-Anbieter auch im PLD-Sinne zu Herstellern macht), mit der DSGVO (Data Breach und Schäden), mit NIS2, mit der GPSR, mit der Representative Actions Directive für Sammelklagen und sogar mit dem European Accessibility Act.
Es geht nicht darum, alle Kürzel zu kennen. Es geht darum, dass eine Lücke in einem Bereich sich ausbreiten und einen Streit in einem anderen verstärken kann. Compliance wird zum System.
Die italienische Umsetzung: eine zu beobachtende Wahl
Italien muss die PLD bis zum 9. Dezember 2026 umsetzen. Da es eine Richtlinie der maximalen Harmonisierung ist, gibt es wenig Raum für „kreative Auslegungen“. Aber ein wichtiger Spielraum bleibt: die Verteidigung des Stands der Technik.
Im Kern kann der Staat entscheiden, ob er die Idee beibehält, dass der Hersteller nicht haftet, wenn der Defekt mit dem zum Zeitpunkt der Inbetriebnahme verfügbaren Wissen nicht erkennbar war. Oder ob er sie streicht.
Das ist kein Detail und es lohnt sich, das zu beobachten. Denn es ändert das Risikoprofil — besonders bei komplexer Software und KI-Szenarien.
Nicht nur Risiken: der Teil, der zum Vorteil werden kann
Liest man sie im Katastrophenmodus, wirkt die PLD nur wie Kosten. Mehr Dokumentation, mehr Prozesse, mehr Versicherung, mehr interne Diskussionen.
Aber es gibt eine andere Lesart, vielleicht die nützlichste, wenn jetzt entschieden werden muss.
Die PLD schafft ein Spielfeld, auf dem Qualität, Sicherheit und Transparenz der Lieferkette zu messbaren Wettbewerbsvorteilen werden. Nicht mehr „vertraut uns“, sondern „wir haben Prozesse und Belege, die einer formalen Anfrage standhalten — und wenn nötig auch einem Gericht“.
Für Software-Häuser kann es ein starkes Argument bei Enterprise und Verwaltung werden, vor der Deadline compliant zu sein. Für Beratung und Systemintegration eröffnet sich eine riesige Nachfrage nach Kompetenzen, die heute, zumindest im italienischen KMU-Gefüge, nicht weit verbreitet ist. Für Produktverantwortliche ist es ein Anreiz, in Dinge zu investieren, die auf lange Sicht die Software wirklich besser machen.
Ein Schluss ohne Triumphalismus
Vierzig Jahre lang konnten wir Software als etwas Besonderes denken. Flexibler, aktualisierbarer, verzeihlicher.
Die PLD sagt: Diese Sonderstellung ist vorbei. Software ist ein Produkt, mit Verantwortlichkeiten ähnlich denen einer Maschine, eines Medizinprodukts, eines Autos.
Es betrifft nicht nur jene, die Code schreiben. Es betrifft Roadmaps und Trade-offs. Es betrifft Verträge und kommerzielle Versprechen. Es betrifft Releases und Support, sogar das End-of-Life.
Das Sinnvollste heute scheint mir, die Frage zu verschieben — von „wie schützen wir uns“ zu „wie machen wir unsere Arbeitsweise belegbar“. Sich vorzubereiten heißt nicht nur, juristische Pflaster zu kleben. Es heißt, das Handwerk besser zu machen, mit mehr Gedächtnis, mehr Nachverfolgbarkeit und weniger blindem Vertrauen darauf, dass es „später schon klappt“.
Die Frage ist nicht, ob man sich vorbereitet. Sondern wie schnell.
Hauptquellen: Richtlinie (EU) 2024/2853; Cyber Resilience Act (Verordnung EU 2024/2847); Analysen von Reed Smith, IBA, Fladgate, Taylor Wessing, Clyde & Co, DLA Piper, Hogan Lovells, ICLG, Covington.
Was du mitnimmst
Die PLD führt verschuldensunabhängige Haftung für Software ein: ein Bug ist nicht mehr nur Betriebsärgernis, sondern potenziell Produktdefekt.
Logging, Audit und SBOM werden zu nicht verhandelbaren Anforderungen — wer nicht beweisen kann, was passiert ist, kann sich nicht verteidigen.
Open Source ist kein Schlupfloch: Wer eine Komponente integriert, haftet für den Defekt, auch wenn er stromaufwärts entsteht.
Drei sofort zu überarbeitende Vertragsklauseln: explizite Garantie und SLAs zu Sicherheit, abgestimmtes Incident-Verfahren, klare Verantwortungszuteilung gegenüber dem Endnutzer.
Wer mit Prä-PLD-Verträgen arbeitet, häuft rechtliches Risiko an, das beim ersten Streit zutage tritt.
Fragen & Antworten
Was ändert sich für Software ab dem 9. Dezember 2026?
Die neue Product Liability Directive (Richtlinie EU 2024/2853) tritt in Kraft und schließt Software ausdrücklich in die Kategorie Produkt ein. Das heißt, der Hersteller haftet für Schäden durch Defekte unabhängig von Fahrlässigkeit — verschuldensunabhängige Haftung wie bei Haushaltsgeräten oder Arzneimitteln. Bugs hören auf, bloßes Betriebsärgernis zu sein, und werden potenziell zu Produktdefekten mit unmittelbaren rechtlichen Folgen.
Wie ändert sich die Produktroadmap mit der PLD?
In drei Richtungen: (1) Logging und Audit werden zu nicht-optionalen Anforderungen — ohne Nachweis dessen, was passiert ist, keine Verteidigung; (2) die Vorhaltefrist für Sicherheits-Updates hat rechtlichen Wert — die Verantwortung endet nicht mit dem Release, sondern am Ende des erklärten Supports; (3) Vulnerability Management wird zum Produktprozess, keine Ad-hoc-Tätigkeit. Die Roadmap kann nicht mehr nur Features enthalten — sie muss auch Wartung enthalten.
Was ändert sich für jene, die Open-Source-Komponenten nutzen?
Viel. Der Hersteller der finalen Software haftet für Defekte auch dann, wenn diese aus integrierten Open-Source-Komponenten kommen. Er kann die Verantwortung nicht auf das Open-Source-Projekt abwälzen (das oft keine Rechtspersönlichkeit hat). Praktische Folge: zwei Pflichtbewegungen — Due Diligence über die integrierten Projekte (Gesundheit, Governance, Patch-Historie) und ein SBOM, der schnelle Reaktion auf Schwachstellen erlaubt. Es ist nicht anti-Open-Source — es ist Verantwortung der Lieferkette.
Wie sind Verträge für B2B-Software zu aktualisieren?
Drei Klauseln zu überarbeiten: (1) explizite Garantie und Service-Level zur Sicherheit, nicht generisch; (2) abgestimmtes Incident-Management-Verfahren (Meldefristen, Verantwortlichkeiten der Behebung); (3) klare vertragliche Allokation zwischen Verantwortung gegenüber dem Endnutzer und Verantwortung zwischen Anbieter und Enterprise-Kunde. Wer heute mit Prä-PLD-Vertragsmustern arbeitet, häuft rechtliches Risiko an, das beim ersten Streitfall zutage tritt.
Der Autor
