Infrastructure-as-Code- und DevOps-Assistent

Cloud- und Plattform-Teams verbringen einen großen Teil ihrer Zeit damit, deklarative Konfigurationen zu schreiben und zu prüfen: Terraform-Module, Kubernetes-Manifeste, Helm-Charts, Ansible-Rollen und CI/CD-Pipelines. KI-Assistenten erzeugen diesen Code heute auf Grundlage aktueller Provider-Dokumentation, erklären, was ein Plan ändern wird, beheben Richtlinienverstöße und eröffnen Pull Requests. Das Anwenden von Änderungen bleibt hinter Plan-Prüfung, Richtlinienprüfungen und menschlicher Freigabe, denn eine falsche Zeile kann hier die Produktion löschen.

Problem & Nutzen

• Heute: Ingenieure kopieren Schnipsel aus Registries und alten Modulen, suchen Fehler bei der YAML-Einrückung und bei geänderten Provider-Argumenten und prüfen lange Plan-Ausgaben. Das Wissen liegt bei wenigen Spezialisten; die Abweichung (Drift) zwischen Code und tatsächlichem Zustand wächst; Befunde aus Sicherheits-Scannern stauen sich als Rückstand.
• Nutzen durch KI: schnellere erste Entwürfe von Modulen und Pipelines, verständliche Plan-Zusammenfassungen für Prüfer, automatische Korrektur-PRs für Scanner-Befunde, Einarbeitung von Nicht-Spezialisten und Antworten auf Fragen zum laufenden Zustand („Welche Buckets sind öffentlich?“).
• Evidenzlage: Anbieter berichten von Produktivitätsgewinnen, doch unabhängige, auf Infrastruktur bezogene Messungen sind selten; messen Sie an Ihren eigenen Repositories, bevor Sie sich auf Ziele festlegen.
• Fundierung zählt: Modelle, die mit älteren Daten trainiert wurden, schlagen veraltete Provider-Argumente vor; Tool-Server, die aktuelle Registry-Dokumentation bereitstellen, begegnen dem direkt [1].

Varianten

• KMU / kleines IT-Team: Assistent in der IDE plus eine geprüfte CI-Pipeline; verwaltetes Kubernetes oder einige Terraform-Stacks.
• Plattform-Engineering im Großunternehmen: gesteuerter Agent mit Organisationskontext, Policy-as-Code-Leitplanken, Freigabeschranken und einem internen Modulkatalog („Golden Paths“) [2].
• Öffentlicher Sektor / regulierte Bereiche: wie zuvor, aber mit selbst betriebenem oder EU-souveränem Modell-Hosting, Audit-Trail und Nachweisen zum Änderungsmanagement für ISO 27001, NIS2 oder DORA.
• Assistent für den Kubernetes-Betrieb: kubectl in natürlicher Sprache, Manifest-Erzeugung und Cluster-Diagnose (kubectl-ai, k8sgpt) [4][5].
• Privat/Homelab: Docker-Compose-, Ansible- und Home-Assistant-Konfigurationen über ein lokales Code-Modell.

So funktioniert es

1. change request / ticket / scanner finding
2. context retrieval (repo, module catalogue, registry docs via MCP, live state read-only)
3. LLM / coding agent drafts IaC change on a branch
4. static checks (fmt, validate, tflint, policy-as-code, Checkov/Trivy)
5. plan in sandbox / ephemeral environment
6. plan summarised by LLM
7. pull request + AI review (CODE-003)
8. human approval (four-eyes)
9. CI applies with scoped, short-lived credentials
10. drift detection loop

• Fundierung: Der Terraform MCP Server liefert Agenten Provider- und Moduldaten aus der Registry und optional Workspace-Operationen in HCP Terraform; zerstörerische Operationen sind standardmäßig hinter einem ausdrücklichen Schalter deaktiviert, und HashiCorp warnt davor, ihn mit nicht vertrauenswürdigen Clients oder Modellen zu koppeln [1].
• Agentenschleife: erzeugen → validieren → Fehler lesen → korrigieren, begrenzt durch Iterations- und Kostengrenzen.
• Mensch-in-der-Schleife (Human-in-the-Loop): Der Agent erhält nur lesende Zugangsdaten; apply, Löschen sowie IAM- und Netzwerkänderungen brauchen immer eine menschliche Freigabe; Änderungen an der Produktion laufen ausschließlich über die Pipeline.

Datenaufbereitung

Klassische Daten werden kaum benötigt; die „Daten“ sind Ihr Infrastrukturwissen. Es liegt in Git-Repositories (Terraform, Helm, Ansible), CI/CD-Definitionen, Wikis, Tickets und oft nur in den Köpfen von ein bis zwei Administratoren. Typische Lücken: undokumentierte manuelle Änderungen in der Cloud-Konsole (Drift), veraltete oder kopierte Module, fest in Repositories eingetragene Geheimnisse, keine Namens- oder Tagging-Konventionen und kein Modulkatalog, aus dem der Agent abrufen kann.

Schritte der Aufbereitung: 1. Alles unter Versionskontrolle stellen und manuell angelegte Ressourcen in den State importieren (terraform import, OpenTofu). 2. Secret-Scanning (gitleaks, trufflehog) durchführen und jedes offengelegte Geheimnis rotieren, bevor ein Modell das Repository sieht. 3. Kurze Konventionen (Benennung, Tags, freigegebene Module) als Markdown-Datei festhalten, die der Agent liest, und einen Modulkatalog pflegen. 4. Policy-as-Code (Checkov, OPA) ergänzen, damit erzeugte Änderungen automatisch geprüft werden. 5. Einige gute frühere Pull Requests als Musterbeispiele sammeln.

Grober Anteil am Gesamtaufwand: etwa 10-20 Prozent, überwiegend für das Aufräumen von Repositories und Drift. Zum Export von Systemdaten und zu Musterbeispielen siehe PREP-005 und PREP-016, zu einer kuratierten Wissensbasis PREP-013 und zu Regeln, was in welches KI-Werkzeug darf, PREP-024.

Umsetzungswege

Welcher Weg für wen

• KMU: A. Teams ohne Plattform-Abteilung erhalten den schnellsten Nutzen von einem ausgereiften Coding-Assistenten (Copilot, Claude Code, GitLab Duo) mit durch Plan-Prüfung abgesicherten Pull Requests, ohne Agenten-Infrastruktur aufzubauen.
• Großunternehmen: B. Die Infrastruktur-Topologie ist strategisch, und interne Modulkataloge, Richtlinien und Leitplanken erfordern eine individuelle Integration, die ein Cloud-API-Agent in Ihrer CI-Pipeline leistet.
• Entwickler: C. Open-Weight-Code-Modelle mit OpenTofu, Checkov und Ollama oder vLLM halten die Repositories lokal und kosten keine Lizenz pro Arbeitsplatz.
• Öffentlicher Sektor: C. Infrastruktur-Topologie und Zugangsdaten sollten in einer souveränen Umgebung bleiben (STACKIT, IONOS, eigenes Rechenzentrum), was selbst betriebene Modelle ermöglichen.

Weg A — Kaufen (Standardsoftware; empfohlen für KMU)

• Agenten von IaC-Plattformen: Pulumi Neo (Agent in Pulumi Cloud, liest den Live-Zustand, eröffnet PRs, Richtlinien-Leitplanken und Freigaben; läuft auf Anthropic Claude über Amazon Bedrock) [2]; HashiCorp Terraform mit seinem MCP-Server und HCP Terraform [1]; Spacelift, env0, Scalr und Firefly (Israel) mit KI-Funktionen.
• Allgemeine Coding-Assistenten: GitHub Copilot, Cursor, Claude Code, JetBrains AI, Amazon Q Developer, Google Gemini Code Assist — alle beherrschen Terraform/YAML gut genug für Entwürfe (CODE-001/002).
• Cloud-eigene Betriebsassistenten: AWS, Azure und Google Cloud bieten Chat-/Agentenfunktionen für ihre eigenen Ressourcen (Verfügbarkeit je EU-Region prüfen).
• EU-Anbieter: Mistral (Codestral, Devstral), JetBrains (Tschechien), GitLab Duo mit EU- bzw. selbst verwalteten Optionen, STACKIT, IONOS und OVHcloud als souveräne Hosting-Ziele für die Infrastruktur selbst.
• A wählen, wenn: Sie bereits Pulumi/Terraform Cloud/GitLab einsetzen und den schnellsten Nutzen wollen.

Weg B — Auf Cloud-KI-Diensten aufbauen (empfohlen für Großunternehmen)

• Modelle: führende Code-Modelle (Claude, GPT, Gemini) oder Mistral Devstral/Codestral über EU- Endpunkte; Bedrock/Azure OpenAI/Vertex in EU-Regionen.
• Stack: Coding-Agent (Claude Code, OpenHands, Aider) in einem CI-Job oder Chatops-Bot; Terraform-MCP- Server und ein lesender Cloud-MCP für den Kontext; ein Schritt zur Plan-Zusammenfassung, der im PR postet.
• Leitplanken: minimale Rechte, kurzlebige OIDC-Zugangsdaten; OPA/Conftest- oder Sentinel-Richtlinien; Geheimnisse niemals in Prompts (Secret-Scanning vor Modellaufrufen).
• B wählen, wenn: Sie eigene Abläufe, interne Modulkataloge oder einen reinen EU-Datenpfad brauchen.

Weg C — Selbst betreiben (Open Source)

• Werkzeuge: OpenTofu (MPL 2.0, Linux Foundation/CNCF) [3], Checkov, Trivy, tflint, OPA, Kyverno, Argo CD/Flux, kubectl-ai [4], k8sgpt [5] mit lokalem Modell-Backend.
• Modelle: Open-Weight-Code-Modelle wie Qwen3-Coder, Devstral, die DeepSeek-Coder-Familie, Codestral (Lizenz prüfen), betrieben mit vLLM oder Ollama; MCP-Server sind modellunabhängig.
• Hardware: HW3 für Agenten-Abläufe mit einem Code-Modell ab 30B; HW2 genügt für Vervollständigung, Erklärung und Prüfungen im kleinen Maßstab mit quantisierten Modellen bis 30B.
• C wählen, wenn: Code oder Topologie-Informationen Ihr Netzwerk nicht verlassen dürfen (z. B. im Umfeld von Verteidigung, kritische Infrastruktur).

Weg D — Eigenes Training

Lohnt sich selten. Feintuning auf interne Module und Konventionen kann die Einhaltung des Hausstils verbessern, doch Retrieval über Ihren Modulkatalog plus Richtlinienprüfungen bringt meist mehr bei geringeren Kosten.

Stand der Technik (2026)

• Agenten mit Tool-Fundierung (MCP-Registry-Server, Zugriff auf den Live-Zustand) ersetzen reine Code- Vervollständigung; Anbieter positionieren sie als Kollegen im Platform Engineering statt als Autovervollständigung [2].
• Fork-Ökosystem: Terraform und OpenTofu entwickeln sich beide schnell (OpenTofu 1.12.x), daher muss erzeugter Code auf die eingesetzte Version festgelegt werden [1][3].
• Stärken: Boilerplate, Übersetzung zwischen Formaten (CloudFormation → Terraform), Pipeline- YAML, Erklärungen, Korrekturen von Scanner-Befunden.
• Fehlerbilder: erfundene Ressourcen-Argumente oder Module, unauffällig zu weit gefasste IAM-Richtlinien, fehlende Abhängigkeiten/Reihenfolgen, ungewollter Austausch von Ressourcen (löschen/neu anlegen), der sich in einem Plan verbirgt, Fehler an der State-Datei sowie Prompt Injection über Repository-Inhalte, Tickets oder Logs, die einen privilegierten Agenten steuern. Syntaktisch gültiger, aber inhaltlich falscher Code ist das Hauptrisiko.

Gemeinsame Bausteine & Kombinationen

• Gleicher Stack (llm-code + agent-framework): CODE-001 IDE-Unterstützung, CODE-002 autonome Coding-Agenten, CODE-003 Code-Review, CODE-021 Automatisierung von Abhängigkeiten/Refactoring — eine Agenten- Plattform und ein Modell-Endpunkt können alle bedienen.
• Nachgelagert/vorgelagert: CODE-010 AIOps (Störung → Korrektur-PR), CODE-011 Log-Analyse, SEC-004 Schwachstellenmanagement mit automatischer Korrektur (Befunde von IaC-Scannern).
• Gemeinsame Infrastruktur: MCP-Server, Umgang mit Geheimnissen und Sandbox-Runner sind für alle Agenten-Anwendungsfälle wiederverwendbar.

Aufwand, Kosten & Kennzahlen

• Weg A: Tage bis Wochen; Preis pro Arbeitsplatz oder pro Ressource.
• Weg B: 1–3 Monate für eine gesteuerte Pipeline mit Richtlinien, Sandbox-Plänen und Audit-Protokollierung; die Token-Kosten wachsen mit Repository-Kontext und Agenten-Iterationen.
• Weg C: 2–4 Monate plus GPU-Betrieb.
• Kennzahlen: Durchlaufzeit für Infrastrukturänderungen, Dauer der PR-Prüfung, Anteil der KI-erstellten PRs, die unverändert gemergt werden, Änderungsfehlerrate und Rollback-Rate (DORA-Metriken), Alter des Rückstands an Richtlinienverstößen, Drift-Vorfälle, Kosten pro Agenten-Aufgabe.

Menschen & Veränderung

Früh einbinden: die Geschäftsführung (Budget, KI-Richtlinie), die Plattform- bzw. Abteilungsleitung (Prozessverantwortliche) und die IT-Sicherheit (Zugangsdaten, minimale Rechte, Prompt Injection, siehe GUIDE-013). Recht/Compliance kommt hinzu, wenn kundenbezogene Infrastruktur berührt wird. Die Endanwender (Administratoren, Entwickler) sollten den Pilot mitgestalten, denn sie verantworten den Prüfschritt.

Betriebsrat: kommt darauf an. Reine Code-Erzeugung ist keine Überwachung, aber Assistenten und CI-Agenten protokollieren, wer was angefragt hat und welche Pull Requests angenommen wurden. Nach §87 Abs. 1 Nr. 6 BetrVG genügt nach der Rechtsprechung des Bundesarbeitsgerichts die objektive Eignung zur Überwachung, prüfen Sie daher Protokollierung und Nutzungsstatistiken. §90 Abs. 1 Nr. 3 verlangt zusätzlich eine rechtzeitige Unterrichtung, wenn Arbeitsabläufe unter Einsatz von KI geplant werden. Öffentlicher Sektor: Personalrat. Siehe GUIDE-004.

Datenschutz: Repositories und Logs enthalten selten personenbezogene Daten über Entwicklernamen hinaus; beziehen Sie die/den Datenschutzbeauftragte(n) kurz ein, schließen Sie mit dem Anbieter einen AVV und führen Sie eine DSFA nur durch, wenn personenbezogene Daten in großem Umfang einfließen.

KI-Kompetenz: Unterstützen Sie Mitarbeitende mit kurzen Schulungen dazu, erzeugten Code zu prüfen, nie Geheimnisse einzufügen und erfundene Module zu erkennen (GUIDE-006).

Kommunikation und Pilot: Beginnen Sie mit einem freiwilligen Team und Nicht-Produktionsumgebungen. Typische Sorge: „Die KI ersetzt Administratoren“ oder legt die Produktion lahm. Begegnen Sie ihr, indem Sie zeigen, dass der Agent nur lesende Zugangsdaten hat, dass apply immer eine menschliche Freigabe nach dem Vier-Augen-Prinzip braucht und dass gewonnene Zeit in Prüfungen und Automatisierung fließt (GUIDE-008, GUIDE-009).

Risiken, Regulierung & Compliance

• KI-Verordnung (AI Act): in der Regel minimales Risiko für Entwicklungswerkzeuge; die Pflicht zur KI-Kompetenz (Art. 4) gilt. Die Einstufung ändert sich nur, wenn der Agent Sicherheitskomponenten kritischer Infrastruktur autonom betreibt (Anhang III Nr. 2) — halten Sie ihn in der Änderungs-Pipeline, nicht in der Echtzeitsteuerung. Kein Verbot nach Art. 5 ist einschlägig [6].
• DSGVO: IaC und Logs können personenbezogene Daten enthalten (Benutzernamen, IPs, Tags); minimieren Sie den an Modelle gesendeten Kontext, nutzen Sie EU-Regionen und einen AVV und nehmen Sie niemals Produktionsdaten in Prompts auf.
• Branchenregeln: NIS2 (Sicherheit der Lieferkette und des Änderungsmanagements), DORA für Finanzunternehmen (IKT-Risikomanagement, Drittanbieter), ISO-27001-Änderungskontrolle; Cyber Resilience Act für Produkte. Dokumentieren Sie den KI-Einsatz in den Änderungsprotokollen.
• Sicherheitsrisiken: offengelegte Geheimnisse, überprivilegierte Zugangsdaten des Agenten, Prompt Injection über Tickets/READMEs, Lieferkettenrisiko durch vorgeschlagene Module. Gegenmaßnahmen: Nur-Lese-Standard, eng gefasste Zugangsdaten, festgelegte Modulversionen/Prüfsummen, signierte Commits, verpflichtende Prüfung und Policy-as-Code-Schranken.

Erste Schritte

1. Wählen Sie ein Repository mit geringem Risiko (z. B. einen Nicht-Produktions-Stack); aktivieren Sie einen Coding-Assistenten mit dem Terraform-MCP-Server im Nur-Lese-Modus.
2. Leitplanken zuerst: fmt/validate/tflint, Checkov oder Trivy, OPA-Richtlinien und eine verpflichtende Plan- Prüfung in der CI.
3. Lassen Sie den Assistenten bestehende Scanner-Befunde per PR beheben und Pläne für Prüfer zusammenfassen.
4. Erfassen Sie DORA-Metriken und PR-Prüfdauer vor und nach dem Einsatz als Ausgangswert; werten Sie Vorfälle mit falscher Ausgabe aus.
5. Erst danach den Umfang erweitern (mehr Stacks, Abfragen des Live-Zustands); apply- und IAM-Änderungen bleiben menschlich freigegeben.

Quellen

1. HashiCorp Terraform MCP Server (GA reporting, InfoQ) — https://www.infoq.com/news/2025/05/terraform-mcp-server
2. Pulumi Neo documentation — https://www.pulumi.com/docs/ai/neo/
3. OpenTofu project — https://opentofu.org/
4. kubectl-ai (Google Cloud Platform) — https://github.com/GoogleCloudPlatform/kubectl-ai
5. k8sgpt — https://github.com/k8sgpt-ai/k8sgpt
6. Regulation (EU) 2024/1689 (AI Act) — https://eur-lex.europa.eu/eli/reg/2024/1689/oj
7. Checkov — https://github.com/bridgecrewio/checkov