Nach dem Update stellt sich die Haftungsfrage neu

Kurzfassung: Wenn ein autonomer Agent Schaden verursacht, entscheidet nicht allein die letzte Nutzeranweisung über die Haftung. Die neue EU-Produkthaftungsrichtlinie berücksichtigt auch die Kontrolle über Software und spätere Änderungen. Wer ein Produkt außerhalb der Herstellerkontrolle wesentlich verändert und anschließend bereitstellt oder in Betrieb nimmt, kann selbst als Hersteller gelten. Für Integrationsbetriebe verändert das den Umfang ihrer Leistung.

Ein Unternehmen setzt einen Agenten ein, der Wartungshinweise nicht nur formuliert, sondern Maschinenbefehle auslöst. Nach einer Erweiterung verursacht das System einen Schaden. Wer hat ihn zu verantworten: der Modellanbieter, der Hersteller der Anwendung, der Integrationsbetrieb oder das einsetzende Unternehmen? Das ist ein gedachtes Beispiel. Es zeigt, warum die Unterscheidung zwischen beauftragtem und selbstständigem Handeln allein zu kurz greift. Für die Geschäftsleitung zählt auch, wer die schadenverursachende Funktion eingebaut hat und unter wessen Kontrolle sie stand.

Die Kontrolle endet nicht an der Auslieferung

Die neue EU-Produkthaftungsrichtlinie zählt Software ausdrücklich zu den Produkten. Ihre beschlossene Ratsfassung vom 23. Oktober 2024 unterscheidet unter anderem den Hersteller eines fehlerhaften Produkts und unter bestimmten Voraussetzungen den Hersteller einer fehlerhaften Komponente. Der Name des verwendeten Sprachmodells beantwortet deshalb noch nicht, welche Beteiligten bei einem konkreten Schaden in Betracht kommen.

Bei vernetzter Software bleibt der ausgelieferte Zustand zudem selten unverändert. Funktionen werden ergänzt, Komponenten ausgetauscht und Sicherheitslücken geschlossen. Artikel 4 erfasst Herstellerkontrolle unter anderem dann, wenn der Hersteller die Integration oder Lieferung einer Komponente selbst vornimmt, autorisiert oder ihr zustimmt. Auch die Möglichkeit, Softwareaktualisierungen selbst oder über Dritte bereitzustellen, gehört zur Definition.

Das hat eine konkrete Folge für spätere Fehler. Artikel 11 begrenzt unter bestimmten Voraussetzungen die Entlastung mit dem Argument, die Fehlerhaftigkeit sei erst nach dem Inverkehrbringen entstanden. Genannt werden etwa Software, Aktualisierungen und fehlende sicherheitsnotwendige Aktualisierungen, soweit diese Ursachen unter Herstellerkontrolle liegen. Ein Hersteller ist also nicht schon deshalb aus der Betrachtung, weil die erste Version bei Lieferung fehlerfrei war.

Dies ist eine Einordnung des EU-Rechtsrahmens, keine Entscheidung über einen deutschen Agentenschaden. Die Richtlinie enthält Umsetzungs- und Übergangsregeln. Welches Recht auf ein bestimmtes Produkt und Ereignis anwendbar ist, muss gesondert geprüft werden. Aus der Richtlinie folgt weder eine pauschale Anbieterhaftung noch eine Freistellung autonom handelnder Systeme.

Ein Umbau kann die rechtliche Rolle verändern

Besonders relevant für das Integrationsgeschäft ist Artikel 8 Absatz 2. Wer ein Produkt außerhalb der Herstellerkontrolle wesentlich verändert und es danach auf dem Markt bereitstellt oder in Betrieb nimmt, wird für die dortige Haftung als Hersteller behandelt. Ein Unternehmen kann dadurch über die Rolle des bloßen Anwenders oder technischen Vermittlers hinausgehen.

Nicht jede Konfiguration ist deshalb eine wesentliche Änderung. Artikel 4 verweist zunächst auf einschlägige Vorschriften zur Produktsicherheit. Soweit diese keine entsprechende Schwelle festlegen, nennt die Richtlinie weitere Bedingungen: Eine Änderung betrifft die ursprüngliche Leistung, den Zweck oder die Art des Produkts, ohne in der ursprünglichen Risikobewertung vorgesehen zu sein. Hinzukommen muss eine veränderte Gefährdung, eine neue Gefährdung oder ein erhöhtes Risiko.

Im gedachten Wartungsbeispiel ist die Erweiterung von einer Empfehlung zu einem ausführbaren Maschinenbefehl deshalb genauer zu betrachten. Sie könnte Verwendung und Gefährdung verändern. Ob die rechtliche Schwelle erreicht wird, hängt aber vom konkreten System, der ursprünglichen Bewertung und dem einschlägigen Recht ab. Ebenso macht es einen Unterschied, ob der ursprüngliche Hersteller die Erweiterung kontrolliert oder ein Dritter sie außerhalb dieser Kontrolle entwickelt.

Darin liegt eine Verschiebung innerhalb der Wertschöpfungskette. Ein Integrationsbetrieb verkauft möglicherweise nicht mehr nur die Verbindung vorhandener Funktionen. Er gestaltet ein verändertes Produkt mit eigener rechtlicher Bedeutung. Diese mögliche Leistungserweiterung gehört in die Kalkulation und Leistungsbeschreibung, nicht erst in die Diskussion nach einem Schaden.

Der Schaden bestimmt den passenden Anspruch

Die Produkthaftungsrichtlinie deckt nicht sämtliche Folgen einer falschen Agentenhandlung ab. Artikel 6 nennt insbesondere Tod und Körperverletzung, bestimmte Sachschäden sowie die Zerstörung oder Beschädigung nicht beruflich verwendeter Daten. Ausschließlich beruflich genutzte Sachen sind aus dem dortigen Sachschadenskatalog ausgenommen.

Ein Personenschaden durch einen fehlerhaften Maschinenbefehl ist deshalb anders einzuordnen als eine falsche Zahlung aus einer Buchhaltungsanwendung oder ein beschädigter rein betrieblicher Datenbestand. Eine Fehlzahlung wird nicht allein dadurch zu einem erfassten Produkthaftungsschaden, dass ein KI-System beteiligt war. Andere vertragliche oder außervertragliche Ansprüche sind damit nicht ausgeschlossen; sie folgen nur nicht automatisch aus diesem Schadenskatalog.

Auch bei einem erfassten Schaden bleiben Fehlerhaftigkeit, Ursachenzusammenhang und die jeweils erforderlichen Haftungsvoraussetzungen zu klären. „Der Agent hat selbst entschieden“ beschreibt zunächst einen Ablauf, keine abgeschlossene juristische Bewertung. Umgekehrt beweist eine menschliche Freigabe nicht, dass ein vorgeschaltetes Produkt fehlerfrei war. Die technische Handlungskette und die rechtliche Anspruchsgrundlage sind verschiedene Ebenen.

Die Erweiterung ist eine eigene Beschaffungsentscheidung

Für das KI-Management lohnt sich deshalb ein genauer Blick auf die Veränderung zwischen zwei Versionen. Welche Funktion kam hinzu? War sie für den ursprünglichen Verwendungszweck vorgesehen? Wer hat sie autorisiert, geliefert und sicherheitsfachlich beurteilt? Die Antworten helfen einzuordnen, ob eine Erweiterung innerhalb der bisherigen Herstellerkontrolle bleibt oder ein eigenständig verändertes Produkt entsteht.

Die Vereinbarung mit einem Integrationsbetrieb sollte diese konkrete Leistung beschreiben. Ein pauschaler Auftrag zur „Automatisierung“ lässt offen, ob lediglich Vorschläge vorbereitet oder zusätzliche Handlungen ermöglicht werden. Ein nachvollziehbarer Versionsstand hilft später, die schadenverursachende Funktion zu bestimmen. Er nimmt die rechtliche Bewertung nicht vorweg.

Dabei sind Ansprüche Geschädigter vom internen Ausgleich zwischen Lieferanten zu trennen. Artikel 15 untersagt den vertraglichen Ausschluss oder die Begrenzung der Haftung nach der Richtlinie gegenüber Geschädigten. Eine interne Freistellungsvereinbarung ist deshalb keine allgemeine Antwort darauf, wer von außen in Anspruch genommen werden kann.

So wird eine Softwareerweiterung auch kaufmännisch genauer sichtbar: Ihr Wert liegt in der zusätzlichen Funktion, ihr Leistungsumfang möglicherweise in einer veränderten Herstellerrolle. Beides lässt sich vor der Beauftragung prüfen. Der Grad der Autonomie bleibt wichtig; entscheidend ist daneben, was verändert wurde und wer diese Veränderung beherrscht.