AI Native Operations in der IT: Wenn AIOps vom Analysewerkzeug zum Betriebsmodell wird

Von Monitoring über AIOps zu AI Native Operations

Monitoring beantwortet Fragen, die man schon kennt – anhand fester Messgrössen und Schwellenwerte. Observability geht weiter. Reichhaltige Telemetrie und Kontext erlauben es, auch unbekannte Zustände zu untersuchen. AIOps setzt an dieser Stelle Statistik, Machine Learning und Automation ein, um Ereignisse zu bündeln, Muster zu erkennen, Incidents zu priorisieren und nächste Schritte vorzuschlagen.

AI Native Operations reiht sich nicht als weitere Funktion in diese Kette ein, sondern verändert das Betriebsmodell von Grund auf. Die KI prägt hier Architektur und Arbeitsablauf. Dazu gehören ein kontextreiches Datenmodell, Korrelation über Domänengrenzen hinweg, nachvollziehbare Hypothesen, integrierte Aktionen und eine Governance, die den Autonomiegrad klar begrenzt.

Grenze des Ansatzes

Ein Chatbot obendrauf, eine generative Zusammenfassung oder eine zusätzliche Anomalieerkennung machen aus einer bestehenden Monitoring-Plattform noch keine Plattform für AI Native Operations.

AIOps als Grundlage: Herkunft und Abgrenzung

Woher AIOps kommt und was es leistet 

Der Begriff AIOps wurde 2016 von Gartner geprägt. Als Antwort auf ein Problem, das viele IT-Abteilungen bis heute kennen. Mit der digitalen Transformation wuchs die Menge an Betriebsdaten schneller, als klassische, regelbasierte Monitoring-Tools sie verarbeiten konnten. Feste Schwellenwerte wie „Warnung ab 90 % CPU-Auslastung" erzeugten mit steigender Systemkomplexität immer mehr Fehlalarme, während echte Probleme im Rauschen untergingen. Dieser Effekt ist als Alert Fatigue bekannt.

 AIOps begegnet diesem Problem, indem es Big Data, Analytik und maschinelles Lernen kombiniert: Daten aus Logs, Metriken, Events, Tickets und Topologien werden automatisch gesammelt, korreliert und interpretiert. Der Unterschied zu älteren Techniken liegt darin, dass das System nicht nur meldet, sondern lernt. Muster aus der Vergangenheit werden erkannt, Zusammenhänge zwischen unabhängig erscheinenden Ereignissen werden sichtbar, und aus tausenden Einzelmeldungen wird eine überschaubare Zahl priorisierter, kontextualisierter Erkenntnisse. Genau diese Fähigkeiten bilden das technische Fundament, auf dem AI Native Operations aufbaut.

Abgrenzung zu DevOps, ITOps und MLOps

In der Praxis wird AIOps häufig mit verwandten Begriffen verwechselt, die jeweils eine andere Phase im IT-Lebenszyklus adressieren:

Vereinfacht: ITOps ist die klassische Disziplin, die AIOps modernisiert. DevOps bestimmt, wie Software entsteht und ausgeliefert wird, AIOps dagegen, wie die daraus entstehende Infrastruktur im laufenden Betrieb überwacht und repariert wird. MLOps wiederum sorgt dafür, dass die KI-Modelle, die auch in AIOps- und in AI-Native-Operations-Plattformen zum Einsatz kommen, selbst zuverlässig laufen. AI Native Operations baut auf all dem auf, geht aber einen entscheidenden Schritt weiter. Die KI prägt hier nicht nur einzelne Funktionen, sondern das gesamte Betriebsmodell.

Wie AI Native Operations funktioniert

1. Daten aus relevanten Domänen erfassen

Metriken, Logs und Events allein reichen bei den meisten Enterprise-Use-Cases nicht aus. Erst Netzwerkpakete, Flows, Konfigurationen, Topologien, Abhängigkeiten, Tickets, synthetische Tests und Service-Kontext ergeben ein vollständiges Lagebild. Wichtiger als die Zahl der angebundenen Quellen sind dabei Coverage, Zeitbezug, Datenqualität und Kosten.

2. Technischen und betrieblichen Kontext aufbauen

Über Entity Resolution und ein sich laufend aktualisierendes Topologiemodell wird sichtbar, welche Komponenten zu welchem Service gehören und wie sich eine Änderung oder ein Ausfall fortpflanzt. Fehlt dieser Kontext, bleibt jede Korrelation oberflächlich – und eine belastbare Ursachenanalyse ist kaum zu leisten.

3. Muster, Zusammenhänge und Auswirkungen einordnen

Machine Learning, statistische Verfahren und domänenspezifische Modelle filtern Duplikate heraus, erkennen Abweichungen und bringen Ereignisse in eine Reihenfolge. Entscheidend ist, dass sichtbar bleibt, welche Daten und Abhängigkeiten eine Hypothese stützen – denn Korrelation belegt noch keine Kausalität.

4. Entscheidungen und Aktionen in bestehende Workflows überführen

Die gewonnenen Erkenntnisse fliessen in ITSM-, Collaboration- oder Automatisierungsplattformen ein. Der Autonomiegrad variiert je nach Use Case: von der assistiven Suche über Empfehlungen bis zu freigegebenen Playbooks oder eng begrenzten, autonomen Aktionen innerhalb fest definierter Policies.

5. Resultate verifizieren und zurückführen

Nach jeder Aktion steht die Kontrolle: Hat der Service wieder den erwarteten Zustand erreicht? Erfolgsquote, Fehlaktionen, Rollbacks und manuelle Eingriffe fliessen als Feedback in Modelle, Regeln und Runbooks zurück. Erst dieser Rückkopplungsschritt macht aus reiner Automation einen kontrollierten Betriebsprozess für AI Native Operations.

In der Praxis scheitern Initiativen am häufigsten beim Aufbau des technischen Kontextes (Schritt 2), konkret an einer fehlenden oder veralteten Topologie-Map und unsauberen CMDB-Daten. Die Telemetrie an sich ist in den meisten Enterprise-Umgebungen ausreichend vorhanden. Ein typisches Praxisbeispiel verdeutlicht das: Bei einem kritischen Netzwerk-Vorfall meldete das Monitoring zwar zuverlässig einen Paketverlust an einem Core-Switch, aber mangels sauberer Switch-Server-Zuordnung (Entity Resolution) konnte die KI nicht ableiten, welche Applikations-Gateways davon betroffen waren. Die Meldung blieb ohne Service-Kontext wertlos. Erst als die Topologie-Daten normalisiert und verknüpft wurden, konnte das System verwertbare Ursachenhypothesen bilden.

Konkreter Mehrwert von AI Native Operations im IT-Betrieb

Die KI allein erzeugt noch keinen Mehrwert. Dieser entsteht erst aus dem Zusammenspiel von Daten, Kontext, Entscheidungslogik und kontrollierten Aktionen und lässt sich nur gegen eine Ausgangsbasis und anhand konkreter Betriebskennzahlen wirklich belegen.

Weniger Analysezeit und schnellere Wiederherstellung

Weniger Analysezeit und schnellere Wiederherstellung

Ein grosser Teil der Zeit bei komplexen Incidents geht schlicht fürs Zusammentragen von Informationen drauf: zwischen Dashboards wechseln, Zeitachsen vergleichen, Abhängigkeiten prüfen, Zuständigkeiten klären. Eine Plattform für AI Native Operations nimmt Teams genau diese Schritte ab. Sie bündelt zusammengehörige Signale, bestimmt betroffene Services, ordnet relevante Änderungen zu und liefert den Incident direkt mit Kontext.

Der Effekt zeigt sich deshalb nicht nur bei der MTTR. Auch MTTA, Mean Time to Innocence und der manuelle Analyseaufwand pro Incident können spürbar sinken. Wie stark, hängt von Datenqualität, Integrationsgrad, Use Case und Betriebsreife ab – ein Pauschalversprechen wäre hier unseriös.

Mehr Funktionalität ohne zusätzliche Dashboard-Flut

AI Native Operations erweitert, was Teams tun können. Ein gemeinsames Daten- und Topologiemodell macht domänenübergreifende Abfragen, Impact-Analysen, Predictive Insights und kontextbezogene Handlungsempfehlungen erst möglich. Copilot-Funktionen erleichtern Fachpersonen den Zugriff auf komplexe Daten, ersetzen aber weder die technische Validierung noch klare Berechtigungen.

Diesen Mehrwert gibt es allerdings nur, wenn die neue Funktionalität in bestehende Prozesse eingebettet wird. Eine zusätzliche Oberfläche ohne Anbindung an ITSM, CMDB, Collaboration und Automation schafft am Ende mehr Komplexität, statt sie zu reduzieren.

Konsistentere Entscheidungen und besser nutzbares Betriebswissen

Erfahrene Fachpersonen erkennen Zusammenhänge oft im Kopf schneller als jedes isolierte Tool. Nur lässt sich dieses Wissen kaum skalieren, und bei Schichtwechseln oder wenn jemand das Unternehmen verlässt, ist es plötzlich weg. Kontextbezogene Modelle, dokumentierte Hypothesen und wiederverwendbare Runbooks machen einen Teil dieses Wissens für das ganze Team nutzbar – und genau das macht Entscheidungen bei AI Native Operations konsistenter und nachvollziehbarer.

Reduktion der Analysezeit durch domänenübergreifende Korrelation:

Ausgangslage: 
Sporadischer Paketverlust führte regelmässig zu Performance-Einbussen einer geschäftskritischen Web-Applikation.

Datenquellen: 
Netzwerk-Flows, Applikations-Logs, Router-Metriken und Firewall-Events.

Bisherige manuelle Schritte: 
Das Operations-Team musste Logs aus vier verschiedenen Tools manuell exportieren, zeitlich abgleichen und Abhängigkeiten prüfen, um den Fehler einzugrenzen. Die Baseline für die Mean Time to Acknowledge (MTTA) lag bei 45 Minuten pro Incident.

Unterstützte Schritte durch AI Native Operations: 
Die Signale aus Netzwerk und Applikation wurden domänenübergreifend auf einer gemeinsamen Zeitachse korreliert. Statt unzähliger isolierter Einzelwarnungen generierte das System einen einzigen, kontextualisierten Incident, der direkt das betroffene Applikations-Gateway als wahrscheinliche Ursache auswies.

Gemessene Veränderung: 
Die Triage-Zeit sank von 45 Minuten auf unter 3 Minuten (Messzeitraum: 3 Monate, Scope: Core Network & App-Gateways).

Typische Enterprise-Use-Cases für AI Native Operations

Domänenübergreifende Incident-Triage:

Signale aus Netzwerk, Infrastruktur, Cloud und Anwendungen laufen auf einer gemeinsamen Zeitachse und im Servicekontext zusammen. Wer zuständig ist, lässt sich so schneller klären – unnötige Eskalationen entfallen.

Priorisierte Ursachenhypothesen:

Statt einzelner Symptome bekommen Teams eine begründete Rangfolge möglicher Ursachen, wobei die zugrunde liegenden Signale und Abhängigkeiten für die fachliche Prüfung nachvollziehbar bleiben.

Automatisiertes Incident Enrichment:

Tickets werden automatisch mit betroffenen Services, relevanten Ereignissen, Topologie, früheren Änderungen und empfohlenen Prüfschritten angereichert – manuelle Erfassung und Rückfragen fallen weitgehend weg.

Predictive Operations und Kapazitätsplanung:

Wiederkehrende Muster und schleichende Verschlechterungen werden früher erkennbar, sodass Teams reagieren können, bevor Kapazitätsgrenzen oder Serviceeinschränkungen tatsächlich eintreten.

Change- und Impact-Analyse:

Ein aktuelles Abhängigkeitsmodell zeigt, welche Services, Standorte oder Nutzergruppen von einer geplanten Änderung betroffen sein könnten – die tatsächliche Wirkung wird danach verifiziert.

Service Assurance und Nutzererfahrung:

Wenn technische Telemetrie mit SLI, SLO, synthetischen Tests oder End-User-Experience-Daten verknüpft wird, lässt sich klar priorisieren, welche technische Abweichung tatsächlich einen relevanten Service beeinträchtigt.

AI Native Operations und AI-Native SecOps

Operations und Security greifen teilweise auf dieselben Datenquellen, Topologien und Automatisierungsmechanismen zu. Ihre Entscheidungslogik unterscheidet sich trotzdem grundlegend. IT Operations zielt auf Verfügbarkeit, Performance, Servicequalität und Wiederherstellungszeit. Bei SecOps geht es um weniger Angriffsfläche, das Erkennen bösartiger Aktivität, die Eindämmung von Auswirkungen und die Wiederherstellung von Vertrauenswürdigkeit.

Eine ungewöhnliche Datenrate kann genauso gut ein Kapazitätsengpass, eine Fehlkonfiguration oder legitime Nutzung sein wie ein Angriff. Deshalb darf AIOps eine Anomalie nicht automatisch als Sicherheitsvorfall werten. Der eigentliche Mehrwert liegt im gemeinsamen Kontext und in klar definierten Übergaben an SIEM, SOAR, EDR, NDR oder XDR – nicht darin, diese Systeme zu ersetzen.

Betriebliche Konsequenz

Gemeinsame Datenpipelines und Case-Informationen können Doppelarbeit vermeiden. Rollen, Zugriffsrechte, Beweissicherug, Eskalationen und Freigaben für die Response müssen für Operations und Security dennoch getrennt geregelt bleiben.

Voraussetzungen für die Einführung von AI Native Operations

• Konkreter Ziel-Use-Case: Der Einstieg gelingt nicht über „AIOps einführen" als Programm, sondern über einen messbaren Engpass, einen kritischen Service oder ein wiederkehrendes Incident-Muster.
• Ausreichende Telemetrie und Datenqualität: Coverage, Zeitstempel, Semantik, Topologie und möglicher Datenverlust gehören vor jede Automatisierung auf den Prüfstand.
• Klare Systemrollen: Es muss feststehen, welche Plattform System of Record, System of Insight und System of Action bleibt.
• Definierter Autonomiegrad: Zulässige Aktionen, Freigaben, Abbruchbedingungen, Rollback und Audit Trail werden pro Use Case festgelegt.
• Datenhoheit und Compliance: Der Einsatz von KI-Modellen erfordert Klarheit darüber, wo Telemetriedaten verarbeitet werden (SaaS vs. On-Premises/Swiss Cloud) und ob Kundendaten zum Training globaler Modelle (LLMs) verwendet werden. Für FINMA-regulierte oder KRITIS-Betriebe sind isolierte Instanzen oder klare Opt-outs beim Modell-Training oft zwingend.
• Proof of Value mit Baseline: Ausgangswerte, Zielkennzahlen, Testzeitraum und Erfolgskriterien stehen schon vor dem Pilotstart fest.

Betriebsverantwortung: Rollen, Runbooks, Eskalationswege, Modellüberwachung und kontinuierliche Verbesserung brauchen einen festen organisatorischen Platz.