KI-Governance-Betriebsmodell: fünf Bausteine im laufenden Betrieb

Was unser KI-Governance-Betriebsmodell leistet

Ein KI-Governance-Betriebsmodell ist ein System aus Entscheidungsrechten, Ownern, Eskalation, Workflow-Gates und Reviews, das festlegt, was KI-Agenten allein erledigen und was auf einen Menschen wartet. Unseres steuert Agenten, die handeln: Diese sichten Anfragen, schreiben Code, entwerfen Guides und teilen anderen Agenten Arbeit zu. Es ist keine Chatbot-Richtlinie für Mitarbeitende und keine Liste freigegebener Tools.

Governance für Agenten ist kein Gremium. Sie besteht aus fünf Dingen, die dort stehen, wo der Agent sie liest, bevor er handelt, und jedes davon ist ein Artefakt, das Sie öffnen können:

Alle fünf betreiben wir auf ConvOps(wird in einem neuen Tab geöffnet), wo die Tasks, Owner, Gates, Notizen und Zeitpläne liegen. Dieser Guide gehört zur Reihe „Loops We Run“; der Leitartikel zeigt, wer im ganzen Unternehmen was entscheidet.

Die Beispiele nutzen Copperfern, einen fiktiven Onlineshop für Wohnaccessoires, und Maya, die dort den Betrieb leitet. Namen und Zahlen sind erfunden; Feldnamen, Notizformate, Regeln und Schwellenwerte sind echt.

Fünf Bausteine, fünf Artefakte: Entscheidungsrechte sind eine Ausschlussliste, der Owner ist ein Name am Task, Eskalation ist eine typisierte Notiz, ein Gate ist eine Freigabe im Workflow, das Review ist ein Zeitplan.

Warum die Regeln im Workflow stehen

Ein Richtliniendokument steuert Menschen, die es lesen. Ein Agent befolgt nur, was in seinem Workflow steht, also muss jede Regel genau dort stehen.

Unsere Agenten haben angefangen, echte Arbeit zu erledigen: Routing, Entwicklung, Veröffentlichung, Zuteilung. Die Regeln standen in einem Chatverlauf und im Kopf einer einzigen Person. Ein Agent mitten in einem Lauf liest keine Richtlinienseite noch einmal. Wenn ein Job aus dem Ruder lief, konnte niemand sagen, welcher Agent die Entscheidung getroffen hatte, mit welcher Begründung oder wo er hätte anhalten müssen.

Also haben wir jede Regel an die Stelle verschoben, an der der Agent handelt. Die Liste dessen, was ein Agent nie übernehmen darf, steht jetzt in dem Schritt, der die Arbeit auswählt. Jede Freigabe wurde zu einem Gate, das der Lauf ohne ein Ja nicht passieren kann. Jede Agentenentscheidung hinterlässt jetzt eine einzeilige Begründung am Task. Governance ist eine Etappe auf dem größeren Weg zum KI-Betriebsmodell.

Sehen Sie, wie ConvOps das Freigabe-Gate in den Workflow legt statt in eine Richtliniendatei(wird in einem neuen Tab geöffnet).

So läuft es

Die Arbeit zwischen den Gates läuft ohne uns. An den Gates setzen wir unsere Aufmerksamkeit ein, und nirgendwo sonst.

Jede Regel hat einen Grund. Ohne das Ja des Operators macht der Triage-Agent nie etwas zur Initiative und stuft nie eine Initiative um, denn über den Umfang entscheidet ein Mensch. Ein Dispatch-Batch umfasst 1 bis 10 Tasks, standardmäßig 5, weil bei einem kleinen Batch jedes Review gründlich bleibt. Der Kandidatenpool wird mit dem Dreifachen dieses Maximums abgefragt, damit nach den Ausschlüssen noch eine volle Liste übrig bleibt.

Ein Agent hält nur bei echten Ermessensfragen an und fragt nach: Produktionszugriff oder Produktionsdaten, Secret-Werte oder die Rotation von Zugangsdaten, Ausgaben, Veröffentlichungen, Änderungen am Umfang und die Wahl zwischen Fix-Optionen. Alles andere entscheidet er selbst und schreibt die Begründung auf. Wenn der Operator für einen Lauf Autonomie gewährt, entscheidet der Orchestrator als sein Delegierter, nur für diesen Lauf, und die Notizen halten das fest.

Die Reviews folgen einem festen Zeitplan, nicht dem Gedächtnis. Bei Copperfern: „Search check“ (Suchprüfung) täglich um 05:00 UTC, „Product photo ideas“ (Produktfoto-Ideen) täglich um 06:00, „Social post“ (Social-Media-Beitrag) täglich um 16:00, „Weekly planning“ (Wochenplanung) jeden Montag um 06:00 und „Monthly research“ (Monatsrecherche) am 2. jedes Monats um 07:00.

Triage, Routing, Entwürfe und Review-Durchgänge laufen allein; Anforderungen, Merge, Veröffentlichung und die Kandidatenliste warten auf einen Menschen; Produktionsdaten, Secrets, Ausgaben und Prüfungen auf der Live-Website werden nie an einen Agenten übergeben.

Veröffentlichungen warten auf einen Menschen, außer ein Mensch hat für diesen Job bereits anders entschieden. Routine-Inhalte wie News und Übersetzungen gehen nach dem Review durch einen separaten Agenten live, weil jemand diese Spalte für den Job gewählt hat, bevor er je lief (welche Jobs auf ein Ja warten).

Manche Regeln brauchen gar kein Gate, weil ein Hook die Aktion direkt blockiert: siehe wie wir Claude Code am Löschen von Dateien hindern. Gates sind für Entscheidungen da, die einen Menschen brauchen, und genau das ist der Kern von Human-in-the-Loop-KI-Systemen.

Ein Owner pro Job, kein RACI

Ein RACI verteilt einen Job auf vier Rollen. Für einen Agenten-Job halten wir zwei Namen fest: den Owner, der die Arbeit erledigt, eingetragen als der eine Executor am Task, und den Menschen, der am Gate freigibt. Ein abgelehnter Job bleibt abgelehnt: Wir versuchen ihn nie mit einem anderen Executor erneut, und wir teilen ihn nie erneut zu, solange ein früherer Lauf noch aktiv sein könnte. Wer einen Job herumreicht, verschleiert, warum er abgelehnt wurde. Jeder Agent hat außerdem eine Zeile in unserem KI-Agenten-Inventar, in der die Owner-Spalte neben dem Ausschalter steht, der ihn stoppt.

Ein Lauf Schritt für Schritt: eine Änderung, zweimal Ja

Das Wertvolle an einer gesteuerten Änderung ist nicht der Code. Es sind die zwei Momente, in denen ein Mensch Ja sagt, und die eine Zeile Begründung, die der Agent hinterlässt.

Maya wünscht sich „eine Geschenkverpackung im Checkout“. So läuft diese Anfrage vom Auslöser bis zum Ergebnis:

Das Einfrieren in Schritt 5 ist strikt. Spätere Schritte fügen nie eine Anforderung hinzu, streichen keine und deuten keine um. Eine Änderung am Umfang geht zurück zum Anforderungsschritt und braucht eine neue Freigabe, sodass sich die Spielregeln nach dem Ja nie mehr ändern.

Die rote Prüfung in Schritt 7 erreicht Maya nie als Frage. Der Fix-Workflow läuft, und das Ergebnis wird auf der neuen Pipeline erneut geprüft. Ein Agent gibt nie seinen eigenen Fix frei, und eine rote Pipeline blockiert das Merge-Gate.

In Schritt 9 braucht der Merge sowohl eine grüne Pipeline als auch eine ausdrückliche Freigabe. Die Freigabe kommt von Maya oder aus ihrer schriftlichen Delegation, wenn sie für diesen Lauf Autonomie gewährt hat. Ohne sie bleibt der Task blockiert am Gate stehen, und das Board zeigt, dass er auf einen Menschen wartet. Die Abnahmeergebnisse, die sie liest, stammen aus einem Browser-Testlauf, beschrieben in unserem Guide zu Abnahmetests.

Der Task behält die Routing-Begründung, beide bestandenen Gates und die CI-Historie.

Eine Änderung, zweimal Ja: Der Agent routet den Geschenkverpackungs-Task, Maya gibt die eingefrorenen Anforderungen frei, eine rote Prüfung läuft durch einen Fix, dann geben Maya oder ihre schriftliche Delegation den Merge frei.

Die Ausschlussliste und das Job-Protokoll

Schreiben Sie die Liste dessen, was ein Agent nie übernehmen darf, vor der Liste dessen, was er tun darf. In der Ausschlussliste steckt die eigentliche Governance.

Die Dispatch-Liste

Ein Dispatch-Lauf beginnt mit einer einzigen Kriterienzeile:

criteria: horizon=now; complexity=S; executor=coding-agent; max=5; project=shop; type=task,bug

Der Agent erstellt dann zwei Tabellen. Behaltene Tasks tragen den Grund, warum jeder passt. Ausgeschlossene Tasks tragen die Regel, die sie ausgeschlossen hat. Ein Task wird ausgeschlossen, wenn:

• bereits ein aktiver oder zugeteilter Lauf für ihn existiert
• er auf ein Operator-Gate wartet
• er den Operator oder Live-Zugriff auf die Produktion braucht
• er mit manual-qa, production-release, mr-review oder ui-review getaggt ist
• er kein konkretes Abschlusskriterium hat
• er blockiert ist oder das Kind eines blockierten Tasks
• der Executor nicht erreicht, was er braucht

Bei Copperfern fällt „Rotate the payment provider key“ (Schlüssel des Zahlungsanbieters rotieren) wegen der Secret-Werte heraus, und „Check the Spanish checkout on the live site“ (spanischen Checkout auf der Live-Website prüfen) fällt als manuelle QA heraus. Der Gate-Prompt lautet „Approve the candidate list (or trim it) before anything is dispatched.“ (Geben Sie die Kandidatenliste frei oder kürzen Sie sie, bevor etwas zugeteilt wird.) Eine Ablehnung schickt den Lauf zurück zu den Kriterien.

Die Dispatch-Liste behält drei Jobs mit dem Grund, warum jeder passt, und schließt zwei mit ihren Begründungen aus; Maya gibt die Liste frei, bevor ein Agent startet.

Das Job-Protokoll

Jedes gesteuerte Ereignis ist eine typisierte Zeile am Job:

Lesen Sie das Protokoll von oben nach unten. Der Reviewer liest das Artefakt, nicht die Zusammenfassung des Executors: jeden Diff-Hunk, und die betroffenen Tests laufen erneut. Eine Zeile changes requested stoppt den Lauf, und dieselbe Session macht mit dem Befund weiter. Eine Ablehnung ohne bekannten Grund, etwa ein unbekannter Fehler, wird zu einem Bug-Task, sodass eine Eskalation in einem nachverfolgten Job endet statt in einer Chatnachricht.

Vier Notizzeilen an einem Job: zugeteilt, Änderungen angefordert, freigegeben, abgeschlossen mit Merge-Request 14.

Was schiefgeht

Die Fehler, die es wert sind, erzählt zu werden, sind die stillen. Ein Job, der nicht mehr läuft, und ein Filter, der nichts zurückgibt, sehen beide aus wie „alles in Ordnung“.

Ein täglicher Job, der nicht mehr startete

Einer unserer täglichen Jobs startete nicht mehr. Sein Ausführungsverlauf zeigte nur Erfolge, denn ein Lauf, der nie beginnt, kann nicht fehlschlagen.

Die Zeitplanebene hat es bemerkt. Ein Zeitplan wird als missed markiert, mit dem Grund „No run for too long“ (zu lange kein Lauf), sobald die Zeit seit seinem letzten Lauf das 1,5-Fache des längsten normalen Abstands in seiner Regel überschreitet. Bei einem täglichen Job sind das 36 Stunden. Ein übersprungener Start zählt nicht als Lauf. Die Markierung nennt das Datum, an dem die Stille begann, und einen Link „Open schedule“ (Zeitplan öffnen) zur Behebung. Der Review-Rhythmus meldet seine eigene Lücke, statt zu verstummen.

Die ConvOps-Seite der Zeitpläne markiert „Product photo ideas“ (Produktfoto-Ideen) mit „No run for too long“ (zu lange kein Lauf), während „Up next“ (Als Nächstes) den Job für heute weiterhin aufführt.

Ein Filter, der nichts zurückgab

In unserem ersten Dispatch-Lauf suchte die Kandidatenabfrage nach Tasks, die noch nicht zugeteilt waren, indem sie ein Statusfeld negierte. Dieses Feld ist bei jedem Task leer, der nie zugeteilt wurde. Ein negierter Filter auf einem leeren Feld verwirft die Zeile, also gab die Abfrage eine leere Liste zurück, während passende Tasks im Backlog lagen. Nichts warf einen Fehler, und eine leere Liste liest sich genau wie „nichts zu tun“.

Die Regel, die daraus entstand: Negieren Sie nie ein Feld, das leer sein kann; filtern Sie nach dem, was Sie wollen, nicht nach dem, was Sie nicht wollen. Sie steht in dem Schritt, der die Kandidaten auswählt: „Never filter on execution_status, executor or any other nullable field with ne / nin / NOT.“ (Nie auf execution_status, executor oder ein anderes Feld, das leer sein kann, mit ne / nin / NOT filtern.) Der Defekt selbst wurde als Bug-Task erfasst. Die Regel steht im Schritt, also gilt sie, egal was die Abfrage-Engine tut. So wird aus einem Fehler eine Regel, in allen unseren Loops.

Ihr eigenes Betriebsmodell aufbauen

Governance für KI-Agenten beginnt in einem kleinen Unternehmen mit einer Seite und einem Gate. Ein kleines Unternehmen braucht kein Gremium. Es braucht einen Owner für jeden Job.

Die einseitige Version zum Übernehmen:

AI governance operating model: <company>
Reviewed: <date>    Page owner: <name>

1. Decision rights
   Runs alone:          triage, routing with a one-line reason, drafting, review passes
   Waits for a person:  frozen requirements, merge, publish, the dispatch list
   Never delegated:     production data, secret values, spend, live-site checks
   Stop and ask:        production, secrets, spend, publishing, scope, a choice of fixes

2. Owners
   <job>   owner: <one agent or person>   approver: <person>

3. Escalation
   refused: <job>: <message, verbatim>    unknown reason: open a bug task
   stalled: <job>: <reason>               tell <person>; never dispatch again while alive

4. Gates
   Requirements: <person> approves, list frozen
   Merge or publish: green check AND <person> or their written delegation

5. Reviews
   <job>   <cadence>   missed after 1.5 times the longest normal gap

Füllen Sie sie für die Jobs aus, die Ihre Agenten bereits erledigen. Das erste Gate, das Sie einbauen sollten, ist das vor jedem Livegang.

Bauen Sie Ihr erstes Freigabe-Gate mit einem kostenlosen ConvOps-Konto in einen Workflow ein(wird in einem neuen Tab geöffnet). Soll es in Ihrem Unternehmen eingerichtet werden? Buchen Sie eine kostenlose Discovery Session.