Der Pilot lief. Jetzt beginnt die Arbeit.

/01Pilot und Betrieb: Begriff und Abgrenzung

Ein Pilot beantwortet eine Frage: Kann ein Modell diese Aufgabe in unserer Umgebung mit unseren Daten gut genug lösen? Er läuft mit einer Handvoll Nutzern, oft auf einem Rechner in der IT, mit einem Modell, das jemand aus Interesse ausgewählt hat, und mit Daten, die jemand von Hand hineinkopiert hat. Sein Ergebnis ist ein Urteil — ja, nein, nur mit Einschränkungen — und eine Zahl, die man vorher nicht hatte: wie oft die Antwort stimmt, wie lange sie dauert, was sie kostet.

Ein Betrieb beantwortet eine andere Frage: Wer sorgt dafür, dass dieser Dienst ab Montag für alle läuft, auch wenn der Kollege im Urlaub ist, das Modell ein Update bekommt und die Fachabteilung ihn plötzlich für etwas anderes benutzt? Der Betrieb hat einen Verantwortlichen, eine Vertretung, ein Monitoring, eine Sicherung, einen Versionsstand und einen Eintrag im Inventar. Das ist nichts KI-Spezifisches — es ist das, was jeder Dienst im Haus hat, vom Mailserver bis zum ERP. Neu ist nur, dass ein KI-Pilot so leicht entsteht, dass niemand merkt, wann er zum Dienst geworden ist.

Was dieser Artikel nicht ist: kein Fahrplan für den Pilot selbst — den gibt es in Vom Prototyp in Produktion: Der 90-Tage-Fahrplan — und keine Rechtsberatung. Er handelt von der Lücke dazwischen: dem Moment, in dem ein Pilot ein Dienst wird, ohne dass es jemand beschlossen hat.

/02Warum Piloten hängen bleiben

Aus den Projekten, die wir übernommen haben, kennen wir drei Muster — als Beobachtung, nicht als Statistik. Das erste: Der Pilot ist längst produktiv. Die Fachabteilung hat ihn in ihren Alltag eingebaut, die IT weiß es nicht, und der Rechner, auf dem er läuft, hat keine Sicherung. Der Übergang hat stattgefunden, nur ohne die Fragen. Das zweite: Der Pilot ist erfolgreich und bleibt Pilot, weil niemand die Kosten für den Betrieb tragen will — das Budget war für ein Experiment, nicht für einen Dienst. Das dritte: Der Pilot wird produktiv gesetzt, wie er ist, und fällt beim ersten Modellupdate, beim ersten Urlaub oder bei der ersten Anfrage aus einer anderen Abteilung.

Allen drei Mustern ist gemeinsam, dass die Betriebsfragen nie gestellt wurden. Nicht, weil sie schwer wären, sondern weil ein Pilot kein Betriebsprojekt ist und niemand den Moment definiert hat, an dem es eines wird. Der Moment ist definierbar: Sobald jemand außerhalb des Pilotteams sich auf das Ergebnis verlässt, ist es ein Dienst. Ab da gelten die fünf Fragen.

/03Frage 1: Wer ist zuständig — und wer vertritt?

Die erste Frage ist die einfachste und die, die am seltensten beantwortet wird. Ein KI-Dienst braucht einen Verantwortlichen mit Namen, eine Vertretung und eine Eskalation. Der Verantwortliche ist nicht der, der den Pilot gebaut hat — der ist oft ein Fachanwender mit Interesse, kein Betreiber. Der Verantwortliche ist die Person, die entscheidet, wann der Dienst abgeschaltet wird, welches Modell läuft und wer Zugriff hat. In einem Betrieb mit einer IT von drei bis zehn Köpfen ist das in der Regel die IT-Leitung, mit einem Fachverantwortlichen aus der Abteilung, die den Dienst nutzt, als zweiter Rolle.

Die Vertretung ist der Punkt, an dem die meisten Piloten scheitern. Ein Dienst, den nur eine Person versteht, ist ein Dienst, der im Urlaub dieser Person ausfällt oder — schlimmer — weiterläuft, ohne dass jemand eingreifen kann. Die Vertretung braucht kein zweiter Experte zu sein; sie braucht das Runbook: wie man den Dienst neu startet, wie man ihn abschaltet, wen man anruft. Wer kein Runbook schreiben kann, hat den Dienst nicht verstanden.

Die Eskalation ist die Antwort auf die Frage, wer entscheidet, wenn der Dienst falsche Ergebnisse liefert und die Fachabteilung ihn trotzdem braucht. Das ist keine technische Frage; sie gehört in die Geschäftsführung, bevor der Fall eintritt.

/04Frage 2: Was passiert nachts — Monitoring, Ausfall, Wiederanlauf

Ein Pilot fällt aus, und jemand merkt es am nächsten Morgen. Ein Dienst fällt aus, und das Monitoring merkt es in Minuten. Der Unterschied ist nicht die Technik — Prometheus und Grafana laufen in den meisten Häusern ohnehin —, sondern die Frage, was gemessen wird. Ein KI-Dienst braucht vier Messgrößen, die ein klassischer Dienst nicht hat:

• Verfügbarkeit des Modells. Antwortet der Inferenzserver, und wie lange dauert die erste Antwort? Bei einem lokalen vLLM sind das die Metriken des Servers; bei einer API ist es ein regelmäßiger Testaufruf.
• Fehlerrate der Aufgaben. Wie viele Anfragen enden ohne brauchbare Antwort, mit Zeitüberschreitung oder mit einer Ablehnung? Ein Anstieg ist das erste Zeichen dafür, dass sich das Modell, die Daten oder das Nutzungsverhalten geändert haben.
• Kosten und Auslastung. Token je Tag, Anfragen je Nutzer, GPU-Auslastung. Ein Dienst, der über Nacht das Dreifache verbraucht, hat entweder einen neuen Nutzerkreis oder ein Problem.
• Warteschlange. Bei Agenten, die Aufgaben abarbeiten: Wie viele warten, wie alt ist die älteste? Das ist die Messgröße, die die Fachabteilung spürt.

Dazu kommen die klassischen Fragen: Wie schnell muss der Dienst nach einem Ausfall wieder da sein, und wie viel darf verloren gehen? Ein RTO und RPO für einen KI-Dienst klingt übertrieben, bis der Server mit der Vektordatenbank ausfällt und niemand weiß, ob die Wissensbasis von letzter Woche noch irgendwo liegt. Bereitschaft außerhalb der Arbeitszeit braucht der Dienst, wenn Kunden ihn nutzen oder Agenten nachts Aufgaben abarbeiten; ein interner Assistent für Bürozeiten kommt ohne aus — aber dann muss das jemand entschieden haben.

/05Frage 3: Wie wird gemessen — Qualität, Kosten, Nutzung

Der Pilot hat eine Zahl geliefert: In soundso vielen Fällen war die Antwort brauchbar. Der Betrieb muss diese Zahl jede Woche neu liefern können, sonst merkt niemand, wenn sie fällt. Das Werkzeug dafür ist ein Evaluationssatz: fünfzig bis zweihundert echte Aufgaben mit bekannter richtiger Antwort, die nach jeder Änderung — Modell, Prompt, Wissensbasis — automatisch durchlaufen werden. Ein Ergebnis sieht dann so aus:

$ python3 eval.py --satz support-v3.jsonl --modell gpt-oss-120b@2026-09
Aufgaben:          180
korrekt:           163   (90,6 %)
teilweise:          11   ( 6,1 %)
falsch:              6   ( 3,3 %)
abgelehnt:           0
Antwortzeit p50:   1,8 s   p95: 4,1 s
Token je Aufgabe:  2.140 (Eingabe) / 310 (Ausgabe)
Vergleich zu v2:   korrekt +2,2 Pp, p95 +0,6 s

Die Zahlen in diesem Beispiel sind erfunden; die Struktur ist das, was zählt. Ohne einen solchen Satz ist jede Aussage über die Qualität eines KI-Dienstes ein Gefühl. Mit ihm ist der Modellwechsel eine Messung statt einer Diskussion. Wer den Satz im Pilot aufbaut — aus den Fällen, die die Fachabteilung ohnehin geprüft hat —, hat den größten Teil der Betriebsmessung schon, bevor der Betrieb beginnt.

Die zweite Messgröße sind Kosten je erfolgreicher Aufgabe: nicht Token je Anfrage, sondern was eine erledigte Rechnung, ein beantwortetes Ticket, ein zusammengefasstes Protokoll kostet — inklusive der Fälle, die der Agent abgebrochen hat und ein Mensch nachgearbeitet hat. Wie diese Rechnung aufgebaut ist, steht in Kosten je erfolgreichem Task. Die dritte ist die Nutzung: Wer verwendet den Dienst wofür? Ein Assistent, der für Protokolle gebaut wurde und plötzlich Bewerbungen sichtet, hat seinen Zweck geändert — und damit möglicherweise seine Risikoklasse.

/06Frage 4: Was passiert beim Modellwechsel?

Modelle wechseln. Ein API-Anbieter stellt eine Version ein, ein Open-Weight-Modell bekommt einen Nachfolger, die Quantisierung wird geändert, weil die Karte zu klein ist. Ein Pilot ist an ein Modell gebunden; ein Dienst muss den Wechsel überstehen. Dafür braucht er vier Dinge, die zusammen das sind, was unter LLMOps läuft:

• Versionsstand. Modell, Quantisierung, Systemprompt, Wissensbasis und Oberfläche haben je eine Version, und die Kombination, die läuft, ist festgehalten. Ein Fehler, der nach einer Änderung auftritt, ist sonst nicht zuzuordnen.
• Regressionstest. Der Evaluationssatz aus Frage 3 läuft gegen das neue Modell, bevor es produktiv geht. Fällt die Trefferquote, bleibt das alte Modell — solange es verfügbar ist.
• Parallelbetrieb. Neues und altes Modell laufen für einen Teil der Anfragen nebeneinander; die Ergebnisse werden verglichen. Bei einem lokalen Modell ist das eine zweite Instanz; bei einer API ein zweiter Schlüssel.
• Rückweg. Ein Wechsel, der sich nicht in einer Stunde zurücknehmen lässt, ist kein Wechsel, sondern ein Sprung. Bei lokalen Modellen heißt das: Die alte Modelldatei bleibt liegen. Bei APIs heißt es: Die alte Version muss noch erreichbar sein — was der Anbieter entscheidet, nicht Sie.

Der letzte Punkt ist der Grund, warum viele Betriebe mit vertraulichen Daten am Ende ein Modell unter eigener Kontrolle betreiben: nicht wegen der Datenklasse allein, sondern weil der Modellwechsel dann ihre Entscheidung ist und nicht die eines Anbieters, der eine Version zum Monatsende abschaltet. Was das für Hardware und Rechnung heißt, steht in On-Premise KI mit vLLM, Qwen3 und GPT-OSS.

/07Frage 5: Wer weist was nach — Rollen, Pflichten, Protokolle

Ein Pilot hat keine Pflichten, die jemand prüft. Ein Dienst hat sie — und die Nachweise dafür entstehen im Betrieb oder gar nicht. Die Liste ist für einen Assistenten oder Agenten im Mittelstand überschaubar, wenn sie von Anfang an geführt wird:

Die letzten drei Zeilen gelten in voller Schärfe nur für Hochrisiko-Systeme nach Anhang III, für die die Pflichten nach dem Digital Omnibus ab dem 2. Dezember 2027 gelten — im Mittelstand vor allem alles, was Bewerbungen, Beschäftigte oder Kreditwürdigkeit bewertet. Für alle anderen Dienste sind Versionsstand und Evaluation trotzdem Pflicht: nicht rechtlich, sondern weil ohne sie Frage 3 und 4 nicht beantwortbar sind. Welche Pflichten seit dem Omnibus für welche Systeme gelten, steht in Welche KI-Pflichten trotz Verschiebung gelten.

/08Die Betriebsakte: was aus den fünf Antworten entsteht

Die fünf Antworten ergeben zusammen ein Dokument, das wir Betriebsakte nennen — nicht, weil der Name wichtig wäre, sondern weil es an einem Ort liegen muss. Es ist kurz. Für einen internen Assistenten mit Wissensbasis sind es acht Abschnitte auf drei bis fünf Seiten:

• Zweck und Grenzen. Was der Dienst tut, für wen, und was er ausdrücklich nicht tut. Die zweite Hälfte ist die wichtigere: Sie ist die Grundlage dafür, eine Zweckänderung zu erkennen.
• Rollen. Verantwortlicher, Vertretung, Fachverantwortlicher, Eskalation. Mit Namen.
• Architektur und Versionsstand. Modell, Betriebsform, Wissensbasis, Oberfläche, Schnittstellen. Wo die Sicherung liegt.
• Runbook. Start, Stopp, Neustart, Wiederherstellung, Modellwechsel, Rückweg. Jeder Schritt als Befehl, nicht als Beschreibung.
• Monitoring und Bereitschaft. Welche Metriken, welche Schwellen, wer alarmiert wird, wann.
• Messung. Evaluationssatz, Turnus, Kennzahlen, Schwelle, unter der der Dienst gestoppt wird.
• Nachweise. Die Tabelle aus Frage 5 mit Ablageort je Zeile.
• Kosten. Was der Dienst im Monat kostet — Hardware oder Token, Betrieb, Personal — und wer das Budget trägt.

Was in der Akte fehlt, ist der Pilotbericht. Der beantwortet die Frage, ob das Modell die Aufgabe kann; die Akte beantwortet die Frage, wie der Dienst läuft. Beide Dokumente haben unterschiedliche Leser, und wer sie zusammenlegt, bekommt eines, das niemand liest.

/09Wo es hakt: Grenzen und Fallstricke

Der Pilot lief mit Produktivdaten ohne Vertrag. Kundendaten gingen im Pilot an eine API, weil es schnell gehen sollte, und ein Auftragsverarbeitungsvertrag wurde nie geschlossen. Der Übergang in den Betrieb ist der Moment, das nachzuholen — oder das Modell zu wechseln. Ein Dienst, der mit einem Datenschutzverstoß beginnt, bleibt einer.

Die Fachabteilung ist Betreiber ohne IT. Ein Pilot, den die Abteilung selbst mit einem Werkzeug aus dem Internet gebaut hat, hat keinen Verantwortlichen in der IT — und die IT erfährt davon, wenn er ausfällt. Die Lösung ist keine Verbotsliste, sondern eine Freigabestelle, bei der ein Pilot angemeldet wird, bevor er Produktivdaten sieht.

Der Modellanbieter ändert das Modell unter derselben Bezeichnung. Die Trefferquote fällt, und niemand hat etwas geändert. Ohne Evaluationssatz ist das nicht nachweisbar; ohne Versionsstand nicht zuzuordnen. Bei APIs hilft nur, die Version festzupinnen, wo der Anbieter das zulässt, und den Evaluationssatz täglich laufen zu lassen.

Die Kosten laufen mit dem Erfolg. Ein Dienst, der gut funktioniert, wird mehr genutzt, und bei tokenbasierter Abrechnung steigt die Rechnung mit dem Nutzen. Das ist kein Fehler, aber es muss jemand budgetieren. Ein lokales Modell hat das Problem nicht — es hat dafür Kapital gebunden, das im Pilot nicht nötig war.

Der Agent bekommt Rechte, die der Pilot nicht hatte. Im Pilot las der Agent aus einer Kopie; im Betrieb schreibt er ins ERP. Damit ändert sich die Frage nach Identität und Rechten des Agenten grundsätzlich: eigene Identität, minimale Rechte, Freigabe vor Handlungen mit Folgen. Ein Agent mit dem Konto seines Erbauers ist im Betrieb nicht tragbar.

Der Pilot war zu gut. Die Fachabteilung hat im Pilot die einfachen Fälle geprüft, weil die schweren Zeit kosten. Der Betrieb sieht alle. Ein Evaluationssatz, der die schweren Fälle enthält, ist unbequem — und der einzige, der die Frage beantwortet, ob der Dienst den Betrieb überlebt.

/10Die Entscheidung: selbst betreiben, betreiben lassen oder abschalten

Selbst betreiben ist richtig, wenn die IT die fünf Fragen mit Namen, Runbook und Monitoring beantworten kann und die Bereitschaft organisiert ist. In einer IT mit fünf und mehr Köpfen, die ohnehin Virtualisierung, Monitoring und Sicherung betreibt, ist ein KI-Dienst ein weiterer Dienst — mit einem Evaluationssatz als einziger neuer Disziplin.

Betreiben lassen ist richtig, wenn die fünf Fragen beantwortet sind, aber niemand im Haus die Antworten tragen kann: keine Bereitschaft, keine Vertretung, kein Werkzeug für Evaluation. Bei uns beginnt die Betriebsübernahme eines bestehenden Stacks bei 690 Euro im Monat, der komplette Stack mit Modell, Plattform und Betrieb bei 1.490 Euro, und hochverfügbarer Betrieb mit Governance-Dokumentation bei 3.900 Euro; GPU-Hardware wird getrennt gemietet oder gekauft. Was Sie behalten, ist die Fachverantwortung und die Entscheidung über Modell und Zweck; was Sie abgeben, ist der Nachtbetrieb.

Abschalten ist richtig, wenn Frage 3 keine Antwort hat — der Nutzen lässt sich nicht messen — oder Frage 1 keine: Niemand will Verantwortlicher sein. Beides ist keine Niederlage; es ist das Ergebnis, für das ein Pilot da ist. Ein abgeschalteter Pilot kostet nichts. Ein Pilot, der als Dienst läuft, ohne dass jemand dafür geradesteht, kostet beim ersten Vorfall mehr als der ganze Betrieb.

Was nicht zur Wahl steht: den Pilot laufen zu lassen und die Fragen später zu beantworten. Später ist, wenn der Rechner ausfällt.

/11Häufige Fragen