Vom Piloten in den Regelbetrieb: Wer pflegt deine KI, wenn der Berater weg ist?

Alle paar Monate landet eine bestimmte Sorte E-Mail in meinem Postfach. Absender: einer der großen KI-Anbieter. Inhalt, höflich verpackt: Das Modell, das deine Anwendung nutzt, wird abgeschaltet. Bitte stell rechtzeitig um. Ich betreibe etliche KI-Agenten in meinem eigenen Unternehmen, meine Buchhaltung sortiert ihre Belege seit September 2025 selbst, und weil meine KI-Assistentin Lea die Modelle von Anthropic und OpenAI parallel nutzt, bekomme ich diese Post gleich von beiden Seiten. Zwischen 2025 und 2026 wurden ganze Modellgenerationen in den Ruhestand geschickt. Für mich ist der Umgang damit inzwischen Routine. Beim ersten Mal saß ich vor so einer Mail und habe verstanden: Meine schönen Automatisierungen haben ein Haltbarkeitsdatum. Und es steht nicht in meinem Kalender, sondern im Kalender des Anbieters.

Genau darüber möchte ich heute schreiben. Über die Frage, die in Projektplänen fast nie auftaucht und in meinen Gesprächen mit Geschäftsführern immer öfter: Der Pilot ist gebaut, oft von einem externen Dienstleister, und er funktioniert. Wer sorgt dafür, dass das so bleibt? (Was KI-Agenten heute realistisch können und was der Betrieb in Euro kostet, sind eigene Themen für die nächsten Wochen. Heute geht es um Verantwortung, Rollen und Routine.)

Kennst du diese Situation auch:

• Der Pilot lief erfolgreich, aber offiziell zuständig für die KI ist in deinem Unternehmen: niemand?
• Nach einem Update antwortet das Tool plötzlich anders, und keiner im Haus weiß, warum?
• Der Einzige, der deine Prompts versteht, ist der externe Dienstleister, und dessen Projekt ist längst abgerechnet?

Dann geht es dir wie vielen. Die gute Nachricht: Die Lösung ist keine neue IT-Abteilung. Sie ist viel kleiner. Aber jemand muss sie beschließen. Und dieser Jemand bist du.

Warum deine KI nicht einfach weiterläuft

Klassische Software tut morgen ungefähr das, was sie heute tut. Sie veraltet auch, klar. Aber langsam und einigermaßen vorhersehbar. Eine KI-Lösung steht dagegen auf Boden, der sich bewegt. Im eigenen Betrieb und in Kundenprojekten habe ich drei Arten von Verschleiß gesehen, und keine davon kündigt sich mit einer Fehlermeldung an.

Die erste: Modelle ändern ihr Verhalten. Eine Forschergruppe aus Stanford und Berkeley hat 2023 gemessen, wie sich „dasselbe" Modell über die Zeit verhält: Zwischen März und Juni 2023 fiel die Trefferquote von GPT-4 bei einer simplen Primzahl-Aufgabe von 84 auf 51 Prozent. Die Zahlen sind historisch, und man muss sie richtig lesen: Sie belegen nicht, dass das Modell „dümmer" wurde, sondern dass es drei Monate später substanziell anders antwortete. Die unbequeme Nachricht: Der Workflow wirft keinen Fehler. Er antwortet nur anders. Und der Mechanismus ist aktuell: Zum GPT-5-Start im August 2025 tauschte OpenAI über Nacht die Modelle in ChatGPT aus. Der Nutzerprotest war so heftig, dass GPT-4o binnen Tagen zurückkam. Wenn selbst der größte Anbieter die Wirkung eines Modellwechsels unterschätzt, solltest du ihn nicht unvorbereitet erleben.

Die zweite: Modelle werden abgeschaltet. Das ist kein Skandal, sondern normaler Produktlebenszyklus, aber einer mit sportlichem Takt. Anthropic gibt nach eigener Dokumentation mindestens 60 Tage Vorlauf, bevor ein öffentlich verfügbares Modell in Rente geht; OpenAI nennt rund sechs Monate für reguläre Modelle. Preview-Modelle können auch nach zwei Wochen verschwinden. Und das ist keine Theorie: Claude 3 Opus wurde im Januar 2026 abgeschaltet, Claude Haiku 3 im April 2026, und zum 23. Oktober 2026 hat OpenAI die Abschaltung je einer GPT-4- und GPT-4o-Version angekündigt. Läuft deine Lösung auf einem fest eingestellten Modell, tickt gerade eine dieser Fristen. Zur Orientierung:

Die dritte Verschleißart hat mit den Anbietern gar nichts zu tun: Dein Unternehmen dreht sich weiter. Der Prompt, der deine Anfragen kategorisiert, kennt die Produktlinie nicht, die du im Frühjahr eingeführt hast. Der Workflow eskaliert an einen Kollegen, der die Abteilung längst gewechselt hat. Das ist der leiseste Verschleiß von allen, und nach meiner Beobachtung aus Workshops und Erstgesprächen der häufigste. Für die eigene Organisation verschickt eben niemand eine Deprecation-Mail.

Der Pilot ist nicht die Ziellinie

Wie groß das Problem ist, zeigt eine Zahl, die ich lange unterschätzt habe: In einer Befragung von S&P Global Market Intelligence unter gut tausend IT- und Fachverantwortlichen (publiziert im März 2025) verwarf die durchschnittliche Organisation 46 Prozent ihrer KI-Proof-of-Concepts, bevor sie produktiv gingen, und der Anteil der Unternehmen, die die Mehrheit ihrer KI-Initiativen abbrechen, stieg von 17 auf 42 Prozent. Man kann das als „KI funktioniert nicht" lesen. Ich lese es anders: Der Pilot ist nicht die Ziellinie. Der Übergang in den Betrieb ist die eigentliche Prüfung. Und auf die bereitet sich kaum jemand vor.

Dazu passt der Blick nach Deutschland: 36 Prozent der Unternehmen ab 20 Beschäftigten setzen laut Bitkom 2025 KI ein, im Jahr davor waren es 20 Prozent. Und die Hürden, die dieselbe Befragung misst, sind keine Einführungshürden: fehlendes Know-how (53 Prozent), mangelnde Personalressourcen (51 Prozent). Das sind Betriebshürden. Die Frage ist immer seltener, ob KI ins Unternehmen kommt, und immer öfter, wer sie dort am Leben hält.

Die Konzern-Antwort darauf heißt MLOps: eigene Teams, eigene Tool-Landschaft, eigene Stellenprofile. Für ein Unternehmen mit 50 bis 500 Mitarbeitern ist das die falsche Referenz. Was du brauchst, passt in einen Teilzeit-Zeitanteil, wenn du es organisierst. Ich nenne es KI-Ops light.

KI-Ops light: ein Kümmerer, eine Monatsroutine, dokumentierte Prompts

Der erste Baustein ist eine benannte Person: der Kümmerer. Kein Team, keine neue Stelle, sondern eine Person, die offiziell zuständig ist. Drei Kriterien halte ich für entscheidend: nah am Fachprozess (wer die Belege kennt, merkt, wenn die Kategorisierung kippt), technisches Grundverständnis (kein Informatikstudium: die Bereitschaft reicht, eine API-Abrechnung und ein Log zu lesen) und ein offiziell freigegebenes Zeitbudget. Am letzten Punkt scheitert es am ehesten: Zuständigkeit ohne Zeit ist keine Zuständigkeit, sondern ein schlechtes Gewissen mit Jobtitel. Genau hier liegt deine Aufgabe als Geschäftsführer: Du musst weder Prompts schreiben noch Logs lesen. Du musst eine Rolle benennen und Zeit freigeben. Das ist die ganze Entscheidung. Sie ist organisatorisch, nicht technisch.

Der zweite Baustein ist eine Monatsroutine. Bei mir sieht sie so aus: Stichproben aus den Outputs gegenlesen (eine Handvoll echter Ergebnisse reicht), ein Blick auf die API-Abrechnung (Kostensprünge sind ein frühes Warnsignal), die Ankündigungen der Anbieter überfliegen (welche Modelle werden abgekündigt?) und kurz notieren, was auffällig war. Meine Agenten, die selbstständig auf meinen Hetzner-Servern arbeiten, schaue ich mir zusätzlich wöchentlich an: beobachten, nachjustieren, Logs lesen. Als Erfahrungswert aus meinem eigenen Betrieb, ausdrücklich kein Benchmark: Das ist eine Sache von Stunden pro Monat, nicht von Tagen. Deutlich weniger, als die Systeme mir einsparen, aber eben nicht null. Wer mit null kalkuliert, plant falsch.

Der dritte Baustein: Prompts, die wie Code behandelt werden. In deinen Prompts steckt inzwischen echtes Firmenwissen: wie dein Unternehmen formuliert, was es priorisiert, welche Regeln gelten. Und trotzdem liegen sie in vielen Projekten „irgendwo im Tool", zuletzt geändert von jemandem, der sich nicht mehr erinnert, warum. Die Lösung ist unspektakulär: ein fester Ablageort, eine Versionierung (und sei es eine Datei-Konvention mit Datum) und zu jeder Änderung zwei Zeilen dazu, was geändert wurde und warum. Das ist keine Bürokratie. Das ist der Unterschied zwischen „wir können jederzeit zurück" und „wir wissen nicht mal, was vorher da stand".

Das Herzstück: kein Modellwechsel ohne Test-Set

Wenn du dir aus diesem Artikel nur einen Satz merkst, dann bitte diesen: Kein Modellwechsel ohne Test-Set. Zehn echte Fälle, deren richtiges Ergebnis du kennst – erst durchlaufen lassen, dann umstellen.

Das Prinzip ist bewusst schlicht: zehn echte Fälle aus deinem Betrieb (echte Belege, echte Kundenanfragen, echte Dokumente), und zu jedem hältst du fest, was das richtige Ergebnis ist. Steht ein Modellwechsel an, lässt dein Kümmerer diese zehn Fälle einmal gegen das neue Modell laufen, vergleicht mit dem Soll und schaut sich jede Abweichung an. Erst dann wird umgestellt. Bewusst zehn Fälle und nicht hundert: Das Ganze muss an einem Vormittag durchführbar sein, sonst macht es niemand.

Warum reicht Bauchgefühl nicht? Weil Drift subtil ist. Die Stanford-Messung von oben zeigt, wie sich Antwortverhalten verschiebt, ohne dass irgendetwas kaputt aussieht. „Fühlt sich gleich an" ist keine Prüfung. Und die Fristen der Anbieter geben den Takt vor: In einem 60-Tage-Fenster willst du nicht erst überlegen, wie du Qualität überhaupt vergleichst. Ich empfehle hier nichts Exotisches: Anthropic selbst rät in seiner Deprecation-Dokumentation, Anwendungen „well before the retirement date" mit dem Nachfolgemodell zu testen. Das Test-Set ist die Mittelstands-Version dieses Rats: ohne Eval-Framework, ohne Data-Science-Team.

Was das im Alltag ausmacht, zeigt der direkte Vergleich:

So baust du das Test-Set an einem Nachmittag

Nimm den häufigsten Fall, das Brot-und-Butter-Geschäft des Workflows. Dazu den kniffligsten Fall: einen, bei dem sich auch Menschen nicht sofort einig wären. Dann den Fall, bei dem ein Fehler am teuersten würde. Und zum Schluss zwei, drei Randfälle, die schon einmal schiefgegangen sind. Zusammen sind das deine zehn.

Zu jedem Fall gehört ein festgehaltenes Soll-Ergebnis, nicht „sollte passen", sondern konkret: Diese Rechnung gehört in diese Kategorie, diese Anfrage bekommt sinngemäß diese Antwort. Und das Ganze liegt neben den Prompts, am selben Ablageort. Griffbereit auch dann noch, wenn dein Kümmerer beim nächsten Wechsel ein anderer ist.

Eine ehrliche Grenze gehört dazu: Ein Test-Set mit zehn Fällen beweist keine Perfektion und wird nicht jede Regression fangen. Aber es fängt die groben, und es verwandelt „irgendwie antwortet das Ding komisch" in „Fall sieben kippt, schau dir Fall sieben an". Das ist der Unterschied zwischen Raten und Prüfen.

Die Übergabe: was du von deinem Berater einfordern solltest (auch von mir)

Jetzt kommt der Teil, in dem ich gegen mein eigenes Geschäftsmodell schreibe. (Mein Vertrieb möge mir verzeihen. Moment, mein Vertrieb bin ich.)

In Workshops und Erstgesprächen begegnen mir immer wieder verwaiste Projekte: Der Pilot wurde von einem Dienstleister gebaut, lief ordentlich, wurde abgenommen. Und dann kam das Schweigen. Kein Ansprechpartner, keine Dokumentation, und manchmal weiß im Haus niemand, auf wen API-Schlüssel und Konten eigentlich laufen.

Deshalb mein Rat: Fordere bei Projektende ein Übergabe-Paket ein. Für mich gehören fünf Dinge hinein:

1. Dokumentierte Prompts und Workflows: versioniert, mit Änderungshistorie, an einem Ort, auf den du Zugriff hast.
2. Ein Zugänge- und Konten-Inventar: welche Accounts, welche API-Schlüssel, und vor allem: auf wen laufen sie? Laufen sie auf den Dienstleister, gehört die Migration auf deine eigenen Konten in die Übergabe.
3. Das Test-Set mit Soll-Ergebnissen: einsatzbereit für den nächsten Modellwechsel.
4. Ein benannter, eingewiesener Kümmerer: die Einweisung ist Teil des Projekts, nicht dein Problem danach.
5. Ein Eskalationsweg für den Ernstfall: wen ruft der Kümmerer an, wenn es klemmt, und zu welchen Konditionen?

Genau das übergebe ich bei meinen Projekten, nicht aus Selbstlosigkeit, sondern weil ich möchte, dass es ohne mich läuft. Vertrauen ist das bessere Geschäftsmodell als Abhängigkeit. Im Umkehrschluss: Wenn dein Dienstleister bei diesen fünf Punkten ausweicht, ist das ein Warnsignal.

Das heißt nicht, dass du die Pflege zwingend selbst stemmen musst. Manche Unternehmen geben sie bewusst extern ab. Das ist völlig legitim, wir bieten das nach unseren Projekten ebenfalls an. Der Unterschied liegt im Wort „bewusst": Eine klare Wartungsvereinbarung mit definierten Aufgaben ist eine Entscheidung. Schweigen nach Projektende ist keine.

Regelbetrieb ist eine Routine, kein Projekt

Fassen wir zusammen: KI-Lösungen verschleißen im Betrieb, weil sich der Boden unter ihnen bewegt: Modelle ändern sich, werden abgeschaltet, und dein Unternehmen dreht sich weiter. Deine Entscheidung als Geschäftsführer ist nicht technisch, sondern organisatorisch: eine Rolle benennen, Zeit freigeben, bei Projektende die Übergabe einfordern. Und der eine Satz für den Notizzettel: Kein Modellwechsel ohne Test-Set.

Auch deshalb endet unser Vorgehensmodell nicht mit dem Piloten, sondern mit der Frage, wie es danach weiterläuft. In unseren KI-Workshops bauen wir mit deinem Team genau diese Kümmerer-Rolle auf: Monatsroutine, Test-Set, Prompt-Dokumentation, damit der Betrieb bei dir im Haus liegt und nicht bei uns.

Und falls du gerade auf ein verwaistes Projekt schaust (Pilot gebaut, Berater weg, seit dem letzten Update spinnt es): Damit bist du nicht allein, und peinlich ist es auch nicht. Sprich mich an, schreib mir eine E-Mail oder ruf einfach an. Wir schauen gemeinsam, was da läuft, was es braucht und wer es künftig pflegt. Wenn die Antwort am Ende „ein Kümmerer, eine Monatsroutine und ein Test-Set" lautet, dann ist das eben die Antwort. Es muss nicht immer ein Folgeprojekt sein.