KI im Betrieb: Qualität, Kosten, Modell-Updates und Störfallbehandlung überwachen

Nach dem Go-live ändern sich die Fragen: Ist die KI noch so gut wie im Pilot? Was kostet sie? Was passiert, wenn der Anbieter das Modell austauscht? Und wer reagiert, wenn sie etwas Schädliches erzeugt? Dieser Leitfaden gibt Ihnen ein schlankes Betriebsmodell mit einer verantwortlichen Person, wenigen Kennzahlen, einer Kostenbremse, einem Änderungsprozess für Modell-Updates und einem Vorfall-Leitfaden.

Warum es wichtig ist

• KI-Systeme verändern sich unter Ihren Händen. Die Lifecycle-Richtlinie von Microsoft für Foundry-/Azure-OpenAI-Modelle sieht für allgemein verfügbare Modelle einen Lebenszyklus von 18 Monaten vor (bei einigen Partnermodellen 12 Monate), sagt mindestens 60 Tage Vorankündigung vor der Abschaltung eines GA-Modells zu und stellt Standard-Bereitstellungen bei der Abschaltung automatisch auf ein Nachfolgemodell um. Vorschau-Modelle können mit 30 Tagen Vorlauf zwangsweise umgestellt werden. Abschaltdaten sind „nicht verlängerbar“ [1]. Ohne Planung kommt das Nachfolgemodell ungetestet gegen Ihre Prompts und Extraktionsregeln.
• Kosten sind variabel und können davonlaufen. Nutzungsbasierte KI wird pro Token oder pro Aufruf abgerechnet. OWASP führt „Unbounded Consumption“ als eines der zehn größten Risiken für LLM-Anwendungen: Unkontrollierte Inferenz führt zu Dienstausfällen und finanziellen Verlusten („Denial of Wallet“). OWASP empfiehlt Ratenbegrenzungen, Kontingente und Nutzungsüberwachung [2]. Die FinOps Foundation empfiehlt, KI-Ausgaben an Stückkosten wie Kosten pro Anfrage, pro Nutzer oder pro Arbeitsablauf zu binden, weil reine Token-Preise Fixkosten ausblenden [3].
• Das Recht erwartet Überwachung, zumindest bei Hochrisiko-KI. Nach Art. 26 KI-Verordnung (AI Act) müssen Betreiber von Hochrisiko-Systemen kompetente menschliche Aufsicht benennen, den Betrieb überwachen, die Nutzung aussetzen und Anbieter sowie Marktüberwachungsbehörde informieren, wenn sie ein Risiko erkennen, und von ihnen kontrollierte Protokolle mindestens sechs Monate aufbewahren [4]. Nach dem Digital Omnibus, Verordnung (EU) 2026/1744, gelten diese Pflichten für Anhang-III-Systeme ab dem 2. Dez. 2027 (siehe GUIDE-014). Für andere Systeme ist es schlicht gute Praxis.
• KI-Vorfälle sind oft zugleich Sicherheits- und Datenschutzvorfälle. Ein Chatbot, der Kundendaten preisgibt, ist eine Verletzung des Schutzes personenbezogener Daten. Nach Art. 33 DSGVO müssen Sie die Aufsichtsbehörde innerhalb von 72 Stunden benachrichtigen [5]. Fällt Ihr Unternehmen unter NIS2, gilt das deutsche Umsetzungsgesetz seit dem 6. Dez. 2025: Erhebliche Sicherheitsvorfälle erfordern eine Frühwarnung an das BSI innerhalb von 24 Stunden, eine Meldung innerhalb von 72 Stunden und einen Abschlussbericht nach einem Monat [6].

Wann Sie es brauchen

• Vor dem Go-live (letzte Phase von GUIDE-009): Benennen Sie eine verantwortliche Person, richten Sie Kennzahlen, Budget-Warnungen und den Meldeweg für Vorfälle ein. Übergeben Sie kein System, das niemand betreibt.
• Ab dem ersten Produktionstag: im ersten Monat wöchentliche Prüfungen, danach monatlich.
• Immer wenn der Anbieter eine Modelländerung , eine neue Version oder eine neue Funktion ankündigt (bei SaaS-Werkzeugen auch „stille“ Änderungen, die in den Release Notes sichtbar werden).
• Immer wenn sich Ihre eigenen Daten oder Prozesse ändern (neue Dokumentlayouts, ERP-Release, Produktsortiment).
• Einmal im Jahr: vollständige Überprüfung einschließlich Vertrag, Kosten, Risikoklasse und der Frage, ob sich der Betrieb des Systems noch lohnt.

Wer beteiligt ist

Punkt zum Betriebsrat: Die Überwachung eines KI-Systems bedeutet fast immer, zu protokollieren, wer was getan hat (Prompts, Antworten, Korrekturen, Bearbeitungszeiten). Nach § 87 Abs. 1 Nr. 6 BetrVG genügt nach Auffassung des Bundesarbeitsgerichts die objektive Eignung zur Verhaltens- oder Leistungskontrolle, daher ist die Protokollierung und Berichterstattung mitbestimmungspflichtig. Vereinbaren Sie in der Betriebsvereinbarung, welche Protokolle es gibt, wer sie einsehen darf, wie lange sie aufbewahrt werden und dass Qualitätskennzahlen pro System oder Team ausgewertet werden, nicht pro Person. Ohne diese Regelung kann Ihr Monitoring-Dashboard den Rollout stoppen.

Schritt für Schritt

1. Ein einseitiges Betriebsblatt schreiben (ein halber Tag). Pro System: Zweck, Verantwortliche(r) und Vertretung, Anbieter und Modellversion, Datenquellen, Risikoklasse (GUIDE-014), Ablageort der Protokolle, Budget, Anbieterkontakt und der „Notausschalter“ (die Funktion abschalten, ohne den Prozess zu stoppen).

2. Basiswert und Testsatz festlegen (1-3 Tage, Pilot wiederverwenden). Nehmen Sie 50-200 reale Pilotfälle (GUIDE-009) mit bekannten richtigen Antworten, z. B. korrekt gebuchte Rechnungen oder freigegebene Antworten auf Kundenfragen. Dieses „Golden Set“ ist Ihr Regressionstest bei jedem Modellwechsel. Speichern Sie es zusammen mit den verwendeten Prompts und der Konfiguration.

3. Fünf bis acht Kennzahlen wählen, nicht fünfzig. Ein praktikabler Satz: - Qualität: Genauigkeit auf dem Golden Set; Anteil der von Nutzern korrigierten Ausgaben; „Daumen runter“-Quote; bei RAG-Assistenten der Anteil der Antworten mit korrekter Quelle. - Nutzung: aktive Nutzer, bearbeitete Fälle, Anteil der Fälle, die weiterhin vollständig manuell laufen. - Kosten: Gesamtausgaben und Kosten pro Fall (pro Rechnung, pro Ticket, pro Gespräch). - Betrieb: Verfügbarkeit, Latenz, Fehlerquote der API-Aufrufe. - Risiko: markierte Ausgaben, blockierte Prompts, Sicherheitsereignisse. Berichten Sie diese monatlich auf einer Seite.

4. Rückmeldungen dort einholen, wo gearbeitet wird. Ein Daumen-hoch/runter-Knopf, ein Link „Falsche Antwort melden“ oder ein Korrekturfeld in der ERP-Maske kostet wenig und liefert die beste Frühwarnung. Rückmeldungen werden anonym ausgewertet (Betriebsvereinbarung). Key-User führen monatlich eine Stichprobe von 20-30 zufälligen Fällen durch.

5. Kostenbremsen setzen (1 Tag). Richten Sie Budget-Warnungen bei 50/80/100 % in der Cloud-Konsole oder im Anbieterportal ein, dazu harte Kontingente pro Anwendung und pro Nutzer, Ratenbegrenzungen, maximale Ein- und Ausgabelänge und einen eigenen API-Schlüssel pro Anwendung, damit Sie sehen, wer welche Kosten verursacht [2][3]. Bei Sitzplatzlizenzen weisen Sie ungenutzte monatlich neu zu. Prüfen Sie die Modellwahl alle sechs Monate; oft genügt ein kleineres Modell.

6. Einen Änderungsprozess für Modell-Updates betreiben. Abonnieren Sie die Lifecycle-Benachrichtigungen des Anbieters (z. B. Service-Health-Warnungen und E-Mails bei Azure [1]). Legen Sie Modellversionen nach Möglichkeit fest und schalten Sie automatische Upgrades ab, damit Sie entscheiden, wann Sie wechseln. Wenn eine Änderung angekündigt wird: 1. Lassen Sie das Golden Set in einer Testumgebung auf dem neuen Modell laufen; 2. vergleichen Sie Qualität, Kosten und Latenz mit dem Basiswert; 3. passen Sie Prompts und Extraktionsregeln an; 4. wechseln Sie mit einer Rückfalloption (behalten Sie die alte Bereitstellung, bis die neue ein bis zwei Wochen sauber gelaufen ist, sofern der Anbieter das erlaubt); 5. dokumentieren Sie die Änderung im Betriebsblatt. Planen Sie zwei bis fünf Personentage pro Modellwechsel und System ein. Bei SaaS-Werkzeugen, bei denen Sie Versionen nicht festlegen können, lassen Sie das Golden Set nach jeder angekündigten Änderung mindestens erneut laufen.

7. Daten- und Wissensdrift beobachten. Bei RAG-Assistenten entfernt eine datenverantwortliche Person veraltete Dokumente und fügt neue hinzu. Bei Prognose- und Prüfmodellen vergleichen Sie monatlich Vorhersagen mit den tatsächlichen Ergebnissen und trainieren neu, wenn der Fehler die vereinbarte Schwelle überschreitet (GUIDE-003).

8. Den Vorfall-Leitfaden vorbereiten (1 Tag). Zu KI-Vorfällen zählen schädliche Ausgaben, abgeflossene vertrauliche oder personenbezogene Daten, erfolgreiche Prompt-Injection, falsche automatisierte Entscheidungen, die Kunden erreichen, ausufernde Kosten und Ausfälle. Legen Sie für jeden Fall fest, wer benachrichtigt wird (IT-Sicherheit, Datenschutzbeauftragte(r), Verantwortliche(r)), wie der Schaden gestoppt wird (Funktion abschalten, API-Schlüssel widerrufen, auf manuellen Betrieb umstellen), wie Beweise gesichert werden (Protokolle, Prompts, Ausgaben) und welche rechtlichen Prüfungen anstehen: Art. 33 DSGVO (72 Stunden) [5], NIS2-Meldung, falls zutreffend [6], Information des Anbieters und bei Hochrisiko-Systemen Information von Anbieter und Marktüberwachungsbehörde (Art. 26 KI-Verordnung) [4]. Binden Sie ihn in Ihren bestehenden IT-Notfallprozess ein, nicht in einen parallelen. Das BSI-Papier zu generativer KI listet Bedrohungen und Gegenmaßnahmen, die Sie hier wiederverwenden können [7].

9. Protokolle aufbewahren, aber bewusst. Bewahren Sie auf, was Sie für Qualität und Sicherheit brauchen, bei Hochrisiko-Systemen mindestens sechs Monate [4]. Vereinbaren Sie Aufbewahrung, Zugriff und Pseudonymisierung mit der/dem Datenschutzbeauftragten und dem Betriebsrat; Prompts enthalten oft personenbezogene Daten. Die DSK-Orientierungshilfe zu KI und Datenschutz adressiert Betreiber von KI-Systemen als Verantwortliche, Sie sind also auch dann für diese Daten verantwortlich, wenn der Anbieter sie speichert [8].

10. Jährlich überprüfen und den Mut zum Abschalten haben. Einmal im Jahr: Liefert der Anwendungsfall noch den geplanten Nutzen? Hat sich die Risikoklasse geändert? Passt der Vertrag noch (GUIDE-010)? Wäre ein anderer Umsetzungsweg inzwischen günstiger (GUIDE-002)? Das Generative-AI-Profil des NIST nennt ausdrücklich die Deaktivierung von Systemen, die außerhalb definierter Grenzen arbeiten, als Managementmaßnahme [9]. Ein dokumentierter „Stopp“ ist gute Governance.

Checkliste

• [ ] Systemverantwortliche(r) und Vertretung für jedes produktive KI-System benannt
• [ ] Einseitiges Betriebsblatt mit Modellversion, Datenquellen, Notausschalter
• [ ] Golden-Test-Set und Basiswert zusammen mit Prompts/Konfiguration gespeichert
• [ ] Fünf bis acht Kennzahlen definiert und monatlich berichtet
• [ ] Feedback-Knopf im Werkzeug und monatliche Stichprobe durch Key-User
• [ ] Budget-Warnungen, Kontingente, Ratenbegrenzungen, ein API-Schlüssel pro Anwendung
• [ ] Lifecycle-Benachrichtigungen des Anbieters abonniert; Versionen nach Möglichkeit festgelegt
• [ ] Änderungsprozess für Modelle mit Regressionstest und Rückfalloption
• [ ] Datenverantwortliche(r) für Wissensbasis / Trainingsdaten
• [ ] KI-Vorfall-Leitfaden in den IT-Notfallprozess integriert (DSGVO 72 h, NIS2 falls zutreffend)
• [ ] Aufbewahrung und Zugriff auf Protokolle mit Datenschutzbeauftragter/m und Betriebsrat vereinbart
• [ ] Jährliche Überprüfung mit ausdrücklicher Entscheidung weiter / ändern / stoppen

Vorlagen & Werkzeuge

• AI Act Service Desk (Kommission): konsolidierter Text von Art. 26 inkl. Digital Omnibus [4].
• BSI „Generative KI-Modelle“: Bedrohungen und Gegenmaßnahmen für Risikoanalyse und Vorfall-Leitfaden [7].
• OWASP Top 10 for LLM Applications 2025: insbesondere LLM10 Unbounded Consumption für Kostenbremsen [2].
• NIST AI 600-1 Generative AI Profile: freiwilliger Katalog von Überwachungs- und Vorfallmaßnahmen [9].
• Materialien der FinOps Foundation zu KI-Kosten und Token-Ökonomie: Stückkosten-Kennzahlen [3].
• Anbieter-Werkzeuge: Kostenbudgets und Warnungen, Nutzungs-Dashboards, Modell-Lifecycle-APIs [1]; für eigene LLM-Anwendungen LLM-Observability-Werkzeuge (Anwendungsfall CODE-018).
• Ihre IHK für NIS2-Grundlagen [6].

Typische Fehler

• „Fire and forget“ nach dem Pilot. Niemand verantwortet das System, die Qualität sinkt unbemerkt. Benennen Sie die verantwortliche Person vor dem Go-live.
• Überraschungen durch automatische Upgrades. Extraktionsfelder verschieben sich nach einem Modelltausch und niemand merkt es bis zum Monatsabschluss. Versionen festlegen, Golden Set behalten.
• Einzelpersonen überwachen. Berichte pro Person lösen Mitbestimmungskonflikte aus und zerstören Vertrauen. Messen Sie System und Team.
• Ein gemeinsamer API-Schlüssel. Kostenspitzen werden nicht mehr nachvollziehbar. Getrennte Schlüssel und Budget-Warnungen brauchen einen Tag.
• Veraltete Wissensbasis. Der Assistent zitiert die Preisliste vom Vorjahr. Datenverantwortung ist eine Betriebsaufgabe.
• Alle Protokolle ewig aufbewahren. Datenschutzrisiko und Widerstand des Betriebsrats. Legen Sie Zweck und Aufbewahrungsdauer fest.

Quellen

1. Microsoft Learn: Foundry Models lifecycle and support policy (model deprecations and retirements), Stand 2026-07-24. https://learn.microsoft.com/azure/ai-services/openai/concepts/model-retirements
2. OWASP GenAI Security Project: LLM10:2025 Unbounded Consumption. https://genai.owasp.org/llmrisk/llm102025-unbounded-consumption/
3. FinOps Foundation: Token economics, the atomic unit of AI value. https://finops.org/insights/token-economics-the-atomic-unit-of-ai-value/
4. Europäische Kommission, AI Act Service Desk: Artikel 26, Pflichten der Betreiber von Hochrisiko-KI-Systemen (konsolidierter Text Stand 27. Jul. 2026 inkl. Digital Omnibus). https://ai-act-service-desk.ec.europa.eu/en/ai-act/article-26
5. Verordnung (EU) 2016/679 (DSGVO), Art. 33 Meldung von Verletzungen des Schutzes personenbezogener Daten. https://eur-lex.europa.eu/eli/reg/2016/679/oj
6. IHK Magdeburg: NIS2, Umsetzung in Deutschland (Registrierungs- und Meldepflichten). https://www.ihk.de/magdeburg/digitalisierung/it-sicherheit/nis2-6096160
7. BSI: Generative KI-Modelle – Chancen und Risiken für Industrie und Behörden. https://www.bsi.bund.de/SharedDocs/Downloads/DE/BSI/KI/Generative_KI-Modelle.pdf
8. Datenschutzkonferenz (DSK): Pressemitteilung zur Orientierungshilfe „Künstliche Intelligenz und Datenschutz“, 6. Mai 2024. https://datenschutzkonferenz-online.de/media/pm/2024_05_06_DSK_PM_OH_KI_und_Datenschutz.pdf
9. NIST AI 600-1: Artificial Intelligence Risk Management Framework, Generative Artificial Intelligence Profile, Juli 2024. https://doi.org/10.6028/NIST.AI.600-1

Abgerufen 2026-10.