Der AI-Shored NOC: Wenn AI Agents Teil des Teams werden
Wie sich Network Operations vom Ticket-Fließband zum kontrollierten Entscheidungs- und Assurance-System entwickeln.
Der klassische Network Operations Center folgt einem bekannten Muster: Alarm oder Request, Ticket, Analyse, Übergabe, Change, Abschluss. In komplexen Umgebungen ist der Mensch dabei die Integration Layer zwischen Ticketing, CMDB, IPAM, DNS, Firewall Management, Routing, Observability und Change System.
Wenn AI Agents Teil des Teams werden, verändert sich nicht nur die Geschwindigkeit dieses Ablaufs. Die Struktur des NOC selbst verändert sich.
Vom Ticket zum Outcome
Nehmen wir eine typische Meldung: „Application A erreicht Service B auf TCP/443 nicht.“
Heute sammelt ein Engineer Kontext aus vielen Systemen: Welche IPs gehören zu den Anwendungen? Welche Zone? Gibt es DNS-Auflösung? Stimmt das Routing? Welche Firewall Rule greift? Wurde kürzlich etwas geändert? Zeigen Logs Drops oder Timeouts?
Ein AI Agent kann diese Schritte parallel vorbereiten. Er sammelt Context, korreliert Signale, formuliert Hypothesen und schlägt den nächsten sicheren Test vor. Der Zielprozess sieht dann so aus:
Intent → Context → AI Analysis → Policy & Risk Validation → Human Judgment → Deterministic Automation → Continuous Assurance
Das Ticket ist nur noch ein Eingangskanal. Entscheidend ist der nachgewiesene Outcome.
Drei Systeme, drei Aufgaben
Ein belastbares Design trennt:
- AI Reasoning: Context verstehen, Hypothesen bilden, Plan vorschlagen.
- Policies: Grenzen, Berechtigungen und Risk Thresholds deterministisch prüfen.
- Automation: freigegebene Schritte reproduzierbar ausführen und testen.
Je näher eine Aktion an der produktiven Infrastruktur ist, desto weniger darf sie von probabilistischem Verhalten abhängen. Oben kann AI kreativ analysieren. Unten muss Execution deterministisch, least-privileged und vollständig protokolliert sein.
Service Assurance statt Config Completion
Klassische Automation endet oft nach dem erfolgreichen API Call. Ein AI-Shored NOC muss weitergehen. Nach einem Firewall Change ist zu prüfen:
- erreicht der erwartete Traffic tatsächlich das Ziel?
- entstehen Sessions in der richtigen Rule?
- bleiben Latenz und Fehler im erwarteten Bereich?
- wurden keine unbeabsichtigten Pfade geöffnet?
- treten neue Security Alerts oder Anomalien auf?
- stimmt der dokumentierte mit dem realen Zustand überein?
Erst dann ist der Outcome validiert. Das entspricht dem Gedanken von Intent-Based Networking: Ein gewünschter Zustand wird nicht nur konfiguriert, sondern kontinuierlich überprüft.
Ein NOC aus spezialisierten Agents
In großen Umgebungen wird ein einzelner Universal Agent kaum ausreichen. Plausibler ist ein Verbund spezialisierter Agents:
- Request Agent für Intent und Vollständigkeit,
- Context Agent für CMDB, IPAM und Ownership,
- DNS Agent für Resolution und Records,
- Network Agent für Routing und Reachability,
- Firewall Agent für Rules, Objects und Logs,
- Security Agent für Policies, Exposure und Risk,
- Change Agent für Plan, Test, Rollback und Evidence,
- Assurance Agent für die Verifikation nach der Ausführung.
Diese Aufteilung verbessert Spezialisierung, schafft aber neue Anforderungen: Jeder Agent braucht eine eigene Identity, definierte Datenzugriffe, nachvollziehbare Messages und klare Verantwortung. Multi-Agent darf nicht Multi-Black-Box bedeuten.
Der NOC wird zum Control Plane
Der künftige NOC besteht aus mehreren Schichten:
- Interaction Layer: Nutzer, Engineers, Tickets, Chat und APIs.
- Knowledge Layer: Architecture, Policies, CMDB, IPAM, Runbooks und Historie.
- Reasoning Layer: AI Agents und Orchestration.
- Control Layer: Policy Engines, Approval, Identity und Risk Gates.
- Execution Layer: deterministic Automation und Plattform-APIs.
- Assurance Layer: Monitoring, Logs, Tests und Continuous Verification.
Damit wird der NOC weniger zu einer Ticketfabrik und mehr zu einem Control Plane für operative Entscheidungen.
Was sich für Menschen verändert
Engineers verbringen weniger Zeit mit Suche, Copy-and-paste und Standarddiagnose. Ihre Arbeit verschiebt sich zu:
- Design von Policies und Automation Patterns,
- Pflege des Knowledge Layer,
- Behandlung komplexer und neuer Störungen,
- Evaluation der Agents,
- Review von Exceptions und Risk Decisions,
- Verbesserung des gesamten Systems.
Das ist keine automatische Entlastung. Schlechte Daten, unklare Ownership und ungepflegte Policies werden durch AI sichtbarer – und können schneller skaliert werden. Deshalb ist organisatorische Reife genauso wichtig wie das Modell.
Provider: von Capacity zu Capability
Auch im NOC ändert sich die Rolle externer Provider. Ihr Wert liegt künftig weniger im Volumen bearbeiteter Tickets, sondern in Platform Engineering, Integration, 24/7 Resilience, Spezialwissen und kontinuierlicher Verbesserung.
Ein guter Vertrag misst deshalb Decision Quality, Architecture Compliance, Control Integrity und validierte Outcomes. Ticketzahlen allein beschreiben den Wert nicht mehr.
Der AI-Shored NOC ist kein autonomes Robot Center. Er ist ein bewusst entworfenes sozio-technisches System, in dem AI analysiert, Policies begrenzen, Automation ausführt und Menschen Verantwortung tragen.
Quellen und Vertiefung
- ETSI ZSM 020: AI Enablers for Zero-touch Network and Service Management
- IETF RFC 9315: Intent-Based Networking – Concepts and Definitions
- TM Forum IG1343: Autonomous Operations Maturity
- Forschung zu AI-Shoring und Knowledge Retention
- Harvard Business Review: AI und Decision Economics