Tool Calling erklärt: Wie KI-Agenten Werkzeuge und APIs aufrufen — und wo die Kontrolle bleiben muss

Wie Tool Calling technisch abläuft

Ein KI-Agent bekommt eine Liste verfügbarer Werkzeuge mit Namen, Beschreibung und erwarteten Parametern. Erkennt das Modell während der Bearbeitung einer Aufgabe, dass ein Werkzeug benötigt wird, erzeugt es einen strukturierten Aufrufvorschlag — etwa „Rechnung Nummer 8842 stornieren" mit den passenden Parametern. Dieser Vorschlag geht zurück an die Anwendung, die ihn ausführt (oder nicht) und das Ergebnis wieder an das Modell zurückgibt. Anbieter setzen dieses Grundmuster unterschiedlich um; die APIs sind ähnlich, aber nicht vollständig identisch.

Der zentrale Mythos: Vorschlag ist nicht gleich Befehl

Ein weit verbreiteter, aber ausdrücklich falscher Mythos lautet, ein Werkzeugaufruf des Modells sei bereits eine autorisierte Aktion. Tatsächlich ist er nur ein Vorschlag. Die Anwendung muss vor der tatsächlichen Ausführung prüfen: Ist dieses Werkzeug für diesen Nutzer in diesem Kontext überhaupt freigegeben? Sind die übergebenen Parameter plausibel und im erlaubten Format? Verstößt die Aktion gegen eine Geschäftsregel — etwa eine Stornierung nach Ablauf der Frist? Erst wenn all das positiv geprüft ist, darf die reale Operation stattfinden.

Die nötigen Kontrollen im Überblick

Für einen produktiv eingesetzten KI-Agenten mit Werkzeugzugriff gehören folgende Kontrollen zur Grundausstattung:

• Allowlist: Nur explizit freigegebene Werkzeuge stehen überhaupt zur Verfügung — keine offene, unbegrenzte Werkzeugliste
• Festes Parameterformat (JSON Schema): Eingaben werden gegen ein definiertes Schema geprüft, bevor sie verarbeitet werden
• Autorisierungsprüfung: Die tatsächlichen Rechte des anfragenden Nutzers werden bei jedem Aufruf erneut geprüft, nicht nur beim Login
• Testlauf ohne echte Wirkung (Dry-Run): Bei kritischen Aktionen zeigt ein Testlauf, was passieren würde, bevor es tatsächlich passiert
• Menschliche Freigabe bei kritischen Schritten: Irreversible oder folgenreiche Aktionen bekommen eine echte Freigabestufe, nicht nur eine Protokollzeile
• Bereinigung der Ausgabe (Output-Sanitization): Ergebnisse aus Werkzeugaufrufen werden geprüft, bevor sie weiterverarbeitet oder angezeigt werden

Warum die Werkzeugbeschreibung selbst zum Risiko wird

Nicht nur der Aufruf, auch die Beschreibung eines Werkzeugs beeinflusst das Verhalten des Modells und die Angriffsfläche. Mehrdeutige oder zu breit gefasste Werkzeugbeschreibungen können zu Fehlaufrufen führen oder die Wirkung eines Prompt-Injection-Angriffs verstärken. Werkzeuge, die schreibend auf Daten zugreifen — also etwas verändern, löschen oder auslösen —, sollten deshalb bewusst klein, eindeutig benannt und in ihrer Wirkung begrenzt gehalten werden, statt ein einziges mächtiges Werkzeug mit vielen Möglichkeiten bereitzustellen.

Autonomie in Stufen statt auf einen Schlag: Read, Propose, Execute

Für risikoreichere Werkzeuge hat sich ein dreistufiges Muster bewährt, das Autonomie graduell statt binär gestaltet: Ein "Read"-Schritt liest ausschließlich autorisierte Daten. Ein "Propose"-Schritt erzeugt daraus einen strukturierten Änderungsvorschlag, ohne ihn bereits umzusetzen. Ein "Execute"-Schritt führt die Änderung erst nach Prüfung tatsächlich aus. Die passende Kontrolltiefe richtet sich nach der Wirkung:

• Niedriges Risiko, reversibel (z. B. freie Kalenderzeiten lesen): Lesezugriff, Ratenbegrenzung, Protokollierung reichen.
• Mittleres Risiko, intern (z. B. eine CRM-Notiz als Entwurf anlegen): zusätzlich Schema- und Objektprüfung sowie eine Rücknahmemöglichkeit.
• Hohes Risiko, extern (z. B. eine E-Mail versenden oder eine Bestellung auslösen): explizite Bestätigung, Idempotenz und Betrags- oder Empfängerlimits.
• Sehr hohes Risiko, irreversibel (z. B. Löschung, Zahlung, Berechtigungsänderung): kein autonomer Aufruf, sondern starke erneute Authentifizierung und ein Vier-Augen-Prinzip.

Was Tool Calling nicht garantiert

Ein strukturiertes Ausgabeformat (Structured Output) sorgt dafür, dass ein Aufruf formal korrekt aufgebaut ist — es garantiert nicht, dass die darin enthaltenen Angaben inhaltlich richtig sind. Ein Modell kann ein technisch valides, aber inhaltlich erfundenes Argument liefern. Formkonformität ersetzt deshalb keine inhaltliche Plausibilitätsprüfung durch die Anwendung.

Was das für den Unternehmenseinsatz bedeutet

Wer einen KI-Agenten mit Zugriff auf reale Systeme plant, sollte die Kontrollarchitektur vor der Funktionalität entwerfen: Welche Werkzeuge sind überhaupt nötig? Welche davon dürfen ohne Rückfrage ausgeführt werden, welche brauchen eine menschliche Freigabe? Ein Agent, der theoretisch alles kann, aber praktisch jede Aktion ungeprüft ausführt, ist kein Fortschritt gegenüber einem klar begrenzten Werkzeugkatalog mit sauberer Autorisierung.