Vom KI-Piloten in den echten Betrieb

Die meisten Unternehmen haben mittlerweile einen Pilot durchgeführt. Manche sogar mehrere. Das Muster ist bekannt: Ein kleines Team wählt einen Use Case, baut ein Modell drumherum, präsentiert es der Geschäftsführung, erntet Applaus und steckt dann irgendwo zwischen „funktioniert im Staging" und „können wir ausliefern" fest.

Laut einer McKinsey-Umfrage von 2024 geben 79 % der Führungskräfte an, dass die KI-Einführung ihnen Probleme bereitet. Eine separate Zahl von Gartner zeigt: Nur 31 % der Organisationen haben ein formales Mess-Framework für produktive Agenten. Wer beide Zahlen zusammenliest, sieht das Problem sofort. Pilots laufen überall. Produktionsdisziplin ist kaum vorhanden.

Das ist keine Fähigkeitslücke. Die Modelle sind gut genug. Das Tooling ist reif genug. Was fehlt, ist das Handwerk: aus einem Experiment etwas zu machen, auf das man sein Quartal verwetten würde.

Warum Piloten an der Schwelle sterben

Ein Pilot beantwortet eine einzige Frage. Kann das funktionieren? Er darf fragil sein. Jemand beobachtet ihn. Jemand greift ein, wenn er halbiert. Jemand prüft den Output manuell, bevor er echte Dinge berührt.

Produktion ist ein anderer Vertrag. Niemand schaut bei jedem Durchlauf zu. Fehler passieren lautlos. Kosten summieren sich im Hintergrund. Nutzer gewöhnen sich an das System, auf gute und schlechte Weise. Und wenn etwas schiefläuft, muss man das in Minuten wissen, nicht in Wochen.

Die Lücke zwischen diesen beiden Zuständen ist kein Sprint voller Aufräumarbeiten. Es ist eine andere Art, über das nachzudenken, was man gebaut hat. Die meisten Teams überspringen dieses Umdenken, weil der Pilot so vielversprechend aussah. Genau dort fangen die Probleme an.

Dazu kommt ein organisatorischer Sog in Richtung Demo. Eine funktionierende Demo ist sichtbar. Sie erzeugt Begeisterung. Production Readiness ist unsichtbar, bis sie vor einem Kunden versagt. Der Anreiz, die Demo zu shippen und das als fertig zu erklären, ist also real. Es braucht bewussten Widerstand, um dem nicht nachzugeben.

Drei Dinge, die in der zweiten Hälfte von 2026 zählen

Nach der Arbeit mit produktiven Agentensystemen in mehreren Kundenprojekten zeigt sich: Drei Disziplinen trennen die Systeme, die sich halten, von denen, die still abgeschaltet werden.

1. Ein Messframework pro Agent, nicht pro Produkt

Die Standardmetrik für die meisten veröffentlichten KI-Features ist Adoption. Wie viele Nutzer es geöffnet haben. Wie viele Sessions. Wie viele Seats aktiviert wurden. Das ist eine Produktmetrik, keine Agentenmetrik. Sie sagt dir nichts darüber, ob der Agent das tut, wofür du ihn gebaut hast.

Nützliche Metriken liegen eine Ebene tiefer. Task-Success-Rate: Hat der Agent die zugewiesene Aufgabe abgeschlossen, ohne dass ein Mensch eingreifen oder nacharbeiten musste? Tool-Call-Genauigkeit: Wenn der Agent eine Funktion oder eine API aufgerufen hat, hat er die richtige mit den richtigen Argumenten gewählt? Kosten pro Ergebnis: nicht pro Token, nicht pro Session, sondern pro Einheit tatsächlich geliefertem Wert.

Das ist schwieriger zu messen, besonders wenn dein Agent schnell für eine Demo zusammengebaut wurde. Aber das sind die einzigen Zahlen, die dir sagen, ob das System seinen Platz im Stack verdient. Leg zwei oder drei Metriken fest, bevor du live gehst. Mehr kannst du später immer noch hinzufügen. Ohne eine einzige fliegst du blind.

2. Identity, Audit Logs, Rollback und menschliche Übernahme sind Pflicht, kein Bonus

Jeder produktive Agent muss wissen, in wessen Auftrag er handelt, eine Spur hinterlassen, was er getan hat, umkehrbar sein, wenn er auf Basis schlechter Daten handelt, und einen klaren Weg haben, damit ein Mensch einspringen und übernehmen kann.

Diese vier Dinge sind keine Compliance-Checkliste. Sie sind die mechanischen Eigenschaften, die ein agentisches System sicher im großen Maßstab betreibbar machen. Ohne sie kann ein einziger Fehllauf den State korrumpieren, einen Kunden falsch belasten, etwas unwiderruflich löschen oder einen nachgelagerten Prozess anstoßen, dessen Rückabwicklung Tage dauert.

Der Einwand, den ich meistens höre. Diese Infrastruktur verlangsamt das Team. Beim ersten Mal stimmt das leicht. Beim dritten Agenten ist es ein Zwei-Stunden-Setup, weil die Muster bereits vorhanden sind. Die Kosten, das nachträglich nach einem Vorfall einzubauen, sind um Größenordnungen höher.

Das ist dieselbe Logik, die Versionskontrolle bei Code unverhandelbar gemacht hat. Darüber streitet niemand mehr. Audit Logs und Rollback für Agenten werden dort auch ankommen. Teams, die das heute als optional behandeln, kaufen sich nur Zeit.

3. ROI auf Ergebnisebene, nicht auf Tool-Ebene

Hier bricht die Business-Case-Logik leise zusammen. Ein Team baut einen Agenten, misst die Betriebskosten (Compute, API-Aufrufe, Engineering-Zeit), vergleicht das mit den Lizenzkosten des abgelösten SaaS-Tools und nennt es einen Erfolg.

Aber die Tool-Kosten waren nie die eigentlichen Kosten. Die eigentlichen Kosten waren die Zeit, die eine Person für eine Aufgabe aufgewendet hat, die ein Ergebnis produziert hat. Die richtige Frage lautet: Liefert der Agent dieses Ergebnis schneller, genauer und mit weniger Nachkorrekturen? Das ist ein Outcome. Da lebt der ROI.

Auf Tool-Ebene zu messen ist bequem, weil die Zahlen leicht zu ziehen sind. Auf Ergebnisebene zu messen erfordert, dass du definierst, wie ein gutes Ergebnis aussieht. Das erzwingt eine Qualitätsdiskussion, für die viele Teams noch nicht bereit sind. Führ diese Diskussion, bevor du shippen. Sie macht alles andere schärfer.

Das Produktions-Mindset in der Praxis

Bei Studio Hyra liegt diese Arbeit in dem, was wir Track B nennen. Track A ist der schnelle, meinungsstarke Build: assisted Coding, schnelles Prototyping, etwas Echtes in wenigen Wochen vor Menschen bringen. Track B ist die Disziplin, die folgt. Kein Handoff, kein separates Projekt. Dasselbe Denken, angewendet auf die Frage, ob das, was wir gebaut haben, über die Zeit auch wirklich verlässlich ist.

Diese Rahmung verändert das Gespräch mit dem Kunden. Wenn Track A und Track B zwei separate Projekte mit zwei separaten Budgets sind, bleibt der Kunde oft bei Track A stehen und geht davon aus, dass die Arbeit getan ist. Wenn sie zwei Phasen desselben Bogens sind, tauchen die Produktionsfragen früh auf: im Design, beim Aufbau des Scaffoldings, bevor die Demo überhaupt fertig ist.

Das Prinzip "Decision Making, Speed of Taste", mit dem wir arbeiten, ist auch hier relevant. Schnelles Urteilsvermögen bedeutet, eine Entscheidung zu treffen, ohne einen dreiwöchigen Analysezyklus zu durchlaufen. In der Agent-Produktion heißt das: Du schaust dir an einem Dienstagmorgen die Task-Success-Rate an und entscheidest bis Mittag, ob du den Agenten zurückziehen, einen Prompt anpassen oder einen Tool-Call umleiten musst. Diese Entscheidungsgeschwindigkeit setzt voraus, dass die Instrumentierung bereits vorhanden ist. Improvisation mitten im Incident ist keine Option.

Was du diesen Monat angehen solltest

Du hast einen Piloten laufen und denkst über den Weg in den Produktivbetrieb nach? Dann beantworte drei Fragen, bevor du eine einzige Zeile Infrastrukturcode schreibst.

Erstens. Wie sieht ein erfolgreicher Lauf dieses Agenten aus, in einem Satz, den jemand ohne technischen Hintergrund versteht? Wer diesen Satz nicht formulieren kann, kann den Agenten auch nicht sinnvoll überwachen.

Zweitens. Was ist das Schlimmste, das dieser Agent unbemerkt tun kann? Ein schlechter E-Mail-Entwurf ist verkraftbar. Ein Schreibzugriff auf einen Kundendatensatz oder ein Zahlungsauslöser nicht. Analysiere das Risikoprofil, bevor du entscheidest, wie viel Eingriffsmöglichkeit und Rollback du wirklich brauchst.

Drittens. Wer verantwortet diesen Agenten in sechs Monaten? Nicht das Team, das ihn gebaut hat. Die Person, die nachts angerufen wird, wenn er anfängt zu driften. Die die Logs liest. Die entscheidet, ob neu trainiert oder ersetzt wird. Steht kein Name dahinter, ist der Agent nicht produktionsreif, egal wie überzeugend die Demo war.

Diese drei Fragen kosten einen Nachmittag. Sie ersparen dir Monate.