KI-Agent, Chatbot oder klassische Automatisierung?
Die Begriffe klingen ähnlich, lösen aber unterschiedliche Aufgaben. Die richtige Wahl folgt aus Variabilität, Handlungsspielraum und Risiko des Prozesses.
Drei Werkzeuge mit verschiedenen Stärken
Klassische Automatisierung
Regelbasierte Automatisierung arbeitet deterministisch: Wenn ein eindeutig definierter Zustand eintritt, wird eine festgelegte Aktion ausgeführt. Das ist ideal für stabile Datenfelder, Validierungen, Freigaberegeln und wiederholbare Systemschritte. Die Stärke liegt in Vorhersagbarkeit und Prüfbarkeit; die Grenze beginnt bei uneindeutiger Sprache und vielen Formulierungsvarianten.
Chatbot
Ein Chatbot ist zunächst ein Interaktionskanal. Er führt einen Dialog, beantwortet Fragen oder sammelt Informationen. Dahinter kann ein fester Entscheidungsbaum, ein Sprachmodell oder beides stehen. Ein Chatbot muss keine Aktionen in Geschäftssystemen ausführen. Für Informationszugang kann diese klare Begrenzung ein Vorteil sein.
KI-Agent
Ein KI-Agent kombiniert Interpretation mit Werkzeugen und einem Ablauf. Er kann eine Anfrage zerlegen, freigegebenes Wissen abrufen, Systemfunktionen aufrufen und je nach Ergebnis den nächsten Schritt wählen. Dieser Handlungsspielraum erhöht den Nutzen, aber auch die Anforderungen an Berechtigungen, Protokollierung, Tests und menschliche Übergaben.
Entscheidung nicht nach Etikett, sondern nach Aufgabe
| Situation | Passender Ausgangspunkt |
|---|---|
| Strukturierte Eingabe, feste Regeln, hohe Wiederholbarkeit | Klassische Automatisierung |
| Fragen aus einem abgegrenzten Wissensbestand | Chat-/Voice-Oberfläche mit Quellenabruf |
| Variable Anfrage, mehrere mögliche Systemschritte | KI-Agent mit begrenzten Werkzeugen |
| Hoher Schaden bei Fehlentscheidung | Automatisierte Vorbereitung plus menschliche Freigabe |
Wichtig ist die kleinste ausreichende Lösung. Ein Agent sollte keine Freiheit erhalten, die der Prozess nicht benötigt. Umgekehrt scheitert ein starrer Entscheidungsbaum schnell, wenn Kundinnen und Kunden ihr Anliegen in vielen Varianten formulieren.
In der Praxis gewinnt die hybride Architektur
Robuste Systeme kombinieren die drei Ansätze. Ein Sprachmodell erkennt das Anliegen und extrahiert Felder. Regeln prüfen Pflichtangaben, Grenzwerte und Berechtigungen. Eine klassische API führt die Transaktion aus. Bei Unsicherheit wird der Vorgang mit Kontext an einen Menschen übergeben. Dadurch lässt sich jede Komponente nach ihrer Stärke einsetzen.
Der Agent erkennt Produkt und Anliegen. Ein Wissensabruf liefert die freigegebene Antwortbasis. Regeln verhindern Auskünfte außerhalb des Geltungsbereichs. Eine API legt bei Bedarf ein Ticket an. Sensible oder uneindeutige Fälle gehen samt Gesprächszusammenfassung an das Team.
Die Architektur sollte außerdem festlegen, welche Quellen verwendet werden dürfen, welche Aktionen schreibend sind und welche Identitätsprüfung erforderlich ist. „Der Agent kann das“ ist keine ausreichende Berechtigungsentscheidung.
Die Architektur in überprüfbare Schichten zerlegen
Eine klare Schichtung erleichtert Entwicklung und Betrieb. Die Kanalschicht übernimmt Web, Telefon oder interne Oberfläche und macht kenntlich, dass KI beteiligt ist. Die Interpretationsschicht erkennt Anliegen und Felder, verändert aber noch keine Geschäftsdaten. Die Wissensschicht liefert nur freigegebene, versionierte Quellen. Die Werkzeugschicht kapselt erlaubte Systemaktionen mit Validierung. Die Kontrollschicht protokolliert Entscheidungen, begrenzt Zugriffe und löst Übergaben aus.
Diese Trennung erlaubt einen gezielten Test. Ein falsches Anliegen ist ein anderes Problem als eine veraltete Wissensquelle oder ein fehlerhafter API-Aufruf. Wer alles nur als „Antwortqualität“ misst, erkennt die Ursache eines Fehlers nicht und kann Verbesserungen kaum sicher freigeben.
Fünf Prüffragen vor der Auswahl
- Wie stark variieren Sprache und Eingaben?
- Muss das System nur informieren oder auch Daten verändern?
- Welche Fehler sind leicht erkennbar und welche hätten hohe Folgen?
- Welche Regeln müssen immer deterministisch gelten?
- Wann und mit welchem Kontext übernimmt ein Mensch?
Wer diese Fragen sauber beantwortet, erhält keine Modearchitektur, sondern ein nachvollziehbares Systemdesign. Evaluation und Betrieb werden dadurch ebenfalls konkreter: Antwortqualität, Felderkennung, Werkzeugwahl und Übergabe lassen sich getrennt prüfen.
Typische Fehlentscheidungen vermeiden
Ein häufiger Fehler ist, einen Chatbot als bloße Oberfläche zu betrachten und dabei die Qualität der Wissensquellen zu ignorieren. Ein flüssiger Dialog kann eine falsche oder nicht freigegebene Antwort besonders überzeugend wirken lassen. Ein zweites Muster ist der zu frühe Einsatz eines Agenten mit vielen Werkzeugen. Jeder zusätzliche Zugriff vergrößert den Testumfang, die Berechtigungsfläche und die Zahl möglicher Nebenwirkungen. Drittens werden menschliche Übergaben oft nur als Notausgang definiert. Ohne Zuständigkeit, Kontext und erreichbaren Kanal ist die Übergabe jedoch kein funktionierender Prozessschritt.
Auch klassische Automatisierung wird manchmal vorschnell verworfen. Wenn Eingaben bereits strukturiert sind und Regeln stabil bleiben, kann sie günstiger, schneller und nachvollziehbarer sein. KI sollte dort eingesetzt werden, wo sie die unvermeidbare Variabilität von Sprache, Dokumenten oder Kontext sinnvoll verarbeitet.
Eine Auswahl im Workshop vorbereiten
Bringen Sie zehn bis zwanzig anonymisierte oder synthetisch nachgebildete Fälle aus dem echten Ablauf zusammen. Markieren Sie jeweils gewünschtes Ergebnis, benötigte Quellen, erlaubte Aktion, mögliche Folge eines Fehlers und verantwortliche Rolle. Ordnen Sie dann jeden Teilschritt einem Mechanismus zu: feste Regel, KI-Interpretation, Wissensabruf, Systemfunktion oder menschliche Entscheidung. Diese Zuordnung bildet eine verständliche erste Architektur.
Danach lassen sich Akzeptanzkriterien formulieren. Für einen Chatbot kann entscheidend sein, dass jede fachliche Aussage auf einer gültigen Quelle beruht. Für einen Agenten müssen zusätzlich Werkzeugwahl, Parameter, Berechtigung und Nebenwirkungen geprüft werden. Für Regeln zählt, dass sie vollständig versioniert und bei Änderungen des Geschäftsprozesses angepasst werden.
Betrieb und Änderungskontrolle
Nach dem Start sollte jede Komponente einen Eigentümer haben. Fachbereiche verantworten Inhalte und Grenzfälle; IT verantwortet Schnittstellen und Zugriff; die Produktverantwortung koordiniert Evaluation und Releases. Änderungen an Modell, Systemanweisung oder Quellen dürfen nicht stillschweigend die zugesicherte Funktion erweitern. Ein kurzer, reproduzierbarer Regressionstest ist wertvoller als eine große einmalige Demo.
Entscheidung in einem Satz dokumentieren
Schließen Sie die Auswahl mit einer überprüfbaren Begründung ab: „Wir verwenden KI zur Interpretation variabler Eingaben, Regeln für Pflichtprüfungen und eine begrenzte API für die Aktion; uneindeutige Fälle werden mit Kontext übergeben.“ Dieser Satz schafft eine gemeinsame Erwartung für Einkauf, Fachbereich, IT und Datenschutz. Spätere Funktionswünsche lassen sich daran prüfen, statt die Architektur unbemerkt auszuweiten.
Ergänzen Sie, welche Beobachtung die Entscheidung später verändern würde. Werden Eingaben vollständig strukturiert oder bietet das Kernsystem die Funktion künftig selbst, kann eine einfachere Automatisierung die bessere Architektur werden.
Verwandte Lösungen
Quellen
Allgemeine Information, keine Rechtsberatung.