KI-Servicebetrieb: SLA, Evaluation, Incident Response

Kurzantwort

Vor jeder Nutzungszusage braucht ein KI-Service drei Schichten Dienstgüte. Erstens klassische SLA: Verfügbarkeit, Latenz, Supportzeiten, Wiederherstellungsziele. Zweitens Qualitätsmetriken mit festem Evaluationsrhythmus: Trefferquote gegen ein Referenz-Testset, Korrektur- und Eskalationsquoten, Drift-Erkennung, anlassbezogene Prüfung bei Modell- und Prompt-Wechseln. Drittens Incident-Fähigkeit: Schweregrad-Klassen mit Reaktionszeiten, vorbereitete Sofortmaßnahmen wie Degradationsmodus oder Abschaltung und klare Kommunikationsregeln. Für Hochrisiko-Systeme kommen ab dem 2. August 2026 die Betreiberpflichten aus Artikel 26 der Verordnung (EU) 2024/1689 hinzu, einschließlich Meldefristen von 15, 10 oder 2 Tagen.

Die Kernaussagen

• Verfügbarkeit misst, ob der Dienst antwortet. Qualität misst, ob die Antwort stimmt. Ein KI-SLA ohne die zweite Schicht steuert am eigentlichen Risiko vorbei.
• Evaluation hat vier Kadenzen: laufende Alarme, wöchentliche Stichprobe, monatliche Voll-Evaluation, anlassbezogene Prüfung bei jeder Änderung. Fehlt die letzte, sind Anbieter-Modellwechsel ein blinder Fleck.
• Drift ist kein Störfall, sondern der Normalzustand: Daten, Nutzerverhalten und Modelle ändern sich laufend. Gemessen wird gegen eine Baseline, sonst gibt es nichts zu erkennen.
• Incident-Klassen mit Reaktionszeiten und geübten Sofortmaßnahmen unterscheiden den Servicebetrieb von der Ad-hoc-Krise.
• Die Meldefristen der Verordnung (EU) 2024/1689 — 2, 10 oder 15 Tage je nach Schwere — sind ohne vorbereitete Vorfallprozesse nicht einzuhalten.
• Gartner (2024) nennt unzureichende Risikokontrollen als einen der vier Hauptgründe für aufgegebene GenAI-Projekte. Der Betriebsapparat ist damit auch eine Investitionsabsicherung.

Warum die Frage jetzt zählt

Immer mehr Unternehmen sagen ihren Beschäftigten und Kunden KI-gestützte Dienste verbindlich zu. Laut McKinsey (2025) nutzen 88 Prozent der befragten Organisationen KI in mindestens einer Funktion, aber nur rund ein Drittel skaliert sie systematisch. In dieser Lücke entsteht ein neues Betriebsrisiko: Dienste laufen produktiv, ohne dass jemand ihre Qualität kontinuierlich misst. Gartner (2024) führte unzureichende Risikokontrollen als einen der vier Hauptgründe an, warum GenAI-Projekte nach dem Proof of Concept aufgegeben werden. S&P Global Market Intelligence (2025) fand Kosten, Datenschutz und Sicherheitsrisiken als Top-Hindernisse, alles Themen des Betriebs, nicht der Entwicklung.

Dazu kommt der Rechtsrahmen. Ab dem 2. August 2026 verpflichtet die Verordnung (EU) 2024/1689 Betreiber von Hochrisiko-Systemen zur laufenden Überwachung, zur Aussetzung bei Risikoverdacht und zur Mitwirkung an der Vorfallmeldung mit Fristen von bis zu zwei Tagen. Ein Unternehmen ohne Incident-Klassen und Meldewege kann diese Fristen strukturell nicht halten. Die Dienstgüte-Frage ist damit keine IT-Feinheit mehr, sondern eine Vorstandsfrage mit Datum.

Das doppelte Dienstgüteversprechen: verfügbar und richtig

Klassische IT-Services kennen ein einfaches Versprechen: Der Dienst ist erreichbar und schnell. Generative Systeme brechen diese Logik. Sie können pünktlich, flüssig und falsch antworten. Deshalb braucht der KI-Servicebetrieb zwei getrennte Metrik-Familien, die im selben Betriebsreport stehen.

Die erste Familie ist vertraut: Verfügbarkeit in Prozent, Latenz je Anfrage, Supportzeiten, Wiederherstellungsziele nach Ausfall, dazu Kosten je Vorgang als Steuergröße. Diese Werte erbt man weitgehend vom Modell- oder Cloud-Anbieter und ergänzt eigene Ziele für die Integrationsschicht.

Die zweite Familie muss das Unternehmen selbst definieren, weil kein Anbieter sie kennt. Bewährt haben sich vier Messgrößen. Erstens die Trefferquote gegen ein Referenz-Testset: kuratierte reale Fälle mit erwartetem Ergebnis, regelmäßig neu gefahren. Zweitens die Korrekturquote: Wie oft ändern Nutzende die Ausgabe wesentlich, bevor sie sie verwenden? Drittens die Eskalationsquote: Wie oft geben Nutzende den Fall an einen Menschen weiter? Viertens die Beanstandungsquote aus strukturiertem Feedback. Jede dieser Größen bekommt eine Zielspanne und eine Alarmschwelle. Erst dann ist „der Service läuft gut“ eine überprüfbare Aussage.

Ein Uptime-SLA für ein generatives System ist das Versprechen, dass der Irrtum jederzeit erreichbar ist. Dienstgüte beginnt bei der Frage, ob die Antwort stimmt, nicht ob sie kommt.

Wichtig ist die Trennung der Verantwortung: Die erste Metrik-Familie gehört der IT, die zweite dem Fachbereich. Wer beide in ein IT-Dashboard schiebt, erzeugt Zahlen ohne Konsequenz, weil niemand mit Fachautorität auf Qualitätssignale reagiert.

Evaluation als Betriebsroutine: Testset, Kadenz, Drift

Evaluation im Betrieb ist keine Wiederholung der Abnahme, sondern eine Routine mit vier Kadenzen. Laufend arbeiten automatische Alarme auf den Qualitätsmetriken: Reißt die Korrekturquote die Schwelle, meldet sich das System selbst. Wöchentlich zieht der Fachbereich eine Stichprobe echter Fälle und bewertet sie manuell. Das fängt Fehlerarten, die keine Metrik kennt. Monatlich läuft die Voll-Evaluation gegen das Referenz-Testset und schreibt das Ergebnis in den Betriebsreport. Anlassbezogen wird geprüft, wann immer sich etwas ändert: neue Modellversion, geänderter Prompt, neue Datenquelle, geänderte Berechtigungen.

Die anlassbezogene Kadenz ist die am häufigsten fehlende. Modell-Anbieter kündigen Versionen ab und stellen um, teils mit kurzer Frist. Dieselben Prompts liefern danach andere Antworten. Ohne Regressionstest gegen das Testset bemerkt das Unternehmen die Änderung erst an den Beschwerden. Das NIST AI Risk Management Framework (2023) verankert diese kontinuierliche Messung als eigene Funktion „Measure“; das Generative-AI-Profil des NIST (2024) konkretisiert sie für generative Systeme. ISO/IEC 42001 (2023) verlangt Betrieb und Leistungsbewertung als Teil eines auditierbaren Managementsystems.

Drift verdient dabei einen eigenen Blick, weil sie drei Quellen hat. Datendrift: Die realen Eingaben entfernen sich von dem, was im Pilot getestet wurde, neue Produktnamen, neue Vertragstypen, neue Sprachen. Verhaltensdrift: Nutzende stellen andere Fragen, sobald sie dem System vertrauen oder misstrauen. Modelldrift: Der Anbieter ändert das Fundament. Alle drei sind unvermeidlich. Steuerbar werden sie nur durch den Vergleich gegen eine dokumentierte Baseline. Wer keine Baseline aus der Pilotphase mitnimmt, kann Drift prinzipiell nicht erkennen, sondern nur Unzufriedenheit registrieren.

Das Referenz-Testset ist das Arbeitspferd dieser Routine. Es startet mit 30 bis 50 realen Fällen, wächst um jeden interessanten Grenzfall aus dem Betrieb und gehört inhaltlich dem Fachbereich. Es ist zugleich das Abnahmekriterium für jeden Modellwechsel und die gemeinsame Sprache zwischen Fach und IT.

Incident-Klassen und Reaktionszeiten

Ein KI-Vorfall sieht anders aus als ein Serverausfall. Das System läuft weiter, es antwortet nur falsch, gibt Vertrauliches preis oder verbrennt unbemerkt Budget. Deshalb braucht der Servicebetrieb eine eigene Schweregrad-Logik mit Reaktionszeiten und vorbereiteten Sofortmaßnahmen. Die folgende Staffelung ist ein redaktionelles Muster für den Mittelstand; die konkreten Zeiten setzt jedes Unternehmen nach Risikolage selbst.

Klasse	Typische Lage	Beispiele	Reaktionszeit	Sofortmaßnahme
SEV 1	Schaden läuft, Außenwirkung	Personenbezogene oder vertrauliche Daten in Ausgaben; falsche Auskünfte an Kunden in Serie	Sofort, unter 1 Stunde	Abschalten oder Feature deaktivieren; GF und Datenschutz informieren; Meldepflichten prüfen
SEV 2	Qualität massiv unter Schwelle, intern	Trefferquote im Testset bricht ein; systematische Falschklassifikation nach Modellwechsel	Unter 4 Stunden	Degradationsmodus: nur Suche, Vorschlag statt Auto-Entscheidung, Zweitprüfung Pflicht
SEV 3	Begrenzte Fehlfunktion	Einzelne Fehlermuster in einem Teilprozess; Latenz- oder Kostenanstieg über Alarmschwelle	1 Arbeitstag	Betroffenen Scope eingrenzen; Ursachenanalyse einplanen; Nutzende gezielt informieren
SEV 4	Auffälligkeit ohne akuten Schaden	Häufung negativer Feedbacks; leichte Drift gegen Baseline	Nächste Betriebsrunde	Beobachtung verdichten; Testset um Fälle ergänzen

Drei Dinge entscheiden, ob diese Tabelle Papier bleibt oder trägt. Erstens die Übung: Der SEV-1-Pfad wird vor dem Go-live einmal real durchgespielt, mit Zeitmessung. Erst dann weiß die Organisation, ob „unter einer Stunde“ erreichbar ist. Zweitens die Doppelbesetzung: Jeder Vorfall braucht eine technische Rolle für Eindämmung und eine fachliche Rolle für die Bewertung der Folgen. Drittens die Kommunikationsregel: Wer informiert wen bei welcher Klasse, einschließlich der Entscheidung, wann Kunden oder Behörden ins Bild kommen. Diese Regel entsteht vor dem ersten Vorfall, weil sie sich unter Druck nicht mehr sauber verhandeln lässt.

Nach dem Vorfall folgt die Ursachenanalyse mit Maßnahmenliste, jede Maßnahme mit Owner und Termin. Ein wiederkehrendes Muster verdient dabei besondere Ehrlichkeit: Wenn dieselbe Vorfallklasse zum dritten Mal auftritt, ist das kein Betriebsproblem mehr, sondern ein Architektur- oder Scope-Problem.

Die teuerste Zeile im Incident-Plan ist die, die fehlt: wer abschalten darf. Ein KI-Service ohne benannten Abschalter wird im Ernstfall von der Hierarchie moderiert statt vom Prozess gestoppt.

Betreiberpflichten: Artikel 26, Post-Market-Monitoring, Meldefristen

Für Hochrisiko-Systeme übersetzt die Verordnung (EU) 2024/1689 diese Betriebsdisziplin in Rechtspflichten. Artikel 26 verlangt vom Betreiber unter anderem: Nutzung entsprechend der Betriebsanleitung, menschliche Aufsicht durch kompetente, geschulte Personen, Sorgfalt bei den Eingabedaten, laufende Überwachung des Betriebs und Aufbewahrung der automatisch erzeugten Protokolle für mindestens sechs Monate. Besteht Grund zur Annahme, dass die Nutzung ein Risiko im Sinne von Artikel 79 birgt, muss der Betreiber die Verwendung aussetzen und Anbieter sowie Marktüberwachungsbehörde unverzüglich informieren.

Der Betrieb ist dabei kein geschlossener Kreis im eigenen Haus. Artikel 72 verpflichtet Anbieter zu einem System der Beobachtung nach dem Inverkehrbringen, das Leistungsdaten über die gesamte Lebensdauer aktiv sammelt und auswertet, ausdrücklich auch Daten, die Betreiber bereitstellen. Die eigene Qualitätsmessung ist damit zugleich Zulieferung an das Post-Market-Monitoring des Anbieters. Wer sauber misst, kann diese Mitwirkungspflicht aus dem Bestand bedienen; wer nicht misst, hat dem Anbieter im Ernstfall nichts zu geben und sich selbst nichts zu zeigen.

Bei schwerwiegenden Vorfällen greift Artikel 73 mit gestaffelten Fristen ab Kenntnis: zwei Tage bei weitverbreiteten Verstößen oder schwerwiegenden, irreversiblen Störungen kritischer Infrastruktur, zehn Tage beim Tod einer Person, fünfzehn Tage bei allen sonstigen schwerwiegenden Vorfällen. Ein unvollständiger Erstbericht ist zulässig, um die Frist zu wahren. Diese Uhren laufen ab Kenntnisnahme, nicht ab Abschluss der internen Analyse. Praktisch heißt das: Die SEV-Klassifikation muss die Frage „meldepflichtig ja oder nein?“ von Anfang an mitführen, und der Meldeweg zur zuständigen Marktüberwachungsbehörde muss vor dem ersten Vorfall bekannt sein. Die Pflichten gelten ab dem 2. August 2026. Auch wer kein Hochrisiko-System betreibt, tut gut daran, dieselbe Mechanik freiwillig zu fahren: Sie ist der Stand der Technik, und die Einstufung eines Systems kann sich mit dem Anwendungsfall ändern.

Maßnahmen für die Geschäftsführung

In 30 Tagen:

• Für den wichtigsten KI-Service die zwei Metrik-Familien schriftlich festlegen: Verfügbarkeits-SLA und drei bis vier Qualitätsmetriken mit Alarmschwellen. Owner: Service-Owner IT mit Fachbereich.
• Referenz-Testset mit 30 bis 50 realen Fällen aufbauen und eine Qualitäts-Baseline messen. Owner: Fachbereichsleitung.
• Incident-Klassen SEV 1 bis SEV 4 mit Reaktionszeiten und Abschaltbefugnis beschließen. Owner: Geschäftsführung.

In 60 Tagen:

• Den SEV-1-Pfad einmal real durchspielen, Zeiten messen, Lücken schließen, inklusive Kommunikationsregel und Meldeweg-Recherche. Owner: IT-Leitung mit Datenschutz.
• Evaluations-Kadenz aktivieren: Alarme laufend, Stichprobe wöchentlich, Voll-Evaluation monatlich, Regressionstest bei jeder Änderung. Owner: Fachbereich mit IT.
• KI-VO-Betroffenheit klären: Hochrisiko-Einstufung, Zuständigkeiten für Artikel-26-Pflichten, Fristenlogik nach Artikel 73. Owner: Legal / Compliance.

In 90 Tagen:

• Ersten monatlichen Betriebsreport mit beiden Metrik-Familien an die Geschäftsführung liefern und Zielspannen nachjustieren. Owner: Service-Owner.
• Feedback-Triage etablieren: Nutzerrückmeldungen strukturiert erfassen, bewerten, ins Testset überführen. Owner: Fachbereich.
• Degradationsmodus technisch verifizieren: kontrolliertes Herunterschalten ohne Komplettausfall. Owner: IT-Leitung.

Was Führung jetzt entscheiden muss

Häufige Fragen (FAQ)

Reicht das SLA unseres Cloud- oder Modell-Anbieters nicht aus?

Nein, denn das Anbieter-SLA deckt nur die Erreichbarkeit der Schnittstelle ab, nicht die Richtigkeit der Ausgaben in Ihrem Prozess. Ob das Modell Ihre Vertragsklauseln korrekt zusammenfasst oder Preise halluziniert, steht in keinem Anbieter-SLA. Die Verantwortung für die fachliche Qualität liegt beim Betreiber, bei Hochrisiko-Systemen macht Artikel 26 der Verordnung (EU) 2024/1689 die Überwachung des Betriebs sogar zur Rechtspflicht. Das Anbieter-SLA ist damit eine notwendige Unterlage, aber kein Ersatz für eigene Qualitätsmetriken und einen eigenen Incident-Pfad.

Wie oft müssen wir ein produktives KI-System evaluieren?

In vier Kadenzen: laufend über automatische Alarme, wöchentlich per Stichprobe, monatlich als Voll-Evaluation gegen das Referenz-Testset und anlassbezogen bei jedem Modell-, Prompt- oder Datenquellen-Wechsel. Die anlassbezogene Prüfung ist die wichtigste, weil Anbieter-Modellwechsel das Verhalten ohne Vorwarnung ändern können. Die Frequenz skaliert mit dem Risiko: Ein internes Recherchewerkzeug verträgt längere Intervalle als ein System mit Kundenkontakt. Entscheidend ist weniger die exakte Taktung als die Verbindlichkeit, ein Evaluationsplan ohne Owner und Termin ist keiner.

Was kostet ein angemessener Evaluations- und Incident-Apparat für ein KI-System?

Realistisch sind wiederkehrende Personalstunden statt großer Investitionen: der Aufbau eines Referenz-Testsets, danach je System wenige Stunden pro Woche für Stichproben, Feedback-Triage und die Betriebsrunde, plus punktuelle Voll-Evaluationen. Das ist erheblich billiger als ein einziger unentdeckter Qualitätsvorfall mit Kundenkontakt. Zur Einordnung des Gesamtaufwands: Laut Deloitte (2025) rechnen 69 Prozent der befragten Unternehmen mit mindestens einem Jahr, bis ihre GenAI-Governance vollständig umgesetzt ist. Wer klein startet, sollte das Budget deshalb als Dauerposten planen, nicht als Projektrest.

Welche Meldefristen gelten, wenn unser KI-System einen schwerwiegenden Vorfall verursacht?

Für Hochrisiko-Systeme gelten nach Artikel 73 der Verordnung (EU) 2024/1689 gestaffelte Fristen ab Kenntnis: 2 Tage bei weitverbreiteten Verstößen oder schwerwiegenden, irreversiblen Störungen kritischer Infrastruktur, 10 Tage beim Tod einer Person, 15 Tage bei allen sonstigen schwerwiegenden Vorfällen. Zulässig ist ein unvollständiger Erstbericht mit späterer Vervollständigung. Betreiber müssen erkannte Vorfälle unverzüglich dem Anbieter und in den vorgesehenen Fällen den Behörden melden; die Pflichten gelten ab dem 2. August 2026. Diese Fristen sind ohne vorbereitete Incident-Klassen und Meldewege praktisch nicht einzuhalten.

Womit fangen wir an, wenn unser KI-System heute ohne SLA und Evaluation läuft?

Mit der Qualitätsseite, nicht mit dem Verfügbarkeitsdokument. Erster Schritt: ein Referenz-Testset aus 30 bis 50 realen Fällen mit erwarteten Ergebnissen, gepflegt vom Fachbereich. Zweiter Schritt: zwei bis drei Qualitätsmetriken festlegen, etwa Korrekturquote der Nutzenden und Trefferquote im Testset, und eine Baseline messen. Dritter Schritt: Incident-Klassen mit Reaktionszeiten und einer geübten Sofortmaßnahme definieren. Das Verfügbarkeits-SLA folgt zuletzt, weil es meist ohnehin vom Anbieter geerbt wird. Diese Reihenfolge liefert in vier bis sechs Wochen einen steuerbaren Grundbetrieb.

Evidenz und Grenzen

Belegt ist: der Wortlaut und die Fristen der Betreiber- und Meldepflichten (Verordnung (EU) 2024/1689, Artikel 26, 72, 73 und 79), die Rolle unzureichender Risikokontrollen beim Scheitern von GenAI-Projekten (Gartner 2024), die Betriebs-Hindernisse Kosten, Datenschutz und Sicherheit (S&P Global Market Intelligence 2025), der Governance-Zeitbedarf (Deloitte 2025) sowie die Verankerung kontinuierlicher Messung in NIST AI RMF (2023, GenAI-Profil 2024) und ISO/IEC 42001 (2023).

Redaktionelle Einschätzung ist: die vier Evaluations-Kadenzen, die vier Qualitätsmetriken und die SEV-Staffelung mit ihren Reaktionszeiten. Standardisierte Branchen-Benchmarks für Reaktions- oder Wiederherstellungszeiten bei KI-Qualitätsvorfällen existieren bislang nicht; die Tabelle ist ein Muster zur Anpassung, keine Norm.

Dieser Artikel leistet nicht: eine Rechtsberatung zur Hochrisiko-Einstufung, eine Toolchain-Empfehlung für Monitoring und Evaluation und die vorgelagerte Frage, wann ein Pilot überhaupt in den Betrieb wechseln sollte, dazu der vorangehende Beitrag zum Übergang in den verantworteten Betrieb.

Quellen und Methodik

1. Verordnung (EU) 2024/1689 (KI-Verordnung), insbesondere Artikel 26 (Pflichten der Betreiber von Hochrisiko-KI-Systemen), Artikel 72 (Beobachtung nach dem Inverkehrbringen), Artikel 73 (Meldung schwerwiegender Vorfälle) und Artikel 79; Amtsblatt der EU, 12.07.2024. https://eur-lex.europa.eu/eli/reg/2024/1689/oj
2. Europäische Kommission, AI Act Service Desk (2025): Erläuterung zu Artikel 73 samt Meldefristen. https://ai-act-service-desk.ec.europa.eu/de/ai-act/article-73
3. Gartner (2024): „Gartner Predicts 30% of Generative AI Projects Will Be Abandoned After Proof of Concept By End of 2025“, Pressemitteilung, 29.07.2024. https://www.gartner.com/en/newsroom/press-releases/2024-07-29-gartner-predicts-30-percent-of-generative-ai-projects-will-be-abandoned-after-proof-of-concept-by-end-of-2025
4. S&P Global Market Intelligence (2025): Voice-of-the-Enterprise-Erhebung zu KI-Projektabbrüchen und Hindernissen (1.006 Befragte); Berichterstattung u. a. CIO Dive, März 2025. https://www.ciodive.com/news/AI-project-fail-data-SPGlobal/742590/
5. Deloitte (2025): „The State of Generative AI in the Enterprise“, Q4-Ausgabe, Januar 2025, u. a. 69 Prozent erwarten mindestens ein Jahr bis zur vollständigen Governance-Umsetzung. https://www.deloitte.com/us/en/about/press-room/state-of-generative-ai.html
6. McKinsey (2025): „The State of AI“, Global Survey, November 2025 (1.993 Befragte, 105 Länder). https://www.mckinsey.com/capabilities/quantumblack/our-insights/the-state-of-ai
7. NIST (2023/2024): „AI Risk Management Framework (AI RMF 1.0)“, NIST AI 100-1, Januar 2023; „Generative Artificial Intelligence Profile“, NIST-AI-600-1, Juli 2024. https://www.nist.gov/itl/ai-risk-management-framework
8. ISO/IEC 42001:2023: „Information technology — Artificial intelligence — Management system“, Dezember 2023. https://www.iso.org/standard/42001

Methodik: Alle Zahlen- und Rechtsclaims wurden im Juli 2026 per Web-Recherche gegen die genannten Fundstellen verifiziert; nicht belegbare Werte wurden durch qualitative Aussagen ersetzt. Die Erstfassung entstand mit KI-Unterstützung; menschliche Faktenprüfung und redaktionelle Freigabe sind vor Veröffentlichung vorgesehen. Der Beitrag ersetzt keine Rechtsberatung.

Änderungsprotokoll

Datum	Änderung
2026-07-23	Erstfassung Launch-Korpus (Status: draft)
2026-07-23	Vollständige Neufassung: doppeltes Dienstgütemodell, Evaluations-Kadenzen, SEV-Tabelle, Artikel-26/72/73-Kapitel, Quellen verifiziert

Das Entscheider-Briefing

Ein Briefing pro Woche: Entscheidungsfragen, eingeordnete Zahlen und Fristen. Ihre Adresse geben wir nicht weiter.

Website

E-Mail-Adresse

Briefing abonnieren

Ich möchte das Briefing per E-Mail erhalten und kann die Einwilligung jederzeit widerrufen. Die Datenschutzerklärung habe ich gelesen.

Sie erhalten zuerst eine E-Mail mit einem Bestätigungslink. Erst nach dem Klick nehmen wir Sie auf. Abmeldung mit einem Klick in jeder Ausgabe.