Die letzte Flasche von Mrs Donoghue

Am 26. August 1928 betrat eine Frau aus Glasgow namens May Donoghue mit einer Freundin ein Café in Paisley, einem Städtchen rund sieben Meilen vom Stadtzentrum entfernt. Die Freundin bestellte und bezahlte für sie einen Scotsman ice cream float, ein Eis mit Ingwerlimonade. Der Wirt des Wellmeadow Café servierte das Getränk in einer undurchsichtigen, dunklen Glasflasche, einer damals verbreiteten Art — das trübe Glas verbarg etwaige Sedimente.

Als die zweite Hälfte der Flüssigkeit zur geschmolzenen Eiscreme ins Glas gegossen wurde, schlüpfte aus der Flasche, von der Limonade mitgespült, eine Schnecke in fortgeschrittenem Verwesungszustand. May Donoghue erkrankte schwer an Gastroenteritis, wurde am 29. August von einem Arzt aufgesucht und am 16. September notfallmäßig in die Glasgow Royal Infirmary aufgenommen. Vier Jahre später, 1932, fällte das House of Lords ein Urteil, das als Grundstein des modernen Produkthaftungsrechts der Common-Law-Welt gilt.

Die Schnecke in der Flasche

Die Entscheidung fiel mit drei zu zwei Stimmen. Verfasser des Mehrheitsvotums war Lord Atkin. In dem berühmten Passus, den Jurastudierende noch heute auswendig lernen, formulierte er den Neighbour Principle — die Pflicht jedes Einzelnen, sich um den juristischen „Nächsten“ zu sorgen; Nächster meinte hier jeden, der vernünftigerweise als Empfänger der Folgen des eigenen Verhaltens vorhersehbar war.

Seitdem haftet der Hersteller für sein Produkt auch gegenüber jenen, mit denen er keine vertraglichen Beziehungen unterhält — auch wenn die Flasche über einen Distributor und ein Café zum Verbraucher gelangt, auch wenn zwischen Fabrik und Donoghues Gastroenteritis Wochen Lagerhaltung und Kilometer Straße liegen.

Was beim Lesen des Urteils fast niemandem auffällt: der Richter brauchte, um den Neighbour Principle zu schreiben, eine genaue ontologische Voraussetzung — eine bestimmte Vorstellung davon, was der besprochene Gegenstand sei. Der Gegenstand war die Flasche. Ein bounded Artefakt, mit klaren Konturen, identifizierbar, prüfbar, aufbewahrbar.

Die Flasche wurde in einer bestimmten Anlage produziert, bei David Stevenson in Paisley, zu einem datierbaren Zeitpunkt befüllt, mit einem Stopfen versiegelt, der die Integrität bis zum Verkaufsort gewährleistete. Hätten Anwälte es verlangt, sie hätten die Charge prüfen, das Glas analysieren, die Lieferkette der Zucker und Aromen verifizieren lassen können. Die causa materialis im aristotelischen Sinn war erreichbar. Die causa efficiens — der Produktionsprozess — war dokumentiert. Die causa formalis — die typische Form einer Limonadenflasche — allgemein bekannt.

Das gesamte moderne Produkthaftungsrecht, das auf Donoghue v. Stevenson aufgebaut wurde, setzt diese sehr einfache und zugleich entscheidende Sache voraus: man kann auf ein Objekt zeigen und sagen „dieses“, und der zeigende Finger findet am Ende stets etwas vor.

Die neue PLD und das Kategorienproblem

1985 hat Europa mit der Richtlinie 85/374/EWG das Donoghue-Prinzip kontinental übernommen, ausgeweitet, systematisiert. Die Product Liability Directive spricht von „fehlerhaften Produkten“ und etabliert eine objektive Herstellerhaftung, unabhängig vom Verschulden, für durch das Produkt verursachte Schäden.

Vierzig Jahre später, am 23. Oktober 2024, wurde die Richtlinie 2024/2853 verabschiedet, am 9. Dezember 2024 in Kraft, bis 9. Dezember 2026 in nationales Recht umzusetzen — mit Aufhebung der Richtlinie von 1985 zu jenem Datum. Die neue PLD wurde explizit für Software gedacht und nimmt digitale Dateien, Softwarekomponenten, Anwendungen und KI-Systeme in den Produktbegriff auf. Eine der ehrgeizigsten Reformen des EU-Zivilhaftungsrechts überhaupt.

Dass es vierzig Jahre brauchte, sie zu überdenken, und dass sie trotz aller Anstrengungen ihrer Verfasser bei Inkrafttreten bereits ungenügend zu sein droht, ist niemandes Schuld. Es ist die Folge eines Problems, das das Recht noch nicht präzise benennen konnte. Das Problem: das „Produkt“, auf dem Lord Atkin und seine Nachfolger zwei Jahrhunderte Rechtsprechung errichtet haben, gibt es in heutiger Software nicht mehr.

Eine Minute lohnt es sich, zu verstehen, wo es geblieben ist — denn die Diagnose ist Ausgangspunkt für alles Folgende.

Von der Schallplatte zum Konzert

Lange war Software ein Produkt im vollen, herkömmlichen Sinn. Aus den Bell Labs ging man heraus in die Massenverteilung mit Unix, später mit Betriebssystemen für Personal Computer.

Eine Anwendung der 80er oder 90er war ein Dateibündel auf Disketten, dann CDs, dann DVDs, mit Versionsnummer, identifizierendem Hash, im Tresor aufbewahrbarer Kopie. Bei einem Defekt konnte man, zumindest theoretisch, die exakte Binär-Version isolieren, mit der vermeintlich korrekten vergleichen, den Bug identifizieren. Windows 95 war ein Produkt. Microsoft Word 97 war ein Produkt. Sogar ein Spiel wie Baldur’s Gate war ein Produkt, mit nummerierten, aufbewahrbaren Patches.

Klar, auch damals hing Software von Dingen ab, die nicht das Produkt im engen Sinn waren — Treiber, Firmware, Netzwerkprotokolle, Systemdienste. Doch diese Abhängigkeiten waren statisch, deklariert, zahlenmäßig begrenzt und vor allem durch ein autarkes Artefakt vermittelt, das man auch nach vielen Jahren noch konservieren und reproduzieren konnte. Die CD-Kopie von Windows 95, die ein digitaler Archivar heute aufbewahrt, ist Bit für Bit noch identisch mit der von 1995. Das Produkt als Objekt mit zeitlicher Kontinuität existierte.

Anfang der 2000er beginnt sich etwas zu ändern, und die Veränderung beschleunigt sich im Folgejahrzehnt drastisch. Der Übergang zum Software as a Service verlagert die Anwendung vom lokalen Datenträger des Kunden zum Server des Anbieters. Anfangs eine Verteilungsfrage, bald eine ontologische Transformation.

Wenn die Anwendung auf einem entfernten Server läuft, ist die Version, die der Nutzer in einem gegebenen Moment verwendet, keine stabile Eigenschaft mehr — sie ist eine momentane, jederzeit vom Anbieter ohne Ankündigung neu verhandelbare Eigenschaft. Continuous Deployment führt diese Fluidität zum natürlichen Endpunkt: Unternehmen veröffentlichen täglich Dutzende oder Hunderte Änderungen in Produktion, ohne dass irgendjemand — auch intern nicht — die genaue Konfiguration des Systems am Dienstag um 14:23 Uhr vor drei Monaten exakt rekonstruieren könnte.

Parallel ändert sich die innere Komposition der Software. Seit Anfang der 2010er, dank Ökosystemen wie npm, Maven oder PyPI, heißt eine Anwendung schreiben: Hunderte oder Tausende Drittpakete einzubinden, jedes seinerseits aus Drittpaketen zusammengesetzt, in einem Graph transitiver Abhängigkeiten, den kein Mensch ganz liest und der sich asynchron zum eigenen Code aktualisiert. Der left-pad-Vorfall 2016, als ein einzelner Entwickler ein elf Zeilen langes npm-Paket löschte und damit Build-Pipelines und Installationsprozesse großer Teile der JavaScript-Welt zum Absturz brachte, war der Moment, in dem die Industrie kurz bemerkte, wie fragil und verteilt geworden war, was sie weiter „Produkt“ nannte.

Die jüngste Beschleunigung, in den letzten Monaten, ist der Einzug von Sprachmodellen in die Software-Produktionskette. Hier ist der Sprung nicht nur quantitativ, sondern kategorial: was ins Produkt einzieht, ist keine deterministische Befehlssequenz, sondern eine probabilistische Komponente, deren Outputs auch bei gleichem Input nicht exakt reproduzierbar sind, und deren Gewichte, sobald der Anbieter zum nächsten Modell übergeht, möglicherweise nicht mehr zugänglich sind.

Eine heute laufende Anwendung, die per API ein Frontier-Modell nutzt, ist eine Anwendung, deren beobachtbares Verhalten von einer Komponente abhängt, die sich morgen anders verhalten könnte, in zwei Jahren nicht mehr in einer wiederherstellbaren Form existieren könnte und deren inneres Funktionieren niemand inspiziert — nicht einmal die Trainerin. Wer Software entwickelt, weiß: würde uns ein Nutzer von vor fünf Jahren bitten, einen damals beobachteten Bug exakt zu reproduzieren, wäre die ehrliche Antwort, dass wir es nicht können — denn das System, das den Bug erzeugte, existiert in keiner restorable Konfiguration mehr. Abhängigkeiten aktualisiert, externe APIs mit neuem Vertrag, Datenbank migriert, KI-Modell ersetzt. Wir haben Logs. Wir haben den Code unserer Anwendung. Aber das Ereignis, das den Bug erzeugte, war ein Konzert; von Konzerten bleiben Aufnahmen, nicht Konzerte.

Diese Metapher, glaube ich, fasst den ontologischen Sprung am besten. Heutige Software ist keine Schallplatte mehr, sie ist ein Konzert.

Die Schallplatte ist ein stabiles, bewahrbares, vergleichbares Artefakt, ein Objekt mit zeitlicher Identität. Das Konzert ist ein im Raum und in der Zeit verteiltes Ereignis, von vielen Agenturen in Echtzeit ko-produziert, unwiederholbar — von dem es Spuren, aber keine Originale gibt. Hören wir die Aufnahme eines Keith-Jarrett-Konzerts von 1975, hören wir ein abgeleitetes Artefakt, nicht das Konzert, das einmal stattfand und zu Ende ging. Das Gleiche gilt für eine SaaS-Anwendung heute.

Was der Nutzer gestern um 11 Uhr erlebt hat, ist ein Ereignis, ko-produziert von der Anwendung, dem Browser, der Netzwerklatenz, der aktuellen Version des zugrundeliegenden LLM, der Konfiguration zwölf externer APIs, einem Rate Limit, das in jenem genauen Moment einen bestimmten Wert hatte. Dieses Ereignis ist nicht reproduzierbar, nicht bewahrbar, ontologisch kein Objekt. Es ist, eben, ein Konzert.

Der Einwand und die Kopie, die nicht mehr ist

An dieser Stelle könnte jemand einwenden, die Unterscheidung sei übertrieben — auch 1998 lief Software auf einem OS, das von Treibern und Hardware abhing, Laufzeit-Kontingenz gab es auch damals, jeder Gebrauch einer Anwendung war immer in gewissem Maß Ereignis und nicht Objekt.

Der Einwand ist teilweise korrekt, und ihn ernst zu nehmen ist wichtig, um die Diagnose nicht in Nostalgie zu verwandeln. Der Unterschied, der alles ändert, ist aber ein einziger — und genau der, den das Recht noch nicht metabolisiert hat.

1998 existierte stets eine Kopie des Artefakts. Im engsten, konkretesten Sinn — im Tresor des Anbieters oder auf der Festplatte des Nutzers oder im Archiv eines digitalen Archivars — existierte ein materielles Objekt, das die Software in autarker Form enthielt. Diese Kopie war der Berührungspunkt zwischen rechtlichem Produkt und exekutivem Ereignis. Der archimedische Punkt, der ein Zurückgehen, Prüfen, Vergleichen, Urteilen ermöglichte. Was es der Juristin erlaubte zu sagen „dieses Produkt war fehlerhaft“ — weil es ein Produkt gab.

Heute existiert diese Kopie nicht mehr, nicht aus Nachlässigkeit oder schlechter Wahl, sondern konstruktiv. Die SaaS-Anwendung von Anbieter X am Dienstag um 14:23 Uhr vor drei Monaten existiert in keinem Backup, keinem Tresor, keinem Archiv. Es existiert nur die Möglichkeit, näherungsweise und teilweise zu rekonstruieren, was sie hätte sein müssen — durch das Kreuzen von Logs, Code-Versionen, Abhängigkeitskonfigurationen, Modellgewichten, Datenbankzustand.

Eine archäologische Rekonstruktion, kein Zugriff aufs Objekt. Selbst wenn sie gelänge, wäre das Resultat etwas anderes — ein Modell der Anwendung jenes Moments, nicht die Anwendung jenes Moments. Das Produkt, im zweihundertjährigen Rechtssinn, ist verschwunden. Was an seiner Stelle ist, wurde nie benannt.

Das EU-Korpus und seine Schieflage

Dem EU-Gesetzgeber muss man zugutehalten: er hat gemerkt, dass etwas nicht passt. In den letzten Jahren hat er ein eindrucksvolles Normenpaket produziert, das den neuen Gegenstand mit verfügbaren Mitteln zu fassen versucht.

Der Cyber Resilience Act, in Kraft seit Dezember 2024, voll anwendbar ab Dezember 2027, führt Security by Design und Security by Default für Produkte mit digitalen Elementen ein, schreibt Lebenszyklus-Support, fordert ein Software Bill of Materials. Die neue PLD, oben erwähnt, dehnt die Haftung explizit auf Cybersicherheitsmängel und fehlerhafte Updates aus. Der AI Act, in Kraft seit 1. August 2024, allgemein anwendbar ab 2. August 2026 (einige Bestimmungen 2. August 2027), klassifiziert KI-Systeme nach Risiko und verlangt Dokumentations-, Transparenz-, Konformitätsbewertungspflichten. Dazu kommen NIS2, DORA, Data Act, EAA.

Zusammen bilden sie das ehrgeizigste Normenkorpus, das je zur Disziplinierung der Softwareherstellung geschaffen wurde — ein ernsthaftes, technisch informiertes, kulturell wichtiges Vorhaben. Es zu banalisieren als Bürokratie oder Innovationsbremse, wie es eine bestimmte libertäre Vulgata kalifornischer Prägung tut, wäre falsch. Die These dieses Aufsatzes ist vielmehr: bei aller Ernsthaftigkeit und Wichtigkeit versuchen diese Instrumente, das Konzert mit den Kategorien der Schallplatte einzufangen — und dieses kategoriale Auseinanderfallen wird in den nächsten Jahren Folgen produzieren, die wir erst zu erahnen beginnen.

Der Fall Software Bill of Materials ist paradigmatisch. Das SBOM listet alle in eine Software einfließenden Komponenten, ihre Versionen, Abhängigkeiten, Lizenzen — softwareäquivalente Zutatenliste auf der Verpackung. Auf dem Papier sinnvoll.

In der Praxis ist das SBOM die Fotografie eines Konzerts, mit allen epistemischen Grenzen dieser Bedingung. Die Foto ist nicht das Konzert; sie ist bereits ein anderes Objekt, abgeleitet, partiell, datiert. Im Augenblick der Aufnahme ändert sich das Konzert schon, im Sekundenbruchteil danach könnten transitive Abhängigkeiten aktualisiert sein, die externe API ihren Vertrag gewechselt haben, das Modellgewicht ersetzt sein.

Das SBOM erfasst einen Zustand, doch heutige Software hat keine stabilen Zustände, nur Flüsse. Die Norm verlangt also, die Foto aktuell zu halten — was Prozesse der Continuous SBOM Generation erzeugt, mit Tools, die das SBOM bei jedem Build, bei jedem Deploy, idealerweise in Echtzeit erstellen. Paradoxes Resultat: das Dokument, das die Produktidentität erfassen sollte, vervielfältigt sich in tausende täglicher Schnappschüsse, von denen jeder bereits beim Erzeugen veraltet ist. Das SBOM erfasst nicht das Produkt, weil es kein Produkt gibt. Es erfasst den Fluss, in diskreten Frames, und jeder Frame ist juristisch relevant. Die dokumentarische Last ist enorm, ihr Beweiswert für die Frage, wer in einem präzisen Moment für was verantwortlich war, ist deutlich weniger eindeutig, als die Gesetzgeber annehmen.

Dasselbe Problem, durch die stochastische Natur der Modelle verschärft, stellt sich für den AI Act. Artikel 10 verlangt, dass Trainings-Datasets dokumentiert, nachvollziehbar, qualitätsgesteuert sind. Artikel 15 verlangt, dass Hochrisiko-Systeme genau, robust, cybersicher sind. Artikel 72 verlangt Post-Market-Monitoring. Jede Pflicht ist isoliert sinnvoll und verweist auf Praktiken, die beste ML-Engineering ohnehin annehmen sollte.

Was die Gesetzgeber nicht voll absorbiert haben: das Sprachmodell, das ein Anbieter heute via API anbietet, ist ein Objekt, dessen Identität in der Zeit bestenfalls konventionell ist. Gewichte werden aktualisiert, RLHF verfeinert, Guardrails geändert — was weiter GPT-4 oder Claude Opus oder Gemini Ultra heißt, ist aus Sicht des beobachtbaren Verhaltens ein anderes Objekt als das, was vor sechs Monaten denselben Namen trug.

Die Trainingsdokumentation zu verlangen, heißt, die Dokumentation von etwas zu verlangen, das im Moment der Dokumentation bereits durch ein anderes Training überholt sein kann. Post-Market-Monitoring ist eine ausgezeichnete Praxis, setzt aber einen Markt voraus, in dem das Produkt zum Verkaufs- und zum Nutzungszeitpunkt dasselbe ist — bei Sprachmodellen fast nie wahr.

Es geht nicht darum, den AI Act für falsch zu erklären — er ist eine der artikuliertesten regulatorischen Antworten, die in vergleichbarem Maßstab je versucht wurden. Aber er erbt vom Produkthaftungsrecht eine Reihe ontologischer Voraussetzungen, die das zu regulierende Objekt nicht erfüllt; die Spannung wird sich in den nächsten Jahren auf die Schultern der Praktiker entladen — als Pflichten mit ambigem Wert, Dokumente unklaren Realitätsbezugs, Streitigkeiten, in denen der Streitstoff sich auf die Frage reduziert, ob ein Snapshot zu jenem Zeitpunkt repräsentativ war.

CrowdStrike, 19. Juli 2024

Ein jüngstes Beispiel, in seiner Tragweite weltweit Lehrstoff, hilft, das konkret zu sehen.

Am 19. Juli 2024 verursachte ein fehlerhaftes Update des Falcon-Sensors von CrowdStrike den gleichzeitigen Absturz von rund 8,5 Millionen Windows-Rechnern weltweit, mit Boot-Loop, der manuelles Eingreifen pro Gerät verlangte. Stillgelegte Flughäfen, in den Papiermodus zurückgekehrte Krankenhäuser, nicht operative Banken, gesperrte Sender, nicht durchgestellte Notrufe. Delta Airlines allein meldete über 500 Millionen Dollar Direktschaden, allein die Fortune 500 nicht versicherte Verluste in Höhe von rund 5,5 Milliarden, globale Schätzungen je nach Quelle in zweistelliger Milliardenhöhe.

Der nachfolgende Streit, in mehreren Jurisdiktionen weiter offen, konzentriert sich auf die Frage: wer war verantwortlich.

• CrowdStrike, das ein Update mit einem Defekt verteilte, der durch jede ernsthafte Prüfung erkennbar gewesen wäre.
• Microsoft, das einer Drittsoftware Kernel-Privilegien zugestand, die das Betriebssystem in den Boot Loop zwingen konnten.
• Die deployenden Organisationen, die Updates per Auto-Push akzeptierten, ohne Canary-Phasen.
• Die EU-Regulierer, laut Microsofts Verteidigung, die Jahre zuvor aus Wettbewerbsgründen die Kernel-Öffnung erzwungen hätten.

Jede Zuschreibung erfasst einen realen Aspekt. Keine, einzeln, erzählt das Geschehene. Das Geschehene war ein Orchestrierungsversagen — ein Ereignis, in dem viele Akteure, jeder in seinem Maß, effektiven Einfluss auf das Laufzeitverhalten hatten, und keiner diesen Einfluss proportional zu den möglichen Folgen ausübte.

Das geltende Recht hat keine Mittel, Verantwortung so zu verteilen; das Verfahren rutscht in Szenarien, in denen gewinnt, wer die besseren Anwälte oder die sicherste Vertragsposition hat — anders gesagt: das Recht hat verzichtet, Substanzielles zum Vorfall zu sagen. Ein CrowdStrike-Fall, im Licht der Kategorie verantwortliche Komposition, hätte ein Urteil produzieren sollen, das Verantwortung in identifizierbaren Quoten zwischen den Akteuren entlang Blast Radius und tatsächlicher Kontrolle verteilt — und einen Präzedenzfall für künftige Vorfälle schafft, die sicher zahlreich sein werden. Nichts dergleichen geschieht — die Kategorie dafür existiert nicht.

Latour, Ricœur und die Pluralität des Handelns

Die verantwortliche Komposition ist keine ex nihilo-Erfindung, sondern die Anpassung philosophischer Reflexionen des 20. Jh. an das juristische Feld.

Bruno Latour zeigte mit der Actor-Network Theory in den 80ern: komplexe Handlungen haben nie einen einzigen Agenten, sondern emergieren aus Netzen menschlicher und nicht-menschlicher Akteure, deren Analyse es verlangt, die Sujet-Obsession zu suspendieren und die tatsächlichen Verbindungen zu verfolgen. Sein kanonisches Beispiel des „schlafenden Polizisten“ (Bodenwelle) ist erhellend: die Bodenwelle erzwingt das Tempolimit unabhängig vom Polizisten, sie ist ein nicht-menschlicher Akteur mit eigener Agency.

Das Abbremsen des Autos wird ko-produziert vom Fahrer, der Bodenwelle, der StVO, der Angst vor Federungsschaden, der gemeinsamen Kultur, die die Welle als Vorsichtszeichen erkennt. Keiner der Akteure allein erklärt das Bremsen. Das positive Recht schneidet die Verantwortung aus pragmatischen Gründen auf den Fahrer zu, doch das philosophische Verständnis verlangt, alle fünf zusammen zu sehen. Den Schritt, den das Recht noch nicht getan hat — die Philosophie seit vierzig Jahren —, wäre, diese Verteilung des Handelns als Norm zu akzeptieren und Konsequenzen für die Zurechnung zu ziehen.

Paul Ricœur in Soi-même comme un autre (1990) und seinen Reflexionen zur Imputabilität fügte hinzu: Zurechnen ist ein narrativer Akt, der eine plausible Kausalitätsgeschichte verlangt; ist sie pluralistisch, kann die imputierende Erzählung nicht auf ein einziges Subjekt reduziert werden, ohne die Wahrheit des Ereignisses zu verraten. Imputation ist Hermeneutik der Verantwortung — sie verlangt Geduld, mehrere Ebenen, kein Vereinfachen.

Heutiges Produkthaftungsrecht vereinfacht zu sehr, weil es eine narrative Grammatik des 19. Jh. erbt, in der der Hersteller einer, identifizierbar, imputierbar war. Imputabilität für heutige Software zu rekonstruieren, heißt, die plurale Natur des Handelns zu akzeptieren und sie auch im Urteilstext wiederzugeben.

Die verantwortliche Komposition

Hört man hier auf, droht die Diagnose pessimistisch zu wirken. Mein Anliegen ist das Gegenteil: wenn der Produktbegriff seine Funktion der Verantwortungszurechnung nicht mehr trägt, muss man die Ersatzkategorie zu denken beginnen.

Das ist eine Aufgabe, die weder reinen Juristen — ohne Runtime-Erfahrung — noch reinen Ingenieuren — die Recht eher als externe Belästigung behandeln — übergeben werden kann. Die Kategorie muss vierhändig gedacht werden — von jenen mit Code-Praxis und Rechtslektüre — und ausgehen vom Faktum: heutige Software ist Orchestrierung, Komposition, verteiltes Ereignis, kein Objekt.

Vorschlag, vorläufig: verantwortliche Komposition.

Was ist eine verantwortliche Komposition näherungsweise? Eine Konfiguration menschlicher und nicht-menschlicher Komponenten, organisiert um eine spezifische, einer Nutzerin angebotene Funktion. Kein Beteiligter hat integrale Kontrolle, jeder übt einen identifizierbaren Grad effektiven Einflusses auf das beobachtbare Laufzeitverhalten aus.

Verantwortung folgt nicht der formalen Inhaberschaft („wer Vertragsinhaber ist, haftet für alles“) und nicht dem historischen Ursprung der Komponenten („Bug in einer importierten Bibliothek? Schuld der Bibliotheks-Maintainerin“). Verantwortung folgt dem Gradienten effektiven Einflusses.

Wer im Schadenszeitpunkt durch eine gezielte technische Handlung das Systemverhalten ändern konnte, haftet proportional zum Grad dieser Möglichkeit. Der Anbieter des KI-Modells, der die Guardrails hätte aktualisieren können und es nicht tat, haftet anteilig. Der Integrator, der das Modell für eine sensible Funktion ohne adäquate Risikobewertung wählte, haftet anteilig. Die Nutzerin, die das System unter Umgehung der Warnungen anomalisch konfigurierte, haftet anteilig. Niemand haftet für alles, niemand haftet für nichts — jeder für seinen Anteil an der Orchestrierung.

Einfach zu sagen, höllisch komplex zu implementieren — wie jede neue Rechtskategorie in ihren ersten Jahrzehnten.

Einwände kommen sofort. Erster: effektive Einflussnahme ist schwer messbar, ein darauf gestütztes System wäre Quelle von Unsicherheit. Wahr, aber weniger schwerwiegend, als es scheint: das Recht arbeitet längst mit fluiden Begriffen — Verschulden, Vorhersehbarkeit, adäquate Kausalität — und hat dafür operative Werkzeuge entwickelt.

Effektiver Einfluss in einem verteilten System ist messbar über das, was Ingenieure Blast Radius nennen — die Schätzung des Wirkungsumfangs einer technischen Handlung. Ein API-LLM-Anbieter hat einen Blast Radius, der potenziell alle Integratoren umfasst — eine Änderung propagiert sich sofort. Ein Integrator hat einen auf seine Nutzer begrenzten Blast Radius, der jedoch verstärkt sein kann, wenn seine Anwendung selbst Infrastruktur weiterer Anwendungen ist.

Es gibt grobe, aber handhabbare technische Metriken zur Schätzung des Blast Radius jedes Akteurs, und die Doktrin könnte darauf eine abgestufte Verantwortungstaxonomie bauen. Nicht fluider als die Fahrlässigkeitslehren des 19. Jh., bevor jahrzehntelange Rechtsprechung sie operabel machte.

Zwei Verformungen, denen zu widerstehen ist

Der zweite Einwand ist politischer und kommt aus zwei entgegengesetzten Richtungen, beide interessiert.

Die erste: kalifornische Big-Tech-Kreise haben in den letzten zwanzig Jahren ein Narrativ gebaut, wonach die Open-Source- und Komponenten-Natur der Software es unmöglich mache, jemandem konkret Verantwortung zuzuschreiben — Verantwortung müsse sich daher auf die ausdrücklich akzeptierten Vertragsbedingungen beschränken. Liest demnach: erleidet eine Nutzerin Schaden durch eine Anwendung, die eine Open-Source-Bibliothek anonymen Autors nutzt, die ihrerseits in einer Cloud läuft, deren Anbieter in den AGB jede Verantwortung ablehnt — dann haftet niemand für nichts, oder genauer: nur jener, der vertraglich Verantwortung übernommen hat.

Das ist die Doktrin der verteilten Unverantwortlichkeit — bequeme Positionsrendite für jene, die die zentralen Knoten der Orchestrierung besetzen: man kassiert den Wert, lagert die Risiken aus. Die verantwortliche Komposition stellt sich frontal gegen sie und weist die Idee zurück, dass das Fehlen formaler Inhaberschaft dem Fehlen substantieller Verantwortung gleichkomme. Ist dein Modell die kritische Komponente Tausender nachgelagerter Anwendungen, hängt deine Verantwortung nicht davon ab, ob du mit deren Endnutzern Verträge geschlossen hast. Sie hängt von deiner Rolle in der Orchestrierung ab — und diese ist objektiv messbar.

Die andere Richtung: kontinentaleuropäischer Formalismus, mit der Doktrin des absoluten Inhabers.

In dieser Tradition haftet der für die Datenverarbeitung Verantwortliche oder der Service-Provider oder der KI-Deployer für alles in der Kette, unabhängig vom Entstehungsort der Nicht-Konformität. Intuitiv gleichmacherisch, weil sie der Nutzerin garantiert, dass jemand stets antwortet. In der Praxis aber zwei ernsthafte Verzerrungen.

Erstens: sie lädt dem Inhaber Verantwortung auf, deren technische Kontrolle er nicht hat — er muss sich gegen Verfahren wegen Defekten verteidigen, die von Komponenten stammen, die er nicht geschrieben, nicht gewählt, nicht inspizieren kann. Zweitens: sie ent-verantwortet die vorgelagerten Knoten — gerade jene mit dem systemischsten Einfluss —, weil sie wissen, dass ihr Anteil formell auf den Endinhaber abgewälzt und die Gerichte weiter mit dem Finger auf den Sichtbarsten zeigen werden.

Auch dagegen wendet sich die verantwortliche Komposition. Die formale Position des Inhabers erschöpft die Frage nicht, und eine nur scheinbar verteilte Last, die sich faktisch immer beim zugänglichsten Knoten konzentriert, lässt die Machtverhältnisse der Branche unverändert.

Der Vorschlag steht damit in einem für beide gängigen Sensibilitäten unbequemen Terrain — und gerade darum verdient er, ausartikuliert zu werden. Wer in der Software arbeitet, weiß, dass die Idee einer rein vertraglichen Verantwortung eine nützliche Fiktion für Silicon Valley ist und eine tägliche Erfahrung der Ohnmacht für jene in Pescara, Mailand oder Frankfurt, die ein System in echten Zwängen wirklich liefern müssen. Zugleich weiß, wer mit europäischer Compliance arbeitet, dass die Doktrin des absoluten Inhabers den Deployer in eine juristische Schmelzsicherung verwandelt — wirtschaftliche Funktion: durchbrennen, wenn das System bricht, sodass die vorgelagerten Komponenten weiter Externalitäten produzieren.

Heutige Software braucht eine Kategorie, die keine der beiden ist und die Verantwortung so verteilt, dass sie die tatsächliche Verteilung technischer Macht abbildet. Keine symmetrische Verteilung — technische Macht ist nicht symmetrisch. Keine Konzentration auf den Inhaber — sie ist nicht beim Inhaber. Eine Verteilung entlang des Gradienten effektiver Einflussnahme, mit transparenten Metriken, einer praktikablen Doktrin, einer ratio, die Praktiker als ihrer Arbeitserfahrung adäquat erkennen.

In manchen Bereichen passiert ansatzweise so etwas, ohne so genannt zu werden. Die DSGVO mit Art. 28 und EDPB-Leitlinien zur Sub-Auftragsverarbeitungs-Kette beginnt zaghaft, eine Abstufung der Verantwortung entlang der Verarbeitungskette anzuerkennen — formell, ohne den nötigen begrifflichen Apparat. Datenschutzfolgenabschätzungen, ernsthaft erstellt, enthalten in nuce eine Blast-Radius-Analyse für personenbezogene Daten.

NIS2 führt für Managed-Service-Anbieter Pflichten ein, die deren systemische Rolle in der Sicherheitskette anerkennen. Der AI Act mit seinen Provider/Deployer/Importer/Distributor-Unterscheidungen versucht, eine Rollentaxonomie aufzubauen, die — noch zu starr — in Richtung einer nicht inhaberzentrierten Verantwortungsverteilung weist.

Keines dieser Instrumente hat das Prinzip der effektiven Einflussnahme als Verantwortungsgradient bisher explizit formuliert, doch alle enthalten Spuren eines Umdenkens, das nur auf doktrinale Systematisierung wartet. Eindruck: Es fehlt das, was für Lord Atkin der Neighbour Principle war — eine synthetische, einprägsame, operative Formulierung, die fünfzig Jahre folgender Rechtsprechung leiten kann. Wer sie schreibt, hat fürs 21. Jahrhundert getan, was das House of Lords fürs 20. tat.

Damit diese Formulierung geschrieben werden kann, braucht es eine intellektuelle Figur, die heute praktisch nicht existiert. Keine reinen Juristen — die innere Grammatik heutiger verteilter Systeme lernt man nicht in Jura. Keine reinen Ingenieure — die Grammatik des Rechts und seine zweihundertjährige Kategoriengeschichte lernt man nicht in Computer Science.

Es braucht Hybride, Grenzfiguren, die beide Berufe lange genug ausgeübt haben, um Logiken und Grenzen verstanden zu haben, und die bereit sind, etwas zu denken, das keiner der Korpora allein denken könnte. In Italien hat diese Figur noch keinen festen Namen. In angelsächsischen Ländern hat sich der Compliance Engineer oder Technical Counsel etabliert — Definitionen, die sich auf Vermittlung beschränken, ohne wirklich eine dritte Kultur zu bauen.

Es braucht etwas Ehrgeizigeres: eine Figur, die nicht nur Tech-Jargon in Rechtsjargon übersetzt und umgekehrt, sondern neue Kategorien erarbeitet, die keiner der Ausgangsdialekte allein zu sagen wüsste. Beruf teils theoretisch (philosophische Ausbildung für abstrakte Kategorien) und teils praktisch (Alltag von Deployment, transitiver Abhängigkeit, durch Minor-Release gebrochener Rückwärtskompatibilität, mehrdeutiger Stack Trace). Ohne Praxis bleiben abstrakte Kategorien in der Luft. Ohne abstrakte Bildung erschöpft sich Praxis in Müdigkeit und geschlossenen Tickets.

Der dritte Weg ist schwer — nicht, weil er seltene Begabungen verlangt, sondern weil der Arbeitsmarkt ihn nicht honoriert, Universitäten ihn nicht ausbilden, Firmen ihn nicht organisieren. Er existiert nur durch individuellen Willen — und gerade deshalb tragen die, die ihn praktizieren, eine intellektuelle Verantwortung, die ihrer formalen Stellung weit voraus ist.

Vom Bill of Materials zum Bill of Accountability

Zurück zum konkreten Ausgangsproblem: wie ordnet man Verantwortung für einen durch heutige Software verursachten Schaden zu?

Akzeptiert man, dass Software kein Produkt mehr ist, sondern Komposition, und dass die Komposition entlang des Gradienten effektiver Einflussnahme zu analysieren ist, so ist der erste operative Schritt eine Dokumentationspraxis der Komposition — keine SBOM-Standfotografie, sondern eine dynamische Karte der Einflussbeziehungen.

Ein solches Werkzeug sollte je Anwendung Antworten geben auf:

• Welche Komponenten würden, modifiziert, das beobachtbare Systemverhalten ändern.
• Welche Akteure haben die technische Möglichkeit, sie zu modifizieren.
• Welche vertraglichen und normativen Pflichten lasten auf jedem.
• Welche Beweise (Logs, Audit) erlauben ex post die Rekonstruktion eines präzisen Zustands.
• Welche Kommunikationskanäle erlauben einem nachgelagerten Akteur, ein Alarmsignal nach oben zu schicken.
• Welche typischen Reaktionszeiten entlang der Kette gelten.

Das Resultatdokument wäre kein Bill of Materials mehr, sondern etwas wie ein Bill of Accountability — eine Karte der Befugnisse und Pflichten entlang der Orchestrierung. Es zu erzeugen verlangte Arbeit, Kooperation zwischen Akteuren mit nicht immer ausgerichteten Interessen, Normen, die seine Erstellung verlangen. Aber es würde das Problem beim Namen nennen, statt es auf eine Inventarfrage zu reduzieren.

Drei Folgen für jene, die Software entwickeln

Aus Sicht der Praxis hätten diese Re-Artikulationen wichtige Folgen.

Erste Folge: der Standardvertrag, der heute alle Verantwortung auf den Endlieferanten oder besten Falls auf das Jahresentgelt begrenzt, würde ein Dokument völlig anderer Struktur. Er würde aus einer Komposition-Analyse heraus gebaut — mit klarer Artikulation, welche Komponenten der Anbieter kontrolliert vs. nur integriert, welche Risiken er voll übernimmt vs. weiterleitet, welche Informationspflichten er übernimmt vs. technisch nicht erfüllen kann. Längerer, komplexerer, ehrlicherer Vertrag — und langfristig auch besser verteidigbar, weil er die Sache erzählt, wie sie ist.

Zweite Folge: der Entwicklungsprozess sollte schon in frühen Phasen die Reflexion über die Orchestrierung enthalten, in die das System eintreten wird — nicht nur funktionale Anforderungen.

• Wer sind die vorgelagerten Akteure, von denen wir abhängen.
• Welche Garantien geben sie.
• Welchen Blast Radius haben sie uns gegenüber.
• Wie verifizieren wir ihre Änderungen.
• Wie reagieren wir, wenn eine ihrer Änderungen unser erwartetes Verhalten bricht.

Heute auf Architektur-Slides verbannte und dann vergessene Fragen sollten Teil der Spezifikation werden. Ihre Abwesenheit in Projektdokumentation würde so unprofessionell wirken wie heute das Fehlen eines Threat Models.

Dritte Folge — kulturell vielleicht die interessanteste, betrifft die Ausbildung. Heute lernt man, Code zu schreiben, der funktioniert, dann — mit Glück — Code, der in Produktion funktioniert. Fast niemand lernt Code zu schreiben, der innerhalb einer bewussten Orchestrierung funktioniert.

Das Bewusstsein der Orchestrierung kommt spät, oft durch einen Vorfall, selten als gelehrte Kompetenz. Eine Ausbildung, die die verteilte Natur heutiger Software ernst nimmt, müsste hier anfangen — vom ersten Tag zeigen: eine API zu schreiben heißt, in eine Orchestrierung einzutreten; eine Bibliothek zu wählen heißt, einen vorgelagerten Anbieter zu akzeptieren; in die Cloud zu deployen heißt, sich in einer Infrastruktur einzunisten, deren Architekturentscheidungen anderswo getroffen werden.

Nicht um Junior-Entwickler zu erschrecken, sondern um sie zu gewöhnen, das zu sehen, was erfahrene Entwickler nach zwanzig Jahren Narben sehen. Orchestrierung ist Gegenstand ihrer Arbeit, nicht Hintergrund. Der Code ist Teilnahme an einem Konzert, nicht ein autarkes Objekt. Wachsen sie damit auf, kommt die Verantwortungsfrage nicht als externe Belästigung, sondern als intrinsische Berufsdimension.

Wenn auch das Schreiben Orchestrierung ist

Wer vermutet, das alles werde durch die SaaS-Linse überdramatisiert und in einfacheren Kontexten halte die Produktkategorie noch — dem sei entgegnet: die Richtung des AI-nativen Entwickelns macht das Problem schärfer, nicht milder.

Beim Arbeiten mit Werkzeugen wie Claude Code oder Praktiken wie specification-driven development à la SpecKit hört Code auf, das Objekt zu sein, das die Entwicklerin direkt schreibt — er wird Output einer Generierungskette: Spec → Modell → Artefakt → Integration in eine bereits verteilte Orchestrierung. Die gestern geschriebene Spec und der gestern generierte Code würden, heute vom selben Modell regeneriert, plausibel ähnlich, aber nicht identisch herauskommen, weil das Modell sich geändert hat.

Der bereits durch Continuous Deployment geschwächte Versionsbegriff wird so noch instabiler — nicht nur zur Ausführungszeit, sondern auch zur Schreibzeit. Wer so entwickelt, weiß: exakte Reproduzierbarkeit ist regulatives Ideal, keine reale Eigenschaft.

In einer Welt, in der auch das Schreiben Orchestrierung ist — zwischen Entwicklerin, Spec, Modell, Toolchain, Pipeline —, wird die verantwortliche Komposition zur natürlichen Kategorie zum Denken der Verantwortung — die einzige, in der das Fehlen monolithischer Autorschaft nicht automatisch in fehlende Imputabilität übersetzt wird.

Der Tod einer Kategorie

Es bleibt eine Frage, die der Aufsatz beantworten muss: macht es Sinn, vom Tod einer Rechtskategorie zu sprechen, oder beschreiben wir nur eine Evolution, einen Wandel, ein Update?

Die Sprache des Todes ist stark. Rechtfertigung: eine Kategorie stirbt im foucaultschen Sinn — wenn sie aufhört, das diskursive Feld produktiv zu organisieren, und beginnt, es zu behindern.

Der Produktbegriff, auf heutige Software angewandt, organisiert das Feld nicht mehr, er behindert es. Er erzeugt Pflichten, denen keine Praxis entspricht; Dokumente, die keine Objekte abbilden; Streitigkeiten, die sich an der Definition des Objekts festlaufen, bevor sie zur Sache kommen.

Ein Begriff, der das Feld behindert, ist nicht nützlich, auch wenn er formell in Kraft bleibt. Der Lichtäther-Begriff in der Physik des späten 19. Jh. war nicht falsch im Sinne einzelner Aussagen — er war ein Begriff, der das Feld nicht mehr produktiv organisierte und es zu behindern begann, bis Einstein ihn schlicht entfernte.

Der Produktbegriff im heutigen Software-Recht steht in vergleichbarer Phase. Noch da, in den Texten, in den Sälen. Aber nicht mehr arbeitend. Und so zu tun, als arbeite er, ist gefährlicher als zuzugeben, dass er es nicht tut.

Ich behaupte nicht, der EU-Gesetzgeber hätte auf die richtige Kategorie warten müssen. Wäre intellektuell rein, politisch unmöglich gewesen — und der Schaden fehlender Regulierung hätte den einer kategorial unvollkommenen übertroffen.

Ich sage bescheidener: die jetzige Regulierung ist work in progress; ihre kategoriale Unvollkommenheit gehört offen anerkannt; und die Konstruktion der Ersatzkategorie ist keine Sache nur für Gesetzgeber, sondern auch für die Praktiker und für die Rechtsphilosophen. Wer beide Beine drinnen hat, kann mehr beitragen als wer nur eines hat. Und der Beitrag ist kein akademisches Vergnügen: jedes Jahr ohne Ersatzkategorie ist ein Jahr, in dem Streitfälle über formale Wege gelöst werden, die nicht die substantielle Verantwortung abbilden; in dem vorgelagerte Anbieter weiter Risiko transferieren, ohne den Preis zu zahlen; in dem Endabnehmer als Sicherungen dienen, ohne dass das System als Ganzes besser wird.

Lord Atkins Saal

Ich habe mich verbreitet, und wer mir bis hierher gefolgt ist, verdient eine ehrliche Synthese.

Wir sind dahin gelangt zu sagen, dass der juristische Produktbegriff, im 20. Jh. auf einer Ontologie begrenzter, bewahrbarer, identifizierbarer Objekte gebaut, für heutige Software unzureichend ist — die eine Orchestrierung menschlicher und nicht-menschlicher Komponenten ist, ein verteiltes Ereignis mehr als ein Objekt, ein Konzert mehr als eine Schallplatte.

Wir sind dahin gelangt zu sagen, dass die EU-Regulierung — der ernsteste je versuchte Anlauf — versucht, das Konzert mit den Schallplatten-Kategorien zu fassen, und dass diese Spannung Pflichten erzeugt, deren substantieller Rechtswert mehrdeutig ist.

Wir sind dahin gelangt, an Stelle der Produktkategorie eine neue zu fordern, vorläufig nennbar verantwortliche Komposition, die Verantwortung nach dem Gradienten effektiver Einflussnahme zur Laufzeit verteilt — nicht nach formaler Inhaberschaft und nicht nach verteilter Unverantwortlichkeit.

Wir sind dahin gelangt zu sagen, dass diese Konstruktion eine hybride Intellektuellen-Figur verlangt — Code-Praxis und Rechtslektüre —, die der Markt nicht honoriert und die nur durch individuellen Willen existiert.

Und dass, solange die Ersatzkategorie nicht emergiert, sich Streitfälle weiter über formale Wege entladen, die nicht die substantiellen Verantwortlichkeiten abbilden — mit realen Kosten für jene, die den Beruf ehrlich ausüben.

Was am Ende vielleicht festzuhalten ist: Lord Atkin war 1932 kein reiner Jurist, sondern ein Richter, der viele Flaschen brechen und viele Menschen erkranken sah und etwas Praktisches über die industrielle Welt verstand, das das frühere begriffliche Instrumentarium nicht zu sagen wusste.

Donoghue v. Stevenson war möglich, weil jemand in einem einzigen Kopf die materielle Erfahrung der Industriewelt und die begriffliche Tradition des Zivilrechts zusammengehalten hat. Heute braucht es, in einem einzigen Kopf, materielle Erfahrung verteilter Systeme und begriffliche Tradition des Haftungsrechts. Das lässt sich nicht delegieren, und es lässt sich auch nicht in einem Aufsatz erledigen. Was ein Aufsatz tun kann: das Problem benennen, eine Richtung anbieten, jene mit ähnlichen Werkzeugen zur Fortsetzung einladen.

Mrs Donoghues Flasche war undurchsichtig, und drinnen war eine Schnecke, die niemand gesehen hatte. Heutige Software ist noch undurchsichtiger, und drinnen sind viel mehr Schnecken — und die Rechtsprechung, die uns schützt, wurde für eine Welt geschrieben, in der die Flaschen aus Glas waren. Es ist Zeit, die Rechtsprechung einer Welt zu schreiben, in der Flaschen nicht mehr existieren.

Der Autor

Andrea MargiovanniEU-Compliance

Ich arbeite mit Teams, die Systeme unter AI Act, CRA, NIS2, DSGVO bauen. Die Regel ist keine Checkliste: sie ist eine architektonische Einschränkung, die schon beim Entwurf an Bord muss, nicht danach.

Zum Weg →