Warum ein KI-Agent nicht alles dürfen sollte

Warum gibt man einem KI-Agenten am besten nicht alle Rechte?

Die naheliegende Idee, wenn man einen KI-Assistenten baut, ist ein Alleskönner. Ein Agent, der Zugriff auf alle Daten und alle Werkzeuge hat und jede Aufgabe übernimmt. Klingt mächtig. In der Praxis wird genau dieser Agent schlechter, nicht besser.

Der Grund ist simpel und gilt für Menschen wie für Maschinen. Wer alles darf, entscheidet unschärfer. Ein Modell mit fünfzig Werkzeugen im Zugriff muss bei jeder Anfrage erst herausfinden, welche fünf davon jetzt zählen. Ein Modell mit genau den Werkzeugen für seine Aufgabe trifft die Entscheidung sofort und richtig.

Dazu kommt die Sicherheitsseite. Ein Agent, der alles darf, kann auch alles kaputt machen, wenn er sich vertut. Und Agenten vertun sich. Sie interpretieren eine Anweisung falsch, sie ziehen einen Schluss, den du nicht gemeint hast. Je enger seine Rechte, desto kleiner der mögliche Schaden.

Beide Argumente, das Qualitäts- und das Sicherheitsargument, zeigen in dieselbe Richtung: enge Rechte. In der Softwarearchitektur heißt dieses Prinzip Least Privilege, und es ist der Grund, warum ich den KI-Assistenten in meiner eigenen Plattform Flowti nicht als einen Agenten baue, sondern als ein kleines Team.

Ein Dirigent und drei Spezialisten

Flowti ist meine Plattform für Zeiterfassung, Kundenverwaltung und Projekte, inzwischen öffentlich verfügbar und von mir selbst täglich genutzt. Die KI darin ist als Kollegium aufgebaut, also als kleine Gruppe benannter Kollegen mit klaren Zuständigkeiten.

Der Nutzer redet immer nur mit einem: mit Flowti, dem Dirigenten. Flowti nimmt die Anfrage entgegen, versteht, worum es geht, und gibt sie an den passenden Spezialisten weiter. Dann fügt er die Antwort zu einer zusammen. Für den Nutzer fühlt es sich an wie ein Ansprechpartner, obwohl im Hintergrund mehrere Rollen zusammenarbeiten.

Hinter dem Dirigenten stehen drei Spezialisten:

Timo kümmert sich um Zeit und Abrechnung. Er sortiert erfasste Aktivität in Zeiteinträge, findet vergessene abrechenbare Stunden und bereitet Reports vor.
Kira ist für Kunden und Beziehungen zuständig. Sie pflegt Kontakte, hält fest, wann du zuletzt mit wem gesprochen hast, und bereitet ein Briefing vor, bevor du in ein Kundengespräch gehst.
Vince hält die Akquise wach. Er stupst Deals an, die zu versanden drohen, und entwirft ein Angebots-Gerüst, das du dann fertig machst.

Die Namen sind bewusst gewählt. Eine Persona ist keine Spielerei, sie ist Benutzerschnittstelle. „Lass Kira mal auf den Kunden schauen" ist klarer und menschlicher als „starte die CRM-Abfrage-Routine". Aber jede Persona muss sich ihren Namen verdienen, durch echte, eng geschnittene Zuständigkeit. Sonst ist es doch nur ein Alleskönner mit Verkleidung.

Warum enge Rechte die Qualität heben

Der Unterschied wird konkret, wenn man auf die Werkzeuge schaut, die jeder Kollege bekommt.

Timo darf Zeiteinträge schreiben, Timer starten und stoppen, Work Sessions zuordnen. Er darf nicht ins CRM schreiben. Kira darf Kontakte und Aktivitäten pflegen, aber keine Zeiten manipulieren. Vince darf an der Vertriebs-Pipeline arbeiten, aber keine Rechnungen anfassen.

Das ist keine Bürokratie, das ist der Grund, warum die Vorschläge besser werden. Wenn Timo eine Stunde einordnen soll, arbeitet er mit einem Werkzeugkasten, in dem nur Zeit-Werkzeuge liegen. Er kann gar nicht auf die Idee kommen, stattdessen einen Kontakt anzulegen. Sein Kontext ist sauber, seine Entscheidung eindeutig.

Ein einzelner Agent mit allen Werkzeugen müsste bei jeder Zeitbuchung die Kundenverwaltung, die Deal-Pipeline und die Aufgabenliste mitdenken, obwohl nichts davon zur Sache gehört. Dieser Ballast macht die Antworten schlechter. Weniger Rechte bedeutet hier direkt mehr Qualität.

Die wichtigste Grenze: vorbereiten ja, senden nie

Es gibt eine Regel im Kollegium, die über allem steht und die technisch erzwungen ist: Kein Kollege kommuniziert je im Namen des Nutzers nach außen.

Kira bereitet ein Gesprächs-Briefing vor, aber sie schreibt keine Mail an den Kunden. Vince entwirft ein Angebots-Gerüst, aber er verschickt es nicht. Die Vorarbeit ja, das Senden nie.

Das ist keine Einstellung, die man versehentlich umlegen kann. Es gibt schlicht kein Werkzeug, das eine Nachricht an einen Kunden verschickt. Die Fähigkeit existiert nicht, also kann sie auch nicht missbraucht werden, weder durch einen Fehler des Modells noch durch eine geschickt formulierte Anfrage.

Dahinter steckt eine Haltung, die ich für richtig halte: Die stumpfe Verwaltungsarbeit nimmt dir die KI ab. Die Beziehung zum Kunden bleibt bei dir. Eine KI, die ungefragt in deinem Namen an deine Kunden schreibt, ist kein Fortschritt, sondern ein Risiko für genau das, worauf dein Geschäft steht.

Wie funktioniert das technisch?

Jetzt wird es etwas technischer. Wer die Architektur-Idee mitgenommen hat, kann direkt zum Fazit springen.

Das Kollegium ist als datengetriebenes Register gebaut. Jeder Kollege ist ein Eintrag mit Name, Rolle, Persona und, entscheidend, seinem erlaubten Werkzeug-Set. Ein neuer Kollege ist ein neuer Eintrag, kein Umbau des Agenten.

Beim Ausbaustand bin ich ehrlich, weil das zur Sache gehört. Live ist Stufe eins: Ein Agent tritt als Flowti auf, und das Register erzeugt den Abschnitt im System-Prompt, der ihm sagt, welche Spezialisten es gibt und welche Werkzeuge zu welcher Rolle gehören. Nach außen schon ein Ansprechpartner, innen bewusst einfach gehalten.

Stufe zwei, bei der jeder Spezialist ein eigener Agent mit eigenem, technisch abgeschottetem Werkzeug-Set wird, ist vorbereitet. Genau das Werkzeug-Feld pro Kollege ist die Grundlage dafür. Gebaut ist sie noch nicht. Das ist Absicht. Die volle Agenten-Hierarchie am ersten Tag zu bauen bringt mehr Risiko als Nutzen. Erst das Fundament tragfähig machen, dann die Kollegen echt aufteilen.

Sicherheit steckt in zwei Schichten, die bei jedem Werkzeug-Aufruf mitlaufen. Eine Prüfung stellt sicher, dass ein Aufruf den Mandanten nicht verlassen kann. Der Agent liefert nie selbst die Kennung des Mandanten mit, die kommt aus dem gesicherten Kontext. Eine zweite Schicht protokolliert jeden Aufruf für die Nachvollziehbarkeit, inklusive welcher Kollege was getan hat. Der Agent bekommt außerdem nie direkten Datenbankzugriff, er spricht nur die abgesicherte Schnittstelle mit dem Token des Nutzers.

Und noch ein Prinzip, das oft untergeht: Nicht alles braucht einen Agenten. Wo ein Ablauf immer gleich läuft, baue ich ihn als festen, deterministischen Prozess, nicht als KI-Entscheidung. Ein Agent gehört dorthin, wo echtes Urteilsvermögen nötig ist. Für Schema-F ist er das falsche, teurere und unzuverlässigere Werkzeug.

Was das für deine eigenen Projekte heißt

Die Frage ist nie, wie mächtig du einen KI-Agenten machen kannst. Die Frage ist, wie eng du seine Rechte schneiden kannst, ohne dass er seine Aufgabe nicht mehr erfüllt.

Wenn dir jemand einen KI-Agenten anbietet, der Zugriff auf alle deine Systeme bekommt und alles kann, ist das kein Zeichen von Stärke. Es ist ein Zeichen fehlender Architektur. Der bessere Bauplan ist ein kleines Team eng zugeschnittener Rollen mit einem Koordinator davor. Frag konkret nach: Welche Rechte hat der Agent, was kann er nicht anfassen, und gibt es Aktionen, die er technisch gar nicht ausführen kann, egal wie man ihn anspricht.

Diese Antworten sagen dir mehr über die Reife einer KI-Lösung als jede Liste beeindruckender Fähigkeiten.

Fazit

Ein guter KI-Assistent ist kein Alleskönner. Er ist ein gut organisiertes Team. Enge Rechte machen die Ergebnisse besser, weil der Kontext sauber bleibt, und sie machen das System sicherer, weil ein Fehler nur begrenzten Schaden anrichten kann. Beides zugleich.

Bei Flowti heißt das: ein Dirigent, drei Spezialisten, jeder in seiner Spur, und eine harte Grenze, über die kein Kollege geht. Die Verwaltungsarbeit übernimmt die KI, die Beziehung zum Kunden bleibt beim Menschen. Genau so baue ich KI-Agenten, die man in echte Abläufe lassen kann.