Produkthaftung für Software: Was kleine Unternehmen wissen sollten
Das neue Produkthaftungsrecht erfasst Software. Was kleine Unternehmen zu Sicherheit, Verantwortung und Updates wissen sollten – mit Checkliste und Prompt.
Ein Handwerksbetrieb erstellt mit einem KI-Werkzeug eine App für seine Kunden. Ein kleines Unternehmen verkauft eine selbst entwickelte Anwendung. Ein anderes lässt seine Software extern bauen und vertreibt sie unter eigenem Namen.
Die technischen Möglichkeiten sind enorm. Aber wer ein digitales Produkt anbietet, sollte auch über seine Sicherheit und die Verantwortung für Schäden nachdenken. In Deutschland wird Software im neuen Produkthaftungsgesetz ausdrücklich als Produkt genannt. Das Gesetz ist verkündet und tritt am 9. Dezember 2026 in Kraft.
Was bedeutet das für kleinere Unternehmen? Und was folgt gerade nicht daraus?
1. Was ändert sich – und ab wann?
Die EU hat die Produkthaftungsrichtlinie 2024/2853 beschlossen. Deutschland setzt sie mit dem Gesetz zur Modernisierung des Produkthaftungsrechts um. Der neue deutsche Gesetzestext wurde am 27. Oktober 2026 im Bundesgesetzblatt verkündet; das neue Produkthaftungsgesetz tritt am 9. Dezember 2026 in Kraft.
Für Produkte, die bis einschließlich 8. Dezember 2026 in Verkehr gebracht oder in Betrieb genommen wurden, verweist die Übergangsvorschrift grundsätzlich auf das bisherige Produkthaftungsgesetz. Inverkehrbringen bedeutet nach dem neuen Gesetz die erstmalige Bereitstellung auf dem Unionsmarkt; bei der Inbetriebnahme gelten eigene Voraussetzungen. Das Datum einer späteren einzelnen Bestellung ist nicht automatisch das maßgebliche Datum. Bei Änderungen bestehender Produkte kommt es auf die Einzelheiten an; ein Update ist nicht ohne Weiteres ein neues Produkt. Eine wesentliche Veränderung kann gesonderte Fragen aufwerfen.
Diese Erläuterung bezieht sich auf Deutschland. Andere EU-Staaten setzen die Richtlinie in nationales Recht um; die Schweiz gehört nicht zur EU. Wer grenzüberschreitend anbietet, sollte die jeweils geltenden Regeln prüfen lassen. Quelle: amtlicher Gesetzestext, §§ 5, 6 und 23 sowie Artikel 17.
2. Software ist ein Produkt – ein Fehler allein löst nicht automatisch einen Anspruch aus
§ 2 nennt Software ausdrücklich als Produkt. Für die Frage der Haftung kommt es aber auf mehr an als darauf, ob eine App einen Bug hat. Das Gesetz knüpft an einen Produktfehler im Sinne der Sicherheit, einen erfassten Schaden einer natürlichen Person und dessen Zusammenhang mit dem Fehler an. Ein Programm, das eine Rechnung falsch formatiert oder eine Funktion nicht bietet, ist nicht allein deshalb bereits ein Produkthaftungsfall.
Die Haftung setzt nicht voraus, dass ein Hersteller schuldhaft gehandelt hat. Das bedeutet aber nicht, dass ein Unternehmen für jeden denkbaren Schaden automatisch und unbegrenzt zahlen muss. Voraussetzungen, mögliche Entlastungen, Beweisregeln und Fristen müssen im Einzelfall geprüft werden. Vertragliche Gewährleistung und andere Haftungsgrundlagen sind eigenständige Fragen.
3. Welche Schäden erfasst das Gesetz?
§ 1 betrifft Schäden, die natürlichen Personen entstehen, wenn ein fehlerhaftes Produkt bestimmte Rechtsgüter verletzt:
- Tod sowie körperliche und gesundheitliche Verletzungen;
- Beschädigung oder Zerstörung einer Sache, ausgenommen das fehlerhafte Produkt selbst und ausschließlich beruflich genutzte Sachen;
- Vernichtung oder Beschädigung von Daten, die nicht für berufliche Zwecke verwendet werden.
Die Regelungen zu Sachen und Daten sind unterschiedlich formuliert: Eine gemischt genutzte Sache ist nicht allein wegen beruflicher Nutzung ausgeschlossen. Bei Daten ist die Formulierung enger. Ob im konkreten Fall Ersatz zu leisten ist und in welcher Höhe, ergibt sich nicht allein aus dieser Liste. Ansprüche juristischer Personen sind von diesem Gesetz nicht erfasst; das schließt andere Anspruchsgrundlagen nicht pauschal aus.
Fiktives Beispiel: Eine App steuert ein privates Gerät. Aufgrund eines Sicherheitsfehlers beschädigt das Gerät eine andere Sache. Ob tatsächlich ein Anspruch besteht, hängt unter anderem von Produktfehler, Schaden, Ursache und den weiteren gesetzlichen Voraussetzungen ab. Das Beispiel ist kein dokumentierter Schadensfall.
4. Wer gilt als Hersteller?
Hersteller ist nach § 3 unter anderem, wer ein Produkt selbst entwickelt oder herstellen lässt. Auch wer durch Name oder Marke als Hersteller auftritt, kann als solcher gelten. Wenn eine Agentur eine App im Auftrag entwickelt oder ein KI-Werkzeug Code erzeugt, sollte deshalb geklärt werden, welche Rolle die Beteiligten rechtlich und technisch jeweils haben. Die bloße Nutzung eines Werkzeugs verschiebt Verantwortung nicht automatisch.
Bei integrierten oder verbundenen Komponenten können unter den Voraussetzungen von § 4 sowohl Produkt- als auch Komponentenhersteller haften. Für freie und Open-Source-Software, die außerhalb einer Geschäftstätigkeit entwickelt oder bereitgestellt wird, sieht das Gesetz eine Ausnahme vor. Daraus folgt weder, dass jede kostenlose App ausgenommen ist, noch dass ein App-Anbieter für jeden Fehler einer Bibliothek automatisch haftet. Ob ein Angebot im Rahmen einer Geschäftstätigkeit erfolgt, ist anhand der Umstände zu beurteilen.
Praktisch hilfreich ist eine Liste wesentlicher Abhängigkeiten: Welche Bibliothek oder welcher Dienst wird genutzt? Welche Version? Wer ist für Updates zuständig? Wo liegt die Dokumentation? Eine solche Liste verhindert keine Schäden, erleichtert aber den Überblick.
5. Sicherheitsupdates gehören zur Verantwortung
Bei der Fehlerbeurteilung berücksichtigt das Gesetz unter anderem einschlägige sicherheitsrelevante Cybersicherheitsanforderungen (§ 7). Behält ein Hersteller die Kontrolle über ein Produkt – etwa weil er Updates bereitstellen kann –, kann das für den Beurteilungszeitpunkt relevant sein (§ 8). § 9 begrenzt unter bestimmten Voraussetzungen eine Entlastungsmöglichkeit, wenn etwa sicherheitsnotwendige Updates fehlen.
Das ist keine pauschale Aussage, dass jede Software unbegrenzt aktualisiert werden muss oder ein bestimmter Supportzeitraum allein jede Haftung beendet. Aber es ist ein guter Anlass, Zuständigkeiten, erkannte Sicherheitsprobleme, Updates und den Kommunikationsweg zu Nutzern zu dokumentieren.
6. Was ist mit KI-generiertem Code?
Das Gesetz enthält keine pauschale Befreiung, weil Code von einem KI-Werkzeug stammt. Entscheidend bleiben das Produkt, die Rollen und die gesetzlichen Voraussetzungen. Eine KI kann bei Tests und Dokumentation helfen, aber ihre Antwort beweist nicht, dass ein System sicher ist.
Wer Software veröffentlicht, sollte daher beispielsweise prüfen, welche Eingaben sie verarbeitet, welche Berechtigungen sie vergibt und welche Folgen ein Fehler für Menschen oder private Daten haben könnte. Ein Prompt kann Fragen sichtbar machen; er ersetzt keine technische Prüfung unter realistischen Bedingungen.
7. Dokumentation und Beweise
In einem gerichtlichen Verfahren kann das Gericht unter den Voraussetzungen des § 19 die Offenlegung relevanter Beweismittel anordnen; dabei gelten unter anderem Anforderungen an Erforderlichkeit, Verhältnismäßigkeit und den Schutz vertraulicher Informationen. § 20 sieht für bestimmte Konstellationen gesetzliche Vermutungen vor. Es gibt keine pauschale Pflicht, sämtliche Unterlagen ungefragt zu veröffentlichen, und keine automatische Beweislastumkehr für jeden Fehler.
Für den eigenen Betrieb ist es trotzdem sinnvoll, Entscheidungen nachvollziehbar festzuhalten: Welche Version wurde wann bereitgestellt? Welche wichtigen Risiken wurden betrachtet? Welche Tests liefen? Welche Fehler waren bekannt? Wer ist für Sicherheitsmeldungen und Updates zuständig?
8. Eine erste Checkliste
- Welche App oder welcher digitale Dienst wird wem und zu welchem Zweck angeboten?
- Wer entwickelt, beauftragt, vertreibt und erscheint gegenüber Nutzern als Anbieter?
- Wann wurde das konkrete Produkt erstmals in Verkehr gebracht oder in Betrieb genommen?
- Welche Sicherheitsrisiken können Menschen, andere Sachen oder nicht beruflich genutzte Daten betreffen?
- Welche Komponenten und externen Dienste sind wesentlich? Wer pflegt sie?
- Wie werden Fehler gemeldet, bewertet und behoben? Wer kann Updates liefern?
- Sind Versionen, Prüfungen, bekannte Grenzen und Entscheidungen nachvollziehbar dokumentiert?
- Sind passende Versicherungs-, Vertrags- und Rechtsfragen für den konkreten Fall fachlich geklärt?
Eine Checkliste ersetzt keine Sicherheitsprüfung und begründet keine rechtliche Konformität.
Prompt für einen ersten technischen Überblick
Hilf mir, mein Softwareprodukt auf Fragen zur Produktsicherheit vorzubereiten. Untersuche nur die Projektdateien, die ich freigegeben habe; verändere nichts und gib keine Geheimnisse oder personenbezogenen Daten aus.
Erstelle eine Tabelle mit Produktfunktionen, Nutzergruppen, technischen Abhängigkeiten, externen Diensten, möglichen sicherheitsrelevanten Fehlerszenarien, vorhandenen Tests, Updatewegen und jeweils konkreten Fundstellen. Trenne belegte Befunde von Hypothesen und unbekannten Punkten. Frage nach Anbieterrollen und Erstbereitstellung, wenn der Code sie nicht belegt.
Nenne mögliche nächste technische Prüfungen. Triff keine verbindliche Aussage zur Haftung, erfinde keine gesetzlichen Pflichten und behaupte keine vollständige Sicherheits- oder Rechtsprüfung.
Fazit und Unterstützung
KI macht es leichter, Software zu bauen. Sie nimmt uns nicht die Aufgabe ab, ihre möglichen Auswirkungen zu verstehen. Für kleine Unternehmen ist das neue Recht vor allem ein Anlass, Verantwortung, Sicherheit und den späteren Betrieb früh mitzudenken.
Den Impuls zu diesem Beitrag verdanke ich Stephan Wirth.
Wenn ihr technische Fragen zu eurer Anwendung habt, sprecht mich bei Moinsen an. Für die rechtliche Einordnung eures Angebots wendet euch an entsprechend qualifizierte Fachleute.
Weiterlesen: Website-Sicherheit · Datenschutz · Betrieb und Backups.
Primärquellen: Bundesgesetzblatt, Gesetzestext · EU-Richtlinie 2024/2853.
Tags:
SoftwareProdukthaftungKMU
Ulrich Diedrichsen
Softwarearchitekt & Produktentwickler
Softwareentwicklung seit dem Informatikstudium. Ex-IBM, Ex-PwC. Baut heute mit KI Produkte in Hamburg.