Während Coding Agenten weit verbreitet sind und immer mehr Entwickler die Ergebnisse ohne Prüfung übernehmen, ist der „Human in the Loop“ in regulierten Umfeldern unverzichtbar. Für regulierte Unternehmen sind Governance und Kontrollmechanismen essenziell. Die IT-Compliance strebt nach dem Ziel, verfügbare und zuverlässige IT-Services bereitzustellen, inklusive der Transparenz darüber, was wann passiert.
Eine große Herausforderung dabei sind die Menge und Geschwindigkeit bei der Generierung von Code durch KI. Eine Kontrolle des Codes durch Menschen wird zunehmend zum Engpass.
Um bei der Nutzung von Coding Agenten die Kontrolle zu behalten, sind verschiedene Ansätze verbreitet. Von der gezielten Instruktion der lokalen Coding Agenten über deterministische Scans in der Pipeline und Reviews bis hin zur Nutzung von KI in einer Plattform wie GitLab. Auch organisatorische Änderungen spielen eine Rolle.
Lokale Regeln für Agenten
Ein Großteil der Entwicklung findet aktuell immer noch lokal auf den Rechnern der Entwicklungsteams statt. Dort werden Coding Agents gestartet, die dann Aufgaben abarbeiten. Dabei hat sich der Fokus in den letzten Monaten immer weiter verschoben, von Prompt Engineering über Harness Engineering zu Loop Engineering, mit steigender Autonomie der Agenten. Der Fokus liegt darauf, dass der Agent die richtigen Arbeitsweisen durch Prompts und Skills vorgeschrieben bekommt. Außerdem werden oft mehrere Agenten genutzt, die gegenseitig ihre Ergebnisse kontrollieren und bewerten sollen. Verschiedene Ansätze, wie die Qualität des Codes verbessert werden kann, wurden auf diesem Blog auch schon vorgestellt, zum Beispiel hier und hier.
Diese Arbeitsweise führt zu besseren Ergebnissen und ist eine gute Grundlage für das weitere Vorgehen. Für die Compliance reicht dieser Ansatz leider nicht, denn es gibt keine Nachweise über die genaue Arbeitsweise und es kann auch nicht sichergestellt werden, dass die Arbeit nach vorgegeben Maßstäben umgesetzt wurde. Dies führt zu einer Fragmentierung der Tool-Landschaft: Jeder Entwickler agiert als Insel mit eigener Konfiguration, das ist das Gegenteil von Compliance.
Gleichzeitig birgt dieser Ansatz Risiken, da das Unternehmen auch nicht die volle Kontrolle über eingesetzte LLMs und Anbieter hat, sodass Daten abfließen können.
Eine Verbesserung kann hier zukünftig die lokale Nutzung der GitLab CLI bringen, da diese die zentral definierten Security Constraints aus der Plattform beachtet.
Absicherung des SDLC in GitLab
In Teil I der Serie haben wir gesehen, wie wir das 4-Augen-Prinzip in GitLab durchsetzen können. Neuer Code landet in Feature Branches, die Pipeline führt Tests, Scans und Code-Analysen aus und der Merge Request stellt alle Informationen und Ergebnisse bereit, sodass ein Review und Freigabe erfolgen können.
Dieser Prozess funktioniert natürlich auch mit KI-generiertem Code und eignet sich gut, um ein „Human in the Loop“ sicherzustellen. Dabei übernehmen sowohl Committer, als auch Approver die Verantwortung für den Code. KI kann beim Schreiben des Codes unterstützen, aber die Verantwortung kann nicht an die KI abgegeben werden, sondern verbleibt beim Menschen. Die Prüfung erfolgt nach den gleichen Kriterien wie bei handgeschriebenem Code. Eine Grundlage für das Funktionieren dieses Ansatzes ist professionelles DevOps mit automatisierten, vollumfänglichen Pipelines, Rollout über mehrere Stages mit Canary Deployments und der Möglichkeit, auf Fehler zu reagieren und automatisiert zurückzurollen.
Eine Herausforderung bleibt trotz allem die Menge an Code die es zu überprüfen gibt, da die Erzeugung mit KI viel schneller geht als das manuelle Programmieren.
Duo Agent Platform
Der vorherige Teil dieser Serie hat gezeigt, dass die Duo Agent Platform direkt in GitLab integriert ist und wie sie die Ausführung von KI( Agenten) innerhalb von GitLab erlaubt.
Wie schon bei den Compliance-Anforderungen merkt man auch bei der Duo Agent Platform, dass GitLab auch größere Unternehmen adressiert. Governance und Security wurden von Anfang an mitgedacht und sind fest im System verankert. Folgende Kontrollmechanismen stehen bereit:
- KI-Features können für einzelne Gruppen oder Projekte freigeschaltet werden, für andere bleiben sie abgeschaltet. So lassen sich individuelle Anforderungen je nach Kritikalität abbilden.
- Jeder Agent hat einen eigenen Service Account, dem explizit Berechtigungen für Projekte gegeben werden können. So kann das bestehende Security-Modell von GitLab weitergenutzt und die Zugriffe exakt auf das benötigte Minimum beschränkt werden.
- Es kann klar geregelt werden, welche Agenten wo benutzt werden dürfen. Neue Agenten müssen erst freigegeben werden.
- Die verfügbaren Modelle werden zentral verwaltet.
- Tool-Aufrufe müssen von Menschen approved werden. Für die zentrale Steuerung dazu gibt es seit neuestem auch Agent Tool Governance Features.
- Es gibt ein vollumfängliches Auditlog, mit dem sich alle Aktionen von Agenten nachvollziehen lassen.
- Es lassen sich eigene Network Policies für AI Features konfigurieren.
- Verfügbare MCP Server lassen sich zentral verwalten und bereitstellen, um den Datenfluss zu kontrollieren und Schnittstellen sicher zu kapseln.
Eine weitere wichtige Anforderung für regulierte Unternehmen ist die Unabhängigkeit von einzelnen Cloud Providern. GitLab lässt sich selbst hosten und auch in dieser „Self Managed“-Variante sind die KI-Funktionen verfügbar. Über ein selbst gehostetes AI Gateway lassen sich eigene Modelle anbinden. Auch die Unterstützung für Open-Weight-Modelle wird immer besser.
Zusammenfassend lässt sich sagen: Die DAP transformiert GitLab zu einer zentralen Steuerungsinstanz für KI. Sie ermöglicht die Nutzung von KI, ohne die Kontrolle über Sicherheitsrichtlinien und Datenhoheit zu verlieren.
Organisatorische Anpassungen sind unvermeidbar
Die grundsätzliche Einführung von KI sollte begleitet werden, sodass die Anforderungen und Regeln allen Menschen im Unternehmen bekannt sind. Gleichzeitig muss ein Enablement stattfinden, um die Funktionen richtig zu nutzen.
Solange menschliche Reviews und Freigaben weiterhin erforderlich sind, verschiebt sich der Arbeitsaufwand massiv zum Review. Hier müssen die Mitarbeiter durch gezielte Weiterbildung befähigt werden, um die Ergebnisse der KI einschätzen zu können. Der Fokus liegt zukünftig auf der Bewertung des Codes, auf Architekturfragen und stärker als bisher auf den Produktanforderungen. Auch die Aufteilung von Arbeit innerhalb des Teams muss sich an die Review-Last anpassen.
Außerdem sollten Unternehmen ihren Angestellten die passenden Tools bereitstellen, um mit den neuen Anforderungen umgehen zu können. Bei der Bewertung der Änderungen ist es hilfreich, wenn Tests, Security Scans und automatisierte Review durch spezialisierte Agenten bereits gelaufen sind und die Ergebnisse zentral zur Verfügung stehen. Dafür sollte möglichst wenig manueller Aufwand nötig sein und Kontextwechsel/Tool-Brüche sind zu vermeiden.
Aber nicht nur die Softwareentwicklung ändert sich – auch Governance Prozesse müssen neu bewertet und an die aktuelle Situation angepasst werden. Dazu gibt es bereits einen eigenen Artikel hier auf dem Blog.
Ausblick
Die Tendenz geht zu immer mehr Autonomie für Agenten mit immer weniger Überprüfung des Codes. Es gibt Untersuchungen, die zeigen, dass menschliche Review keinen Vorteil mehr bringt, weil sie der Agentischen unterlegen ist.
Aus Compliance-Sicht spielt hier noch eine andere Perspektive eine Rolle: Neben dem Auffinden von Fehlern geht es auch darum, bewusste Manipulationen des Quellcodes und Angriffe zu verhindern.
Eine ähnliche Diskussion gab es beim Aufkommen von Hochsprachen, als Compiler die Übersetzung zu Assembler Code übernommen haben. Anfangs gab es noch Skepsis und die Ergebnisse wurden manuell kontrolliert, heute findet eine solche Prüfung so gut wie nie statt. In Zukunft prüfen wir also vielleicht nicht mehr den Code, der „herauskommt“, sondern nur noch die Anforderungen, die „hineingehen“ und die Leitplanken, die den Agenten lenken. Damit wird das Review auf eine ganz andere, viel abstraktere Ebene gehoben. Der Fokus wandert auch in diesem Fall viel mehr auf die Domäne und das Produkt, aber auch die klare Beschreibung von Sicherheitsrichtlinien.
Fazit
Aktuell gibt es sehr schnelle Fortschritte in der KI-gestützten Softwareentwicklung. Die Anforderungen von Compliance und Regulatorik bleiben grundsätzlich bestehen, müssen sich aber auch an aktuelle Entwicklungen anpassen und dürfen dabei nicht hinter den technischen Fortschritten hinterherhinken. Die genauen Veränderungen und Themen sind sehr schwierig im Detail vorherzusagen.
Aktuell ist die Freigabe des Codes durch Menschen noch eine grundlegende Anforderung, denn ein Mensch muss die Verantwortung übernehmen. GitLab bietet eine gute Grundlage, um KI-gestützte Softwareentwicklung durch Governance abzusichern. Die Grundlagen bilden der Merge Request zentrierte SDLC und die bestehenden Security-, Compliance- und Auditfunktionen der integrierten Plattform. Somit bietet sich hier auch im KI-Umfeld die Chance auf eine Konsolidierung der Tool-Landschaft.
Damit sind wir auch am Ende dieser Serie angekommen. Wir sind vom klassischen GitLab-Setup gestartet, haben moderne Kollaboration integriert und sind bei einer KI-gestützten Zukunft gelandet, in der Compliance kein Hindernis, sondern direkt integriert ist.
Hier noch einmal die ganze Serie im Überblick:
War dieser Beitrag hilfreich?
Weitere Artikel in diesem Themenbereich
Entdecke spannende weiterführende Themen und lass dich von der codecentric Welt inspirieren.
22.6.2026
Blog-Autor*in
Erik Petzold
Professional Services Engineer | Consultant | Developer
Du hast noch Fragen zu diesem Thema? Dann sprich mich einfach an.
Du hast noch Fragen zu diesem Thema? Dann sprich mich einfach an.