Wie kommt man vom Prototyp zum zuverlässigen Produkt?
Viele KI-Projekte scheitern nicht am ersten Prototyp, der oft erstaunlich schnell entsteht: Ein Prompt, ein Modellaufruf, ein paar Beispieldokumente, vielleicht ein gut gewählter Satz von Werkzeugen liefern ein Ergebnis, das im Demo-Termin überzeugt. Das Problem beginnt danach.
Sobald aus dem Prototyp ein produktiver Prozess werden soll, ändert sich die Fragestellung. Es reicht nicht, dass ein Ergebnis plausibel klingt. Es muss klar sein, welche Schritte in welcher Reihenfolge ausgeführt wurden, welche Daten verwendet wurden, wo das Sprachmodell entscheiden durfte und wo klassische Logik die Führung hatte, welche Werkzeuge verfügbar waren, was bei Fehlern passiert und wie sich ein Ergebnis später überprüfen lässt.
Mit einem Baukasten aus Prompts, Tools und Skripten lässt sich das nicht zuverlässig umsetzen. Er bleibt von Konventionen abhängig: Die Entwickler*innen müssen daran denken, welche Werkzeuge ein Prompt verwenden darf, im Code nachvollziehen, wie Zwischenergebnisse und Fehlerbehandlungen weitergereicht werden, Wiederholungen und Abbrüche selbst zusammensetzen. Mit fortschreitendem Prozess entsteht ein Geflecht, das nur noch schwer zu lesen, zu prüfen und zu ändern ist. Während es im Prototyp genügt, dass etwas funktioniert, muss im Produkt sichtbar sein, warum es funktioniert, und was passiert, wenn nicht.
Die falsche Verantwortung für das Sprachmodell
Die zunehmende Ernüchterung über KI hat einen einfachen Grund: KI-Projekte scheitern weniger an Modellproblemen als an der Architektur, die dem LLM zu viel Verantwortung aufbürdet. Ein Large Language Model ist stark, wenn es darum geht, Sprache zu verstehen, Bedeutungen zu erkennen, Varianten zu formulieren, unscharfe Informationen einzuordnen oder aus mehreren Hinweisen ein plausibles Muster zu bilden. Es hat aber Schwächen, wenn es den stabilen Ablauf eines industriellen Prozesses unterstützen soll. Reihenfolge, Terminierung, Fehlerbehandlung, Zustandsverwaltung und Nachvollziehbarkeit sind keine Aufgaben, die man einem Sprachmodell überlassen sollte.
Ein Sprachmodell ist schnell, mustererkennend und flexibel, aber ihm fehlt die prüfende, strukturierende Instanz. Diese Kontrollschicht muss von außen kommen: durch Architektur, deterministische Logik und klare Grenzen. Genau das meint das MADWYN-Prinzip des Make AI Do What YOU Need: Nicht das Modell bestimmt, was zu tun ist; der Mensch gibt Bedarf, Aufgabe und Grenzen vor, und die KI wird darauf verpflichtet. Industrietauglich wird die KI erst durch diese Trennung von kognitiven und algorithmischen Anteilen – das Modell übernimmt das Deuten und Formulieren, die Architektur den verlässlichen Rahmen. Das Sprachmodell soll nicht den Prozess tragen, sondern dort wirken, wo seine Stärke liegt, eingebettet in einen Ablauf, der stabil, transparent und überprüfbar bleibt. Ausführlich hergeleitet ist das im PROSTEP-Whitepaper „Das MADWYN-Prinzip – Make AI do what YOU need“.
Ein Modell für die Entwicklung und Ausführung des Prozesses
Ein industrieller KI-Prozess braucht deshalb ein Modell, das sowohl die Entwicklung des Prozesses als auch seine Ausführung umfasst. Man muss den Prozess beschreiben können, bevor er läuft, ihn prüfen können, bevor er ausgeliefert wird, und ihn zur Laufzeit so ausführen, dass seine Grenzen eingehalten und seine Schritte beobachtbar bleiben. Bei PROSTEP ist dieses Modell die AI Pattern Language (APL). APL hält den Prozessfluss algorithmisch und bindet die KI als kognitiven Schritt genau dort ein, wo Sprache, Bedeutung oder Bewertung gebraucht werden.
APL ist nicht nur eine Notation für Prompts, sondern eine formale Sprache zur Beschreibung KI-gestützter Prozesse. Für die Ausführung liefert APL eine Programmbibliothek, die die formale Definition des KI-Prozesses lädt und sie Schritt für Schritt abarbeitet.
Dadurch, dass die Ausführungsumgebung als Bibliothek bereitgestellt wird und kein externer Dienst wie etwa eine kommerzielle Agentenplattform ist, der irgendwo im Netz läuft, kann sie zum integralen Bestandteil beliebiger Anwendungen werden. So lässt sich KI nahtlos in die Business-Logik eines Softwareproduktes integrieren, mit voller Versionskontrolle, Testunterstützung und Review-Fähigkeit. So wird aus einem losen Skript neben dem eigentlichen System ein echtes Produktfeature.
Wie unterscheidet sich das von verbreiteten Ansätzen? Mit Bibliotheken wie LangChain lassen sich Prompts sehr schnell zu einem Ablauf verketten. Aber dieser Ablauf existiert nur im Programmcode, auch dort, wo er als Graph strukturiert wird: Es gibt kein eigenständiges, vorab prüfbares Ablaufdokument, und was die KI tun darf, steckt in Code-Konventionen statt in einer klaren, sichtbaren Vorgabe. Andere Werkzeuge optimieren Prompts automatisch, bis sie in Tests gut abschneiden. Das ist praktisch, wo sich Erfolg messen lässt, aber der so entstandene Prompt ist hinterher kaum noch nachvollziehbar. Und klassische Workflow-Werkzeuge steuern Abläufe zwar zuverlässig, sind aber gar nicht für KI gemacht. APL setzt bewusst dazwischen an: Bei einem lesbaren, vorab prüfbaren Ablauf, in dem die KI nur an klar umrissenen Stellen entscheidet und der als eigenes Dokument vorliegt, nicht versteckt im Code. Diese Verbindung aus einem Ablauf, den man vorab liest und freigibt, und eine Laufzeit, die im Produkt selbst steckt, statt als Dienst daneben, ist uns bei keinem anderen Werkzeug bekannt.
APL-Prozesse sind für Menschen und Agenten wartbar
Der Wert eines solchen Modells liegt darin, dass es nicht nur dafür sorgt, dass ein Prozess heute läuft. Es gewährleistet außerdem, dass er morgen geändert werden kann, ohne die Kontrolle über den Prozess zu verlieren.
In produktiven KI-Anwendungen verschiebt sich die Grenze zwischen algorithmischem und kognitivem Anteil ständig: Ein Schritt wird deterministisch lösbar, ein anderer braucht plötzlich KI, ein Modellwechsel verändert das Prompt-Verhalten, ein neuer Anwendungsfall verlangt andere Werkzeuge. Besteht der Prozess nur aus Code, Prompts und Konventionen, sind solche Änderungen riskant. Ist er jedoch wie in APL durch eine klare, deklarative Abstraktionsschicht und die Ausführungsregeln der Laufzeitumgebung determiniert, lassen sich Änderungen gezielt und mit geringerem Risiko von Seiteneffekten durchführen. Der Ablauf bleibt lesbar, der Übergang zwischen algorithmisch und kognitiv sichtbar und die Grenzen der KI ein Teil der Beschreibung.
Weil APL die Trennung von Prozesslogik, kognitiven und deterministischen Schritten, Werkzeugen und Laufzeitverhalten erzwingt, kann nicht nur der Mensch den KI-Prozess besser verstehen. Die Trennung und der deklarative Charakter machen APL auch für Coding-Agenten gut handhabbar: Ein Agent kann neue Schritte ergänzen, Prompts austauschen oder Werkzeuggrenzen anpassen, ohne die ganze Anwendung umzuschreiben und die Details der Ausführungslogik lesen zu müssen. So wird nicht nur die Ausführung kontrollierbar, sondern auch die Weiterentwicklung des Prozesses.
So viel KI wie nötig und so wenig wie möglich
Industrietauglich wird ein KI-Prozess nicht durch möglichst viel KI, sondern dadurch, dass er vier Eigenschaften erfüllt:
- Transparent: Man kann sehen, welche Schritte ausgeführt wurden.
- Kontrollierbar: Man bestimmt, welche Werkzeuge und Entscheidungen der KI offenstehen.
- Nachprüfbar: Ergebnisse lassen sich auf Zwischenschritte und Quellen zurückführen.
- Skalierbar: Der Ansatz trägt nicht nur für einen Demo-Fall, sondern für viele Prozesse, Produkte und Varianten.
Eine lose Sammlung von Prompts kann das punktuell leisten. Ein Modell aus Sprache und Laufzeit macht es zur Architektur.
Der nächste Beitrag macht dieses Kernprinzip konkret — und beantwortet die Frage, die sich damit sofort stellt: Woran erkennt man überhaupt, welche Stelle im Prozess die KI übernehmen soll und welche besser klassische Logik?
