Der Aufstieg agentischer Entwicklungstools, die KI-Agenten die Vorbereitung von Codeänderungen anvertrauen, wirft die Frage nach der Auditierbarkeit von Workflows auf. In regulierten Branchen reicht es nicht mehr zu wissen, wer eine Änderung genehmigt hat: Man muss den Kontext, die Kontrollen und die Entscheidungen, die sie hervorgebracht haben, nachvollziehen können.
In einer großen Finanzinstitution, die einen Agenten in ihrem Entwicklungs-Workflow einsetzt, stellte sich das interne Audit- und Compliance-Team eine präzise Frage. Für eine Merge Request (eine Anfrage zur Code-Zusammenführung), die von einem Agenten eröffnet wurde, um eine Abhängigkeit eines Zahlungsdienstes zu aktualisieren: Konnte man angeben, wer sie genehmigt hatte, welche Eingabedaten und Prompts der Agent verwendet hatte, welche Richtlinienkontrollen bewertet wurden und wie diese Aufgabe reproduziert oder rückgängig gemacht werden konnte? Das Team hatte keine Antwort. Das Lieferungssystem betrachtete die Arbeit des Agenten nicht als eine abgegrenzte und auditierbare Transaktion.
Ein von der CI (Continuous Integration, die Code automatisch testet) validierter und genehmigter Diff beweist, dass eine Änderung stattgefunden hat. Er beweist jedoch nicht den vom Agenten verwendeten Kontext, die vor der Erstellung der Merge Request bewerteten Richtlinienentscheidungen oder die Möglichkeit, das Ergebnis bei einer späteren Ausführung zu reproduzieren. In regulierten Umgebungen sind das « Wie » und « Warum » jedoch essenziell. Diese Situation findet sich auf allen Plattformen und in DevSecOps-Organisationen: Das Budget für agentische Tools wird innerhalb weniger Wochen genehmigt, während das für Ausführungsaufzeichnungen, Identitätsverknüpfung und Replay-Tools nie auftaucht oder lediglich als reine Compliance-Kosten behandelt wird.
Vier wiederkehrende Ausnahmen
Sobald Agenten Merge Requests in einer regulierten CI/CD-Umgebung eröffnen, treten vier Arten von Compliance-Ausnahmen auf. Die erste ist die fehlende Herkunft: Niemand kann sagen, welche Daten der Agent verwendet hat, ob Spezifikationen, abgerufener Kontext, Tool-Aufrufe oder der Zustand des Repositories. Die zweite ist die unsichere Identitätszuweisung, da der Agent unter einem gemeinsamen Service-Token handelte, ohne einen verantwortlichen menschlichen Ansprechpartner. Die dritte ist eine nicht rekonstruierbare Entscheidungskette, da die Argumentation nur flüchtig erfasst wurde. Die vierte ist das nicht abgegrenzte Zurücksetzen: Da die Änderungen des Agenten gekoppelt sind, wird jede Rücknahme zu manueller Arbeit über Commits und Repositories hinweg.
Die nachträgliche Rekonstruktion besteht darin, Konversations-Logs, partielle CI-Ausgaben und noch verfügbare Agenten-Traces zu untersuchen. In den meisten Organisationen erfasst niemand die wöchentlich für diese Aufgabe aufgewendeten Stunden, weshalb ihre Kosten unsichtbar bleiben. Die Quelle schlägt einen einfachen Test vor: Ist ein Team in der Lage, innerhalb einer Stunde einen Beweisdatensatz zu erstellen, der die Aufgabenspezifikationen, den Repository-Zustand, die bewerteten Kontrollen und den für die Aktion verantwortlichen Menschen zusammenfasst?
« Zuerst liefern » und seine Grenzen
Die Strategie « Zuerst liefern, später regieren » kann funktionieren, wenn Agenten auf enge Bereiche beschränkt sind, wie die Generierung von Tests, kleine Refactorings oder die Aktualisierung von Dokumentation, mit einer robusten menschlichen Überprüfung. Sie bricht jedoch, wenn Teams sich davon befreien, Prompt-Bibliotheken mit inkonsistenter Protokollierung sich vervielfachen und gemeinsame Tokens die Zuordnung auf Portfolio-Ebene unmöglich machen. Der Artikel zitiert auch den Fall eines großen Unternehmens, das eine Workflow-Basisplattform aufbauen wollte, bevor es Agenten verallgemeinerte: Das Plattformprojekt zog sich über mehrere Quartale hin, und die Teams umgingen es schließlich.
Der Artikel betont, dass « der Wettbewerbsdruck Geschwindigkeit belohnt, während Regulierungsbehörden die Rekonstruktionsfähigkeit belohnen ». Er beschreibt die Kosten dieser Kluft: Fehlende Beweise, die bei einer Kontrolle entdeckt werden, wochenlange Nachbesserungen und ein Wirkungsradius, der sich mit jeder schlecht aufgezeichneten Agentenaktion erweitert. In diesem Zusammenhang wird Crédit Agricole CIB zitiert, das laut Text eine Lieferung pilotiert, die Tausende von Entwicklern in Dutzenden von Ländern auf einer einzigen DevSecOps-Plattform vereint – eine Voraussetzung, um agentische Arbeit zu auditieren.
Arbeit benennen und messen
Die Quelle empfiehlt, diese Aufgabe wie ein eigenständiges Produkt zu behandeln, genannt « Aufgezeichnete Ausführung für agentisches CI/CD », mit Ressourcen, die Plattform-Engineering, Sicherheit, Audit und Developer Experience vereinen. Seine Liefergegenstände umfassen ein Aufzeichnungsschema, das Eingabedaten, Ausgaben, Tool-Aufrufe und Modellversion erfasst, eine Identitätsverknüpfung, die jede Aktion einem menschlich Verantwortlichen zuordnet, Logs von Richtlinienentscheiden sowie Mechanismen für Replay und Rückgängigmachen. Das Tracking kann sich auf die Tiefe der Ausnahmen-Warteschlange, die mediane Zeit zur Beschaffung von Beweisen, die Erfolgsquote von Replays und die Wiedereröffnungsrate von Ausnahmen stützen.
Wenn nur ein Schritt unternommen werden muss, rät der Text, mit den risikoreichsten Fällen zu beginnen, wie Abhängigkeitsänderungen, Infrastructure-as-Code-Modifikationen und Sicherheitskonfigurationen. Der letzte vorgeschlagene Test besteht darin, ein Team aufzufordern, eine von einem Agenten verfasste, zusammengeführte Änderung sauber rückgängig zu machen, wobei es sich ausschließlich auf aufgezeichnete Artefakte stützt.
