Am 9. Dezember wird Ihre Software zum Produkt: Was die neue Produkthaftung für KI-Anbieter wirklich ändert

Es gibt in der europäischen Digitalregulierung Termine, über die monatelang geredet wird, und solche, die fast unbemerkt näherrücken. Der 9. Dezember 2026 gehört zur zweiten Sorte. An diesem Tag endet die Frist, bis zu der die Mitgliedstaaten die neue Produkthaftungsrichtlinie in nationales Recht überführt haben müssen — und ab diesem Tag gilt für neu auf den Markt gebrachte Produkte ein Haftungsregime, in dem Software ausdrücklich ein Produkt ist.

Das klingt technisch, ist aber die weitreichendste Änderung der zivilrechtlichen Haftung für Softwareanbieter seit vierzig Jahren — und sie kommt ohne das Aufsehen daher, das den AI Act begleitet hat. Der Unterschied zwischen beiden Regelwerken erklärt auch, warum das eine so viel lauter war: Der AI Act ist Aufsichtsrecht und sagt, was Sie tun müssen, um am Markt bleiben zu dürfen. Die Produkthaftungsrichtlinie ist Zivilrecht und sagt, wer zahlt, wenn trotzdem etwas schiefgeht. Aufsichtsrecht erzeugt Projekte. Haftungsrecht erzeugt Klagen, und zwar erst Jahre später.

Was sich am 9. Dezember ändert

Die alte Produkthaftungsrichtlinie stammt aus dem Jahr 1985. Sie war für Toaster, Autoreifen und Arzneimittel geschrieben, und ob Software überhaupt darunterfällt, war jahrzehntelang umstritten. Die Neufassung beendet diesen Streit. Die Produktdefinition in Artikel 4 nennt Software ausdrücklich — und zwar unabhängig davon, ob sie auf einem Gerät gespeichert, über ein Netzwerk oder eine Cloud abgerufen oder als Software-as-a-Service bereitgestellt wird. SaaS ist erfasst. Ein KI-Modell, das Sie über eine Programmierschnittstelle anbieten, ist damit haftungsrechtlich ein Produkt wie eine Bohrmaschine.

„Verschuldensunabhängig“ heißt dabei: Es kommt nicht darauf an, ob Sie sorgfältig gearbeitet haben. Der Geschädigte muss Ihnen keinen Fehler im Sinne eines Vorwurfs nachweisen, sondern nur, dass das Produkt nicht die Sicherheit bot, die man erwarten durfte. Ob Ihr Team gut gearbeitet hat, ist eine andere Frage als die, ob das Ergebnis fehlerhaft war.

Bei der Beurteilung dieser Fehlerhaftigkeit nennt Artikel 7 ausdrücklich Umstände, die vor vierzig Jahren niemand im Blick hatte: die Fähigkeit des Produkts, nach dem Inverkehrbringen weiterzulernen, das Zusammenwirken mit anderen vernetzten Produkten und die Einhaltung sicherheitsrelevanter Cybersicherheitsanforderungen. Ein System, das sich im Betrieb verändert, wird also nicht deshalb milder beurteilt, weil es sich verändert hat.

Der eigentliche Hebel: das nicht eingespielte Update

Wer nur eine Neuerung aus diesem Text mitnehmen will, sollte es diese sein. Nach Artikel 11 bleibt ein Produkt so lange in der Kontrolle des Herstellers, wie dieser die Fähigkeit behält, Software-Updates bereitzustellen — selbst oder über Dritte. Und solange das der Fall ist, kann sich der Hersteller nicht damit entlasten, dass der Fehler erst nach der Auslieferung entstanden ist. Das gilt ausdrücklich für Fehler, die auf eine zugehörige Dienstleistung zurückgehen, auf ein Update oder Upgrade — und auf das Unterlassen eines notwendigen Sicherheitsupdates.

Übersetzt in die Sprache eines SaaS-Anbieters: Der Klassiker der neuen Haftung ist nicht der Bug, der beim Ausrollen passiert. Es ist die bekannte Schwachstelle, die monatelang im Backlog liegt, weil das Quartalsziel ein anderes war. Wer patchen kann und nicht patcht, haftet. Für Produktverantwortliche verschiebt das eine Abwägung, die bisher rein wirtschaftlich getroffen wurde, in den Bereich des Haftungsrisikos.

Damit ist auch die Frage, wie lange Sie eine Version pflegen, keine reine Support-Entscheidung mehr — und der stillschweigende Austausch eines Modells hinter Ihrer Schnittstelle ist ein Update im Sinne dieser Vorschrift.

Die Beweislast, und warum sie für KI eigens umgebaut wurde

Der praktisch größte Unterschied zum alten Recht steht in den Artikeln 9 und 10. Im Grundsatz muss weiterhin der Kläger Fehler, Schaden und Ursachenzusammenhang beweisen — aber drei Erleichterungen entschärfen diesen Grundsatz erheblich.

Erstens muss der Beklagte auf gerichtliche Anordnung relevante Beweismittel offenlegen. Zweitens wird die Fehlerhaftigkeit vermutet, wenn er dieser Anordnung nicht nachkommt, wenn das Produkt zwingende Sicherheitsvorgaben verletzt oder wenn bei bestimmungsgemäßem Gebrauch eine offensichtliche Fehlfunktion vorlag. Drittens — und das ist die Vorschrift, die erkennbar für Systeme wie die Ihren geschrieben wurde — kann das Gericht Fehlerhaftigkeit oder Ursächlichkeit schon dann vermuten, wenn der Kläger wegen technischer oder wissenschaftlicher Komplexität in übermäßige Beweisschwierigkeiten gerät. Es genügt dann, dass beides wahrscheinlich ist.

Damit ist das häufigste stille Argument der Verteidigung entwertet. Bisher konnte ein Anbieter darauf setzen, dass ein Außenstehender die Funktionsweise eines großen Modells niemals so weit durchdringt, dass er einen konkreten Fehler benennen kann. Genau diese Undurchschaubarkeit wird jetzt zum Argument der Gegenseite.

Erweitert wurde auch der ersatzfähige Schaden: neben Tod, Körperverletzung und Sachschäden nun ausdrücklich die Zerstörung oder Verfälschung nicht beruflich genutzter Daten und ärztlich anerkannte psychische Gesundheitsschäden. Die frühere Haftungshöchstgrenze entfällt ersatzlos, vertragliche Beschränkungen zulasten des Geschädigten sind unwirksam, und die Ausschlussfrist von zehn Jahren ab Inverkehrbringen verlängert sich bei spät auftretenden Personenschäden auf 25 Jahre.

Die Falle in der Übergangsregel

Hier lohnt sich Genauigkeit, weil die Regel oft falsch wiedergegeben wird. Die Richtlinie gilt nicht rückwirkend. Maßgeblich ist ausschließlich, wann ein Produkt in Verkehr gebracht oder in Betrieb genommen wurde — nicht, wann der Schaden eintritt. Für alles, was vor dem 9. Dezember 2026 auf den Markt kam, gilt weiterhin das alte Recht von 1985.

Das entlastet kurzfristig und verpflichtet langfristig: Ihr bestehendes Portfolio wechselt nicht über Nacht das Haftungsregime, aber jedes ab Dezember neu auf den Markt gebrachte Produkt trägt einen Haftungsschwanz, der im Extremfall bis in die späten 2040er Jahre reicht. Wer die Frage „was gilt eigentlich als neues Inverkehrbringen?“ heute nicht beantworten kann, sollte sie mit seiner Rechtsabteilung klären, bevor die Antwort jemand anders gibt.

AI-Act-Konformität schützt nicht — sie wird zum Maßstab

Eine verbreitete Hoffnung lautet, wer den AI Act einhalte, sei haftungsrechtlich auf der sicheren Seite. Das Gegenteil trifft eher zu. Artikel 7 bestimmt die Fehlerhaftigkeit unter anderem anhand der Sicherheitsanforderungen, die das Unionsrecht vorschreibt. Damit werden die Pflichten des AI Act inhaltlich in die zivilrechtliche Fehlerdefinition hineingezogen. Und ein Verstoß gegen zwingende Sicherheitsvorgaben löst nach Artikel 10 unmittelbar die Vermutung der Fehlerhaftigkeit aus.

Die Konsequenz ist unbequem, aber verwertbar: Die Dokumentation, die Sie für den AI Act ohnehin anlegen — Risikomanagement, technische Dokumentation, Protokollierung —, ist zugleich Ihr wichtigstes Verteidigungsmittel im Haftungsprozess. Nicht als Freibrief, sondern als Nachweis eingehaltener Sorgfalt. Umgekehrt wird jede Lücke darin im Streitfall gegen Sie verwendet.

Was fehlt: die zurückgezogene Schwesterrichtlinie

Ursprünglich sollte die Produkthaftung von einer eigenen KI-Haftungsrichtlinie flankiert werden, die die verschuldensabhängige Haftung harmonisiert hätte — also jene Fälle, in denen es nicht um einen Produktfehler geht, sondern etwa um reine Vermögensschäden oder um Diskriminierung durch eine automatisierte Entscheidung. Diese Richtlinie ist nicht in der Warteschleife, sie ist tot: Die Kommission sah sie im Arbeitsprogramm 2025 zur Rücknahme vor, weil eine Einigung nicht absehbar war, und machte die förmliche Rücknahme am 6. Oktober 2025 im Amtsblatt bekannt. Ein neuer Vorschlag ist bis heute nicht angekündigt.

Für Unternehmen bedeutet das eine unangenehme Asymmetrie. Für Personen- und Sachschäden gilt europaweit einheitlich das strenge Produkthaftungsregime. Für alles andere — und „alles andere“ ist bei betrieblich eingesetzter KI der Regelfall — bleibt es beim nationalen Deliktsrecht von 27 Mitgliedstaaten. Wer grenzüberschreitend anbietet, bekommt in der einen Hälfte des Risikos Harmonisierung und in der anderen einen Flickenteppich.

Deutschland bei laufender Uhr

Der deutsche Umsetzungsstand ist zum Redaktionsschluss unfertig. Die Bundesregierung hat einen Entwurf zur Modernisierung des Produkthaftungsrechts vorgelegt, die erste Lesung im Bundestag fand am 4. März 2026 statt, die Anhörung im Rechtsausschuss am 13. April. Zweite und dritte Lesung sowie die Beteiligung des Bundesrats stehen noch aus. Bei einer Frist zum 9. Dezember ist das eng — ob sie gehalten wird, lässt sich seriös nicht vorhersagen.

Bemerkenswert ist die Anhörung selbst, weil die Kritik aus entgegengesetzten Richtungen kam. Die DIHK hielt dem Entwurf vor, über die europäischen Vorgaben hinauszugehen und Kosten zu erzeugen; der Verbraucherzentrale Bundesverband gingen die Offenlegungsrechte nicht weit genug und forderte vorprozessuale Auskunftsansprüche. Zwei Rechtswissenschaftler warnten unabhängig voneinander vor Rechtsunsicherheit. Wenn Wirtschafts- und Verbraucherseite denselben Text aus gegenläufigen Gründen für misslungen halten, ist das kein gutes Zeichen für die Vorhersehbarkeit der ersten Urteile.

Auch europaweit ist die Umsetzung ungleichmäßig, und die nationalen Entwürfe weichen ausgerechnet dort ab, wo es teuer wird — besonders beim Entwicklungsrisiko-Einwand. Diese Verteidigung, ein Fehler sei nach dem Stand von Wissenschaft und Technik nicht erkennbar gewesen, bleibt grundsätzlich bestehen; die Richtlinie erlaubt den Mitgliedstaaten aber ausdrücklich, sie für einzelne Produktkategorien einzuschränken oder abzuschaffen.

Zwei offene Flanken

Die erste betrifft quelloffene Software. Die Ausnahme gilt nur für sie, wenn sie außerhalb einer Geschäftstätigkeit entwickelt oder bereitgestellt wird — sie schützt also den Betreuer eines Projekts, nicht dessen kommerziellen Weiterverwender: Wer offene Komponenten in ein bezahltes Produkt integriert, wird zum Hersteller des Gesamtprodukts. Wo die Grenze der „Geschäftstätigkeit“ verläuft, sobald Spenden, Supportverträge oder Datennutzung ins Spiel kommen, ist fachlich umstritten. Für Unternehmen mit viel offenem Code im KI-Stack wird die Lieferkettendokumentation damit von der Kür zur Pflicht.

Die zweite betrifft die Versicherbarkeit. Der Schweizerische Versicherungsverband beschreibt KI als aufkommendes Risiko in der Haftpflichtversicherung; passende Produkte müssten wegen der Komplexität erst noch entwickelt werden. Besonders heikel ist sein Befund, dass KI-Risiken in bestehenden Policen häufig weder ausdrücklich erwähnt noch ausdrücklich ausgeschlossen sind — genau die Konstellation, die die Branche vor Jahren beim stillschweigend mitversicherten Cyberrisiko erlebt hat. Sie wurde damals nicht zugunsten der Versicherungsnehmer aufgelöst.

Was jetzt zu tun ist

Vier Dinge, keines davon aufwendig, alle vor dem 9. Dezember erledigbar. Klären Sie erstens, was in Ihrem Haus als Inverkehrbringen gilt, und dokumentieren Sie das Datum je Produkt und Version — die gesamte Übergangsregel hängt daran. Schreiben Sie zweitens fest, welche Sicherheitsupdates Sie für welche Versionen wie lange liefern, und behandeln Sie das als Verpflichtung, nicht als Marketingaussage. Prüfen Sie drittens, ob Ihre Protokollierung im Streitfall zeigen kann, wie eine bestimmte Ausgabe zustande kam — Artikel 10 belohnt nicht denjenigen, der es nicht zeigen kann. Und lassen Sie sich viertens von Ihrem Versicherer schriftlich bestätigen, wie Ihre Police KI-bedingte Schäden behandelt.

Das ist unspektakuläre Arbeit. Aber sie entscheidet, ob Sie einen Haftungsfall verteidigen können — oder ob die Vermutungsregeln die Verteidigung übernehmen, auf der anderen Seite.