KI-Agenten für das Infrastrukturmanagement einsetzen

Warum KI-Agenten für Infrastruktur hinter den Erwartungen zurückbleiben

Ingenieure in Unternehmen behandeln KI-Agenten eher als eine intelligentere Suchmaschine, anstatt sie ordnungsgemäß in ihre Plattformen zu integrieren. Sie werfen jeden Vorfall, jeden Fehler und jedes Konfigurationsproblem einem beliebigen KI-Agenten vor und erwarten, dass dieser sie auf magische Weise löst. In den meisten Fällen erhalten sie jedoch allgemeine Antworten, die zwar isoliert betrachtet korrekt sind, vertrauenswürdig klingen und auf den ersten Blick hilfreich erscheinen, für ihre Umgebung jedoch falsch sind und den Betrieb lahmlegen können.

KI-Agenten können Infrastrukturcode schreiben, Konfigurationen entwerfen und komplexe Probleme durchdenken. Aber sie haben einen strukturellen blinden Fleck, den kein Prompt überwinden kann: Sie sind durch ihre Trainingsdaten begrenzt. Entwickler von eher universell einsetzbaren Modellen wie Claude Code und GitHub Copilot trainieren ihre Modelle nur mit öffentlich verfügbaren Daten. Standardmäßig wissen diese Agenten nicht, wie ein bestimmtes Unternehmen funktioniert. Dazu gehören:

• Namenskonventionen
• Systemeinschränkungen
• interne Servicetopologie
• benutzerdefinierte Abstraktionen
• Compliance-Richtlinien
• Architekturentscheidungen
• Post-Mortem-Analysen
• Runbooks mit betriebskritischen Spezifikationen

Ingenieure können viele Stunden damit verbringen, diese KI-Agenten zu reparieren und anzupassen, um sicherzustellen, dass sie sich effektiv in ihre Systeme integrieren, wodurch die erwarteten Produktivitätsgewinne zunichte gemacht werden. Dies ist die Lücke, die CIOs und Führungskräfte schließen müssen, wenn sie KI-Tools für ihre Infrastrukturteams evaluieren. Die Auswahl eines KI-Agenten ist die halbe Miete. Ob dieser Agent Leistung bringt, hängt davon ab, wie Unternehmen ihm institutionelles Wissen zuführen.

So versorgen Sie KI-Agenten mit Infrastrukturwissen

Es gibt drei Ansätze, mit denen Unternehmen ihren KI-Agenten Informationen über ihre Infrastruktur zuführen können.

1. Fachwissen

Erfahrene Ingenieure fügen geschäftsspezifische Anweisungen aus dem Gedächtnis in den Prompt ein. Das kann so einfach sein wie: „In diesem Unternehmen verwenden wir …“ Dies funktioniert nur, weil sich der Ingenieur zufällig an die richtigen Informationen erinnert. Diese Methode kann unzuverlässig und nicht skalierbar werden, wenn Ingenieure wichtige Details falsch wiedergeben oder wenn neuen Teammitgliedern die notwendigen Informationen fehlen.

2. Statische Dokumentation

Ingenieure können die KI auf den Speicherort der Dokumentation verweisen, die interne Standards beschreibt, wahrscheinlich in einer Markdown-Datei. Sie können sich auch dafür entscheiden, deren Inhalt in jede Unterhaltung mit dem Modell zu kopieren. Dies ist jedoch ein manueller Prozess, und angesichts der Tatsache, wie langsam Teams arbeiten können, kann die Dokumentation schnell veralten.

Noch entscheidender ist, dass das Unternehmenswissen nicht nur aus einer Handvoll Dokumenten besteht. Es besteht aus wertvollem Wissen, das über Git-Repositories, Notion-Seiten, Confluence-Seiten, Slack-Threads und Zoom-Protokolle verstreut ist. Viele dieser Quellen überschneiden sich und widersprechen einander, sodass der Aufwand des Kopierens und Einfügens bei jeder KI-Interaktion untragbar ist.

3. Eine kontextbezogene Retrieval-Pipeline

Realistisch betrachtet kann ein Dokument verschiedene Themen abdecken. Es ist ineffizient, KI-Agenten jedes Detail zuzuführen, wenn sie nur Informationen für die jeweilige Aufgabe benötigen. Unternehmen sollten Retrieval-Augmented Generation (RAG) mit zwei Pipelines implementieren: eine für die Erfassung und eine für die Abfrage.

Die Erfassungspipeline erfasst Unternehmensdokumente, wo immer sie sich befinden, und zerlegt sie in Daten. Vektordatenbanken speichern, verwalten und indizieren diese Daten. Die Abfragepipeline empfängt Anfragen und sendet sie an einen MCP-Server (Model Context Protocol).

Ein MCP-Server wandelt die Anfragen in Embeddings um und führt eine semantische Suche in der Vektordatenbank durch, um relevante Daten abzurufen. Das Large Language Model (LLM) kombiniert den spezifischen operativen Kontext mit seinem Allgemeinwissen, um eine Antwort zu generieren.

Ein Kubernetes-Controller kann die Dokumentenerfassung automatisieren und so dafür sorgen, dass die Pipeline kontinuierlich läuft und mit den Dokumentationen und Ressourcen synchron bleibt, wenn sich diese ändern. Für die meisten Infrastrukturteams befindet sich die Arbeitslast bereits in Kubernetes, sodass keine separate Orchestrierungsebene eingeführt werden muss.

Beachten Sie, dass RAG die Infrastruktur etwas komplexer macht, da es mehrere bewegliche Teile gibt. Außerdem ist die Datenqualität entscheidend, da schlecht strukturierte Daten zu unzuverlässigen Ergebnissen führen können.

Daten können auch veralten. Wenn sie in der Vektordatenbank verbleiben, nachdem jemand die Quelldokumente aktualisiert hat, ruft das RAG widersprüchliche Informationen ab. Entwickler sollten die Pipeline so gestalten, dass alte Daten entfernt werden, anstatt nur neue Daten anzuhängen.

Sicherheitsrisiken durch KI-Agenten in der Infrastruktur verhindern

Da KI-Agenten immer stärker in die Infrastruktur eingebettet werden, werden sie zu einem zentralen Thema in Bezug auf Sicherheit und Compliance. Im Folgenden sind drei wichtige Sicherheitsbereiche aufgeführt, die Unternehmen frühzeitig angehen müssen:

• Berechtigungs- und Zugriffskontrollen. Agenten sind nicht nur passive Werkzeuge; sie greifen ständig auf sensible Unternehmensdaten zu. Daher sollten Agenten wie Mitarbeiter mit privilegiertem Zugriff behandelt werden, da die Auswirkungen eines Fehlers ebenso groß sind. Sie sollten in der Lage sein, Infrastruktur-Cluster zu ändern, aber keinen Zugriff auf das Cloud-Abrechnungssystem haben. Sie sollten Pull-Anfragen erstellen können, aber ihre eigene Arbeit nicht ohne menschliche Genehmigung in die Produktion einbinden dürfen.
• Sicherheitsbarrieren. Dies sind wesentliche Schutzmaßnahmen, um die Handlungsmöglichkeiten eines Agenten einzuschränken. Agenten sollten keine risikoreichen Aktionen ausführen, ohne dass ein Mensch in den Prozess eingebunden ist. Dazu können Aktionen wie Datenbankbereitstellung, Datenlöschung und die Ausführung von Finanztransaktionen gehören.
• Observability. KI-Schlussfolgerungen sind nicht deterministisch. Eingaben, Ausgaben und LLM-Schlussfolgerungen sind unvorhersehbar. Agenten könnten Tools aufrufen, mit denen Ingenieure nicht gerechnet haben. Wenn man Agenten dieselben Fragen stellt, können sie unterschiedliche Antworten geben. Aus diesen Gründen müssen Teams die Observability über Agenten hinweg gewährleisten. Observability Tools können auf KI-Agenten ausgeweitet werden, um deren Verhalten abzudecken und eine einheitliche Ansicht über Tool-Aufrufe, Modelleingaben und -ausgaben hinweg zu bieten. Dies sollte als unverzichtbare Anforderung betrachtet werden, nicht als nachträglicher Einfall.

Die betrieblichen Herausforderungen bei der Skalierung von KI-Agenten für die Infrastruktur

Die beiden wichtigsten betrieblichen Herausforderungen, auf die sich Ingenieure bei der Nutzung von KI-Agenten für die Infrastrukturentwicklung einstellen müssen, sind Einschränkungen des Kontextfensters und Kosten.

Einschränkungen des Kontextfensters

Letztendlich werden Agenten mit einer großen Menge an Daten aus verschiedenen Quellen arbeiten. Wenn Ingenieure diese Daten immer weiter in das Kontextfenster des KI-Agenten stapeln, wird dieser bald ausfallen. Ein breiterer Kontext liefert keine besseren Ergebnisse. Stattdessen kann er zu Leistungseinbußen, höheren Kosten und ungenauen Antworten führen, die das System unbrauchbar machen.

Um dies zu verhindern, sollte jede Interaktion mit dem MCP-Server mit einem völlig neuen Kontext beginnen. Der MCP erhält die relevanten Informationen, die er zur Bearbeitung der spezifischen Aufgabe benötigt, unabhängig davon, wann diese Informationen ursprünglich abgerufen oder erstellt wurden.

Kosten

Die Kosten für agentische KI-Systeme steigen schnell an, wenn mehrere Systeme gleichzeitig betrieben werden. Eine einzige Abfrage kann eine mehrstufige Schlussfolgerungskette auslösen, die mehrere Tools aufruft und Token verbraucht. Mit Modell-Routing können Ingenieure verschiedene Arten von Anfragen an Agenten weiterleiten, die unterschiedliche Modelle ausführen.

Das Routing im Modell selbst durchzuführen, funktioniert besser. Der Agent kann entscheiden, welches Modell für welche Aufgabe verwendet wird. Für einfachere Aufgaben wie das Zusammenfassen und Klassifizieren von Daten können Ingenieure ein kostengünstiges Modell verwenden und leistungsstärkere Modelle für komplexe Schlussfolgerungen aufheben.

Blaupause für IT-Führungskräfte

Für IT-Führungskräfte, die Investitionen in agentische KI innerhalb der Infrastruktur tätigen oder verteidigen, sollte die Architektur, die das Versprechen wirklich einlöst, Folgendes umfassen:

• Mehrere spezialisierte Agenten. Anstelle eines einzigen monolithischen KI-Agenten sollten mehrere eingesetzt werden, von denen jeder auf einen Bereich mit spezifischen Aufgaben zugeschnitten ist.
• Einen MPC-Server. Unternehmen sollten diesen Server in Tools integrieren, die ihre Ingenieure bereits nutzen.
• Eine Systemkontextschicht. Diese versorgt KI-Agenten mit Unternehmenswissen und operativen Anleitungen.
• Eine Vektordatenbank. Diese speichert Daten, die KI-Agenten aus Unternehmensressourcen und Dokumentationen aufschlüsseln.
• Agentenspeicher. Der Speicher ermöglicht es Agenten, aus ihren eigenen Erfahrungen zu lernen.
• Sicherheitsvorkehrungen. Priorisieren Sie Sicherheitsvorkehrungen für kritische Elemente, die Produktionssysteme beeinflussen, und integrieren Sie Human-in-the-Loop-Strategien.
• Eine beobachtbare Konfiguration. Die Unternehmensleitung behält den vollständigen Überblick über die Systemleistung und die damit verbundenen Kosten.