Das Betriebsmodell entscheidet, nicht das Werkzeug

Viele Unternehmen starten die KI-Einführung mit der Frage nach dem richtigen Modell oder Framework: Claude, GPT, ein Agent-Framework, eine Workflow-Engine wie n8n. Diese Wahl ist selten der Engpass. Der Engpass ist, dass der Agent auf eine Organisation trifft, die für menschliche Bearbeiter gebaut wurde. Eine Person bearbeitet einen Vorgang, eine Führungskraft genehmigt Ausnahmen, ein Ticket-System dokumentiert den Verlauf. Ein Agent bearbeitet hundert Vorgänge parallel, kennt keine Mittagspause – und braucht trotzdem eine Antwort auf die Frage, wer haftet, wenn er falsch liegt.

In den meisten Projekten, die wir sehen, bleibt diese Frage unbeantwortet. Der Agent läuft als Pilot, in einer Sandbox, mit einem Entwickler, der ihn beobachtet. Sobald er in die Fläche soll, fehlt das Betriebsmodell: keine Rolle ist für sein Verhalten verantwortlich, keine Eskalation ist definiert, kein Prozess entscheidet, wann er abgeschaltet wird. Das Ergebnis ist eine überraschend stabile Konstante in der KI-Einführung: Die Demo funktioniert, die Produktion bleibt aus.

Für ein Portfolio-Unternehmen heißt das konkret: Der Business Case in der Value-Creation-Planung war korrekt gerechnet, unterstellte aber, dass der Agent wie ein Feature launcht. In Wirklichkeit launcht er wie eine neue Abteilung – mit eigenem Verantwortungsbereich, eigener Fehlerkultur und eigenem Eskalationsweg.

Ein produktiver Agentenbetrieb braucht mindestens drei neue Rollen, unabhängig von Branche und Unternehmensgröße. Der Agent Owner verantwortet Ergebnis und Verhalten eines Agenten so, wie ein Product Owner ein Feature verantwortet – inklusive Fehlerquote, Eskalationen und Kosten pro Vorgang. Ohne diese Rolle gehört ein Agent niemandem, und was niemandem gehört, wird nicht gepflegt.

Der Reviewer-in-the-loop prüft Ausgaben dort, wo Fehler teuer sind, bevor sie wirksam werden – an klar definierten Punkten: vor einer Zahlung, vor einer Kundenkommunikation mit rechtlicher Wirkung, vor einem Schreibzugriff auf ein Kernsystem. Der Toolchain-Verantwortliche pflegt die Grundlage, auf der der Agent läuft: Prompts, Testfälle, Evals, Modellversionen. Diese Rolle existiert in den meisten Engineering-Organisationen noch nicht, weil sie zwischen Softwareentwicklung und Fachbereich liegt.

Alle drei Rollen lassen sich meist mit vorhandenem Personal besetzen. Der Agent Owner ist oft der bisherige Prozessverantwortliche aus dem Fachbereich, nicht aus der IT. Der Reviewer ist eine erfahrene Fachkraft aus Support, Finanzen oder Operations. Entscheidend ist nicht, wer die Rolle übernimmt, sondern dass sie explizit vergeben und nicht implizit vorausgesetzt wird.

Diese drei Rollen brauchen einen festen, kurzen Rhythmus, in dem sie sich abstimmen – einen wöchentlichen Blick auf dieselben Zahlen: Wie viele Fälle hat der Agent bearbeitet, wie viele eskaliert, wo lag die Fehlerquote, welche Änderung an Prompt oder Freigabegrenze steht an. Der Agent Owner bringt die fachliche Sicht, der Reviewer die Fehlerbeispiele der Woche, der Toolchain-Verantwortliche die technische Erklärung dafür.

Ohne diesen Rhythmus fallen die drei Rollen auseinander: Der Agent Owner sieht nur Ergebnisse, ohne die Ursache zu verstehen. Der Reviewer sammelt Fehler, ohne dass sie in eine Verbesserung münden. Der Toolchain-Verantwortliche ändert Prompts, ohne zu wissen, welche fachliche Wirkung das hat. Der Rhythmus ist der Mechanismus, der aus drei Einzelrollen ein Betriebsmodell macht.

Der Reflex vieler Organisationen ist, ein zentrales Kontrollgremium für KI einzurichten, das jeden Agenten-Einsatz freigibt. Das bremst genau die Fälle aus, in denen ein Agent den größten Hebel hat – hohe Fallzahl, geringes Einzelrisiko –, und schützt kaum vor den Fällen mit echtem Risiko. Wirksamer sind Freigabegrenzen, die direkt im Agenten verankert sind: ein Betragsschwellenwert, ab dem eine Transaktion an einen Menschen geht; eine Datenklasse, die ein Agent nie ungeprüft verändern darf; ein Kundensegment, bei dem jede Kommunikation vor dem Versand gegengelesen wird.

Diese Schwellenwerte macht man explizit, dokumentiert und regelmäßig überprüft – nicht implizit im Prompt vergraben. Und sie sind kein einmal festgelegter Zustand, sondern ein Regler: Mit belegter Trackrecord sinkt der Anteil der Fälle, die an einen Menschen gehen. Ohne belegte Trackrecord bleibt er hoch. Governance wird damit zu einer messbaren Größe statt zu einer Grundsatzentscheidung.

Ein Beispiel aus der Praxis zeigt den Unterschied: Eine schlechte Freigabegrenze lautet „jede Kundenantwort wird vor dem Versand geprüft“ – das skaliert nicht und macht den Agenten zur Fußnote der menschlichen Arbeit. Eine gute Freigabegrenze lautet „Antworten zu Standardanfragen gehen direkt raus, Antworten mit Rückerstattung über einem Schwellenwert oder mit erkennbarer Unzufriedenheit im Ton gehen an einen Menschen“. Der Unterschied liegt in der Präzision der Grenze, nicht im Vertrauen in die Technologie.

Agentic Engineering verwischt die Grenze zwischen Bauen und Betreiben. Ein Agent, der in Produktion läuft, braucht Monitoring wie ein Softwaredienst – Fehlerquote, Latenz, Kosten pro Aufruf – und zusätzlich eine fachliche Qualitätsmessung, die kein klassisches Ops-Team abdeckt: Hat der Agent die richtige Antwort gegeben, nicht nur eine syntaktisch gültige?

Diese Rückkopplung von der Produktion in die Prompt- und Eval-Entwicklung ist der Kern eines funktionierenden Betriebsmodells. Wer trägt den Pager, wenn ein Agent um zwei Uhr nachts anfängt, falsche Entscheidungen zu treffen? Ohne eine klare Antwort verschlechtert sich ein Agent still, jedes Mal, wenn sich das zugrundeliegende Modell, die Datenlage oder das Kundenverhalten ändert – und niemand bemerkt es, bis der Schaden sichtbar wird.

Praktisch bedeutet das: eine Eval-Suite, die vor jeder Änderung an Prompt oder Modellversion läuft, so wie ein Testlauf vor jedem Software-Release läuft; ein Dashboard, das Fehlerquote und Eskalationsrate über die Zeit zeigt, nicht nur den aktuellen Wert; und eine feste Regel, wer eine Regressions-Warnung sieht und wer entscheidet, ob der Agent bei einer Verschlechterung sofort auf die vorherige Version zurückgesetzt wird.

Agenten-Wildwuchs: Jedes Team baut sich seinen eigenen Agenten, ohne zentrales Register. Niemand weiß mehr, wie viele Agenten mit welchen Rechten laufen. Fehlender Audit-Trail: Ein Agent trifft Entscheidungen, aber niemand kann im Nachhinein rekonstruieren, welche Daten er gesehen und welche Regel er angewendet hat – ein Problem, das spätestens bei der ersten Kundenbeschwerde oder Prüfung eskaliert.

Lebenszyklus wie ein Chatbot: Der Agent wird eingeführt und danach nicht mehr verändert – keine Versionierung, kein Rollback, kein geplantes Ende für Experimente, die nicht funktionieren. Change Management übersprungen: Mitarbeitende, deren Aufgabe ein Agent übernimmt, werden nicht eingebunden. Der Widerstand, der daraus entsteht, wird dann fälschlich als Technologieproblem behandelt, obwohl er ein Führungsproblem ist.

Freigabegrenzen und Owner sind keine technischen Details, die man dem Engineering-Team überlässt. Sie sind Governance-Entscheidungen, die genauso in die Geschäftsführung und den Beirat gehören wie eine neue Kreditlinie. Ein belastbarer Bericht an den Aufsichtsrat listet konkret: welche Agenten laufen, mit welchen Freigabegrenzen, welche Fehlerquote sie haben, wer sie verantwortet.

Diese Sichtbarkeit ist auch der Unterschied zwischen einer AI-Initiative, die im nächsten Budgetzyklus überlebt, und einer, die als Kostenposition ohne erkennbaren Verantwortlichen gestrichen wird.

Sobald ein Unternehmen – oder ein PE-Portfolio über mehrere Beteiligungen hinweg – mehrere Agenten betreibt, reicht das Betriebsmodell für einen einzelnen Workflow nicht mehr. Es braucht ein leichtes zentrales Register: welche Agenten existieren, mit welchem Owner, welchen Rechten, welcher Freigabegrenze. Das ist kein neues Kontrollgremium, sondern eine Bestandsliste, ähnlich der Liste kritischer Lieferanten oder Systeme, die in jeder Governance ohnehin geführt wird.

Die Entscheidungsrechte bleiben dabei lokal: Der Agent Owner in der jeweiligen Fachfunktion oder Portfolio-Gesellschaft trifft die operativen Entscheidungen. Zentral standardisiert wird nur das Format, in dem berichtet wird – dieselben Kennzahlen, dieselbe Struktur für Freigabegrenzen –, damit eine Geschäftsführung oder ein Operating Partner mehrere Agenten vergleichen kann, ohne für jeden eine eigene Sprache zu lernen.

Der pragmatische Einstieg ist ein Betriebsmodell für einen einzigen Workflow. Ein Team wählt einen Prozess mit hoher Fallzahl und moderatem Risiko, definiert Owner, Freigabegrenzen, Monitoring und Eskalationspfad für genau diesen Prozess und bringt ihn in Produktion. Das Modell, das dabei entsteht, ist der Bauplan für den nächsten Agenten – nicht eine Präsentation, die vorher geschrieben wurde.