Das Problem in einem Satz: Ein Unternehmen reklamiert fehlerhafte KI-Outputs beim Anbieter – und stellt fest, dass der Vertrag keine Leistungsbeschreibung enthält, an der sich „Fehler“ überhaupt messen ließen. Dann zeigt sich, ob der Vertrag die Realität von KI abbildet – oder die Realität von 2015.

Warum klassische IT-Muster bei KI strukturell versagen

Die Ausgangslage ist vielen Geschäftsführern und IT-Leitern vertraut: Das Unternehmen beschafft ein KI-System. Das Procurement-Team greift auf bewährte Vertragsmuster zurück – SaaS-Vereinbarung, Lizenzvertrag, Rahmenvertrag für IT-Dienstleistungen. Die Muster sind intern abgestimmt, vom Datenschutzbeauftragten gesichtet, vom Legal-Team freigegeben. Sie haben sich bewährt.

Das Problem liegt nicht in der Qualität dieser Muster. Es liegt darin, dass sie für eine andere Art von Software entwickelt wurden: deterministische Systeme, die bei gleichen Inputs verlässlich gleiche Outputs liefern, gegen eine spezifizierte Leistungsbeschreibung getestet werden können und deren Versionierung planbar und ankündigungspflichtig ist. KI-Systeme – insbesondere große Sprachmodelle und multimodale Modelle, die als Service bezogen werden (KIaaS: KI as a Service) – funktionieren grundlegend anders.

Vier strukturelle Unterschiede zwischen klassischer Software und KI-Systemen:

  • Outputs sind nicht vorhersagbar. Es gibt keine Spezifikation im klassischen Sinne, gegen die man Abweichungen als „Fehler“ messen könnte. Derselbe Input kann bei verschiedenen Anfragen unterschiedliche Outputs erzeugen.
  • Das System verändert sich. Modelle werden aktualisiert, nachtrainiert, durch neue Versionen ersetzt – häufig ohne Vorankündigung. Die KI, die heute eine bestimmte Leistung erbringt, ist nach dem nächsten Update möglicherweise eine andere.
  • Die Leistung ist kontextabhängig. Dasselbe System liefert je nach Input, Prompt-Gestaltung und Datengrundlage unterschiedliche Qualität. Wer schuldet was – und wann ist die Qualität mangelhaft?
  • Verantwortlichkeiten sind verteilt. Anbieter, Integrator und Betreiber wirken jeweils an unterschiedlichen Stufen der Wertschöpfungskette mit. Klassische Zweipersonenverhältnisse (Anbieter – Nutzer) bilden diese Realität nicht ab.

Das Qualifikationsproblem: Welcher Vertragstyp gilt überhaupt?

Bevor man über Vertragsinhalt sprechen kann, stellt sich die Frage der Vertragsqualifikation – und sie ist bei KI-Systemen alles andere als trivial. Das deutsche Recht kennt für KI-Nutzungsverträge keinen eigenen Vertragstyp. Je nach Ausgestaltung kommt in Betracht:

  • Mietvertrag (§§ 535 ff. BGB): Wenn das KI-System zeitlich befristet zur Nutzung überlassen wird, ohne dass ein spezifisches Ergebnis geschuldet ist. Typisch für reine API-Zugänge zu KI-Plattformen.
  • Dienstvertrag (§§ 611 ff. BGB): Wenn die Erbringung von KI-gestützten Dienstleistungen geschuldet ist, nicht deren Erfolg. Maßgeblich: Der Anbieter schuldet sorgfältiges Bemühen, kein bestimmtes Output.
  • Werkvertrag (§§ 631 ff. BGB): Wenn ein bestimmtes Ergebnis geschuldet ist – z.B. ein fertig generierter Bericht, eine Klassifikation, eine Entscheidungsempfehlung. Dann stellt sich die Folgefrage: Was ist der geschuldete Erfolg bei einem probabilistischen System?
  • Typengemischter Vertrag: In der Praxis am häufigsten – KIaaS-Verträge kombinieren typischerweise Elemente aus Miete (Plattformzugang), Dienst (Betrieb, Support) und Werk (Ergebnis einzelner KI-Aufgaben).

Die Qualifikation ist nicht akademisch. Sie entscheidet darüber, welches gesetzliche Gewährleistungsregime gilt, ob Kündigungsrechte aus § 627 BGB greifen und welche Verjährungsfristen für Mängelansprüche gelten. Wer diese Frage im Vertrag nicht klärt, überlässt sie dem Gericht.

Die sieben Regelungsbereiche, die KI-Verträge zwingend abdecken müssen

1. Leistungsbeschreibung: Was wird geschuldet?

Das zentrale Problem im KI-Vertragsrecht ist die Leistungsbeschreibung. Bei klassischer Software lässt sie sich technisch spezifizieren: Funktionsumfang, Performanceparameter, Verfügbarkeits-SLA, Schnittstellendefinitionen. Bei KI-Systemen greift das nicht.

KI-Verträge müssen deshalb zwischen zwei Ebenen der Leistungsbeschreibung unterscheiden:

  • Prozessuale Ebene: Was schuldet der Anbieter hinsichtlich des Betriebs des Systems? Verfügbarkeit, Reaktionszeit, Datensicherheit, Infrastruktur. Diese Ebene lässt sich klassisch spezifizieren.
  • Output-Ebene: Was schuldet der Anbieter hinsichtlich der Ergebnisqualität? Hier sind klassische Erfolgsmaßstäbe nicht anwendbar. Stattdessen kommen statistische Qualitätsparameter in Betracht: Precision, Recall, F1-Score für Klassifikationsaufgaben; Halluzinationsraten und Factual Accuracy für Sprachmodelle; Benchmark-Performance auf definierten Testdatensätzen.

Praxistipp: Vereinbaren Sie nicht nur SLAs für Verfügbarkeit, sondern auch Qualitäts-SLAs für Output-Parameter – mit definierten Messmethoden, Messzeitpunkten und Konsequenzen bei Unterschreitung. Ohne diese Vereinbarung haben Sie bei verschlechterter KI-Leistung nach einem Modellupdate keine vertragliche Handhabe.

2. Modellaktualisierungen: Ankündigung, Rückfall, Einfrierung

KI-Modelle werden kontinuierlich weiterentwickelt. Anbieter behalten sich typischerweise das Recht vor, das zugrundeliegende Modell jederzeit zu aktualisieren, zu ersetzen oder einzustellen. Für Betreiber, die auf die Stabilität des Systemverhaltens angewiesen sind – etwa in regulierten Bereichen wie Medizin, Recht, Finanzberatung oder im Personalbereich – ist das ein erhebliches Risiko.

KI-Verträge sollten deshalb regeln:

  • Ankündigungsfrist: Wie weit im Voraus muss der Anbieter über wesentliche Modellaktualisierungen informieren? Wesentlich ist dabei alles, was die Output-Qualität oder das Systemverhalten in einem Maß verändert, das die bestehende Leistungsbeschreibung berührt.
  • Rückfalloption: Hat der Betreiber das Recht, bei einer Modellaktualisierung vorübergehend auf die vorherige Modellversion zurückzufallen? Für wie lange?
  • Versionsfixierung: In sensiblen Anwendungsfällen kann es sinnvoll sein, eine bestimmte Modellversion vertraglich einzufrieren – mit definiertem Support-Zeitraum.
  • Wesentliche Änderungen als außerordentlicher Kündigungsgrund: Wenn eine Modellaktualisierung die Eignung des Systems für den vereinbarten Zweck wesentlich beeinträchtigt, sollte der Betreiber ein außerordentliches Kündigungsrecht haben.

3. Transparenz- und Informationspflichten des Anbieters

Betreiber von KI-Systemen – insbesondere im Anwendungsbereich des AI Act – haben gegenüber Behörden, Betroffenen und Arbeitnehmern eine Reihe von Informationspflichten, die sie nur erfüllen können, wenn der Anbieter ihnen die dafür erforderlichen Informationen bereitstellt. Art. 13 AI Act verpflichtet Anbieter von Hochrisiko-KI-Systemen, ihren Betreibern hinreichende Transparenz zu gewährleisten – durch technische Dokumentation, Betriebsanleitungen und Informationen über Zweckbestimmung, Leistungsgrenzen und Risiken des Systems.

KI-Verträge müssen diese Pflicht vertraglich konkretisieren und absichern:

  • Recht des Betreibers auf Zugang zur technischen Dokumentation nach Art. 11 AI Act
  • Recht auf Aktualisierung der Dokumentation bei wesentlichen Systemänderungen
  • Recht auf Informationen über bekannte Leistungsgrenzen, Fehlerquellen und Einsatzbeschränkungen
  • Auskunftsrecht über Art und Herkunft der Trainingsdaten – relevant für urheberrechtliche Compliance (vgl. LG München I, Az. 42 O 763/25) und für DSGVO-Konformität

4. Haftungsallokation: Wer schuldet was in der Leistungskette?

KIaaS-Verträge sind typischerweise Mehrpersonenverhältnisse: Der Anbieter des Grundmodells (z.B. ein US-amerikanischer Foundation-Model-Anbieter) lizenziert an einen Integrator, der das Modell in eine Applikation einbettet und an den Betreiber liefert, der das System gegenüber Endnutzern einsetzt. Auf jeder dieser Stufen können Fehler entstehen – im Grundmodell, in der Fine-Tuning-Schicht, in der Prompt-Konfiguration, in der Datenbasis des Betreibers.

Das Haftungsdilemma: Wenn ein KI-Output fehlerhaft ist und dem Betreiber ein Schaden entsteht – wer haftet? Der Anbieter des Grundmodells, der Integrator oder der Betreiber selbst, weil er den Prompt schlecht gestaltet hat? KI-Verträge müssen diese Frage im Voraus beantworten, nicht dem Gericht überlassen. Konkret: Vereinbaren Sie klare Verantwortlichkeitszuweisungen für jede Stufe der Leistungskette, Freistellungsklauseln für nicht dem jeweiligen Vertragsverhältnis zuzurechnende Fehler und Haftungshöchstgrenzen, die das wirtschaftliche Risikoverhältnis abbilden.

Besondere Aufmerksamkeit verdient die Frage der Haftung bei KI-gestützten Entscheidungen. Wenn ein Betreiber ein KI-System zur Entscheidungsunterstützung einsetzt und ein Betroffener durch eine auf dem KI-Output basierende Entscheidung geschädigt wird, stellen sich nach der KI-Haftungsrichtlinie (AI Liability Directive) und dem AI Act komplexe Fragen der Kausalität und Verschuldenszurechnung. Der Vertrag sollte regeln, welche Partei in solchen Fällen die Beweisführungslast trägt und wer gegenüber Dritten primär exponiert ist.

5. AI Act-Pflichten: Art. 25 und Art. 26 vertraglich zuordnen

Der AI Act bringt für Unternehmen, die KI-Tools beschaffen und einsetzen, konkrete Rechtspflichten mit sich – und zwar unabhängig davon, ob das intern bekannt ist oder nicht. Wer als Betreiber ein KI-System im operativen Betrieb nutzt, unterliegt Art. 26 AI Act. Wer das System darüber hinaus anpasst oder unter eigenem Label weitergibt, läuft Gefahr, nach Art. 25 AI Act selbst zum Anbieter zu werden – mit erheblich weitergehenden Pflichten.

Art. 25 AI Act: Die unterschätzte Falle für Unternehmen, die KI anpassen. Wer ein Hochrisiko-KI-System mit eigenem Markennamen oder eigener Handelsmarke versieht, eine wesentliche Veränderung am System vornimmt oder dessen Zweckbestimmung so ändert, dass es zum Hochrisiko-System wird, gilt nicht mehr als Betreiber, sondern selbst als Anbieter im Sinne des AI Act – mit der vollen Pflichtenlast nach Art. 16 AI Act: Konformitätsbewertung, CE-Kennzeichnung, technische Dokumentation, EU-Datenbankregistrierung. In der Praxis passiert das schneller als gedacht: Fine-Tuning mit unternehmenseigenen Daten, ein internes KI-Tool unter Unternehmensmarke, ein angepasstes Modell für ein Kundensegment. Verträge müssen deshalb klar regeln, wer welche Anpassungen vornehmen darf – und welche Anpassungen den Anbieterstatus auslösen.

Auf der Betreiberseite verpflichten Art. 26 Abs. 1, 4 und 5 AI Act zu konkreten Maßnahmen: Das System muss gemäß Betriebsanleitung und mit menschlicher Aufsicht verwendet werden; Eingabedaten müssen zweckbestimmungsgemäß sein; schwerwiegende Vorfälle müssen unverzüglich gemeldet werden. All das setzt voraus, dass der Anbieter die dafür nötigen Informationen überhaupt liefert – vollständige Betriebsanleitungen, Dokumentation, Risikohinweise. Art. 25 Abs. 4 AI Act schreibt deshalb vor, dass Anbieter und Drittlieferanten diese Pflichten in einer schriftlichen Vereinbarung verbindlich regeln müssen.

Für Geschäftsführer und IT-Leiter bedeutet das: Jedes KI-Tool, das im Unternehmen eingesetzt wird, braucht eine klare Rollenzuweisung. Bin ich Betreiber? Werde ich durch Anpassungen zum Anbieter? Wer trägt welche Compliance-Last? Und ist das vertraglich abgesichert – oder überlasse ich diese Frage dem Zufall?

6. DSGVO und Datenschutz: Mehr als der Standard-AVV

KI-Systeme verarbeiten häufig personenbezogene Daten – als Trainingsdaten, als Eingabedaten im laufenden Betrieb oder als Teil ihrer Outputs. Der Standard-Auftragsverarbeitungsvertrag (AVV) nach Art. 28 DSGVO ist dabei notwendige, aber keine hinreichende Bedingung für eine datenschutzkonforme KI-Nutzung.

Darüber hinaus sind zu regeln:

  • Opt-out aus dem Training: Werden Eingabedaten des Betreibers für das weitere Training des Modells verwendet? Das ist bei vielen KIaaS-Anbietern in den Standardbedingungen der Fall und muss vertraglich ausgeschlossen werden.
  • Datenlokalisierung: Wo werden Eingabedaten verarbeitet und gespeichert? Für Unternehmen, die besondere Kategorien personenbezogener Daten (Art. 9 DSGVO) oder vertrauliche Geschäftsdaten verarbeiten, ist das kein optionales Thema.
  • Automatisierte Einzelentscheidungen: Wenn das KI-System zur automatisierten Entscheidungsfindung eingesetzt wird, sind Art. 22 DSGVO und – im Hochrisiko-Bereich – die Transparenz- und Aufsichtspflichten des AI Act kumulativ zu beachten. Der Vertrag muss festlegen, wer die menschliche Aufsicht nach Art. 26 Abs. 2 AI Act sicherstellt.
  • Datenschutz-Folgenabschätzung: Art. 26 Abs. 9 AI Act sieht vor, dass Betreiber die vom Anbieter nach Art. 13 AI Act bereitgestellten Informationen für ihre DSGVO-Folgenabschätzung nach Art. 35 DSGVO verwenden. Der Vertrag sollte sicherstellen, dass diese Informationen tatsächlich und rechtzeitig bereitgestellt werden.

7. Exit und Portabilität: Was passiert bei Vertragsende?

KIaaS-Verhältnisse erzeugen eine besondere Form von Abhängigkeit: Betreiber, die ihr Geschäftsmodell, ihre internen Prozesse oder ihre Kundenangebote auf einem bestimmten KI-System aufgebaut haben, sind bei Kündigung oder Einstellung des Dienstes durch den Anbieter in einer schlechten Verhandlungsposition. KI-Verträge müssen deshalb Exit-Szenarien regeln:

  • Datenportabilität: In welchem Format und innerhalb welcher Frist erhält der Betreiber seine Daten zurück – Eingabedaten, Fine-Tuning-Daten, Protokolldaten?
  • Modellportabilität: Soweit der Anbieter ein kundenspezifisches Fine-Tuning durchgeführt hat: Hat der Betreiber ein Recht auf das Fine-Tuned Model oder nur auf die zugrundeliegenden Daten?
  • Übergangsfristen: Wie lange stellt der Anbieter nach Kündigung oder Einstellung des Dienstes einen Read-Only-Zugang oder eine Exportfunktion bereit?
  • Löschpflichten: Welche Daten werden nach Vertragsende auf welcher Zeitachse gelöscht – und wie wird das nachgewiesen?

KIaaS-Verträge: Die besonderen Herausforderungen bei Nutzung externer Modelle

KIaaS – die Nutzung großer KI-Modelle als cloudbasierter Dienst über API-Zugang – ist die in der Unternehmenspraxis am weitesten verbreitete Form der KI-Beschaffung. Sie bringt gegenüber dem klassischen Softwarekauf oder der Eigenentwicklung spezifische Herausforderungen mit sich, die in der Vertragsgestaltung häufig unterschätzt werden.

Der wichtigste Unterschied: Bei KIaaS kauft der Betreiber kein Produkt, sondern nutzt eine Infrastruktur, die der Anbieter kontinuierlich weiterentwickelt und über die er die vollständige technische Kontrolle behält. Der Anbieter kann Preise ändern, Nutzungsbedingungen anpassen, Modellversionen abkündigen, Dienste einstellen oder geografische Verfügbarkeit ändern – und der Betreiber hat darauf keinen direkten Einfluss.

Der unterschätzte Risikofaktor: AGB-Kontrolle. Die Standardbedingungen großer KIaaS-Anbieter sind typischerweise AGB im Sinne der §§ 305 ff. BGB. Das bedeutet: Klauseln, die den Betreiber unangemessen benachteiligen, sind nach § 307 BGB unwirksam – selbst wenn der Betreiber sie vertraglich akzeptiert hat. Gleichzeitig schränken die Grundsätze der Inhaltskontrolle die Möglichkeit ein, bestimmte Risiken durch AGB vollständig auf den Betreiber zu verlagern. Wer als Betreiber KIaaS-Dienste von US-amerikanischen Anbietern nutzt, sollte prüfen, welche AGB-Klauseln einer deutschen AGB-Kontrolle standhalten – und welche nicht.

Hinzu kommt die Frage der Drittlandübermittlung: Die meisten großen KIaaS-Anbieter sind US-amerikanische Unternehmen. Die Nutzung ihrer Dienste ist damit regelmäßig eine Übermittlung personenbezogener Daten in die USA im Sinne von Art. 44 ff. DSGVO. Nach dem Schrems II-Urteil des EuGH und der aktuellen Rechtslage zum EU-US Data Privacy Framework (DPF) – dessen Stabilität nach dem Wiedererstarken politischer Angriffe in den USA nicht als gesichert gelten kann – ist eine Einzelfallbewertung der Drittlandübermittlung unerlässlich.

Kritische Einordnung: Was fehlt, kann man nicht einklagen

Die Praxis zeigt ein wiederkehrendes Muster: Geschäftsführer und IT-Leiter beschaffen KI-Systeme mit hohem Aufwand für technische Due Diligence und intern abgestimmte Rollouts – und vernachlässigen die vertragliche Absicherung. Die technische Eignung wird geprüft, die rechtliche Leistungsbeschreibung nicht. Das Ergebnis sind Verträge, die im Streitfall keine Handhabe bieten: keine messbare Qualitätsschwelle, keine Ankündigungspflicht für Modellaktualisierungen, keine Exit-Regelung, keine klare AI Act-Pflichtenzuweisung.

Fehlt die Leistungsbeschreibung, fehlt auch der Maßstab für den Mangel. Fehlt die Ankündigungspflicht, hat der Betreiber bei einer verhaltensverändernden Modellaktualisierung kein Kündigungsrecht. Fehlt die Exit-Regelung, ist der Betreiber bei Einstellung des Dienstes auf die Kulanz des Anbieters angewiesen. Fehlt die AI Act-Pflichtenzuweisung, haften Betreiber für Pflichtverletzungen, die sie mit den ihnen zur Verfügung stehenden Mitteln gar nicht verhindern konnten.

KI-Verträge sind kein bürokratisches Hindernis für die KI-Beschaffung. Sie sind die rechtliche Infrastruktur, die eine stabile und rechtssichere KI-Nutzung überhaupt erst ermöglicht. Wer diese Infrastruktur nicht baut, baut auf Sand.

Quellen und Rechtsgrundlagen