Von 250+ Prototypen zum Produkt: was ich dabei gelernt habe

TL;DR

Ich baue seit Ende 2024 täglich mit KI-Agenten. Aus mehr als 250 eigenen Prototypen und Experimenten ist für mich vor allem eine Unterscheidung geblieben: Ein Versuch beantwortet eine Frage. Ein Produkt braucht darüber hinaus einen Ablauf für den täglichen Betrieb. Hier geht es um die Arbeit dazwischen und darum, wann ich einen Versuch beende.

Welche Frage soll der Prototyp beantworten?

Bei einem Prototyp reicht mir zunächst eine begrenzte Frage: Kann ein Modell die benötigten Angaben aus einem Beleg lesen? Findet es die passende Information in meinen Unterlagen? Lässt sich ein wiederkehrender Arbeitsschritt damit vorbereiten?

Ein brauchbares Ergebnis sagt noch wenig darüber aus, wie der Ablauf mit anderen Eingaben funktioniert. Deshalb gehören schwierige Beispiele früh dazu: ein schlecht fotografierter Beleg, ein unvollständiger Datensatz, eine Anfrage, für die die Information fehlt.

Wenn du noch keinen konkreten Anwendungsfall hast, beschreibt der Einstiegsguide für Unternehmen, wie du einen einzelnen Prozess dafür auswählst.

Was außerhalb des Modells liegt

Bei BuchhaltGenie war die Texterkennung auf Belegen ein wichtiger Teil der Arbeit. Neben dem Modell musste ich mich mit den Eingaben und der Weiterverarbeitung beschäftigen: unterschiedliche Dokumentformate, Vorverarbeitung und die strukturierte Aufbereitung der Ergebnisse.

Für einen vollständigen Ablauf kommen weitere Fragen dazu:

• Eingaben: Welche Formate kommen an? Was passiert, wenn etwas fehlt oder nicht lesbar ist?
• Prüfung: Woran erkenne ich eine falsche Antwort? Welche Ergebnisse brauchen eine Freigabe?
• Integration: Wo landet das Ergebnis, und wer darf darauf zugreifen?
• Fehler: Wie wird ein fehlgeschlagener Schritt sichtbar? Kann ich ihn wiederholen, ohne etwas doppelt anzulegen?
• Betrieb: Wer reagiert, wenn die Qualität sinkt oder sich eine Schnittstelle ändert?

Ein Modellwechsel kann helfen. Die Fragen rundherum bleiben trotzdem Teil des Projekts.

Kleine Schritte, die sich überprüfen lassen

In meinen Entwicklungs-Sessions arbeite ich an begrenzten Änderungen. Danach prüfe ich das Ergebnis, bevor der nächste Schritt dazukommt. Bei KI-Ausgaben braucht es dafür konkrete Beispiele mit einem erwarteten Ergebnis. Eine plausibel klingende Antwort allein hilft beim Vergleich wenig.

Ich halte auch fest, warum ich einen Ansatz gewählt oder verworfen habe. Wenn ich später wieder in das Projekt einsteige, brauche ich diese Entscheidung und die offenen Punkte. Die nächste Session soll an der Arbeit anknüpfen können.

Wann der Versuch vorerst reicht

Nicht jede beantwortete Frage braucht ein Produkt. Für die Entscheidung schaue ich auf vier Dinge:

Funktioniert es mit den tatsächlichen Eingaben? Wenn der Ansatz nur mit ausgesuchten Beispielen trägt, brauche ich weitere Versuche, bevor ich den Ablauf erweitere.

Geht sich der Aufwand aus? Zu den Modellkosten kommen Integration, Prüfung und Wartung. Ich rechne mit dem erwarteten Volumen und dem Aufwand, der bisher für den Arbeitsschritt anfällt.

Ist der Umgang mit Fehlern geklärt? Ein unvollständiger Entwurf lässt sich korrigieren. Eine falsche Aktion in einem angeschlossenen System kann mehr Arbeit verursachen. Die Freigabe muss zum jeweiligen Schritt passen.

Wer kümmert sich nach dem Start darum? Auch bei meinen eigenen Projekten ist das eine Kapazitätsfrage. Ein weiterer laufender Dienst braucht Zeit für Updates und Fehler.

Wenn das noch nicht zusammenpasst, kann der Prototyp liegen bleiben. Die beantwortete Frage und die Grenzen des Ansatzes halte ich fest.

Wenn daraus ein Produkt werden soll

Ich würde den Übergang in vier Schritten planen. Wie lange sie dauern, hängt am konkreten Vorhaben.

1. Mit echten Beispielen prüfen. Erwartete Ergebnisse, Fehlerfälle und laufende Kosten zusammenstellen. Vorher festlegen, welche Qualität für den Arbeitsschritt genügt.
2. Den Betrieb vorbereiten. Zugriffe, Datenhaltung, Fehlerbehandlung, Monitoring und die passenden rechtlichen Anforderungen klären.
3. Begrenzt einsetzen. Den Ablauf mit einem überschaubaren Umfang nutzen, Rückmeldungen sammeln und die Ergebnisse weiter prüfen.
4. Zuständigkeit festhalten. Dokumentieren, wer Updates und Fehler übernimmt und wie sich die Funktion abschalten oder zurücksetzen lässt.

Der Prototyp hilft mir zu entscheiden, ob sich diese weitere Arbeit lohnt. Erst danach plane ich den Umfang für den Betrieb.

Wenn du diese Entscheidung für einen eigenen Prototyp gerade vor dir hast, kannst du mir den Ablauf über den Kontakt-Abschnitt beschreiben.