KI-Agenten im Projektteam: Warum sie eine Rolle brauchen, keinen Blankoscheck

Montagmorgen, 8:14 Uhr: Das Kanban-Board hat über Nacht fünf neue Kommentare bekommen – vier davon von einem KI-Agenten, der eigenständig zwei Tickets umpriorisiert und eines als „erledigt" markiert hat. Niemand im Team hat das angestoßen. Der Agent durfte es einfach, weil ihm vor einigen Wochen jemand Schreibrechte im Board eingerichtet hat – und seitdem hat niemand mehr darüber nachgedacht. Genau an diesem Punkt stehen aktuell viele Projektteams: KI-Agenten übernehmen operative Aufgaben, bevor irgendjemand entschieden hat, welche Rolle sie im Team eigentlich spielen.

Vom Werkzeug zur Mitarbeiterin ohne Arbeitsvertrag

Solange KI nur auf Zuruf antwortete – ein Prompt, eine Antwort, fertig –, war die Frage nach ihrer Rolle im Team einfach: Werkzeug, Punkt. Agentische Systeme verschieben das. Sie beobachten ein Board, lesen Postfächer, reagieren auf Ereignisse und handeln mehrstufig, ohne dass für jeden einzelnen Schritt ein Mensch den Auslöser betätigt. Damit tauchen sie faktisch in den Abläufen auf, die ein Projekt sonst über Rollen und Zuständigkeiten regelt – nur eben ohne dort offiziell eingetragen zu sein. In der Beratungsliteratur zu Agentic AI wird inzwischen offen diskutiert, dass solche Agenten einen Platz in der RACI-Matrix eines Projekts brauchen (der Rollenübersicht, die festlegt, wer wofür verantwortlich, zuständig, zu konsultieren oder zu informieren ist), statt nur eine Zeile im Tool-Verzeichnis zu sein. Für Projektverantwortliche heißt das: Wer einem Agenten Zugriff auf ein System gibt, vergibt damit implizit eine Rolle – ob das so gewollt war oder nicht.

Drei Grade der Aufsicht

In der Diskussion um verantwortungsvollen Einsatz von KI-Agenten hat sich eine Dreiteilung etabliert, die sich gut auf Projektarbeit übertragen lässt: Human-in-the-loop, Human-on-the-loop und Human-out-of-the-loop. Sie beschreiben, wie eng ein Mensch noch in die Entscheidung eines Agenten eingebunden ist – nicht, wie "gut" oder "schlecht" eine Stufe ist, sondern wofür sie passt.

Eine kleine Einordnung hilft, die drei Stufen im Projektalltag auseinanderzuhalten:

Schematische Darstellung, keine Messdaten – Einordnung in Anlehnung an gängige Human-in-the-Loop-Terminologie der KI-Governance-Diskussion.

Die meisten Projekte landen in der Praxis bei Human-on-the-loop: Der Agent arbeitet, jemand schaut regelmäßig aufs Dashboard. Das eigentliche Problem ist seltener die Wahl der Stufe als die Tatsache, dass sie nie bewusst getroffen wurde – der Agent ist einfach „irgendwo zwischen" allen drei Stufen gelandet, je nachdem, was technisch am wenigsten Einrichtungsaufwand gemacht hat.

Verantwortlich ist nicht dasselbe wie zuständig

Der wichtigste Punkt, den viele RACI-Überlegungen zu KI-Agenten übersehen: Ein Agent kann durchaus als „Responsible" eingetragen werden – er führt die Aufgabe aus. Er darf aber nie „Accountable" sein. Diese Rolle verlangt, am Ende für ein Ergebnis geradezustehen, Rückfragen zu beantworten und im Zweifel eine Entscheidung zu revidieren. Das kann ein System nicht leisten, selbst wenn es technisch „entscheidet". Wer Responsible und Accountable hier verwechselt, hat im Ernstfall ein Protokoll – aber keine Person, die dafür geradesteht.

Ein paar Faustregeln, die sich in der Praxis bewähren:

• Jeder Agent mit Schreibzugriff auf ein Projektsystem braucht einen eingetragenen menschlichen Accountable – eine namentlich benannte Person, keine Teamadresse.
• Die Aufsichtsstufe wird einmal bewusst festgelegt und begründet dokumentiert, nicht implizit über technische Freigabe-Einstellungen vererbt.
• Je irreversibler eine mögliche Aktion, desto näher muss die Aufsicht an Human-in-the-loop liegen – unabhängig davon, wie gut der Agent in Tests abgeschnitten hat.
• Stichprobenkontrollen bei Human-on-the-loop-Aufgaben werden terminiert, nicht „bei Gelegenheit" gemacht – sonst verwässern sie unbemerkt zu Human-out-of-the-loop durch Unterlassung.

Wer schließt das Ticket?

Eine IT-Abteilung eines Krankenhauses testet einen KI-Agenten, der eingehende Störungstickets kategorisiert und einfache Fälle – ein vergessenes Passwort, ein blockierter Drucker – direkt schließt, ohne auf einen Menschen zu warten.

Vorher: Niemand hatte dem Agenten eine Rolle zugewiesen, nur einen Zugang. Technisch durfte er jedes Ticket schließen, auch solche, die eigentlich eine Fachabteilung betrafen – etwa eine Störung an einem Diagnosegerät, die fälschlich als „IT-Routinefall" einsortiert und ungeprüft geschlossen wurde. Aufgefallen ist das erst, als sich jemand auf der Station wunderte, warum niemand zurückgerufen hatte.

Die IT-Leitung zog danach eine klare Linie: Der Agent bleibt Responsible für Kategorisierung und für das Schließen einer eng definierten Liste risikoarmer Standardfälle. Für alles, was medizinische Geräte, Patientendaten oder mehr als eine Abteilung betrifft, bleibt er auf Human-in-the-loop-Stufe – er schlägt vor, ein Mensch bestätigt. Ein namentlich benannter Teamleiter trägt die Accountable-Rolle und wird bei jeder Eskalation informiert, nicht erst bei einer Beschwerde.

Nachher: Falsch geschlossene Tickets wurden sichtbar seltener, die Reaktionszeit bei den echten Routinefällen blieb trotzdem schnell. „Der Agent ist seitdem nicht langsamer geworden", sagt die IT-Leitung dazu, „er hat nur gelernt, wann er langsam sein muss."

Auf den Punkt

KI-Agenten brauchen im Projekt eine bewusst zugewiesene Rolle, nicht nur einen Zugang. Die Aufsichtsstufe – in, on oder out of the loop – sollte pro Aufgabenart begründet entschieden werden, nicht einfach technisch mitlaufen. Und egal wie autonom ein Agent arbeitet: Die Accountable-Rolle bleibt bei einem Menschen mit Namen, nie bei einem System. Wer das von Anfang an klärt, muss es nicht erst nach dem ersten unangenehmen Ticket nachträglich tun.