Ein Vertrag zwischen den falschen Personen
Der Vertrag war Ende 2023 unterzeichnet worden, und aus der Sicht des Hauptanbieters war es ein sauberer, gut strukturierter Vertrag, mit allen Schutzklauseln, die die Rechtsabteilung über die Jahre verlangt hatte. Er spezifizierte klar den Gegenstand der Lieferung, legte die Service-Level fest, fixierte die Vertragsstrafen für Nichteinhaltung, definierte den Perimeter der Anbieterhaftung mit Standardobergrenzen am jährlichen Vertragswert, schloss indirekte Schäden aus, regelte die Subunternehmen über eine Klausel, die vom Kunden die Genehmigung der Hauptsubunternehmen verlangte und die die Verantwortung für deren Eignungsprüfung auf den Kunden verlagerte. Er war vier Monate verhandelt worden, war durch drei Runden juristischer Prüfung auf beiden Seiten gegangen, war von Führungskräften mit den notwendigen Vollmachten unterzeichnet worden. Der Hauptanbieter, ein Software-Haus mit fünfzig Personen, betrachtete ihn als guten Vertrag. Der Kunde, eine private Gesundheitsdienstleistungsgesellschaft mit einer Million Versicherten, betrachtete ihn als ausgewogenen Vertrag. Zwei Jahre lang lief das Verhältnis gut.
Ende 2025 erlitt ein Versicherter einen Schaden durch das, was das klinische System hätte tun sollen und nicht tat. Die technische Ursache wurde einer Risikobewertungs-Bibliothek zugeschrieben, die das System zur Klassifizierung der Interventionsprioritäten verwendete. Die Bibliothek war von einem vom Kunden vier Jahre zuvor genehmigten Subunternehmer geliefert worden, war achtzig Tage vor dem Vorfall vom Subunternehmer selbst still aktualisiert worden, mit einer Algorithmusänderung, die niemand dem Hauptanbieter mitgeteilt hatte, und niemand hatte eine Aktualisierung der Dokumentation verlangt, weil der Subunternehmer seine Aktualisierung als gewöhnliche Wartung betrachtete. Der Subunternehmer hatte seinen Sitz in einem Drittland, hatte keinen Rechtsvertreter in der Union, und in den Monaten nach der Klage erwies er sich faktisch als unerreichbar für gerichtliche Zustellungen.
Der Hauptanbieter reagierte auf die Schadensersatzforderung des Anwalts des Versicherten, indem er den Vertrag vorzeigte. Er behauptete, dass der Subunternehmer vom Kunden genehmigt worden war, dass die Änderung einseitig vom Subunternehmer ohne jede Mitteilung eingeführt worden war, dass der Vertrag indirekte Schäden ausschloss und die Haftung am jährlichen Wert deckelte, und dass jedenfalls die materielle Verantwortung beim Kunden lag, als demjenigen, der die Beziehung zum Versicherten direkt verwaltete. Der Anwalt des Versicherten focht keinen dieser vertraglichen Punkte an. Er bemerkte schlicht, dass der Vertrag zwischen Anbieter und Kunden ihn nicht betraf, weil er ihn nicht unterzeichnet hatte, und dass seine Klage auf dem neuen europäischen Produkthaftungsregime beruhte, unter dem der Hauptanbieter als Hersteller des fehlerhaften Produkts qualifizierbar war und gegenüber dem geschädigten Endverbraucher unabhängig von den mit seinem Kunden vereinbarten Vertragsklauseln nach dem Prinzip der verschuldensunabhängigen Haftung haftete. Diese Klauseln, fügte er hinzu, regelten den Regress zwischen den Vertragsparteien, nicht die Exposition gegenüber Dritten. Der Vertrag, mit anderen Worten, war ein guter Vertrag zwischen den falschen Personen.
Der traditionelle Einwand
Der Einwand, den ich sofort behandeln möchte, weil er der am tiefsten verwurzelte und der aufrichtigste ist, ist der, der von den traditionellen Juristen kommt, mit denen ich in diesen Jahren gearbeitet habe. Er klingt so: All das ist ein Problem der Vertragsgestaltung. Wenn die Klauseln gut geschrieben sind, wenn die Freistellungen vollständig sind, wenn die Subunternehmer-Verfahren rigoros sind, ist der Hauptanbieter geschützt. Es ist ein Einwand, der formal kohärent ist mit der Art, wie das Vertragsrecht in der Software vierzig Jahre lang funktioniert hat. Bis vor wenigen Jahren war er auch substanziell wahr, weil das Haftungsregime des Software-Herstellers schwach war, die Klagen der geschädigten Dritten fast immer durch den direkten Kunden gingen, und der Hauptanbieter vernünftigerweise erwarten konnte, dass seine Exposition sich in den vereinbarten Vertragsgrenzen erschöpfte.
Diese Epoche ist vorbei. Das juristische Regime, das sich in Europa zwischen 2024 und 2027 konsolidiert und über das ich in dieser Reihe bereits in Bezug auf das als geschriebenes Versprechen bewertete Software-Produkt und auf die Spezifikation als juristisch relevanten Aktivposten geschrieben habe, führt eine Haftungsebene ein, die außerhalb des Vertrags wirkt und die der Vertrag nur teilweise regeln kann. Die Überarbeitung der Product Liability Directive, anwendbar ab dem 9. Dezember 2026, qualifiziert Software ausdrücklich als Produkt und wendet auf den Software-Hersteller ein Regime der verschuldensunabhängigen Haftung gegenüber den geschädigten Endverbrauchern an. Der Cyber Resilience Act, voll anwendbar ab dem 11. Dezember 2027, führt Sicherheitspflichten für das digitale Produkt ein, die auf dem Hersteller über den gesamten Lebenszyklus lasten und sich auf integrierte Komponenten erstrecken. Der AI Act verteilt Pflichten entlang der Kette der Anbieter von KI-Systemen so, dass der Anbieter des finalen Systems gewährleisten muss, dass die integrierten Komponenten konform sind. Der Digital Operational Resilience Act, anwendbar ab dem 17. Januar 2025, erlegt Finanzunternehmen und ihren kritischen ICT-Anbietern Pflichten zum Risikomanagement der Lieferkette auf, die vertragliche Grenzen überschreiten. NIS2, anwendbar ab dem 18. Oktober 2024, macht denselben Schritt für die erweiterten kritischen Sektoren. Jeder dieser Akte wäre einzeln genommen mit einigen vertraglichen Anpassungen handhabbar. Zusammen genommen und in ihren Schnittmengen definieren sie eine Haftungsstruktur, die der Liefervertrag nicht mehr enthalten kann.
Die vier gefallenen Voraussetzungen
Das traditionelle Vertragsmodell der Software ist in einer Epoche aufgewachsen, in der einige implizite Voraussetzungen galten, und es ist unzureichend geworden, weil all diese Voraussetzungen im selben Jahrzehnt gefallen sind. Da war zunächst die Idee, dass die Haftung des Anbieters gegenüber dem Kunden die Exposition des Anbieters erschöpfte, weil der zwischengeschaltete Kunde jede Haftung gegenüber geschädigten Dritten absorbierte und verwaltete. Da war dann die Überzeugung, dass Software ein im Lieferzeitpunkt begrenztes Objekt sei, das auf der Grundlage eines statischen Lastenhefts zum Zeitpunkt des Releases bewertbar sei. Drittens wurde als selbstverständlich angenommen, dass die Lieferkette aus juristischer Sicht im Wesentlichen bilateral sei, das heißt, dass jedes Glied durch einen Vertrag zwischen zwei Parteien geregelt werden könne, ohne sich um die Gesamtdynamik der Kette kümmern zu müssen. Und schließlich wurde vorausgesetzt, dass das Haftungsregime über die Zeit stabil bleibe, ausreichend, um es vernünftig zu machen, mehrjährige Verträge auf der Grundlage des zum Zeitpunkt der Unterzeichnung geltenden Rechtsrahmens zu unterzeichnen. Es waren Voraussetzungen, die bis etwa 2020 wie Naturgesetze der Software-Vertragsgestaltung erschienen, und die sich rückblickend einfach als die Merkmale einer spezifischen juristischen Epoche erweisen.
Die erste Voraussetzung wurde durch die Erweiterung der Aktivlegitimation der geschädigten Dritten in der neuen PLD erodiert. Unter dem alten Produkthaftungsregime konnte der geschädigte Endverbraucher gegen den Hersteller klagen, aber in der Praxis gingen die Klagen meist über den Wiederverkäufer oder den kommerziellen Integrator, und der Software-Hersteller genoss bis 2024 eine interpretative Unsicherheit darüber, ob er überhaupt unter die Definition des Herstellers fiel. Die neue Richtlinie, die Software ausdrücklich in die Produktdefinition aufnimmt und Mangelvermutungen einführt, die die Beweislast des Geschädigten erleichtern, macht die Position des Software-Herstellers viel exponierter. Sie fügt zudem einen Mechanismus der dokumentarischen Offenlegung hinzu, der es dem Richter erlaubt, dem Anbieter aufzuerlegen, die technische Dokumentation des Produkts vorzulegen, und den Mangel im Falle der Nichtvorlage zu vermuten. Von diesem Moment an braucht der Anwalt des Geschädigten nicht mehr über den zwischengeschalteten Kunden zu gehen und kann direkt gegen den Hauptanbieter der Software klagen, die den Schaden verursacht hat, wobei er die Vertragsklauseln zwischen Anbieter und Kunden vollständig ignoriert, weil diese Klauseln eine Beziehung regeln, an der der Geschädigte ein Dritter ist. Die Sache ist ausdrücklich in Artikel 15 der Richtlinie geschrieben, mit dem Titel „Ausschluss oder Begrenzung der Haftung“, der den Mitgliedstaaten auferlegt zu gewährleisten, dass die Haftung des Wirtschaftsakteurs gegenüber dem Geschädigten weder durch Vertragsklauseln noch durch Vorschriften des nationalen Rechts begrenzt oder ausgeschlossen werden kann. Es ist ein kurzer und technischer Artikel, aber er ist der Schlussstein des gesamten Aufbaus, weil er das, was wie vertraglicher Spielraum aussah, in eine Zone juristischer Unverfügbarkeit verwandelt.
Die zweite Voraussetzung wurde durch den Cyber Resilience Act und den AI Act erodiert, die beide Sicherheits- und Risikomanagementpflichten einführen, die auf dem Hersteller über den gesamten Lebenszyklus des Produkts lasten und nicht nur zum Zeitpunkt der Lieferung. Software hat aufgehört, ein im Lieferzeitpunkt begrenztes Objekt zu sein, und gestaltet sich als ein Objekt, das dem regulatorischen Regime kontinuierlich ausgesetzt ist; jedes Update, jede Modifikation, jede Integration neuer Komponenten kann als wesentliche Modifikation requalifiziert werden, die das Produkt in das anwendbare Regime zurückbringt, auch wenn das Produkt in einer früheren Epoche auf den Markt gebracht worden war. Der Hauptanbieter, der das System 2023 geliefert hat, hat sich nicht 2026 von der Haftung entlastet, als eine in dieses System integrierte Drittbibliothek aufgehört hat, gewartet zu werden, und Sicherheitsschwachstellen entwickelt hat. Die Haftung hat sich einfach auf die Wartungsebene verschoben, und der Anbieter, der nicht aktualisiert hat, ist ein Anbieter, der einer fortlaufenden Pflicht nicht nachgekommen ist, nicht einer auf den Zeitpunkt der ursprünglichen Lieferung begrenzten Pflicht.
Auch die dritte Voraussetzung, die der Bilateralität der Lieferkette, wurde durch die Einführung von Haftungsketten erodiert, die die bilaterale Vertragsgestaltung durchqueren. Unter dem DORA-Regime muss das Finanzunternehmen sein ICT-Drittanbieter-Risiko entlang der gesamten Kette kartieren und verwalten, und wenn ein Anbieter als kritisch qualifiziert ist, erweitern sich die Pflichten so, dass die Vertragsklauseln zwischen dem Finanzunternehmen und dem kritischen Anbieter unabhängig vom Willen der Parteien spezifische, von der Verordnung auferlegte Elemente enthalten müssen. Der CRA seinerseits verpflichtet den Hersteller eines digitalen Produkts, die Sicherheit des integrierten Produkts zu gewährleisten, und diese Garantie erschöpft sich nicht in den Vertragsbeziehungen mit den eigenen Subunternehmern, weil der Regulator das Produkt als einheitliches Ganzes unabhängig von der internen Zusammensetzung der Lieferkette bewertet. Die überarbeitete PLD fügt eine zusätzliche Komplikation hinzu, indem sie vorsieht, dass der wesentliche Modifikator eines Produkts selbst als Hersteller verantwortlich werden kann, und das eröffnet eine zirkuläre Haftungsdynamik, in der der Hauptanbieter, der zwischengeschaltete Integrator, der Subunternehmer und der Endverbraucher unter verschiedenen Titeln für denselben Schaden in Anspruch genommen werden können. NIS2 und der AI Act vervollständigen das Bild, indem sie analoge Pflichten jeweils auf die erweiterten kritischen Sektoren und auf KI-Systeme mit hohem Risiko ausdehnen, mit dem Ergebnis, dass jedes Kettensegment heute von mindestens zwei oder drei überlappenden Regimen durchquert wird, die bilaterale Vertragsklauseln nicht zu komponieren vermögen.
Die vierte Voraussetzung, die der Stabilität des Rechtsregimes über die Zeit, ist die, deren Erosion die subtilsten Effekte erzeugt, weil die heute unter dem geltenden Rahmen unterzeichneten mehrjährigen Verträge morgen unter einem Rahmen angewendet werden, der sich entwickelt haben wird. Der Anbieter, der 2026 einen sechs- oder siebenjährigen Vertrag unterzeichnet, wird sich 2032 oder 2033 unter Regimen wiederfinden, die sich bis dahin signifikant verändert haben könnten, weil die PLD eine Revisionsklausel vorsieht, weil der CRA Gegenstand von Leitlinien sein wird, die die Auslegung ganzer Abschnitte ändern werden, weil der AI Act bereits von der Kommission selbst als offene Baustelle definiert worden ist. Der mehrjährige Vertrag unter dem traditionellen Modell setzte eine regulatorische Trägheit voraus, die es nicht mehr gibt.
Vier Phänomene, die der Vertrag nicht adressiert
Jedes dieser vier Phänomene hat praktische Konsequenzen, die der traditionelle Vertrag nicht adressieren kann. Die gesamtschuldnerische Haftung der Lieferanten kritischer Komponenten, auf unterschiedliche Weise von PLD und CRA eingeführt, sorgt dafür, dass der Hauptanbieter für die Mängel der integrierten Komponenten haftet, auch wenn die Subunternehmer säumig oder unerreichbar sind. Die Vertragsklauseln, die den Regress gegen die Subunternehmer regeln, bleiben zwischen den Vertragsparteien gültig, verschieben aber die Haftung gegenüber dem geschädigten Endverbraucher nicht, der jederzeit gegen den Hauptanbieter als das zugängliche und vermögensmäßig solideste Glied der Kette klagen kann. Der Hauptanbieter, der das Risiko über vertragliche Klauseln auf den Subunternehmer übertragen wollte, muss es daher absorbieren und kann erst nachträglich versuchen, im Regress wiederzugewinnen, vorausgesetzt, der Subunternehmer existiert noch, ist solvent und erreichbar.
Die durch die neue PLD eingeführten dokumentarischen Offenlegungspflichten sind das zweite Phänomen, und sie sind besonders heimtückisch, weil sie den Anbieter in ein Subjekt verwandeln, das dem Richter seine eigene technische Dokumentation vorlegen muss, auch wenn diese Dokumentation Designentscheidungen, Sicherheitskonfigurationen, Trainingsdatensätze, architektonische Entscheidungen umfasst, die das Unternehmen als Geschäftsgeheimnis betrachten würde. Der Richter muss das Recht auf Offenlegung mit dem Schutz von Geschäftsgeheimnissen abwägen, aber in der Praxis findet sich der Anbieter dokumentarischen Forderungen ausgesetzt, die der Vertrag mit dem Kunden nicht begrenzen kann, weil der Vertrag weder den Richter noch den Geschädigten bindet. Der Anbieter mag mit dem Kunden die Unzugänglichkeit der Dokumentation vereinbart haben, aber wenn der Geschädigte die Vorlage verlangt, muss der Anbieter produzieren, und die etwaige Verweigerung der Vorlage erzeugt nach Artikel 10 der Richtlinie eine Mangelvermutung.
Die Mangelvermutungen, die der einzelne Anbieter nicht allein widerlegen kann, sind das dritte Phänomen und das subtilste der vier. Die neue PLD sieht vor, dass der Richter die Mangelhaftigkeit des Produkts vermuten kann, wenn das Produkt technisch oder wissenschaftlich komplex ist und der Beweis des Mangels für den Geschädigten übermäßig schwierig wäre. Für komplexe Software-Systeme, insbesondere für solche, die KI-Komponenten integrieren, aktiviert sich diese Vermutung nahezu automatisch, und die Last, sie zu widerlegen, fällt auf den Anbieter. Die Vermutung zu widerlegen verlangt nachzuweisen, dass das Produkt zum Zeitpunkt der Lieferung den Mangel nicht aufwies, oder dass der Mangel später durch Modifikationen außerhalb der Kontrolle des Anbieters eingeführt wurde. Beide Nachweise verlangen detaillierte historische Dokumentation des Systems, und der Anbieter, der diese Dokumentation nicht gepflegt hat, findet sich dabei, nichts beweisen zu können, und unterliegt daher der Vermutung.
Die Accountability des wesentlichen Modifikators ist das vierte Phänomen, und es ist dasjenige, das die Struktur des bilateralen Vertrags am radikalsten bricht. Wenn ein Kunde oder ein zwischengeschalteter Integrator ein von einem Dritten geliefertes Software-Produkt wesentlich modifiziert, kann er selbst als Hersteller des modifizierten Produkts haften, und das eröffnet eine Dynamik, in der der ursprüngliche Anbieter möglicherweise nicht mehr für das Produkt in modifizierter Form haftet, der Modifikator aber möglicherweise nicht über die Kompetenzen, die Dokumentation und die Struktur verfügt, um die Verantwortung zu übernehmen, die er materiell übernommen hat. Das Ergebnis ist eine Grauzone der Haftung, in der der Geschädigte wählt, wen er verklagt, auf der Grundlage von Kriterien der vermögensrechtlichen und prozessualen Zugänglichkeit, und in der die beteiligten Parteien sich die Verantwortung mit oft paradoxen Ergebnissen zuspielen.
Die Konsolidierung, die nicht sofort kommt
Man könnte einwenden, und jemand wird es tun, dass all dies übertrieben ist und dass die richterliche Praxis einen Weg finden wird, Ordnung in das System zurückzubringen. Es ist ein Einwand, der Respekt verdient, weil die richterliche Praxis immer diese ausgleichende Funktion hat, und weil die europäischen Verordnungen, einmal in nationale Rechtsprechung übersetzt, oft die Strenge verlieren, die sie auf dem Papier haben. Die Antwort, die ich zu geben mich getraue, nachdem ich beobachtet habe, wie sich die Praxis in den europäischen Jurisdiktionen bewegt, in denen die ersten Fälle auftauchen, ist, dass die Konsolidierung kommen wird, aber sie wird in fünf oder sieben Jahren kommen, und in der Zwischenzeit ist das Expositionsfenster für Anbieter, die unter traditionellen Verträgen operieren, sehr breit. Die ersten relevanten Urteile zur Software-Herstellerhaftung unter der neuen PLD werden nicht vor 2028 kommen, weil das Regime auf Produkte angewendet wird, die nach dem 9. Dezember 2026 in Verkehr gebracht werden, und Verfahren mindestens anderthalb Jahre dauern. Von da an werden weitere drei oder vier Jahre nötig sein, bis sich eine konsolidierte Rechtsprechung bildet. In der Zwischenzeit akkumuliert jeder Anbieter, der mit Verträgen alten Modells arbeitet, rückwirkende Exposition, weil viele der Systeme, die er heute liefert, noch in Produktion sein werden, wenn sich die Rechtsprechung gefestigt hat, und sie werden mit den Kriterien bewertet, die sich bis dahin konsolidiert haben werden.
Die Sektoren, die uns vorangehen
Es wäre unaufrichtig, nicht anzuerkennen, dass es Sektoren gibt, in denen diese Dynamiken seit Jahrzehnten bestehen, und in denen Lieferverträge eine Struktur haben, die die Unzulänglichkeit des traditionellen bilateralen Modells anerkennt. Es sind Sektoren, die unter strengen Produkthaftungsregimen weit vor der Allgemeinsoftware leben, und die vertragliche Praktiken entwickelt haben, die es verdienen, studiert zu werden. Die Zivilluftfahrt ist eine davon, und Lieferverträge für Luftfahrtkomponenten enthalten seit jeher Pflichten zur dokumentarischen Rückverfolgbarkeit, zur Drittzertifizierung, zur koordinierten Behandlung von Nichtkonformitäten, zur gesamtschuldnerischen Haftung gegenüber Aufsichtsbehörden. Das Medizinprodukt ist ein weiterer, und Lieferverträge für Medizinproduktekomponenten sehen Qualitätsrahmenvereinbarungen vor, die über den einzelnen kommerziellen Vertrag hinausgehen und die Beziehung zwischen den Parteien als regulatorische Beziehung neben einer kommerziellen regeln. Das Automobil ist der dritte, vor allem nach der Einführung der ISO-26262-Normen zur funktionalen Sicherheit der elektronischen Systeme von Fahrzeugen, und Lieferverträge für Automobilsoftware enthalten seit etwa zehn Jahren Klauseln zur Haftung entlang der Kette, die die Unmöglichkeit anerkennen, die Exposition in bilateralen Verhältnissen einzudämmen.
Was in der Allgemeinsoftware geschieht, ist die Konvergenz — beschleunigt durch das europäische Regulierungspaket — auf das Modell, das diese Sektoren bereits praktizieren. Der Unterschied ist, dass Luftfahrt, Medizinprodukte und Automobil dreißig Jahre Zeit hatten, die vertraglichen Praktiken, die internen Kompetenzen, die Branchenstandards und die strukturierten Lieferbeziehungen aufzubauen. Die Allgemeinsoftware hat fünf oder sieben Jahre, dasselbe zu tun, und sie muss es tun, während sie weiterhin auf Märkten operiert, auf denen die meisten Wettbewerber noch im alten Modell denken. Es ist ein asymmetrischer Übergang, in dem, wer sich zuerst bewegt, einen Positionierungspreis zahlt, den, wer sich später bewegt, nicht zahlt, aber wer sich zuerst bewegt, baut auch die Kapazität auf, nachfolgende regulatorische Entwicklungen zu absorbieren, die der Spätbewegliche zu konsolidierten Marktpreisen wird kaufen müssen.
Fünf operative Dimensionen
Auf operativer Ebene hat die Transformation des Software-Liefervertrags fünf Dimensionen, die gleichzeitig zu verwalten sind. Die erste ist der Übergang vom Vertrag-als-Dokument zu den Vertragsdokumenten als Ökosystem. Ein Software-Liefervertrag unter dem neuen Regime erschöpft sich nicht in einem einzelnen Dokument, das bis zur Erneuerung gilt, sondern bildet ein System verbundener Dokumente, das den Hauptvertrag, die Service-Level-Anhänge, die Sicherheitsanhänge, die den Medizinproduktevereinbarungen ähnlichen Qualitätsvereinbarungen, die Vereinbarungen über die Verarbeitung personenbezogener Daten nach Artikel 28 DSGVO, die Vereinbarungen zur koordinierten Schwachstellenbehandlung, die Vereinbarungen zur gegenseitigen Lieferketten-Disclosure umfasst. Jedes dieser Dokumente lebt mit einem eigenen Aktualisierungszyklus, und der Hauptvertrag wird zum Rahmen, der sie zusammenhält, nicht zum Behälter aller Klauseln.
Die zweite Dimension ist die Transformation der Haftungsbegrenzungsklausel. Die traditionellen Klauseln, die die Haftung des Anbieters auf den jährlichen Vertragswert deckeln oder die indirekte Schäden ausschließen, bleiben zwischen den Vertragsparteien gültig, entfalten aber gegenüber den geschädigten Dritten keine Wirkung. Für den Anbieter bedeutet das, dass die effektive Exposition diejenige gegenüber dem geschädigten Endverbraucher ist, nicht die mit dem Kunden vereinbarte, und die Versicherungspolicen müssen auf dieser effektiven Exposition dimensioniert werden, nicht auf den vertraglichen Höchstgrenzen. Die Versicherungspraxis des Sektors ist in diesem Moment verworren, weil die Gesellschaften die Produkte für die Produkthaftung von Software-Herstellern in Funktion des neuen Regimes neu definieren, und die Prämien steigen nichtlinear. Für mittelgroße italienische Software-Häuser wird die Versicherungskosten der Produkthaftung zu einer relevanten Bilanzposition, wo sie bis vor wenigen Jahren eine vernachlässigbare war.
Die dritte Dimension ist die Neufassung der Klauseln zur Subunternehmerschaft, die von einem Modell, in dem der Kunde die Hauptsubunternehmer zum Zeitpunkt der Unterzeichnung genehmigt, zu einem Modell übergehen müssen, in dem es ein kontinuierliches Verfahren der Bewertung, des Monitorings und der Disclosure der Subunternehmer über die gesamte Vertragsdauer gibt. Der Hauptanbieter muss jederzeit die Zusammensetzung seiner Lieferkette nachweisen können, muss die SBOM nach dem CRA produzieren können, muss auf Auditanfragen des Kunden oder des Regulators antworten können, muss Situationen verwalten, in denen ein Subunternehmer den Markt verlässt oder die Wartung einer Komponente einstellt. All das verlangt Werkzeuge zum Lieferkettenmanagement, die das traditionelle Vertragsmodell als selbstverständlich nahm und die heute zu kontinuierlicher operativer Tätigkeit werden.
Die vierte Dimension ist die Einführung von Klauseln zur koordinierten Behandlung von Schwachstellen und Sicherheitsvorfällen. Unter dem CRA, unter NIS2 und unter DORA für den Finanzsektor haben Anbieter und Kunde beide Berichtspflichten innerhalb enger Zeitfenster, und die Einhaltung dieser Fenster verlangt eine Koordination, die der Vertrag operativ regeln muss, nicht nur formal. Eine Klausel, die sagt „die Parteien arbeiten bei der Vorfallsbehandlung zusammen“, ist nutzlos, wenn sie nicht spezifiziert, wer wann über welche Kanäle mit welchen Schwellenwerten benachrichtigt. Die Klausel muss fast ein vertragliches Mini-Runbook sein, und ihre Qualität bemisst sich an der Fähigkeit zu funktionieren, wenn ein realer Vorfall im Gange ist, nicht an ihrer juristischen Eleganz.
Die fünfte Dimension ist die subtilste, und sie betrifft das Lebenszyklus-Management des Produkts. Unter dem CRA muss der Hersteller den Supportzeitraum des Produkts erklären und ihn für diesen Zeitraum aufrechterhalten, und er muss den Marktaustritt des Produkts so verwalten, dass die Nutzer informiert sind und Übergangspfade haben. Der Software-Liefervertrag muss diesen Aspekt regeln, weil der Hauptanbieter auch nach dem Ende der Vertragsbeziehung mit dem Kunden gegenüber dem geschädigten Endverbraucher exponiert ist, und weil die Verwaltung des End-of-Support zu einem kritischen Moment wird, in dem sich Resthaftungen materialisieren können. Die traditionellen Klauseln „perpetual licence“ oder „no warranty after termination“ entfalten gegenüber den geschädigten Dritten keine Wirkung, und das bedeutet, dass der Anbieter den Lebenszyklus des Produkts als Funktion verwalten muss, die die Vertragsdauer übersteigt.
Disclosure: achtzehn Monate Neufassung
Ich muss in einem Punkt transparent sein, weil ich zu diesem Thema Transformationen beschreibe, die ich in erster Person erlebe. Die Überarbeitung unserer Lieferverträge im Unternehmen, in dem ich arbeite, ist eine seit achtzehn Monaten laufende Tätigkeit und hat noch keine stabile Form erreicht. Wir arbeiten mit unserer Referenzkanzlei daran, den Basisvertrag für die Lieferung von Software-Dienstleistungen neu zu schreiben, und was dabei herauskommt, ist weit entfernt von dem sauberen, eleganten Vertrag, den wir zu produzieren hofften, und hat die Form eines komplexer artikulierten Dokumentensystems als das vorhergehende, mit Anhängen, die aus unterschiedlichen Gründen existieren und die sich nicht auf ein einziges Template reduzieren lassen. Einige Kunden akzeptieren die neue Struktur, andere finden sie unnötig komplex und bitten, zum alten Modell zurückzukehren. Der Marktdruck zur vertraglichen Einfachheit ist noch stark, und in einigen Fällen akzeptieren wir selbst, Verträge alten Modells zu unterzeichnen, wenn der Kunde es auferlegt, im Wissen, dass wir rückwirkende Exposition akkumulieren. Es ist eine Wahl, die wir aus unmittelbaren kommerziellen Gründen treffen, und die ich in unseren internen Gesprächen zusammengesetzte Exposition genannt habe, weil sie nichtlinear akkumuliert, während das Kundenportfolio wächst.
Eine Chance, nicht nur eine Last
Ich möchte auch sagen, weil sonst der Text wie eine pessimistische Prognose über die italienische Software-Industrie klänge, dass die Transformation, die ich beschreibe, eine Chance ist, bevor sie eine Last ist. Mittelgroße italienische Software-Häuser, die sich entscheiden, vertragliche Kompetenzen aufzubauen, die mit dem neuen Regime kohärent sind, der Delivery-Arbeit eine kontinuierliche Arbeit der dokumentarischen Pflege und des Lieferkettenmanagements zur Seite zu stellen, intern die hybriden Figuren auszubilden, die ich im vorhergehenden Text dieser Reihe beschrieben habe, werden in fünf Jahren eine schwer zu erodierende Wettbewerbsposition haben. Die Software-Häuser, die weiterhin traditionelle Verträge unterzeichnen werden, in der Hoffnung, dass der regulatorische Rahmen sich nicht wirklich anwenden wird oder dass die nationale Rechtsprechung ihn abmildern wird, werden sich exponiert finden und werden den Rückstand zu Kosten aufholen müssen, die viel höher sind als die heute tragbaren. Es ist eine jener Situationen, in denen die Entscheidung, nicht zu entscheiden, die teuerste von allen ist, weil die Zeit gegen den arbeitet, der sich nicht bewegt, und weil jeder heute unter dem alten Modell unterzeichnete Vertrag eine Verbindlichkeit ist, die sich in einigen Jahren offenbaren wird, wenn die von der PLD als Standard-Szenario gezeichneten Fälle in den Berichterstattungs-Sektionen der Fachpresse zu erscheinen beginnen.
Die Zentralität, die stirbt
Wenn ich die vier Stücke dieser Reihe zusammensetze, ist das allgemeine Argument, das ich zu konstruieren versuche, das folgende. Die Software, als industrielles und als juristisches Objekt, ändert vor unseren Augen ihre Natur, und die Ingenieur- und Geschäftskultur des Sektors passt sich nicht in der Geschwindigkeit an, die der Augenblick verlangt. Das erste Stück, Cruft, keine Patina, argumentierte, dass Software nicht altern kann wie materielle Objekte. Das folgende, Die Spezifikationsschulden, verlagerte die Aufmerksamkeit auf die Tatsache, dass die geschriebene Spezifikation zum juristisch relevanten Aktivposten des Produkts geworden ist und dass unsere Industrie nicht über die Werkzeuge verfügt, sie am Leben zu halten. Dann kam Der Aufstieg des Compliance Engineers, gewidmet der hybriden Berufsfigur, die hervortritt, um das Vakuum zwischen Ingenieurkunst und Regulierung zu übernehmen. In diesem vierten Stück verlagert sich das Argument von der Ebene des Produkts und der Arbeit auf die Ebene der Beziehung zwischen Organisationen, und die These ist, dass der Liefervertrag, das klassische juristische Instrument dieser Beziehung, zu einem Instrument unter anderen einer breiteren und strukturierteren Beziehung wird, die das traditionelle Vertragsrecht nur teilweise regeln kann.
Der Software-Liefervertrag ist nicht tot, und nichts, was ich geschrieben habe, ist als Vorhersage seines Verschwindens zu lesen. Was tot ist, ist seine Zentralität, die Idee, dass die Beziehung zwischen Anbieter und Kunde umfassend durch ein zu Beginn der Beziehung verhandeltes und bei Erneuerungen aktualisiertes bilaterales Dokument beschrieben werden kann. Die zeitgenössische Beziehung ist eine multilaterale Beziehung, regulatorisch aufgeladen, dynamisch dritten Subjekten ausgesetzt, die der Vertrag nicht bindet, und durchquert von kontinuierlichen dokumentarischen Pflichten, die der Vertrag nur zusammenfassen kann. Zu denken, es genüge, die Klauseln besser zu schreiben, ist eine verständliche und menschliche Nostalgie, und es ist auch der schnellste Weg, Exposition zu akkumulieren, während man sich für geschützt hält. Die Klauseln dienen noch, mehr noch als zuvor, aber sie dienen als Elemente eines breiteren Dispositivs, das sie enthält und übersteigt.
Der Vertrag, wie wir ihn kannten, ist zur sanften Täuschung geworden, die es Software-Anbietern erlaubt zu glauben, sie wüssten, woran sie sich exponieren. Traditionelle Verträge werden noch einige Jahre lang unterzeichnet werden, weil sich der Markt langsamer bewegt als das Recht, und weil das alte Modell vertraut ist und die neuen Modelle noch in Bildung sind. Aber wer in den nächsten fünf Jahren weiterhin traditionelle Verträge unterzeichnet, unterzeichnet neben dem Vertrag eine stille Wette darauf, dass sich die Dinge nicht wirklich ändern werden. Es ist eine Wette, die meine Generation derer, die in Europa Software machen, wahrscheinlich verlieren wird, weil sich die Dinge bereits ändern, und das, was heute wie ein Übermaß an Vorsicht der wenigen aussieht, die sich bewegen, wird sich in einigen Jahren als das vorsichtige Minimum erweisen, das von Anfang an verlangt war.
Was du mitnimmst
Artikel 15 der überarbeiteten PLD ist der Schlussstein des neuen Regimes: Die Haftung gegenüber dem Geschädigten kann weder durch Vertragsklauseln noch durch nationale Rechtsvorschriften begrenzt oder ausgeschlossen werden. Was wie vertraglicher Spielraum aussah, wird zu einer Zone juristischer Unverfügbarkeit.
Vier implizite Voraussetzungen des traditionellen Vertragsmodells sind im selben Jahrzehnt gefallen: die Anbieter-Exposition, die in der Kundenbeziehung erschöpft war, Software als auf die Lieferung begrenztes Objekt, Lieferkette als Summe bilateraler Beziehungen, regulatorische Stabilität, die mehrjährige Verträge unter einem festen Rahmen sinnvoll machte.
Vier Phänomene, die der traditionelle Vertrag nicht adressieren kann: gesamtschuldnerische Haftung für kritische Komponenten, dokumentarische Disclosure an den Richter (mit Mangelvermutung bei Nichtvorlage), Mangelvermutungen für technisch komplexe Systeme, Accountability des wesentlichen Modifikators — die die bilaterale Struktur am radikalsten bricht.
Sektoren, die seit Jahrzehnten unter diesem Regime leben — Zivilluftfahrt, Medizinprodukte, Automobil — hatten dreißig Jahre Zeit, die Praktiken aufzubauen. Allgemeinsoftware hat fünf bis sieben Jahre, dasselbe zu tun, während die meisten Wettbewerber noch im alten Modell denken.
Der Vertrag ist nicht tot — seine Zentralität ist es. Die zeitgenössische Beziehung ist multilateral, regulatorisch aufgeladen, dynamisch Dritten ausgesetzt, die der Vertrag nicht bindet, durchquert von kontinuierlichen dokumentarischen Pflichten, die der Vertrag nur zusammenfassen kann. Klauseln zählen weiterhin — mehr als zuvor — aber als Elemente eines größeren Dispositivs, das sie enthält und übersteigt.
Fragen & Antworten
Warum hat der Software-Liefervertrag „aufgehört, zentral zu sein“?
Weil das juristische Regime, das sich zwischen 2024 und 2027 in Europa konsolidiert, eine Haftungsebene einführt, die außerhalb des Vertrags wirkt und die der Vertrag nur teilweise regeln kann. Die überarbeitete PLD, der CRA, der AI Act, NIS2 und DORA konvergieren darin, den Anbieter unabhängig von den mit dem zwischengeschalteten Kunden vereinbarten Klauseln gegenüber dem geschädigten Dritten haften zu lassen, und darin, dokumentarische, sicherheitsbezogene und lieferketten-bezogene Pflichten aufzuerlegen, die die bilaterale Vertragsgestaltung durchqueren. Die Klauseln regeln weiterhin den Regress zwischen den Vertragsparteien, verschieben aber die Haftung gegenüber Dritten nicht. Der Vertrag ist nicht tot — seine Zentralität ist es.
Was ändert sich mit Artikel 15 der überarbeiteten PLD?
Artikel 15 mit dem Titel „Ausschluss oder Begrenzung der Haftung“ verlangt von den Mitgliedstaaten zu gewährleisten, dass die Haftung des Wirtschaftsakteurs gegenüber dem Geschädigten weder durch Vertragsklauseln noch durch Vorschriften des nationalen Rechts begrenzt oder ausgeschlossen werden kann. Es ist ein kurzer, technischer Artikel, aber er ist der Schlussstein des gesamten Aufbaus: Er verwandelt das, was wie vertraglicher Spielraum aussah, in eine Zone juristischer Unverfügbarkeit. Der Anbieter, der sich mit Haftungsobergrenzen oder dem Ausschluss indirekter Schäden absichert, stellt fest, dass diese Klauseln den Regress mit dem unterzeichnenden Kunden regeln, nicht die Exposition gegenüber dem geschädigten Dritten.
Welches sind die vier operativen Phänomene, die der traditionelle Vertrag nicht adressieren kann?
Erstens, die gesamtschuldnerische Haftung der Lieferanten kritischer Komponenten: Der Hauptanbieter haftet für Mängel von Subunternehmern auch dann, wenn diese säumig oder unerreichbar sind. Zweitens, dokumentarische Offenlegungspflichten gegenüber dem Richter, mit Mangelvermutung bei Nichtvorlage (Artikel 10 PLD). Drittens, Mangelvermutungen für technisch komplexe Systeme, die sich für Software, die KI-Komponenten integriert, nahezu automatisch aktivieren. Viertens, die Accountability des wesentlichen Modifikators: Der Kunde oder der zwischengeschaltete Integrator, der ein Produkt modifiziert, kann selbst zum verantwortlichen Hersteller werden und damit die bilaterale Vertragsstruktur brechen.
Welche Sektoren operieren bereits unter einem ähnlichen Regime, und was können wir lernen?
Zivilluftfahrt, Medizinprodukte und Automobil leben seit Jahrzehnten unter strengen Produkthaftungsregimen und haben nützliche vertragliche Praktiken entwickelt. Luftfahrtverträge enthalten Pflichten zur dokumentarischen Rückverfolgbarkeit und zur Zertifizierung durch Dritte. Medizinprodukte sehen Qualitätsrahmenvereinbarungen vor, die über den einzelnen kommerziellen Vertrag hinausgehen. Automobil, vor allem nach ISO 26262, enthält Klauseln zur Haftung entlang der Kette. Der Unterschied ist, dass diese Sektoren dreißig Jahre Zeit hatten, die Praktiken aufzubauen; Allgemeinsoftware hat fünf bis sieben Jahre, dasselbe zu tun.
Welches sind die fünf operativen Dimensionen der vertraglichen Transformation?
Erstens: vom Vertrag-als-Dokument zu vertraglichen Dokumenten als Ökosystem (Rahmenvertrag, SLAs, Sicherheitsanhänge, Qualitätsvereinbarungen, Datenverarbeitungsvereinbarungen nach Artikel 28 DSGVO, koordinierte Schwachstellenbehandlung, Lieferketten-Disclosure). Zweitens: die Haftungsbegrenzungsklausel, die zwischen den Parteien gültig bleibt, aber gegenüber Dritten keine Wirkung entfaltet (was eine Neudimensionierung der Versicherungspolicen erzwingt). Drittens: die Neufassung der Subunternehmen, von einer anfänglichen Genehmigung zu einem kontinuierlichen Bewertungs- und Disclosure-Verfahren. Viertens: operative Klauseln zur Behandlung von Schwachstellen und Vorfällen, fast wie vertragliche Mini-Runbooks. Fünftens: Lebenszyklus-Management des Produkts und End-of-Support, das die Dauer der Vertragsbeziehung übersteigt.
Gibt es einen Zusammenhang zwischen diesem Text und den drei vorhergehenden Essays der Reihe?
Ja, und das ist der vierte und letzte der Reihe. Cruft, keine Patina argumentierte, dass Software nicht altern kann. Die Spezifikationsschulden verlagerte die Aufmerksamkeit auf die Tatsache, dass die geschriebene Spezifikation zum juristisch relevanten Aktivposten des Produkts geworden ist und dass die Werkzeuge fehlen, sie am Leben zu halten. Der Aufstieg des Compliance Engineers beschrieb die hybride Figur, die das Vakuum zwischen Ingenieurkunst und Regulierung übernimmt. Dieser Text verlagert das Argument auf die Ebene der Beziehung zwischen Organisationen: Der Vertrag — das klassische juristische Instrument dieser Beziehung — wird zu einem Instrument unter anderen eines breiteren Dispositivs. Die einigende These ist, dass Software, als industrielles und als juristisches Objekt, sich vor unseren Augen in der Natur ändert, und die Ingenieur- und Geschäftskultur des Sektors sich nicht in der Geschwindigkeit anpasst, die der Augenblick verlangt.