Plattform-Engineering im Wandel: Was KI-Agenten wirklich verändern

KI-Agenten übernehmen zunehmend Aufgaben, die bislang explizite Interaktionsschichten erforderten – von der Infrastrukturbereitstellung bis zur Richtliniendurchsetzung. Das stellt Plattformteams vor die Frage: Welche Rolle spielen Infrastructure as Code und klassische API-Workflows künftig noch?

Dieser Beitrag basiert auf den Einschätzungen von Arnaud Lheureux, Chief Developer Advisor bei Microsoft für Asien, und David Wright, Partner Solution Architect bei Microsoft. Lheureux unterstützt Unternehmensteams bei der Einführung moderner Entwicklerplattformen; Wright begleitet ISVs beim Aufbau moderner SaaS- und KI-Agenten auf Azure. Die geäußerten Ansichten sind ihre eigenen.

Jahrelang basierten Plattform-Engineering-Workflows auf klar definierten Interaktionsschichten: CLIs, SDKs, Pipelines und UI-Prozesse übersetzten menschliche Absichten in maschinenlesbare API-Aufrufe. KI-Agenten verändern dieses Muster grundlegend – sie kombinieren Sprachverarbeitung, Schlussfolgern und direkten Zugriff auf API-Spezifikationen und können so ohne zwischengeschaltete Werkzeuge vom Intent zur Plattformaktion gelangen.

Besonders deutlich wird das im Bereich Infrastructure as Code (IaC) und Pipeline-Workflows, wo Agenten zunehmend als Interpreter zwischen Ingenieuren und Cloud-APIs wirken.

Das klassische Modell und seine Grenzen

Im traditionellen Ansatz durchläuft eine Infrastrukturänderung mehrere Ebenen:

• Architekturziele und Anforderungen als Ausgangspunkt
• Explizite Interaktionsschicht: CLI-Befehle, GitOps-Workflows, Pull Requests
• IaC-Abstraktion: CloudFormation, ARM/Bicep, Terraform HCL
• Providerebene: AWS, Azure, GCP und SaaS-Plattformen

Diese Schichtung sichert Korrektheit und Nachvollziehbarkeit – auf Kosten von Geschwindigkeit und einem hohen Maß an Werkzeugkenntnis.

Was sich mit KI-Agenten verändert

Moderne Agenten können diesen Ablauf erheblich verkürzen: Sie nehmen Absichten in natürlicher Sprache auf, lesen API-Schemas aus, generieren und validieren IaC und führen Änderungen direkt über Provider-APIs aus – eingebettet in Sicherheitsvorkehrungen und Genehmigungsschritte.

Wichtig: Agenten umgehen dabei keine APIs. Sie ersetzen Menschen als API-Übersetzer. Die bisherige Interaktionsschicht wird implizit; der Agent selbst übernimmt die Funktion des Steuerungsebenen-Interpreters.

IaC bleibt relevant – aber in veränderter Rolle

Auch heute gilt: IaC ist in Unternehmensumgebungen nach wie vor das bevorzugte System. Es liefert:

• Ein deterministisches Modell des gewünschten Zustands
• Eine versionierte Änderungshistorie
• Überprüfbare Pläne (Was-wäre-wenn, Plan, Änderungssätze)
• Einen Abgleichmechanismus bei Konfigurationsabweichungen

In agentenbasierten Workflows fungiert IaC als kanonisches Referenzregister, gegen das der aktuelle Plattformstatus geprüft wird. Agenten arbeiten mit IaC – sie ersetzen es nicht.

Der zukünftige Zustand: Wohin die Entwicklung zeigt

Langfristig zeichnet sich eine Verschiebung ab: Nicht APIs oder IaC verschwinden, sondern die Frage, wo die maßgebliche Wahrheit im Bereitstellungssystem liegt, wird neu beantwortet.

Wenn Agenten in der Lage sind, direkt über Anbieterschemata zu schlussfolgern, Änderungen mit integrierter Richtliniendurchsetzung auszuführen und vollständige, unveränderliche Ausführungsspuren zu erstellen, verschiebt sich die Rolle von IaC:

• Aus dem primären Absichtsformat wird ein Ausführungsformat unter mehreren
• Die maßgebliche Referenz rückt stromaufwärts: von wie Infrastruktur beschrieben wird zu warum sie existieren darf
• Sicherheits- und Compliance-Richtlinien, Architekturentscheidungsaufzeichnungen und genehmigte Referenzarchitekturen rücken als Hauptregister in den Vordergrund

Architekturartefakte als neues Hauptbuch

In einem agentenbasierten Modell werden verwaltete Dokumente zum eigentlichen Kontrollregister:

• Sicherheitsstandards (NIST, HIPAA, interne Richtlinien)
• Architekturentscheidungsaufzeichnungen (ADRs)
• Genehmigte Referenzarchitekturen und Diagramme
• Agenten-Ausführungsspuren als überprüfbare Belege

Herkömmliche IaC-Tools können weiterhin als Ausführungsformat oder Kompatibilitätsschicht dienen – müssen aber nicht mehr die einzige Quelle der Wahrheit sein.

Vier konkrete Auswirkungen auf Plattformteams

1. Interaktion verlagert sich von Syntax zu Absicht IaC wird zum Implementierungsdetail; Entwurfsgespräche konzentrieren sich auf das Was, nicht das Wie.

2. Governance wird in den Agenten integriert Richtliniendurchsetzung für Sicherheit, Kosten und Compliance erfolgt direkt in den Agentenanweisungen – mit manuellen Prüfpunkten an risikoreichen Stellen.

3. Module entwickeln sich zu wiederverwendbarem Wissen Statt starrer Variablensammlungen kodieren sie Architekturstandards, die der Agent automatisch auswählt und anwendet.

4. Abweichungskorrektur wird kontinuierlich Agenten erkennen Konfigurationsabweichungen, schlagen Korrekturen vor, erstellen Pläne, beantragen Genehmigungen und setzen Änderungen um.

Praxisbeispiele

• Netzwerksegmentierung: Der Agent liest ein genehmigtes Hub-and-Spoke-Diagramm, leitet daraus zulässige VNets, Routing-Tabellen und NSGs ab, wendet Änderungen über ARM-APIs an und dokumentiert den Nachweis im ADR.
• Identitätsgrenzen: Anhand eines Identitätsarchitekturdiagramms ermittelt der Agent zulässige Microsoft Graph-Operationen und blockiert Änderungen, die eine undefinierte Vertrauensgrenze überschreiten.
• Datenklassifizierungskontrollen: Diagrammatisch dargestellte Datenflüsse werden konkreten technischen Kontrollen zugeordnet – private Endpunkte, TLS-Durchsetzung, Aufbewahrungsrichtlinien – und per Read-Back-Abfragen validiert.
• Goldene Pfade als Blaupausen: Ein Referenzarchitekturdiagramm für einen Workload-Typ wird maschinenlesbar; der Agent wählt das Muster, befüllt Parameter, generiert Repositories und öffnet einen PR mit verknüpfter Begründung.

Drei Durchsetzungsebenen im modernen Stack

• Generierungszeit: KI wendet Muster und Richtlinien beim Schreiben von IaC an
• Planungszeit: Statische Analyse-Tools wie tflint, Sentinel und OPA erkennen Abweichungen vor dem Deployment – ergänzt durch Template Analyzer für Bicep/ARM und Linting in CloudFormation
• Laufzeit: Azure Policy als letzte Instanz – lehnt nicht konforme Deployments ab oder löst Korrekturen aus

Compliance als integrierter Prozess

Die GitHub-Plattform mit Copilot übernimmt dabei eine zentrale Steuerungsfunktion auf mehreren Ebenen:

• Kontextebene: Copilot Spaces kuratieren, was der Agent weiß – Architekturdokumente, genehmigte Muster, Sicherheitsrichtlinien
• Anweisungsebene: Repository- und organisationsweite Anweisungen kodieren Schutzmaßnahmen in natürlicher Sprache, versioniert gemeinsam mit dem Code
• Agentenebene: Benutzerdefinierte Agenten bündeln Anweisungen, Fähigkeiten und Kontext zu domänenspezifischen Einheiten
• Validierungsebene: GitHub Actions und Organisationsregelsätze blockieren nicht konformen Code vor dem Merge; Microsoft Defender for DevOps führt IaC-Sicherheitsscanner direkt in CI/CD aus

Microsoft Defender for Cloud schließt die Kette: Vom GitHub-Repository über IaC-Scan-Ergebnisse bis hin zu bereitgestellten Ressourcen und Laufzeitstatus – einschließlich der Rückverfolgung einer Fehlkonfiguration auf die auslösende IaC-Zeile.

Grafiken Quelle: Microsoft

Was das Plattformteam jetzt tun kann

Einstiegsschritte im Überblick:

• .github/copilot-instructions.md mit Basisregeln erstellen
• ADRs, Referenzimplementierungen und Muster in einem Copilot Space zusammenführen
• Wiederverwendbare Fähigkeiten entwickeln: CMDB-Abfragen, Namenskonventionsprüfung, Kostenstellenvalidierung
• Benutzerdefinierte Agenten aus Anweisungen, Fähigkeiten und Kontext zusammenstellen
• Den Coding Agent autonom arbeiten lassen: IaC generieren, PRs öffnen, auf Review-Feedback iterieren

Das Ergebnis verändert sich: Statt eines Moduls mit 47 Variablen liefert das Plattformteam einen Agenten, der den gesamten Infrastrukturkontext kennt und bei Bedarf konformen Code erzeugt.

Was sich nicht ändert

Provider-APIs bleiben die letztgültige Wahrheitsquelle. Menschliche Verantwortung – insbesondere bei Genehmigungen und Risikobewertungen – bleibt unverzichtbar.

Was sich ändert, ist das Aufzeichnungssystem: Richtlinien, Sicherheitskontrollen und Architekturartefakte übernehmen die Rolle des primären Registers. Agenten erzeugen den überprüfbaren Pfad dazwischen – von der Absicht bis zum Ergebnis.

Quellen: Arnaud Lheureux, Chief Developer Advisor bei Microsoft für Asien; David Wright, Partner Solution Architect bei Microsoft. Die geäußerten Ansichten sind ihre eigenen.

„Die in diesem Beitrag veröffentlichten Informationen wurden sorgfältig recherchiert. Dennoch übernehmen wir keine Gewähr für Vollständigkeit oder absolute Richtigkeit. Die Inhalte dienen der allgemeinen Orientierung und ersetzen keine fachkundige Beratung. Für etwaige Fehler, Auslassungen oder Folgen aus der Nutzung der Informationen übernimmt die Redaktion keine Haftung. Trotz sorgfältiger Prüfung können vereinzelt unbeabsichtigte Fehler oder Ungenauigkeiten, etwa bei Übersetzungen, auftreten.“

Lesen Sie mehr

---

Bild/Quelle: https://depositphotos.com/de/home.html

Folgen Sie uns auf X

Folgen Sie uns auf Bluesky

Folgen Sie uns auf Mastodon

Hamsterrad Rebell – Cyber Talk