Wer verantwortet Maschinenarbeit? Das Operating Model für Agentic AI

Sobald Software handelt, wird sie zur Frage des Operating Models

Ein Onboarding-Agent kann Arbeit schneller erledigen und trotzdem eine falsche Kundenkonfiguration, eine unzulässige Zusage oder mehr Supportarbeit hinterlassen. Software kann heute Kundendatensätze ändern, Kunden kontaktieren, Preise oder kommerzielle Abläufe verändern, Transaktionen auslösen, Systeme ausrollen oder ändern und Budget verbrauchen. Sobald sie für das Unternehmen handelt, delegiert das Unternehmen Handlungsmacht. Die Führung muss entscheiden: Welche Ergebnisse werden besser, welche Zusagen sind erlaubt und wer trägt die Folgen?

Ein AI Assistant bereitet eine Antwort vor. Ein AI Agent kann ein Ziel interpretieren, Schritte wählen, Werkzeuge nutzen und in Systemen handeln. Die Führungsfrage lautet deshalb: Wie arbeitet das Unternehmen, wenn Software beginnt, folgenreiche Arbeit auszuführen?

Dafür braucht es ein Operating Model für Agentic AI: das Geschäftsergebnis klar zuordnen, delegierte Handlungsmacht begrenzen und Maschinenarbeit wirtschaftlich sinnvoll betreiben.

Agentic AI erzeugt Maschinenarbeit. Maschinenarbeit braucht einen menschlichen Verantwortlichen.

Das Ziel sind bessere Produkte, Kundenergebnisse und wirtschaftliche Abläufe—nicht möglichst viele Agenten. Kontrollen sollen dieses Ergebnis ermöglichen und sich an den Folgen einer Handlung orientieren.

Ein Agent ist kein digitaler Mitarbeiter

Der Begriff „digitaler Mitarbeiter“ ist attraktiv, weil er neue Technologie vertraut erscheinen lässt. Gleichzeitig führt er in die Irre.

Ein Mensch wird durch Arbeitsverhältnis, Führung, Richtlinien, Zugriffsrechte und etablierte Verantwortungsstrukturen Teil einer Organisation. Ein Agent bringt keine dieser Beziehungen mit. Er erhält technische Identität, Berechtigungen, Instruktionen, Tools, Modelle und Datenzugänge, weil Menschen sie entwerfen und autorisieren.

OpenAIs Praxisleitfaden für AI Agents beschreibt Agenten als Systeme, die Aufgaben selbstständig im Auftrag eines Nutzers erledigen, und grenzt sie von Anwendungen ab, bei denen ein Modell lediglich eine Antwort erzeugt. Der operative Unterschied ist entscheidend: Ein Agent kann einen Workflow über Tools ausführen, statt nur den nächsten Schritt vorzuschlagen.

Autonomie ist delegierte Handlungsmacht, kein Produktmerkmal. Das Unternehmen entscheidet, was Software unter Unsicherheit tun darf.

Wer einen Agenten als Mitarbeiter bezeichnet, verdeckt leicht den wichtigsten Punkt: Die Maschine kann keine Unternehmensverantwortung tragen. Sie kann Arbeit ausführen. Für Zweck, gewünschtes Ergebnis und akzeptable Folgen bleibt ein menschlicher Executive oder Business Owner verantwortlich.

Ein Agent kann einen Task-Status besitzen. Die geschäftliche Konsequenz kann er nicht besitzen.

Jemand muss das Kunden- und Betriebsergebnis verantworten

Ein Unternehmen kann einen Agenten bauen, bevor es geklärt hat, wem er gehört.

Technology verantwortet möglicherweise die Plattform. Ein Fachbereich fordert den Use Case. Security definiert Kontrollen. Legal oder Risk prüfen. Finance finanziert. Ein Anbieter betreibt Teile des Stacks. Wenn die Leistung sinkt oder eine Aktion Schaden verursacht, verweist jede Partei auf eine andere Grenze.

Das ist keine geteilte Ownership. Es ist fragmentierte Verantwortlichkeit.

Microsofts Architektur für Agentenidentitäten zeigt, wie sich die technische Control Plane entwickelt. Mit Microsoft Entra Agent ID beschreibt Microsoft eigene Agentenidentitäten, benannte Verantwortliche, begrenzte Berechtigungen und Zugriffslaufzeiten. Google beschreibt Agent Registry, Agent Identity, Policy Enforcement und überwachte Gateways für kontrollierte agentische Workloads. Die AI Agent Standards Initiative des NIST nennt Sicherheit und Identität von Agenten ausdrücklich als Standardisierungsthema.

Das sind wichtige Entwicklungen der Control Plane. Sie entscheiden jedoch nicht, wer für ein kommerzielles, kundenbezogenes oder operatives Ergebnis einsteht. Eine Registry kann einen Agenten identifizieren; das Geschäftsergebnis kann sie nicht verantworten.

In einer IBM-Befragung von 2.000 Technology Executives aus dem Jahr 2026 gaben zwei Drittel an, für AI-Systeme verantwortlich zu sein, die sie nicht vollständig kontrollieren. Die Befragung zeigt ein Führungsproblem: Wer ein Kunden- oder Betriebsergebnis verantwortet, braucht auch Einfluss auf die Systeme, die es erzeugen.

Sechs Entscheidungen, bevor Software für das Unternehmen handelt

Ein Unternehmen braucht nicht für jeden Agenten ein separates Operating Model. Es braucht eine konsistente Antwort auf sechs Entscheidungen, sobald Software relevante Handlungsmacht erhält.

Entscheidung	Was muss die Unternehmensführung wissen?	Konsequenz für die Gestaltung
Ergebnis	Wer verantwortet das Kunden- und Geschäftsergebnis?	Ein verantwortlicher Business Owner und ein klares Erfolgsmaß
Handlungsmacht	Wozu darf Software das Unternehmen verpflichten?	Kleinste ausreichende Befugnis; klare Freigabegrenzen
Identität	Wessen delegierte Befugnis hat diese Aktion ermöglicht?	Zurechenbare Aktionen und Berechtigungen mit Lebenszyklus
Evidenz	Funktioniert der gesamte Ablauf und schafft er Wert?	Ergebnisse, Fehler und Kundenfolgen prüfen—nicht nur Outputs
Intervention	Wer kann eingreifen, Fehler beheben und den Betrieb fortführen?	Praktikable Eskalation, Wiederherstellung und Abschaltrechte
Wirtschaftlichkeit	Ist das Ergebnis nach allen Betriebskosten besser?	Vollkosten je erfolgreichem Geschäftsergebnis gegenüber einer einfacheren Lösung

Die sechs Entscheidungen verstärken sich gegenseitig. Ein benannter Owner ohne beobachtbare Aktionen kann nicht steuern. Starkes Monitoring ohne Kompetenzgrenze protokolliert nur unkontrolliertes Verhalten. Ein sicheres System ohne tragfähige Wirtschaftlichkeit bleibt eine schlechte operative Entscheidung.

Ergebnis: ein verantwortlicher Business Owner

Jeder relevante Agent braucht eine Person, die das Kunden- und Geschäftsergebnis verantwortet—nicht nur den fehlerfreien Softwarebetrieb. Diese Person muss den Workflow, das Erfolgsmaß und die Entscheidung über den weiteren Einsatz beeinflussen können. Technology betreibt die Plattform, übernimmt damit aber nicht automatisch jedes Geschäftsergebnis, das sie berührt.

Das erweitert Mit KI erst Arbeit neu gestalten, dann über Kapazität entscheiden: zuerst die Arbeit und ihr Ergebnis klären. Bei Agenten trägt der Workflow-Verantwortliche auch die Folgen der delegierten Handlung.

Handlungsmacht: einen Rahmen definieren, keinen vagen Zweck

„Customer Service unterstützen“ ist ein Zweck, keine Handlungsvollmacht. Legen Sie fest, welche Daten der Agent lesen, welche Datensätze er ändern, welche Kunden er kontaktieren und welche Budgets er verbrauchen darf—und wo eine Freigabe nötig ist.

Eine Wissensbasis zu lesen ist etwas anderes, als eine Rückerstattung auszulösen. Code vorzubereiten ist etwas anderes, als ihn in Produktion zu bringen. Mit Folgen, Irreversibilität oder Unsicherheit sollte der Rahmen enger werden.

Die kleinste ausreichende Befugnis ist meist besser als maximale Autonomie. Autonomie wird je Aktionsklasse verdient, nicht als allgemeiner Agentenstatus vergeben.

Identität: Maschinenhandlungen zurechenbar machen

Gemeinsame Zugangsdaten können verschleiern, wer gehandelt hat. Enterprise AI Agents brauchen eigene, begrenzte Identitäten und Aktionsprotokolle, die Ausführung mit Agentenversion, Modell, Tools, Berechtigungen, Nutzerkontext und Verantwortlichem verbinden. Menschliche Credentials dürfen Maschinenhandlungen nicht als Entscheidung dieser Person erscheinen lassen.

Endet der Zweck oder ändern sich Verantwortlicher, Rechte oder Abhängigkeiten, müssen Zugriffe auslaufen oder neu autorisiert werden. Registries und Identitätsplattformen unterstützen diesen Lebenszyklus; die Delegation bleibt Unternehmensverantwortung. Zurechenbarkeit verbindet Architektur mit operativer Verantwortung.

Evidenz: das System evaluieren, nicht die Demo

Eine überzeugende Demo belegt weder Kundennutzen noch Betriebsreife. Prüfen Sie vollständige Workflows gegen das gewünschte Geschäftsergebnis und einen Vergleichsmaßstab: erfolgreiche Ausführung, verbotene Aktionen, Ausnahmen, Zuverlässigkeit, Kundenfolgen, Prüfaufwand und Kosten. Grenzfälle und adversariale Bedingungen gehören innerhalb des definierten Handlungsrahmens dazu.

Das Industrial AI Production Readiness Model folgt derselben Produktionslogik. Bei Agenten geht die Evaluation nach dem Start weiter, weil Aktionen und Abhängigkeiten sich verändern. Entscheidend ist, ob die aktuelle Befugnis weiterhin vertretbare Ergebnisse erzeugt—nicht, ob ein einzelner Modellscore gut aussieht.

Intervention: das Recht zum Eingriff gestalten

Menschliche Aufsicht muss ein Ergebnis verändern oder Risiken angemessen reduzieren. Ein Prüfer ohne Kontext, Reaktionszeit oder Befugnis erzeugt Verzögerung statt Kontrolle. Verlangen Sie Freigaben, wo Urteilskraft zählt; nutzen Sie deterministische Grenzen, Monitoring und Stichproben, wo geringe Folgen leichtere Eingriffe erlauben.

Benennen Sie, wer Ausnahmen erhält, Berechtigungen entzieht oder die Ausführung stoppt und wie betroffene Kundenarbeit weitergeht. Wiederherstellung kann Rollback, Korrektur oder manuelle Fortführung bedeuten; manche Zusagen lassen sich nicht zurücknehmen. Ein Mensch in der Schleife ist nur dann nützlich, wenn er etwas bewirken kann.

Wirtschaftlichkeit: Kosten je erfolgreichem Outcome messen

Der Tokenpreis ist nicht die Wirtschaftlichkeit eines Agenten. Messen Sie Vollkosten je erfolgreichem Geschäftsergebnis: Modell- und Plattformnutzung, Integration, Monitoring, menschliche Prüfung, Wiederholungen, Ausnahmen, Incidents und spätere Ablösung. Teilen Sie die Gesamtkosten des Workflows—einschließlich fehlgeschlagener Versuche—durch abgeschlossene Ergebnisse, die die Geschäfts- und Qualitätskriterien erfüllen.

Die AWS-Anleitung zu Kosten je Request in agentischen Workloads verdeutlicht das Transparenzproblem: Monatliche Tokenmengen zeigen nicht die Kosten einer einzelnen Anfrage. Die Führungsentscheidung geht weiter: Vergleichen Sie die vollständige Ergebniswirtschaftlichkeit mit menschlicher Arbeit oder einfacherer Automatisierung, einschließlich Kundenfolgen und knapper Prüfkapazität.

Das erweitert das Technology Value Economics Model. Ein Agent, der Aufgaben günstig erledigt, aber Nacharbeit oder Wartezeit für Kunden erzeugt, hat seinen Wert noch nicht bewiesen.

Hypothetisches Beispiel: Kunden-Onboarding in B2B SaaS

Ein beispielhafter B2B-SaaS-Workflow: Ein Kunde bittet um eine Account-Konfigurationsänderung, um eine Datenquelle anzubinden und einen Workspace zu aktivieren. Ein Agent kann CRM-, Vertrags- und Produktkontext prüfen, den nächsten Schritt wählen, freigegebene Onboarding-Felder aktualisieren, Standardanleitungen versenden, eine interne Engineering-Aufgabe eröffnen und Compute-Budget verbrauchen. Derselbe Ablauf kann den Kundennutzen schneller erreichbar machen—oder eine nicht gedeckte Kundenzusage erzeugen, deren Folgen Operations beheben muss.

Die sechs Entscheidungen verändern die Gestaltung:

Ergebnis: Die Leitung Customer Success verantwortet die erfolgreiche Aktivierung und das Kundenergebnis. Abgeschlossen ist eine funktionierende, akzeptierte Konfiguration mit den nötigen Prüfungen—nicht lediglich ein geschlossenes Ticket.
Handlungsmacht: Der Agent darf freigegebenen Account-Kontext lesen, benannte Onboarding-Felder ändern und Anleitungen aus freigegebenem Material versenden. Vertragsänderungen, Rabatte, Rückerstattungen, Produktions-Deployments und privilegierte Zugriffe benötigen die zuständige menschliche Freigabe. Ein technisch durchgesetztes Compute-Budget begrenzt die Ausführung; bei Erreichen wird sie ausgesetzt und der Fall einem Verantwortlichen zugewiesen.
Identität: Eine begrenzte Agentenidentität verbindet jede Aktion mit Account, Workflow-Durchlauf, Konfigurationsversion und Verantwortlichem. Sie nutzt weder die Credentials eines Account Managers noch erhält sie Zugriff auf Daten anderer Kunden.
Evidenz: Tests umfassen fehlende Daten, widersprüchliche Vertragsbedingungen, doppelte Anfragen, gescheiterte Integrationen und irreführende Eingaben. Im Betrieb werden akzeptierte Aktivierungen, Zeit bis zum Kundennutzen, Kundenkorrekturen und Ausnahmen mit dem bisherigen Ablauf verglichen. Schnellere Ticket-Schließung allein reicht nicht.
Intervention: Unklare Berechtigungsansprüche, Sicherheitsbedenken oder wiederholte Integrationsfehler gehen an Customer Success und das zuständige technische Team. Der Verantwortliche kann den Lauf stoppen und Rechte entziehen; das menschliche Team führt das Onboarding anhand des protokollierten Zustands fort. Kundenzusagen müssen korrigiert werden, wenn ein Rollback unmöglich ist.
Wirtschaftlichkeit: Verglichen werden die Gesamtkosten des Workflows je akzeptierter Aktivierung. Dazu gehören Fehlversuche, Modell- und Tool-Nutzung, Integrationspflege, Monitoring, menschliche Freigaben, Kundenkorrekturen und Ausnahmebehandlung. Maßstab ist der bisherige menschliche oder deterministische Ablauf bei gleicher Qualität.

Damit wird die operative Entscheidung konkret: Routinekoordination delegieren, Kundenzusagen in menschlicher Verantwortung halten und Befugnisse nur erweitern, wenn Ergebnisse und Wirtschaftlichkeit es rechtfertigen.

AgentOps muss Managemententscheidungen ermöglichen

AgentOps wird häufig als Tooling-Schicht für Tracing, Evaluation und Monitoring von Agenten beschrieben. Das ist notwendig, aber unvollständig.

Operations wird nützlich, wenn seine Evidenz Entscheidungen ermöglicht:

Soll der Agent seine aktuelle Handlungsmacht behalten?
Welche Fehlermuster verlangen einen engeren Rahmen?
Löst der Owner Ausnahmen oder wächst verdeckte manuelle Arbeit?
Verbessern sich die Kosten je erfolgreichem Outcome?
Hat eine Änderung an Modell, Tool, Datenquelle oder Anbieter frühere Evidenz entwertet?
Sollte der Agent erweitert, neu gestaltet, pausiert oder stillgelegt werden?

Die OECD-Publikation Agentic AI in organisations untersucht anhand von Praxisinterviews Deployment und Governance als Organisationspraxis. Die operative Frage ist, wie diese Praxis verantwortliche Entscheidungen unterstützt, sobald Agenten reale Workflows übernehmen.

AgentOps darf deshalb nicht zu einem weiteren technischen Dashboard ohne Verbindung zur Linienführung werden. Es ist das Evidenzsystem, über das Business Owner, Technology, Security, Risk und Finance Maschinenarbeit gemeinsam steuern.

Auch zentrale Kontrolle kann zum Fehlermodus werden

Die Antwort auf unkontrollierte Agenten ist nicht unbegrenzte Zentralisierung.

Ein einziges Gremium, das jedes Experiment freigeben muss, bremst Lernen und treibt Teams in nicht registrierte Tools. Ein universeller Kontrollstandard kann einem begrenzten internen Assistant dieselbe Last auferlegen wie einem folgenreichen Finanzagenten. Ein großes Plattformprogramm kann beginnen, bevor das Unternehmen einen einzigen wertvollen Workflow betreibt.

Governance sollte ein gemeinsames Minimum setzen—Inventar, Ownership, Identität, Handlungsmacht, Evidenz und Intervention—und Kontrollen anschließend nach Konsequenz skalieren. Risikoarme Experimente können in begrenzten Sandboxes laufen. Agenten mit größerer Handlungsmacht brauchen stärkere Evidenz und unabhängigere Kontrollen. Zentralisiert werden sollten wiederverwendbare Fähigkeiten und Policies, nicht jede Produktentscheidung.

Das Operating Model muss sicheres Experimentieren einfacher machen als Shadow Deployment.

Wann dieses Modell nicht erforderlich ist

Nicht jedes als Agent vermarktete System leistet Maschinenarbeit.

Wenn ein Tool Text für einen Menschen entwirft, keine relevanten Daten nutzen kann, außerhalb seiner Oberfläche nicht handelt und der Mensch aktiv entscheidet, können gewöhnliche Application-, Datenschutz- und AI-Use-Kontrollen ausreichen. Ist ein Workflow stabil und regelbasiert, kann deterministische Automatisierung sicherer, günstiger und besser erklärbar sein. Sind Fehlerfolgen hoch und zuverlässige Kontrollen nicht verfügbar, sollte das Unternehmen die Aktion nicht delegieren.

Ein Agent ist auch dann die falsche Wahl, wenn:

der Outcome nicht präzise genug für eine Evaluation definiert werden kann;
die erforderliche Handlungsmacht einen unakzeptablen Blast Radius erzeugt;
Ausnahmen häufig auftreten, aber schwer erkennbar sind;
menschliches Review den gesamten theoretischen Gewinn verbraucht;
verlässliche Daten oder Systemschnittstellen fehlen;
das Unternehmen keinen Owner benennt, der die Konsequenz trägt;
einfachere Software dasselbe Ergebnis zuverlässiger erzeugt.

Das Modell soll nicht mehr Agenten legitimieren. Es soll eine disziplinierte No-Agent-Entscheidung ermöglichen.

Fragen, die das Executive Team klären sollte

Bevor ein relevanter Agent produktiv wird, sollte das Executive Team folgende Fragen beantworten können:

Welcher Business Outcome hat genau einen benannten Owner?
Welche Aktionen sind delegiert, verboten oder freigabepflichtig?
Welche Identität führt jede Aktion aus, und wer ist ihr Sponsor?
Welche Produktionsevidenz rechtfertigt den aktuellen Grad an Autonomie?
Welche Fehler werden verhindert, erkannt, rückgängig gemacht oder toleriert?
Wer erhält eine Exception, und wer darf das System stoppen?
Wie hoch sind die Kosten je erfolgreichem Outcome nach Review- und Fehlerkosten?
Welche Änderung an Abhängigkeit oder Modell löst eine Neuautorisierung aus?
Wann wird der Agent stillgelegt, wenn der erwartete Wert nicht entsteht?

Das sind keine Fragen für Technology allein. Sie verbinden Produkt, Operations, Finance, Security, Risk und Executive Accountability. Sie gehören zur Rolle eines Technology Executive, weil Agentenarchitektur künftig mitbestimmt, wer—oder was—im Unternehmen handeln darf.

Fazit

Agentic AI schafft Maschinenarbeit. Maschinenarbeit braucht einen menschlichen Verantwortlichen. Autonomie ist delegierte Handlungsmacht. Vergeben Sie die kleinste ausreichende Befugnis. Messen Sie Vollkosten je erfolgreichem Geschäftsergebnis.

Diese fünf Prinzipien machen aus einer attraktiven Demo eine operative Entscheidung: Routinearbeit delegieren, wo sie Kundenergebnis und Wirtschaftlichkeit verbessert, das Ergebnis in menschlicher Verantwortung halten und Eingriffe ermöglichen. Einfachere Automatisierung oder menschliches Urteil bleibt die bessere Wahl, wenn sie dasselbe Ergebnis zuverlässiger liefert.

Fragen Sie nicht nur, ob ein Agent die Arbeit ausführen kann. Fragen Sie, wer das Ergebnis verantwortet, wenn er es tut.

Quellen und Einordnung des Modells

Das Modell mit sechs Entscheidungen ist eine Synthese aus Executive-Perspektive. Quellen sind an der jeweiligen Stelle verlinkt; der Kunden-Onboarding-Workflow ist hypothetisch.

Über Andrei Lisikov · Operative Erfahrung · AI Work Redesign · Industrial AI Production Readiness · Technology Value Economics Model