Produkthaftung Software KI: Was Startups 2026 jetzt prüfen müssen

Inhalt dieses Artikels

Wenn du heute ein SaaS mit KI-Feature, ein vernetztes Gerät oder eine App unter eigener Marke verkaufst, ist das Thema Produkthaftung Software KI keine Theorie mehr. Der Bundestag hat den Gesetzentwurf zur Modernisierung des Produkthaftungsrechts am 8. Oktober 2026 angenommen, die Einordnung der Bundesregierung dazu stammt vom 9. Oktober 2026. Damit zieht Deutschland die neue EU-Produkthaftungsrichtlinie nach, die digitale Produkte, künstliche Intelligenz und globale Lieferketten in den Blick nimmt.

Der Hintergrund ist einfach: Produkte sind nach dem Launch nicht mehr fertig. Sie verändern sich durch Updates, Modellwechsel, neue Features und angebundene Cloud-Dienste. Genau das spiegelt die Reform. Relevant ist das vor allem für Teams, die KI-Funktionen in ein SaaS integrieren, Hardware mit App und Cloud verkaufen, fremde Software unter eigener Marke vertreiben oder sicherheitsrelevante Consumer- und Assistenzfunktionen anbieten.

Keine Panik: Nicht jede Online-Dienstleistung wird dadurch automatisch zu einem voll haftungsrelevanten Produkt. Aber die bequeme Abkürzung „Wir liefern doch nur einen Service“ reicht als Risikoeinschätzung nicht mehr aus.

Quellen: Bundestag zum Produkthaftungsrecht | Bundesregierung: Produkthaftung, Digitalisierung und KI

Inhaltsverzeichnis

• Die neue Logik in einfachen Worten
• Wann ein digitales Angebot in den Fokus rückt
• Fünf typische Konstellationen aus dem Startup-Alltag
• Die eigene Rolle vor dem ersten Release klären
• Releases, Sicherheitsupdates und bekannte Fehler als Risikoprozess
• Die 30-Tage-Prioritätenliste
• Was oft schiefläuft und was AGB nicht lösen
• Produkthaftung vs. CRA, AI Act, DSGVO, CE und NIS2
• FAQ
• Fazit

Die neue Logik in einfachen Worten

Produkthaftung betrifft Schadenersatzansprüche wegen Schäden, die durch ein fehlerhaftes Produkt entstehen. Fehlerhaft ist ein Produkt dann, wenn es nicht die Sicherheit bietet, die berechtigterweise erwartet werden kann oder rechtlich vorgeschrieben ist. Dieser Maßstab klingt abstrakt, wird in der Praxis aber sehr konkret, sobald Software reale Vorgänge steuert.

Für digitale Angebote ändert sich vor allem vier Dinge. Der Produktbegriff umfasst ausdrücklich Software. Lernende oder nachträglich hinzugefügte Funktionen können in die Sicherheitsbewertung einfließen. Cybersicherheitsanforderungen, vorhersehbare Nutzung und die betroffenen Nutzergruppen spielen eine Rolle. Und: Die Kontrolle des Herstellers nach dem Inverkehrbringen bleibt relevant, etwa bei Updates, Upgrades oder weiter betriebenen verbundenen Diensten.

Der Begriff Lebenszyklus ist deshalb keine Floskel, sondern eine Arbeitsfrage. Es geht nicht nur darum, ob der Launch sauber war. Es geht auch darum, wie ihr auf Sicherheitslücken, Fehlerberichte, Modelländerungen und den Ausfall eines verbundenen Dienstes reagiert.

Quellen: Richtlinie (EU) 2024/2853

Wann ein digitales Angebot in den Fokus rückt

Nach der neuen EU-Richtlinie gilt: Software ist Produkt, unabhängig davon, ob sie heruntergeladen, als App installiert, über die Cloud bereitgestellt oder in ein Gerät eingebettet wird. Für die Praxis lohnt es sich, vier Konstellationen sauber zu trennen:

• Stand-alone-Software: eine eigenständig angebotene App oder lokal installierte Fachsoftware.
• Eingebettete Software: Firmware oder Steuerungscode in einem physischen Gerät.
• Verbundene digitale Dienste: Cloud-Funktionen, die nötig sind, damit ein Produkt wesentliche Funktionen überhaupt ausführen kann.
• KI-Funktionen: besonders prüfenswert, wenn sie Entscheidungen, Empfehlungen, Priorisierungen oder Steuerungen mit Auswirkungen auf Gesundheit, Sicherheit, Eigentum, Zugänge oder Transaktionen beeinflussen.

Wichtig für die Einordnung: SaaS Haftung ist kein Automatismus. Reine digitale Inhalte wie Medien oder E-Books sind abzugrenzen, und nicht geschäftlich bereitgestellte freie Open-Source-Software wird in der Richtlinie gesondert betrachtet. Ausschlaggebend bleiben Funktion, Sicherheitsbezug, Produktversprechen, Kontrolle und die Einbindung in ein Produkt.

Vier Mini-Prüffragen pro Angebot helfen weiter:

• Kann ein Fehler zu Personen-, Sach- oder sicherheitsrelevanten Vermögensschäden beitragen?
• Ist die Software für eine wesentliche Gerätefunktion notwendig?
• Welche Nutzungen und welche Fehlanwendungen sind vorhersehbar?
• Wer kontrolliert Betrieb, Releases, Updates und eine mögliche Abschaltung?

Quellen: Amtsblatt-Fassung der Produkthaftungsrichtlinie

Fünf typische Konstellationen aus dem Startup-Alltag

Konstellation	Worauf es ankommt	Operative Mindestmaßnahme
KI-Feature im SaaS (Priorisierung, Empfehlung, Auto-Freigabe)	Bei der KI-System Haftung sind unklare Nutzungsgrenzen, nicht dokumentierte Modell- oder Prompt-Änderungen, fehlende menschliche Prüfung bei folgenreichen Empfehlungen und unklare Eskalationswege kritisch.	Freigaberegeln für Modelländerungen, dokumentierte Grenzen, klarer Hinweis, wann menschliche Kontrolle nötig ist.
IoT-Gerät mit App und Cloud (Sensor, Zugangssystem, Energiesteuerung)	Für vernetzte Produkte im Startup gilt: App-Ausfall, fehlerhafte Firmware, Cloud-Abhängigkeit und fehlende Sicherheitsupdates können die sichere Nutzung beeinträchtigen.	Architektur- und Abhängigkeitsübersicht, klare Update-Verantwortung, Offline- und Fallback-Verhalten testen.
White-Label-Software unter eigener Marke	Eigene Marke und Außenauftritt können die Rolle gegenüber Kund:innen deutlich verändern.	Lieferantenverträge prüfen, aber eigene Qualitäts-, Test- und Dokumentationsarbeit nicht auslagern.
Digitales Medizin- oder Assistenzprodukt	Möglicher Gesundheitsbezug erfordert erhöhte Sorgfalt.	Produktgrenzen, Tests, Warnhinweise und Eskalation bei Fehlverhalten nachvollziehbar dokumentieren.
Consumer-App mit sicherheitsrelevanter Funktion (Zugang, Fahrzeug, Haustechnik, Notfall)	Sicherheitsversprechen in der Kommunikation und das reale Verhalten im Fehlerfall müssen zusammenpassen.	Fehlermeldungen, Berechtigungen, Offline-Verhalten und Zeit bis zum Fix definieren.

Die eigene Rolle vor dem ersten Release klären

Bevor ihr über Risiken sprecht, klärt eure Rolle. Hersteller ist, wer ein Produkt entwickelt oder herstellen lässt und es unter eigenem Namen oder eigener Marke vermarktet. Importeur ist, wer ein Produkt aus einem Drittstaat in die EU einführt. Und wer ein fremdes Produkt unter eigener Marke anbietet, sollte besonders genau prüfen, ob er nach außen wie ein Hersteller auftritt.

Die Bundesregierung nennt Hersteller, Importeure und unter Umständen Lieferanten als potenziell relevante Akteure entlang globaler Lieferketten. Für euch heißt das praktisch: Legt eine schlanke Rollenmatrix pro Produkt an, mit Produktname, Marke, Code- und Hardware-Herkunft, Hosting, Lieferanten, Importweg, Release-Verantwortung und einer namentlich verantwortlichen Person.

Ein Punkt wird oft übersehen: Die vertragliche Rückgriffsmöglichkeit gegen Lieferanten kann wirtschaftlich sehr wichtig sein. Sie beseitigt aber nicht automatisch die Außenwirkung gegenüber Geschädigten.

Quellen: Bundesregierung: Produkthaftung, Digitalisierung und KI

Releases, Sicherheitsupdates und bekannte Fehler als Risikoprozess behandeln

Beim Thema Updates Haftung lohnt eine Präzisierung: Nicht jedes Update löst automatisch eine Haftung aus. Relevant kann aber sein, ob ein Fehler, ein Upgrade oder das Unterlassen notwendiger Sicherheitsupdates die Produktsicherheit beeinträchtigt. Nach der Richtlinie bleiben Updates, Upgrades und verbundene Dienste, die unter der Kontrolle des Herstellers stehen, für die Fehlerbewertung relevant.

Ein realistischer Minimalprozess für kleine Teams sieht so aus:

1. Jede Veröffentlichung bekommt Version, Datum, verantwortliche Freigabe, Änderungsumfang und bekannte Risiken.
2. Sicherheitsrelevante Tickets erhalten eine klar definierte Eskalation und Priorisierung.
3. Vor kritischen Releases steht ein getesteter Rollback bereit, also die Rückkehr auf eine stabile Vorversion.
4. Known-Issue-Handling definieren: Problem erfassen, Auswirkung bewerten, temporäre Schutzmaßnahme festlegen, Kommunikation entscheiden, Behebung dokumentieren.
5. Supportfälle mit möglichem Sicherheits- oder Schadensbezug zentral bündeln statt in einzelnen Postfächern liegen zu lassen.
6. Bei Abschaltung oder Änderung eines Cloud-Dienstes prüfen, ob dadurch wesentliche oder sichere Produktfunktionen entfallen.

Ergänzend, aber nicht identisch: Der Cyber Resilience Act verlangt für Produkte mit digitalen Elementen unter anderem Schwachstellenbehandlung, Sicherheitsaktualisierungen und Angaben zur Dauer der Sicherheitsunterstützung. Die Berichtspflichten gelten seit dem 11. September 2026, die wesentlichen übrigen Pflichten grundsätzlich ab dem 11. Dezember 2027.

Quellen: Amtsblatt-Fassung der Produkthaftungsrichtlinie | CRA-FAQ der EU-Kommission

Die 30-Tage-Prioritätenliste

Woche 1 – Inventar und Zuständigkeiten. Erfasst alle Produkte, Apps, KI-Features, Geräte, APIs, Cloud-Dienste und externen Komponenten. Notiert je Angebot Marke, technische Herkunft, Hosting, Hardwarebezug, Lieferanten, Importbezug und die verantwortliche Person.

Woche 2 – Risiken und Nutzungsgrenzen. Sammelt pro Angebot drei bis fünf plausible Fehlerszenarien: falsche Empfehlung, Ausfall, unberechtigter Zugriff, fehlerhaftes Update, Ausfall eines verbundenen Dienstes. Haltet den vorgesehenen Zweck, klare Grenzen und vorhersehbare Fehlanwendungen fest. Bei KI-Funktionen klärt ihr, welche Änderungen dokumentiert werden und wann menschliche Kontrolle vorgesehen ist.

Woche 3 – Release und Support. Testet Freigabe-Check, Versionierung, Rollback und Notfall-Update praktisch durch. Richtet eine Known-Issue-Liste und einen Eskalationskanal für kritische Supportmeldungen ein.

Woche 4 – Incident und Nachweise. Erstellt ein Incident-Template mit Zeitpunkt, betroffener Version oder Funktion, Auswirkung, Sofortmaßnahme, Kommunikation, Ursache, Korrektur und verantwortlicher Person. Führt eine Tabletop-Übung durch, etwa ein fehlerhaftes KI-Update oder einen App-Ausfall bei einem vernetzten Gerät. Überführt die Ergebnisse in konkrete Prozessverbesserungen.

Diese Liste schafft Transparenz und Routine. Eine juristische Einzelfallprüfung ersetzt sie nicht.

Was oft schiefläuft und was davon nicht durch AGB lösbar ist

• Software pauschal nur als Dienstleistung betrachten: Bewertet Funktionen einzeln nach Sicherheitsbezug und Produktintegration.
• Open-Source-Bibliotheken, Modellanbieter, externe APIs und Lieferanten nicht dokumentieren: Führt eine gepflegte Komponenten- und Abhängigkeitsliste.
• Verantwortlichkeiten zwischen Product, Development, Security und Support nur mündlich klären: Legt pro Prozess eine benannte Rolle fest.
• Sicherheitsupdates ohne Priorisierung oder Rollback ausrollen: Dokumentiert und testet Freigabe- und Notfallverfahren.
• Bekannte Fehler nur intern kennen: Bewertet sie strukturiert, legt Maßnahmen fest und bereitet bei Bedarf Kundenkommunikation vor.
• Terms, AGB oder Disclaimer als Ersatz für Produktsicherheit verstehen: Vertragsklauseln ersetzen keine operative Sicherheits-, Test- und Reaktionsarbeit.

Was Produkthaftung von CRA, AI Act, DSGVO, CE und NIS2 unterscheidet

Regelwerk	Kernfrage	Was es nicht ersetzt
Produkthaftung	Wer haftet für Schäden durch ein fehlerhaftes Produkt?	Kein Ersatz für Cybersicherheits- oder KI-Compliance.
Cyber Resilience Act	Sind Produkte mit digitalen Elementen cybersicher entwickelt und gepflegt, inklusive Schwachstellenbehandlung?	Keine Produkthaftungsanalyse des konkreten Produkts.
EU AI Act	Risikobasierte Pflichten für KI-Systeme, bei Hochrisiko-KI unter anderem Risikomanagement, Datenqualität, Protokollierung, technische Dokumentation, menschliche Aufsicht, Genauigkeit, Robustheit und Cybersicherheit.	Keine Sicherheits- oder Haftungsbewertung des Produkts als Ganzes.
DSGVO und AVV	Wie werden personenbezogene Daten verarbeitet, insbesondere bei Auftragsverarbeitung nach Artikel 28?	Beantwortet nicht, ob das Produkt sicher ist.
CE-Kennzeichnung	Erfüllt das Produkt die einschlägigen EU-Vorschriften, die CE verlangen, inklusive Konformitätsbewertung und EU-Konformitätserklärung?	Kein allgemeiner Haftungsfreibrief.
NIS2	Fällt das Unternehmen nach Größe, Sektor und Tätigkeit in den Anwendungsbereich?	Keine automatische Betroffenheit jedes SaaS-Startups.

Quellen: EU-Rechtsrahmen für KI | DSGVO | CE-Kennzeichnung | BSI NIS-2-Entscheidungsbaum

FAQ

Fällt mein SaaS automatisch unter die neue Produkthaftung?

Nein. Entscheidend sind Funktion, Sicherheitsbezug, Produktversprechen, eure Marktrolle und die Einbindung in ein Produkt. Prüft funktionsweise statt pauschal.

Haften wir, wenn ein KI-Modell eine falsche Empfehlung gibt?

Das hängt davon ab, ob das Produkt die berechtigterweise erwartbare Sicherheit bietet. Dokumentierte Nutzungsgrenzen, nachvollziehbare Modelländerungen und vorgesehene menschliche Kontrolle sind dabei zentrale Bausteine.

Muss ich jedes Update dokumentieren?

Ja, zumindest minimal: Version, Datum, Änderungsumfang, Freigabe und bekannte Risiken. Das kostet wenige Minuten pro Release und ist im Ernstfall euer wichtigster Nachweis.

Reichen gute AGB als Absicherung?

Nein. Vertragsklauseln können operative Sicherheits-, Test- und Reaktionsarbeit nicht ersetzen.

Ab wann greifen die CRA-Pflichten?

Die Berichtspflichten gelten seit dem 11. September 2026, die wesentlichen übrigen Pflichten grundsätzlich ab dem 11. Dezember 2027.

Fazit

Bei Produkthaftung Software KI zählt nicht nur der Code zum Launch, sondern die Kombination aus Produktfunktion, Marktrolle, Sicherheitsniveau, Updates und eurer Reaktion auf Vorfälle. Startet in den nächsten 30 Tagen mit Produktinventar, Rollenmatrix, Release- und Rollback-Prozess sowie Incident-Handling.

Pro-Tipp: Führt die Tabletop-Übung mit einem echten Szenario aus eurem Backlog durch, nicht mit einem erfundenen. Ihr findet so meist in zwei Stunden die drei Lücken, die im Ernstfall wirklich weh tun.

Kleine Teams brauchen keine Konzernbürokratie, sondern nachvollziehbare Mindestprozesse, die bei einem echten Fehler funktionieren. Dieser Beitrag bietet allgemeine Orientierung und ersetzt keine individuelle Rechtsberatung.

Transparenzhinweis: Dieser Beitrag wurde unter Zuhilfenahme künstlicher Intelligenz erstellt und vor der Veröffentlichung redaktionell geprüft. Alle Zahlen und Angaben wurden gegen die im Text verlinkten Primärquellen abgeglichen.