Vom Pilotprojekt in den Betrieb
Die meisten KI-Piloten scheitern nicht an der Technik, sondern am Übergang danach: fehlende Datenreife, keine Einbettung in den Arbeitsalltag und ungeklärte Zuständigkeit nach dem Abschluss des Piloten. Wer diese drei Lücken gezielt schließt, bevor der Pilot endet, überführt ihn zuverlässig in einen stabilen, überwachten Betrieb statt in eine ungenutzte Demoversion.
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:
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.