SLA & SLO (Service Level Objectives)

DefinitionZielwerte für Verfügbarkeit/Latenz von KI-Systemen

SLA & SLO (Service Level Objectives) sind Zielwerte und Vereinbarungen, mit denen Teams die Zuverlässigkeit von KI-Systemen messbar machen – z. B. Verfügbarkeit, Latenz, Fehlerraten oder Antwortqualität. Ein SLO definiert interne Zielwerte (z. B. „99,9% der Requests unter 2 Sekunden“), ein SLA ist die vertragliche Zusage gegenüber Kunden inkl. Konsequenzen bei Nichteinhaltung.

Was bedeutet SLA und was bedeutet SLO?

SLO (Service Level Objective) beschreibt konkrete, messbare Ziele für einen Service. Es ist meist ein internes Steuerungsinstrument für Engineering, Produkt und Betrieb. SLA (Service Level Agreement) ist die externe Vereinbarung (Vertrag/Anhang), die typischerweise auf einem oder mehreren SLOs basiert und oft Kompensation, Credits oder Eskalationswege regelt. Praktisch: Nicht jedes SLO wird automatisch zum SLA – SLAs sind meist konservativer, um rechtliche und finanzielle Risiken zu begrenzen.

Wie funktioniert das in KI-Systemen (LLM, RAG, Agents)?

In KI-Stacks entstehen Ausfälle und Verzögerungen nicht nur im eigenen Backend, sondern auch durch Modellanbieter, Vektorsuche, Tools, Datenquellen oder Workflows. Deshalb definiert man SLOs entlang der Nutzerreise und misst sie über Service Level Indicators (SLIs) wie:

Verfügbarkeit (z. B. Anteil erfolgreicher Antworten ohne 5xx/Timeout)
Latenz (z. B. p95/p99 „Time to First Token“ und „Time to Final Answer“)
Qualität/Erfolg (z. B. „Antwort enthält Quellen“, „Tool-Call erfolgreich“, „RAG-Recall“)
Fehlerraten (z. B. Rate an Rate-Limits, Parsing-Fehlern, Tool-Failures)
Kosten (z. B. Token pro Request als Guardrail, um Budget-SLOs einzuhalten)

Ein typischer Ablauf: (1) User-Flow definieren, (2) SLIs messen, (3) SLO-Ziele festlegen, (4) Error Budget ableiten (z. B. 0,1% Ausfall pro Monat), (5) Alerts/Runbooks und Release-Regeln daran koppeln.

Beispiele für SLA/SLO in der Praxis

Chatbot mit ChatGPT/Large Language Model (LLM): SLO „99,9% erfolgreiche Antworten/Monat“, Latenz-SLO „p95 < 3s bis zur ersten Antwort“. SLA nach außen z. B. „99,5% monatliche Verfügbarkeit“.
RAG (Retrieval-Augmented Generation) mit Vektordatenbank (Vector Database) und Embeddings: SLO „p95 Retrieval < 300ms“ + „Antwort enthält in 95% der Fälle mindestens 1 valide Quelle“.
AI Agents (KI-Agenten) mit Function Calling / Tool Use: SLO „Tool-Call Erfolgsrate > 98%“ und „Max. 1 Retry im Mittel“, damit Agenten nicht in Schleifen laufen.
Automations in n8n / Automatisierung (Automation): SLO „Job-Completion-Rate > 99%“ und „Durchlaufzeit p95 < 2 Minuten“.

Warum sind SLA & SLO für KI wichtig?

KI-Systeme sind probabilistisch: Antworten können schwanken, externe Modelle können drosseln, und Fehler wirken sich direkt auf Nutzervertrauen aus (z. B. durch Halluzinationen (Hallucinations), Timeouts oder fehlende Quellen). SLOs schaffen klare Leitplanken für Produktqualität und Betrieb – und machen Entscheidungen objektiv: Wenn das Error Budget aufgebraucht ist, werden Releases pausiert, Stabilität priorisiert oder Kapazitäten erhöht. Das ist ein Kernprinzip moderner MLOps- und Reliability-Ansätze.

Was kostet es, SLA/SLO umzusetzen?

Es gibt keinen Fixpreis – die Kosten hängen vor allem von Monitoring/Observability, Skalierung und Redundanz ab. Treiber sind z. B. zusätzliche Telemetrie (Tracing, Token-Metriken), Lasttests, Fallback-Modelle, Caching, Multi-Provider-Strategien und Incident-Management. Je strenger das SLA (z. B. 99,99% statt 99,9%), desto überproportional steigen Aufwand und Infrastrukturkosten.

Best Practices (kurz)

SLOs an Nutzerwert koppeln (Antwort rechtzeitig und nutzbar), nicht nur an „Server lebt“.
p95/p99-Latenzen und End-to-End-Messung nutzen (inkl. Modell- und Tool-Zeiten).
Fallbacks definieren (z. B. kleineres Modell, vereinfachte Antwort, späteres Nachreichen von Quellen).
SLA juristisch sauber formulieren, SLO technisch präzise messen.

99,5%
typisches Verfügbarkeitsziel
Für produktive KI-Services im B2B setzen viele Unternehmen ein SLO von 99,5% Verfügbarkeit an, um Ausfälle spürbar zu begrenzen und zugleich Infrastrukturkosten für KMU beherrschbar zu halten.
<2 Sek.
erwartete Antwortzeit
Bei internen KI-Assistenten und Support-Anwendungen gelten Antwortzeiten unter 2 Sekunden oft als praxisnahes SLO, weil längere Latenzen die Nutzerakzeptanz und Prozessgeschwindigkeit deutlich senken.
20–30%
weniger Ticketaufkommen
Klare SLA- und SLO-Vorgaben für Verfügbarkeit und Reaktionszeit reduzieren in vielen KMU das IT-Ticketaufkommen um 20–30%, da Erwartungen, Eskalationen und Störungen besser gesteuert werden.

Chatbot-SLAs für verlässlichen Kundenservice im Onlineshop festlegen
Ein KMU im E-Commerce definiert für seinen KI-Chatbot klare SLOs, etwa 99,5 % Verfügbarkeit während der Geschäftszeiten und maximale Antwortzeiten von 2 Sekunden. So kann das Unternehmen sicherstellen, dass Kundenanfragen zu Lieferstatus, Retouren oder Produktfragen auch bei hohem Anfragevolumen zuverlässig bearbeitet werden. Werden die Zielwerte verfehlt, greifen Eskalationen an den menschlichen Support.
SLOs für KI-gestützte Qualitätsprüfung in der Fertigung absichern
Ein produzierendes KMU nutzt Bild-KI zur Erkennung von Fehlern auf Bauteilen und legt dafür Zielwerte für Systemverfügbarkeit und Auswertungszeit pro Prüfpunkt fest. Dadurch bleibt die Prüfung auch im laufenden Betrieb stabil und verursacht keine Engpässe an der Produktionslinie. Die definierten SLA- und SLO-Werte helfen zudem, Anforderungen gegenüber externen Software- oder Integrationspartnern messbar zu machen.
Verfügbarkeitsziele für KI-Prognosen in der Lager- und Tourenplanung vereinbaren
Ein Logistik- oder Handels-KMU setzt KI ein, um Bestellmengen und Lieferzeiten vorherzusagen, und definiert dafür SLOs für tägliche Berechnungen bis zu festen Uhrzeiten. So stehen Disposition und Tourenplanung morgens zuverlässig aktuelle Vorschläge zur Verfügung, ohne manuelle Notfallprozesse auslösen zu müssen. Mit klaren SLAs gegenüber dem Anbieter wird geregelt, wie schnell bei Ausfällen oder Verzögerungen reagiert werden muss.

Häufig gestellte Fragen

Was ist der Unterschied zwischen SLA und SLO?

Ein SLO (Service Level Objective) ist ein internes, messbares Ziel für die Zuverlässigkeit eines Systems, zum Beispiel Verfügbarkeit, Latenz oder Fehlerrate. Ein SLA (Service Level Agreement) ist die vertragliche Zusage gegenüber Kunden und enthält meist auch Folgen, wenn die vereinbarten Werte nicht eingehalten werden.

Welche Kennzahlen werden bei SLA und SLO typischerweise gemessen?

Typische Kennzahlen sind Verfügbarkeit, Antwortzeit, Fehlerrate, Durchsatz und bei KI-Systemen auch Antwortqualität oder Erfolgsquote eines Workflows. Wichtig ist, nur Werte zu wählen, die für Nutzer und Geschäftsprozesse wirklich relevant und sauber messbar sind.

Wir haben kein eigenes Tech-Team – können wir trotzdem sinnvolle SLOs für unsere Systeme definieren?

Ja, genau dafür ist meine Tech-Partnerschaft als externer CTO gedacht. Ich helfe dir, aus deinen bestehenden Tools, Prozessen und Engpässen realistische Service Level Objectives abzuleiten, ohne dass du dafür intern eine komplette IT-Leitung aufbauen musst.

Lohnt sich das Thema SLA und SLO auch für kleinere Unternehmen mit 5 bis 30 Mitarbeitern?

Ja, gerade kleinere Unternehmen profitieren davon, weil Ausfälle, langsame Prozesse oder unklare Tool-Verantwortung direkt Zeit und Umsatz kosten. Mit einem Tech-Gutachten oder einer laufenden Tech-Partnerschaft schaffen wir Klarheit, welche Systeme kritisch sind und welche Zielwerte für dein Unternehmen wirklich sinnvoll sind.

Wie finde ich heraus, ob unsere KI- oder Software-Prozesse überhaupt messbar genug für SLOs sind?

Das prüfen wir strukturiert in der KI-Beratung oder im Tech-Gutachten. Ich analysiere mit dir Prozesse, Datenbasis und technische Umsetzbarkeit, damit du nicht mit theoretischen Kennzahlen arbeitest, sondern mit messbaren Zielen, die im Alltag wirklich steuerbar sind.

Ist die Einführung von SLA- und SLO-Standards nicht sehr aufwendig?

Nicht, wenn man pragmatisch vorgeht. Statt ein kompliziertes Monitoring-Projekt aufzusetzen, definieren wir zuerst die wichtigsten Systeme, Risiken und Zielwerte und bauen dann nur so viel Struktur auf, wie dein Unternehmen tatsächlich braucht – zum Beispiel im Rahmen von OrbitOS-Umsetzungen oder einer laufenden CTO-Begleitung.

Kannst du SLA- und SLO-Ziele auch direkt in unsere Systemlandschaft und Prozesse integrieren?

Ja, genau das ist Teil meiner Arbeit in der Umsetzung mit OrbitOS und in technischen Analysen. Ich sorge nicht nur für Empfehlungen auf dem Papier, sondern für klare Prozesse, Dashboards, Automationen und Verantwortlichkeiten, damit Zuverlässigkeit im Tagesgeschäft wirklich messbar und steuerbar wird.