Produkthaftung Software: das gilt ab Dezember 2026

Ein Kunde ruft an: Die Buchungs-App, die du vor zwei Jahren gebaut hast, hat über ein fehlerhaftes Update die Termindaten hunderter Nutzer durcheinandergebracht. Einer davon verlangt jetzt Schadenersatz für die Wiederherstellung seiner Daten – nicht vom Kunden, sondern von dir, der Agentur, die die Software entwickelt hat. Bisher wäre so ein Fall juristisch heikel, aber mit guten Verteidigungschancen gewesen. Ab dem 9. Dezember 2026 ändert sich die Ausgangslage grundlegend: Dann gilt in der gesamten EU eine neue Produkthaftung, die Software ausdrücklich als Produkt behandelt.

Für kleine Agenturen ist das kein juristisches Randthema. Wer Apps, Plugins, Templates oder ganze Portale entwickelt, verkauft künftig im rechtlichen Sinne möglicherweise ein Produkt – mit allem, was an verschuldensunabhängiger Haftung daran hängt. Dieser Beitrag ordnet ein, was sich ändert, wen es trifft und was du vorbereiten solltest. Vorab und ausdrücklich: Das ist eine journalistische Einordnung, keine Rechtsberatung. Geht es im konkreten Fall um deine Haftung, gehört das in die Hände einer fachkundigen Kanzlei.

Produkthaftung Software: Das steckt hinter der neuen EU-Richtlinie

Die Grundlage ist die Richtlinie (EU) 2024/2853 vom 23. Oktober 2024. Sie ersetzt die alte Produkthaftungsrichtlinie aus dem Jahr 1985 – eine Zeit, in der Software schlicht kein Thema war. Die Mitgliedstaaten müssen die neuen Regeln bis zum 9. Dezember 2026 in nationales Recht umsetzen; in Deutschland geschieht das über ein reformiertes Produkthaftungsgesetz. Entscheidend ist der Stichtag: Die neuen Regeln gelten für Produkte, die ab dem 9. Dezember 2026 in Verkehr gebracht oder in Betrieb genommen werden. Was vorher auf den Markt kam, bleibt unter dem alten Recht.

Der Kern der Reform ist eine einzige, folgenreiche Ausweitung des Produktbegriffs. Künftig gelten laut Richtlinie ausdrücklich auch Software – von Betriebssystemen über Firmware und Apps bis zu KI-Systemen – als Produkte, und zwar unabhängig von der Art der Bereitstellung. Ob die Software lokal installiert, als Cloud-Dienst oder im SaaS-Modell genutzt wird, spielt keine Rolle. Sogar digitale Konstruktionsdateien, die etwa einen 3D-Drucker steuern, fallen darunter. Ausgenommen bleibt freie und quelloffene Software, die außerhalb einer Geschäftstätigkeit entwickelt und bereitgestellt wird. Aber Achtung: Wer solche Open-Source-Komponenten in ein kommerzielles Produkt einbaut, haftet für das Gesamtprodukt wie ein Hersteller.

Wichtig ist der Unterschied zur Produzentenhaftung, die viele im Kopf haben. Die Produkthaftung ist verschuldensunabhängig. Es kommt also nicht darauf an, ob dir ein Vorwurf zu machen ist – es genügt, dass das Produkt fehlerhaft war und dadurch ein Schaden entstanden ist. Dieser Unterschied ist der eigentliche Hebel der Reform.

Was als Fehler gilt – und warum Sicherheits-Updates dazugehören

Spannend für die Praxis ist, was die Richtlinie als Fehler einstuft. Ein Produkt ist fehlerhaft, wenn es nicht die Sicherheit bietet, die man berechtigterweise erwarten darf. Bei Software zählt dazu ausdrücklich auch die Cybersicherheit: Fehlende oder zu spät gelieferte Sicherheits-Updates können einen Produktfehler begründen. Die Begründung ist einleuchtend – anders als bei einer Bohrmaschine behält der Hersteller bei vernetzter Software nach der Auslieferung die Kontrolle über das Produkt. Verändert ein Update das Produkt oder unterbleibt ein nötiges Sicherheitsupdate, bleibt die Haftung bestehen.

Damit verzahnt sich die Produkthaftung mit anderen Pflichten, die Agenturen ohnehin schon im Nacken sitzen. Die Einhaltung verbindlicher Sicherheitsvorgaben – etwa aus dem AI Act, dem Cyber Resilience Act oder NIS2 – wird zum Maßstab für die Fehlerfreiheit. Wer die dort geforderten Standards reißt, riskiert, dass das Produkt allein deshalb als fehlerhaft gilt. Dass unter Zeitdruck entstandener oder KI-generierter Code überdurchschnittlich oft bekannte Schwachstellen mitbringt, bekommt vor diesem Hintergrund eine neue Dimension.

Die Beweislast verschiebt sich zugunsten der Geschädigten

Die zweite große Neuerung ist weniger sichtbar, aber mindestens so wichtig: Die Richtlinie erleichtert geschädigten Personen den Nachweis erheblich. Bisher scheiterten Klagen oft daran, dass Betroffene die Fehlerhaftigkeit einer komplexen Software kaum belegen konnten. Das ändert sich gleich doppelt.

Zum einen gibt es eine Offenlegungspflicht. Gerichte können Unternehmen verpflichten, relevante Beweismittel herauszugeben, wenn ein Anspruch plausibel dargelegt ist und die Herausgabe verhältnismäßig erscheint – Geschäftsgeheimnisse werden dabei gesondert geschützt. Zum anderen greifen gestaffelte Vermutungen. Die Fehlerhaftigkeit wird vermutet, wenn ein Unternehmen seiner Offenlegungspflicht nicht nachkommt oder gegen verbindliche Sicherheitsanforderungen verstößt. Die Kausalität zwischen Fehler und Schaden wird vermutet, wenn der Fehler feststeht und der Schaden typischerweise dazu passt. Und für Fälle, in denen der Nachweis wegen übermäßiger technischer oder wissenschaftlicher Komplexität besonders schwer ist – die Richtlinie nennt KI und maschinelles Lernen ausdrücklich – reicht es, wenn die geschädigte Person eine hinreichende Wahrscheinlichkeit darlegt.

Für Agenturen heißt das praktisch: Wer im Streitfall nicht sauber dokumentieren kann, was eine Software konnte, welche Sicherheitsstandards sie erfüllte und welche Updates wann ausgeliefert wurden, steht schlechter da als früher. Dokumentation wird vom lästigen Nebenprodukt zum Haftungsschutz.

Wer haftet – und ist deine Agentur überhaupt Herstellerin?

Die entscheidende Frage für dich lautet: Giltst du als Herstellerin? Haftungsadressat ist in erster Linie der Hersteller des Produkts – also derjenige, der es entwickelt oder herstellt. Dem Hersteller gleichgestellt ist, wer unter eigenem Namen oder eigener Marke auftritt. Daneben können Importeure, EU-Bevollmächtigte und Fulfillment-Dienstleister in die Haftung geraten, und mehrere Verantwortliche haften gesamtschuldnerisch – jeder also potenziell auf den vollen Schaden.

Hier liegt zugleich die wichtigste Differenzierung für kleine Agenturen. Nicht jede Zeile Code, die du schreibst, ist automatisch ein haftungsrelevantes Produkt. Ein individuell für einen einzigen Kunden erstelltes Werk wird juristisch eher als Dienst- oder Werkleistung eingeordnet und unterliegt dann primär dem Vertragsrecht, nicht der Produkthaftung. Klarer im Fokus stehen dagegen produktisierte Angebote: ein Plugin, das du an viele Kunden verkaufst, ein eigenes SaaS-Tool, eine App im Store, ein White-Label-Produkt, ein kommerzielles Theme. Je stärker du etwas als fertiges, verteiltes Produkt in Verkehr bringst, desto eher bist du in der Rolle der Herstellerin. Die Grenze ist im Einzelfall fließend und juristisch noch nicht ausgefochten – genau deshalb lohnt der frühe Blick auf das eigene Portfolio.

Wichtig zur Einordnung des Risikos: Die Produkthaftung schützt natürliche Personen, nicht dein Geschäftskundenverhältnis. Ersatzfähig sind Tod und Körperverletzung, Sachschäden an privat genutzten Gegenständen sowie neu auch die Zerstörung oder Beschädigung von Daten, die nicht ausschließlich beruflich genutzt werden – inklusive der Kosten für die Wiederherstellung. Reine Vermögensschäden, Datenschutzverstöße oder Diskriminierung fallen dagegen nicht unter die Produkthaftung, sondern werden über andere Wege geltend gemacht. Und: Die im deutschen Produkthaftungsgesetz bisher geltende Haftungshöchstgrenze von 85 Millionen Euro entfällt.

Was du als Agentur jetzt tun kannst

Panik ist der falsche Reflex, Vorbereitung der richtige. Bis zum Stichtag bleibt Zeit, und die meisten sinnvollen Schritte zahlen ohnehin auf gute Arbeit ein.

Verschaffe dir zuerst Klarheit über dein eigenes Angebot. Trenne gedanklich das individuelle Auftragsgeschäft von allem, was du als fertiges Produkt mehrfach verkaufst – Plugins, Templates, eigene Tools, White-Label-Lösungen. Für diese produktnahen Angebote ist das Haftungsrisiko am greifbarsten und eine anwaltliche Prüfung am ehesten das Geld wert.

Zweitens: Mach Sicherheit und Dokumentation zum festen Prozess. Nachvollziehbare Versionsstände, ein belegbarer Update-Pfad und die Einhaltung einschlägiger Sicherheitsstandards sind künftig nicht nur gute Praxis, sondern deine Verteidigungslinie, wenn die Beweislastvermutungen greifen. Belegbarkeit statt Bauchgefühl ist ohnehin ein Prinzip, dem sich bei Ragnova das gesamte Produkt verschrieben hat – im Haftungskontext wird es zur schlichten Notwendigkeit.

Drittens: Denk die Produkthaftung in deinen Verträgen mit. Ein sauberer Wartungsvertrag regelt, wer nach dem Go-live für Updates zuständig ist – und wer eben nicht. Wird die laufende Pflege verbindlich vereinbart und vergütet, lässt sich die Verantwortung für Sicherheits-Updates klar zuordnen, statt im Schadensfall zwischen Agentur und Kunde zu zerfasern. Ein belastbarer Wartungs- und Update-Prozess ist damit nicht nur ein wiederkehrender Umsatz, sondern gelebtes Risikomanagement. Dass eine einzige verseuchte Abhängigkeit reicht, um ein ganzes Produkt fehlerhaft zu machen, zeigt im Übrigen jeder Supply-Chain-Angriff – auch dieses Risiko wandert künftig stärker in die Produkthaftung.

Fazit

Die neue EU-Produkthaftung ist die vielleicht unterschätzteste Rechtsänderung des Jahres für alle, die Software bauen. Ab dem 9. Dezember 2026 ist Software ein Produkt, Sicherheitslücken und fehlende Updates können Fehler sein, und die Beweislast kippt zugunsten der Geschädigten. Für kleine Agenturen ist die entscheidende Weichenstellung die ehrliche Trennung zwischen individuellem Auftragswerk und produktisiertem Angebot – denn dort, wo du etwas als fertiges Produkt verkaufst, wirst du zur Herstellerin mit verschuldensunabhängiger Haftung. Wer sein Portfolio jetzt sortiert, Sicherheit dokumentiert und Wartung vertraglich sauber regelt, verwandelt ein diffuses Risiko in eine beherrschbare Routine. Und genau diese Weitsicht ist es, die Kunden von einer Agentur erwarten dürfen, die mehr kann als Code ausliefern.