Infrastructure as Code ist etabliert – aber noch nicht wirklich intelligent
Terraform, Pulumi, Ansible, CloudFormation – wer heute Infrastruktur betreibt, kommt an Infrastructure-as-Code-Werkzeugen kaum vorbei. Sie ermöglichen reproduzierbare, versionierbare und prüfbare Infrastruktur. Trotzdem bleibt IaC fehleranfällig: Konfigurationsdriften, vergessene Abhängigkeiten, veraltete Module und inkonsistente Benennung sind in der Praxis häufige Ursachen für Störungen.
Genau hier beginnen LLMs einen echten Mehrwert zu liefern – nicht als Ersatz für IaC-Werkzeuge, sondern als intelligente Schicht darüber.
Bildquelle: Pexels / ThisIsEngineering – Entwicklerin vor mehreren Monitoren als Symbolbild für moderne DevOps-Arbeit
Was LLMs bei IaC heute leisten können
Die Integration von Sprachmodellen in IaC-Workflows ist 2026 kein Zukunftsszenario mehr, sondern in vielen Teams gelebte Praxis. Die Einsatzbereiche lassen sich in drei Kategorien einteilen:
1. Code-Generierung und -Übersetzung
Wer eine neue AWS-VPC mit mehreren Subnetzen, Security Groups und einem NAT-Gateway aufsetzen will, kann das heute per natürlichsprachigem Prompt beschreiben und erhält in Sekunden eine Terraform-Konfiguration, die als Startpunkt dient. Ähnliches gilt für die Übersetzung zwischen IaC-Formaten: Wer von CloudFormation auf Terraform migriert, kann LLMs nutzen, um Template-Blöcke zu übersetzen und zu kommentieren.
Wichtig: Der generierte Code ist ein Ausgangspunkt, kein fertiges Ergebnis. Policy-Checks (z. B. über Open Policy Agent oder Checkov) und manuelles Review bleiben unverzichtbar.
2. Drift-Erkennung und -Erklärung
Wenn terraform plan eine lange Ausgabe mit unerwarteten Änderungen produziert, fällt es manchmal schwer, schnell zu erfassen, was davon kritisch ist und was harmlos. LLMs können dabei helfen, Plan-Outputs zu lesen, zu klassifizieren und in verständliche Sprache zu übersetzen – inklusive einer Einschätzung, welche Änderungen besondere Aufmerksamkeit verdienen.
„Diese Änderung betrifft die Security Group sg-0abc123 und erlaubt neu eingehenden Traffic auf Port 443 aus allen Quellen. Das sollte geprüft werden, ob es der Intention entspricht."
Solche Hinweise beschleunigen den Review-Prozess – vor allem in Teams, in denen nicht jede Person gleich tief in alle Infrastrukturkomponenten eingearbeitet ist.
3. Dokumentationsgenerierung
IaC-Code ist oft schlecht dokumentiert. LLMs können aus bestehenden Terraform-Modulen automatisch Dokumentation generieren: Was macht dieses Modul? Welche Variablen sind Pflicht? Was sind typische Fallstricke? Das verbessert die Onboarding-Erfahrung und reduziert Rückfragen im Team.
Pulumi und die Sprachintegration
Pulumi unterscheidet sich von Terraform dadurch, dass Infrastruktur in echten Programmiersprachen (TypeScript, Python, Go, C#) beschrieben wird. Das hat Vorteile – volle Ausdruckskraft, Tests, Typsicherheit – aber auch eine steilere Lernkurve.
LLM-Assistenten sind bei Pulumi besonders nützlich, weil sie Infrastrukturanforderungen direkt in Programmcode übersetzen können. Wer Python kennt, aber die Pulumi-SDK-API nicht auswendig lernen will, kann per Prompt beschreiben, was gebraucht wird, und erhält funktionierenden Code als Basis.
Sicherheitsrisiken beim KI-gestützten IaC
Der Einsatz von LLMs in IaC-Workflows birgt auch Risiken, die ernst genommen werden sollten:
- Falsch konfigurierte Ressourcen: Generierter Code enthält manchmal unsichere Standardwerte – offene Security Groups, fehlende Verschlüsselung oder zu weitreichende IAM-Berechtigungen. Static Analysis ist Pflicht.
- Halluzinierte Ressourcen oder Provider-Versionen: Modelle können veraltete API-Versionen oder nicht existierende Attribute verwenden. Immer die offizielle Dokumentation des Providers gegenprüfen.
- Sensible Daten im Prompt: Account-IDs, ARNs und Secrets gehören nicht in Prompts, die an externe API-Dienste gesendet werden. Lokale Modelle oder strikte Datentrennung sind hier sinnvoll.
Best Practices für den Einsatz in der Praxis
Wer LLMs sinnvoll in IaC-Workflows integrieren will, sollte folgende Grundsätze beachten:
- Generierter Code immer durch ein statisches Analyse-Tool laufen lassen (Checkov, tfsec, KICS).
- Module aus vertrauenswürdigen Registries bevorzugen – LLM-generierte Module sind kein Ersatz für gepflegte Community-Module.
- Kein direktes Apply ohne Planung:
terraform planist immer der erste Schritt, unabhängig davon, wer oder was den Code geschrieben hat. - Drift regelmäßig überwachen – KI kann bei der Erklärung helfen, aber der Erkennungsprozess selbst braucht klare Pipelines und Alerting.
- Dokumentation als festen Bestandteil des Workflows verstehen, nicht als optionalen Nachschritt.
Welche Werkzeuge sich gut kombinieren lassen
In der Praxis haben sich einige Kombinationen als besonders nützlich erwiesen:
- Terraform + Claude via API: Plan-Output direkt an ein Sprachmodell senden und eine Zusammenfassung der kritischen Änderungen erhalten.
- Pulumi + Code-Assistent im Editor: Direkt im IDE-Plugin arbeiten, das auf Basis der geöffneten Infrastruktur-Dateien ergänzt und erklärt.
- Ansible + LLM-Playbook-Generator: Für Ops-Teams, die keine tiefen Python-Kenntnisse haben, aber Automatisierungen schnell aufbauen müssen.
Fazit: IaC wird smarter, aber nicht autonomer
LLMs verändern, wie Infrastructure as Code geschrieben, geprüft und dokumentiert wird. Sie beschleunigen die Arbeit, senken die Einstiegshürde und helfen dabei, Fehler früh zu erkennen. Was sie nicht leisten: eigenständig verlässliche Produktionskonfigurationen liefern. Die Entscheidungsverantwortung bleibt beim Team.
2026 ist der kluge Einsatz von KI im IaC-Workflow kein Differenzierungsmerkmal mehr – er wird zur Grunderwartung. Teams, die jetzt damit beginnen, bauen Erfahrung auf, bevor es zur Notwendigkeit wird.
Quellen: Terraform-Dokumentation (developer.hashicorp.com), Pulumi-Dokumentation (pulumi.com), Checkov-Dokumentation (checkov.io), eigene Einschätzung 2026.
