Infrastructure as Code: Brauchen wir IaC noch in Zeiten von AI Agents?

AI Agents provisionieren Cloud-Ressourcen über APIs, interpretieren Observability-Daten in Echtzeit und reagieren auf Incidents, ohne menschliches Zutun. Terraform-Plan, Review, Apply: Ist dieser Zyklus noch zeitgemäß, wenn ein Agent dieselbe Änderung in Sekunden umsetzen kann?

Die kurze Antwort: Ja. Und zwar mehr denn je.

Denn wer Agents ohne belastbare Leitplanken auf Produktionsinfrastruktur loslässt, tauscht manuelle Fehler gegen automatisierte Fehler. Nur schneller und mit größerem Blast Radius. Infrastructure as Code wird nicht obsolet. Es wird zur Governance-Schicht, die autonomen Agents den sicheren Handlungsrahmen vorgibt. Entscheidend ist dabei ein klares Trust-Level-Framework: Wie viel Autonomie ist heute vertretbar, und welche Guardrails müssen dafür stehen?

Was ist Infrastructure as Code, und warum hat es sich durchgesetzt?

Infrastructure as Code bedeutet, dass Infrastruktur nicht manuell konfiguriert, sondern in Code beschrieben wird. Tools wie Terraform, Pulumi, CloudFormation oder Bicep ermöglichen es, Server, Netzwerke und Datenbanken deklarativ zu definieren, zu versionieren und automatisiert auszurollen.

Reproduzierbarkeit und Konsistenz

Der größte Vorteil von IaC ist Determinismus. Gleicher Code führt zum gleichen Ergebnis, egal ob in der Entwicklungsumgebung oder in Produktion. Das eliminiert die klassischen „Works on my machine"-Probleme auf Infrastrukturebene.

Auditierbarkeit durch Versionierung

Jede Änderung an der Infrastruktur ist in der Git-History nachvollziehbar. Wer hat was, wann und warum geändert? Für regulierte Branchen wie Finanz oder Gesundheitswesen ist das keine Option, sondern Pflicht.

Skalierung und Zusammenarbeit

Infrastructure as Code erlaubt es Teams, hunderte Environments aus einem einzigen Template zu erzeugen. Pull Requests und Code Reviews machen Infrastrukturänderungen zum Teamsport, genau wie bei Anwendungscode.

Das Argument gegen IaC: AI Agents können Infrastruktur direkt managen

AI Agents werden immer leistungsfähiger. Sie interpretieren Logs, analysieren Kosten, erkennen Sicherheitslücken und können über Cloud-APIs direkt Ressourcen erstellen oder ändern. Warum also noch der Umweg über deklarativen Code?

Geschwindigkeit und Reaktionsfähigkeit

Ein Agent reagiert in Sekunden. Kein Plan-Apply-Zyklus, kein Warten auf CI/CD-Pipelines. Wenn ein Service unter Last steht, kann ein Agent sofort skalieren, ohne dass jemand ein Terraform-File anpassen muss.

Kontextverständnis über Silos hinweg

Wo Menschen zwischen Monitoring-Dashboard, Cost Explorer und Architektur-Dokumentation hin- und herspringen, sieht ein Agent alle Datenquellen gleichzeitig. Das ermöglicht Entscheidungen, die mehrere Dimensionen berücksichtigen.

Weniger Komplexität für Endanwender

Kein State-File-Management, keine Provider-Versionen, keine HCL-Syntax-Fehler. AI Agents könnten Infrastruktur Management demokratisieren und auch Nicht-DevOps-Teams den Zugang zu Cloud-Ressourcen erleichtern.

Effizienz und Kosteneinsparung

Agents reduzieren manuelle Ops-Aufwände signifikant: weniger Bereitschaftseinsätze, schnellere Incident Resolution, geringerer Koordinationsaufwand zwischen Teams. Für das mittlere Management ist das ein relevanter Hebel, um Investitionen in Automatisierung gegenüber der Geschäftsführung zu begründen.

Warum wir Infrastructure as Code gerade jetzt brauchen: Guardrails für AI Agents

Die Stärke von AI Agents, Geschwindigkeit und Autonomie, ist gleichzeitig ihr größtes Risiko. Und die relevantere Frage für viele Organisationen ist nicht, ob sie AI Agents einsetzen wollen, sondern ob ihre Teams es nicht längst tun, ohne dass Governance-Strukturen dafür existieren. Genau hier wird Infrastructure as Code zur unverzichtbaren Sicherheitsschicht.

Deklarativer Soll-Zustand als Vertrag

IaC definiert, was existieren soll. Ein Agent kann entscheiden, wie und wann Änderungen umgesetzt werden, aber nur innerhalb dieses definierten Rahmens. Der deklarative Soll-Zustand wird zum Vertrag zwischen Mensch und Maschine.

Policy-as-Code als Sicherheitsnetz

Tools wie OPA/Rego, Sentinel oder Checkov definieren Regeln, die jede Infrastrukturänderung einhalten muss. Diese Policies sind unverzichtbar, wenn ein autonomer Agent Änderungen vornimmt. Sie verhindern, dass ein Agent versehentlich eine Datenbank öffentlich zugänglich macht oder eine Security Group zu weit öffnet.

Blast-Radius-Kontrolle

Ein Mensch, der manuell arbeitet, macht einen Fehler nach dem anderen, langsam genug, um Schäden zu begrenzen. Ein Agent ohne Guardrails kann mit einem einzigen API-Call eine Produktionsdatenbank löschen. Infrastructure as Code erzwingt Review-Gates und Approval-Prozesse, die den Blast Radius jeder Änderung begrenzen.

Compliance und Auditierbarkeit

„Der Agent hat das gemacht" reicht keinem Auditor. Regulierte Organisationen brauchen eine versionierte, nachvollziehbare Änderungshistorie. IaC liefert genau das, auch wenn die Änderung von einem Agent initiiert wurde.

Deterministische Reproduzierbarkeit

Agent-Entscheidungen sind oft nicht-deterministisch. Derselbe Kontext kann zu unterschiedlichen Ergebnissen führen. Für Disaster Recovery ist das untragbar. Infrastructure as Code garantiert: gleicher Input, gleiches Ergebnis. Diese Garantie ist nicht verhandelbar.

Eine Frage des Vertrauens: Das Trust-Level-Framework für AI Agents

Wie viel Autonomie sollten Sie AI Agents in Ihrem Infrastruktur Management geben? Die Antwort ist kein Entweder-oder, sondern ein Spektrum. Angelehnt an etablierte Autonomie-Stufenmodelle wie die SAE Levels im autonomen Fahren lässt sich auch für das Infrastruktur Management ein abgestuftes Trust-Level-Modell formulieren.

Entscheidend dabei: Vertrauen ist eine risikobasierte Entscheidung. Das passende Trust-Level ist keine technische, sondern eine organisatorische Entscheidung. Sie hängt direkt vom Risikoappetit, der Kritikalität der betroffenen Systeme und den regulatorischen Anforderungen ab. Frameworks wie NIS-2 und ISO 27001 geben hier den Rahmen vor. NIS-2 fordert ein nachweisbares Risikomanagement für Netz- und Informationssysteme, ISO 27001 verlangt dokumentierte Kontrollen und eine kontinuierliche Risikobewertung. Wer AI Agents auf Infrastruktur loslässt, muss das gewählte Trust-Level in genau diesen Kontext einordnen und nachweisbar begründen können.

Level 0: Read-Only

Der Agent beobachtet und berichtet. Er fasst Monitoring-Daten zusammen, erkennt Anomalien und informiert das Team. Keinerlei Schreibzugriff auf die Infrastruktur.

Level 1: Suggest

Der Agent schlägt Änderungen vor, zum Beispiel als automatisch erstellter Pull Request auf ein Terraform-Modul. Die Entscheidung und Ausführung bleibt beim Menschen.

Level 2: Act with Approval

Der Agent erstellt einen konkreten Änderungsplan und führt ihn nach menschlicher Freigabe aus. Das ist heute der realistischste Einstieg in agentengestütztes DevOps.

Level 3: Act within Boundaries

Der Agent handelt autonom, aber nur innerhalb klar definierter Grenzen. Auto-Scaling innerhalb festgelegter Min-Max-Werte oder Self-Healing nach vordefinierten Runbooks sind typische Beispiele.

Level 4: Full Autonomy

Der Agent managt die Infrastruktur vollständig eigenständig. Für Produktionsumgebungen ist dieses Level heute kaum vertretbar, denn es fehlen belastbare Standards für Zuverlässigkeit, Erklärbarkeit und Haftung.

Die meisten Organisationen stehen aktuell bei Level 0 bis 1. Der realistische Sweet Spot für die nächsten zwei bis drei Jahre liegt bei Level 2 bis 3.

Ausblick: Wie AI Agents das Infrastruktur Management verändern werden

Infrastructure as Code verschwindet nicht. Aber es verändert sich.

Vom Schreiben zum Reviewen

DevOps Engineers werden weniger IaC selbst schreiben und stattdessen Agent-generierte Vorschläge reviewen. Die Kernkompetenz verschiebt sich von Syntax-Wissen hin zu Architekturverständnis und kritischer Bewertung.

Intent-based Infrastructure

Statt „Erstelle eine EC2-Instanz mit t3.large" werden Teams sagen: „Ich brauche einen Service, der 1.000 Requests pro Sekunde aushält." Der Agent wählt die passende Umsetzung, innerhalb der Guardrails, die IaC und Policy-as-Code definieren.

Continuous Reconciliation

Agents werden Drift in Echtzeit überwachen und autonom korrigieren. Der deklarative Soll-Zustand aus dem IaC-Code bleibt dabei die verbindliche Referenz.

Fazit: Infrastructure as Code wird zum Betriebssystem für AI Agents

Die Frage ist nicht „Infrastructure as Code oder AI Agents?". Beide gehören zusammen. IaC liefert den deklarativen Rahmen, die Auditierbarkeit und die deterministische Reproduzierbarkeit. AI Agents bringen Geschwindigkeit, Kontextverständnis und Adaptivität.

Infrastructure as Code wird nicht überflüssig. Es wird zur Grundlage, auf der AI Agents sicher und kontrolliert agieren. Wer heute in solide IaC-Praktiken, Policy-as-Code und ein durchdachtes Trust-Level-Framework investiert, schafft die Voraussetzungen für ein Infrastruktur Management, das mit der Geschwindigkeit von Agents Schritt hält, ohne die Kontrolle zu verlieren.

Die entscheidende Frage für Ihr Team lautet nicht, ob AI Agents kommen. Sie lautet: Welches Trust-Level sind Sie bereit zu geben, und welche Guardrails setzen Sie dafür? Wie Sie das passende Trust-Level für Ihre Organisation bestimmen und die notwendigen Guardrails etablieren, hängt von Ihrem individuellen Risikoprofil ab. Bei Posedio begleiten wir Organisationen dabei, Infrastruktur Management an dieser Schnittstelle von Automatisierung, Governance und Regulatorik zukunftssicher aufzustellen.