Die meisten Produktions-Workflows funktionieren nur, weil erfahrene Mitarbeiter sie am Laufen halten. Sie wissen, welche CRM-Felder veraltet sind und welche Slack-Nachrichten nicht bis morgen warten können. Nichts davon erscheint normalerweise im Workflow-Diagramm, aber das Geschäft ist täglich davon abhängig.

KI-Agenten ändern diesen Ansatz. Sobald ein Agent beginnt, Schritte selbstständig zu planen und auszuführen, werden die Schwachstellen des Workflows viel schwerer zu verbergen. Und nun muss die Urteilsfähigkeit, die früher im Kopf eines Menschen saß, in das System integriert werden: Regeln, Berechtigungen, Eskalationspfade, Genehmigungspunkte und Ausnahmen. Andernfalls wird der Agent die Unklarheit nicht beheben. Er wird sie lediglich schneller ausführen.

Das ist die Aufgabe eines KI-Betriebsmodells. Es ist kein weiteres Transformations-Framework oder eine Folie mit fünf Säulen und einem futuristischen Symbol in der Mitte.

Es ist eine funktionierende Spezifikation dafür, wie KI in das Unternehmen integriert wird. Welche Aufgaben kann der Agent erledigen? Aus welchen Systemen kann er lesen? Wohin darf er schreiben? Wann genehmigt ein Mensch den nächsten Schritt? Und wem gehört das Ergebnis, wenn der Workflow abgeschlossen ist?

Ohne diese Spezifikation setzen Sie Agenten nicht wirklich in Produktion ein. Sie lassen ein System mit Urteilsvermögen, Unsicherheit und Tool-Zugriff innerhalb des Unternehmens ohne klare Verträge agieren.

Was ein KI-Betriebsmodell bedeutet

gemeinsam .In diesem Modell entscheiden Unternehmen, wie die Arbeit zwischen einem Menschen, einem Agenten, einem CRM, einem Genehmigungsschritt, einer Überwachungsebene und manchmal einem kundenorientierten System wechselt.

Bevor ein Unternehmen mit dem Aufbau von Agenten beginnt, sollte es einige grundlegende Dinge über das System verstehen, das es schaffen will. Diese Fragen stellen keine vollständige Methodik dar. Aber es sind die Art von Fragen, die wir verwenden, wenn wir Kunden dabei helfen, eine KI-Idee in etwas umzuwandeln, das in einem realen Workflow bestehen kann:

Umfang:

1. Genau welche Aufgaben kann der KI-Agent ausführen? Zugriff:
2. Auf welche führenden Systeme und Tools darf er zugreifen? Genehmigung:
3. Welche Entscheidungen erfordern eine Genehmigung durch einen Menschen (Human-in-the-Loop)? Ausnahmen:
4. Wie ist das Vorgehen, wenn der Agent unsicher oder blockiert ist?
5. Verantwortung: Wer ist rechtlich und operativ für das Ergebnis verantwortlich?

Deloitte: Der Stand der KI in Unternehmen 2026 zeigt dasselbe Problem im großen Maßstab. Der Zugang zu KI wächst schneller als die Neugestaltung von Geschäftsprozessen. Immer mehr Mitarbeiter nutzen KI, und die meisten Unternehmen erwarten, Agenten an ihre eigenen Prozesse anzupassen, doch wesentlich weniger berichten von einer tiefgreifenden Unternehmenstransformation.

Diese Lücke soll ein KI-Betriebsmodell schließen. Es wandelt die KI-Einführung in ein operatives Design um: Workflows, Zugriffsregeln, Governance, Infrastruktur, Rollen und Metriken, die Agenten in der Produktion tatsächlich unterstützen können.

Gestaltung des Betriebsmodells 

Die Neugestaltung des Unternehmens für agentische Arbeit erfordert einen mehrschichtigen Ansatz, bei dem Governance, Architektur und Betrieb als untrennbar betrachtet werden.

1. Workflow-Karte: Definieren Sie die Arbeit vor dem Agenten

Das erste Ergebnis ist der Workflow selbst, nicht der Agent. Bevor ein Modell ausgewählt oder ein Prompt geschrieben wird, benötigt das Team eine dokumentierte Beschreibung der Arbeit, die der Agent ausführen wird. Es umfasst: 

• Auslösendes Ereignis
• Eingabedaten, von denen die Arbeit abhängt
• Entscheidungspunkte entlang des Weges
• Systeme, in die die Arbeit schreibt
• Menschliche Freigabeschritte, die den Prozess gliedern

Das klingt einfach, ist es aber nicht. Die Workflows, die auf einer Folie am einfachsten aussehen, sind in der Regel diejenigen, die in der Produktion durch undokumentiertes menschliches Urteilsvermögen überleben. Ein Lead-Qualifizierungs-Workflow, der in einem Kick-off-Meeting reibungslos abläuft, wird in der Praxis zu einer Abfolge kleiner Ermessensentscheidungen darüber, welche Datensätze zusammengeführt und welche Leads als Duplikate von bereits in der Pipeline befindlichen Konten übersprungen werden sollen. Die Karte muss den Workflow so erfassen, wie er tatsächlich abläuft, nicht wie er in der SOP dargestellt ist.

Eine nützliche Workflow-Karte ist auch eine Umfangsvereinbarung. Alles, was außerhalb der dokumentierten Auslöser, Eingaben, Entscheidungspunkte, Systeme und Genehmigungen liegt, fällt nicht in die Zuständigkeit des Agenten. Wenn der Agent auf einen Fall stößt, den die Karte nicht beschreibt, ist das richtige Verhalten, zu eskalieren, nicht zu improvisieren.

Diese Einschränkung macht das Verhalten des Agenten später überprüfbar. Ohne eine dokumentierte Karte erfordert die spätere Überprüfung der Aktionen des Agenten eine Rekonstruktion des Workflows aus der Erinnerung des Teams.

Die Karte ist das operative Artefakt. Sie ist das, was ein Entwicklungsteam implementieren, ein CTO überprüfen und ein Compliance Officer auditieren kann. Solange sie nicht existiert, können keine der nachgelagerten Designentscheidungen mit Zuversicht getroffen werden.

2. Daten- und Kontextebene: Eine vertrauenswürdige Version der Realität

Die Workflow-Karte definiert, was der Agent tun soll. Die Daten- und Kontextebene bestimmt, was der Agent dafür wissen muss. Agenten leiten die Geschäftsrealität nicht von Grund auf neu ab. Sie agieren auf Basis dessen, was sie zur Laufzeit lesen können. Wenn die gelesenen Daten unvollständig oder über verschiedene Quellen hinweg widersprüchlich sind, übernehmen die Aktionen des Agenten diese Probleme.

Zwei Fehlerursachen sind erwähnenswert. Die erste ist direkt: Der Agent liest ein veraltetes Feld und handelt danach. Die zweite ist subtiler: Der Agent liest korrekte Daten, aber diese Daten enthalten nicht den Kontext, den ein Mensch zur Interpretation verwendet hätte.

Der NPS-Wert eines Kunden sieht isoliert betrachtet wie eine Metrik aus. Derselbe Wert, zusammen mit dem Vertragswert des Kunden, aktuellen Support-Tickets und dem Verlängerungsdatum gelesen, sieht wie eine Entscheidungsgrundlage aus. Der Agent agiert nur auf Basis des Kontexts, den die Datenschicht bereitstellt.

Die meisten Produktionsdaten sind in drei oder vier führenden Systemen verteilt, die von verschiedenen Teams gepflegt werden, unterschiedliche Aktualisierungszyklen haben und unterschiedliche Definitionen dessen, was als maßgeblich gilt. Der Agent weiß nichts davon. Er liest, was die Integrationsschicht bereitstellt, und behandelt es als absolute Wahrheit.

Deshalb muss die Datenschicht den Speicher verwalten. Speicher im Sinne eines Agenten ist umfassender als der Sitzungsstatus. Er ist der Mechanismus, durch den Agenten Kontext über mehrere Läufe hinweg ansammeln und vermeiden, bei jeder Ausführung von Null zu beginnen. Vier Arten sind relevant:

Ein Hinweis zum graphenbasierten Speicher, der die meisten Agentenarchitekturen letztendlich in Schwierigkeiten bringt. Vektorähnlichkeit ist gut genug für „ähnliche Passagen finden“, aber nicht für „die Beziehungen dieser Entität über fünf Sprünge hinweg verfolgen“. Für einen Agenten, der auf einer Multi-Tenant-SaaS-Plattform, in einem regulierten FinTech-Workflow oder in jedem System agiert, in dem Entitäten sinnvolle Beziehungen zueinander haben (Kunde → Vertrag → Rechnung → Zahlung → Verlängerung), ist ein graphenbasierter Speicher das, was mehrstufiges Denken zuverlässig macht.

3. Umfang und Befugnis

Zwei Entscheidungen liegen dem zugrunde, was die meisten Teams als „was der Agent tut“ bezeichnen. Die erste ist der Umfang der Arbeitsklasse, die dem Agenten zugewiesen wird. Die zweite ist die Befugnis: wie unabhängig er bei dieser Arbeit handeln darf. Diese sehen von außen ähnlich aus, sind aber unterschiedliche Probleme und erfordern unterschiedliche Kontrollen.

Bezüglich des Umfangs scheitern abteilungsbezogene Bezeichnungen („ein Finanzagent“, „ein Vertriebsagent“, „ein Support-Agent“) in der Produktion oft, weil sie eine Organisationseinheit beschreiben und nicht eine Arbeitseinheit. 

Ein Finanzagent, der „alles Finanzbezogene“ bearbeitet, erbt die Mehrdeutigkeit der Finanzfunktion selbst. Eine produktionsreife Abgrenzung bindet einen Agenten an eine spezifische Verantwortung: einen Geschäftspartner vor Abschluss eines Geschäfts recherchieren, ein eingehendes Ticket anhand einer definierten Taxonomie klassifizieren und eine Transaktion anhand von Compliance-Regeln validieren. 

Jede Verantwortung bringt ihre eigenen Eingaben, Ausgaben und Fehlerursachen mit sich. Wo Workflows mehrere Schritte erfordern, koordinieren sich mehrere spezialisierte Agenten. Jeder bleibt auf eine einzige überprüfbare Arbeitseinheit beschränkt.

Bei der Befugnis ist die relevante Frage, wo das Team die Schwelle für die Akzeptanz autonomer Handlungen zieht. Vier Stufen decken die meisten Produktionsimplementierungen ab:

Umfang und Befugnis definieren zusammen, wofür der Agent da ist und wie viel Unabhängigkeit das Team ihm in jeder Phase gewährt. Ohne diese im Voraus getroffenen Entscheidungen wird die Einführung des Agenten zu einer kontinuierlichen Improvisation, bei der Ingenieure, Betrieb und das Geschäft die Rolle des Agenten jedes Mal neu verhandeln, wenn etwas schiefgeht.

4. Grenzen und Laufzeitkontrolle

Sobald ein Agent Umfang und Befugnis hat, ist die nächste Entscheidung, wohin er reichen darf und was ihn stoppt, wenn etwas schiefgeht. Teams legen die Grenze zur Entwurfszeit fest, und die Laufzeitkontrolle setzt sie durch, wenn der Agent auf Randfälle stößt, die das Team nicht vorhergesehen hat.

Die richtige Herangehensweise ist, einen bereitgestellten Agenten als digitalen Insider mit Schreibzugriff zu behandeln. Das Team, das den Agenten bereitstellt, hat einem nicht-deterministischen Akteur interne API-Berechtigungen erteilt. Dies erfordert die architektonische Disziplin, die für menschlichen privilegierten Zugriff verwendet wird, plus mehrere spezifische Kontrollen für Agenten.

Vier Kontrollen erledigen den Großteil der Arbeit in der Produktion:

Zwei Praktiken ergänzen die Kontrollen:

• Red Teaming. Sonden für agentenspezifische Schwachstellen: indirekte Prompt-Injektion durch abgerufene Dokumente, Manipulation von Tool-Aufrufen, Exfiltration über legitime Kanäle.
• Haftungszuweisung. Die Organisation, die die Autorität des Agenten definiert und dessen Umgebung kontrolliert hat, trägt die Verantwortung, wenn etwas schiefgeht.

Beide Entscheidungen müssen getroffen werden, bevor der Agent ausgeliefert wird. Wird eine davon ausgelassen, muss das Team in der Produktion improvisieren.

5. Messmodell: Workflow-Verbesserung statt KI-Aktivität

Sobald ein Agent in Produktion ist, stellt sich die Frage, ob der Workflow verbessert wurde. Die meisten Teams beantworten dies mit den falschen Metriken. Token-Nutzung und Akzeptanzraten messen, wie oft die KI verwendet wurde, nicht aber, ob die Arbeit besser geworden ist.

Eine nützliche Messung trennt Ergebnis-Metriken (war der Workflow besser?) von Metriken zur operativen Gesundheit (verhält sich der Agent wie vorgesehen?). Beides ist wichtig und erfordert unterschiedliche Instrumentierung.

Metriken nach Autonomie-Stufe lesen:

• Shadow. Die Übereinstimmungsrate verfolgen. Stimmt der Vorschlag des Agenten mit dem überein, was der Mensch getan hätte? Eine geringe Übereinstimmung ist ein Kalibrierungssignal, keine Bereitstellungsfehler.
• Überwacht. Die Genehmigungsrate und die Genehmigungszeit beobachten. Reflexartige Genehmigungen bedeuten, dass der Mensch nur abnickt. Langsame Genehmigungen bedeuten, dass der Workflow nicht schneller ist als der manuelle.
• Geführt. Eindämmungsrate und Überschreibungsrate. Eine hohe Überschreibungsrate bedeutet, dass die Grenze falsch ist.
• Autonom. Ergebnisqualität im Vergleich zu den Geschäfts-KPIs, die der Workflow bereits hatte.

Was das Betriebsmodell nicht messen sollte: wie viel KI verwendet wurde. Akzeptanzmetriken sagen dem Team, dass die KI genutzt wird, nicht aber, dass sie bessere Arbeit leistet. Machen Sie die operativen Metriken zur primären Bewertungsgrundlage.

6. Verantwortlichkeitsmodell: Namen in der Pflicht

Verantwortlichkeit entscheidet, wer für das System einsteht, wenn es nicht funktioniert. Ohne diese vorherige Entscheidung verteilen sich autonome Fehler auf den Modell-Anbieter, den Plattform-Anbieter, das Integrationsteam und die Geschäftseinheit, bis niemand mehr die Konsequenzen trägt. Verantwortlichkeitsdiffusion ist der absehbare Endzustand, wenn die Verantwortlichkeit undefiniert bleibt.

Das Betriebsmodell weist namentlich genannten Personen bestimmte Rollen zu. Vier davon decken die meisten Produktivbereitstellungen ab:

Zwei strukturelle Anmerkungen dazu, wie diese Rollen zusammenhängen:

• Business Owner und Technical Owner sind Dual-Key. Gemeinsam entscheiden sie, ob der Agent ausgeliefert wird, seinen Umfang erweitert oder in eine höhere Autonomiestufe aufsteigt. Keiner von beiden kann alleine handeln.
• Data Owner und Modellaufsicht sind Spezialfunktionen. Sie berichten an einen oder beide der Dual-Key-Owner, abhängig von der Struktur der Organisation.

Ein Praxistest: Wenn der Agent ein unerwartetes Ergebnis liefert, sollte das Team innerhalb von fünf Minuten benennen können, welche dieser vier Rollen für die Reaktion zuständig ist. Wenn die Klärung der Antwort ein Meeting erfordert, ist das Verantwortlichkeitsmodell nicht etabliert.

Die sechs in diesem Abschnitt behandelten Entscheidungen definieren das Betriebsmodell: Workflow, Daten und Kontext, Umfang, Befugnis, Laufzeitkontrolle und Messung. Die Benennung der Verantwortlichen macht diese Entscheidungen durchsetzbar.

Ein CEO/CTO-Entscheidungsfilter: Sind Sie bereit für ein KI-Betriebsmodell?

Bevor Sie einen Agenten entwickeln oder skalieren, unterziehen Sie das Betriebsmodell einer Diagnose. Sechs Fragen, eine pro Designentscheidung. Ziel ist es, Lücken aufzudecken, die vor der Bereitstellung geschlossen werden sollten, nicht um das Projekt zu blockieren.

Der Filter ist eine Diagnose, kein Hindernis. Teams, die alle sechs Fragen souverän beantworten können, können einen Agenten ausliefern. Teams, die dies nicht können, erhalten eine klare Spezifikation dessen, was sie entwerfen müssen, bevor sie dies tun.

Fazit

Das oben genannte Framework ist am nützlichsten als Landkarte, nicht als Projektplan. Nur wenige Organisationen müssen das gesamte Betriebsmodell auf einmal neu gestalten. Die meisten müssen die sechs Entscheidungen auf einen einzelnen Workflow anwenden, den resultierenden Agenten ausliefern, lernen, was das Framework in ihrem spezifischen Kontext übersehen hat, und dann von dort aus erweitern.

Die Wahl des richtigen ersten Workflows ist wichtiger als die Wahl des richtigen Modells. Die stärksten Kandidaten weisen drei Eigenschaften auf: ein ausreichend hohes Volumen, um die Automatisierung lohnenswert zu machen, ausreichend gut dokumentiert, um ohne monatelange Recherche eingegrenzt werden zu können, und einen ausreichend begrenzten Schadensradius, sodass ein Fehler eher Aufwand als Kunden oder den Compliance-Status kostet. In der Lieferpraxis von Codebridge, sehen die typischen ersten Workflows wie folgt aus:

• Compliance-Triage in einem regulierten FinTech-Workflow, bei dem der Agent Fälle klassifiziert und die mehrdeutigen an Menschen weiterleitet
• Patientenaufnahme oder Terminplanung in einer HealthTech-Plattform, bei der der Agent strukturierte Datensätze liest und die Fälle hervorhebt, die einer klinischen Überprüfung bedürfen
• Wissensabruf innerhalb eines Steuer- oder Rechtsberatungsteams, bei dem der Agent relevante Präzedenzfälle abruft und den Spezialisten die Beurteilung vornehmen lässt

Bevor die Entwicklung beginnt, sollten die sechs Designentscheidungen an einem Ort dokumentiert werden. Kein 40-seitiges Strategiepapier. Eine Spezifikation, die kurz genug ist, um in einem Zug gelesen zu werden, und die den Workflow, von Agenten gelesene Daten, Umfang und Berechtigungsstufe, Leitplanken und Laufzeitkontrollen, Erfolgsmetriken sowie die vier benannten Verantwortlichen umreißt. Sobald dieses Dokument existiert, ist die Entwicklungsarbeit umsetzbar. Ohne es arbeitet das Team auf der Grundlage von Annahmen, denen niemand zugestimmt hat.

Der Vorteil im Zeitalter der Agenten wird operativer Natur sein. Produktionssoftware lief lange Zeit mit einer versteckten Subvention menschlichen Urteilsvermögens. Agenten verlagern diese Arbeit auf das dokumentierte System, was bedeutet, dass es sich lohnen muss, dieses System zu betreiben. Es ist das Betriebsmodell, das den Betrieb darauf lohnenswert macht.