← Zur Übersicht aller Beiträge
Wenn die KI den Störungsdienst mitmacht: Chance und Risiko
AWS lässt Coding-Agenten Lambda-Funktionen und verbundene Ressourcen diagnostizieren. Das kann die Fehlersuche beschleunigen – ist aber zunächst Diagnose, nicht automatisch autonome Reparatur. Rechte für Lesen und Ändern sollten getrennt werden.
Wenn die KI den Störungsdienst mitmacht: Chance und Risiko
AWS lässt Coding-Agenten Lambda-Funktionen und verbundene Ressourcen diagnostizieren. Das kann die Fehlersuche beschleunigen – ist aber zunächst Diagnose, nicht automatisch autonome Reparatur. Rechte für Lesen und Ändern sollten getrennt werden.
KI-Assistenten können inzwischen deutlich tiefer in technische Betriebsdaten schauen. AWS hat Anfang September eine Serverless-Funktion für seinen MCP Server angekündigt, mit der Coding-Agenten Probleme in laufenden Lambda-Funktionen und verbundenen Diensten diagnostizieren können.
Der Agent kann laut AWS unter anderem Konfigurationen und Änderungen untersuchen, Fehlersignale mit einer Sieben-Tage-Basis vergleichen und Zusammenhänge über Dienste wie API Gateway, S3, DynamoDB oder Step Functions herstellen.
Wichtig ist die Grenze der Meldung: AWS beschreibt hier Diagnose, nicht automatisch autonome Reparatur. Aus einem Leserecht für die Fehlersuche folgt nicht, dass ein Agent auch produktive Ressourcen ändern dürfen sollte.
Was Führung und Betrieb trennen sollten
Lesen: Welche Betriebs- und Konfigurationsdaten darf ein Diagnose-Agent sehen?
Ändern: Welche Remediation darf er selbst ausführen – falls überhaupt?
Nachweis: Welche Diagnose, Empfehlung und tatsächliche Änderung bleibt nachvollziehbar?
Für reine Diagnose kann menschliche Freigabe vor jedem einzelnen Analyseschritt unnötig sein. Vor produktiven Änderungen, die schwer rückgängig zu machen oder besonders folgenreich sind, kann eine separate Freigabe dagegen sinnvoll sein.
Der praktische Punkt ist deshalb nicht „KI im Störungsdienst braucht immer Vier-Augen“, sondern: Diagnosezugriff und Änderungsrecht sind zwei verschiedene Berechtigungen.
AWS ermöglicht Coding-Agenten eine tiefere Diagnose von Lambda-Funktionen und verbundenen Ressourcen. Das ist zunächst Fehlersuche, nicht autonome Reparatur. Trennen Sie deshalb Leserechte von Änderungsrechten. Eine Analyse kann automatisiert laufen, während produktive und schwer rückgängig zu machende Änderungen eine eigene Berechtigung oder Freigabe bekommen.
KI-Assistenten können inzwischen deutlich tiefer in technische Betriebsdaten schauen. AWS hat Anfang September eine Serverless-Funktion für seinen MCP Server angekündigt, mit der Coding-Agenten Probleme in laufenden Lambda-Funktionen und verbundenen Diensten diagnostizieren können.
Der Agent kann laut AWS unter anderem Konfigurationen und Änderungen untersuchen, Fehlersignale mit einer Sieben-Tage-Basis vergleichen und Zusammenhänge über Dienste wie API Gateway, S3, DynamoDB oder Step Functions herstellen.
Wichtig ist die Grenze der Meldung: AWS beschreibt hier Diagnose, nicht automatisch autonome Reparatur. Aus einem Leserecht für die Fehlersuche folgt nicht, dass ein Agent auch produktive Ressourcen ändern dürfen sollte.
Was Führung und Betrieb trennen sollten
Lesen: Welche Betriebs- und Konfigurationsdaten darf ein Diagnose-Agent sehen?
Ändern: Welche Remediation darf er selbst ausführen – falls überhaupt?
Nachweis: Welche Diagnose, Empfehlung und tatsächliche Änderung bleibt nachvollziehbar?
Für reine Diagnose kann menschliche Freigabe vor jedem einzelnen Analyseschritt unnötig sein. Vor produktiven Änderungen, die schwer rückgängig zu machen oder besonders folgenreich sind, kann eine separate Freigabe dagegen sinnvoll sein.
Der praktische Punkt ist deshalb nicht „KI im Störungsdienst braucht immer Vier-Augen“, sondern: Diagnosezugriff und Änderungsrecht sind zwei verschiedene Berechtigungen.
Quellen
Transparenz: Konzept, Auswahlkriterien und inhaltliche Vorgaben stammen von Christian Hohlfeld. Recherche und Formulierung wurden nach diesen Vorgaben mit KI-Werkzeugen unterstützt. Redaktionell geprüft und verantwortlich: Christian Hohlfeld.