Ratgeber · Betrieb nach Go-Live

Managed AI Operations: Was nach dem Go-Live wirklich anfällt

Der Go-Live ist der Anfang, nicht das Ergebnis. In den ersten zwölf Monaten Betrieb entscheidet sich, ob eine KI-Lösung Teil des Tagesgeschäfts wird oder zur stillen Belastung. Was in dieser Zeit anfällt, ist konkret, vorhersagbar und nicht besonders dramatisch — wenn es bewusst geplant wird.

Dieser Ratgeber beschreibt, was im laufenden KI-Betrieb tatsächlich passiert, was Unternehmen vorher selten realistisch einschätzen und wo die häufigsten Stolpersteine in den ersten zwölf Monaten liegen. Aus realer DACH-Mittelstandspraxis, nicht aus dem Whitepaper.

1. Was in den ersten zwölf Monaten tatsächlich passiert

Ein realistisches Bild des Betriebs-Verlaufs, aufgeteilt in drei Phasen. Zahlen sind Bandbreiten aus DACH-KMU-Projekten, keine Garantien — sie variieren mit Use Case, Volumen und Reife der Umgebung.

Phase 1 (Monat 1–3): Justierungs-Phase

Höchster Pflegeaufwand. Eskalations-Schwellen werden in der Praxis nachjustiert. Edge Cases tauchen auf, die im Pilot nicht im Sample waren. Anwender lernen, wie sie das System nutzen, und finden Wege, es zu umgehen — was wichtige Hinweise auf Lücken liefert. Typisch: 0,3–0,5 Personentage pro Woche.

Phase 2 (Monat 4–9): Stabilisierungs-Phase

Niedrigster Pflegeaufwand. Das System läuft im definierten Bereich, KPIs sind eingespielt. Was hier passiert, ist meist ruhige Beobachtung plus gelegentliche Konfigurations-Anpassungen. Typisch: 0,1–0,3 Personentage pro Woche. Vorsicht: dies ist die Phase, in der Verantwortlichkeit am häufigsten erodiert — der Sponsor zieht sich zurück, weil „läuft ja".

Phase 3 (Monat 10–12): Erste größere Anpassungen

Drift wird messbar. Geschäftsprozesse haben sich verschoben (neue Produktlinien, neue Sprachvarianten, neue Lieferanten). Modell-Anbieter haben mindestens eine größere Version ausgerollt. Eine geplante Optimierungs-Iteration wird fällig. Typisch: 0,2–0,4 Personentage pro Woche plus ein Iterations-Pack.

2. Was Unternehmen am häufigsten unterschätzen

Vier wiederkehrende Muster aus der Mittelstandspraxis. Keine davon ist exotisch — alle vier kommen verlässlich, wenn sie nicht vorab durchdacht wurden.

Geschwindigkeit des Drifts

„Drift passiert in den ersten Wochen praktisch nicht" — falsch. Drift beginnt am Tag eins, ist aber lange unterhalb der Wahrnehmungsschwelle. Erst wenn die Eskalationsrate über mehrere Wochen steigt, wird das Problem sichtbar — und dann ist es bereits eingetreten. Frühe Messung statt späte Reaktion.

Abhängigkeit von Einzelpersonen

Nach Go-Live verschwindet die Implementierungs-Mannschaft, das Wissen bleibt informell. Wenn die Person, die den Pilot gebaut hat, in den Urlaub geht oder kündigt, bleibt eine Lücke. Dokumentation der Konfiguration, der Eval-Sets und der Eskalations-Regeln ist nicht optional — sie ist die Versicherung.

Schnittstellen-Pflege als versteckte Kosten

Das ERP wird im Quartal upgedated, die CRM-API ändert eine Version, das DMS bekommt ein neues Feld. Wenn niemand diese Updates verfolgt und vorab testet, lernt man davon im Ausfall. Schnittstellen-Pflege ist nicht KI-Pflege — aber sie kostet im KI-Kontext oft mehr Aufwand als die KI selbst.

Eskalations-Anteil als emotionaler Faktor

Selbst bei 95 Prozent Automatisierungs-Quote: die fünf Prozent Eskalationen sind die Vorgänge, die jeder sieht und über die jeder spricht. Wenn die Operations-Mannschaft nicht weiß, dass dies normal ist und in welchen Bandbreiten es bleibt, entsteht das Gefühl, das System „funktioniert nicht". Erwartungs-Management ist Teil des Betriebs.

3. Wo Systeme typischerweise wirklich brechen

Vier konkrete Ausfallmuster, die in produktiven DACH-Mittelstandsprojekten verlässlich auftreten. Wer sie erwartet, kann sie beherrschen. Wer sie nicht erwartet, erlebt sie als Eskalation.

Daten-Drift

Eingabe-Mischung verschiebt sich: neue Sprachvarianten, neue Lieferanten, neue Produktlinien, neue Anfragetypen. Modell-Qualität sinkt langsam. Gegenmittel: laufendes Monitoring der Eingangsdaten-Verteilung plus Sample-Bewertung der Outputs.

Modell-Update bricht etwas

Der Anbieter rollt eine neue Version aus, ein bestehender Prompt verliert Präzision, eine Klassifikation verschiebt sich. Gegenmittel: Eval-Set aus realen Beispielen, vor jedem Update ausgeführt, mit dokumentierter Akzeptanz-Schwelle. Rollback-Pfad zur Vorgängerversion vorab definiert.

Geschäftsprozess-Drift

Die Fachabteilung ändert eine Freigabe-Regel, eine Vorschrift kommt dazu, ein neuer Vorgangstyp soll mitlaufen — und der Workflow passt nicht mehr. Gegenmittel: quartalsweise Abgleichs-Runde mit der Fachabteilung, dokumentierte Änderungs-Anforderungen, kontrollierte Übernahme.

Schnittstellen-Bruch

ERP, CRM oder DMS bekommt ein Major-Update, eine API-Version wird deprecatet. Wenn niemand das verfolgt, fällt die Integration aus. Gegenmittel: dokumentierter Versions-Stand, Roadmap-Verbindung zum Anbieter-Update-Plan, Staging-Test vor Produktiv-Update. Mehr im ERP-Integration-Ratgeber.

4. Was ein ehrlicher Operations-Report enthalten muss

Der monatliche Operations-Report ist das Werkzeug, mit dem Geschäftsführung, IT und Fachabteilung dieselbe Faktenlage sehen. Er kann nicht durch ein Dashboard ersetzt werden — Dashboards zeigen Zustand, der Report zeigt Entwicklung und Entscheidungen. Mindest-Inhalte:

KPI-Stand mit Vergleich: Durchlaufzeit, Eskalationsrate, Fehlerquote, Volumen, ggf. Token-Kosten — alle gegen den Vormonat und gegen den Stand bei Go-Live.

Vorfälle: jede Anomalie mit Ursache, Lösung und Datum. Auch kleinere — Vollständigkeit schlägt Selektivität.

Änderungen: alle durchgeführten Modell- oder Konfigurations-Änderungen mit Datum, Begründung und Wirkung.

Anbieter-Stand: welche Modell-Versionen, welche API-Versionen, welche Hosting-Region sind aktiv produktiv im Einsatz.

Optimierungs-Backlog: priorisierte Vorschläge mit Aufwand- und Nutzen-Schätzung. Keine Wunschliste, eine Entscheidungsgrundlage.

Empfehlung: eine konkrete Aussage zum kommenden Monat — Beobachten, Anpassen, Iterieren. Keine Marketing-Sprache, keine Buzzwords.

Ein guter Operations-Report ist drei bis fünf Seiten lang. Wenn er regelmäßig fünfzehn Seiten überschreitet, wird er nicht mehr gelesen — und damit nutzlos.

Wann Managed AI Operations sinnvoll ist — und wann nicht

Sinnvoll, wenn

• Die KI-Lösung ist im operativen Tagesgeschäft eingebettet
• Es gibt keine dedizierte AI-Operations-Rolle intern
• Verarbeitete Vorgänge wirken direkt auf Kunden oder Cashflow
• Volumen liegt über etwa 100 Vorgängen pro Tag
• Mehrere KI-Anwendungen laufen parallel produktiv

Nicht sinnvoll, wenn

• Reines Experiment ohne produktive Geschäftslast
• Etablierte interne MLOps-Mannschaft mit Kapazität
• Volumen so gering, dass quartalsweise Stichprobe ausreicht
• Use Case ist tot — Eskalation an „nicht weiterführen" sinnvoller
• Pilot ist noch im Pilot-Status, nicht im Regelbetrieb

Häufige Fragen zum laufenden KI-Betrieb

Wie viel Aufwand verursacht der Betrieb einer KI-Lösung tatsächlich?

Im ersten Quartal nach Go-Live deutlich mehr als später — typischerweise zwischen 0,2 und 0,5 Personentagen pro Woche pro produktiver KI-Anwendung. Danach pendelt sich der laufende Aufwand bei stabilen Use Cases auf 0,1 bis 0,3 Personentage pro Woche ein, plus etwa einem halben Tag pro Monat für den Operations-Report und Optimierungs-Triage. Die Streuung kommt aus zwei Faktoren: Komplexität der Eingangsdaten und Häufigkeit, mit der sich Geschäftsprozesse rundherum ändern.

Wann lohnt sich Managed AI Operations und wann nicht?

Lohnt sich, wenn die KI-Lösung im operativen Tagesgeschäft eingebettet ist, intern keine dedizierte AI-Operations-Rolle existiert und Ausfälle oder schleichende Qualitätsverluste direkt Geld kosten. Lohnt sich nicht für reine Experimente ohne Geschäftslast, für hochgradig regulierte Eigenbetriebe mit etablierter MLOps-Mannschaft, oder wenn das Volumen so gering ist, dass eine quartalsweise Stichprobe ausreicht. Faustregel: ab 100 verarbeiteten Vorgängen pro Tag oder ab direkter Kundenwirkung ist die Frage nicht mehr „ob", sondern „durch wen".

Was wird im ersten Quartal nach Go-Live am häufigsten unterschätzt?

Drei Dinge: (1) Wie oft sich die Eingangsdaten verschieben — neue Lieferanten, neue Produktlinien, neue Sprachvarianten kommen schneller als erwartet. (2) Wie stark die Eskalationsrate auf operative Stimmung wirkt — fünf Prozent schwer eskalierbarer Fälle binden gefühlt die ganze Aufmerksamkeit. (3) Wie viel Pflege die Anbindungs-Schnittstellen zum ERP oder CRM in Wahrheit brauchen. Die KI selbst ist meist robust, die Umgebung ist es nicht.

Was muss in einem ehrlichen Operations-Report enthalten sein?

Mindestens: aktuelle KPIs gegenüber dem Vormonat (Durchlaufzeit, Eskalationsrate, Fehlerquote, Volumen), aufgetretene Vorfälle mit Ursache und Lösung, alle durchgeführten Modell- oder Konfigurations-Änderungen mit Datum und Begründung, aktueller Modell- und Anbieter-Stand, offenes Optimierungs-Backlog mit Aufwand- und Nutzen-Schätzung, sowie eine konkrete Empfehlung für den kommenden Monat. Was nicht reingehört: Marketing-Sprache, Buzzwords und vage „läuft super"-Sätze.

Welche typischen Fehler passieren in den ersten zwölf Monaten?

(1) Niemand benannt für laufende Verantwortung — der Pilot-Sponsor zieht sich zurück, der Operations-Owner wurde nie definiert. (2) Modell-Updates werden ungetestet übernommen, weil „der Anbieter sagt, es ist besser". (3) Eskalations-Regeln werden nicht angepasst, obwohl sich Volumen oder Mischung der Eingaben ändert. (4) Kein Rollback-Pfad dokumentiert, wenn doch etwas bricht. (5) Der Erfolg des Piloten verleitet zur Skalierung auf den nächsten Use Case, bevor der erste sauber im Regelbetrieb ist.

KI-Lösung läuft, Pflege offen?

Eine kostenlose KI-Potenzialanalyse bewertet die Operations-Lücken Ihrer produktiven KI-Systeme — und welcher Pflege-Aufwand realistisch ist, intern oder via Managed Services.

KI-Potenzialanalyse anfragen