Artificial Intelligence
Tool Use bei KI-Agenten: Wie KI auf externe Systeme zugreift
Tool Use ist das technische Fundament autonomer KI-Agenten. Wie greifen Agenten auf APIs, CRM und Datenbanken zu? Definition, Funktionsweise & Praxisbeispiele.
Ein KI-Agent, der nur aus seinem Trainingswissen schöpft, ist wie ein Kundenservice-Mitarbeiter ohne Bildschirm: Er kann reden, aber nicht nachschauen, nicht bestätigen, nicht handeln. Tool Use ist die Fähigkeit, die diesen Unterschied überbrückt und die aus einem Sprachmodell einen echten, handlungsfähigen Agenten macht.
In diesem Artikel erfahren Sie, was Tool Use technisch bedeutet, wie Function Calling funktioniert, welche Tools im Kundenservice den größten Hebel haben und wie Sie Tool Use sicher und DSGVO-konform einsetzen.
Was ist Tool Use?
Tool Use bezeichnet die Fähigkeit eines KI-Agenten, zur Laufzeit definierte externe Funktionen, sogenannte Tools, aufzurufen, um Informationen abzurufen oder Aktionen auszuführen. Ein Tool kann eine einfache API-Abfrage sein (“Gib mir den aktuellen Bestellstatus für Bestellnummer #49812”), eine Datenbankoperation (“Aktualisiere die Lieferadresse des Kunden”) oder eine komplexere Systemaktion (“Erstelle ein Retourenlabel und sende es per E-Mail”).
Ohne Tool Use ist ein KI-Agent auf das beschränkt, was er beim Training gelernt hat – und das ist immer ein Snapshot der Vergangenheit. Mit Tool Use wird der Agent zur Gegenwart verbunden: Er kennt den heutigen Lagerstand, den aktuellen Ticketstatus und die Öffnungszeiten von morgen.
Der Begriff wird häufig synonym mit Function Calling verwendet – streng genommen ist Function Calling die konkrete Implementierungsmethode, während Tool Use das übergeordnete Konzept beschreibt. Technisch basiert beides auf Large Language Models (LLMs), die gelernt haben, strukturierte Funktionsaufrufe zu generieren. In der Praxis meinen beide dasselbe: das kontrollierte Aufrufen externer Funktionen durch das LLM.
Wie funktioniert Function Calling technisch?
Function Calling läuft in einem klar definierten Ablauf ab, den jeder Entscheider verstehen sollte, unabhängig vom technischen Hintergrund:
| Schritt | Was passiert | Beispiel |
|---|---|---|
| 1. Tool-Definition | Der Entwickler beschreibt der KI, welche Tools verfügbar sind – Name, Zweck, Parameter | get_order_status(order_id: string) |
| 2. Intent-Erkennung | Das LLM analysiert die Anfrage und entscheidet, ob und welches Tool benötigt wird | Kunde fragt nach Bestellung → Tool get_order_status passt |
| 3. Parameter-Extraktion | Das LLM extrahiert die nötigen Parameter aus dem Gesprächskontext | Bestellnummer #49812 aus der Nachricht |
| 4. Tool-Aufruf | Das System ruft die externe Funktion mit den extrahierten Parametern auf | API-Request an das Order-Management-System |
| 5. Ergebnis-Integration | Das LLM empfängt das Tool-Ergebnis und formuliert eine natürlichsprachliche Antwort | „Ihre Bestellung wird morgen zwischen 10–12 Uhr geliefert.” |
Der entscheidende Punkt: Das LLM entscheidet selbst, ob ein Tool-Aufruf nötig ist und mit welchen Parametern. Es muss nicht für jede Kombination explizit trainiert werden, es generalisiert aus den Tool-Beschreibungen. Das macht moderne KI-Agenten so viel flexibler als regelbasierte Automationen.
Paralleles Tool Use
Moderne LLMs wie GPT-4o oder Claude Sonnet können mehrere Tools gleichzeitig aufrufen, wenn die Ergebnisse voneinander unabhängig sind. Ein Agent, der gleichzeitig den Bestellstatus und die Kundenstammdaten und offene Reklamationen abfragt, antwortet deutlich schneller als einer, der diese Schritte sequenziell abarbeitet. Das ist auch die technische Grundlage für Multi-Agent Systeme: Mehrere Agenten rufen parallel unterschiedliche Tools auf und teilen ihre Ergebnisse.
Die 5 wichtigsten Tool-Kategorien im Kundenservice
Read-Tools sind die häufigste Kategorie. Sie fragen externe Systeme ab, ohne Daten zu verändern. Damit sind sie risikoarm und einfach freizugeben.
Typische Read-Tools im Kundenservice sind Bestellstatus-Abfragen (Order-Management-API), Kundenstammdaten (CRM), Tracking-Informationen (Carrier-API), Produktverfügbarkeit (ERP/WMS) und FAQ-Abfragen aus der Wissensdatenbank. Allein durch diese Kategorie lassen sich im E-Commerce erfahrungsgemäß 30–40 % des Ticketvolumens vollständig automatisieren (OMQ-Kundenbenchmark).
Write-Tools führen Aktionen mit Systemwirkung durch – Adressänderung im CRM, Ticket-Erstellung in Zendesk, Retourenlabel-Generierung. Sie erfordern präzisere Freigaberegeln und sind typischerweise der Bereich, in dem Human-in-the-Loop- und Vier-Augen-Prinzip-Mechanismen greifen: Änderungen über einem definierten Schwellenwert (finanziell, vertragsrelevant) werden vor der Ausführung zur menschlichen Freigabe vorgelegt.
Search-Tools durchsuchen strukturierte und unstrukturierte Wissensquellen – interne Dokumente, FAQ-Datenbanken, Support-Archive, Produkthandbücher. Sie sind das Rückgrat der Antwortqualität: Ein Agent, der in Echtzeit die passende Wissensseite findet, antwortet konsistenter und genauer als einer, der ausschließlich auf sein Trainings-Snapshot-Wissen vertraut.
OMQ nutzt für Search-Tools eine zentrale, kanalübergreifende Wissensdatenbank, die alle Produkte gleichzeitig speist – Chatbot, E-Mail-Bot, Help Center und Kontaktformular greifen auf dieselbe Quelle zu. Keine parallele Pflege, keine inhaltlichen Widersprüche zwischen Kanälen.
Communication-Tools lösen Kommunikationsaktionen aus: Bestätigungsmail versenden, SMS-Benachrichtigung triggern, Slack-Nachricht an einen internen Channel senden, Kalendereinladung erstellen. Sie schließen Prozessschleifen ab – ein Workflow, der die Adresse geändert hat, bestätigt das automatisch per E-Mail.
Im OMQ-Kundenbenchmark reduzieren Communication-Tools die Zahl der Folgenachrichten von Kunden (z. B. „Wurde meine Änderung übernommen?”) um durchschnittlich 25 % – weil die proaktive Bestätigung die Unsicherheit des Kunden behebt, bevor sie entsteht.
Calculation-Tools führen definierte Berechnungslogiken aus – Versandkostenberechnung, Rückerstattungsbetrag bei Teillieferung, Rabattberechnung auf Basis der Kundenkategorie. Sie sind besonders wichtig, weil LLMs bei arithmetischen Aufgaben fehleranfällig sind: Statt das Modell selbst rechnen zu lassen, übergibt ein gutes System die Rechenlogik an ein determiniertes Tool und gibt nur das Ergebnis zurück ans LLM.
Tool Use vs. RAG: Was ist der Unterschied?
In Gesprächen über KI-Architekturen werden Tool Use und RAG (Retrieval-Augmented Generation) oft verwechselt oder gleichgesetzt. Es gibt wichtige Unterschiede:
| Merkmal | Tool Use / Function Calling | RAG (Retrieval-Augmented Generation) |
|---|---|---|
| Was wird abgerufen | Strukturierte Daten, API-Antworten, Systemaktionen | Unstrukturierte Textdokumente, FAQ-Einträge |
| Trigger | LLM entscheidet aktiv, welches Tool gerufen wird | Automatische Ähnlichkeitssuche bei jeder Anfrage |
| Aktionsfähigkeit | Ja – kann Daten schreiben, E-Mails senden, etc. | Nein – nur Lesezugriff auf Texte |
| Antworttyp | Strukturierter Datensatz (JSON, API-Response) | Relevante Textpassagen |
| Typischer Einsatz | Bestellstatus, Adressänderung, Ticketerstellung | FAQ-Beantwortung, Produktbeschreibungen |
In der Praxis sind Tool Use und RAG komplementär: Ein gut konfigurierter KI-Agent nutzt RAG, um die passende Wissensseite zu finden, und Tool Use, um darüber hinaus in Systemen zu handeln. OMQ kombiniert beide Ansätze in einer einheitlichen Architektur.
Sicherheit und DSGVO bei Tool Use
Tool Use bedeutet, dass ein KI-Agent auf echte Unternehmens- und Kundendaten zugreift. Das erfordert klare Sicherheitsarchitektur – keine Option, sondern Voraussetzung für den Produktivbetrieb.
Minimal Privilege Prinzip: Jeder Agent erhält nur Zugriff auf die Tools, die er für seine definierten Aufgaben braucht. Ein FAQ-Agent hat keinen Zugriff auf Zahlungsdaten; ein Retouren-Agent hat keine Schreibrechte im Abrechnungssystem. OMQ implementiert Tool-Zugriffsrechte granular pro Agent-Konfiguration.
Vollständiges Audit-Logging: Jeder Tool-Call wird mit Zeitstempel, Agent-ID, aufgerufenem Tool, übergebenen Parametern und zurückgegebenem Ergebnis protokolliert. Das erfüllt die Transparenz- und Nachvollziehbarkeitsanforderungen des EU AI Acts und ermöglicht forensische Analysen im Fehlerfall.
Keine Datenexfiltration: Tool-Ergebnisse werden ausschließlich zur Antwortgenerierung innerhalb der Konversation genutzt – sie werden weder extern gespeichert noch zu Trainingszwecken verwendet. Bei OMQ fließen keine Kundendaten in externe Modelltrainings.
EU-Server-Pflicht: Alle API-Aufrufe laufen über EU-basierte Infrastruktur. Das stellt sicher, dass Kundendaten zu keinem Zeitpunkt in Drittstaaten übertragen werden – eine Grundvoraussetzung für DSGVO-konformes Tool Use.
ROI-Betrachtung: Was Tool Use konkret bringt
Der Business Case für Tool Use ist direkt: Jeder Tool-Call, der eine manuelle Systemabfrage durch einen Mitarbeiter ersetzt, spart Zeit und damit Kosten.
| Anwendungsfall | Manuelle Bearbeitungszeit | Mit Tool Use | Einsparung |
|---|---|---|---|
| Bestellstatus-Abfrage | 3–4 Min. (Login, Suche, Antwort) | < 5 Sek. | ~97 % |
| Adressänderung | 5–8 Min. (CRM-Update, Bestätigung) | < 30 Sek. | ~90 % |
| Retouren-Berechtigung prüfen | 4–6 Min. (3 Systemzugriffe) | < 10 Sek. | ~94 % |
| Terminbuchung | 3–5 Min. (Kalender, Einladung) | < 20 Sek. | ~92 % |
Für ein Unternehmen mit 4.000 monatlichen Anfragen in diesen Kategorien ergibt sich bei einer durchschnittlichen manuellen Bearbeitungszeit von 5 Minuten und einem Kostensatz von 0,50 €/Min. eine monatliche Einsparung von rund 10.000 € – allein durch Tool Use, ohne weitere Automatisierungsebenen.
Tool Use mit OMQ
OMQ ist als Tool-Use-fähige Plattform konzipiert: Alle Produkte können über definierte Schnittstellen auf externe Systeme zugreifen – ohne individuelle Entwicklungsprojekte für jede Integration.
| Produkt | Tool-Use-Funktion |
|---|---|
| OMQ Chatbot | Ruft CRM, Order-Management, Carrier-APIs und Wissensdatenbank in Echtzeit auf – direkt im Live-Chat |
| OMQ Reply | Zieht Bestelldaten, Kundenstatus und relevante Wissenseinträge für die E-Mail-Antwortgenerierung |
| OMQ Assist | Stellt Agenten sofort alle relevanten Tool-Ergebnisse bereit – als strukturiertes Briefing auf dem Screen |
| OMQ Contact | Enriches Kontaktformular-Einsendungen mit CRM-Daten vor der Weiterleitung |
| OMQ Help | Nutzt Search-Tools, um Kunden im Self-Service die präziseste Antwort aus der Wissensdatenbank zu liefern |
Alle Produkte greifen auf dieselbe zentrale Wissensdatenbank zu – Tool-Konfigurationen werden einmal angelegt und kanalübergreifend genutzt. Das reduziert den Wartungsaufwand erheblich und verhindert inhaltliche Inkonsistenzen zwischen den Kanälen.
Fazit
Tool Use ist nicht ein Feature unter vielen – es ist die Eigenschaft, die den Unterschied zwischen einem intelligenten Gesprächspartner und einem echten digitalen Mitarbeiter ausmacht. Erst wenn ein KI-Agent in Echtzeit auf Bestellsysteme, CRM und APIs zugreift, wird Automatisierung greifbar: nicht als Antwortsimulation, sondern als tatsächliche Handlung mit Systemwirkung.
Für Unternehmen bedeutet das: Der Aufbau einer soliden Tool-Architektur – mit klaren Zugriffsrechten, vollständigem Logging und EU-konformer Infrastruktur – ist die Investition, die alle nachgelagerten KI-Automatisierungen erst skalierbar macht. Wer hier sauber aufbaut, hat die Basis für Multi-Agent Systeme, KI-Workflows und Human-in-the-Loop-Architekturen bereits gelegt. Mehr zu DSGVO-konformem KI-Einsatz im Kundenservice: DSGVO-konforme KI-Antworten.
