Bildquelle: extern
Agentische Automatisierung braucht keinen Freiflug, sondern einen kontrollierten Ausführungspfad
Die Debatte über KI-Agenten im IT-Betrieb wird noch zu oft auf die falsche Frage verkürzt: Kann ein System Störungen erklären, Empfehlungen formulieren oder Runbooks in natürlicher Sprache anstoßen? Das ist interessant, aber nicht der eigentliche Engpass. Der operative Bruch liegt meist eine Stufe später. Zwischen Einsicht und echter Infrastrukturänderung fehlt in vielen Umgebungen ein sauberer Pfad, der Freigaben, Identität, Protokollierung und Rückfalloptionen zusammenhält. Genau deshalb ist Red Hats aktueller Ausbau von Ansible Automation Platform relevanter, als der Schlagwortanteil rund um „agentic AI“ zunächst vermuten lässt.
Red Hat hat Mitte Mai 2026 Ansible Automation Platform 2.7 und einen neuen Automation Orchestrator angekündigt. Die Produktbotschaft lässt sich nüchtern lesen: Wenn Teams KI im Betrieb ernsthaft nutzen wollen, brauchen sie keinen Agenten mit mehr Freiheiten, sondern eine belastbare Verbindung zwischen Analyse und Ausführung. Sonst bleibt auch die beste Empfehlung nur ein weiterer Textbaustein im Incident-Chat, während Änderungen weiter in Silos, Sonderskripten und statischen Servicekonten hängen.
Der neue Ansible-Winkel trifft damit einen echten Schmerzpunkt in IT-Organisationen. Es fehlt heute selten an Signalen. Logs, Events, Tickets, Monitoring und Kostenwarnungen sind meist genug vorhanden. Was fehlt, ist ein gemeinsames Modell dafür, wann aus einem Signal eine Maßnahme werden darf, unter welcher Identität sie läuft und wie sich im Nachgang nachvollziehen lässt, wer warum gehandelt hat. Genau hier setzt der Gedanke einer „trusted execution layer“ an.
Der eigentliche Engpass liegt zwischen Empfehlung und Änderung
Red Hat formuliert den Kern erstaunlich klar: Organisationen brauchen einen verlässlichen Weg, um Modellergebnisse mit ihrer bestehenden Infrastruktur zu verbinden. Das ist mehr als Marketing-Sprache. In vielen Unternehmen endet die aktuelle KI-Nutzung im Betrieb genau an dieser Schwelle. Ein Agent darf Zusammenhänge erkennen, aber nicht produktiv eingreifen. Oder er dürfte theoretisch eingreifen, müsste dafür aber über statische Konten, undurchsichtige Sonderrechte oder manuell gepflegte Brückenskripte gehen. Dann steigt das Risiko schneller als der Nutzen.
Für ITSM- und Operations-Teams ist das kein abstraktes Architekturthema. Im Incident entscheidet dieser Zwischenschritt darüber, ob eine Empfehlung in Minuten geprüft und umgesetzt wird oder ob wieder drei Teams, zwei Freigaben und ein ad hoc gebautes Shell-Skript nötig sind. Im Change-Betrieb zeigt sich derselbe Bruch bei Routineaufgaben: Patches, Quotenanpassungen, Zugriffspfaden, Restart-Folgen oder Konfigurationsänderungen. Solange Analyse und Aktion nicht über denselben Governance-Rahmen laufen, bleibt Automatisierung punktuell und agentische Automatisierung operativ fragil.
Red Hats Gegenentwurf lautet deshalb nicht „mehr KI“, sondern „mehr kontrollierte Ausführung“. Bestehende Playbooks und deterministische Abläufe sollen nicht verdrängt, sondern als vertrauenswürdige Grundlage genutzt werden. Der Agent darf also untersuchen, anreichern, priorisieren und vorschlagen. Ausgeführt wird idealerweise weiterhin über bekannte, versionierte und auditierbare Automatisierung. Das ist für Generalisten wichtig, weil es die richtige Reihenfolge wiederherstellt: erst Verlässlichkeit, dann Reichweite.
Drei Änderungen sind für den Betrieb wirklich relevant
Die spannendste Neuerung ist nicht eine einzelne KI-Funktion, sondern das Zusammenspiel aus Orchestrierung, Identität und Werkzeuganbindung. Genau daraus entsteht der operative Mehrwert.
Erstens baut Red Hat den Automation Orchestrator als übergeordneten Steuerungsrahmen auf. Laut Produktseite soll er task-basierte, event-getriebene und KI-getriebene Automatisierung in einem gemeinsamen Ablauf zusammenführen. Für den Betrieb ist das wichtig, weil diese Modi heute oft in unterschiedlichen Werkzeugwelten leben. Ein Monitoring-Event startet irgendwo einen Workflow, ein klassisches Playbook läuft in einer anderen Logik, und KI-Vorschläge hängen separat daneben. Wenn diese drei Ebenen auf einer gemeinsamen Ausführungsfläche zusammenkommen, wird Governance einfacher: ein Datenmodell, eine Auditspur, ein Freigaberahmen.
Zweitens wird die Identitätsseite modernisiert. Red Hat beschreibt Ansible Automation Platform 2.7 als OIDC-Provider für HashiCorp Vault, sodass Automatisierungsjobs mit kurzlebigen, jobspezifischen Tokens statt mit statischen Servicekonten arbeiten können. Genau das ist betrieblich größer als es auf den ersten Blick klingt. In vielen Umgebungen scheitern sichere Automatisierungsmodelle nicht an fehlenden Vaults oder fehlender MFA, sondern an langlebigen Maschinenidentitäten, die über Jahre immer mehr Sonderrechte ansammeln. Kurzlebige Tokens engen die Reichweite eines Fehlers oder Missbrauchs stark ein und passen deutlich besser zu Zero-Trust-Anforderungen.
Drittens wird mit dem MCP-Server für Ansible die Werkzeugbrücke konkretisiert. Red Hat beschreibt ihn als Verbindung zwischen MCP-Clients und der Automation Platform. In der aktuellen „What’s new“-Seite wird das bereits als Weg zu natürlicher Sprachsteuerung für Job-Management, Troubleshooting und Workflow-Starts beschrieben. Für Generalisten ist daran weniger die Sprachschnittstelle interessant als die Standardisierung. Wenn Agenten über eine klar definierte Brücke an Automatisierung andocken, sinkt der Druck, für jeden neuen Assistenten eigene Sonderintegrationen zu bauen. Das spart nicht nur Engineering-Aufwand, sondern reduziert auch die Zahl der unkontrollierten Seiteneingänge in produktive Infrastruktur.
Warum das noch kein Selbstläufer ist
Gerade weil die Richtung sinnvoll ist, sollte man sie nicht romantisieren. Ein kontrollierter Ausführungspfad löst noch nicht die schwierigsten Organisationsfragen. Teams müssen weiterhin festlegen, welche Maßnahmen ein Agent überhaupt anstoßen darf, wo zwingend ein Mensch in der Freigabe bleibt und welche Systeme nur lesend angebunden werden dürfen. Der Unterschied ist nur: Diese Fragen lassen sich in einem gemeinsamen Modell besser beantworten als in verteilten Ad-hoc-Integrationen.
Dazu kommt der Reifegrad. Red Hat nennt den Automation Orchestrator als kommende Funktion für Q3 2026 und einige Bausteine weiterhin als Technology Preview. Das ist wichtig für die Einordnung. Der strategische Punkt ist real, aber nicht jeder Teil ist sofort produktionsreif für jede Umgebung. Wer jetzt vorschnell von „autonomem Betrieb“ spricht, verkennt den eigentlichen Wert. Der Gewinn liegt zunächst darin, produktive Automatisierung klarer zu staffeln: lesen, analysieren, vorschlagen, freigeben, ausführen, dokumentieren.
Genau deshalb sollten IT-Leitungen und Plattformteams bei solchen Ankündigungen nicht mit Demo-Fragen anfangen, sondern mit Betriebsfragen. Welche bestehenden Playbooks gelten heute schon als vertrauenswürdig? Welche Change-Typen sind gut genug standardisiert, um sie in einen solchen Pfad aufzunehmen? Welche Secrets dürfen nur kurzlebig bezogen werden? Und wie sieht ein sauberer Rückfallpfad aus, wenn ein Agent oder Orchestrator nur teilweise richtig liegt? Wenn diese Antworten fehlen, beschleunigt eine neue Agentenebene nur das Chaos.
Worauf IT-Management jetzt konkret achten sollte
- Zwischen Analyse und Aktion sauber trennen: Ein Agent darf mehr sehen als er ausführen darf. Diese Grenze muss fachlich bewusst definiert werden.
- Bestehende Playbooks als Governance-Kern behandeln: Nicht der freie Prompt, sondern die verlässliche Automatisierung sollte das letzte Wort vor produktiven Änderungen haben.
- Kurzlebige Identitäten priorisieren: Wenn Jobs weiter mit statischen Servicekonten laufen, bleibt die neue Intelligenz an einer alten Sicherheitsarchitektur hängen.
- Multi-Mode-Abläufe bewusst modellieren: Event-Trigger, manuelle Freigaben und KI-Vorschläge sollten in derselben Prozesssicht landen statt in getrennten Werkzeuginseln.
- Technology-Preview-Bausteine ehrlich staffeln: Lesen und Troubleshooting zuerst, produktive Schreibrechte erst nach klarer Audit- und Rückfallprüfung.
Fazit
Die eigentliche Botschaft hinter Ansible Automation Platform 2.7 ist nicht, dass KI-Agenten jetzt mehr dürfen. Die wichtigere Botschaft lautet, dass IT-Betrieb endlich einen saubereren Pfad zwischen Erkenntnis und Ausführung bekommt. Das ist für Generalisten, Service-Verantwortliche und Plattformteams deutlich relevanter als jede neue Chat-Oberfläche.
Agentische Automatisierung wird im Alltag nicht daran gemessen, wie klug ein System klingt, sondern wie kontrolliert es in reale Betriebsabläufe eingebettet ist. Wer dafür Orchestrierung, kurzlebige Identität, Audit-Spuren und klare Freigabegrenzen zusammendenkt, baut keinen Freiflug für Agenten, sondern einen tragfähigen Betriebsrahmen. Genau dort beginnt der eigentliche Fortschritt.
Quellen
- Red Hat: Red Hat Establishes Ansible Automation Platform as the Trusted Execution Layer for IT Operations in an Agentic Era
- Red Hat: Automation orchestrator
- Red Hat: What’s new in Red Hat Ansible Automation Platform 2.7
- Red Hat Documentation: Create a credential using a Vault OIDC credential type
- Red Hat Blog: IT automation with agentic AI: Introducing the MCP server for Red Hat Ansible Automation Platform
