KI-Systeme vom Pilot in den verantworteten Betrieb

Kurzantwort

Ein KI-System wechselt erst dann in den Betrieb, wenn neun Bedingungen prüfbar erfüllt sind: belegter Nutzen, besetzte Betriebsrollen, aktives Monitoring, Evaluationsrhythmus, getesteter Incident-Pfad, geklärte Berechtigungen samt Datenschutzfreigabe, informierte Beschäftigte, gesichertes Run-Budget und eine Exit-Skizze. Die Übergabe ist eine protokollierte Portfolioentscheidung mit sichtbarer Stoppalternative. Der Fachbereich übernimmt die Ergebnisqualität, die IT den technischen Dienst. Fehlt eine dieser Bedingungen, läuft kein Produktivsystem, sondern ein Dauerpilot mit Produktionsdaten.

Die Kernaussagen

• Die Engstelle liegt im Übergang, nicht in der Technik: Nur rund 5 Prozent der unternehmensspezifischen KI-Werkzeuge erreichen laut MIT NANDA (2025) die Produktion.
• Betriebsreife ist keine Gefühlsfrage. Neun Dimensionen mit je einem Nachweis-Artefakt machen die Freigabe prüfbar und delegierbar.
• Ein Pilot optimiert auf Lernen, der Betrieb auf Rechenschaft. Wer beide Phasen gleich führt, importiert Pilotschulden in den Alltag.
• Verantwortung braucht zwei Adressen: Fachbereich für die Ergebnisqualität, IT für den Dienst. Eine Sammeladresse produziert Zuständigkeitslücken.
• Modelle werden vom Anbieter abgekündigt, Prompts driften, Datenquellen ändern sich. Der Modellwechsel ist Regelbetrieb und muss vor dem Go-live geprobt sein.
• Für Hochrisiko-Systeme sind Überwachung, Aufsicht und Protokollierung ab dem 2. August 2026 Rechtspflicht des Betreibers nach Artikel 26 der Verordnung (EU) 2024/1689.

Warum die Frage jetzt zählt

Die Zahlen zum Pilotsterben sind inzwischen belastbar. Gartner prognostizierte im Juli 2024, dass mindestens 30 Prozent der GenAI-Projekte nach dem Proof of Concept aufgegeben werden, wegen schlechter Datenqualität, unzureichender Risikokontrollen, eskalierender Kosten oder unklaren Geschäftswerts. S&P Global Market Intelligence (2025) hat gemessen, was daraus wurde: 42 Prozent der befragten Unternehmen haben die Mehrheit ihrer KI-Initiativen abgebrochen, im Schnitt wurden 46 Prozent der Machbarkeitsnachweise vor der Produktion verworfen. Die MIT-Initiative NANDA (2025) fand in ihrer Untersuchung von über 300 Vorhaben, dass 95 Prozent der Organisationen keinen messbaren Ergebnisbeitrag erzielen und nur 5 Prozent der maßgeschneiderten Werkzeuge die Produktion erreichen.

Bemerkenswert ist die Begründung. Das Scheitern liegt laut MIT-Untersuchung selten an der Modellqualität. Es liegt an brüchigen Arbeitsabläufen, fehlender Einbettung in den Alltag und fehlender Lernfähigkeit der Organisation. Anders gesagt: am Betriebsmodell. Gleichzeitig setzt die Verordnung (EU) 2024/1689 dem informellen Weiterlaufen eine Frist. Ab dem 2. August 2026 gelten die Betreiberpflichten für Hochrisiko-Systeme. Wer den Übergang in den Betrieb heute nicht sauber organisiert, hat dann ein doppeltes Problem: ein unkontrolliertes System und eine dokumentierbare Pflichtverletzung.

Was „verantwortet“ im Betrieb konkret heißt

Ein Pilot darf improvisieren. Er läuft mit ausgewählten Nutzern, begrenzten Daten und der stillen Erlaubnis, Fehler zu machen. Der Betrieb kennt diese Erlaubnis nicht. Dort arbeiten Menschen mit den Ausgaben, ohne jeden Einzelfall zu hinterfragen. Verantwortung heißt deshalb: Jemand kann jederzeit drei Fragen beantworten. Wie gut ist das System heute? Wer greift ein, wenn es kippt? Wie kommen Änderungen kontrolliert hinein?

Die erste Frage verlangt Monitoring in zwei Schichten. Die technische Schicht misst Verfügbarkeit, Antwortzeiten und Kosten je Vorgang. Die fachliche Schicht misst Ergebnisqualität: Trefferquoten gegen ein Referenz-Testset, Korrekturquoten der Nutzenden, Eskalationsraten. Ein KI-System kann technisch grün und fachlich rot sein. Wer nur die erste Schicht beobachtet, betreibt einen zuverlässig verfügbaren Irrtum.

Die zweite Frage verlangt einen Eskalationspfad mit Namen und Schwellen. Wer entscheidet bei welcher Fehlerlage, dass das System gedrosselt, auf einen Notmodus gestellt oder abgeschaltet wird? Ein Degradationsmodus, etwa nur noch Suche statt generierter Antworten oder Rückfall auf manuelle Bearbeitung, gehört vorbereitet, nicht improvisiert.

Die dritte Frage verlangt einen Änderungsprozess. Modellversionen, Prompts, Datenquellen und Berechtigungen ändern sich laufend. Jede materielle Änderung braucht einen Regressionstest gegen das Referenz-Testset und eine Freigabe. Rahmenwerke wie das NIST AI Risk Management Framework (2023) fassen genau diese Fähigkeiten unter den Funktionen Govern, Map, Measure und Manage zusammen; ISO/IEC 42001 (2023) macht sie als Managementsystem zertifizierbar.

Ein KI-System ohne benannten Betriebsverantwortlichen ist kein Produktivsystem. Es ist ein Experiment mit Produktionsdaten, und die Organisation ist das Versuchsobjekt.

Die Betriebsreife-Checkliste: neun Dimensionen, neun Artefakte

Die Freigabe zum Betrieb wird prüfbar, wenn jede Dimension ein vorzeigbares Artefakt verlangt. Eine Absichtserklärung zählt nicht. Ein Dokument, ein Testprotokoll oder eine Budgetzeile zählen. Die folgende Checkliste hat sich als Gerüst bewährt; die Schwellen bleiben unternehmensspezifisch.

Dimension	Leitfrage	Nachweis-Artefakt	Owner
Nutzennachweis	Wurde die Pilot-Baseline erreicht oder der Verfehlgrund dokumentiert?	Messprotokoll gegen Exit-Kriterien	Fachbereichsleitung
Betriebsrollen	Sind Ergebnis-Owner und Service-Owner benannt und verfügbar?	Rollenbeschreibung mit Stundenkontingent	GF / CIO
Monitoring	Werden Technik- und Qualitätsmetriken laufend erhoben?	Dashboard plus Alarmschwellen	IT-Leitung
Evaluation	Existiert ein Referenz-Testset mit fester Prüf-Kadenz?	Testset plus Evaluationsplan	Fachbereich
Incident-Pfad	Ist der Vorfallweg definiert und einmal durchgespielt?	Übungsprotokoll mit Zeitmessung	IT-Leitung
Berechtigungen und Datenschutz	Sind Zugriffe minimal und die Verarbeitung freigegeben?	IAM-Review plus DSFA-Ergebnis	CISO / DSB
Beschäftigte und Mitbestimmung	Sind Betroffene informiert und Gremien eingebunden?	Kommunikations- und Schulungsnachweis	HR / Fachbereich
Run-Budget	Sind Nutzung, Personal und Evaluation im Plan verbucht?	Budgetzeile im Wirtschaftsplan	CFO
Exit und Reversibilität	Können Daten exportiert und der Dienst ersetzt werden?	Exit-Skizze mit Fristen	Einkauf / IT

Zwei Regeln machen die Checkliste wirksam. Erstens: Sie wird in einem Termin vollständig entschieden, nicht über Wochen zerredet. Jede Dimension bekommt den Status erfüllt, bewusst zurückgestellt oder blockierend. Zweitens: Die Stoppalternative steht in derselben Vorlage. Ein Gremium, das nur zwischen „jetzt live“ und „später live“ wählen darf, wird nie stoppen. Erst die dritte Option macht die anderen beiden ehrlich.

Die Checkliste hat einen Nebeneffekt, der oft mehr wert ist als die Freigabe selbst. Sie zwingt die Organisation, den Unterschied zwischen Projektende und Produktbeginn auszusprechen. Deloitte (2025) berichtet, dass über zwei Drittel der befragten Unternehmen höchstens 30 Prozent ihrer GenAI-Experimente binnen drei bis sechs Monaten voll skalieren. Die Organisation ändert sich langsamer als die Technik. Die Checkliste macht dieses Tempo sichtbar, statt es zu kaschieren.

Verantwortungsübergabe: Fachbereich, IT und die Lücke dazwischen

Der häufigste Konstruktionsfehler nach dem Go-live ist unsichtbar: Das Pilotteam löst sich auf, und niemand erbt dessen Wissen. Die Datenquellen, die Prompt-Historie, die bekannten Schwächen, alles verdunstet. Übergabe heißt deshalb zuerst Wissensübergabe: dokumentierte Systemgrenzen, bekannte Fehlermuster, offene Risiken. Wer das auslässt, lässt den Betrieb bei null anfangen, nur ohne die Freiheiten des Piloten.

Danach braucht es zwei klar getrennte Rollen. Der Ergebnis-Owner sitzt im Fachbereich. Er besitzt die Qualitätsschwellen, entscheidet über das Referenz-Testset und beurteilt, ob eine Ausgabenqualität für den Prozess noch tragbar ist. Der Service-Owner sitzt in der IT. Er verantwortet Verfügbarkeit, Berechtigungen, Kostenkontrolle und die technische Seite jeder Änderung. Beide treffen sich in einer festen Betriebsrunde, anfangs wöchentlich, später monatlich. Diese Runde ist keine Bürokratie. Sie ist der Ort, an dem fachliche und technische Signale zusammenlaufen, bevor sie zum Vorfall werden.

Zwischen Go-live und Regelbetrieb liegt sinnvollerweise eine Hypercare-Phase von vier bis acht Wochen. In dieser Zeit bleibt das Aufbauteam abrufbar, die Prüf-Kadenz ist verdichtet, und die Rückfallschwelle ist niedrig. Das klingt teuer, ist aber billiger als die Alternative. Die MIT-Untersuchung (2025) zeigt übrigens, dass mittelgroße Unternehmen den Weg vom Pilot zur vollen Einführung in rund 90 Tagen schaffen, Großunternehmen brauchen neun Monate und mehr. Kurze Wege und klare Owner sind hier ein struktureller Vorteil des Mittelstands, wenn die Rollen tatsächlich besetzt werden.

Der Mittelstand verliert seinen Geschwindigkeitsvorteil genau dann, wenn er die Übergabe wie ein Konzern zerteilt: viele Gremien, keine Owner. Zwei Namen und eine Betriebsrunde schlagen jedes Übergabehandbuch.

Modellwechsel und Änderungen: der unterschätzte Dauerlauf

Klassische Software altert in Jahren, KI-Systeme in Monaten. Anbieter kündigen Modellversionen ab, neue Versionen antworten anders auf dieselben Prompts, angebundene Datenquellen ändern Struktur und Inhalt. Ein Betrieb, der nur den Status quo bewacht, wird von jeder dieser Änderungen überrascht. Deshalb gehört zum verantworteten Betrieb ein Modellwechsel-Prozess, der vor dem Go-live einmal real geprobt wurde: neues Modell gegen das Referenz-Testset fahren, Abweichungen bewerten, Freigabe oder Ablehnung protokollieren, Nutzende bei spürbaren Änderungen informieren.

Dieselbe Logik gilt für Prompts und Datenquellen. Jede materielle Änderung ist ein Release mit Test und Freigabe. Ohne dieses Gate entstehen stille Regressionen: Das System wird schleichend schlechter, und niemand kann sagen, seit wann. Das Referenz-Testset ist dafür das zentrale Instrument. Es gehört dem Fachbereich, wird regelmäßig um echte Grenzfälle ergänzt und ist die gemeinsame Sprache zwischen Fach und IT.

Für Hochrisiko-Systeme ist dieser Dauerlauf zusätzlich Rechtspflicht. Artikel 26 der Verordnung (EU) 2024/1689 verpflichtet Betreiber, den Betrieb anhand der Betriebsanleitung zu überwachen, die Aufsicht kompetenten Personen zu übertragen und automatisch erzeugte Protokolle mindestens sechs Monate aufzubewahren. Besteht Grund zur Annahme eines Risikos im Sinne von Artikel 79, muss der Betreiber die Nutzung aussetzen und Anbieter sowie Marktüberwachungsbehörde informieren. Die Beobachtungsdaten der Betreiber fließen zudem in das Post-Market-Monitoring der Anbieter nach Artikel 72 ein. Diese Pflichten gelten ab dem 2. August 2026. Ein Betrieb, der Monitoring, Eskalation und Protokollierung ohnehin beherrscht, erfüllt sie nebenbei. Ein Dauerpilot erfüllt sie nicht, und kann das ab diesem Datum auch nicht mehr verbergen.

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

In 30 Tagen:

• Inventar aller als „produktiv“ geltenden KI-Systeme mit Stage-Zuordnung erstellen: Pilot, Übergang, Betrieb. Owner: CIO.
• Betriebsreife-Checkliste mit den neun Dimensionen als verbindliche Freigabevorlage beschließen, inklusive Option Stopp. Owner: Geschäftsführung.
• Für das wichtigste System Ergebnis-Owner und Service-Owner mit Stundenkontingent benennen. Owner: Geschäftsführung mit Fachbereichsleitung.
• KI-VO-Einstufung der laufenden Systeme prüfen: Hochrisiko ja oder nein, Transparenzpflichten ja oder nein. Owner: Legal / Compliance.

In 60 Tagen:

• Die erste Betriebsübergabe vollständig nach Checkliste entscheiden und protokollieren, inklusive bewusst zurückgestellter Punkte. Owner: Portfolio-Gremium.
• Incident-Pfad für dieses System einmal real durchspielen und Zeiten messen. Owner: IT-Leitung.
• Run-Budget für alle Betriebssysteme in die Wirtschaftsplanung aufnehmen: Nutzung, Personal, Evaluation. Owner: CFO.

In 90 Tagen:

• Einen Modellwechsel am Referenz-Testset proben und das Freigabeverfahren dokumentieren. Owner: Service-Owner mit Fachbereich.
• Hypercare der ersten Übergabe mit einem Review abschließen: Was bleibt Regelbetrieb, was war Anlaufkosten? Owner: Ergebnis-Owner.
• Dauerpiloten im Inventar entscheiden: zurück in den Pilot mit Exit-Datum, Übergabe nach Checkliste oder Stopp. Owner: Geschäftsführung.

Was Führung jetzt entscheiden muss

Häufige Fragen (FAQ)

Woran erkennen wir, dass unser produktives KI-System in Wahrheit ein Dauerpilot ist?

An drei Fehlstellen: kein Run-Budget in der Planung, kein benannter Betriebsverantwortlicher mit Entscheidungsrecht und kein getesteter Incident-Pfad. Ein viertes Signal ist weich, aber verlässlich: Qualitätsbeschwerden landen im ursprünglichen Projektteam, das offiziell längst aufgelöst ist. Wer diese Merkmale findet, betreibt ein Experiment mit Produktionsdaten. Die Korrektur ist eine Stage-Entscheidung: zurück in den Pilot mit Exit-Datum, in den Betrieb mit vollständiger Checkliste oder bewusster Stopp.

Was kostet der laufende Betrieb eines KI-Systems im Verhältnis zum Aufbau?

Der Betrieb kostet dauerhaft, der Aufbau nur einmal, und genau diese Dauerlast wird systematisch unterschätzt. Gartner (2024) nennt eskalierende Kosten als einen der vier Hauptgründe, warum GenAI-Projekte nach dem Proof of Concept aufgegeben werden, und beziffert Entwicklung und Rollout je nach Ansatz auf 5 bis 20 Millionen US-Dollar. Für den Mittelstand heißt das kleiner skaliert: Nutzungsgebühren, Evaluationszeit, Monitoring, Schulung und ein Ansprechpartner mit realen Stunden. Wer das Run-Budget nicht vor dem Go-live verbucht, bezahlt es später ungeplant.

Welche Pflichten treffen uns als Betreiber nach der KI-Verordnung, wenn das System produktiv geht?

Bei Hochrisiko-Systemen verlangt Artikel 26 der Verordnung (EU) 2024/1689 ab dem 2. August 2026: Nutzung gemäß Betriebsanleitung, menschliche Aufsicht durch kompetente Personen, Kontrolle der Eingabedaten, laufende Überwachung des Betriebs, Aufbewahrung der Protokolle für mindestens sechs Monate und Information der betroffenen Beschäftigten. Bei begründetem Risikoverdacht muss der Betreiber die Nutzung aussetzen und Anbieter sowie Marktüberwachungsbehörde informieren. Auch unterhalb der Hochrisiko-Schwelle gelten Transparenzpflichten. Die Einstufung des eigenen Systems gehört deshalb vor den Go-live, nicht danach.

Wer sollte den Betrieb verantworten: der Fachbereich oder die IT?

Beide, mit getrennten Rollen: Der Fachbereich verantwortet die fachliche Ergebnisqualität, die IT den technischen Dienst. Der Fachbereich besitzt die Qualitätsschwellen, das Referenz-Testset und die Entscheidung, wann Ausgaben nachgeprüft werden. Die IT verantwortet Verfügbarkeit, Berechtigungen, Kostenüberwachung und die technische Umsetzung von Änderungen. Ein gemeinsames Betriebs-Board mit fester Kadenz verbindet beide Sichten. Liegt alles bei der IT, wird Qualität zur Ticketnummer. Liegt alles beim Fachbereich, fehlen Incident-Routine und Plattformdisziplin.

Womit fangen wir an, wenn mehrere Piloten gleichzeitig Richtung Betrieb drängen?

Mit einem Inventar und einer einzigen Übergabe, nicht mit allen gleichzeitig. Zuerst alle Systeme mit Stage-Zuordnung erfassen: Pilot, Übergang, Betrieb. Dann das Vorhaben mit dem höchsten Nutzen- und Risikoprofil auswählen und die Betriebsreife-Checkliste vollständig durchentscheiden, inklusive der Option Stopp. Diese erste Übergabe erzeugt die Vorlagen, Rollenprofile und das Protokollmuster für alle weiteren. Parallelübergaben ohne geübtes Verfahren erzeugen dagegen drei halbe Betriebsmodelle und keinen belastbaren Präzedenzfall.

Evidenz und Grenzen

Belegt ist: die Größenordnung des Pilotsterbens (Gartner 2024; S&P Global Market Intelligence 2025; MIT NANDA 2025), die geringe Skalierungsgeschwindigkeit (Deloitte 2025) und der Inhalt der Betreiberpflichten samt Fristen (Verordnung (EU) 2024/1689, Artikel 26, 72 und 79). Die genannten Studien messen unterschiedliche Grundgesamtheiten und Definitionen von „Scheitern“; die Zahlen sind deshalb als konvergierende Indizien zu lesen, nicht als eine einzige Quote.

Redaktionelle Einschätzung ist: der Zuschnitt der neun Checklisten-Dimensionen, die Rollenteilung zwischen Ergebnis- und Service-Owner sowie die Empfehlung einer Hypercare-Phase von vier bis acht Wochen. Diese Elemente folgen etablierter Service-Transition-Praxis und den Funktionen des NIST AI RMF, sind aber keine Norm.

Dieser Artikel leistet nicht: eine Rechtsberatung zur Einstufung konkreter Systeme, branchenspezifische Qualitätsschwellen und die Detailplanung der SLA-, Evaluations- und Incident-Mechanik im laufenden Betrieb, Letztere behandelt der Folgebeitrag zum KI-Servicebetrieb.

Quellen und Methodik

1. 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
2. S&P Global Market Intelligence (2025): Voice-of-the-Enterprise-Erhebung zu KI-Projektabbrüchen (1.006 Befragte, Nordamerika und Europa); Berichterstattung u. a. CIO Dive, März 2025. https://www.ciodive.com/news/AI-project-fail-data-SPGlobal/742590/
3. MIT NANDA (2025): „The GenAI Divide: State of AI in Business 2025“, MIT Project NANDA, Juli 2025. https://mlq.ai/media/quarterly_decks/v0.1_State_of_AI_in_Business_2025_Report.pdf
4. Deloitte (2025): „The State of Generative AI in the Enterprise“, Q4-Ausgabe, Januar 2025. https://www.deloitte.com/us/en/about/press-room/state-of-generative-ai.html
5. Verordnung (EU) 2024/1689 (KI-Verordnung), insbesondere Artikel 26 (Pflichten der Betreiber von Hochrisiko-KI-Systemen), Artikel 72 (Beobachtung nach dem Inverkehrbringen) und Artikel 79; Amtsblatt der EU, 12.07.2024. https://eur-lex.europa.eu/eli/reg/2024/1689/oj
6. NIST (2023): „Artificial Intelligence Risk Management Framework (AI RMF 1.0)“, NIST AI 100-1, Januar 2023. https://www.nist.gov/itl/ai-risk-management-framework
7. ISO/IEC 42001:2023: „Information technology — Artificial intelligence — Management system“, Dezember 2023. https://www.iso.org/standard/42001

Methodik: Die Zahlenclaims dieses Beitrags wurden im Juli 2026 per Web-Recherche gegen die genannten Primär- und Sekundärquellen geprüft; nicht verifizierbare Werte wurden gestrichen und qualitativ formuliert. 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: Betriebsreife-Checkliste, Rollenmodell, Modellwechsel-Kapitel, KI-VO-Bezug, 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.