KI-Agent vs. Chatbot: der Unterschied zwischen Antworten und Handeln

Beim Vergleich KI-Agent vs. Chatbot zählt vor allem, ob eine Software nur antwortet oder in Ihren Systemen handelt. Ein Chatbot beantwortet Fragen in einem Dialog, sobald ein Mensch schreibt, und sein Ergebnis ist Text. Ein KI-Agent verfolgt ein Ziel, ruft dafür Werkzeuge und Schnittstellen auf und ändert Daten in Systemen wie ERP, CRM oder Ticketsystem.

Daraus folgen drei praktische Unterschiede. Ein Agent startet oft durch ein Ereignis, etwa eine neue E-Mail im Serviceeingang, und nicht durch eine Frage. Er braucht eigene Rechte in den Systemen, in denen er arbeitet. Und weil seine Aktionen Folgen haben, braucht jede Aktion eine Regel, wer sie verantwortet und wer sie freigibt.

Beide können auf demselben Sprachmodell laufen. Der Unterschied liegt in dem, was um das Modell herum gebaut ist, also in Auslösern, Werkzeugen, Rechten und Kontrollen.

Das Sprachmodell ist das gemeinsame Bauteil. Chatbot, Copilot, KI-Agent und agentischer Workflow unterscheiden sich darin, wer sie auslöst, worauf sie zugreifen und was sie verändern dürfen. Ein KI-Agent ist deshalb kein besseres Sprachmodell, sondern Software, die ein Modell mit Werkzeugen, Rechten und einer Schleife aus Planen, Handeln und Prüfen verbindet.

Beim Vergleich KI-Agent vs. Assistent verläuft die Grenze beim Handeln. Der Assistent schlägt vor, und der Mensch handelt; der Agent handelt selbst.

Vergleichen Sie konkrete Produkte anhand ihrer Zugriffsrechte und Aktionen. Eine reine Dialoganwendung liefert Text. Ein Agent kann zusätzlich Datensätze anlegen, ändern oder Nachrichten versenden. Manche Chatbots und Copilot-Produkte enthalten solche Agentenfunktionen.

Mit den Funktionen ändern sich die Fehlerfolgen. Ein falscher Text kann vor der Verwendung geprüft werden. Eine falsche Buchung oder bereits versendete Nachricht wirkt dagegen unmittelbar. Für jede wirksame Aktion braucht es deshalb eine klare Berechtigung und Freigaberegel.

Ein Chatbot ist die richtige Wahl, wenn die Antwort selbst das Ergebnis ist und kein System verändert werden muss. Typische Fälle sind Fragen zu Produkten, Lieferbedingungen oder internen Richtlinien, die sich aus gepflegten Dokumenten beantworten lassen. Dafür braucht es keine Schreibrechte, keine Freigabeschritte und keine Integration ins ERP, und das hält Aufbau und Betrieb günstig.

Ein Assistent oder Copilot passt, wenn die Arbeit von Fall zu Fall verschieden ist und ein Mensch ohnehin entscheidet, etwa bei einem Memo für die Geschäftsführung, einem langen E-Mail-Verlauf oder einer Auswertung in Excel. Er wird meist pro Nutzer lizenziert und braucht kein Integrationsprojekt. Dafür verteilt sich der Nutzen auf viele Einzelne und lässt sich schwer messen.

Ein Agent lohnt sich, wenn dieselbe Art von Fall hunderte Male im Monat auftritt, das Ergebnis in einem führenden System landen muss und jemand im Fachbereich daran gemessen wird. Als Probe genügt der Blick auf das Ende eines Vorgangs. Entsteht oder ändert sich dort ein Datensatz in ERP, CRM oder Ticketsystem, kommt ein Workflow mit Agent in Frage; liest dort ein Mensch einen Text und handelt selbst, reicht ein Assistent.

Dieselbe Reihenfolge empfiehlt der Modellanbieter Anthropic, der in seinem Leitfaden zum Bau von Agenten rät, mit der einfachsten Lösung zu beginnen und Komplexität nur hinzuzufügen, wenn sie das Ergebnis nachweislich verbessert.

„Agent“ ist kein geschützter Begriff, und Anbieter verwenden ihn für sehr verschiedene Dinge. In der Dokumentation zu Microsofts Copilot Studio etwa reicht er von regelbasierten Agenten für strukturierte, wiederholbare Gespräche bis zu Agenten mit eigenem Konto, die proaktiv an Aufgaben arbeiten. Für Ihre Entscheidung zählt deshalb nicht das Etikett, sondern was ein konkretes Setup darf.

Drei Fragen klären das in jedem Anbietergespräch. Lautet die Antwort auf die erste Frage Nein, kaufen Sie einen Chatbot oder Assistenten, gleich wie das Produkt heißt. Lautet sie Ja, entscheiden die zweite und die dritte Antwort, ob das Produkt in einen kontrollierten Workflow passt.

Agenten bringen zwei Risiken mit, die ein Chatbot in dieser Form nicht hat, nämlich Aktionen mit Folgen und Anweisungen, die über eingehende Inhalte eingeschleust werden. Eine falsche Chatantwort lässt sich ignorieren, eine versandte E-Mail, eine gebuchte Gutschrift oder ein geänderter Stammsatz nicht. Die OWASP Top 10 für LLM-Anwendungen führen dieses Risiko als „Excessive Agency“ (LLM06:2025) und nennen drei Ursachen: zu viele Funktionen, zu weite Rechte und zu viel Autonomie.

Das zweite Risiko ist eine Form der Prompt Injection, die in derselben Liste an erster Stelle steht (LLM01:2025). Bei einer indirekten Prompt Injection stecken Anweisungen in externen Inhalten, die das Modell verarbeitet, und für einen Agenten im Serviceeingang ist jede eingehende E-Mail und jeder Anhang ein solcher Inhalt. Das BSI beschreibt in einer Veröffentlichung vom September 2026, wie Angreifer Anweisungen im Fließtext, in Metadaten, in Kommentaren oder in weißer Schrift auf weißem Grund verstecken. Es erinnert daran, dass es schon 2023 auf das Fehlen einer zuverlässigen Gegenmaßnahme hingewiesen hat, die das Problem vollständig beseitigt, und hält fest, dass sich selbst gezielt entwickelte Abwehrmaßnahmen durch angepasste Angriffe umgehen lassen.

Daraus folgt, dass die Grenzen eines Agenten im Zielsystem gezogen werden und nicht im Prompt; auch OWASP empfiehlt, Berechtigungen in den nachgelagerten Systemen durchzusetzen, statt sich auf das Modell zu verlassen. Der Agent erhält nur die Werkzeuge und Rechte, die sein Schritt braucht, und schreibt nur in einen Entwurfsstatus. Jede Aktion mit Wirkung nach außen läuft über eine menschliche Freigabe im Workflow, eingehende Inhalte gelten als Daten und nie als Auftrag, und Fälle mit verdächtigem Inhalt gehen in die Eskalation.

Im Dezember 2025 hat OWASP zusätzlich eine eigene Top 10 für agentische Anwendungen veröffentlicht.

Ein Workflow legt die Schritte vorher fest, ein Agent wählt seine nächsten Schritte selbst. Anthropic beschreibt Workflows als Systeme, in denen Sprachmodelle und Werkzeuge über vordefinierte Codepfade gesteuert werden, und Agenten als Systeme, in denen das Modell seinen Ablauf und den Einsatz der Werkzeuge selbst lenkt. Für wiederkehrende Fälle mit klaren Regeln ist die erste Bauform berechenbarer, für wechselnde Eingänge braucht es das Urteil der zweiten.

Im Betrieb bewährt sich die Kombination aus beidem. Der Prozessrahmen ist fest, und der Agent entscheidet nur innerhalb einzelner Schritte. In der Service-Triage heißt das: Eingang einer Anfrage, Kontext aus CRM, ERP und Dokumentation, Vorschlag einer Antwort mit Quellen, Freigabe durch einen Servicemitarbeiter, Rückschreiben ins Ticketsystem. Der Agent liest in drei Systemen und schreibt nur in eines.

Bevor ein solcher Workflow allein entscheiden darf, läuft er im Schattenbetrieb an echten Fällen. Der Agent entwirft, Menschen entscheiden, und der Vergleich belegt je Kategorie, wo sich Freigaberechte erweitern lassen. Ob ein konkreter Ablauf dafür taugt, zeigen die zehn Fragen im Workflow-Check, und im Workflow Assessment messen wir Volumen, Bearbeitungszeit und Fehlerquote als Basiswert.