Die EU-Produkthaftungsrichtlinie und Ihre KI: Was sich ab dem 9. Dezember 2026 ändert

Vieles, was ich über die neue EU-Produkthaftungsrichtlinie lese, klingt nach einem Grund zur Panik. Bei vielen KI-Systemen ist das nicht nötig. Bei manchen schon.

Vier Fragen zeigen Ihnen, wo. Und wenn die Antwort Ja lautet, wird das, was Ihr Team ab jetzt aufbewahrt (Tests, Traces, Änderungsprotokolle), wichtiger sein als jedes Richtliniendokument.

Ich baue und betreibe KI-Systeme; juristisch ausgebildet bin ich nicht. Hier steht, was der Text sagt und was ich aufbewahren würde.

Allgemeine Orientierung, keine Rechtsberatung. Wo der genaue Wortlaut zählt, nenne ich den Artikel, damit Sie oder Ihre Rechtsberatung ihn am Text prüfen können.

Die Kurzfassung

• Was sich ändert: Für Produkte, die am oder nach dem 9. Dezember 2026 in Verkehr gebracht oder in Betrieb genommen werden (verkauft oder geliefert bzw. erstmals im eigenen Unternehmen genutzt), ist Software, auch KI, ein Produkt im Sinne des EU-Produkthaftungsrechts. Ist sie fehlerhaft und schadet jemandem, muss die geschädigte Person nicht beweisen, dass jemand fahrlässig war.
• Wen es betrifft: Nur natürliche Personen haben Anspruch auf Schadensersatz, und nur für drei Arten von Schäden: Tod oder Körperverletzung, Sachschäden sowie die Vernichtung oder Beschädigung ihrer Daten, die nicht beruflich genutzt werden. Verluste, die innerhalb Ihres Unternehmens bleiben, sind nicht erfasst. Schäden an einer Person, an ihren Sachen oder an ihren nicht beruflich genutzten Daten sind es.
• Was Sie aufbewahren sollten: Kommt es zu einem Anspruch, kann das Gericht Sie zur Offenlegung von Beweismitteln verpflichten; tun Sie es nicht, wird Ihre KI als fehlerhaft vermutet (Sie können das widerlegen, also das Gegenteil beweisen). Hilfreich sind Nachweise, die Sie zeitnah festgehalten haben: Tests, Traces und eine Aufzeichnung jeder Änderung.

Was sich ändert: Software wird zum Produkt

Die überarbeitete Produkthaftungsrichtlinie ¹ ersetzt die EU-Regeln von 1985 ². Sie gilt für Produkte, die am oder nach dem 9. Dezember 2026 in Verkehr gebracht oder in Betrieb genommen werden (Art. 2 Abs. 1). Was vor diesem Datum in Verkehr gebracht oder in Betrieb genommen wurde, bleibt unter den alten Regeln (Art. 21).

Durch eine amtliche Berichtigung vom 7. Mai 2026 ⁶ wurde Art. 2 Abs. 1 von „nach dem 9. Dezember 2026“ in „nach dem 8. Dezember 2026“ geändert. Einige Kommentare sprechen weiterhin von „nach dem 9. Dezember“.

Vier Punkte sind für jeden wichtig, der KI entwickelt oder einsetzt:

• Software ist ein Produkt. Die Richtlinie nennt „KI-Systeme“ als Beispiel und besagt, dass Software unabhängig von der Art ihrer Bereitstellung als Produkt gilt, einschließlich Software-as-a-Service (Erwägungsgrund 13).
• Kein Verschulden erforderlich. Die Frage ist, ob das Produkt fehlerhaft war, nicht, ob man fahrlässig gehandelt hat.
• Weder Untergrenze noch Obergrenze. Die alten Regeln sahen für Sachschäden einen Selbstbehalt von 500 € vor und erlaubten den Ländern, die Haftung zu begrenzen. Der Selbstbehalt von 500 € entfällt (Art. 6), und nationales Recht darf die Haftung nicht mehr begrenzen (Art. 15, Erwägungsgrund 56).
• Längerer Zeitraum für Ansprüche. Eine Person hat drei Jahre ab dem Zeitpunkt, zu dem sie von dem Schaden, dem Fehler und der haftenden Person Kenntnis erlangt hat oder hätte erlangen müssen (Art. 16). Ansprüche können bis zu 10 Jahre nach dem Inverkehrbringen oder der Inbetriebnahme des Produkts entstehen, bei manchen Personenschäden, die erst spät auftreten, bis zu 25 Jahre (Art. 17).

Jedes EU-Land setzt die Richtlinie bis zum 9. Dezember 2026 in nationales Recht um (Art. 22). In Deutschland ist das der Regierungsentwurf zur Modernisierung des Produkthaftungsrechts (Bundestagsdrucksache 21/4297) ³. Er wurde im März 2026 in erster Lesung beraten und im April in einer Ausschussanhörung behandelt; Anfang Oktober 2026 hatte der Bundestag ihn noch nicht verabschiedet. Im vorliegenden Entwurf gilt Software als Produkt, unabhängig von der Art der Bereitstellung, auch als SaaS, und der heutige Selbstbehalt von 500 € sowie die Haftungshöchstgrenze von 85 Millionen € entfallen. Prüfen Sie die Fassung in Ihrem eigenen Land.

Zwei Dinge, die diese Richtlinie nicht ist. Sie ist nicht die KI-Haftungsrichtlinie. Das war ein eigener Vorschlag, den die Kommission 2025 zurückgezogen hat ⁴. Und sie ist nicht die KI-Verordnung (AI Act), deren Hochrisiko-Regeln auf Dezember 2027 und August 2028 verschoben wurden ⁵. Das Datum für die Produkthaftung hat sich nicht verschoben.

Im Vereinigten Königreich: Die Richtlinie gilt nicht in Großbritannien. Wird Ihre KI aber in der EU in Verkehr gebracht, gilt sie dort, und der EU-Importeur oder Ihr Bevollmächtigter kann ebenfalls haften (Art. 8 Abs. 1 Buchst. c).

Betrifft das auch Sie? Vier Fragen

Nur natürliche Personen haben Anspruch auf Schadensersatz (Art. 5), und nur für drei Arten von Schäden (Art. 6 Abs. 1):

1. Tod oder Körperverletzung, einschließlich medizinisch anerkannter Schäden an der psychischen Gesundheit.
2. Schäden an Sachen, mit Ausnahme des fehlerhaften Produkts selbst, eines Produkts, das durch eine vom Hersteller eingebaute fehlerhafte Komponente beschädigt wurde, und von Sachen, die ausschließlich für berufliche Zwecke verwendet werden.
3. Vernichtung oder Beschädigung von Daten, die nicht für berufliche Zwecke verwendet werden.

Daraus ergeben sich vier Fragen zu Ihrem KI-System, beginnend mit dem Zeitpunkt:

• Wird es am oder nach dem 9. Dezember 2026 in Verkehr gebracht oder in Betrieb genommen oder danach wesentlich verändert?
• Könnte eine Fehlfunktion plausibel jemanden verletzen? Zum Beispiel eine Verbraucher-App, die falsche Dosierungs- oder Sicherheitshinweise gibt.
• Könnte es Daten einer Person zerstören oder beschädigen, die nicht beruflich genutzt werden?
• Könnte es Sachen beschädigen, die nicht rein betrieblich genutzt werden? Zum Beispiel eine Haus- oder Fahrzeugsteuerung, die Besitztümer einer Person beschädigt.

Lautet die erste Antwort Ja, die anderen drei aber Nein, ist diese Richtlinie wahrscheinlich nicht Ihr größtes KI-Risiko. Ein Verlust, der im Unternehmen bleibt – etwa ein Lieferant, den ein Rechnungs-Agent doppelt bezahlt –, gehört nicht zu den drei Arten, und ebenso wenig ein Kunde, dem ein Bestell-Agent den falschen Betrag erstattet: Ein reiner Vermögensschaden löst diese Richtlinie für sich genommen nicht aus (Erwägungsgrund 24). Wird eine der Schadensfragen mit Ja beantwortet, lesen Sie weiter.

Drei Fragen, die die Richtlinie nicht klärt

Einige Fälle lassen sich allein aus dem Text nicht klären. Verstehen Sie meine Lesart bei keinem davon als die Antwort. Trifft einer auf Sie zu, sprechen Sie ihn mit Ihrer Rechtsberatung durch.

KI, die Sie selbst bauen oder beauftragen und selbst betreiben, einschließlich kundennaher Agenten, die Ihre Kunden nutzen, aber nicht kaufen. Als Hersteller gilt nach der Richtlinie, wer „ein Produkt für den Eigenbedarf entwickelt, herstellt oder produziert“ (Art. 4 Nr. 10 Buchst. c). „Inbetriebnahme“ bedeutet die erstmalige Verwendung eines Produkts in der Union im Rahmen einer Geschäftstätigkeit, sofern es nicht zuvor in Verkehr gebracht wurde (Art. 4 Nr. 9). Was der Text nicht ausdrücklich regelt: wie das für ein KI-System gilt, das ein Unternehmen selbst betreibt, sei es für die eigenen Beschäftigten oder um seine Kunden zu bedienen.

KI, die bereits live ist. Systeme, die vor dem 9. Dezember 2026 in Verkehr gebracht oder in Betrieb genommen wurden, bleiben unter den alten Regeln (Art. 21). Was geschieht, wenn eines davon nach diesem Datum wesentlich verändert wird, sagt die Richtlinie nicht ausdrücklich. Sie sagt aber, dass als Hersteller gilt, wer ein Produkt außerhalb der Kontrolle des Herstellers wesentlich verändert und es dann auf dem Markt bereitstellt oder in Betrieb nimmt (Art. 8 Abs. 2). Und bei einem wesentlich veränderten Produkt beginnt die 10-Jahres-Frist von Neuem (Art. 17 Abs. 1 Buchst. b). „Wesentliche Änderung“ ist eigens definiert (Art. 4 Nr. 18): Wo die Produktsicherheitsvorschriften keinen Maßstab festlegen, ist es eine Änderung von Leistung, Zweck oder Art des Systems, die in der ursprünglichen Risikobewertung nicht vorgesehen war und die die Art der Gefahr verändert, eine neue schafft oder das Risiko erhöht. Planen Sie eine große Änderung an einem laufenden System, fragen Sie Ihre Rechtsberatung, ob sie darunter fällt und welche Regeln dann gelten.

Kundendaten, die Ihr Unternehmen speichert. Die Datenklausel erfasst Daten, die „nicht für berufliche Zwecke verwendet werden“ (Art. 6 Abs. 1 Buchst. c). Ob Daten, die Ihr Unternehmen über einen Kunden hält, etwa ein gespeichertes Konto oder eine Bestellhistorie, dazugehören, sagt der Text nicht. Kann Ihre KI solche Daten löschen oder verfälschen, fragen Sie Ihre Rechtsberatung.

Wer ist der Hersteller, wenn jemand anderes das System entwickelt?

An den meisten KI-Systemen sind mehrere Unternehmen beteiligt: Eines baut es, eines betreibt es, und meist läuft es auf dem Modell eines weiteren. Die Richtlinie hat für jeden dieser Fälle einen klaren Ausgangspunkt.

Die kurze Antwort: Gilt Ihr System hier als Produkt, können Sie, Ihr Entwickler und Ihr Modellanbieter alle in Anspruch genommen werden, und wer Änderungen nach der Übergabe freigibt, ist ebenso wichtig wie die Frage, wer es gebaut hat.

Der Wortlaut. Hersteller ist, wer ein Produkt entwickelt oder herstellt, wer „ein Produkt entwerfen oder herstellen lässt“ oder wer es mit seinem eigenen Namen oder seiner Marke versieht (Art. 4 Nr. 10 Buchst. a und b). Nach Erwägungsgrund 13 ist ein Softwareentwickler, auch ein Anbieter eines KI-Systems, als Hersteller zu behandeln. Haften mehrere Unternehmen für denselben Schaden, kann die geschädigte Person von jedem einzelnen den gesamten Betrag verlangen („gesamtschuldnerisch“, Art. 12 Abs. 1). Wer zahlt, kann sich nach nationalem Recht bei den anderen schadlos halten (Art. 14).

Ein Beratungsunternehmen baut es für Sie

Die allgemeine Antwort: Gilt Ihr System hier als Produkt, sind Sie wahrscheinlich Hersteller, und Ihr Entwickler möglicherweise ebenfalls. Als Hersteller gilt nach der Richtlinie, wer ein Produkt „entwerfen oder herstellen lässt“ – das tun Sie –, und trägt es Ihren Namen, treten Sie als dessen Hersteller auf (Art. 4 Nr. 10 Buchst. b). Ihr Entwickler hat es entwickelt (Art. 4 Nr. 10 Buchst. a). Eine geschädigte Person könnte sich an einen von beiden halten.

Was der Text den Tatsachen überlässt, ist der Zeitpunkt. Ein Hersteller haftet nicht, wenn er beweist, dass er das Produkt nicht in Verkehr gebracht oder in Betrieb genommen hat. Ob die Übergabe Ihres Entwicklers an Sie als Inverkehrbringen gilt oder erst Ihre erste Nutzung als Inbetriebnahme, hängt davon ab, wie der Vertrag gestaltet ist (Art. 11 Abs. 1 Buchst. a, Art. 4 Nr. 7 bis 9).

Ändern Sie es später wesentlich, entscheidet viel, wer die Änderung freigegeben hat. Nehmen Sie eine wesentliche Änderung vor, die Ihr Entwickler nicht kontrolliert hat, und stellen Sie das System dann bereit oder nehmen es in Betrieb, gelten Sie für diese Änderung als Hersteller. Wer es geändert hat, entgeht der Haftung nur, wenn er beweist, dass der Fehler in einem Teil liegt, den die Änderung nicht berührt hat (Art. 8 Abs. 2, Art. 11 Abs. 1 Buchst. g). Ihr Entwickler kann dann geltend machen, der Fehler sei erst nach seiner Auslieferung entstanden. Dieses Argument bleibt ihm verwehrt, wenn die Änderung in seinem Einflussbereich lag, wozu Änderungen gehören, die er genehmigt hat oder denen er zugestimmt hat (Art. 11 Abs. 1 Buchst. c, Art. 11 Abs. 2 Buchst. d).

Es basiert auf einem Modell des Anbieters

Die allgemeine Antwort: Wer das System darauf aufbaut, ist Hersteller des Produkts und haftet für das gesamte System, einschließlich der Teile des Anbieters, die eingebaut oder in seinem Einflussbereich verbunden sind (Art. 8 Abs. 1, letzter Unterabsatz). Auch der Anbieter kann haften, nämlich als Hersteller einer fehlerhaften Komponente, die das System fehlerhaft gemacht hat (Art. 8 Abs. 1 Buchst. b). Beide haften gegenüber der geschädigten Person (Erwägungsgründe 36 und 53).

Die Richtlinie nennt KI-Modelle oder Modell-APIs nicht. Eine „Komponente“ ist aber jeder körperliche oder nicht körperliche Gegenstand, der in ein Produkt integriert oder mit ihm verbunden ist (Art. 4 Nr. 4), und ein „verbundener Dienst“ ist ein digitaler Dienst, ohne den das Produkt eine oder mehrere seiner Funktionen nicht ausführen könnte (Art. 4 Nr. 3). Ein Modell, das Ihr System aufruft, fällt wahrscheinlich unter eines von beiden, und das sollten Sie für Ihren Aufbau bestätigen. Der Anbieter hat eine eigene Verteidigung: Er haftet nicht, wenn der Fehler aus der Konstruktion Ihres Systems oder aus Ihren Anweisungen an ihn stammt (Art. 11 Abs. 1 Buchst. f). Sitzt der Anbieter außerhalb der EU, können auch sein EU-Importeur oder Bevollmächtigter haften (Art. 8 Abs. 1 Buchst. c).

Zusammengesetzt. Angenommen, Ihr Unternehmen betreibt einen Agenten für Kunden, den eine Beratungsfirma auf dem Modell eines US-Anbieters gebaut hat. Gilt das System als Produkt, sind Sie und die Beratungsfirma wahrscheinlich beide Hersteller, und der Anbieter kann für sein Modell als Komponente haften, oder über seinen EU-Importeur oder Bevollmächtigten. Wie auch immer der Anbieter aufgestellt ist: Gehen Sie nicht davon aus, dass ein Anspruch beim Anbieter endet. Als wahrscheinlicher Hersteller gehören Sie zu den Unternehmen, die er erreichen kann (Art. 8 Abs. 1, Art. 12 Abs. 1).

Was Ihre Verträge leisten können und was nicht. Wer am Ende wem zahlt, also zwischen Ihnen, Ihrem Entwickler und Ihren Anbietern, richtet sich nach nationalem Recht (Art. 14), und Ihre Verträge können das gestalten. Sie können aber nicht verringern, was der geschädigten Person zusteht (Art. 15).

Die genaue Aufteilung hängt von Ihren Verträgen und den Tatsachen ab: wer was gebaut hat, wessen Name darauf steht, wer die Updates kontrolliert und wann es live ging. Verstehen Sie das als Landkarte, und lassen Sie Ihre Rechtsberatung Ihren eigenen Aufbau daran prüfen.

So läuft ein Anspruch ab: Offenlegung, dann Vermutungen

Die klagende Seite muss weiterhin drei Dinge beweisen: dass das Produkt fehlerhaft war, dass ein Schaden entstanden ist und dass der Fehler ihn verursacht hat (Art. 10 Abs. 1). Neu ist, wie viel Hilfe sie dabei bekommt.

Schritt 1: Offenlegung. Legt die klagende Seite Tatsachen und Beweise vor, die den Anspruch plausibel machen, kann ein Gericht anordnen, dass Sie relevante Beweismittel offenlegen, die Sie besitzen (Art. 9 Abs. 1). Das ist auf das Notwendige und Verhältnismäßige begrenzt, Geschäftsgeheimnisse sind geschützt, und das Gericht kann verlangen, dass die Offenlegung leicht zugänglich und leicht verständlich erfolgt (Art. 9 Abs. 3 bis 6).

Schritt 2: Vermutungen. Ein Gericht vermutet, dass Ihr Produkt fehlerhaft ist, wenn eines davon zutrifft (Art. 10 Abs. 2):

• Sie legen die Beweismittel nicht offen;
• die klagende Seite weist nach, dass das Produkt verbindliche Produktsicherheitsanforderungen nicht erfüllt, die vor diesem Risiko schützen sollen;
• die klagende Seite weist nach, dass der Schaden durch eine offensichtliche Funktionsstörung bei vernünftigerweise vorhersehbarem Gebrauch oder unter gewöhnlichen Umständen entstanden ist.

Steht fest, dass das Produkt fehlerhaft ist und der Schaden von der Art ist, die typischerweise zu diesem Fehler passt, wird auch der ursächliche Zusammenhang vermutet (Art. 10 Abs. 3).

Schritt 3: Die Komplexitätsregel. Ist es auch nach der Offenlegung übermäßig schwierig, den Fall zu beweisen, „insbesondere aufgrund der technischen oder wissenschaftlichen Komplexität“, geht ein Gericht von Fehlerhaftigkeit, Ursächlichkeit oder beidem aus, sofern die klagende Seite darlegt, dass dies wahrscheinlich ist (Art. 10 Abs. 4). Erwägungsgrund 48 nennt maschinelles Lernen als Beispiel für komplexe Technologie.

Schritt 4: Sie können jede dieser Vermutungen widerlegen (das Gegenteil beweisen) (Art. 10 Abs. 5). Die Richtlinie gibt Ihnen dieses Recht. Wie Sie es ausüben, sagt sie nicht.

Vier Punkte, die für KI schwerer wiegen als für einen Toaster

Der Großteil der Richtlinie liest sich für jedes Produkt gleich. Vier Punkte treffen KI härter.

• Es verändert sich laufend. Gerichte berücksichtigen „die Auswirkungen der Fähigkeit des Produkts, nach seinem Inverkehrbringen oder seiner Inbetriebnahme weiter zu lernen oder neue Funktionen zu erwerben“ (Art. 7 Abs. 2 Buchst. c). Änderungen, die Ihr Team vornimmt, etwa Feinabstimmung, neue Prompts oder ein neues Modell, fallen stattdessen unter die Regeln zu Änderungen und Updates (Art. 8 Abs. 2, Art. 11 Abs. 2).
• Sicherheit schließt Cybersicherheit ein. Gerichte berücksichtigen außerdem sicherheitsrelevante Cybersicherheitsanforderungen (Art. 7 Abs. 2 Buchst. f). Sicherheitstests wie die Prompt-Injection-Tests aus meinem letzten Beitrag sind deshalb nicht nur eine IT-Frage.
• Updates bleiben Ihre Verantwortung. Sie entgehen der Haftung nicht mit dem Nachweis, der Fehler sei erst nach der Auslieferung entstanden, wenn er auf Software, ein Update oder ein fehlendes, für die Sicherheit nötiges Update zurückgeht und sich noch in Ihrem Einflussbereich befand (Art. 11 Abs. 2). Zum Einflussbereich gehört auch die Möglichkeit, Updates bereitzustellen (Art. 4 Nr. 5 Buchst. b).
• Vertraglich ausschließen geht nicht. Die Haftung gegenüber der geschädigten Person lässt sich vertraglich weder beschränken noch ausschließen (Art. 15). Ihre Nutzungsbedingungen leisten das nicht.

Eine Regel spricht für Sie: Ein Produkt ist nicht schon deshalb fehlerhaft, weil später eine bessere Version oder ein Update erscheint (Art. 7 Abs. 3). Ein Update allein macht die frühere Version nicht fehlerhaft.

Was Sie ab jetzt aufbewahren sollten

Dieser Teil ist meine Sicht, nicht der Text der Richtlinie. Müssen Sie eine Vermutung widerlegen oder Beweise offenlegen, die ein Gericht nachvollziehen kann, ist zeitnah entstandenes Material am stärksten: was das System leisten sollte, wie es getestet wurde, was es tat und was sich änderte. Eine Aufzeichnung, die erst nach Eingang eines Anspruchs entsteht, wiegt weniger.

Diese Beweise decken sich mit den fünf Lücken aus meinem letzten Beitrag: den fünf Dingen, die ein Pilotprojekt benötigt, bevor es für echte Kunden bereit ist.

Zwei praktische Hinweise:

• Bewahren Sie es lange genug auf. Ansprüche können bis zu 10 Jahre nach dem Inverkehrbringen kommen, bei manchen Schäden länger (Art. 17). Nach 30 Tagen gelöschte Traces helfen im dritten Jahr nicht. Testsätze, Änderungsprotokolle und Erfolgsquoten enthalten wenige oder keine personenbezogenen Daten, bewahren Sie sie also lange auf. Fall-Traces enthalten sie oft; klären Sie deshalb mit der oder dem Datenschutzbeauftragten, wie lange Sie sie aufbewahren und ob Sie pseudonymisieren.

• Halten Sie es lesbar. Ein Gericht kann Beweismittel in leicht verständlicher Form verlangen (Art. 9 Abs. 6). Ein Dashboard-Export, den nur Ihr Team lesen kann, ist ein Anfang, nicht das Ziel.

Fünf Fragen, die Sie Ihrem Team diese Woche stellen sollten

Eine Frage pro Nachweis. Eine vage Antwort zeigt Ihnen, wo Sie anfangen müssen.

1. Anwendungsbereich: Könnte dieses System jemanden verletzen, Sachen einer Person beschädigen oder nicht beruflich genutzte Daten einer Person vernichten oder beschädigen? Wer hat das geprüft?
2. Zeitpunkt: Wird es am oder nach dem 9. Dezember 2026 in Verkehr gebracht oder in Betrieb genommen oder nach diesem Datum wesentlich verändert?
3. Tests: Wenn ein Gericht fragte, wie es vor der Freigabe getestet wurde, welche datierten Testergebnisse würden wir übergeben?
4. Änderungen: Können wir jede Änderung seit dem Start (Prompt, Modell, Tool) mit dem zugehörigen Testergebnis nachweisen?
5. Aufbewahrung: Wie lange bewahren wir Traces und Testergebnisse auf, und gäbe es sie in drei Jahren noch?

Wo Sie anfangen

Die Richtlinie verlangt nicht, dass Sie aufhören, KI zu bauen. Sie fragt, ob Sie im Nachhinein zeigen können, wie sie gebaut, getestet und geändert wurde. Bei einem System, das noch entsteht, lassen sich diese Nachweise jetzt viel leichter führen, als sie später zu rekonstruieren.

Haben Sie ein Pilotprojekt kurz vor dem Start, oder noch nichts gebaut, aber einen Workflow, bei dem Sie wissen, dass es nötig ist, baut der KI-Implementierungssprint das von Tag eins an ein: Tests an Fällen, die das System nie gesehen hat, Traces jedes Falls, Sicherheitstests und eine Übergabe mit Code, Dokumentation, Testfällen und Prüfpfad in Ihren Konten. Schon live, mit einer geplanten neuen Version? Die neue Version kann den Sprint bei „Pilotprojekt vorhanden“ beginnen, mit den Nachweisen von Woche eins an eingeplant. Wenn Sie mehrere Workflows abwägen und nicht sicher sind, welcher gefährdet ist, ist die KI-Wertanalyse der richtige Anfang.

Dieser Beitrag ist eine allgemeine Orientierung, keine Rechtsberatung. Er gibt die Richtlinie (EU) 2024/2853 und den deutschen Regierungsentwurf in der veröffentlichten Fassung wieder und nennt den Artikel, wo der genaue Wortlaut zählt. Der Abschnitt dazu, wer Hersteller ist, zeichnet das allgemeine Bild, das der Text trägt; die genaue Aufteilung in Ihrem Fall hängt von Ihren Verträgen und Tatsachen ab, lassen Sie sie daher von Ihrer eigenen Rechtsberatung prüfen. Wo dieser Beitrag sagt, die Richtlinie klärt eine Frage nicht, meint er, dass der Text sie nicht klärt, nicht dass die Antwort unerkennbar wäre.

Quellen

1. Richtlinie (EU) 2024/2853 über die Haftung für fehlerhafte Produkte
2. Richtlinie 85/374/EWG des Rates
3. Deutscher Bundestag, Drucksache 21/4297: Entwurf eines Gesetzes zur Modernisierung des Produkthaftungsrechts (Februar 2026)
4. Amtsblatt C/2025/5423: Rücknahme von Vorschlägen der Kommission (Okt. 2025)
5. Verordnung (EU) 2026/1744
6. Berichtigung der Richtlinie (EU) 2024/2853, ABl. L, 2026/90364, 7. Mai 2026