Ihre IT-Governance wurde für Software gebaut, die sich nicht ändert. Agenten ändern sich täglich.
Sie haben bereits IT-Governance, und sie ist gut in dem, wofür sie gebaut wurde: deterministische Software, änderungskontrollierte Releases, dieselbe Eingabe erzeugt dieselbe Ausgabe. Sie hat Ihnen jahrzehntelang gedient, und der Instinkt, sie auf Agenten auszudehnen, ist vernünftig.
Nur ist ein Agent nichts von dem, was diese Governance voraussetzt. Er ist probabilistisch, er driftet mit jedem Modell-Update, und er handelt auf lebendem Kontext, den keine Release Note erfasst. Change Control für festen Code auf etwas zu stülpen, das sich täglich ändert, hält nicht, und das Gegenteil zu behaupten ist die Art, wie ein governt aussehendes Projekt ein ungovernbares System hervorbringt.
Der Fehler ist nicht, dass IT-Governance schwach wäre. Sondern dass Sie von ihr eine Frage beantwortet haben wollen, die zu stellen sie nie entworfen wurde. Change Control fragt "was hat sich geändert, wer hat es freigegeben, und wann haben wir es ausgeliefert?". Diese Frage hat keine Antwort, wenn die Änderung ein Modell-Update ist, das Sie nicht ausgeliefert haben, und das Verhalten sich von selbst verschob.
Die Einheit der Governance muss sich ändern
Deterministische Governance governt Releases. Agenten-Governance muss Entscheidungen governen.
Das klingt nach einer Feinheit. Es ist die ganze Sache. In einer release-zentrierten Welt gilt, sobald ein Build getestet und ausgeliefert ist, jede Ausführung dieses Builds als korrekt, weil der Build korrekt ist. Die Einheit, die Sie abzeichnen, ist das Release, und das Release ist stabil.
Ein Agent hat kein stabiles Release zum Abzeichnen. Zwei Läufe desselben Agenten auf demselben Dokument können sich unterscheiden, und das Modell dahinter kann nächste Woche ein anderes sein. Was Sie governen, kann also nicht der Build sein. Es muss jede Entscheidung sein, die der Agent trifft: was er entschied, in wessen Vollmacht, auf welchen Eingaben und gegen welche Policy. Governance wird vom einmal passierten Gate zu einer Disziplin, die fortlaufend läuft, bei jeder Entscheidung, über die Lebensdauer des Systems.
Das ist kein Policy-PDF. Es ist ein konstruiertes Control mit Eigentümer und Audit-Trail.
Agenten verdienen Autonomie, sie starten nicht damit
Der Kernmechanismus ist abgestufte Autonomie. Ein Agent geht nicht autonom live. Er steigt eine Leiter, und Evals, die Tests, die messen, ob er eine Schwelle überspringt, sind das Vertrauens-Gate auf jeder Stufe.
| Stufe | Rolle | Was sie bedeutet | Beispiel |
|---|---|---|---|
| Shadow | Agent beobachtet | Schlägt vor, handelt nie. Baseline-Evals setzen die Schwelle. | Entwirft das Kreditmemo; ein Mensch schreibt das, was rausgeht. |
| Supervised | Human-in-the-loop | Handelt erst, nachdem ein Mensch jeden Schritt freigibt. | Bereitet die Zahlung vor; ein Mensch klickt auf Freigeben. |
| Guided | Human-on-the-loop | Handelt autonom; Menschen bearbeiten Ausnahmen. | Onboardet Kunden durchgängig; Menschen prüfen markierte Fälle. |
| Full | Autonom | Läuft durchgängig in einem begrenzten, dokumentierten Wirkradius. | Gleicht nachts Konten ab; folgenschwere Entscheidungen brauchen weiter eine Freigabe. |
Lesen Sie die Leiter genau, denn zwei Eigenschaften machen sie zu mehr als einer Reifegradtabelle.
Erstens wird eine Stufe verdient, nicht terminiert. Der Agent steigt nur auf, wenn er die Eval-Schwelle der nächsten Ebene überspringt, und die Schwelle wird vorab auf der Baseline des Prozesses gesetzt. Das ist das Gegenteil eines Launch-Plans, den man für ein Datum durchdrückt.
Zweitens wird eine Stufe automatisch verloren. Erkennt die Drift-Überwachung, dass die Leistung die Schwelle verlassen hat, wird der Agent zurückgestuft, ohne zu warten, bis es ein Mensch bemerkt. Autonomie ist keine einmal erteilte und vergessene Erlaubnis. Sie ist ein Zustand, den das System fortlaufend rechtfertigen muss.
Während der Agent sich bewährt, werden Menschen von Freigebenden zu Ausnahmebearbeitenden. Das ist ein echter Effizienzgewinn, und er ist per Design durch Haftung begrenzt. Die Autonomiematrix und der Kill-Switch sind dokumentiert, getestet und tragen ein unveränderliches Override-Log. Der Wirkradius eines "Full"-Agenten ist nicht "was immer er zu tun beschließt". Es ist ein begrenzter, schriftlicher Scope, mit folgenschweren Entscheidungen weiterhin bei einer Person.
Evals sind die Vertrauensschwelle, kein Häkchen zum Launch
Das Wort "Eval" wird locker verwendet, deshalb lohnt Konkretheit über seine Rolle hier.
Ein Eval ist kein einmaliger Abnahmetest, den man vor Go-live fährt und dann archiviert. Es ist die stehende Messung, die fortlaufend entscheidet, ob der Agent die Autonomie verdient, die er gerade hält. Es verwandelt "wir glauben, es funktioniert" in "es hat die Schwelle heute um 09:14 übersprungen, und das ist der Score, der diese Stufe autorisiert hat".
Das zählt, weil probabilistische Systeme leise degradieren. Ein Modell-Update verbessert ein Verhalten und verschlechtert ein anderes. Eine Verschiebung der Eingabeverteilung, neue Dokumentformate, ein neues Betrugsmuster, entfernt den Agenten von den Fällen, an denen er validiert wurde. Ohne laufendes Eval und Drift-Überwachung ist nichts davon sichtbar, bis es eine Kundin oder eine Aufsicht erreicht. Mit ihnen ist die Rückstufung automatisch, und die Aufzeichnung zeigt genau wann und warum.
Evals plus Drift-Überwachung lassen Sie den Satz sagen, den ein Risikoausschuss hören muss: Die Vollmacht des Agenten wird nicht unterstellt, sie wird gemessen, und sie wird entzogen, sobald die Messung fällt.
Das steht neben Ihrer IT-Governance, nicht darüber
Das Ziel ist nicht, ITIL zu ersetzen. Es ist, Verantwortlichkeiten so sauber zu benennen, dass niemand annimmt, die andere Schicht decke eine Lücke.
| Thema | Ihre IT-Governance | Agenten-Governance |
|---|---|---|
| Deterministische Releases, Infrastruktur, Zugriff | Gehört ihr | Nutzt sie |
| Modell- und Verhaltensdrift, Tag für Tag | Nicht dafür entworfen | Gehört ihr (Evals, Drift-Überwachung) |
| Nachweise pro Entscheidung | Nicht ihre Arbeitseinheit | Gehört ihr (Nachweisspur) |
| Autonomie und Wirkradius | Entfällt | Gehört ihr (Leiter, Kill-Switch) |
Ihre IT-Governance macht weiter, worin sie exzellent ist: Infrastruktur, Zugriff, deterministische Releases. Die Agenten-Governance-Schicht steht daneben und verantwortet, was deterministische Governance nie tragen sollte: Drift, Nachweise pro Entscheidung und die Autonomieleiter. Zwei Systeme, saubere Nähte, keine unterstellte Abdeckung.
Der zu vermeidende Fehlermodus ist der leise: ein Projekt, das governt aussieht, weil es durch das übliche Change Board ging, und in der Praxis ungovernbar ist, weil dieses Board kein Mittel hat, ein Modell-Update zu sehen oder Drift zu messen. Es hat das falsche Gate passiert.
Die Frage für Ihr nächstes Review lautet also nicht "ist das durch Change Control gegangen?". Sie lautet: wem gehört bei einem System, das sich täglich ändert, die Drift, wo sind die Nachweise pro Entscheidung, und können wir einen Agenten automatisch zurückstufen, sobald er seine Schwelle verlässt? Lautet die ehrliche Antwort "unser Release-Prozess nimmt an, dass es getestet bleibt", haben Sie noch keine Agenten-Governance. Sie haben deterministische Governance, gerichtet auf ein probabilistisches System, und die beiden passen nicht.
Wenn Sie sehen wollen, wie verdiente Autonomie an einem Ihrer Prozesse aussieht, buchen Sie einen Termin.