Operational AI: Wie gelingen reproduzierbare Ergebnisse?
Im Jahr 1911 veröffentlichte Frederick Winslow Taylor das schmale Buch “The Principles of Scientific Management”. Taylor hatte weder eine neue Maschine erfunden noch eine Fabrik gebaut. Er hatte etwas Unspektakuläreres getan. Er hatte beobachtet, wie Menschen mit Maschinen arbeiten, und festgestellt, dass die Dampfmaschine allein noch keine Fabrik produktiv macht. Produktiv wird eine Fabrik durch Abläufe, Taktung, Organisation. Durch das System, das um die Maschine herum entsteht.
Die Dampfmaschine stand da, seit Jahrzehnten. Aber erst Taylor machte sie operativ.
Wer heute über künstliche Intelligenz in Unternehmen spricht, steht an einem ähnlichen Punkt. Die Modelle sind da, und sie sind beeindruckend. Was fehlt, ist die Methode.
Auf einen Blick
- Jede Technologie durchläuft zwei Phasen: In der ersten benutzt man sie. In der zweiten beginnt man, mit ihr zu denken. Die Dampfmaschine hat Jahrzehnte in Fabriken gestanden, bevor Taylor verstand, dass sie nie das Problem war.
- Was es zu gewinnen gibt: Die meisten Unternehmen befinden sich mit KI in der ersten Phase. Sie benutzen sie. Manche sogar gut. Wer als Erstes in die zweite Phase übergeht, wird nicht nur einen technologischen Vorsprung haben, sondern einen fundamentalen Wettbewerbsvorteil.
KI ohne (nachhaltige) Wirkung
Es gibt ein Phänomen, über das erstaunlich wenig gesprochen wird: KI-Projekte, die gelingen und trotzdem nichts bewegen.
Der Chatbot im Kundenservice läuft. Die Copilot-Lizenzen sind ausgerollt. Der Prototyp aus der Fachabteilung hat im Workshop alle begeistert, auf der Folie steht „erfolgreich pilotiert”, und sechs Monate später ist die Organisation genau dort, wo sie vorher war. Warum? Weil nach dem Piloten niemand die Frage gestellt hat, die eigentlich zählt: Was folgt daraus für den Prozess, für die Struktur, für die Art, wie hier gearbeitet wird?
Der Pilot war erfolgreich, aber folgenlos.
In den meisten Organisationen existieren heute drei, fünf, manchmal zehn solcher Initiativen parallel. Jede für sich sinnvoll, jede mit eigenem Modell und eigener Infrastruktur. Sie sprechen nicht miteinander. Sie bauen nicht aufeinander auf. Was sie hinterlassen, ist kein System. Es ist eine Sammlung.
Was Operational AI meint
Der Begriff klingt nach Beraterdeutsch, und ich bin mir bewusst, dass die Welt nicht auf ein weiteres Framework gewartet hat. Aber er trifft etwas, für das es bisher kein gutes Wort gibt. Operational AI beschreibt die Fähigkeit, KI-gestützte Prozesse so aufzusetzen, dass sie reproduzierbar funktionieren. Dass der zehnte Durchlauf genauso zuverlässig ist wie der erste. Dass das Ergebnis nicht vom Zufall abhängt, nicht von der Tagesform eines Sprachmodells und nicht von der Person, die den Prompt geschrieben hat.
Drei Denkverschiebungen machen diesen Unterschied greifbar.
Standardisierung
Der typische Einstieg in KI ist der Use Case. Ein Problem, ein Werkzeug, eine Lösung. Dagegen ist nichts einzuwenden, solange man versteht, dass es nicht reicht.
Taylor hat das verstanden. Er hat nicht die eine Fabrik optimiert, sondern ein Prinzip formuliert, das sich auf jede Fabrik übertragen ließ. Was einmal gelöst war, wurde dokumentiert und zum Standard erklärt. Wiederholbar, übertragbar, lehrbar.
Bei KI passiert das Gegenteil. Ein Team entwickelt eine Lösung, die funktioniert, und im Stockwerk darüber fängt ein anderes Team bei null an. Prompts werden jedes Mal neu geschrieben, Architekturen jedes Mal neu gedacht, Fehler jedes Mal neu gemacht. Enormer Aufwand, kaum Lerneffekt.
Operational AI stellt hier eine einfache Forderung: Was gelöst ist, wird zum Asset. Zur SOP, zum Template, zum wiederverwendbaren Baustein. Das klingt banal. Aber es ist der einzige Mechanismus, durch den Wissen in Organisationen skaliert. Das war vor hundert Jahren so, und auch KI ändert daran nichts.
Trennung der Verantwortlichkeiten
Hier wird es technischer. Die Pointe ist trotzdem lesenswert.
Große Sprachmodelle können beeindruckende Dinge: Sprache verstehen, Texte generieren, Zusammenhänge erkennen, die Menschen übersehen. Zuverlässig rechnen gehört nicht dazu. Das liegt in ihrer Natur. Sie arbeiten probabilistisch, schätzen also die wahrscheinlichste Antwort, statt sie herzuleiten.
Für einen Blogpost ist das in Ordnung. Für eine Due-Diligence-Prüfung, eine Bilanzanalyse oder eine Kreditentscheidung ist „wahrscheinlich richtig” ein Compliance-Albtraum.
Die kluge Architektur löst das, indem sie zwei Rollen sauber trennt.
- Aufgabenstellung: Das Sprachmodell übersetzt, indem es Dokumente liest, Daten extrahiert, Strukturen erkennt. Es überbrückt die unordentliche Welt der menschlichen Sprache und die saubere Welt der Variablen.
- Berechnung: Klassische Software enthält die eigentliche Berechnung, die Entscheidungslogik, den Audit Trail. Deterministisch. Nachvollziehbar. Langweilig, wenn man so will. Und genau deshalb vertrauenswürdig.
Ob eine Organisation diese Trennung vornimmt, klingt wie eine technische Detailfrage. In Wahrheit ist es eine Führungsfrage. Sie bestimmt, ob das System auditierbar ist, ob ein Wirtschaftsprüfer es abnimmt, ob die Geschäftsleitung sich traut, Entscheidungen darauf zu stützen.
Autonomie
Wer baut das System? Wer betreibt es? Und vor allem: Wer versteht es noch, wenn der externe Berater das Projekt abgeschlossen hat?
Die meisten KI-Projekte enden mit einer Lösung, die funktioniert, solange die Leute da sind, die sie gebaut haben. Das ist ein erweiterter Prototyp. Ein ziemlich teurer, manchmal.
Operational AI verlangt etwas anderes. Die Architektur muss so angelegt sein, dass die Organisation sie selbst weiterentwickeln kann. Das bedeutet Standards, die man nachlesen kann, statt Tricks, die jemand im Kopf hat. Dokumentation, die existiert, bevor jemand danach fragt. Governance, die Leitplanken setzt, statt Innovation auszubremsen.
Es ist im Übrigen auch die ehrlichste Antwort auf die Frage, die Führungskräfte eigentlich stellen, wenn sie sich mit KI beschäftigen. Die Frage lautet selten „Welches Modell sollen wir nutzen?” Sie lautet meistens: „Wie werden wir gut in KI, ohne dauerhaft auf Hilfe angewiesen zu sein?”
Beispiel: Angebotsqualifizierung bei einem Maschinenbauer (anwendbar auf jede andere Branche)
Ausgangslage: Ein Maschinenbauer mit 800 Mitarbeitenden bekommt jährlich rund 3.000 Angebotsanfragen. Jede muss technisch geprüft, kalkuliert und freigegeben werden. Das dauert im Schnitt vier Tage, und hängt komplett an fünf erfahrenen Leuten im Vertriebsinnendienst, die Lastenhefte lesen, Stücklisten abgleichen und Machbarkeiten einschätzen.
Ein KI-Pilot zeigt: Ein Sprachmodell kann Lastenhefte lesen, relevante Anforderungen extrahieren und mit dem Produktkatalog abgleichen. Der Pilot begeistert. Und dann passiert – nichts.
Was Operational AI hier anders macht:
1. Standardisierung
Die Prompt-Logik, die im Piloten funktioniert hat, wird nicht im Kopf eines Beraters gelassen. Sie wird als standardisierter Workflow dokumentiert: Eingabeformat, Extraktionsregeln, Ausgabestruktur. Wenn nächste Woche das Team in der zweiten Niederlassung denselben Prozess aufsetzen will, muss es nicht bei null anfangen, sondern nutzt das Template.
2. Trennung der Verantwortlichkeiten
Das Sprachmodell liest das Lastenheft und extrahiert die technischen Parameter wie Drehmoment, Toleranzen, Materialanforderungen. Aber es rechnet nicht. Die eigentliche Kalkulation von Stückkosten, Lieferzeiten und Margenberechnung läuft in der bestehenden ERP-Logik. Deterministisch, nachvollziehbar, prüfbar.
Der Vertriebsleiter kann dem Geschäftsführer erklären, woher die Zahl kommt. Das konnte er beim Piloten nicht.
3. Autonomie
Zwei Mitarbeitende aus dem Vertriebsinnendienst werden geschult. Nicht im Prompt Engineering, sondern darin, die Extraktionsregeln zu pflegen, neue Produktvarianten einzuarbeiten und Fehlklassifikationen zu korrigieren. Nach drei Monaten brauchen sie keinen externen Support mehr .
Ergebnis: Die Durchlaufzeit sinkt von vier Tagen auf einen halben. Die Konkurrenz nutzt das gleiche Sprachmodell, aber der Maschinenbauer hat das System, das dauerhaft belastbare Ergebnisse liefert.
Eine Frage der Führung
Alle drei Prinzipien haben etwas gemeinsam: Sie lassen sich nicht an die IT-Abteilung delegieren.
Welche Lösung zum Standard wird und welche als Experiment versandet, ist eine strategische Entscheidung. Ob die Architektur Vertrauen verdient, weil sie Transparenz erzwingt, entscheidet kein Prompt Engineer. Ob die Organisation in einem Jahr besser da steht als der Wettbewerb, hängt an der Führung.
Operational AI ist eine Organisationsaufgabe. Sie verlangt den Blick auf das Ganze, nicht nur auf das nächste (Pilot-) Projekt. Und sie verlangt die Bereitschaft, in Struktur zu investieren, bevor deren Nutzen sichtbar wird. Unbequem. Aber es ist der einzige Ansatz, der über den Einzelfall hinaus funktioniert.