EU-Produkthaftung 2026: Haftung für KI-generierten Code erklärt

Die EU-Produkthaftungsrichtlinie 2024/2853 stuft Software erstmals ausdrücklich als Produkt ein – vom Betriebssystem bis zur SaaS-App, KI-Systeme eingeschlossen. Sie trat am 8. Dezember 2024 in Kraft, Deutschland muss sie bis zum 9. Dezember 2026 umsetzen. Für alle, die mit KI-Tools Software bauen und verkaufen, verschiebt das die Haftungsfrage grundlegend.

Software ist jetzt ein Produkt – auch deine SaaS

Das bisherige Produkthaftungsgesetz von 1989 kannte Software bestenfalls als Grauzone. Die Richtlinie (EU) 2024/2853 räumt damit auf: Als Produkt gilt Software in ihrer ganzen Breite – lokal installiert, heruntergeladen, aus der Cloud bezogen oder als SaaS betrieben; KI-Systeme werden als Unterkategorie von Software behandelt. Eine feine, für Entwickler relevante Grenze zieht die Richtlinie beim Quellcode selbst: Er gilt als reine Information und ist kein Produkt. Haftungsauslöser ist also nicht das Repo, sondern das in Verkehr gebrachte Programm.

Produkthaftung bedeutet dabei verschuldensunabhängige Haftung: Der Geschädigte muss dir kein Verschulden nachweisen, nur Fehler, Schaden und Kausalität. Neu ist auch der Umfang – die bisherige Selbstbeteiligung von 500 Euro bei Sachschäden fällt weg, ebenso die Haftungshöchstgrenze von 85 Millionen Euro bei Personenschäden. Ersatzfähig sind künftig auch Schäden durch Verlust oder Beschädigung von Daten. Und: Hersteller haften auch für Produkte, die sich nach dem Inverkehrbringen verändern, etwa durch Updates – oder durch fehlende Sicherheitsupdates.

Beweislastumkehr und Offenlegungspflicht: Was vor Gericht anders läuft

Zwei Mechanismen der Richtlinie treffen Softwareanbieter besonders. Erstens die Offenlegungspflicht (Art. 9): Legt ein Geschädigter Tatsachen vor, die seinen Anspruch plausibel machen, kann das Gericht dich verpflichten, relevante Beweismittel herauszugeben – Architektur-Doku, Testprotokolle, interne Analysen. Kommst du dem nicht nach, wird die Fehlerhaftigkeit deines Produkts vermutet.

Zweitens die Beweiserleichterungen (Art. 10): Verstößt ein Produkt gegen gesetzliche Sicherheitsanforderungen, wird seine Fehlerhaftigkeit vermutet. Bei wissenschaftlich oder technisch komplexen Sachverhalten – und dazu dürften KI-gestützte Systeme regelmäßig zählen – genügt es, wenn der Geschädigte Fehler und Kausalzusammenhang plausibel darlegt; widerlegen musst dann du. Die Konsequenz für den Dev-Alltag: Wer keine Doku hat, kann sich nicht verteidigen. Fehlende Testprotokolle sind ab Dezember 2026 kein Schönheitsfehler mehr, sondern ein Prozessrisiko.

Wen die Haftung trifft: Freelancer, Agenturen, Solo-Founder

Die Richtlinie adressiert Wirtschaftsakteure entlang der ganzen Kette: Hersteller, Importeure, Fulfilment-Dienstleister – und Hersteller von Komponenten, worunter auch integrierte KI-Modelle fallen können. Für die Praxis heißt das: Der Solo-Founder, der seine per Vibe Coding gebaute App kommerziell anbietet, ist Hersteller im Sinne der Richtlinie. Die Agentur, die Kundensoftware ausliefert, ebenso. Beim Freelancer kommt es auf die Konstellation an: Wer im Werkvertrag Software für einen Auftraggeber erstellt, der sie unter eigenem Namen vermarktet, haftet dem Endkunden gegenüber meist nicht produkthaftungsrechtlich – wohl aber vertraglich dem Auftraggeber, mit 2 Jahren Gewährleistung nach §634a BGB und möglichen Regressklauseln.

Eine wichtige Entlastung gibt es für die Community: Open-Source-Software, die außerhalb einer kommerziellen Tätigkeit entwickelt oder bereitgestellt wird, bleibt von der verschuldensunabhängigen Haftung ausgenommen. Wer Open Source dagegen geschäftlich in sein Produkt integriert, haftet für das Gesamtprodukt – inklusive der fremden Komponenten. Das kostenlose Side-Project auf GitHub bleibt also draußen; sobald du daraus einen bezahlten Dienst, einen kommerziellen Fork oder ein Support-Geschäft machst, wechselst du die Seite.

Zwei Klarstellungen zum Anwendungsbereich helfen bei der Einordnung. Die Produkthaftung schützt Geschädigte bei Personenschäden, Schäden an privat genutzten Sachen und – neu – bei Datenverlust; reine Vermögensschäden eines Geschäftskunden, etwa entgangener Umsatz durch einen Bug, laufen weiter über das Vertragsrecht. Und sitzt der Hersteller außerhalb der EU, verlagert die Richtlinie die Haftung auf Importeure oder Bevollmächtigte in der Union – der Verweis „unser Anbieter sitzt in den USA" führt für Geschädigte nicht mehr ins Leere.

„Das hat die KI geschrieben" schützt nicht – im Gegenteil

KI-generierter Code bekommt in diesem Regime keine Sonderbehandlung. Haftungsanknüpfung ist das Inverkehrbringen, nicht die Urheberschaft der einzelnen Zeile – ob Claude Code, Cursor oder ein Praktikant den Bug produziert hat, ist für den Geschädigten irrelevant. Diskutiert wird in der juristischen Literatur eher die andere Richtung: Auch Anbieter von KI-Modellen können als Komponentenhersteller in den Adressatenkreis rutschen, wenn ihr Modell in ein Produkt integriert wird. Für dich als Anbieter ändert das am Ausgangspunkt nichts – du stehst vorn in der Haftungskette.

Ungeprüft übernommener KI-Code verschärft die Lage sogar: Wenn Gerichte den Entwicklungsprozess über die Offenlegungspflicht ausleuchten, sieht ein Workflow ohne Review, ohne Tests und ohne dokumentierte Abnahme schlecht aus. Die im Mai 2026 publik gewordene Analyse von rund 380.000 KI-generierten Apps mit tausenden offenen Datenlecks zeigt, wie real das Szenario „Sicherheitsanforderung verletzt, Fehlerhaftigkeit vermutet" ist.

Alte vs. neue Rechtslage im Vergleich

Punkt	ProdHaftG (bis 2026)	Richtlinie (EU) 2024/2853
Software als Produkt	Umstritten, meist nur auf Datenträger	Ausdrücklich ja – inkl. SaaS und KI-Systemen
Beweislast	Voll beim Geschädigten	Offenlegungspflicht + Vermutungsregeln (Art. 9, 10)
Selbstbeteiligung Sachschaden	500 €	Entfällt
Haftungshöchstgrenze	85 Mio. € (Personenschäden)	Entfällt
Datenverlust	Nicht erfasst	Ersatzfähig
Updates / Weiterentwicklung	Nicht geregelt	Haftung auch nach Inverkehrbringen

Drei Dev-Praktiken, die ab jetzt zählen: Doku, Review, Vertrag

Die gute Nachricht: Die Gegenmaßnahmen sind gewohnte Engineering-Hygiene, nur mit neuem Ernst. Drei Bereiche solltest du bis Dezember 2026 aufsetzen.

1. Dokumentation als Beweismittel behandeln. Architektur-Entscheidungen, Testberichte, Security-Checks und Release-Notes so ablegen, dass du sie in einem Verfahren vorlegen kannst. Auch KI-Nutzung dokumentieren: welches Tool, welcher Review-Stand. Was du vorlegen kannst, entkräftet Vermutungen – was fehlt, begründet sie.
2. Review- und Update-Prozesse festschreiben. Kein KI-generierter Code ohne menschliches Review in Produktion; automatisierte Tests und Dependency-Scans als Pflichtgate. Dazu ein Update-Prozess, denn die Haftung endet nicht beim Launch: Bekannte Schwachstellen ungefixt zu lassen, wird zum Produktfehler.
3. Verträge und Versicherung anpassen. Für Freelancer und Agenturen: Haftung für leichte Fahrlässigkeit auf den Auftragswert begrenzen (bei Vorsatz und grober Fahrlässigkeit geht das nicht), KI-Einsatz und Abnahmeprozess explizit regeln, und die Haftungsbegrenzung mit einer passenden IT-Haftpflicht unterlegen – eine Begrenzung ohne Versicherungsschutz ist wenig wert.

Der deutsche Gesetzgeber arbeitete Stand Frühjahr 2026 noch an der Umsetzung; am Kern – Software ist Produkt, Beweislast kippt Richtung Anbieter – ändert das nichts mehr, denn die Richtlinie gibt ihn verbindlich vor. Wer jetzt Doku- und Review-Prozesse aufsetzt, launcht im Dezember 2026 entspannt. Für die übrigen Launch-Pflichten lohnt der Blick in die Checkliste zu Impressum, DSGVO und Cookies für KI-gebaute Apps.

Dieser Artikel ist keine Rechtsberatung. Für verbindliche Auskünfte wende dich an eine Kanzlei.