KI automatisiert längst einzelne Arbeitsschritte. Doch der eigentliche Engpass liegt zunehmend zwischen den Prozessen: beim Einordnen von Informationen, beim Abwägen von Optionen und bei der Entscheidung über den nächsten Schritt. Autonome Systeme versprechen, genau diese Lücke zu schließen. Damit daraus produktive Entlastung statt neuer Komplexität entsteht, brauchen Unternehmen jedoch belastbaren Kontext, klar definierte Entscheidungsräume und wirksame menschliche Aufsicht.

Management Summary

Entscheidungen werden zum Engpass: Klassische Automatisierung führt feste Regeln aus; autonome Systeme sollen Situationen bewerten und kontextabhängig reagieren.
Komplexität schmälert den KI-Nutzen: Integration, Datenaufbereitung, Governance und Support binden Budget und Arbeitszeit, bevor messbarer Mehrwert entsteht [1].
Unternehmenskontext ist unverzichtbar: Systeme benötigen verlässliche Informationen über Services, Prozesse, Richtlinien, Prioritäten und frühere Ereignisse.
Autonomie braucht Grenzen: Berechtigungen, Freigabeschwellen, Protokollierung, Eskalationswege und menschliche Aufsicht müssen vor dem produktiven Einsatz feststehen [2][3].
Der Nutzen reicht über die IT hinaus: Wenn Systeme Störungen früh erkennen und innerhalb definierter Leitplanken bearbeiten, sinkt der Koordinationsaufwand im gesamten Unternehmen.

Illustration Absmeier foto ki designer

Autonome IT entsteht nicht durch maximale Entscheidungsfreiheit, sondern durch Kontext, klar begrenzte Rechte, nachvollziehbare Kontrollen und definierte Übergaben an den Menschen.

Warum die nächste Stufe der Automatisierung bei einem bislang menschlichen Engpass ansetzt.

Zugespitzt lässt sich sagen: Unternehmen führen KI ein, um Arbeit zu automatisieren – doch mit jeder neuen Anwendung wächst auch der Aufwand für die IT. Systeme müssen integriert, mit den richtigen Daten versorgt, überwacht und kontinuierlich angepasst werden. So kann ausgerechnet die Technologie, die Prozesse vereinfachen soll, selbst neue Komplexität schaffen.

Wie groß dieses Problem bereits ist, zeigt der Cost of Complexity Report von Freshworks. Deutsche Unternehmen schätzen, dass 26 Prozent ihrer KI-Budgets durch ungeplante Kosten rund um Integration, Governance, Datenaufbereitung und laufenden Support gebunden werden. Gleichzeitig verbringen Beschäftigte 27 Prozent ihrer KI-bezogenen Arbeitszeit damit, diese Komplexität zu bewältigen.

Mehr Automatisierung allein greift deshalb zu kurz. Denn während sich viele einzelne Arbeitsschritte bereits automatisieren lassen, bleibt ein entscheidender Teil der Arbeit beim Menschen: Informationen einordnen, Zusammenhänge erkennen und entscheiden, was als Nächstes passieren soll. Genau diese wachsende Entscheidungsarbeit wird zum Engpass.

Wenn feste Regeln nicht mehr ausreichen

Besonders deutlich zeigt sich das im IT-Service-Management (ITSM), also der Organisation und Bereitstellung von IT-Services für die Beschäftigten eines Unternehmens. Nachdem dort zunächst Informationen digitalisiert und später immer mehr Prozesse automatisiert wurden, folgt ein Großteil der Automatisierung bis heute einem festen Prinzip: Wenn X passiert, führe Y aus.

Doch moderne IT-Umgebungen erzeugen eine enorme Menge an technischen Signalen, Warnmeldungen, Nutzeranfragen und Veränderungen. Nicht für jede Situation lässt sich im Voraus eine passende Reaktion festlegen. Statt nur weitere Arbeitsschritte zu automatisieren, geht es deshalb zunehmend darum, auch einen Teil der Entscheidungen dazwischen an Systeme zu übertragen.

Von Automatisierung zu kontrollierter Autonomie

Darin liegt der Unterschied zu klassischer Automatisierung. Autonome Systeme sollen nicht nur eine vorgegebene Reaktion ausführen, sondern eine Situation erfassen, Handlungsmöglichkeiten bewerten und ihre Reaktion an den jeweiligen Kontext anpassen.

Dafür reicht ein leistungsfähiges KI-Modell allein nicht. Es muss das jeweilige Unternehmen kennen: seine Systeme und Services, Mitarbeiter, Prozesse, Richtlinien, bisherige Ereignisse und Prioritäten. Erst dieser Kontext ermöglicht es, eine passende Entscheidung für die konkrete Situation zu treffen.

Gleichzeitig braucht Autonomie klare Grenzen. Unternehmen müssen festlegen, welche Entscheidungen ein System selbst treffen darf, wann eine menschliche Freigabe notwendig ist und wann ein Mitarbeiter übernehmen muss. Die Rolle des Menschen verschwindet also nicht, sondern verändert sich: Statt jeden Einzelfall selbst zu bearbeiten, definiert er zunehmend die Regeln und Grenzen, innerhalb derer Systeme handeln können.

Wenn aus einer Störung gar nicht erst ein Problem wird

Der Mehrwert geht damit über die Entlastung der IT hinaus. Das Ziel ist, dass technische Störungen im besten Fall gar nicht erst zu einem Problem für Beschäftigte werden: Ein System erkennt eine Störung, ordnet sie anhand des Unternehmenskontexts ein und behebt sie innerhalb festgelegter Grenzen selbst – bevor ein Mitarbeiter sie bemerkt, melden muss oder bei seiner Arbeit ausgebremst wird.

Das ist auch eine Frage der Skalierbarkeit. Wenn jede wachsende Zahl technischer Vorgänge von Menschen bewertet und koordiniert werden muss, steigt der personelle Aufwand mit der technologischen Komplexität. Können Systeme einen Teil dieser Entscheidungen selbst übernehmen, muss menschliche Entscheidungs- und Koordinationsarbeit nicht im gleichen Maße zunehmen.

Damit wird autonome IT von einer Effizienzfrage für IT-Teams zu einer Produktivitätsfrage für das gesamte Unternehmen: Entscheidend ist nicht nur, wie viele Aufgaben KI automatisiert, sondern wie viele Probleme gar nicht erst menschliche Aufmerksamkeit erfordern.

Simon Hayward, VP Sales International & GM Europe

[1] https://www.freshworks.com/de/report/cost-of-complexity/

Tipps für den verantwortungsvollen Einsatz autonomer Systeme

Mit einem begrenzten Anwendungsfall starten: Der Einstieg sollte nicht mit einem unternehmensweiten Agentensystem beginnen, sondern mit einem klar abgegrenzten Prozess, dessen Ausgangslage, Nutzen und Risiken messbar sind. Besonders geeignet sind wiederkehrende Aufgaben mit standardisierten Daten, eindeutigen Erfolgskennzahlen und der Möglichkeit, jede Aktion zurückzunehmen. Vor dem Start sollten Verantwortliche festlegen, welche Fehler tolerierbar sind, wann das System stoppen muss und anhand welcher Kennzahlen über eine Ausweitung entschieden wird.
Praxisbeispiel: Ein IT-Service-Team lässt ein autonomes System zunächst nur abgelaufene Testkonten erkennen und nach einer Freigabe deaktivieren. Gemessen werden Bearbeitungszeit, Fehlzuordnungen, notwendige Rücknahmen und die Zahl menschlicher Eingriffe. Erst wenn die Ergebnisse über einen festgelegten Zeitraum stabil sind, kommen weitere Kontotypen hinzu.
Entscheidungsrechte festlegen: Für jeden Anwendungsfall braucht es eine verbindliche Entscheidungsmatrix. Sie beschreibt, welche Aktionen das System selbstständig ausführen darf, welche eine menschliche Freigabe benötigen und welche grundsätzlich Menschen vorbehalten bleiben. Dabei sollten neben finanziellen Schwellenwerten auch Datenschutz, Sicherheitsrelevanz, Auswirkungen auf Beschäftigte und die Reversibilität einer Maßnahme berücksichtigt werden. Eskalationswege müssen eindeutig und auch außerhalb der üblichen Arbeitszeiten funktionsfähig sein.
Praxisbeispiel: Ein KI-Agent darf Standardsoftware aus einem freigegebenen Katalog automatisch bereitstellen. Für kostenpflichtige Lizenzen ist die Zustimmung der Kostenstelle erforderlich; bei administrativen Werkzeugen übernimmt zusätzlich die IT-Sicherheit. Das System dokumentiert, welche Regel die jeweilige Übergabe ausgelöst hat.
Berechtigungen minimieren: Autonome Systeme sollten ausschließlich die Zugriffe erhalten, die sie für ihren konkreten Auftrag benötigen. Dauerhafte Administratorrechte sind zu vermeiden; sensible Berechtigungen sollten zeitlich befristet, zweckgebunden und getrennt voneinander vergeben werden. Getrennte Konten für Test und Produktion, sichere Geheimnisverwaltung und zusätzliche Freigaben für privilegierte Aktionen begrenzen mögliche Folgen von Fehlentscheidungen oder kompromittierten Komponenten.
Praxisbeispiel: Ein Agent zur Bearbeitung von Cloud-Störungen darf Protokolle lesen und einen einzelnen Dienst neu starten, aber weder Benutzerrollen verändern noch Ressourcen löschen. Für eine weitergehende Reparatur fordert er ein kurzzeitig gültiges Zugriffstoken an, das erst nach Freigabe durch den Bereitschaftsdienst aktiviert wird.
Kontextqualität prüfen: Gute Entscheidungen setzen verlässliche und aktuelle Informationen voraus. Unternehmen sollten deshalb festlegen, welche Datenquellen maßgeblich sind, wer sie pflegt und wie Konflikte zwischen verschiedenen Quellen behandelt werden. Veraltete Servicekataloge, unklare Zuständigkeiten oder widersprüchliche Richtlinien können zu plausibel klingenden, betrieblich aber falschen Aktionen führen. Automatische Aktualitätsprüfungen und feste Datenverantwortliche sind deshalb Teil der Betriebsorganisation.
Praxisbeispiel: Vor einer Änderung gleicht ein IT-Agent den Configuration-Management-Datenbestand mit dem aktuellen Cloud-Inventar und dem Bereitschaftsplan ab. Stimmen Eigentümer, Schutzbedarf oder Wartungsfenster nicht überein, führt er die Änderung nicht aus, sondern eröffnet einen Klärungsfall.
Aktionen protokollieren: Jede autonome Entscheidung muss im Nachhinein nachvollziehbar sein. Das Protokoll sollte mindestens Auftrag, Zeitpunkt, verwendete Datenquellen, gewählte Handlungsoption, ausgeführte Schritte, Ergebnis und menschliche Eingriffe enthalten. Sensible Inhalte sind dabei zu schützen; Zugriffsrechte und Aufbewahrungsfristen müssen geregelt sein. Die Protokolle dienen nicht nur Audits, sondern auch Ursachenanalysen und der Verbesserung von Regeln und Tests.
Praxisbeispiel: Bei einer automatisch behobenen Netzwerkstörung speichert das System die auslösenden Alarme, die betroffenen Dienste, die geprüften Alternativen, den gewählten Konfigurationswechsel und die anschließenden Gesundheitstests. Ein Dashboard zeigt zusätzlich, ob ein Mensch die Aktion bestätigt, abgebrochen oder später zurückgenommen hat.
Grenzfälle testen: Ein erfolgreicher Standardtest reicht für autonome Systeme nicht aus. Testpläne sollten fehlerhafte, unvollständige und widersprüchliche Daten ebenso abdecken wie Lastspitzen, verzögerte Antworten, manipulierte Eingaben und den Ausfall angebundener Werkzeuge. Entscheidend ist, ob das System unter Unsicherheit konservativ reagiert, seine Grenzen erkennt und korrekt eskaliert. Solche Prüfungen sollten vor jeder größeren Änderung wiederholt werden.
Praxisbeispiel: In einer isolierten Testumgebung erhält ein Helpdesk-Agent gleichzeitig eine gefälschte dringende Anweisung, widersprüchliche Benutzerinformationen und eine nicht erreichbare Identitätsprüfung. Der Test ist nur bestanden, wenn der Agent keine Berechtigung ändert, den Vorgang stoppt und den Sicherheitsdienst mit den relevanten Belegen informiert.
Abbruch und Rücknahme ermöglichen: Kritische Aktionen brauchen einen technisch und organisatorisch erprobten Not-Aus. Unternehmen sollten definieren, wer ein System stoppen darf, wie laufende Aktionen isoliert werden und welche Schritte automatisch zurückgenommen werden können. Wo ein vollständiges Rollback nicht möglich ist, sind Sicherungen, Wiederanlaufpläne und alternative Betriebsverfahren erforderlich. Ein Abbruchmechanismus ist nur dann belastbar, wenn er regelmäßig getestet wird.
Praxisbeispiel: Ein Agent verteilt eine neue Konfiguration zunächst an fünf Prozent der Endgeräte. Steigen Fehlerraten oder Supportmeldungen über einen Grenzwert, stoppt das System die Verteilung automatisch, stellt die vorherige Konfiguration wieder her und informiert den verantwortlichen Service Owner.
Verantwortung zuordnen: Auch wenn ein System selbstständig handelt, bleibt die organisatorische Verantwortung beim Unternehmen. Für fachliche Ziele, technische Betreuung, Datenqualität, Sicherheitsfreigaben, Risikoakzeptanz und Vorfallbearbeitung sollten konkrete Rollen benannt sein. Eine RACI-Matrix kann sichtbar machen, wer entscheidet, wer ausführt, wer konsultiert wird und wer informiert werden muss. Unklare Zuständigkeiten verlängern Reaktionszeiten und erschweren die Aufarbeitung von Fehlern.
Praxisbeispiel: Bei einem autonomen Beschaffungsassistenten verantwortet der Einkauf die Geschäftsregeln, die IT den Betrieb, die Informationssicherheit die Zugriffskontrollen und die Rechtsabteilung Vertrags- und Datenschutzgrenzen. Für Preisabweichungen über einem Schwellenwert ist eine namentlich definierte Person freigabeberechtigt.
Nutzen und Risiko gemeinsam messen: Eine reine Betrachtung von Zeit- und Kosteneinsparungen greift zu kurz. Neben Durchlaufzeit und Automatisierungsquote sollten Unternehmen Fehlentscheidungen, Eskalationen, Rücknahmen, Nacharbeit, Sicherheitsereignisse und Auswirkungen auf Servicequalität und Beschäftigte erfassen. Die Kennzahlen brauchen eine belastbare Ausgangsbasis vor dem Einsatz. So wird sichtbar, ob ein System tatsächlich entlastet oder Aufwand lediglich in Kontrolle und Fehlerkorrektur verlagert.
Praxisbeispiel: Ein Service-Desk-Agent verkürzt die durchschnittliche Bearbeitungszeit um 35 Prozent. Gleichzeitig misst das Team, wie oft Fälle wieder geöffnet werden, wie viele Aktionen korrigiert werden müssen und ob kritische Tickets länger liegen bleiben. Erst die gemeinsame Auswertung entscheidet über die Ausweitung.
Leitplanken laufend anpassen: Prozesse, Bedrohungen, Datenbestände und regulatorische Anforderungen verändern sich. Deshalb müssen Entscheidungsregeln, Berechtigungen, Schwellenwerte, Tests und Eskalationswege regelmäßig überprüft werden. Erkenntnisse aus Vorfällen, Beinahe-Fehlern und manuellen Übersteuerungen sollten in einen kontrollierten Verbesserungsprozess einfließen. Änderungen an Leitplanken benötigen Versionierung, Prüfung und eine dokumentierte Freigabe [2][3][4].
Praxisbeispiel: Ein monatliches Governance-Board wertet Fehlalarme, gestoppte Aktionen und neue Angriffsmuster aus. Nach mehreren unnötigen Eskalationen wird ein Schwellenwert angepasst, zunächst in einer Testumgebung geprüft und anschließend mit dokumentierter Freigabe produktiv gesetzt.

FAQ

Was unterscheidet autonome KI von klassischer Automatisierung?
Die klassische Automatisierung folgt überwiegend vorab definierten Regeln. Autonome Systeme bewerten zusätzlich Kontext, wählen zwischen Handlungsoptionen und können mehrstufige Aktionen innerhalb festgelegter Grenzen ausführen.
Warum rückt die Entscheidungsarbeit in den Mittelpunkt?
Viele Einzelschritte sind bereits automatisiert. Der verbleibende Aufwand entsteht häufig beim Priorisieren, Koordinieren und Entscheiden zwischen diesen Schritten. Genau dort setzen autonome Systeme an.
Welche Rolle spielt der Unternehmenskontext?
Ohne Informationen über Systeme, Services, Zuständigkeiten, Richtlinien und Prioritäten kann ein Modell zwar plausible, aber betrieblich unpassende Entscheidungen treffen. Kontext muss deshalb aktuell, autorisiert und nachvollziehbar bereitgestellt werden.
Wo liegt der wirtschaftliche Hebel?
Der Hebel liegt nicht nur in schneller bearbeiteten Aufgaben, sondern auch in vermiedenen Störungen, weniger Übergaben und geringerem Koordinationsaufwand. Zugleich zeigt der Freshworks-Bericht, dass Integrations- und Governance-Komplexität einen erheblichen Teil der KI-Investitionen binden kann [1].
Welche Entscheidungen sollten beim Menschen bleiben?
Insbesondere irreversible, sicherheitskritische, rechtlich relevante oder finanziell weitreichende Entscheidungen benötigen risikogerechte menschliche Aufsicht. Der EU AI Act verlangt für Hochrisiko-KI geeignete Maßnahmen, damit qualifizierte und befugte Personen Systeme wirksam beaufsichtigen können [3].
Wie lässt sich Autonomie technisch begrenzen?
Geeignet sind unter anderem rollenbasierte Rechte, minimale Berechtigungen, Freigabeschwellen, erlaubte Aktionslisten, isolierte Ausführungsumgebungen, Rate Limits, Protokollierung sowie Abbruch- und Rollback-Mechanismen.
Welche Governance-Struktur ist sinnvoll?
Ein praktikabler Ansatz verbindet Verantwortlichkeiten mit einem wiederholbaren Risikoprozess. Das NIST AI RMF strukturiert diesen über die Funktionen Govern, Map, Measure und Manage [2].
Welche Sicherheitsrisiken sind besonders relevant?
Dazu zählen manipulierte Eingaben, übermäßige Berechtigungen, kompromittierte Daten- oder Toolketten, unkontrollierte Folgeaktionen, Datenabfluss und unzureichende Nachvollziehbarkeit. Das BSI bündelt Empfehlungen für sichere Entwicklung, Bereitstellung, Nutzung und Wartung von KI-Systemen [4].
Wie sollte ein Unternehmen beginnen?
Mit einem klar abgegrenzten, reversiblen Anwendungsfall, belastbaren Ausgangskennzahlen und einem kleinen Kreis autorisierter Systeme. Erst nach Tests, dokumentierten Kontrollen und messbaren Ergebnissen sollte der Entscheidungsraum erweitert werden.
Woran lässt sich der Erfolg messen?
Neben Bearbeitungszeit und Kosten sollten Unternehmen die Zahl vermiedener Störungen, Eskalationsquote, Fehlentscheidungen, Rücknahmen, Nacharbeit, Sicherheitsereignisse und den Anteil menschlicher Eingriffe erfassen. So bleibt sichtbar, ob Autonomie tatsächlich entlastet oder neue Komplexität erzeugt.

Quellen

[1] https://www.freshworks.com/de/report/cost-of-complexity/

[2] https://www.nist.gov/itl/ai-risk-management-framework

[3] https://ai-act-service-desk.ec.europa.eu/en/ai-act/article-14

[4] https://www.bsi.bund.de/DE/Themen/Unternehmen-und-Organisationen/Informationen-und-Empfehlungen/Kuenstliche-Intelligenz/kuenstliche-intelligenz_node.html

Management Summary, FAQ und Bild wurden mit Hilfe von KI erstellt

5338 Artikel zu „Automatisierung KI“

IT-Security | Kommentar | Künstliche Intelligenz | News

Alarmflut im Sicherheitszentrum – Mit Automatisierung und KI der Alert Fatigue entgegenwirken

23. September 2026

Wenn im Security Operations Center jede Warnung gleich laut ist, wird aus Schutz schnell Überlastung. Alert Fatigue ist deshalb kein reines Effizienzproblem, sondern ein Managementrisiko: Kritische Signale können im Grundrauschen untergehen, Reaktionszeiten steigen und Fachkräfte werden durch repetitive Triage gebunden. KI und Automatisierung schaffen Abhilfe, wenn sie Meldungen kontextualisieren, priorisieren und wiederkehrende Abläufe standardisieren –…