KI-Prototypen gehen selten live, weil eine Demo nur zeigt, dass etwas möglich ist, und nicht, dass es jeden Tag mit echten Daten, echten Nutzern und echten Rechten funktioniert. Zwischen Demo und Betrieb liegen fünf Lücken: Daten, Rechte, Tests, Betrieb und Verantwortung, und wer sie von Anfang an mitplant, bringt seinen KI-Pilot auch in Produktion.

Das Muster kennen viele: Nach zwei Wochen steht ein beeindruckender Chat. Er beantwortet Fragen zu ein paar hochgeladenen PDFs, die Geschäftsführung ist begeistert, alle wollen ihn haben. Ein halbes Jahr später nutzt ihn niemand. Nicht weil das Sprachmodell schlecht war, sondern weil der Weg vom Prototyp in die Produktion ein anderes Projekt ist als der Prototyp selbst. In diesem Beitrag geht es darum, was zwischen Demo und Betrieb fehlt, woran du einen Prototyp erkennst, der live gehen kann, was „produktiv“ konkret heißt und wer sich danach kümmert.

Die fünf Lücken zwischen Demo und Betrieb (Daten, Rechte, Tests, Betrieb, Verantwortung)

Ein Prototyp darf Abkürzungen nehmen. Das ist sein Zweck: schnell zeigen, ob eine Idee trägt. Das Problem entsteht, wenn niemand aufschreibt, welche Abkürzungen es waren. Fast immer sind es dieselben fünf.

1. Daten. In der Demo liegen zehn ausgewählte Dokumente, sauber und aktuell. Im Alltag sind es Tausende, verteilt auf Wiki, Laufwerk und Postfach, teils veraltet, teils doppelt, teils hinter einem Login. Dazu ändern sie sich jeden Tag. Ein System, das nur einmal von Hand befüllt wurde, antwortet nach drei Monaten mit dem Stand von vor drei Monaten.

2. Rechte. In der Demo sieht jeder alles. Im Unternehmen darf die Buchhaltung andere Dokumente sehen als der Vertrieb, und Personalakten sieht fast niemand. Ein KI-Assistent muss diese Rechte übernehmen, sonst plaudert er aus, was der Fragende nie hätte lesen dürfen. Das lässt sich nicht am Ende dranbauen. Es entscheidet mit, wie die Daten eingelesen und gespeichert werden.

3. Tests. Die Demo wird mit Fragen vorgeführt, von denen man weiß, dass sie gut funktionieren. Im Betrieb kommen Fragen, an die niemand gedacht hat. Ohne eine feste Sammlung echter Fälle mit erwarteten Ergebnissen, ein Testset, weiß niemand, wie gut das System wirklich ist. Und niemand merkt, wenn eine Änderung es schlechter macht. Sprachmodelle antworten nie ganz gleich. Wie man trotzdem verlässliche Ergebnisse bekommt, steht im Beitrag über Determinismus in KI-Agenten.

4. Betrieb. Die Demo läuft auf einem Laptop oder in einem Notebook. Produktion heißt: ein Server, Updates, Backups, Protokolle, Kostenkontrolle. Und die Modelle selbst ändern sich. Anbieter schalten ältere Modelle ab. Bei Anthropic zum Beispiel schlagen Anfragen an ein abgeschaltetes Modell fehl, angekündigt wird das für öffentlich verfügbare Modelle mindestens 60 Tage vorher (Anthropic, Model deprecations, Stand: Oktober 2026). Der Anbieter empfiehlt selbst, die eigene Anwendung rechtzeitig mit dem Nachfolger zu testen. Ein System ohne Testset und ohne jemanden, der das tut, hört an einem bestimmten Tag einfach auf zu funktionieren.

5. Verantwortung. Den Prototyp hat jemand gebaut, der Lust darauf hatte. Wer ihn betreibt, wenn ein Nutzer sich über eine falsche Antwort beschwert, wenn die Kosten steigen oder wenn der Entwickler das Unternehmen verlässt, hat niemand festgelegt. Diese Lücke ist die häufigste und die unsichtbarste.

So sieht der Unterschied im Überblick aus:

Lücke In der Demo Im Betrieb
Daten Zehn ausgewählte Dokumente, einmal hochgeladen Alle Quellen, automatisch aktuell gehalten
Rechte Jeder sieht alles Jeder sieht nur, was er sehen darf, mit Anmeldung
Tests Fragen, die man vorher ausprobiert hat Ein Testset aus echten Fällen, das bei jeder Änderung läuft
Betrieb Läuft auf einem Laptop Server, Updates, Backups, Monitoring, Kostenkontrolle
Verantwortung Die Person, die es gebaut hat, solange sie Zeit hat Eine feste Ansprechperson mit vereinbartem Umfang

Ein Beispiel aus der Praxis: Für eine Schule habe ich einen KI-Assistenten gebaut, der Fragen aus dem internen Wiki und einem juristischen Nachschlagewerk mit rund 1.400 Seiten beantwortet. Die erste Version davon wäre schnell gebaut gewesen: das PDF hochladen, Fragen stellen, fertig. Damit daraus ein System wird, das im Alltag genutzt wird, mussten genau die fünf Lücken geschlossen werden:

  • Daten: Das Wiki liegt hinter einem Login und wird jede Nacht automatisch neu eingelesen. Das Nachschlagewerk wird nach seinen Abschnitten zerlegt. Niemand pflegt Inhalte für den Assistenten von Hand.
  • Rechte: Jeder Nutzer meldet sich an, ein Admin-Bereich verwaltet die Zugänge.
  • Tests: Die Anbindung an das Wiki ist mit automatischen Tests abgesichert. Und wenn passender Kontext fehlt, sagt der Assistent das, statt zu raten.
  • Betrieb: Automatisiertes Deployment, jede Antwort wird protokolliert, und Nutzer bewerten sie direkt im Chat. So sieht man, wo das System gut ist und wo es nachgeschärft werden muss.
  • Verantwortung: Eine Person, von der Anforderung bis zum Betrieb. Ich habe das System allein gebaut, ausgerollt und betrieben, ohne Übergabe an einen zweiten Entwickler.

Nichts davon ist spektakulär. Aber genau das ist der Teil, der in Demos fehlt.

Woran du einen produktionsreifen Prototyp erkennst

Ob ein Prototyp live gehen kann, siehst du nicht daran, wie beeindruckend die Demo ist. Du siehst es an ein paar nüchternen Fragen. Je mehr davon mit Ja beantwortet werden, desto kürzer ist der Weg in die Produktion:

  • Läuft er mit echten Daten? Nicht mit Beispieldaten, sondern mit den Dokumenten, E-Mails oder Datensätzen, die im Alltag vorkommen, inklusive der unordentlichen.
  • Gibt es ein Testset? Eine Liste echter Fälle mit erwarteten Ergebnissen, an der man die Qualität in einer Zahl ablesen kann. Ohne sie ist „funktioniert gut“ eine Meinung.
  • Ist klar, was gut genug ist? Vorher festgelegt, nicht nach der Demo. Zum Beispiel: Bei 9 von 10 Testfragen stimmt die Antwort, und die Quelle ist die richtige.
  • Sind die Rechte mitgedacht? Wenigstens im Konzept: Woher kommen die Berechtigungen, und wie kommen sie ins System?
  • Gibt es ein Fehlerverhalten? Was passiert, wenn das Modell nichts Passendes findet, eine Schnittstelle nicht antwortet oder die Eingabe unsinnig ist? Ein guter Prototyp sagt dann „Weiß ich nicht“ und rät nicht.
  • Sind die laufenden Kosten geschätzt? Wie viel Modell und Server im Monat kosten, lässt sich vorher ausrechnen. Wie das geht, steht im Beitrag Was kostet ein KI-Wissensassistent?.
  • Gibt es jemanden im Fachbereich, der ihn will? Eine Person, die den Prozess kennt und sagt: Das nutze ich ab Montag. Ein Prototyp, den nur die Geschäftsführung gut findet, wird selten benutzt.

Ein Prototyp, der bei den meisten Punkten ein Nein bekommt, ist nicht wertlos. Er hat bewiesen, dass die Idee trägt. Aber er ist eine Skizze, kein halbfertiges Produkt. Oft ist es günstiger, die Erkenntnisse mitzunehmen und den Weg in die Produktion sauber neu zu planen, statt die Skizze Stück für Stück zu flicken.

Was „produktiv“ konkret heißt

„Produktiv“ wird oft mit „online“ verwechselt. Ein System ist nicht produktiv, weil es eine URL hat. Produktiv heißt: Menschen verlassen sich bei ihrer Arbeit darauf, jeden Tag, und es funktioniert auch an dem Tag, an dem niemand hinschaut. Konkret gehört dazu:

  • Anbindung an die echten Systeme. Die Daten kommen automatisch aus Wiki, Laufwerk, Postfach oder Datenbank und sind aktuell. Wo es nötig ist, schreibt das System Ergebnisse zurück, statt dass jemand sie kopiert.
  • Anmeldung und Berechtigungen. Jeder Nutzer meldet sich an und sieht nur, was er sehen darf.
  • Gemessene Qualität. Das Testset läuft bei jeder Änderung an Prompt, Modell oder Daten. Erst wenn es grün ist, geht die Änderung live.
  • Fehlerbehandlung. Fällt eine Quelle aus oder antwortet das Modell nicht, merkt der Nutzer das an einer klaren Meldung, nicht an einer falschen Antwort.
  • Protokolle und Monitoring. Jede Anfrage und jede Antwort ist nachvollziehbar. Qualität, Kosten und Fehler sind sichtbar, bevor sich jemand beschwert.
  • Deployment, Updates und Backups. Neue Versionen gehen automatisiert live, Sicherheitsupdates kommen zeitnah, die Daten sind gesichert.
  • Eine Oberfläche, die man ohne Schulung versteht. Mit Quellenangabe, damit Nutzer prüfen können, woher eine Antwort stammt.
  • Dokumentation, die dem Unternehmen gehört. Code, Zugänge und Doku liegen in euren Systemen. Das Projekt darf nicht am Kopf einer einzelnen Person hängen.

Diese Liste ist der Grund, warum der Schritt vom Prototyp zur Produktion oft mehr Arbeit ist als der Prototyp selbst. Das ist kein Zeichen, dass etwas schiefgelaufen ist. So ist Software, die Menschen jeden Tag benutzen. Wichtig ist nur, dass das vor dem Prototyp klar ist und nicht danach.

Wer sich nach dem Go-live kümmert

Ein KI-System ist nach dem Go-live nicht fertig, es fängt dann erst an. Modelle werden abgeschaltet oder durch neue ersetzt, die sich anders verhalten. Dokumente veralten. Nutzer stellen Fragen, an die niemand gedacht hat. Und die Kosten wachsen mit der Nutzung. Ohne Pflege wird ein KI-System leise schlechter, oft ohne dass es jemand merkt.

Deshalb muss vor dem Go-live feststehen, wer sich kümmert. Das kann jemand im eigenen Team sein, wenn es ein Engineering-Team gibt. Im Mittelstand gibt es das meistens nicht. Dann braucht es eine feste Ansprechperson von außen, mit schriftlich vereinbartem Umfang und Reaktionszeiten. Was zu ihren Aufgaben gehört:

  • Qualität überwachen: Feedback der Nutzer auswerten, schlechte Antworten finden und nachschärfen.
  • Jede Modelländerung testen: Neues Modell, neuer Prompt, neue Daten laufen zuerst durch das Testset.
  • Kosten im Blick behalten: Sehen, wenn die Rechnung steigt, und gegensteuern.
  • Sicherheitsupdates und Backups: Server und Abhängigkeiten aktuell halten.
  • Weiterentwickeln: Neue Quellen anbinden, den nächsten Anwendungsfall bauen.

Genau dafür arbeite ich in denselben vier Schritten, egal ob es um einen Wissensassistenten, einen KI-Agenten oder eine Automatisierung geht: Verstehen, Beweisen, Produktiv machen, Betreiben. Beim Verstehen kläre ich, welcher Prozess es ist, welche Daten und Rechte im Spiel sind und ob es überhaupt KI braucht. Wer damit anfangen will, macht das als KI-Prozess-Check: eine kurze Analyse zum Festpreis, am Ende ein Go oder No-Go mit einer Kostenrechnung. Beim Beweisen zeigt ein kleiner Pilot mit echten Daten und einem Testset, ob die Qualität reicht. Beim Produktiv machen kommen Anbindung, Berechtigungen, Tests und Monitoring dazu, ob für einen KI-Wissensassistenten, KI-Agenten oder eine KI-Automatisierung. Und beim Betreiben bleibe ich: Monitoring, Qualitätstests und Weiterentwicklung, auch für Systeme, die jemand anderes gebaut hat.

Der Unterschied zum Prototyp, der in der Schublade landet, ist nicht das bessere Modell. Es ist, dass die fünf Lücken von Anfang an Teil des Plans sind.

Liegt bei dir ein Prototyp, der nicht live geht? Oder läuft ein KI-System schon und niemand kümmert sich richtig darum? Dann schau dir Betrieb & Weiterentwicklung an: Ich übernehme auch Systeme, die jemand anderes gebaut hat, nach einem ehrlichen Blick auf Code und Infrastruktur. Und wenn du wissen willst, was deinem Prototyp bis zum Betrieb fehlt: Projekt anfragen.