Vom Prototyp zum Produktivsystem: was noch fehlt
Ein guter Prototyp ist ehrlich unfertig. Er zeigt einen engen Fall an echten Daten und lässt alles weg, was für den Beweis nicht nötig ist. Genau dieses Weggelassene ist der Weg vom Prototyp in die Produktion. Sechs Lücken tauchen fast immer auf: die einmalige Datenprobe wird zur laufenden Versorgung, der Mensch neben dem System wird zu einem definierten Fehlerpfad, aus stillem Betrieb wird Monitoring, aus einem Testzugang werden saubere Rechte, aus unbeachteten Kosten werden Limits, und aus einem eingefrorenen Stand wird ein Umgang mit Modell- und Datenänderungen. Der größte einzelne Hebel ist der Fehlerpfad: Ein Produktivsystem darf im Ausnahmefall nicht einfach stehen bleiben, sondern muss wissen, wann es an einen Menschen übergibt. Keine dieser Lücken ist ein Grund, den Prototyp zu meiden. Sie sind der Grund, ihn nicht mit einem fertigen Produkt zu verwechseln.
Was ein Prototyp bewusst weglässt
Ein Prototyp ist kein halbfertiges Produkt. Er ist eine ehrliche Antwort auf eine einzige Frage: Funktioniert dieser Fall an echten Daten. Um diese Frage zu beantworten, lässt ein guter Prototyp alles weg, was für den Beweis nicht nötig ist. Er zieht die Daten einmal von Hand, er scheitert im Ausnahmefall vor den Augen eines Menschen, und er läuft, solange jemand danebensteht.
Das ist kein Mangel, sondern der Sinn der Sache. Wer in den Prototyp schon Monitoring, Rechte-Konzept und Fehlerbehandlung einbaut, verbrennt Zeit an einem System, das vielleicht nie in Betrieb geht. Erst der Prototyp entscheidet, ob sich der Rest überhaupt lohnt. Deshalb ist das Weggelassene keine Schlamperei, sondern eine bewusste Reihenfolge.
Der teure Moment kommt später, wenn ein gelungener Prototyp mit einem fertigen System verwechselt wird. Die Demo lief, alle waren begeistert, und plötzlich soll das Ding am Montag in den Alltag. Genau hier wird sichtbar, was der Prototyp nie versprochen hat.
| Aspekt | Was der Prototyp tut | Was der Betrieb braucht |
|---|---|---|
| Daten | einmalige Probe, von Hand gezogen | laufende, geprüfte Versorgung |
| Fehler | ein Mensch fängt sie ab | definierter Pfad und Eskalation |
| Beobachtung | jemand schaut beim Test zu | Monitoring und Alarmierung |
| Zugriff | Testzugang, breit freigegeben | saubere Rechte, minimal vergeben |
| Kosten | fallen auf, stören aber nicht | Limits und ein Blick auf den Verbrauch |
Die sechs Lücken bis zum Betrieb
Wenn man viele Übergänge vom Prototyp in den Betrieb nebeneinanderlegt, wiederholen sich sechs Lücken. Sie treten selten einzeln auf, und keine davon ist ein technisches Rätsel. Es ist Arbeit, die man vorher benennen und einplanen kann, statt sie im Livegang zu entdecken.
Die einmalige Datenprobe muss zu einer laufenden Versorgung werden. Der Mensch neben dem System muss durch einen definierten Fehlerpfad ersetzt werden, der weiß, wann er übergibt. Aus dem stillen Zusehen beim Test wird Monitoring, das Qualität, Kosten und Ausfälle sichtbar macht. Aus einem breiten Testzugang werden saubere, minimal vergebene Rechte. Aus unbeachteten Kosten werden Limits, damit ein Fehler nicht zur Rechnung wird. Und aus einem eingefrorenen Stand wird ein Umgang mit Änderungen, weil Modelle, Prompts und Daten sich bewegen.
Von der Datenprobe zur laufenden Versorgung
Im Prototyp zieht man die Daten einmal. Ein Export, eine Handvoll Beispiele, genug, um den Fall zu zeigen. Im Betrieb gibt es diesen einen Moment nicht mehr. Die Daten müssen jeden Tag ankommen, aktuell sein, im richtigen Format vorliegen und auch dann noch stimmen, wenn irgendwo eine Quelle ihr Schema ändert.
Das ist die Lücke, die am häufigsten unterschätzt wird, weil sie im Prototyp gelöst aussah. War sie aber nicht. Eine einmal von Hand gezogene Probe sagt nichts darüber, ob dieselben Daten verlässlich, rechtmäßig und automatisch fließen. Genau hier steckt oft mehr Arbeit als im eigentlichen KI-Teil: Anbindung an die Quellsysteme, Prüfung auf Vollständigkeit, Umgang mit Lücken und ein Plan für den Tag, an dem eine Quelle ausfällt.
Der ehrliche Test ist einfach: Läuft dein Fall auch, wenn niemand die Daten von Hand bereitstellt. Solange die Antwort nein ist, hast du einen Prototyp, keinen Betrieb.
Der Fehlerpfad trägt den Betrieb
Im Prototyp ist der Fehlerpfad ein Mensch. Fällt etwas Ungewöhnliches an, schaut jemand hin, korrigiert und macht weiter. Das ist völlig in Ordnung, solange das System im Test läuft. Im Betrieb ist dieser Mensch nicht mehr da, jedenfalls nicht rund um die Uhr, und das System muss selbst wissen, was es tut, wenn es unsicher wird.
Ein Produktivsystem darf im Ausnahmefall nicht einfach weitermachen, als wäre nichts. Es muss erkennen, dass es an seiner Grenze ist, und mit Kontext an einen Menschen übergeben.
Ein sauberer Fehlerpfad beantwortet drei Fragen: Woran erkennt das System, dass es unsicher ist. Was tut es dann, hält es an, fragt nach oder gibt es weiter. Und wer bekommt den Fall mit genug Kontext, um ihn schnell zu lösen. Fehlt dieser Pfad, wird die erste unerwartete Eingabe entweder still falsch verarbeitet oder legt den Ablauf lahm. Beides ist teurer als der Aufwand, den Pfad vorher zu bauen.
| Symptom im Betrieb | Eigentliche Lücke | Was vorher fehlte |
|---|---|---|
| System verarbeitet Unsinn still weiter | keine Unsicherheitsgrenze | ein Schwellwert und ein Stopp |
| Ein Fehler legt den ganzen Ablauf lahm | kein Eskalationspfad | Übergabe an einen Menschen |
| Niemand merkt den Ausfall rechtzeitig | kein Monitoring | Alarm bei Qualität und Kosten |
| Kosten explodieren über Nacht | kein Limit | Verbrauchsgrenze pro Zeitraum |
Die Produktionsreife-Prüfung
Bevor ein Prototyp in den Alltag geht, beantworte diese sechs Fragen. Wo du keine klare Antwort hast, liegt die Arbeit, die noch fehlt, und zwar bevor sie im Livegang teuer wird.
- Fließen die Daten automatisch, aktuell und rechtmäßig, ohne dass jemand sie von Hand bereitstellt?
- Kennt das System seine Grenze, und was tut es, wenn es unsicher wird?
- Gibt es einen Fehlerpfad mit klarer Übergabe an eine benannte Person, samt Kontext?
- Siehst du im Betrieb, wie Qualität, Kosten und Ausfälle sich entwickeln, mit Alarm bei Abweichung?
- Sind die Rechte minimal vergeben, nicht der breite Testzugang aus dem Prototyp?
- Was passiert bei Änderungen an Modell, Prompt oder Datenquelle, und wer prüft das?
Kernsatz: Der Sprung vom Prototyp in die Produktion ist zu einem kleinen Teil KI und zu einem großen Teil Betrieb. Was der Prototyp weggelassen hat, ist genau die Liste dessen, was jetzt zu bauen ist.
Häufige Irrtümer
- Der Prototyp läuft, also ist die Hauptarbeit getan.
- Der Prototyp beweist die Machbarkeit, das ist der kleinere Teil. Der Betrieb baut alles, was der Prototyp zum Beweisen weglassen durfte, und das ist oft mehr Arbeit als der Prototyp selbst.
- Betriebsreife ist ein technisches Detail am Ende.
- Datenversorgung, Fehlerpfad und Rechte sind keine Politur, sondern eigene Bausteine. Wer sie ans Ende schiebt, findet im Livegang heraus, dass sie den größten Teil des Wegs ausmachen.
Fragen und Antworten
- Wie lange dauert der Weg vom Prototyp in den Betrieb?
- Das hängt an den sechs Lücken, nicht am KI-Teil. Ist die Datenversorgung schon halb geklärt und der Fall eng, kann es schnell gehen. Muss erst eine laufende Anbindung entstehen und ein Fehlerpfad definiert werden, ist es die eigentliche Arbeit. Ehrlich ist, das vor dem Livegang zu benennen statt danach zu entdecken.
- Muss wirklich alles betriebsreif sein, bevor wir starten?
- Nein, aber die kritischen Lücken müssen geschlossen sein: verlässliche Daten und ein Fehlerpfad. Monitoring und Kostenlimits kann man knapp starten und ausbauen. Rechte hingegen sollten von Anfang an sauber sein, weil sie sich später schwer nachziehen lassen.
- Können wir den Prototyp einfach weiterlaufen lassen?
- Selten gut. Ein Prototyp ist auf Beweis gebaut, nicht auf Dauerlast, Ausfallsicherheit und Aufsicht. Ihn ungeprüft in den Alltag zu schieben, verlagert die weggelassene Arbeit nur in den Moment, in dem sie am teuersten ist.
Sources and evidence
Es werden keine externen Statistiken oder Kundenergebnisse als belegt behauptet. Daten-, Rechte- und Kostenfragen werden vor dem Livegang mit dem realen Stack geprüft.