Wer darf Agenten bauen? Wie Self-Service-KI Regeln bekommt, ohne auszubremsen

Stellen Sie sich einen Freitagnachmittag im Kundenservice eines Maschinenbauers vor. Eine Mitarbeiterin hat die immer gleichen Rückfragen zum Fehler E-217 am Füller FL-200 satt. Sie beschreibt in zwei Sätzen, was ein Agent tun soll, und hat vor Feierabend einen Ablauf, der Antwortentwürfe erstellt und per E-Mail versendet. Er funktioniert gut. Am Montag stellen drei Personen drei Fragen. Die IT will wissen, wer das erlaubt hat. Die Teamleitung will wissen, wer den Ablauf künftig ändern darf. Und die Geschäftsführung fragt, was passiert, wenn die Mitarbeiterin im Urlaub ist und gerade eine Antwort auf Freigabe wartet.

Dieses Szenario ist ein Gedankenexperiment mit fiktiven Unterlagen, kein Kundenfall. Es zeigt aber, worum es bei Self-Service-KI geht: Das Bauen ist schnell geworden, die Zuständigkeiten sind es nicht. Wer Agenten ohne Programmierkenntnisse zusammenstellen kann, braucht kein Projekt mehr, um etwas auszulösen. Genau deshalb braucht es vorher Regeln, wer was auslösen darf.

Unsere These: Self-Service-KI braucht keine Bremse, sondern Trennung. Bauen, Teilen, Veröffentlichen und Handeln sind vier verschiedene Rechte. Wer sie sauber trennt und jeweils einer benannten Rolle zuordnet, kann das Bauen für viele öffnen und trotzdem bei wenigen Stellen entscheiden lassen, was wirklich nach außen wirkt. Dieser Artikel geht die Trennlinien der Reihe nach durch: die vier Rollen, das Teilen, den Weg vom Entwurf zur Veröffentlichung, Versionen, Werkzeugrechte und die Vertretung bei Freigaben.

Zwei Wege, die beide scheitern

Wenn Unternehmen KI-Agenten einführen, landen sie meist an einem von zwei Extremen.

Der erste Weg ist die Zentrale: Nur ein kleines Team, meist in der IT, darf Agenten bauen, alle anderen stellen Anträge. Das fühlt sich sicher an. In der Praxis entsteht eine Warteschlange, und die Fachabteilungen, die ihr Problem am besten kennen, warten auf ein Team, das es nur aus zweiter Hand kennt. Man kennt das von anderen Werkzeugen: Es wird ausgewichen, auf private Konten, auf kostenlose Dienste, auf Browser-Erweiterungen. Was Sie nicht ermöglichen, passiert trotzdem, nur ohne Protokoll.

Der zweite Weg ist der offene Raum: Jeder darf alles, Hauptsache schnell. Die ersten Wochen sind beeindruckend. Nach einem halben Jahr gibt es Agenten, deren Ersteller das Team gewechselt haben, Abläufe, die E-Mails an Kundschaft versenden, und niemand weiß mehr, wer sie damals geprüft hat. Das ist kein Vorwurf an die Mitarbeitenden, sondern die Folge fehlender Struktur.

Die dritte Zeile ist unsere Empfehlung. Sie ist weder die bequemste noch die strengste, aber sie ist die einzige, bei der Tempo und Kontrolle nicht gegeneinander ausgespielt werden. Das gelingt nur, wenn die Stufen nicht Gefühl sind, sondern im Werkzeug stehen: als Zugriffsstufe, als Veröffentlichungsstatus, als Werkzeugrecht.

Vier Rollen statt einer Berechtigung

Die meisten Regelwerke scheitern an einem Wort: „Admin“. Wenn es nur Nutzer und Admins gibt, wird jede Person, die mehr als lesen soll, zum Admin, und Admins dürfen dann alles. In der Praxis bewährt sich ein Modell mit vier Rollen. Es ist ein Vorschlag, den Sie an Ihre Organisation anpassen, keine Produktvorgabe. Eine Person kann mehrere Rollen tragen. Nur beim selben Agenten sollte sie nicht gleichzeitig Ersteller und Freigebende sein.

Vergrößern

Wie bildet TheroAI das ab? Je Agent gibt es drei Zugriffsstufen: „Darf ansehen“, „Darf bearbeiten“ und „Darf verwalten“. Die Rollen Nutzer und Ersteller liegen darauf. Die Rolle der Freigebenden taucht an zwei Stellen auf. Beim Veröffentlichen sind es die Veröffentlichungsprüfer, die Eigentümer getrennt vom Bearbeitungsrecht vergeben. Im Ablauf selbst sind es die freigebenden Personen eines Freigabeschritts. Die Rolle der Administratoren sitzt in den Einstellungen der Organisation und in den Auswertungen, dort, wo Werkzeugrechte, Konnektoren und das Audit-Log liegen.

Der Kern des Modells ist die Spalte ganz rechts in der Tabelle: Jede Rolle hat etwas, das sie bei ihren eigenen Agenten nicht tun darf. Das ist keine Misstrauensbekundung. Es ist derselbe Gedanke wie bei der Überweisung über einer bestimmten Summe: Nicht, weil die Person unzuverlässig wäre, sondern weil ein zweiter Blick Fehler findet, die dem ersten verborgen bleiben, wenn man seine eigene Arbeit prüft.

Teilen: Wer darf einen Agenten sehen, ändern und verwalten

„Teilen“ klingt harmlos, ist aber die Stelle, an der aus einem persönlichen Hilfsmittel ein gemeinsames Werkzeug wird. In TheroAI beantwortet der Dialog „Teilen“ die Frage, wer einen Agenten sehen und bearbeiten darf. Die engste Einstellung ist „Privat“. Von dort gibt es drei Wege: einzelne Personen hinzufügen, die gesamte Organisation freigeben oder den Zugriff wieder entziehen.

Zwei Regeln helfen im Alltag. Erstens: Teilen Sie standardmäßig zum Ansehen, nicht zum Bearbeiten. Der Bearbeiter-Zugriff ist die Einladung zum Mitbauen. Er ist sinnvoll, wenn zwei Personen an einem Ablauf arbeiten oder wenn jemand als Vertretung einspringen soll. Er ist zu großzügig, wenn er nur bequem war. Zweitens: Der Kreis der Nutzer ist selbst eine Änderung, die Aufmerksamkeit verdient. TheroAI trägt dem Rechnung. Entzogener Zugriff wirkt sofort. Neue Zielgruppen können einen bereits veröffentlichten Agenten dagegen erst nach Prüfung und Veröffentlichung der erweiterten Zugriffe nutzen. Wer den Agenten auf die ganze Organisation ausweiten will, geht also durch dieselbe Tür wie bei einer inhaltlichen Änderung.

Entwurf und Veröffentlichung: der Schalter zwischen Probieren und Wirken

Die wichtigste Trennlinie im gesamten Modell verläuft zwischen dem, was jemand ausprobiert, und dem, was für andere gilt. In TheroAI wird jeder Agent zuerst als Entwurf gespeichert. Der Entwurf lässt sich im Editor testen, ohne dass irgendwo etwas auslöst: Die nächste Testnachricht nutzt den gespeicherten Entwurf, ein Testlauf zeigt die Schritte. Entscheidend ist ein Satz, der im Editor steht: Auslöser laufen nur mit einer veröffentlichten Fassung. Ein Zeitplan, ein Formular oder ein Ereignis wirkt also erst, wenn jemand bewusst auf „Veröffentlichen“ klickt.

Vergrößern

Der Editor hilft dabei mit einfachen Prüfungen. Fehlt der Name, fehlen die Anweisungen, hat ein Ablauf noch keine Schritte oder ist ein Zeitplan ungültig, meldet er „Noch nicht veröffentlichbar“ und listet die offenen Punkte. Dazu kommt eine Festlegung, die man leicht übersieht: Die Arbeitsweise, also frei arbeiten oder nach Ablauf, steht nach der Veröffentlichung fest. Ein Agent wechselt nicht still von einer Art in die andere.

Was beim Einreichen passiert

Für Agenten, die mit anderen geteilt werden, kommt eine zweite Stufe hinzu: die Prüfung. Der Ersteller reicht eine Fassung „zur Prüfung“ ein und beschreibt in einem Satz, was sich ändert und warum. Von da an gilt:

• Die Fassung ist eingefroren. Spätere Änderungen am Entwurf bleiben separat und ändern nichts an der eingereichten Fassung.
• Die Prüfung zeigt den Unterschied. Die prüfende Person sieht den aktuellen Live-Stand neben der eingereichten Fassung, wahlweise nur die Änderungen, dazu Zugriffe, Auslöser und Verlauf.
• Testnachweise gehören zur Fassung. Ist dieser Fassung kein Ausführungstest zugeordnet, sagt die Oberfläche das offen: Ein früherer oder späterer Test belegt nicht diesen konkreten Stand.
• Es gibt mehr als Ja und Nein. Die Prüfung kann veröffentlichen, Änderungen anfordern oder ablehnen, der Ersteller kann die Fassung zurückziehen.
• Veraltete Kandidaten fallen auf. Hat sich der Live-Stand inzwischen geändert, soll der Kandidat zurückgezogen und auf aktueller Basis neu eingereicht werden.

Geprüft werden nicht nur Texte. Zur Fassung gehören Name und Beschreibung, Anweisungen, Werkzeuge und Wissen beziehungsweise die Schritte des Ablaufs, Auslöser und Zeitplan, Zielgruppe und Zugriffe, die ohne Begleitung erlaubten Werkzeuge, die Ausführungsidentität, die Zustellung der Ergebnisse sowie die Verbindungsidentitäten und Berechtigungen. Anders gesagt: Auch die Stellschrauben, an denen ein Agent mächtiger wird, laufen durch die Prüfung.

Wer prüft

Die Prüfer werden von den Eigentümern getrennt vom Bearbeitungsrecht vergeben. Für gemeinsam genutzte Agenten gilt: Es braucht eine andere Person als den Autor. Wer persönliche Agenten ebenfalls prüfen lassen will, kann das als Richtlinie verlangen. Wir würden das für alle Agenten empfehlen, die nach außen schreiben, und bei reinen Recherchehelfern auf die Prüfung verzichten. Entscheidend ist, dass die Unterscheidung bewusst getroffen wird und nicht am Zufall hängt.

Vergrößern

Versionen: Zurückholen ist möglich, Ungeschehenmachen nicht

Jede Veröffentlichung erzeugt in TheroAI eine Version, die Sie später zurückholen können. Das nimmt dem Veröffentlichen die Angst, aber nur, wenn man genau versteht, was „Zurückholen“ bedeutet.

Beim Zurückholen wird der Entwurf mit Name, Beschreibung, Auslöser und Schritten der gewählten Version überschrieben. Die aktive Version bleibt unverändert, bis Sie erneut veröffentlichen. Der Weg zurück ist also zweistufig: erst zurückholen, dann bewusst wieder veröffentlichen. Wer den Entwurf nur verwerfen will, kann „Zurück zur Veröffentlichung“ wählen und sieht vorher, welche Felder verworfen werden. Und weil jeder Lauf festhält, mit welcher Version er lief (im Protokoll etwa „lief mit v2“), lässt sich später nachvollziehen, welcher Stand eine bestimmte Antwort erzeugt hat.

Vergrößern

Daneben gibt es die Rücknahme einer Veröffentlichung. Sie stoppt neue Chatstarts, Zeitpläne und Ereignisläufe. Laufende Vorgänge behalten ihre Version und unterliegen den aktuellen Richtlinien. Was bereits nach außen gegangen ist, etwa eine versendete E-Mail, wird dadurch nicht rückgängig gemacht. Das ist die ehrliche Grenze jeder Versionierung: Sie kann die Konfiguration zurückdrehen, nicht die Wirkung. Deshalb gehören Versionen und Freigaben zusammen. Die Version fängt Fehler im Bauen auf, die Freigabe fängt Fehler vor der Wirkung auf.

Werkzeugrechte: der Rahmen der Organisation und der Spielraum je Agent

Ein Agent ist nur so mächtig wie die Werkzeuge, die er benutzen darf. Deshalb ist die Frage nach den Werkzeugrechten die eigentliche Frage nach der Risikogrenze. In TheroAI wirken sie in drei Ebenen, die sich wie Schalen ineinander legen.

Ebene 1, die Organisation. In den Einstellungen unter „KI-Tools“ legen Administratoren je Dienst oder Aktion fest, was erlaubt ist, eine Bestätigung erfordert oder gesperrt bleibt. Diese Einstellungen gelten für alle in der Organisation. Schreibende Werkzeuge sind gekennzeichnet, und für sie ist „Nachfragen“ die naheliegende Wahl. In der Demo-Umgebung zeigt die Übersicht 236 erlaubte, 138 Werkzeuge mit Nachfrage und 0 gesperrte.

Vergrößern

Ebene 2, der Agent. Ein Agent, der dauerhaft im Hintergrund arbeitet, hat eine eigene Liste „Selbstständig erlaubt“. Dort stehen die Aktionen, die er ohne Rückfrage ausführen darf. Zur Auswahl stehen nur Werkzeuge, die etwas verändern oder versenden, und jede Ausführung wird protokolliert. Zusätzlich zeigt der Bereich „Im Hintergrund“ ehrlich, was gerade möglich ist: bereit, mit Freigabe, nur im Chat, Zugriff fehlt. Diese Liste ist Teil der Fassung, die geprüft wird. Wer einem Agenten mehr Selbstständigkeit gibt, ändert damit etwas, das eine zweite Person sieht.

Ebene 3, der Lauf. Auch bei erlaubten Aktionen kann ein Ablauf eine Freigabe vor der Wirkung verlangen. Das ist die Ebene der Freigebenden, und sie ist im nächsten Abschnitt Thema.

Vergrößern

Die Regel hinter den Schalen ist so gedacht: Jede Ebene darf enger werden als die darüber, nie weiter. Die Oberfläche sagt es bei einem gesperrten Werkzeug ausdrücklich: Es steht dem Agenten nicht zur Verfügung. Prüfen Sie in Ihrer Umgebung an einem Beispiel, dass das auch für die Liste „Selbstständig erlaubt“ gilt, bevor Sie sich darauf verlassen. Wie Sie die Voreinstellungen wählen, hängt von der Reichweite einer Aktion ab. Die folgende Tabelle ist ein Vorschlag für den Start, keine Produktvorgabe.

Mehr zu den Werkzeugen und ihren Einstellungen finden Sie auf der Seite zu den Werkzeugen, zum Gesamtbild des Schutzes auf der Seite Sicherheit.

Vertretung: damit Freigaben im Urlaub nicht hängen bleiben

Kommen wir zurück zur Frage der Geschäftsführung vom Anfang: Was passiert, wenn die Mitarbeiterin im Urlaub ist und eine Freigabe wartet? Die Antwort ist unspektakulär, aber sie muss vorher feststehen. Für Agenten, die dauerhaft im Hintergrund arbeiten, kennt TheroAI eine Vertretung. Der Eigentümer benennt sie in den Einstellungen des Agenten, und sie entscheidet über Freigaben und Daueraufträge, wenn er nicht da ist.

Drei Details zeigen, wie genau das gedacht ist. Die Vertretung muss zuvor als Bearbeiter für den Agenten eingetragen sein. Hier zahlt sich die Regel aus dem Abschnitt zum Teilen aus: Wer nie jemanden als Bearbeiter eingetragen hat, kann auch niemanden vertreten lassen. Die Vertretung wird nur vom Eigentümer gewählt. Und sie entfällt, wenn der Zugriff der Person entzogen oder auf „Darf ansehen“ reduziert wird. So bleibt nie eine Vertretung übrig, die ihre Rechte längst verloren hat.

Im Ablauf selbst legt jeder Freigabeschritt fest, wer entscheidet und bis wann. Im Beispielablauf „Support-Anfrage beantworten“ sind das eine freigebende Person und eine Frist von 72 Stunden. Die erste Entscheidung zählt. Und wenn das Vier-Augen-Prinzip eingeschaltet ist, dürfen Auslöser und Ersteller des Agenten nicht entscheiden, auch nicht als Admin. Das ist die technische Seite des Satzes, dass niemand den eigenen Agenten freigibt.

Warum die Vertretung kein Detail ist, zeigt eine Beispielrechnung. Die Zeiten sind angenommen, die Frist stammt aus dem Beispielablauf.

Vergrößern

Was nach Ablauf einer Frist technisch geschieht, behauptet diese Rechnung bewusst nicht; sie zeigt nur die Zeit, in der niemand entschieden hat. Sie beweist nichts über Ihre Abläufe, sie macht nur sichtbar, dass die Frist eines Freigabeschritts und die Abwesenheiten Ihres Teams zusammenpassen müssen. Eine Frist ohne benannte Vertretung ist eine Verabredung mit niemandem. Eine gute Vertretung kennt den Agenten, hat Zugriff als Bearbeiter und ist nicht dieselbe Person, die ihn gebaut hat, sonst fehlt der zweite Blick auch in der Urlaubszeit.

Wie Freigabeschritte im Ablauf aufgebaut sind, beschreibt die Seite zu den Workflows.

Woran Self-Service-Governance in der Praxis scheitert

Die Regeln selbst sind selten das Problem. Es sind die Gewohnheiten drumherum. Fünf Muster, auf die Sie achten sollten:

• Agenten ohne lebenden Eigentümer. Die Person hat das Team gewechselt, der Agent läuft weiter. Prüfen Sie regelmäßig, ob jeder aktive Agent einen erreichbaren Verantwortlichen und eine Vertretung hat.
• Bearbeiter-Zugriff als Abkürzung. Es ist einfacher, jemanden als Bearbeiter einzutragen, als zu klären, was die Person tatsächlich braucht. Das Ergebnis sind viele Mitbauende ohne gemeinsame Verantwortung.
• Alle Freigaben bei derselben Person. Wer jeden Tag zwanzig Anfragen bestätigt, schaut irgendwann nicht mehr hin. Verteilen Sie Freigaben nach Fachlichkeit und sorgen Sie für Vertretung.
• Werkzeugrechte, die einmal gesetzt und nie wieder angesehen werden. Neue Verbindungen und neue Werkzeuge verändern das Gesamtbild. Eine Durchsicht im Quartal reicht oft, wenn sie feststeht.
• Veröffentlicht wird, was funktioniert hat, nicht, was geprüft wurde. Der Test von gestern gilt nicht für die Fassung von heute. Verlangen Sie, dass Nachweis und eingereichte Fassung zusammengehören.

Betriebsrat und Recht: ein Hinweis

Ein Rollenmodell mit Protokoll berührt die Mitbestimmung. Technische Einrichtungen, die dazu bestimmt sind, das Verhalten oder die Leistung von Beschäftigten zu überwachen, unterliegen nach § 87 Abs. 1 Nr. 6 des Betriebsverfassungsgesetzes der Mitbestimmung des Betriebsrats. Ob und in welchem Umfang das für Ihre Protokolle gilt, hängt vom Einzelfall ab. Unsere Empfehlung ist praktisch: Zeigen Sie dem Betriebsrat das Rollenmodell, bevor Sie es einführen, und erklären Sie, wer was sieht und wozu. Das ist keine Rechtsberatung, klären Sie den Einzelfall mit Ihrer Rechtsberatung.

Was Sie daraus mitnehmen können

Unsere Position in einem Satz: Öffnen Sie das Bauen weit, halten Sie das Veröffentlichen eng und machen Sie das selbstständige Handeln zur begründeten Ausnahme mit Namen. Dann ist Self-Service-KI kein Risiko, das man tolerieren muss, sondern ein Verfahren, das man erklären kann.

Fünf Schritte für die nächsten Wochen:

1. 1.Rollen benennen. Wer sind Ersteller, wer Freigebende, wer Administratoren? Schreiben Sie Namen auf, nicht Funktionen.
2. 2.Teilen-Standard festlegen. Neue Agenten bleiben privat, Zugriff zum Ansehen ist der Normalfall, Bearbeiter-Zugriff braucht einen Grund.
3. 3.Veröffentlichungsprüfer ernennen. Mindestens zwei Personen je Fachbereich, damit niemand allein entscheidet und niemand zum Engpass wird.
4. 4.Werkzeugrechte durchgehen. Schreibende Werkzeuge auf „Nachfragen“, gefährliche auf „Sperren“, und die Liste „Selbstständig erlaubt“ mit dem Team Zeile für Zeile lesen.
5. 5.Vertretungen eintragen. Für jeden dauerhaft arbeitenden Agenten, mit Bearbeiter-Zugriff, und die Frist der Freigabeschritte an die Abwesenheitsrealität anpassen.

Und sieben Prüffragen, die Sie jedem Agenten stellen können:

Wer ist verantwortlich, und wer vertritt diese Person?

>

Wer hat diese Fassung geprüft, und war es eine andere Person als der Autor?

>

Was wirkt nach außen, und steht davor eine Freigabe?

>

Welche Werkzeuge darf der Agent ohne Rückfrage nutzen, und wer hat das entschieden?

>

Auf welche Version können wir zurück, und was lässt sich dadurch nicht rückgängig machen?

>

Wer kann den Agenten pausieren, wenn etwas schiefgeht?

>

Wie würden wir das der Revision und dem Betriebsrat erklären?

Wenn Sie sehen möchten, wie sich Entwurf, Teilen, Freigabe und Werkzeugrechte in TheroAI anfühlen, zeigen wir Ihnen das gern in einem Demo-Termin, mit Ihren eigenen Beispielen und ohne Vorbereitung auf Ihrer Seite.