Chatbot oder KI-Agent im Kundenservice: Der praktische Unterschied

„Wir brauchen einen KI-Agenten im Support” ist ein Satz, den ich in Erstgesprächen häufig höre – und der meistens ein anderes Problem meint. Meist geht es um Anfragen, die zu lange liegen bleiben, um Standardfragen, die immer wieder von Menschen beantwortet werden, oder um Tickets, die falsch landen. Für all das reicht in der Regel ein gut angebundener Chatbot mit Zugriff auf die eigene Wissensbasis. Ein autonomer Agent, der Bestellungen ändert oder Rückerstattungen auslöst, ist ein anderes, deutlich größeres Vorhaben – mit anderem Risiko, anderer Prüftiefe und anderen Kosten.

Dieser Artikel richtet sich an Geschäftsführung, Operations, IT und Fachbereich in kleinen und mittleren Unternehmen, die vor der Frage stehen: Chatbot oder Agent – und was davon brauchen wir eigentlich? Er ordnet die Begriffe, zeigt, wer welche Aktionen ausführen darf, und liefert eine Entscheidungsmatrix für die eigene Situation. Grundsätzliches zur Automatisierung von Kundenservice-Prozessen behandelt der Cluster-Artikel Kundenservice automatisieren, hier geht es konkret um die Wahl zwischen den beiden Systemtypen.

Begriffe und Abgrenzung: Was ist ein Chatbot, was ein Agent?

In Marketingtexten werden beide Begriffe oft austauschbar verwendet. Technisch und praktisch ist der Unterschied aber klar:

Ein Chatbot ist ein System, das auf eine Eingabe eine Ausgabe erzeugt – regelbasiert über feste Dialogbäume oder generativ über ein Sprachmodell, das häufig per RAG (Retrieval Augmented Generation) an eure eigenen Dokumente angebunden ist. Die Datenschutzkonferenz beschreibt RAG-Systeme als Kombination aus einem Sprachmodell mit einer eigenen Datenbasis, damit Informationen genutzt werden können, „die (nur) dem Verantwortlichen zur Verfügung stehen und nicht Teil der Trainingsdaten des LLMs waren” – genau das Prinzip hinter unternehmensinternen Support-Chatbots. Der Chatbot antwortet einmal pro Anfrage. Was danach mit der Information passiert, entscheidet weiterhin ein Mensch oder ein separates, regelbasiertes System.

Ein KI-Agent geht einen Schritt weiter: Er verfolgt ein Ziel über mehrere Schritte hinweg, kann dafür Werkzeuge oder Schnittstellen aufrufen, das Ergebnis bewerten und bei Bedarf einen neuen Anlauf nehmen. Zapier beschreibt den Unterschied so: Ein normaler KI-Workflow „kann einen Lead klassifizieren und im CRM protokollieren”, ein agentischer Workflow dagegen „könnte den Lead bewerten, entscheiden, dass er angereichert werden muss, fehlende Daten beschaffen, eine Folge-Ansprache erstellen und den Ansatz anpassen, falls der erste Versuch keine Antwort bekommt.” Übertragen auf den Kundenservice heißt das: Ein Agent kann nicht nur eine Antwort formulieren, sondern zum Beispiel einen Sendungsstatus abfragen, eine Rückerstattung anstoßen oder ein Ticket in mehreren Systemen aktualisieren – vorausgesetzt, er hat dafür die technischen Berechtigungen.

Wichtig für die Abgrenzung ist auch, was RAG-Systeme nicht automatisch lösen. Die DSK weist in einer Fußnote zu den Grenzen der RAG-Methode darauf hin, dass komplexe „Wenn-Dann-Gedankenketten” über mehrere Textabschnitte hinweg oft nicht zuverlässig erfasst werden – und dass „versucht [wird], dieses Problem durch KI-Agenten-Systeme zu lösen, welche ggf. iterativ mehrere Anfragen an den Retriever schicken.” Der Agent ist damit auch technisch die logische Erweiterung, wenn ein einzelner Retrieval-Schritt nicht ausreicht – nicht nur ein Marketingbegriff für einen besseren Chatbot.

Was kann ein Chatbot?

Ein gut gebauter Support-Chatbot mit Wissensanbindung leistet drei Dinge zuverlässig: Er beantwortet wiederkehrende Fragen aus FAQ, Handbüchern oder Produktdokumentation, er sortiert eingehende Anliegen nach Thema oder Dringlichkeit vor, und er übergibt Fälle, die er nicht lösen kann, an Menschen – idealerweise mit Kontext, damit die Übergabe keine Wiederholung für den Kunden bedeutet.

Mit RAG-Anbindung an eure eigenen Dokumente wird die Qualität der Antworten spürbar besser: Die DSK hält fest, dass die RAG-Methode „Halluzinationen reduziert und die Ausgabe unrichtiger […] Daten […] verringert werden” kann – allerdings nur, wenn die Referenzdokumente aktuell, vollständig und gut aufbereitet sind. Ein Chatbot ist also nur so gut wie die Wissensbasis, auf die er zugreift. Veraltete oder lückenhafte Dokumentation produziert veraltete oder lückenhafte Antworten, egal wie gut das zugrunde liegende Sprachmodell ist.

Was ein Chatbot in dieser Ausprägung nicht tut: eigenständig Entscheidungen in euren Systemen treffen. Er liest, er antwortet, er leitet weiter – er schreibt nicht in Bestell-, Zahlungs- oder CRM-Systeme. Diese Grenze ist keine technische Beschränkung, sondern in den meisten seriösen Umsetzungen eine bewusste Design-Entscheidung: Ein System, das nur liest, kann bei einer falschen Antwort im schlimmsten Fall verwirren – nicht versehentlich eine Rückerstattung auslösen.

Was kann ein Agent zusätzlich?

Ein KI-Agent im Kundenservice bekommt zusätzlich zur Sprachfähigkeit Zugriff auf Werkzeuge: Schnittstellen zu Bestellsystem, Versanddienstleister, CRM oder Ticketsystem. Der entscheidende Unterschied ist nicht die Sprachqualität – die ist bei Chatbot und Agent oft identisch, weil beide dasselbe Sprachmodell nutzen können –, sondern die Fähigkeit, mehrschrittig zu handeln: eine Anfrage interpretieren, die passende Aktion auswählen, sie ausführen, das Ergebnis prüfen und gegebenenfalls nachsteuern.

Praktisch heißt das: Ein Agent könnte auf „Wo ist meine Bestellung?” nicht nur mit einer allgemeinen Information antworten, sondern den tatsächlichen Sendungsstatus live abfragen. Er könnte bei einer erkannten Fehllieferung nicht nur einen Vorgang anlegen, sondern – innerhalb definierter Grenzen – direkt eine Rückerstattung oder einen Ersatzversand anstoßen. Das ist der eigentliche Nutzenversprechen von Agenten: weniger Übergaben, kürzere Bearbeitungszeit, weil ein System den ganzen Vorgang statt nur die Auskunft übernimmt.

Der Preis dieser Fähigkeit ist Kontrollverlust an genau den Stellen, an denen vorher ein Mensch geprüft hat. Ein Agent, der falsch entscheidet, tut nicht nur etwas Falsches sagen – er tut etwas Falsches. Das ist der Kern der Risikofrage im nächsten Abschnitt.

Welche Systeme dürfen Aktionen ausführen?

Das ist die Frage, die in der Praxis am häufigsten übersprungen wird – und die zuerst geklärt gehört, bevor irgendein Agent produktiv geht. Das BSI gibt dafür in seinem Management-Blitzlicht zu generativer KI eine klare, technologieunabhängige Leitlinie für Unternehmen, die ein KI-System per Schnittstelle in eigene Anwendungen integrieren, etwa „ChatBots für Kunden”:

• Rollen und Verantwortlichkeiten eindeutig zuweisen – für die Anwendung selbst und für die integrierten KI-Systeme.
• Systeme und Datenbanken auflisten, auf die das KI-System Zugriff hat, und diesen Zugriff auf das Nötige einschränken.
• KI-Ausgaben validieren, bevor sie an Backend-Systeme weitergegeben werden – also nicht direkt vom Sprachmodell in die Zahlungsschnittstelle durchreichen.
• Anwendungen nicht ungeprüft für Geschäftsentscheidungen oder kritische Geschäftsprozesse einsetzen.
• Transparenz herstellen: Systeme und Prozesse, die KI verwenden, kennzeichnen, und Zweck sowie freigegebene Daten dokumentieren.

Übertragen auf Chatbot vs. Agent ergibt sich daraus eine einfache Faustregel: Lesender Zugriff (Wissensdatenbank durchsuchen, Status abfragen) ist mit überschaubarem Aufwand absicherbar. Schreibender Zugriff (Rückerstattung buchen, Bestellung ändern, E-Mail im Namen des Unternehmens versenden) braucht zusätzlich eine Freigabeschwelle: entweder einen Menschen, der die Aktion vor Ausführung bestätigt (Human-in-the-Loop), oder enge, hart codierte Grenzen, innerhalb derer der Agent autonom handeln darf – zum Beispiel „Rückerstattungen bis 30 Euro ohne Rückfrage, alles darüber zur Prüfung”.

Rechtlich kommt eine weitere Ebene hinzu: Der AI Act stuft KI-Systeme nach Risiko ein und verlangt für Systeme mit direktem Nutzerkontakt – also klassische Chatbots – eine Transparenzpflicht: Menschen müssen erkennen können, dass sie mit einer Maschine interagieren. Bei Systemen, die Zugang zu wesentlichen privaten oder öffentlichen Dienstleistungen beeinflussen, ist zudem eine Einstufung als Hochrisiko-System möglich, was deutlich striktere Anforderungen an Risikobewertung, Datenqualität und menschliche Aufsicht auslöst. Ob ein konkretes Agenten-Setup im Kundenservice darunterfällt, hängt vom Einzelfall ab und ist keine Frage, die sich pauschal beantworten lässt (Stand Juli 2026, keine Rechtsberatung) – im Zweifel gehört das vor den produktiven Einsatz auf den Tisch von Datenschutz- und Rechtsberatung, nicht danach.

Wie unterscheiden sich Risiko und Kosten?

Risiko

Der Risikounterschied lässt sich an einer einfachen Frage festmachen: Was ist der größtmögliche Schaden, wenn das System falsch liegt?

Bei einem reinen Auskunfts-Chatbot ist das eine falsche oder unvollständige Antwort – ärgerlich, korrigierbar, meist ohne bleibenden Schaden, sofern ein Mensch bei komplexeren Fällen übernimmt. Bei einem Agenten mit Schreibrechten ist der größtmögliche Schaden eine tatsächlich ausgeführte, falsche Handlung: eine zu Unrecht gebuchte Rückerstattung, eine fälschlich stornierte Bestellung, eine an die falsche Adresse versandte Information. Die DSK benennt dafür grundsätzlich das Problem der KI-Halluzination – plausibel klingende, aber nicht durch die Datenbasis gestützte Ausgaben –, das bei einem rein antwortenden System eine falsche Aussage produziert, bei einem handelnden System aber eine falsche Aktion.

Dazu kommt die Datenschutzdimension: Sobald ein System personenbezogene Kundendaten verarbeitet – und das tun beide Systemtypen im Kundenservice praktisch immer –, gelten die üblichen DSGVO-Anforderungen an Richtigkeit, Zweckbindung und Betroffenenrechte. Ein Agent, der Daten aus mehreren Systemen zusammenführt und darauf basierend handelt, hat tendenziell eine komplexere, schwerer zu dokumentierende Verarbeitungskette als ein Chatbot, der nur aus einer Wissensdatenbank liest.

Kosten

Zu Kosten lässt sich seriös nur mit Bandbreiten und klar benannten Annahmen sprechen – verlässliche, allgemeingültige Zahlen für „einen Chatbot” oder „einen Agenten” gibt es nicht, weil beides je nach Umsetzungstiefe fast beliebig einfach oder aufwändig sein kann. Als grobe Einordnung aus meiner Projekterfahrung, unter der Annahme eines KMU mit bestehender Wissensdokumentation und Standard-Kundenservice-Software:

Aspekt	Chatbot (nur Auskunft)	Agent (mit Aktionsrechten)
Typischer Zugriff	Lesend auf Wissensbasis/FAQ	Lesend + schreibend auf mehrere Fachsysteme
Größtmöglicher Einzelschaden bei Fehler	Falsche Auskunft, korrigierbar	Falsch ausgeführte Aktion, ggf. finanzieller oder rechtlicher Schaden
Prüf-/Freigabeaufwand	Stichprobenkontrolle der Antwortqualität	Freigabeschwellen, Logging jeder Aktion, ggf. Human-in-the-Loop
Integrationsaufwand	Eine Datenquelle (Wissensbasis), ein Kanal	Mehrere Systeme mit Schreibzugriff, Fehlerbehandlung pro Schritt
Realistischer Einstiegspunkt	Meist der erste Schritt	Meist Ausbaustufe nach laufendem Chatbot-Betrieb

Eigene Vergleichsmatrix Philogic Labs, auf Basis von BSI-Empfehlungen zu KI-Schnittstellenintegration und eigener Projekterfahrung. Keine Kostenangaben in Euro, da diese stark von Systemlandschaft und Integrationstiefe abhängen und ohne Analysephase nicht seriös bezifferbar sind.

Grundsätzlich gilt: Der Sprung von „liest nur” zu „darf schreiben” ist der teurere Sprung – nicht wegen der KI-Komponente selbst, sondern wegen des zusätzlichen Aufwands für Berechtigungskonzepte, Validierung, Protokollierung und Freigabeprozesse, den das BSI für integrierte KI-Systeme ausdrücklich fordert. Wer diesen Aufwand einspart, spart nicht wirklich – er verschiebt das Risiko nur unsichtbar in den Betrieb.

Was passt wann?

Als Faustregel aus der Praxis: Ein Chatbot passt, wenn der Engpass Informationsbereitstellung und Vorsortierung ist – viele wiederkehrende Fragen, überlastete Support-Postfächer, lange Wartezeiten auf einfache Auskünfte. Das ist der Fall für den überwiegenden Teil der KMU, die ich in Erstgesprächen treffe.

Ein Agent lohnt sich erst, wenn drei Bedingungen gleichzeitig erfüllt sind: Es gibt einen klar abgegrenzten, wiederkehrenden Prozess mit definierten Handlungsoptionen (nicht „irgendwie den Kunden zufriedenstellen”, sondern „Rückerstattung bis X Euro auslösen”), es gibt technische Schnittstellen zu den betroffenen Systemen, und es gibt eine organisatorische Antwort auf die Frage, wer Freigabeschwellen festlegt und Protokolle prüft. Fehlt eine dieser drei Bedingungen, ist ein Agentenprojekt in aller Regel verfrüht – dann hilft ein besser angebundener Chatbot mehr als ein unausgereifter Agent.

In der Praxis sehe ich fast ausschließlich den Weg Chatbot zuerst, Agent später: Ein Unternehmen bringt zunächst einen Auskunfts-Chatbot mit sauberer Wissensanbindung produktiv, sammelt darüber Erfahrung mit typischen Anfragen und Fehlerbildern, und erweitert dann gezielt einzelne, gut verstandene Vorgänge um Aktionsrechte – nicht das ganze Support-System auf einmal.

Umsetzung: So gehe ich vor

Unabhängig davon, ob am Ende ein Chatbot oder ein Agent steht, empfiehlt sich dieselbe Reihenfolge:

1. Anfragen analysieren. Welche Themen kommen am häufigsten vor, welche sind reine Auskunft, welche erfordern eine echte Handlung in einem System? Ohne diese Aufteilung lässt sich nicht seriös entscheiden, was gebraucht wird.
2. Wissensbasis prüfen und aufräumen. Ein RAG-System ist laut DSK „nur so gut wie die Qualität, Aktualität und Vollständigkeit der verwendeten Referenzdokumente” – veraltete FAQ oder widersprüchliche Dokumente untergraben jede Chatbot-Qualität, bevor das Modell überhaupt eine Rolle spielt.
3. Systeme und Berechtigungen auflisten. Vor jeder Integration: Welche Systeme sollen angebunden werden, wer braucht lesenden, wer schreibenden Zugriff – entsprechend der BSI-Empfehlung, das explizit zu dokumentieren statt implizit zu lassen.
4. Mit lesendem Zugriff starten, Freigabeschwellen für Aktionen definieren. Auch wenn am Ende ein Agent stehen soll: Der produktive Start mit reiner Auskunftsfunktion liefert Erfahrungswerte, bevor Schreibrechte vergeben werden.
5. Prüf- und Eskalationswege festlegen. Wer sieht Protokolle, wer greift bei Fehlern ein, wann übernimmt ein Mensch? Das gehört vor den Livegang geklärt, nicht danach.
6. Klein pilotieren, messen, erst dann ausrollen. Ein Kanal, ein Themenbereich, eine definierte Testphase – bevor der komplette Kundenservice umgestellt wird.

Wer diese Schritte nicht allein durchgehen will: Mein Beratungsangebot beginnt genau bei dieser Analyse, bevor irgendein Tool ausgewählt wird, und ein kostenloses Erstgespräch klärt in 45 Minuten, wo euer Fall in dieser Landkarte steht.

Risiken & Grenzen

Ein paar ehrliche Einschränkungen gehören dazu:

• Kein System ist fehlerfrei. Weder Chatbot noch Agent garantieren korrekte Antworten oder Handlungen. Halluzinationen bleiben laut DSK auch mit RAG-Anbindung ein Restrisiko, das durch Qualität der Referenzdokumente und Systemprompt-Design reduziert, aber nicht vollständig ausgeschlossen werden kann.
• Agenten sind kein Ersatz für ungeklärte Prozesse. Wenn schon der manuelle Prozess unklar oder inkonsistent ist, macht ein Agent das nicht besser, sondern automatisiert die Unklarheit.
• Schnittstellenqualität begrenzt die Umsetzung. Ein Agent kann nur so viel tun, wie die angebundenen Systeme technisch zulassen. Fehlt eine API oder ist sie unzuverlässig, ist die Aktionsfähigkeit von vornherein eingeschränkt.
• Governance ist kein einmaliger Schritt. Berechtigungen, Freigabeschwellen und Protokolle müssen laufend gepflegt werden, besonders wenn neue Systeme angebunden oder bestehende Prozesse geändert werden.
• Rechtliche Einordnung ist einzelfallabhängig. Ob ein konkretes Setup als Hochrisiko-System nach AI Act gilt oder welche DSGVO-Anforderungen im Detail greifen, lässt sich pauschal nicht beantworten (Stand Juli 2026) – das gehört zur Rechtsberatung oder zum Datenschutzbeauftragten, nicht in diesen Artikel.

Was dieser Artikel nicht liefert: eine Garantie für Einsparungen, eine Automatisierungsquote oder eine Aussage zur Rechtskonformität eures konkreten Setups. Das lässt sich nur am tatsächlichen Fall klären.

Checkliste: Chatbot oder Agent entscheiden

1. Wir haben unsere Support-Anfragen nach „reine Auskunft” und „erfordert Handlung in einem System” aufgeteilt.
2. Unsere Wissensbasis ist aktuell, vollständig und in nutzbarer Form vorhanden – oder wir haben einen Plan, sie dahin zu bringen.
3. Wir haben aufgelistet, auf welche Systeme ein KI-System zugreifen soll, und ob dieser Zugriff lesend oder schreibend sein muss.
4. Für jede geplante Aktion gibt es eine definierte Freigabeschwelle oder einen Human-in-the-Loop-Schritt.
5. Es ist geklärt, wer KI-Ausgaben validiert, bevor sie an Backend-Systeme weitergegeben werden.
6. Datenschutz und – bei möglichen Hochrisiko-Fällen – rechtliche Einordnung sind vor dem produktiven Start geprüft, nicht danach.
7. Wir starten mit einem eng abgegrenzten Piloten statt mit dem kompletten Kundenservice.
8. Es gibt eine benannte Person, die Protokolle prüft und bei Fehlern eingreifen kann.

Wenn ihr bei Punkt 3 oder 4 nicht weiterkommt, ist das ein starkes Signal, erst einmal beim Chatbot zu bleiben und den Agentenschritt für später zu planen. Wer beim Aufbau der Wissensbasis oder bei der Team-Kompetenz zu KI-Systemen Unterstützung braucht, findet dazu Schulungsformate – die häufigste Lücke ist selten das Modell, sondern die saubere Grundlage, mit der es arbeitet.