Die Automatisierungsschicht will Enterprise-KI dominieren

Jede Generation von Unternehmenssoftware hat ihren Autobahnknoten – den Moment, in dem vier separate Straßen beschließen, eine gemeinsame Auffahrt zu teilen, statt weiter parallel Asphalt zu verlegen. Kubernetes war so ein Moment. Die Identitätsebene rund um SAML und OAuth war ein weiterer. Was Automation Anywhere gemeinsam mit Cisco, NVIDIA, Okta und OpenAI gerade angekündigt hat, sieht aus wie das frühe Betonieren des nächsten solchen Knotenpunkts – und der Verkehr, den sie leiten, sind autonome Agenten.

Nennen Sie es das KI-Interchange. Hier werden Reasoning, Compute, Identität und Konnektivität zu einer einzigen Auffahrt verschweißt – und wer die Mautstelle besitzt, besitzt das nächste Jahrzehnt des Unternehmensbetriebs.

Was passiert ist

Automation Anywhere nutzte seine Plattform-Roadmap 2026, um eine Reihe von Erweiterungen vorzustellen, die gezielt auf KI-gesteuerte Unternehmensprozesse abzielen, und lancierte dabei eine neue Initiative namens EnterpriseClaw. Wie DevOps.com berichtete, ist EnterpriseClaw an Partnerschaften mit vier Anbietern geknüpft, die jeweils eine andere strukturelle Schicht dessen repräsentieren, was ein Enterprise-KI-Stack tatsächlich benötigt, um in der Produktion zu laufen.

OpenAI ist als Reasoning-Schicht positioniert. NVIDIA sitzt darunter als Compute-Infrastruktur und Runtime-Beschleunigung. Okta übernimmt Identität und Vertrauen. Cisco deckt Netzwerk, Konnektivität und die operative Infrastruktur ab, an die die meisten Engineers erst denken, wenn sie ausfällt.

Der Autor des Originalartikels hatte die vorherigen Wochen damit verbracht, mit Enterprise-IT-Leitern, Platform Engineers, Sicherheitsteams und Softwareanbietern zu sprechen. Die Beobachtung, die die Geschichte antreibt, ist einfach: Vor sechs Monaten drehten sich die meisten Gespräche über KI im Unternehmen um Copilots, Produktivitätssteigerungen und Experimente. Jetzt geht es um Ausführung. Teams wollen wissen, wie Agenten innerhalb realer Systeme operieren können, ohne operative Instabilität oder Sicherheitsrisiken einzuführen, die sie nicht kontrollieren können.

Diese Verschiebung ist die eigentliche Geschichte. Die Ankündigung selbst lässt sich leicht neben einem Dutzend anderer Enterprise-KI-Plattform-Launches dieses Jahres ablegen. Das Interessante ist die Form der Allianz: Reasoning plus Compute plus Identität plus Konnektivität, bewusst zusammengestellt und auf Teams ausgerichtet, die bereits über die Demo-Phase hinaus sind und dem langweiligen Teil der tatsächlichen Betriebsführung gegenüberstehen.

Technische Anatomie

Rund fünfzehn Jahre lang war Enterprise-Automatisierung ein deterministisches Spiel. Infrastructure as Code stellte Ressourcen bereit. CI/CD bewegte Artefakte. Kubernetes plante Container. Selbst die ambitionierteren Workflow-Tools liefen innerhalb begrenzter Logik mit vorhersehbaren Ausführungspfaden. Wenn eines dieser Systeme ausfiel, konnte man in der Regel den Schadensradius nachvollziehen, ein Rollback durchführen und nach Hause gehen.

Agentische KI bricht dieses Modell auf. Anstatt eine Aufgabe zu automatisieren, automatisiert man Urteilsvermögen. Ein Agent entscheidet, welcher Alert relevant ist, welches System er als nächstes berührt, welche Maßnahme er versucht und was er tut, wenn der erste Versuch etwas Unerwartetes zurückgibt. Der Ausführungspfad ist kein Diagramm mehr, das man in Miro gezeichnet hat. Es ist eine Laufzeit-Verhandlung zwischen einem probabilistischen Modell, einem Identity Provider, einem Netzwerk-Fabric und welchem Geschäftssystem auch immer den API-Aufruf beantwortet.

Genau deshalb liest sich die Vier-Wege-Partnerschaft wie ein verkleidetes Architekturdiagramm. Reasoning ohne Compute ist eine Demo. Compute ohne Identität ist ein Sicherheitsvorfall, der nur darauf wartet zu passieren. Identität ohne Konnektivität ist ein Richtliniendokument, das niemand durchsetzt. Konnektivität ohne Reasoning ist eben, nun ja, Cisco.

Der Artikel von DevOps.com zieht eine explizite Parallele zum Cloud-Native-Übergang – und das ist die richtige. Kubernetes hat sich letztlich weniger wegen der Container selbst durchgesetzt, sondern weil es zur Control Plane für die Koordination operativer Komplexität wurde. Platform Engineering entstand darüber, um Entwicklern standardisierte Abstraktionen und operative Leitplanken zu geben. Wer schon einmal um 2 Uhr nachts ein fehlerhaftes Helm-Chart debuggt hat, weiß: Die Control Plane ist der Ort, wo die eigentliche Macht sitzt.

In der agentischen Welt sieht es so aus, als würde Identität diese Control Plane werden. Jede Aktion, die ein Agent ausführt, ist eine Berechtigungsprüfung. Jede Entscheidung ist ein Audit-Event. Jede Aufrufkette ist ein Trace, der im Nachhinein rekonstruierbar sein muss. Das ist eine Aufgabe für echtes Distributed Tracing und strukturierte Telemetrie – und Standards wie OpenTelemetry werden am Ende weit mehr Gewicht tragen, als ihre Maintainer wahrscheinlich eingeplant haben. Der Knotenpunkt ist nicht das Reasoning. Es ist die Identitäts-und-Observability-Ebene, die darum gewickelt ist.

Wer unter Druck gerät

Die erste Gruppe, die die Hitze spürt, sind pure-play-RPA-Anbieter, die ihre Agenten-Story noch nicht gefunden haben. Deterministische Workflow-Automatisierung ist ein gelöstes Problem. Wenn Ihre Plattform nicht innerhalb einer governed Agent-Runtime mit einem echten Identitätsmodell dahinter sitzen kann, sind Sie ein Feature, kein Unternehmen. Das EnterpriseClaw-Framing ist Automation Anywhere, das auf diesem Terrain zuerst die Flagge pflanzt.

Die zweite Gruppe sind die Identitätsteams in jedem großen Unternehmen. Die meisten Organisationen haben keine standardisierten Identitätsmodelle für KI-Agenten, die mit Unternehmensberechtigungen operieren. Sie haben Menschen, sie haben Service-Accounts, und sie haben eine Tabelle mit API-Keys, die niemand öffnen möchte. Agenten passen in keines davon sauber. In den nächsten neunzig Tagen werden Okta-geprägte Gespräche auf IAM-Verantwortliche treffen, die dachten, sie seien mit ihrer 2026-Roadmap fertig.

Die dritte Gruppe – und das ist diejenige, die ich in iGaming, Fintech und Ad-Tech genau im Auge behalten würde – sind die Platform Engineering Teams. Probabilistische Workflows in der Produktion bedeuten, dass der Observability-Stack Fragen beantworten muss, für die er nie konzipiert wurde. Warum hat der Agent diese Aktion gewählt? Welchen Kontext hatte er? Welche nachgelagerten Systeme hat er berührt, und in welcher Reihenfolge? Teams, die SRE-Playbooks gegen deterministische Dienste ausführen, werden bald eine Klasse von Incidents erben, die sich nicht sauber zurückrollen lässt.

Sicherheitsteams bekommen eine Version desselben Problems. Der Schadensradius eines kompromittierten Agenten ist nicht der Schadensradius eines kompromittierten Skripts. Ein Agent mit legitimen Anmeldedaten, der innerhalb seiner Berechtigungen handelt, kann dennoch operativen Schaden anrichten, indem er Entscheidungen so verkettet, wie es niemand modelliert hat. Das ist ein Governance-Problem, kein Firewall-Problem – und die meisten SOCs sind nicht dafür ausgestattet.

Playbook für Engineering-Teams

Beginnen Sie mit Identität. Bevor ein Agent ein Produktionssystem berührt, entscheiden Sie, was eine Agenten-Identität in Ihrer Organisation tatsächlich ist. Kein gemeinsamer Service-Account. Kein geliehenes Token eines Mitarbeiters fürs Wochenende. Ein erstklassiges Principal mit abgegrenzten Berechtigungen, rotierenden Anmeldedaten und einem Audit-Trail. Wenn Okta oder Ihr bevorzugter IdP das heute nicht abbilden kann, nehmen Sie dieses Quartal den Roadmap-Call wahr.

Als nächstes instrumentieren Sie für probabilistisches Verhalten. Traditionelles APM setzt voraus, dass dieselbe Eingabe dieselbe Ausgabe erzeugt. Agenten nicht. Fügen Sie Trace-Attribute hinzu, die die Modellversion, den Prompt-Kontext, die getätigten Tool-Calls und die Entscheidung des Agenten erfassen. Behandeln Sie jede Agentenaktion als Span. Die Referenzarchitekturen für Zuverlässigkeitsmuster sind ein guter Ausgangspunkt, müssen aber für nicht-deterministische Ausführungspfade erweitert werden.

Drittens: Bauen Sie einen Kill Switch, der tatsächlich funktioniert. Kein Config-Flag, das in einem Repo vergraben ist, das freitags niemand deployt. Eine Laufzeitsteuerung, die die Berechtigungen eines Agenten innerhalb von Sekunden über alle Systeme hinweg widerrufen kann, ohne dass ein Mensch sich in vier verschiedene Konsolen einloggen muss. Das ist der Teil, an dem es in den meisten Organisationen, die ich gesehen habe, zusammenbricht.

Widerstehen Sie schließlich dem Drang, den gesamten Stack von einem Anbieter zu kaufen, weil das Slide-Deck aufgeräumt aussieht. EnterpriseClaw ist ein architektonisches Signal, keine Einkaufsliste. Die Schichten, die es benennt – Reasoning, Compute, Identität, Konnektivität – sind real. Welche spezifischen Anbieter diese Schichten in Ihrem Unternehmen füllen, sollte eine bewusste Entscheidung sein, keine Voreinstellung.

Die wichtigsten Erkenntnisse

• EnterpriseClaw ist weniger ein Produktlaunch als vielmehr Automation Anywheres Anspruch auf die operative Schicht unterhalb von Enterprise-KI-Agenten – mit Cisco, NVIDIA, Okta und OpenAI als vier strukturellen Säulen.
• Der Wechsel von der Automatisierung von Infrastruktur zur Automatisierung operativer Entscheidungen verändert das Risikoprofil grundlegend, da probabilistische Systeme keine sauberen Rollback-Pfade haben.
• Identität entwickelt sich zur eigentlichen Control Plane für autonome Ausführung – ebenso wie Kubernetes zur Control Plane für Container-Orchestrierung wurde.
• Die meisten Unternehmen haben Modelle, APIs und Copilots. Was ihnen fehlt, ist Runtime-Governance, probabilistische Observability und ein standardisiertes Identitätsmodell für Agenten.
• Engineering-Teams sollten Agenten-Identität, Trace-Instrumentierung und einen funktionierenden Kill Switch als Voraussetzungen behandeln, nicht als nachgelagerte Tickets.

Der Knotenpunkt wird gerade gegossen. Die Anbieter, die darauf konvergieren – Identität, Infrastruktur, Automatisierung – setzen alle auf dieselbe Weise. Wer am Ende die Mautstelle besitzt, wird nicht wegen des Reasoning-Modells darüber gewinnen. Sie werden gewinnen, weil sie den langweiligen Teil – Identität und Observability zur Agent-Laufzeit – tatsächlich zum Laufen gebracht haben.