Als wir die ersten Konnektoren für Thero gebaut haben, ist uns eine Zahl davongelaufen: die Zahl der Werkzeuge. Eine angebundene App ist aus Sicht der KI keine Einheit, sie zerfällt in einzelne Werkzeuge. Gmail bringt Werkzeuge zum Durchsuchen des Postfachs mit, zum Lesen einzelner Nachrichten, zum Erstellen von Entwürfen, zum Senden. Ein Kalender bringt Werkzeuge zum Anzeigen, Anlegen und Verschieben von Terminen. Dazu kommen Websuche, Personensuche, die interne Wissensdatenbank, Dokumente. Zählt man zusammen, was eine Organisation anbindet, stehen mehr als 300 einzelne Werkzeuge bereit, die ein Assistent, ein Agent oder ein Workflow aufrufen kann.
Für IT-Verantwortliche klingt das zunächst nach Kontrollverlust. Die Frage kam in fast jedem frühen Gespräch: Wer entscheidet, was die KI darf? Und gleich danach die Folgefrage: Gilt diese Entscheidung auch dann, wenn nachts ein automatisierter Workflow läuft und niemand zuschaut?
Unsere Antwort auf beide Fragen ist keine Funktionsliste. Es ist eine einzelne Architekturentscheidung, die wir früh getroffen haben: Die Regeln wohnen an genau einer Stelle. In diesem Artikel beschreiben wir diese Entscheidung, die Abwägungen dahinter und die Form, in der sie heute im Produkt sichtbar ist.
Wo wohnen die Regeln?
Als die ersten Konnektoren standen, gab es drei naheliegende Orte, an denen Regeln hätten leben können. Alle drei haben wir verworfen.
- Im Prompt. „Bitte sende keine E-Mails ohne Rückfrage“ ist keine Regel. Es ist ein Wunsch. Ein Modell kann ihn übersehen, ein langer Kontext kann ihn verdrängen. Auf einen Wunsch baut niemand eine Compliance-Argumentation.
- In der Konfiguration jedes Agenten. Dann hat eine Organisation mit zwanzig Agenten zwanzig Regelwerke. Sie driften auseinander. Gefährlich ist am Ende der eine Agent, den beim letzten Update niemand angefasst hat.
- Am Konnektor als Ganzem. Ein Schalter pro App ist zu grob. Wer die Mail-Anbindung abschaltet, weil Senden riskant ist, verliert auch das Lesen. In der Praxis führt das zu Ausnahmen, und Ausnahmen sind der Anfang von Schatten-IT.
Alle drei Varianten teilen denselben Konstruktionsfehler: Die Regel steht nicht dort, wo der Aufruf passiert. Jemand muss sich an sie erinnern, sie kopieren oder pflegen.
Unsere Entscheidung sieht anders aus. Es gibt eine Organisationsrichtlinie pro Werkzeug. Nicht pro App, nicht pro Agent, nicht pro Prompt. Durchgesetzt wird sie an einer einzigen Stelle: in der Schicht, durch die jeder Werkzeugaufruf läuft. Ob der Aufruf aus einem Chat kommt, von einem Agenten oder aus einem Workflow-Schritt, spielt für die Prüfung keine Rolle. Es ist derselbe Pfad und damit dieselbe Regel.
Es gibt kein zweites Regelwerk, das ein Agent vergessen könnte.
Der Satz klingt banal. In Sicherheitsgesprächen ist er trotzdem das Argument mit dem größten Gewicht, weil er die Suche nach Sonderfällen beendet.
Drei Zustände pro Werkzeug
Jedes Werkzeug hat genau einen von drei Zuständen. Mehr braucht es nach unserer Erfahrung nicht, weniger reicht nicht aus.
| Zustand | Was beim Aufruf passiert | Typischer Einsatz |
|---|---|---|
| Erlaubt | Das Werkzeug läuft sofort. Der Aufruf wird im Audit-Log protokolliert. | Lesende Zugriffe: Postfach durchsuchen, Termine anzeigen, Wissensdatenbank abfragen |
| Mit Nachfrage | Der Aufruf stoppt. Eine Person sieht die konkreten Parameter und genehmigt oder lehnt ab. | Schreibende Zugriffe: E-Mail senden, antworten, weiterleiten |
| Gesperrt | Das Werkzeug ist organisationsweit nicht aufrufbar, unabhängig davon, wer fragt. | Werkzeuge, die eine Organisation grundsätzlich ausschließt |
Weitere Zustände haben wir bewusst nicht eingeführt. Jede zusätzliche Abstufung, etwa „erlaubt, aber nur zu Bürozeiten“, müsste erklärt, gepflegt und auditiert werden. Drei Zustände kann ein Administrator im Kopf behalten.
So sieht die Einstellungsseite in unserer eigenen Umgebung aus, gefiltert auf Mail:
Der Zähler am Kopf der Seite ist echt, er zeigt „290 erlaubt · 32 mit Nachfrage · 0 gesperrt“. Zwei Dinge an dieser Verteilung sind interessant. Erstens laufen rund neun von zehn Werkzeugen ohne Unterbrechung, weil lesende Zugriffe keine Nachfrage brauchen. Zweitens steht hinter „gesperrt“ eine Null. Beides ist kein Zufall, beides folgt aus zwei Entwurfslinien, die wir in den nächsten Abschnitten beschreiben.
Lesen und Schreiben sind verschiedene Risikoklassen
Die wichtigste Linie im Katalog verläuft zwischen lesenden und schreibenden Werkzeugen. Jedes Werkzeug ist entsprechend klassifiziert, und die Oberfläche zeigt die Klasse offen an: Schreibende Werkzeuge tragen ein eigenes Badge.
Ein lesender Zugriff verändert nichts. Er unterliegt zudem den Berechtigungen, die ohnehin gelten, denn der Assistent liest nur, was die fragende Person selbst öffnen dürfte. Ein schreibender Zugriff wirkt dagegen nach außen. Eine gesendete E-Mail lässt sich nicht zurückholen, ein verschobener Termin steht sofort in fremden Kalendern.
Am Outlook-Konnektor zeigt sich das Muster exemplarisch. Die lesenden Werkzeuge stehen auf Erlaubt, vom Durchsuchen des Postfachs bis zum Lesen einzelner Nachrichten. Send, Reply und Forward tragen dagegen das Badge „Schreibend“ und das Hand-Symbol für die Nachfrage. Ein Agent kann also jederzeit rekonstruieren, was in einem Vorgang passiert ist. Sobald er selbst eine Nachricht verschicken will, hält der Aufruf an und wartet auf einen Menschen.
Die Linie verläuft dabei entlang der Außenwirkung, nicht entlang der Bequemlichkeit. Einen E-Mail-Entwurf darf der Assistent ohne Nachfrage anlegen, er landet nur im Entwurfsordner des Postfachs und verlässt die Organisation nicht. Erst beim Versand hält der Aufruf an.
Der Blick auf die Suche zeigt die andere Seite derselben Linie:
WebSearch, PeopleSearch und KnowledgeHub lesen ausschließlich, also stehen sie auf Erlaubt. Niemand muss eine Recherche genehmigen. Genau das macht die Nachfrage an anderer Stelle tragbar: Sie trifft ausschließlich Aufrufe, bei denen tatsächlich etwas nach außen geht.
Warum „mit Nachfrage“ besser ist als eine Sperre
Der erste Reflex vieler Organisationen ist die Sperre. E-Mail-Versand durch eine KI? Lieber ganz abschalten. Wir halten das für die schwächere Lösung, und der Grund lässt sich präzise benennen: Eine Sperre verbietet eine Fähigkeit pauschal. Eine Nachfrage entscheidet über einen konkreten Fall.
Will ein Agent eine E-Mail senden, stoppt der Aufruf und eine Genehmigungskarte erscheint. Darin stehen Empfänger, Betreff und der vollständige Text, darunter die Wahl zwischen Genehmigen und Ablehnen. Reagiert innerhalb von fünf Minuten niemand, gilt der Aufruf als abgelehnt, die sichere Voreinstellung ist das Nein. Die prüfende Person entscheidet über genau diese eine Nachricht an genau diesen Empfänger. Sie muss nicht die abstrakte Frage beantworten, ob eine KI jemals E-Mails senden darf. An dieser abstrakten Frage bleiben Freigabeprozesse in vielen Unternehmen hängen.
Die Nachfrage erzeugt außerdem Belege. Jede Entscheidung wird protokolliert: wer wann welchen konkreten Aufruf freigegeben oder abgelehnt hat. Aus der vagen Aussage „die KI darf das“ wird ein prüfbarer Eintrag.
Und die Null bei den Sperren? Sie ist die Konsequenz dieser Abwägung. Ein Werkzeug, das vor jedem schreibenden Aufruf um Erlaubnis fragt, muss selten ganz verboten werden. Die Sperre bleibt als hartes Mittel für Werkzeuge, die eine Organisation grundsätzlich ausschließen will. In unserer eigenen Umgebung haben wir sie bis heute nicht gebraucht.
Die Richtlinie am laufenden Prozess
Eine Richtlinie, die nur auf einer Einstellungsseite existiert, wäre wenig wert. Entscheidend ist, dass sie dort greift, wo Arbeit tatsächlich passiert, und dass man ihr dabei zusehen kann.
In der Prozessübersicht sehen Verantwortliche alle Agenten und Workflows der Organisation mit ihrem aktuellen Status. Ruft ein Agent mitten im Lauf ein nachfragepflichtiges Werkzeug auf, hält der Lauf genau an diesem Schritt an und wartet, bis jemand entschieden hat.
An diesem Punkt wird das Modell in der Praxis prüfbar. Ein Workflow, der nachts um drei läuft, unterliegt derselben Richtlinie wie eine Frage im Chat am Vormittag. Es gibt keinen Modus, in dem ein Agent mehr darf, weil er automatisiert läuft. Wer die Umgebung auditiert, muss deshalb keine Sonderfälle durchgehen. Es gilt eine Regel pro Werkzeug, es gibt einen Durchsetzungspunkt, und das Audit-Log hält zu jedem Aufruf Zeitpunkt, Prozess, Aktion, Status, Dauer und Person fest. Die Einträge lassen sich filtern und als CSV exportieren.
Auch Änderungen bleiben zentral. Stellt ein Administrator ein Werkzeug von „Mit Nachfrage“ auf „Erlaubt“, gilt das ab diesem Moment für jeden Aufrufer. Kein Agent muss neu konfiguriert werden, kein Workflow angefasst.
Was Sie daraus mitnehmen können
Unabhängig davon, welche Plattform Sie einsetzen, lässt sich aus dieser Architektur etwas ableiten. Vier Prüffragen haben sich in unseren Gesprächen bewährt:
- Zählen Sie Werkzeuge, nicht Apps. „Wir haben das Postfach angebunden“ sagt nichts darüber, ob die KI senden kann. Erst die Liste der einzelnen Werkzeuge macht das Risiko sichtbar und verhandelbar.
- Trennen Sie Lesen und Schreiben. Die beiden Klassen brauchen unterschiedliche Regeln. Wer sie gleich behandelt, ist entweder zu streng für die Recherche oder zu locker für den Versand.
- Bevorzugen Sie die Nachfrage vor der Sperre. Eine Genehmigung im konkreten Fall erhält die Fähigkeit und erzeugt zugleich einen Beleg. Eine Pauschalsperre erzeugt vor allem Umgehungen.
- Fragen Sie nach dem Durchsetzungspunkt. Gilt dieselbe Regel im Chat, im Agenten und im Workflow? Nennt die Antwort mehrere Konfigurationsorte, existieren mehrere Regelwerke, und eines davon wird irgendwann vergessen.
Mehr als 300 Werkzeuge klingen nach einem Kontrollproblem. Mit einer Richtlinie pro Werkzeug, durchgesetzt an einer Stelle, werden daraus drei Zahlen, die jeder Administrator auf einen Blick lesen kann. In unserer Umgebung stehen sie heute bei 290, 32 und 0.
Thero live sehen
Buchen Sie eine kurze Demo. Sie sprechen direkt mit dem Gründerteam.