Plattform-Engineering: Rückgrat für die KI-Einführung im Unternehmen

Thenewstack

Die Landschaft der Technologieeinführung verschiebt sich, insbesondere im Hinblick auf künstliche Intelligenz. Die Ära der Top-Down-Vorgaben für Entwickler-Tools schwindet, da etwa die Hälfte aller Unternehmen die KI-Einführung inzwischen durch einen Bottom-Up-Ansatz fördern und Teams befähigen, mit neuen KI-Entwicklungstools zu experimentieren. Für Organisationen, die diese Umstellung nur langsam annehmen, wird der Aufstieg von „Schatten-KI“ – nicht genehmigte Tools, die von Mitarbeitern verwendet werden – bald eine formelle Einführung erforderlich machen.

Diese neu gewonnene Freiheit birgt jedoch auch erhebliche Risiken und potenziell Ineffizienz. Trotz über drei Jahren schneller KI-Integration haben nur 60 % der Organisationen eine akzeptable Nutzungsrichtlinie für KI etabliert. Obwohl zwei Drittel der Organisationen KI-Tools in Produktionsumgebungen eingesetzt haben, fehlt einem ähnlichen Anteil – 60 % – immer noch klare Metriken, um die Auswirkungen von KI effektiv zu messen. Darüber hinaus hat der intensive Fokus auf die 20 % des Entwickler-Tages, die mit Codieren verbracht werden, ein überraschendes Paradoxon offenbart: KI-generierter Code, obwohl als Produktivitätssteigerung wahrgenommen, kann tatsächlich den Entwicklerdurchsatz verlangsamen und die Zuverlässigkeit beeinträchtigen.

Dieses komplexe Umfeld unterstreicht die wachsende Relevanz des Plattform-Engineerings, das in den letzten Jahren maßgeblich als Reaktion auf die zunehmende Komplexität moderner Technologie-Stacks entstanden ist. Heute bietet es eine überzeugende Lösung für viele Hindernisse bei der KI-Einführung. Ähnlich wie die KI selbst ist Plattform-Engineering am effektivsten, wenn es die „Mühsal“ und andere Ablenkungen beseitigt, die Softwareentwickler daran hindern, Endbenutzern einen Mehrwert zu liefern.

Es war daher nicht überraschend, dass die vierte Ausgabe der PlatformCon im Juni stark Diskussionen über Plattform-Engineering im Kontext der KI enthielt. Eine interne Entwicklerplattform (IDP) kann sich als idealer Schutzmechanismus erweisen, um KI-Innovationen ohne katastrophale Folgen zu fördern. Luca Galante, eine prominente Stimme in diesem Bereich, betonte diesen Punkt und erklärte, dass KI zwar Schlagzeilen mache, „Plattformen für KI jedoch das Rückgrat all dessen sein werden“, indem sie die Schaffung von unternehmensweiten Wegen zur Produktion für alles von Datenwissenschaft und maschinellem Lernen bis hin zur traditionellen Entwicklung ermöglichen.

Das Zeitalter der KI erfordert eine Weiterentwicklung der IDP, um KI-Prozesse zu umfassen. Diese Erweiterung wird die skalierbare Bereitstellung bewährter KI-Anwendungsfälle in der gesamten Softwareentwicklung erleichtern und gleichzeitig Datensilos aufbrechen. Durch die Überbrückung dieser Lücken ist Plattform-Engineering in der Lage, Konsistenz, Qualität und Sicherheit bei der Bereitstellung sowohl autonomer KI-Agenten als auch generativer KI-Anwendungen zu gewährleisten.

Bis vor kurzem war KI weitgehend auf Datenwissenschaftsabteilungen beschränkt. Jetzt muss sie dem Verlauf der organisationsübergreifenden Cloud-Einführung folgen. Patrick Debois, Mitautor des „DevOps Handbook“, argumentierte auf der PlatformCon, dass KI ein dediziertes Plattformteam erfordert. In dieser neuen Ära entwickelt sich der KI-Ingenieur zu einem wichtigen Veränderungsagenten, der den beschleunigten Weg der Datenwissenschaft zur Produktion überbrückt, indem er mit dem Plattformteam bei der teamübergreifenden Zusammenarbeit, der Befähigung von Datenwissenschafts- und Anwendungsteams und einer robusten Governance zusammenarbeitet.

Debois stellt sich eine KI-fähige Variante der traditionellen internen Entwicklerplattform vor, die neu organisiert wird, um mehr KI-Stakeholder einzubeziehen und ihren Umfang auf die Verwaltung auszudehnen von: großen Sprachmodellen (LLMs), ob Open Source, proprietär oder hybrid; unstrukturierten und strukturierten Daten, die eine Indexierung über Vektordatenbanken erfordern; RagOps (Retrieval-Augmented Generation as a Service), einem aufkommenden Konzept, das Drittanbieter-Datenquellen integriert; KI-Agenten als Service, die Speicher, Zustand, Zugriffssteuerung und die Exposition gegenüber Model Context Protocol (MCP)-Servern umfassen; Ausführungsumgebungen für KI-Agenten; umfassende Zugriffs- und Versionskontrolle über alle Modelleingaben und -ausgaben; und eine zentrale Caching-Schicht zur Kostenverwaltung. Alle diese Komponenten wären über das „Single Pane of Glass“ der Plattform zugänglich und böten Transparenz und eine einheitliche Ansicht. Ein solch umfassendes, aber sich erweiterndes Toolset unterstreicht die Notwendigkeit einer IDP, um es effektiv zu verwalten. Debois schlägt vor, dass neue KI-Plattformteams damit beginnen sollten, Prototyping- und Sandboxing-Umgebungen für sichere Experimente mit neuen KI-Tools zu schaffen. Sobald Entwickler sich vertraut gemacht haben, kann ein standardisiertes Framework, das mit bestehenden Sprachen und einem robusten Ökosystem für Caching, Tests und Debugging abgestimmt ist, zu besser definierten „goldenen Pfaden“ für die KI-Entwicklung führen.

Debois skizzierte auch vier sich entwickelnde „KI-native Entwickler“-Muster: die Verschiebung vom Produzenten zum Manager, bei der Entwickler Code-Agenten mit Unterstützung des Betriebs verwalten; von der Implementierung zur Absicht, bei der Entwickler das „Was“ ausdrücken und die KI das „Wie“ übernimmt; von der Bereitstellung zur Entdeckung, wodurch die Kosten für Experimente durch bestehende CI/CD-Pipelines gesenkt werden; und von Inhalten zu Wissen, da KI einen überzeugenden Grund für Teams liefert, Wissen zu teilen, wodurch Wissen selbst zu einem einzigartigen Wertversprechen für Unternehmen werden kann.

Wie bei jeder Produktentwicklung müssen Plattformteams ihre Benutzerbasis berücksichtigen, die sich bei KI über traditionelle Entwickler hinaus erstreckt. Ina Stoyanova, Staff Infrastructure und Platform bei Equilibrium Energy, betonte die Notwendigkeit einer organischen Erweiterung nativer KI-Tools. In diesem frühen Stadium der KI, insbesondere für Startups, macht der schnelle Wandel starre, permanente Plattformfunktionen zu einer potenziellen Verschwendung. Durch die Einbeziehung von Stakeholdern identifizierte das Plattformteam von Equilibrium kritische Bedürfnisse sowohl für Softwareentwicklungs- als auch für Datenwissenschaftsteams, einschließlich Cluster-Management, Rechenressourcen, Datenressourcen, Daten-Tools, Speicher, Abfrageanalyse und Beobachtbarkeit. Datenwissenschafts- und quantitative Analyseteams hatten jedoch auch einzigartige Überlegungen, die zunächst nicht auf dem Radar des Plattform-Engineering-Teams waren. Stoyanova definierte Plattform-Engineering für ihr Team neu als „ein kuratiertes Set wiederverwendbarer Tools, Workflows, APIs und Dokumentationen, die internen Benutzern ermöglichen, Infrastruktur, Umgebungen und Bereitstellungspipelines mit minimalem kognitiven Aufwand selbst zu verwalten.“ Dieser benutzerzentrierte Ansatz, bei dem Benutzer gefragt werden „Welche Tools möchten Sie verwenden?“, ermöglichte es ihnen, die richtigen Lösungen zu entwickeln, ohne übermäßig zu investieren oder die Anpassungsfähigkeit des Startups zu behindern. Equilibrium Energy priorisierte von Anfang an auch die Kostenverfolgung und Metriken, ein Anwendungsfall, der sowohl bei Geschäfts- als auch bei technischen Teams Anklang fand.

Die effektive Nutzung von KI hängt davon ab, sowohl strukturierte als auch unstrukturierte Daten zu nutzen. Die interne Entwicklerplattform dient als Gerüst, auf dem Datenwissenschaftler und Machine-Learning-Ingenieure eine Datenstrategie aufbauen können, um KI-Anwendungsfälle voranzutreiben. Auf der PlatformCon kündigte die Platform Engineering Community eine neue Referenzarchitektur für KI an, die noch in diesem Jahr veröffentlicht werden soll. Diese Architektur bietet ein strukturiertes mentales Modell, das Beobachtbarkeit, Plattform-Schnittstellen und Versionskontrolle, Integration und Bereitstellung, Daten- und Modellmanagement sowie Sicherheitsebenen umfasst. Wie Luca Galante bemerkte, geht dies über technische Änderungen hinaus und verändert, wie die Branche das Plattform-Engineering-Team selbst wahrnimmt.

Traditionell bestanden Plattform-Engineering-Teams aus verschiedenen Rollen, von Plattform-Engineering-Leitern bis hin zu Infrastruktur-, Entwicklererfahrungs- und Produktmanagern, die Stakeholder wie Entwickler, Führungskräfte, Compliance-, Rechts-, Infrastruktur-, Betriebs- und Sicherheitsteams bedienten. Im Lichte der KI hat sich die Teamstruktur und Rollenentwicklung erweitert und umfasst nun Zuverlässigkeits-, Sicherheits-, Daten- und KI- sowie Beobachtbarkeits-Plattformingenieure. Dieses breitere Team interagiert nun mit einer noch größeren Bandbreite von Stakeholdern, wie Site Reliability Engineering-Teams, Architekten, Datenwissenschaftlern und Machine Learning Operations-Ingenieuren, was eine erhöhte Granularität spezifischer Bedürfnisse auf dem Markt widerspiegelt. Es besteht kein Zweifel, dass Plattformteams im Zeitalter der KI einen erweiterten Aufgabenbereich haben.

Eine Schlüsselrolle für moderne Plattformteams besteht darin, übergreifende Anwendungsfälle für die Bereitstellung generativer KI-Anwendungen zu identifizieren und zu skalieren sowie geeignete Designmuster (z. B. offene versus geschlossene generative KI-Modelle) auszuwählen. Majunath Bhat, VP Analyst und Fellow bei Gartner, hob jedoch auf der PlatformCon hervor, dass die größte Herausforderung für Plattformteams im Bereich KI Sicherheit und Governance ist, oft verknüpft mit Kostenauswirkungen. Da Produktteams in diesen Bereichen möglicherweise keine Expertise haben, stellen Architekten oft fachliches Wissen bereit. Um Anwendungen über bloße Prototypen hinaus zu skalieren, empfiehlt Bhat die Einrichtung eines Exzellenzzentrums für generative KI oder eines „Enabling Teams“ gemäß Team Topologies. Dieses Team würde eng mit Produktteams und Plattform-Engineering-Experten zusammenarbeiten und spezialisiertes Wissen bereitstellen, das dann skaliert werden kann. Bhat warnt davor, sofort eine gemeinsame Plattform aufzubauen, und wiederholt Stoyanovas Standpunkt: „Solange wir nicht verstehen, welche unterschiedlichen Anwendungsbedürfnisse bestehen, ist es nicht angebracht, dass das Plattformteam annimmt, diese Bedürfnisse zu verstehen.“ Dieser Ansatz, der „komplizierte Subsystem-Teams“ von KI-Experten umfassen könnte, kann die kognitive Belastung sowohl für Anwendungs- als auch für Plattformteams weiter reduzieren.

Ein neues Paradigma entsteht in der Anwendungssicherheit. Während KI-generierter Code ein größeres Volumen an zu scannendem und zu schützendem Code bedeutet, können autonome KI-Agenten auch bei der proaktiven und autonomen Behebung helfen. Die interne Entwicklerplattform ist nicht nur ein Kanal zum Rollout neuer KI-Tools, sondern auch eine entscheidende Schicht zur Etablierung von Schutzmechanismen, zur Verwaltung der rollenbasierten Zugriffssteuerung und zur Automatisierung von Sicherheitsprüfungen. Sónia Antão, Senior Product Manager bei Checkmarx, betonte auf der PlatformCon, dass die traditionelle Anwendungssicherheit mit mehr Code, mehr Mitwirkenden und kürzeren Zeitplänen nicht Schritt halten kann. Sie plädiert für die Integration autonomer KI-Agenten mit Application Security Posture Management (ASPM) direkt in die integrierte Entwicklungsumgebung (IDE) für Echtzeit-Codesicherheit. Dieser „intelligente Shift Left“ ermöglicht es AppSec, ein klares, risikobasiertes Gesamtbild der Anwendungslandschaft zu erhalten, nicht nur Schwachstellen frühzeitig zu erkennen, sondern diese auch schneller und mit Zuversicht in der vom Geschäft geforderten Geschwindigkeit zu beheben. Dieser Ansatz hat zu einer Reduzierung der Schwachstellen um 25-35 % und einer Verbesserung der Reaktionsgeschwindigkeit um 69 % geführt.

Generative KI kann Plattform-Engineering in adaptive, intelligente Systeme verwandeln, die die Entwicklerproduktivität, Zuverlässigkeit und Geschäftsausrichtung verbessern, wie Ajay Chankramath, Autor von „Effective Platform Engineering“, auf der PlatformCon 2025 diskutierte. Er stellte fest, dass sich generative KI von passiver Unterstützung zu autonomen, absichtsbewussten Agenten entwickelt hat, die selbstheilende Pipelines, Echtzeit-Feedback und personalisierte Codevorschläge ermöglichen. Zu den wichtigsten Einflüssen, die diese Verschiebungen vorantreiben, gehören Retrieval Augmented Generation (RAG), das die Antworten von KI-Agenten in Echtzeit, kontextbezogener Dokumentation verankert; das Model Context Protocol (MCP), das die Kommunikation von LLM-Agenten mit externen APIs standardisiert, um die Akzeptanz zu fördern; und die Integration generativer KI in CI/CD-Pipelines, die intelligente, selbstkorrigierende und selbstoptimierende Prozesse ermöglicht.

Chankramath beschrieb eine Entwicklung von Entwicklern, die „es selbst finden“ zu standardisierten IDPs und nun zur direkten Einbettung von KI-Agenten in Entwickler-Workflows. Der Betrieb hat sich von Ticket-basierten Ansätzen zu semi-Self-Service und nun zu absichtsgesteuerten autonomen Agenten entwickelt. Das Ziel, betonte er, ist nicht der Ersatz, sondern die Erhöhung: Entwicklern und Plattform-Ingenieuren zu ermöglichen, sich auf höherwertige Aktivitäten zu konzentrieren. Um diese Entwicklung des KI-gesteuerten Plattform-Engineerings zu unterstützen, bot er fünf Empfehlungen an: die KI-Strategie an den Wertströmen der Entwickler auszurichten und KI als integrierte, flussnative Komponenten zu behandeln; menschliches Urteilsvermögen immer einzubeziehen, um sicherzustellen, dass Agenten Aktionen vorschlagen, nicht genehmigen; KI-Agenten kollaborativ zu gestalten, indem Entwickler sie überschreiben, neu trainieren und rekontextualisieren können; Beobachtbarkeit und Schutzmaßnahmen standardmäßig zu integrieren, einschließlich Token-Trace-Logs, Prompt-Drift-Erkennung und Relevanzbewertung; und die Messung der KI-Auswirkungen über Genauigkeit und Latenz hinaus zu erweitern, um den Net Promoter Score (NPS) interner Kunden einzubeziehen und alle Erkenntnisse und Metriken zu teilen, um Vorteile zu beweisen und die Akzeptanz zu erhöhen.

Matthew Vollmer, Leiter des Blink Deep-Code Research Agent bei Coder, stimmte dem Gefühl der „Goldenen Pfade mit Leitplanken“ zu und betonte, dass das Ziel nicht nur die Nutzung von Agenten sei, sondern deren kluge Nutzung für Produktivität und Sicherheit. Dies erfordert, den Agenten Kontext zu geben (Dokumentation, Richtlinien, Codebasen), verantwortungsvolle Delegation (Tools zuerst an erfahrene Entwickler zu geben) und klare Grenzen durch isolierte, kurzlebige Umgebungen mit strengen Zugriffs Kontrollen und Nutzungslimits zu setzen. Die Einführung einer spezifikationsgesteuerten Entwicklung stellt sicher, dass KI-Agenten genau wie angewiesen funktionieren, wodurch Risiken oder übermäßige Kosten vermieden werden. Der optimale Punkt, so schlägt er vor, liegt darin, Agenten „eigenständige, klar definierte Aufgaben“ wie kleine bis mittlere Fehlerbehebungen zuzuweisen. Eine interne Entwicklerplattform kann dies erleichtern, indem sie KI-Agenten wie Teamkollegen einbindet. Vollmer erzählte eine Anekdote, in der ein Ingenieur die Erfahrung als „Paarung mit einem superschnellen Junior-Entwickler, der Code 100-mal schneller schreiben konnte als ein menschlicher Junior-Entwickler“ beschrieb. Durch die Auslagerung dieser „Routineaufgaben“ an die KI können Teams ihre Innovationszeit schützen und Entwicklern ermöglichen, sich auf hochwertige Arbeit zu konzentrieren.

Letztendlich gedeihen sowohl KI als auch Plattform-Engineering dort, wo die Reibung hoch ist. Plattform-Engineering zielt darauf ab, die kognitive Belastung der Entwickler zu reduzieren, ein Ziel, das KI bei korrekter Implementierung erheblich voranbringen kann. Diese Synergie kommt nicht nur einzelnen Entwicklern, sondern der gesamten Softwareorganisation zugute. Laut dem Atlassian State of Developer Experience 2025 nutzen Entwickler die durch KI gewonnene Zeit bereits, um Code zu verbessern, neue Funktionen zu entwickeln und Dokumentationen zu erstellen. Wenn die plattformgesteuerte KI-Einführung effektiv umgesetzt wird, führt dies zu noch mehr Zeit, die für wertschöpfende Aktivitäten aufgewendet werden kann.