SLA für KI Systeme: was ein Service Level regeln muss

SLA für KI Systeme: Überwachung, Nachtraining und Reaktion richtig vereinbaren

Ein SLA für KI Systeme legt fest, welche Leistung ein Betreiber nach dem Go live schuldet. Neben der Verfügbarkeit gehören dazu die Qualität gemessen gegen einen vorab festgelegten Referenzwert, Kostengrenzen, Regeln für Nachtraining und Modellupdates, Schweregrade mit Reaktionswegen, verständliche Berichte und die Mitwirkungspflichten des Unternehmens.

Warum klassische SLAs für KI Systeme nicht reichen

Was passiert, wenn Ihr KI System an einem Freitagabend falsche Antworten gibt? Wenn Ihr Vertrag darauf keine Antwort hat, haben Sie kein Service Level, sondern eine Hoffnung.

In der klassischen IT sind Service Level Vereinbarungen, kurz SLA, seit Jahren Standard. Sie regeln Verfügbarkeit, Reaktionszeiten und Wartungsfenster. Für einen Mailserver oder ein ERP reicht das weitgehend, denn diese Systeme arbeiten deterministisch: Läuft der Dienst, liefert er das erwartete Ergebnis.

KI Systeme verhalten sich anders. Ein Sprachmodell kann erreichbar sein, schnell antworten und trotzdem Inhalte liefern, die fachlich falsch sind. Ein Prognosemodell kann jeden Morgen pünktlich rechnen und dabei immer weiter neben dem tatsächlichen Absatz liegen, weil sich Sortiment, Preise oder Kundenverhalten verändert haben. Dieses Phänomen heißt Modelldrift. Es entsteht ohne eine einzige Änderung am Code.

Ein SLA, das nur die Verfügbarkeit regelt, deckt deshalb genau den Fehler nicht ab, der für KI typisch ist: Das System läuft, es liefert aber nicht.

Die Bausteine eines KI Service Levels

Baustein	Was vereinbart wird	Woran Sie es erkennen
Verfügbarkeit	Betriebsziel, Messmethode, Wartungsfenster	Regelmäßiger Bericht zur Erreichbarkeit
Qualität	Zielgröße, Referenzwert, Schwellen für Prüfung und Maßnahme	Laufende Messung gegen einen festen Testkatalog
Reaktion nach Schweregrad	Definition der Grade, Meldeweg, Ansprechperson, Eskalation	Protokoll jeder Meldung mit Zeitstempel
Kosten	Obergrenzen, Warnungen bei ungewöhnlichem Verbrauch	Verbrauch je Anwendungsfall im Bericht
Nachtraining	Auslöser, regulärer Prüfturnus, Freigabe	Dokumentierte Trainingsläufe mit Ergebnis vorher und nachher
Updates	Testpflicht vor dem Einspielen, Weg zurück zur Vorversion	Änderungsprotokoll mit Testergebnis
Berichte	Inhalt, Turnus, Empfänger in Fachbereich und IT	Bericht, den auch die Fachabteilung lesen kann
Mitwirkung	Datenzugang, Ansprechpersonen, Freigaben	Benannte Personen auf beiden Seiten
Ausstieg	Herausgabe von Daten, Modellen und Konfiguration	Vereinbartes Format und Übergabeplan

Ein vollständiges Service Level für KI besteht aus mehreren Bausteinen. Nicht jeder Anwendungsfall braucht alle in gleicher Tiefe. Fehlen sollte jedoch keiner.

Für die Verfügbarkeit setzen wir 99,9 % als Betriebsziel. Entscheidend ist, dass im Vertrag steht, wie diese Zahl gemessen wird: an welchem Punkt, in welchem Zeitraum und mit welchen Ausnahmen für geplante Wartung. Eine Verfügbarkeitszahl ohne Messmethode lässt sich weder prüfen noch einfordern.

Ebenso wichtig ist der Kostenbaustein. Anders als bei klassischer Software hängen die laufenden Kosten eines KI Systems direkt von der Nutzung ab, besonders bei Abrechnung pro Token. Ein neuer Anwendungsfall, eine fehlerhafte Schleife in einem Agenten oder eine unerwartet hohe Nachfrage können den Verbrauch sprunghaft steigen lassen. Vereinbaren Sie deshalb Obergrenzen je Anwendungsfall und eine Warnung, bevor diese erreicht werden. Im Bericht sollte erkennbar sein, welcher Anwendungsfall welche Kosten verursacht.

Berichte selbst werden oft unterschätzt. Ein Bericht, der nur Laufzeiten und Antwortzeiten der Server zeigt, hilft der IT, nicht dem Fachbereich. Ein guter Bericht beantwortet drei Fragen in einer Sprache, die auch Geschäftsführung und Fachabteilung verstehen: Lief das System wie vereinbart? Hat sich die Qualität gegenüber dem Referenzwert verändert? Welche Maßnahmen stehen als Nächstes an?

Qualität messbar machen: Referenzwert und Schwellen

Der wichtigste Unterschied zu einem klassischen SLA ist der Qualitätsbaustein. Er setzt voraus, dass vor dem Go live ein Referenzwert festgelegt wurde: Wie gut war der Prozess ohne KI, und wie gut war das System bei der Abnahme?

Für Sprachmodelle eignet sich ein fester Katalog von Testfragen mit geprüften Antworten aus Ihrem Fachbereich. Für Prognosemodelle eignet sich die Abweichung zwischen Prognose und tatsächlichem Wert, bewertet über die geschäftliche Zielgröße. Bei der Bedarfsprognose ist das die Differenz im gebundenen Kapital bei gleichem Servicegrad.

Auf dieser Grundlage vereinbaren Sie zwei Schwellen. Die erste löst eine Prüfung aus: Das Betriebsteam analysiert die Ursache und informiert den Fachbereich. Die zweite löst eine Maßnahme aus, etwa ein Nachtraining, eine Anpassung der Wissensbasis oder im Extremfall die vorübergehende Abschaltung. Wer über eine Abschaltung entscheidet, sollte namentlich geregelt sein und nicht nur als Rolle.

Drei Schweregrade und was für jeden geregelt sein muss

Schweregrad	Typisches Beispiel	Was geregelt sein muss
1: Das System steht	Anwendung nicht erreichbar, Schnittstelle zum ERP ausgefallen	Meldeweg auch außerhalb der Geschäftszeiten, benannte Ansprechperson, Reaktionszeit, Information an Fachbereich und IT, Ersatzprozess für die Dauer des Ausfalls
2: Spürbar falsche Ergebnisse	Antworten weichen systematisch vom Referenzwert ab, Prognosen liegen deutlich daneben	Wer den Qualitätsverlust feststellt, Reaktionszeit, Recht zur vorübergehenden Abschaltung, Ursachenanalyse, Entscheidung über Nachtraining oder Rückkehr zur Vorversion
3: Ein Einzelfall verhält sich unerwartet	Eine einzelne Antwort ist unpassend, ein seltenes Dokument wird falsch gelesen	Meldung mit Beispiel, Reaktionszeit, Aufnahme in den Testkatalog, Bündelung in die nächste reguläre Verbesserung

Drei Schweregrade reichen in den meisten Fällen aus. Mehr Stufen erschweren die Einordnung im Ernstfall, weniger Stufen vermischen Ausfall und Qualitätsproblem.

Welche Reaktionszeit für welchen Grad angemessen ist, hängt vom Anwendungsfall ab. Ein Assistent für interne Recherchen hat andere Anforderungen als ein System, das Kundenanfragen beantwortet oder Bestellungen auslöst. Wichtig ist, dass jede Stufe eine Reaktionszeit, eine Ansprechperson und eine Eskalation hat und dass beide Seiten dieselbe Definition verwenden. Wir legen diese Werte gemeinsam mit Ihnen auf Grundlage des konkreten Anwendungsfalls fest.

Hilfreich ist zudem ein gemeinsamer Probelauf. Spielen Sie vor dem Go live je einen Fall pro Schweregrad durch und prüfen Sie, ob Meldeweg, Ansprechperson und Eskalation in der Praxis funktionieren. Lücken fallen dabei auf, bevor sie im Ernstfall Zeit kosten.

Nachtraining, Updates und der Weg zurück

Nachtraining gehört als geplanter Prozess in das SLA, nicht als Notfallmaßnahme. Drei Fragen sind zu klären: Was löst ein Nachtraining aus, etwa das Überschreiten einer Qualitätsschwelle oder ein neues Sortiment? Wie oft wird regulär geprüft, ob eines nötig ist? Wer gibt das neue Modell frei, bevor es produktiv geht?

Für Updates von Modellen und Software gilt dieselbe Logik. Ein neues Basismodell kann insgesamt besser sein und trotzdem an genau der Stelle schlechter antworten, auf die Ihr Prozess angewiesen ist. Deshalb gehören in das SLA eine Testpflicht gegen den vereinbarten Testkatalog vor jedem Einspielen und ein dokumentierter Weg zurück zur Vorversion. Updates ohne diesen Weg zurück sind ein Risiko, das Sie nicht tragen sollten.

Zu diesem Baustein gehört auch die Frage, was am Ende der Zusammenarbeit passiert. Daten, angepasste Modelle, Prompts und Konfigurationen sollten Sie in einem offenen Format mitnehmen können. Worauf es dabei ankommt, beschreiben wir unter Ausstieg.

Die Gegenseite: was Ihr Unternehmen beiträgt

Ein Service Level ist keine Einbahnstraße. Es funktioniert nur, wenn klar ist, was das Unternehmen selbst beiträgt. Dazu gehören in der Regel:

Zugang zu den Daten, die für Überwachung und Nachtraining nötig sind
eine benannte Ansprechperson im Fachbereich, die Qualitätsfragen fachlich beurteilen kann
eine Ansprechperson in der IT für Schnittstellen, Rechte und Infrastruktur
zeitnahe Freigaben, wenn Nachtraining oder Updates anstehen
Meldungen von Auffälligkeiten über den vereinbarten Weg

Fehlen diese Beiträge, kann auch der beste Betreiber seine Zusagen nicht einhalten. Ein sauberes SLA benennt deshalb Pflichten auf beiden Seiten. Die vertragliche Ausgestaltung im Einzelfall stimmen Sie bitte mit Ihrer Rechtsabteilung oder Ihrer Kanzlei ab. Dieser Leitfaden beschreibt die fachlichen Inhalte und ersetzt keine rechtliche Prüfung.

Bei uns gehören diese Bausteine zum Betrieb und nicht zu einem optionalen Zusatz. Wie wir Service Level konkret aufsetzen, zeigen wir auf der Seite Service Level.

Häufig gestellte Fragen

Reicht ein Verfügbarkeitsziel von 99,9 % als SLA?

Nein. Verfügbarkeit sagt nur, dass das System erreichbar ist. Ob es brauchbare Ergebnisse liefert, regelt erst der Qualitätsbaustein mit Referenzwert und Schwellen. Beides gehört in die Vereinbarung.

Wer entscheidet, ob ein KI System abgeschaltet wird?

Das sollte im SLA namentlich geregelt sein. In der Regel entscheidet eine verantwortliche Person im Unternehmen auf Grundlage der Bewertung durch das Betriebsteam. Wichtig ist, dass diese Frage nicht erst im Ernstfall geklärt wird.

Wie oft muss ein KI Modell nachtrainiert werden?

Das hängt davon ab, wie schnell sich Daten und Prozesse verändern. Statt eines starren Turnus empfehlen wir regelmäßige Messungen gegen den Referenzwert und ein Nachtraining, sobald eine vereinbarte Schwelle überschritten wird. Verfügbarkeit allein ist kein Qualitätsversprechen. Ein KI System muss nicht nur laufen, es muss liefern. In einem Erstgespräch gehen wir mit Ihnen durch, welche Bausteine Ihr Anwendungsfall braucht und wie sich Qualität bei Ihnen messen lässt.