Dieses Projekt uebertraegt nicht einfach ein einzelnes Sprachmodell in ein Chatfenster, sondern baut einen dialogbasierten Systemzugang mit sauberer Zustaendigkeitslogik auf. Unterschiedliche Anfragen benoetigen unterschiedliche Antwortwege, unterschiedliche Datenquellen und unterschiedliche Eskalationsregeln. Genau deshalb arbeitet der Chatbot nicht mit einem universellen Agenten, sondern mit einer aufgeteilten Struktur aus Routing, Fachlogik und Human Handoff.
Viele KI-Chatbots sehen auf den ersten Blick ueberzeugend aus, weil sie fluessig formulieren und schnell antworten. Im produktiven Einsatz zeigt sich jedoch ein anderes Bild. Support-Anfragen, Produktfragen, FAQ-Themen, Kontaktanliegen oder vertriebsnahe Dialoge folgen nicht derselben Logik. Sie brauchen unterschiedliche Quellen, unterschiedliche Freigaben, unterschiedliche Tonalitaet und teilweise sogar echte Aktionen in angebundenen Systemen.
Wenn all das in einem einzigen Prompt oder einem einzigen Agenten endet, entsteht genau die Art von Chaos, die ein Unternehmen spaeter teuer bezahlt: unklare Zustaendigkeiten, falsche Antworten, fehlende Eskalation, schlechte Uebergaben an Menschen und keine saubere Trennung zwischen Information, Aktion und Weiterleitung. Das Problem liegt also nicht darin, dass Modelle noch nicht gut genug waeren. Das Problem ist, dass die Systemlogik hinter dem Chat oft zu simpel gedacht wird.
Ein produktiver KI-Chatbot braucht deshalb mehr als gute Formulierungen. Er braucht eine Architektur, die erkennt, mit welcher Art von Anfrage sie es zu tun hat, welche Instanz zustaendig ist, welche Datenquellen erlaubt sind und wann ein Mensch uebernehmen muss.
Jede eingehende Nachricht wird zunaechst eingeordnet. Danach uebernimmt nicht die KI allgemein, sondern genau der Teil des Systems, der fuer diese Art von Anfrage vorgesehen ist, inklusive Wissenszugriff, Tool-Nutzung und sauberer Eskalation.
Die Loesung setzt auf eine mehrschichtige Struktur. Eingehende Nachrichten werden zuerst klassifiziert: Geht es um eine Wissensfrage, ein Support-Problem, eine vertriebsnahe Anfrage oder einen Fall, der nicht automatisiert beantwortet werden sollte? Diese Entscheidung ist zentral, weil sie bestimmt, welche Datenquellen, welche Antwortlogik und welche Tool-Aktionen ueberhaupt zulaessig sind.
Anstatt einen einzigen Bot auf alles loszulassen, arbeitet das System mit spezialisierten Zustaendigkeiten. Ein FAQ- oder Wissensagent greift auf eine gepflegte Wissensbasis zu. Ein Support-orientierter Agent kann Faelle strukturieren und, wenn freigegeben, mit externen Systemen interagieren. Ein vertriebsnaher Agent bewertet Anfragen anders als ein reiner Informationsagent. Dadurch entsteht nicht nur bessere Antwortqualitaet, sondern ein sauberer betrieblicher Ablauf.
Besonders wichtig ist die Uebergabelogik. Das System ist nicht darauf ausgelegt, jede Anfrage zwanghaft selbst zu loesen. Wo Unsicherheit, Sonderfaelle oder sensible Anliegen auftreten, wird ein sauberer Human Handoff ausgeloest, mit Kontext, Verlauf und Einordnung. Genau dadurch wird aus einem Demo-Chatbot ein produktiv nutzbares Dialogsystem.
Nicht jede Nachricht ist dieselbe Art von Aufgabe
Jede Nutzeranfrage wird zunaechst klassifiziert. Dabei geht es nicht nur um Schlagworte, sondern um die operative Einordnung: Wissensfrage, Support-Fall, Vertriebsanfrage, Kontaktwunsch oder Eskalationsfall. Diese erste Trennung verhindert, dass der Chatbot vorschnell eine scheinbar passende, aber systemisch falsche Antwort erzeugt.
Die Anfrage landet dort, wo ihre Logik hingehoert
Nach der Einordnung uebernimmt ein Routing-Layer die Verteilung. Er entscheidet, welcher Agent oder welcher Service zustaendig ist, welche Datenquellen genutzt werden duerfen und welcher Antwortmodus ueberhaupt zulaessig ist. Damit wird verhindert, dass alle Arten von Anfragen im selben Gespraechsmuster landen.
Reproduzierbare Antworten auf Basis gepflegter Inhalte
Fuer FAQ- und Wissensfragen arbeitet das System nicht mit freier Improvisation, sondern mit einer RAG- oder Dokumentenlogik. Relevante Informationen werden aus einer definierten Wissensbasis gezogen und in den Antwortprozess eingebunden. Das erhoeht Konsistenz und reduziert Halluzinationen deutlich.
Support ist ein Fall, kein freier Fliesstext
Sobald eine Anfrage Support-Charakter hat, muss das System anders reagieren. Statt nur hoeflich zu antworten, werden Kontext, Problemtyp und moegliche naechste Schritte strukturiert behandelt. Je nach Integration kann das System Tickets anlegen, Statusinformationen einholen oder Faelle fuer Menschen vorbereiten. Das macht aus einem Chat ein Arbeitswerkzeug.
Nicht jede Kontaktanfrage ist Support
Vertriebsnahe Dialoge benoetigen eine andere Sprache, andere Prioritaeten und oft eine andere Zielsetzung. Hier geht es nicht primaer um Problemloesung, sondern um Orientierung, Qualifizierung oder Uebergabe. Das System beruecksichtigt deshalb, dass Verkaufsnaehe und Wissensvermittlung nicht vermischt werden sollten.
Saubere Uebergabe statt abgebrochener Automatisierung
Wenn die automatische Bearbeitung endet, darf kein Kontext verloren gehen. Deshalb erzeugt das System fuer die Uebergabe eine strukturierte Zusammenfassung des Falls, inklusive bisherigem Verlauf, erkannter Kategorie und relevanter Zusatzinformationen. So wird aus einer Eskalation kein Bruch, sondern ein kontrollierter Uebergang.