Warum Standardverträge hier nicht reichen
Wer ein KI-System nicht nur einmalig einführt, sondern dauerhaft betreibt, braucht einen anderen Vertragstyp als den klassischen IT-Dienstleistungsvertrag. Der Unterschied ist substanziell: Ein ERP läuft nach definierten Regeln. Ein LLM-basiertes System produziert jeden Monat andere Outputs – weil das Modell upgedated wird, weil sich Prompt-Verhalten ändert, weil neue Daten einfließen.
Das Vertragsmuster für den laufenden KI-Betrieb muss genau diese Dynamik abbilden. Typisches Muster in Österreich und Deutschland: Ein Dienstleister liefert ein fertig eingerichtetes KI-System, stellt es auf eigener Infrastruktur (oder SaaS) bereit und betreibt es für 12 Monate. Der Auftraggeber zahlt monatlich. Klingt einfach – ist es aber vertraglich nicht.
SLAs: Was wirklich messbar sein muss
Ein SLA für KI-Systeme hat drei Schichten, die separat geregelt sein müssen.
Schicht 1 – Verfügbarkeit der Infrastruktur: Das ist der klassische Uptime-Wert. 99,5 % pro Monat sind realistisch, 99,9 % nur mit entsprechend teurerer Redundanz. Wichtig: Geplante Wartungsfenster explizit ausnehmen, aber zeitlich begrenzen (z. B. maximal 4 Stunden pro Monat, außerhalb Geschäftszeiten).
Schicht 2 – Antwortqualität: Das ist der heikle Teil. Bei einem KI-System kann die Infrastruktur laufen und das System trotzdem unbrauchbare Outputs liefern – weil das zugrunde liegende Modell ein Update bekommen hat oder weil sich die Datenbasis geändert hat. Hier braucht es messbare Qualitätsmetriken: Ablehnungsrate, Halluzinationsrate auf einem Testset, durchschnittliche Antwortrelevanz. Diese Metriken müssen im Vertrag definiert sein, nicht erst in einem späteren Anhang.
Schicht 3 – Reaktionszeiten: Klassisch P1/P2/P3-Klassifizierung. P1 (System komplett ausgefallen oder systematisch falsche Outputs): Reaktion innerhalb 2 Stunden, Lösung innerhalb 8 Stunden. P2 (eingeschränkte Funktion): 4 Stunden Reaktion. P3 (Einzelfälle, keine Betriebsunterbrechung): nächster Werktag.
Ohne alle drei Schichten ist das SLA wertlos.
Haftung: Drei Szenarien, die explizit geregelt sein müssen
Szenario 1 – Falsche Ausgaben mit Folgeschäden: Das KI-System empfiehlt intern eine falsche Vorgehensweise, ein Mitarbeiter folgt ihr, es entsteht ein Schaden. Wer haftet? Der Operator (Dienstleister) haftet grundsätzlich nur für nachgewiesenes Verschulden bei der Implementierung oder Wartung – nicht für inhärente Modellfehler. Das muss im Vertrag klar stehen, inklusive einer Haftungsobergrenze (typisch: 3–6 Monatsentgelte).
Szenario 2 – Datenschutzverletzung durch Modell-Output: Das System gibt in seiner Antwort personenbezogene Daten aus, die es aus dem Retrieval-System zieht und an nicht berechtigte Nutzer liefert. Hier ist die Haftungsfrage komplexer, weil DSGVO-Bußgelder nicht deckeln lassen. Der Vertrag muss festhalten, wer als Verantwortlicher und wer als Auftragsverarbeiter gilt, und welche technischen Maßnahmen der Operator schuldet (z. B. Role-based Access im RAG-System).
Szenario 3 – Modell-Update mit Verhaltensänderung: Der Modellanbieter (OpenAI, Anthropic, etc.) ändert sein Modell. Das KI-System verhält sich danach anders – nicht falsch im technischen Sinne, aber unerwünscht aus Sicht des Auftraggebers. Mein Rat: Dieses Szenario explizit im Vertrag benennen und dem Operator eine Pflicht zur Vorab-Testung vor jedem Modell-Update auferlegen, mit Rollback-Option innerhalb von 48 Stunden.
Datenhoheit: Vier Punkte, die nicht fehlen dürfen
Datenhoheit ist kein abstraktes Prinzip – sie muss operativ definiert sein.
1. Datenspeicherort: Wo liegen die Vektordaten, die Gesprächsverläufe, die Fine-Tuning-Daten? EU-Rechenzentrum ist Mindeststandard für alles mit Personenbezug. Der Vertrag muss den konkreten Standort nennen, nicht nur „EU-konform”.
2. Eigentum an generierten Daten: Alle Outputs, alle Logs, alle durch den Betrieb entstehenden Daten gehören dem Auftraggeber. Klingt selbstverständlich – ist es vertraglich aber oft nicht. Viele Dienstleister behalten sich vor, anonymisierte Daten für Modell-Verbesserungen zu nutzen. Das muss ausdrücklich ausgeschlossen oder eingeschränkt werden.
3. Zugriff durch den Operator: Welche Personen beim Dienstleister haben Zugriff auf welche Daten, zu welchem Zweck? Technischer Support braucht Logs – aber nicht Klartextgespräche. Das muss differenziert geregelt sein.
4. Weitergabe an Sub-Dienstleister: Nutzt der Operator seinerseits einen Cloud-Anbieter oder einen Modell-API-Anbieter? Diese Sub-Auftragsverarbeiter müssen vertraglich genehmigt sein (Liste als Anhang), und Änderungen daran müssen mit Vorlaufzeit angekündigt werden (30 Tage sind Mindeststandard).
Exit-Klauseln: Der Teil, den alle unterschätzen
Nach 12 Monaten läuft der Vertrag aus – oder nicht, je nach Verlängerungsklausel. Was dann?
Datenrückgabe: Der Operator muss alle Kundendaten, Vektordatenbanken, Fine-Tuning-Datensätze und Konfigurationen in einem maschinenlesbaren Standardformat übergeben. Frist: 30 Tage nach Vertragsende. Format: explizit festlegen (JSON, CSV, JSONL für Embeddings). Kosten für den Export: Pauschal oder nach Aufwand – muss definiert sein, sonst wird daraus eine Nachverhandlung.
Datenlöschung: Alle Daten beim Operator werden nach Übergabe innerhalb von weiteren 30 Tagen gelöscht, mit schriftlicher Bestätigung. Sub-Dienstleister einschließen.
Übergabedokumentation: Der Operator schuldet eine technische Dokumentation, die es ermöglicht, das System bei einem anderen Anbieter neu aufzubauen. Das schließt Prompt-Designs, Systemarchitektur, verwendete Modellversionen und Evaluierungstestsets ein. Diese Pflicht muss schon beim Vertragsabschluss verankert sein – nicht erst beim Kündigungsgespräch.
Kündigungsfristen: Bei 12-Monats-Verträgen: 3 Monate zum Vertragsende ist Standard. Wichtig ist die Regelung für außerordentliche Kündigung: Bei anhaltenden SLA-Verletzungen (z. B. 3 Monate in Folge unter vereinbartem Qualitätsschwellwert) muss eine fristlose Kündigung möglich sein, ohne Pönale.
Governance während des Betriebs
Ein Punkt, der in den meisten Vertragsmustern fehlt: die laufende Steuerung.
Empfehlung: monatliche Betriebsberichte als Vertragspflicht festschreiben. Inhalt: tatsächliche Verfügbarkeit, Qualitätsmetriken gegen die vereinbarten Schwellwerte, Anzahl und Klassifizierung der Supporttickets, geplante Änderungen im nächsten Monat.
Zusätzlich: ein Change-Management-Prozess im Vertrag. Jede wesentliche Änderung am System (neues Modell, neue Datenquellen, geänderte Prompt-Architektur) braucht eine schriftliche Change-Anfrage mit Bewertung der Auswirkungen, Genehmigung durch den Auftraggeber und einen Testnachweis vor dem Go-live.
Beispielhaft: ein Steuerberater mit 12 Mitarbeitern, der ein internes Wissens-KI einsetzt. Wenn der Operator im Hintergrund das Retrieval-System umstellt, merkt der Auftraggeber das oft erst, wenn Antworten plötzlich unvollständig sind. Ohne Change-Management-Klausel hat er vertraglich keine Handhabe.
Checkliste: Was muss in den Vertrag
Die wichtigsten Punkte komprimiert:
- SLA Infrastruktur: Uptime-Wert, Wartungsfenster, Messmethode
- SLA Qualität: Metriken, Schwellwerte, Messzeitraum
- SLA Reaktion: P1/P2/P3 mit konkreten Zeiten
- Haftung: Obergrenzen, DSGVO-Verantwortlichkeit, Modell-Update-Szenario
- Datenhoheit: Speicherort, Eigentum, Zugriffsrechte, Sub-Auftragsverarbeiter
- Exit: Rückgabeformat, Löschfristen, Übergabedokumentation
- Kündigung: Fristen, außerordentliche Kündigung bei SLA-Verletzung
- Governance: Monatsbericht, Change-Management-Prozess
- Modell-Updates: Testpflicht vor Rollout, Rollback-Option
Was ich in der Praxis empfehle
Aus meiner Sicht gibt es zwei häufige Fehler bei der Vertragsgestaltung.
Erster Fehler: Qualitäts-SLAs werden wegverhandelt, weil beide Seiten nicht wissen, wie man KI-Qualität misst. Das ist kein Argument, es wegzulassen – es ist ein Argument, mehr Zeit in die Definition der Metriken zu investieren, bevor der Vertrag unterschrieben wird.
Zweiter Fehler: Exit-Klauseln werden als theoretisch betrachtet. Niemand denkt beim Vertragsabschluss ans Ende. Typisches Muster: Nach 12 Monaten gibt es Wechselabsichten, aber keine verwertbare Übergabedokumentation existiert, und die Verhandlung darüber dauert länger als ein Neuaufbau. Der Exit ist kein Misstrauensvotum – er ist operative Absicherung.
Ein 12-Monats-KI-Betriebsvertrag ist kein IT-Wartungsvertrag mit anderem Deckblatt. Er braucht eine eigene Struktur, die die Dynamik von KI-Systemen abbildet. Wer das beim ersten Vertrag richtig macht, spart sich erheblichen Aufwand beim zweiten.