KI-Agenten
KI-Agenten brauchen Budget und Grenzen – nicht nur einen Prompt
Die interessante Frage bei einem KI-Agenten ist nicht nur, ob er eine Aufgabe erledigen kann. Sie lautet auch: Was darf passieren, wenn er die Aufgabe falsch versteht? Ein überzeugender Ablauf in einer Vorführung beantwortet das nicht. Sobald ein System Werkzeuge aufrufen, Informationen abrufen oder kostenpflichtige Dienste nutzen darf, wird aus einer Frage der Textqualität eine Frage der betrieblichen Verantwortung. Dafür braucht es mehr als eine sorgfältig formulierte Anweisung.
Der Auftrag ist nicht die Berechtigung
Ein Mensch kann einen Auftrag im Kontext einordnen und bei Unklarheiten nachfragen. Ein automatisierter Ablauf benötigt zusätzlich eine technisch durchgesetzte Grenze. Wenn Sie einem Agenten nur erlaubte Ziele nennen, ihm aber umfassenden Netzwerkzugriff und lesbare Zugangsdaten geben, liegen Absicht und tatsächliche Befugnis auseinander. Diese Lücke bleibt auch bei einem guten Modell bestehen.
In meinem Open-Source-Projekt tentaflake bearbeite ich diese Trennung mit einer NixOS-Vorlage für isoliert betriebene Agenten. Die dokumentierte Ausführung sieht unter anderem Ressourcenbegrenzungen und eingeschränkten Netzwerkzugriff vor. Das Projekt befindet sich noch vor einer stabilen Erstveröffentlichung. Seine Beschreibung ist deshalb kein pauschales Sicherheitsversprechen und ersetzt keine Prüfung der konkret eingesetzten Konfiguration.
Schlüssel gehören nicht automatisch zum Werkzeug
Ein Agent kann eine Leistung nutzen, ohne den dazugehörigen geheimen Schlüssel selbst lesen zu können. Das ist ein wichtiger Unterschied: Wer einen Schlüssel besitzt, kann möglicherweise auch außerhalb des vorgesehenen Arbeitsablaufs handeln. Ein vorgeschalteter Dienst kann dagegen prüfen, welcher Auftrag gerade läuft, welche Funktion erlaubt ist und ob noch ein freigegebenes Budget besteht.
tentaflake sieht vor, Anbieterschlüssel auf dem Host zu halten und verschiedene Kontrollaufgaben getrennt zu behandeln. Für die Beschaffung bedeutet das: Fragen Sie nicht bloß nach einer Liste angebundener Dienste. Lassen Sie sich zeigen, welche Komponente die Befugnis erteilt, welche sie durchsetzt und was bei deren Ausfall geschieht. Eine Beschreibung im Handbuch allein beantwortet diese Betriebsfrage nicht.
Recherche braucht ein eigenes Mandat
In meinem experimentellen Open-Source-Projekt tentaflake-research erhält öffentliche Webrecherche einen eigenen, regelgebundenen Zugangsweg. Der Dienst prüft Auftragszugehörigkeit und Budgets und hält Herkunftsinformationen zu gespeicherten Belegen fest. Der Client benötigt dafür keine eigenen Anbieterschlüssel. Das macht die Rechercheentscheidung expliziter, behauptet aber weder vollständige Isolation noch einen vollständigen Schutz vor manipulativen Quellen.
Auch ein lokales Ausgabenbudget hat Grenzen. Eine intern reservierte Summe ist nicht dasselbe wie eine vom Anbieter erzwungene Kostenobergrenze. Wenn Ihre Freigabe von einer harten Kostengrenze abhängt, müssen Sie beide Ebenen verstehen. Sonst kann eine technisch korrekte Anzeige im eigenen System eine wirtschaftliche Sicherheit suggerieren, die der externe Dienst gar nicht zugesagt hat.
Ein Vertrag ist noch keine laufende Kontrolle
Mein Open-Source-Projekt architecture-kit beschreibt Werkzeugverträge, Anforderungen und Prüfbeispiele für Agentensysteme. Es ist ein Spezifikations- und Verifikationspaket, kein ausgelieferter Agentenbetrieb. Ein gewähltes Profil installiert keinen Dienst und erteilt keine Berechtigung. Diese Unterscheidung ist wichtig, weil sorgfältig ausgearbeitete Unterlagen leicht wie ein bereits vorhandenes Produkt wirken können.
Für eine Freigabe brauchen Sie deshalb eine nachvollziehbare Verbindung zwischen Anforderung, implementierter Kontrolle und beobachtetem Ergebnis. Synthetische Beispiele können die Konsistenz eines Vertrags zeigen. Ob im vorgesehenen Betrieb unerlaubte Verbindungen tatsächlich scheitern, müssen andere Nachweise beantworten. Beides ist sinnvoll; problematisch wird es erst, wenn ein Nachweis für die eine Frage als Antwort auf die andere verkauft wird.
Mit dem Stoppfall beginnen
Ich würde eine Beschaffungsentscheidung nicht bei der schönsten erfolgreichen Aufgabe beginnen, sondern bei einer verweigerten Aktion. Was passiert bei fehlender Freigabe, nicht erreichbarer Kontrolle oder ausgeschöpftem Budget? Eine nachvollziehbare Ablehnung ist oft aussagekräftiger als eine weitere gelungene Vorführung. Sie zeigt, ob die Grenze unabhängig vom guten Willen des Agenten existiert.
Daraus folgt keine Forderung nach vollständiger Automatisierung aller Entscheidungen. Manche Aktionen sollen bewusst eine menschliche Freigabe behalten. Entscheidend ist, dass diese Zuständigkeit vor dem Einsatz feststeht und nicht erst im Zwischenfall ausgehandelt wird. Der Nutzen eines Agenten lässt sich verantwortlicher beurteilen, wenn Auftrag, Befugnis, Kosten und Abnahme nicht in einem einzigen Versprechen verschwinden.
Fragen an Ihr Team oder Ihren Anbieter
- Welche Aktionen und Netzwerkziele kann der Agent tatsächlich erreichen, und welche Komponente begrenzt diesen Zugriff?
- Wo liegen Zugangsdaten, und kann der Agent sie direkt lesen oder nur eine begrenzte Leistung anfordern?
- Welche Kostenbegrenzung erzwingt der Anbieter selbst, und welche existiert nur in Ihrer lokalen Planung?
- Was geschieht, wenn eine Freigabe fehlt, ein Kontrolldienst ausfällt oder das Budget aufgebraucht ist?
- Welche Nachweise stammen aus der vorgesehenen Betriebsumgebung und welche lediglich aus synthetischen Prüfbeispielen?
- Wer verantwortet Änderungen an Berechtigungen und entscheidet über die erneute Freigabe des Systems?