KI-Einkauf im Unternehmen folgt einem bekannten Drehbuch: jemand zeigt eine Demo, das System antwortet dreimal hintereinander gut, der Raum nickt, es wird unterschrieben. Niemand öffnet den Tab mit dem Service-Level-Agreement. Sechs Monate später, an einem Dienstagmorgen, antwortet der Agent, der Kunden beantwortet, nicht mehr —und da beginnt das Gespräch, das man vor der Unterschrift hätte führen sollen: wer repariert das, in welcher Zeit, und was passiert, wenn er es nicht repariert?
Die These in einem Satz: du wählst den Anbieter nach der Demo und lebst mit ihm über den Support. Und das SLA, das du gekauft zu haben glaubst, versagt meist an drei Punkten gleichzeitig: es deckt nicht den Tarif ab, den du nutzt, es misst Verfügbarkeit statt guter Arbeit des Systems, und es sagt absolut nichts darüber, wie lange das Modell noch existiert, von dem dein Betrieb abhängt.
Support und SLA deines KI-Anbieters decken nicht das ab, was du glaubst
Fangen wir beim Grundlegendsten an, das am wenigsten geprüft wird: fast kein Einstiegstarif hat ein SLA. Die Verfügbarkeitszusage lebt im Enterprise-Vertrag, der Rest der Kunden arbeitet mit dem besten Bemühen des Anbieters und einem Forum. Das ist kein Verdacht: es steht auf ihren eigenen Seiten.
Bei OpenAI hängen die 99,9 % Verfügbarkeit und die Latenzzusagen am Scale Tier, und die eigene Seite sagt es ohne Umschweife: es ist ein Angebot für Enterprise-Kunden, an das man über den Vertrieb kommt. Die normale nutzungsbasierte Abrechnung trägt diese Zusage nicht. Dazu kommt: das Vehikel wechselt mit der Modellgeneration. Der Scale Tier gilt für Modelle vor GPT-5.6, ab dort verlagert sich das Gespräch auf den Reserved Tier. Wenn dein Service-Level-Vertrag an einem Produkt hängt, das mit dem Modell in Rente geht, hat deine Absicherung ein Ablaufdatum —auch wenn es nirgends auf dem Papier steht.
Der Fall n8n ist noch klarer, weil er der Grenze einen Preis gibt. Der Business-Tarif kostet 667 € pro Monat bei jährlicher Abrechnung, und auf der eigenen Preisseite steht, dass Business eine Self-Service-Option ist und dedizierter Support nur im Enterprise-Tarif steckt. Heißt: du kannst fast achthundert Euro im Monat zahlen und dein offizieller Supportkanal bleibt das Community-Forum. Kein Skandal —es ist veröffentlicht und passt zu ihrem Modell— aber genau die Art Detail, die im Einkaufsmeeting niemand liest und die an dem Tag auftaucht, an dem der kritische Flow ausfällt.
Ein SLA misst, dass es an ist —nicht, dass es richtig liegt
Hier steckt der Punkt, der am teuersten kommt, weil er konzeptionell ist und sich nicht mit mehr Geld beheben lässt. Ein KI-Service-Level-Agreement misst Verfügbarkeit und, mit Glück, Latenz. Die Scale-Tier-Seite von OpenAI veröffentlicht zum Beispiel Geschwindigkeitszusagen der Art „99 % über 50 bis 100 Tokens pro Sekunde“, gemessen an der mittleren Latenz in Fünf-Minuten-Fenstern. Eine ernsthafte, überprüfbare Zusage. Und sie sagt nichts darüber, ob die Antwort richtig war.
Treib es ins Extrem, dann siehst du es klar: ein Modell, das mit voller Geschwindigkeit Unsinn ausspuckt und nie ausfällt, erfüllt die 99,9 % mit Auszeichnung. Das SLA ist erfüllt; dein Betrieb ist kaputt. Qualität —dass der Agent richtig klassifiziert, nichts erfindet, einem Kunden keinen Unfug antwortet— steht in keinem Infrastrukturvertrag, weil es kein Infrastrukturproblem ist. Es ist deins. Und deshalb delegiert man die Arbeit, die akzeptable Schwelle zu setzen und sie mit echten Fällen zu messen, nicht an den Anbieter.
| Was du glaubst, dass das SLA abdeckt | Was es wirklich abdeckt | Wer geradesteht |
|---|---|---|
| Dass das System funktioniert | Dass der Dienst verfügbar ist | Der Anbieter, mit Gutschriften |
| Dass es schnell antwortet | Manchmal, und nur in hohen Tarifen | Der Anbieter, wenn du es unterschrieben hast |
| Dass es richtig antwortet | Nichts. Qualität steht nicht im SLA | Du |
| Dass es das Modell weiter gibt | Nichts. Das regelt die Abschaltpolitik | Du, beim Migrieren |
| Dass deine Integration nicht bricht | Nichts. Auch Parameter werden abgekündigt | Du |
Die letzten beiden Zeilen sind die, die überraschen. Sie verdienen einen eigenen Abschnitt.
Die Uhr, auf die niemand schaut: wie lange dein Modell noch lebt
Dein System hängt nicht an „der KI“: es hängt an einem konkreten Modell, mit Namen und Version, das eines Tages abgeschaltet wird. Anthropic dokumentiert das mit einer Klarheit, die man anerkennen muss —und die man als das lesen sollte, was sie ist: eine Mindestzusage, kein Bestandsversprechen. Kunden mit aktiven Deployments werden mindestens 60 Tage vor der Abschaltung eines veröffentlichten Modells informiert.
Sechzig Tage klingen nach viel, bis du sie im echten Kalender ansiehst. Die eigene Abschalthistorie zeigt es: Claude Opus 4.1 wurde am 5. Juni 2026 als veraltet markiert und am 5. August 2026 abgeschaltet. Claude Sonnet 4 und Opus 4 wurden am 14. April 2026 angekündigt und am 15. Juni abgeschaltet. Zwei Monate, von der Ankündigung bis zum Aus. In dieser Frist musst du es mitbekommen, den Nachfolger gegen deine echten Fälle testen, sehen, was schlechter wird, die Prompts nachziehen, die am Verhalten des alten Modells hingen, und ausrollen. Wenn dein Betrieb die Ankündigungsmail nach vierzig Tagen entdeckt, hast du keine zwei Monate: du hast drei Wochen.
Und es gibt eine Nuance, die ganze Planungen zerlegt: das Datum hängt davon ab, wo du kaufst. Die Dokumentation von Anthropic weist darauf hin, dass von Partnern betriebene Plattformen —Amazon Bedrock und Google Cloud— eigene Abschaltkalender setzen. Dasselbe Modell kann also je nach Bezugsweg unterschiedliche Status und Daten haben. Wenn dein Cloud-Vertrag und dein Modell-Vertrag verschieden sind, hast du zwei Uhren, und keine warnt dich vor der anderen.
Die feine Version des Problems ist nicht einmal das Modell: es sind die Parameter. Anthropic dokumentiert, dass „temperature“, „top_p“ und „top_k“ ab Claude Opus 4.7 veraltet sind und einen Fehler 400 zurückgeben, wenn du sie auf einen anderen als den Standardwert setzt. Übersetzt: eine Codezeile, die zwei Jahre lang lief, bricht plötzlich den Aufruf. Das ist kein Ausfall des Dienstes —das SLA bleibt makellos— aber dein Agent arbeitet nicht mehr wie vorher.
Die fünf Fragen, die man vor der Unterschrift wirklich stellt
Dafür braucht es keine Rechtsabteilung. Es braucht fünf Fragen, schriftlich, und die Antworten aufgehoben:
- Gilt das SLA für meinen Tarif? Und wenn nicht: was kostet der Tarif, der es trägt? Oft macht die Antwort aus einem billigen Kauf eine ganz andere Entscheidung.
- Was misst es genau und wie reklamiert man? Monatliche Verfügbarkeit, Latenz, beides. Und vor allem: kommen die Gutschriften automatisch, oder muss ich sie selbst einfordern, mit Nachweis und innerhalb eines Zeitfensters? Wenn Letzteres —und meist ist es Letzteres— muss jemand in deinem Team überwachen, um überhaupt reklamieren zu können.
- Was ist der echte Supportkanal und seine Reaktionszeit? Forum, E-Mail oder ein Mensch mit Namen. Eine schriftlich zugesagte Reaktionszeit ist mehr wert als ein „24/7 Support“-Logo auf der Website.
- Wie sieht die Abschaltpolitik für Modelle aus und wie viel Vorlauf gebt ihr? Und mit der Antwort in der Hand: schafft mein Team die Migration und die Neuvalidierung in dieser Frist, mit meinen echten Fällen?
- Was passiert mit meinen Daten, wenn ich gehe? Exportformat, Löschfrist, und ob der Anbieter mit dem trainiert, was du ihm schickst. Es ist die unangenehmste Frage und die, die am schnellsten zeigt, mit wem du es zu tun hast.
Was dir kein SLA geben wird: die Rufbereitschaft
Selbst wenn du den besten Vertrag am Markt unterschreibst, bleibt eine Lücke, die kein Anbieter füllt —und genau die tut weh. Wenn dein Agent aufhört zu funktionieren, ist der Normalfall nicht, dass der Anbieter ausgefallen ist: es ist, dass eine API nebenan ein Feld geändert hat, dass sich das Volumen verdreifacht hat, dass jemand einen Prompt angefasst hat oder dass der seltene Fall endlich aufgetaucht ist. Da gibt es niemanden anzurufen. Die Antwort ist deine.
Das heißt vier wenig glamouröse Dinge, die aber genau die Arbeit sind, KI zu betreiben: jemand, der wacht und es vor dem Kunden merkt, jemand in Rufbereitschaft mit der Befugnis, das System zu stoppen, ein schriftliches Verfahren für den Fehlerfall —die Wartung der KI-Automatisierungen ist nicht optional, sie ist die Hälfte des Projekts— und ein Kontrollrahmen, der festlegt, wer was abschalten darf, worum es bei Governance und Kontrolle der Automatisierung geht. Wenn diese vier Teile keinen Eigentümer haben, ist dein SLA ein hübsches Blatt Papier.
Unsere Position ist schlicht und wenig verkäuferisch: das SLA des Anbieters deckt seinen Teil ab, und sein Teil ist der kleinste. Der große —dass das System die Arbeit gut macht, dass jemand merkt, wenn es damit aufhört, und dass das Geschäft nicht stehen bleibt, während repariert wird— ist eine laufende operative Funktion, die man aufbauen muss. Genau das machen wir mit dem Incident-Management für KI-Agenten: Schicht, Verfahren, Eindämmung und Postmortem, damit der Ausfall ein gemanagter Vorfall ist und kein verlorener Vormittag.
Das Fazit, ohne Schmuck
Ein SLA ist eine sehr partielle und sehr eng abgegrenzte Risikoübertragung: der Anbieter gibt dir ein paar Gutschriften zurück, wenn sein Dienst nicht verfügbar war. Er gibt dir nicht den Kunden zurück, der gegangen ist, nicht den Abschluss, der sich verschoben hat, und nicht die drei Wochen, die dich der hektische Modellwechsel gekostet hat. Lies es mit diesem Verständnis, und du unterschreibst besser. Lies es in der Erwartung, dass es dich vor allem schützt, und die Überraschung kommt an einem Dienstagmorgen.
Die anderen wählen den Anbieter nach der Demo und entdecken den Support, wenn es kein Zurück mehr gibt. Du kannst fünf Fragen vor der Unterschrift stellen und die Rufbereitschaft aufbauen, die kein Vertrag enthält. Nicht glamourös. Aber genau das hält das System am Dienstag am Laufen.