Agentic AI im Softwareprojektmanagement

Die Governance-Lücke, über die kaum jemand spricht

Agentic AI hält Einzug in die Softwareentwicklung – und das in einem Tempo, das die wenigsten Entwicklungsteams einplanen konnten. Gartner geht davon aus, dass bis Ende 2026 bereits 40 % der Enterprise-Software aufgabenspezifische KI-Agenten einsetzen wird. Bis 2028 sollen autonome Agenten bis zu 15 % der täglichen Entscheidungen in Unternehmen eigenständig treffen. Die Werkzeuge sind da – die nötigen Kontrollmechanismen noch nicht.

Genau in dieser Lücke liegt das eigentliche Risiko.

In den meisten Fachdebatten steht bislang die Produktivitätsfrage im Vordergrund: schnellere Code-Generierung, automatisierte Aufgabenpriorisierung, Agenten, die Iterationen planen, Abhängigkeiten identifizieren und Architekturvorschläge in Minuten ausarbeiten. Beides stimmt. Doch diese Vorteile erzeugen dabei Fehlertypen, die sich grundlegend von klassischer Automatisierung unterscheiden – und auf die die meisten Delivery-Teams heute nicht vorbereitet sind.

McKinsey-Daten verdeutlichen das Ausmaß: 80 % der Unternehmen haben bereits unkontrolliertes oder schadhaftes Verhalten von KI-Agenten festgestellt. Gleichzeitig experimentieren zwar 62 % der Unternehmen mit KI-Agenten – doch zwei Drittel davon haben noch keinen nennenswerten Rollout begonnen. Wer am meisten ausprobiert, häuft damit auch das meiste unkontrollierte Risiko an.

Dieser Artikel plädiert nicht gegen Agentic AI in der Softwareentwicklung – sondern dafür, die Governance-Schicht aufzubauen, bevor die ersten ernsthaften Probleme auftauchen.

Kein schnellerer Entwickler – eine andere Kategorie

Viele Projektverantwortliche behandeln Agentic AI als bloßen Beschleuniger bestehender Abläufe – als Entwickler, der schneller coden kann, oder als Projektmanagement-Assistent, der Statusberichte in Sekunden schreibt. Damit übersehen sie, was Agentic AI von früheren Systemen grundlegend unterscheidet.

Klassische Automatisierung folgt festen Regeln: Ein Deployment-Skript arbeitet eine festgelegte Schrittfolge ab. Ein Workflow-Tool leitet ein Ticket nach festgelegter Logik weiter. Beide Systeme sind deterministisch: Gleiche Eingabe, gleiche Ausgabe. Sie lassen sich testen, nachvollziehen und zuverlässig einschätzen.

Agentic AI arbeitet anders: auf Basis von Zielen. Ein Agent erhält eine Aufgabe auf hohem Abstraktionsniveau – etwa „löse dieses Problem”, „refaktoriere dieses Modul” oder „identifiziere Blocker im aktuellen Sprint” – und plant dann eigenständig, welche Schritte er unternimmt, welche Werkzeuge er einsetzt und wie er auf das Unerwartete reagiert. Statt ein Skript abzuarbeiten, schlussfolgert er sich zu einem Ziel vor.

Das ist die Quelle seiner Stärke. Und zugleich der Grund, warum er sich mit den Governance-Annahmen, die im klassischen Projektmanagement gelten, nicht einfach verwalten lässt.

McKinsey-Partner Rich Isenberg bringt es auf den Punkt: „Agency isn’t a feature – it’s a transfer of decision rights.” Diese Verschiebung hat unmittelbare Konsequenzen für Planung, Steuerung und Verantwortung in Softwareprojekten.

Drei Fehlermuster, die klassische PM-Frameworks überfordern

1. Nicht-Determinismus im Großmaßstab

Weil ein Agent seine eigenen Handlungsschritte plant, kann dieselbe Anweisung bei verschiedenen Ausführungen zu unterschiedlichen Ergebnissen führen. Bei einer klar begrenzten Aufgabe ist das beherrschbar. In einer großen Enterprise-Codebasis mit querschnittlichen Abhängigkeiten und mehreren parallelen Features wird daraus ein kaum beherrschbares Stabilitätsproblem.

Praxiserfahrungen zeigen: Ohne eine deterministische Workflow-Engine, die Phasenübergänge durchsetzt, überspringen Agenten regelmäßig Schritte, erzeugen zirkuläre Abhängigkeiten oder verlieren sich in Analyse-Schleifen. Innerhalb eines klar umrissenen Problems leisten Agenten gute Arbeit. Bei Meta-Entscheidungen über Reihenfolgen, Abhängigkeiten und organisatorischen Kontext – dem impliziten Wissen erfahrener Projektleiter – stoßen sie schnell an Grenzen.

Dieser Nicht-Determinismus ist kein Fehler, den man mit einem Update beseitigen kann. Er steckt im Prinzip selbst: Systeme, die auf Ziele hinarbeiten, folgen eben keiner festen Logik. Klassische PM-Werkzeuge – Gantt-Charts, Velocity-Tracking, Abnahmekriterien – setzen voraus, dass Ergebnisse bis zu einem gewissen Grad vorhersehbar sind. Agentic-Systeme erfüllen diese Bedingung grundsätzlich nicht.

2. Fehlende Audit-Trails

In regulierten Branchen – Banken, Versicherungen, Pharma, öffentliche Verwaltung – ist die lückenlose Nachvollziehbarkeit von Entscheidungen keine Option. Lückenlose Protokolle bilden die Basis für Compliance, Fehleranalyse und vertragliche Haftung – doch sobald Agenten Zwischenentscheidungen eigenständig treffen, klafft genau hier eine Lücke.

KI-Agenten legen ihren Entscheidungsweg kaum offen – oft nicht einmal für die Teams, die sie entwickelt haben. Wenn ein Entwickler eine wesentliche Änderung an der Architektur vornimmt, dokumentiert er das in der Regel – im Commit-Kommentar, in der PR-Review oder im Ticketsystem. Führt ein Agent dieselbe Maßnahme im Rahmen eines autonomen Workflows aus, fehlt häufig die Erklärung, warum diese Maßnahme gewählt wurde.

Die Regulierung holt derweil auf. Die neue EU-Produkthaftungsrichtlinie, die bis Dezember 2026 in nationales Recht umzusetzen ist, umfasst ausdrücklich Software und KI als Produkte – und eröffnet damit eine verschuldensunabhängige Haftung, wenn ein KI-System als fehlerhaft eingestuft wird. Im Januar 2026 veröffentlichte die Infocomm Media Development Authority (IMDA) Singapurs einen Entwurf für ein Governance-Framework speziell für Agentic AI, nachdem das Weltwirtschaftsforum im November 2025 ein vergleichbares Dokument vorgelegt hatte. Beide Frameworks erkennen ausdrücklich an, dass bestehende KI-Governance-Strukturen die spezifischen Risiken agentischer Systeme nicht abdecken.

Wer in einer regulierten Branche Agentenentscheidungen nicht strukturiert protokolliert und prüft, trägt heute bereits ein konkretes Haftungsrisiko – das ist kein Problem, das man auf später verschieben kann.

3. Verschwimmende Verantwortlichkeit

Macht ein menschlicher Entwickler einen Fehler, lässt sich die Verantwortung in der Regel nachvollziehen. Wenn ein Agent einen Fehler macht – und Agenten machen Fehler, die umso häufiger auftreten, je mehr Agenten im Einsatz sind – wird die Frage der Verantwortung erheblich komplexer.

Trifft den Entwickler die Schuld, der den Agenten beauftragt hat? Den Projektleiter, der das Ergebnis abnahm, ohne die Zwischenschritte zu prüfen? Den Modellanbieter, dessen System den fehlerhaften Output lieferte? Oder das Unternehmen, das den Agenten ohne ausreichende Leitplanken freigegeben hat?

Ein Fehler in einem Agenten kann sich durch nachgelagerte Systeme fortpflanzen und den Schaden erheblich vergrößern. Hinzu kommt das Lieferkettenrisiko: Viele Agentic-Deployments stützen sich auf mehrschichtige Ökosysteme aus Modellanbieter, Tooling-Vendoren und Integrationspartnern. Ein Modell-Update beim Anbieter kann das Verhalten des Agenten verändern – ohne jede direkte Anpassung durch das Unternehmen selbst.

Klassische RACI-Matrizen, Eskalationspfade und vertragliche Haftungsklauseln in Projektmanagement-Frameworks wurden für diese Situation nicht entworfen. Sie müssen angepasst werden.

Was gute Governance konkret bedeutet

Die Antwort liegt nicht im Verzicht auf Agentic AI – sondern im Aufbau einer Aufsichtsschicht, die dem Autonomiegrad der eingesetzten Agenten gerecht wird. Aus frühen Enterprise-Implementierungen und regulatorischen Leitlinien zeichnen sich dabei einige zentrale Prinzipien ab.

Autonomie vor dem Einsatz begrenzen. Bevor ein Agent in eine Delivery-Pipeline integriert wird, sollte sein Aktionsraum explizit definiert sein: Auf welche Systeme kann er zugreifen? Welche Entscheidungen darf er eigenständig treffen? Welche Aktionen sind irreversibel? Das Governance-Framework von Singapurs IMDA benennt dies direkt: Risiken vor der Inbetriebnahme einschätzen und den Aktionsraum des Agenten entsprechend einschränken. Ein Agent, der die Codebasis lesen darf, braucht keinen Schreibzugriff auf die Produktionsinfrastruktur.

Governance als Schutzschalter, nicht als Kontrollpunkt. Das klassische PM-Modell behandelt Governance als Phasentor – eine Überprüfung am Ende eines Sprints oder Meilensteins. Mit Agenten, die kontinuierlich und asynchron agieren, greift dieses Modell nicht mehr. Governance muss in die Pipeline eingebettet sein: erzwungene Phasenübergänge, Zustandsmaschinen für Artefakte, Eskalations-Trigger, wenn Agenten auf Unklarheiten oder Grenzfälle stoßen. Treffend formuliert: „Governance ist kein Kontrollpunkt mehr – sie ist ein Schutzschalter, der direkt in die Pipeline integriert ist.”

Jede Annahme eines Agenten protokollieren. Ein Muster, das sich in der Praxis bewährt hat, ist ein dedizierter Wissensagent, der jede Frage eines autonomen Agenten erfasst, die aus dem Kontext heraus nicht beantwortet werden kann – zusammen mit der Annahme, die der Agent daraufhin trifft, um fortzufahren. Weil diese Interaktionen über strukturierte Tool-Aufrufe laufen, entsteht dadurch ein auswertbarer Audit-Trail. Keine vollständige Lösung – aber ein Ansatz, der in der Praxis greift.

Freigaben nach Reversibilität staffeln. Nicht alle Agentenentscheidungen tragen dasselbe Risiko. Einen Anforderungsentwurf zu erstellen ist risikoarm und leicht korrigierbar. Einen Branch in den Main zu mergen, ein Datenbankschema zu ändern oder eine nachgelagerte Integration anzustoßen ist es nicht. Ein gestaffeltes Freigabemodell – bei dem der Schwellenwert für menschliche Überprüfung mit der Irreversibilität und dem Schadenspotenzial einer Aktion steigt – erlaubt es Teams, die Effizienzgewinne von Agenten bei risikoarmen Aufgaben zu nutzen und gleichzeitig dort echte Kontrolle zu behalten, wo es darauf ankommt.

Inventarisieren, was läuft. Wer Governance für Agentic AI betreiben will, muss zunächst wissen, was im Einsatz ist. Agenten, die nicht inventarisiert und nicht identitätsgebunden sind, skalieren nicht – sie multiplizieren blinde Flecken im Risikobild. Ein Agent-Register mit dokumentierter Eigentümerschaft, definiertem Aktionsraum und Monitoring-Anbindung ist die Grundbedingung für jedes funktionsfähige Governance-Konzept.

Der richtige Einstieg

Die Lücke zwischen dem Einsatz von Agentic AI und der tatsächlichen Bereitschaft dafür ist real – aber schließbar. Den größten Nutzen ziehen erfahrungsgemäß nicht die, die am schnellsten ausrollen, sondern die, die am sorgfältigsten vorgehen.

Ein sinnvoller Ausgangspunkt ist ein AI Readiness Health Check für die bestehende Delivery-Pipeline: Wo werden Agenten bereits eingesetzt oder pilotiert? Wie ist die Audit-Trail-Abdeckung? Welche Verantwortlichkeitsstrukturen existieren – und wo klaffen die größten Lücken, bevor ein ernsthafter Zwischenfall eintritt?

itestra begleitet seit über 20 Jahren Unternehmen an der Schnittstelle von Softwareentwicklung und technologischem Wandel – mit Erfahrung aus mehr als 90 Enterprise-Projekten. Diese Erfahrung zeigt: Die Fehlermuster von Agentic AI sind keine theoretischen Szenarien. Sie tauchen bereits in laufenden Projekten auf – als unerklärliche Regressionen, übersehene Compliance-Anforderungen oder Verantwortlichkeitskonflikte, für die klassische PM-Prozesse schlicht nicht ausgelegt sind.

Die Argumente für Agentic AI sind überzeugend – die für eine belastbare Governance-Schicht mindestens ebenso. Beides lässt sich verbinden, aber nur, wenn Governance von Anfang an als Gestaltungsaufgabe begriffen wird und nicht als nachträgliche Absicherung.