Die Shift/CX Konferenzwoche 2026 hat in mehreren Tracks gezeigt, wie sich die Debatte um Customer Experience verschiebt. Nach dem Feedback-First-Problem im Voice-of-Customer-Bereich, dem Service-Oxymoron zwischen Effizienz und Service-Exzellenz und dem Touchpoint-Stresstest für konsistente Erlebnisse führt auch der Track zu Chatbots und Conversational Experiences zu einer klaren Erkenntnis: Bei Conversational AI geht es nicht mehr nur um Automatisierung. Entscheidend wird, ob Unternehmen die Qualität, Nachvollziehbarkeit und Vertrauenswürdigkeit der Antworten sicherstellen können.

Eingebettete Large Language Models sind dabei längst Teil vieler neuer Conversational-Projekte. In den Diskussionen war zu hören, dass rund 80 Prozent der neuen Vorhaben auf Embedded LLMs setzen. Die Frage „ob LLM" tritt damit in den Hintergrund. Wichtiger wird die Frage, wie Unternehmen mit einem generativen Ansatz in einem Kontext umgehen, der fachlich belastbare, regelkonforme und prozessual anschlussfähige Antworten verlangt. Das zentrale Learning lautet daher: Vertrauen entsteht nicht im LLM selbst. Es entsteht in der Architektur um das Modell herum, in der Qualität der angebundenen Daten, in der Gestaltung der Experience und in einem Betriebsmodell, das Antworten kontinuierlich prüft und verbessert.

Frage 1: LLMs sind keine Wissenssysteme

Ein wiederkehrender Punkt im Track war die architektonische Trennung von Sprache, Wissen und Prozess. Dr. Michael Patrushev, Co-Founder und CTO der AICONIQ Group, brachte dies mit der Aussage auf den Punkt, dass LLMs keine Wissenssysteme sind. Sprachmodelle erzeugen plausible Sprache. Sie ersetzen aber keine gepflegte Wissensbasis, keine Berechtigungslogik und keine fachliche Verantwortung für korrekte Inhalte.

Die Konsequenz ist ein anderer Architekturansatz. Das LLM unterstützt bei Sprache, Intent-Erkennung und Antwortformulierung. Wissen, Regeln, Berechtigungen und Prozesslogik liegen in externen Systemen. Embedded LLMs werden damit zu einer Komponente in einer Orchestrierungsschicht, die mit Retrieval-Augmented Generation, Knowledge Graphs, CRM-Systemen, Ticketdaten und unternehmenseigenen Wissensquellen zusammenspielt.

Im Panel zum Track wurde die Architekturentwicklung als Evolutionslinie skizziert: von rein regelbasierten Dialogbäumen über klassische Conversational AI hin zu prozessgetriebener Orchestrierung und schließlich zu Agentic-AI-Mustern, die wir in Was ist Agentic AI im Kundenservice näher beschrieben haben. Welche Stufe für welchen Use-Case angemessen ist, hängt weniger von der technologischen Faszination ab als von Domäne, Risikoprofil und Datengrundlage.

Patrushev beschrieb diese Wissensschicht als „Corporate Brain". Gemeint ist eine unternehmensspezifische Ebene, die fachliche Inhalte, Kontextinformationen und Governance-Mechanismen verbindet. Erst dadurch lässt sich generative Sprachfähigkeit kontrolliert nutzen. Gerade in regulierten Branchen spricht vieles für hybride Architekturen aus spezialisierten Modellen, regelbasierten Komponenten und generativen LLMs. Die Frage ist nicht, welche Technologie moderner wirkt. Entscheidend ist, welche Aufgaben ein System verantwortbar übernehmen darf.

Frage 2: Die Experience wird im Backend entschieden

Verlässlichkeit entsteht nicht erst im sichtbaren Dialog. Sie entsteht in den Daten, Regeln, Prüfungen und Prozessanschlüssen, die eine Antwort ermöglichen oder begrenzen. Dr. Maximilian Panzner, CTO und Co-Founder von Mercury.ai, beschrieb dafür einen Faktenprüfungs-Layer. Jede Antwort läuft dabei durch einen geprüften Zwischenschritt, bevor sie das System verlässt. Das LLM liefert die sprachliche Form, der Inhalt stammt aus validierten Datenquellen.

Diese Logik ist besonders in Branchen wie Finanzdienstleistung, Versicherung oder Gesundheit wichtig. Dort reicht es nicht, wenn ein System freundlich und plausibel antwortet. Es muss fachlich belastbar, regelkonform und nachvollziehbar bleiben. Die Trust-Komponente entsteht damit nicht durch das Modell allein, sondern durch die Kombination aus geprüften Daten, klaren Grenzen und nachvollziehbaren Kontrollmechanismen.

Auch Maren Kaspers und Ludger Kesting von Octonomy setzten in ihrem Beitrag „Die Chatbot-Illusion" genau hier an. Ihr Punkt: Der entscheidende Hebel liegt im Backend, das Frontend folgt. Ein Bot, der nur auf eine FAQ-Datenbank zugreift, kann komplexe Anliegen nicht zufriedenstellend lösen. Erst die Integration von CRM, Ticketsystem, Wissensbasis und Prozessinformationen schafft die Grundlage für präzise und kontextbezogene Antworten. Welche Architekturlogik dafür nötig ist, haben wir in Composable DXP ausgeführt.

Damit wird Conversational AI zu einer Prozess- und Integrationsfrage. Eine gute Experience entsteht nicht durch ein schöneres Chatfenster, sondern durch die Fähigkeit, Anliegen zu erkennen, Kontext zu verstehen, Informationen zusammenzuführen und nächste Schritte sinnvoll anzustoßen. Auch Markenkonsistenz gehört dazu. Brand Voice ist keine nachträgliche Tonalitätsübung. Sie muss über Prompts, Wissensquellen, Tests und Freigabeprozesse abgesichert werden.

Frage 3: Der Betrieb entscheidet über Vertrauen

Mit eingebetteten LLMs endet ein Conversational-Projekt nicht beim Go-live. Dort beginnt die Phase, in der sich Qualität, Vertrauen und Wirtschaftlichkeit beweisen. Benjamin Gebauer, Director AI & Data Practice bei infinit.cx, beschrieb diese Aufgabe als „AI Operating Model": eine laufende Praxis aus Governance, Monitoring und Optimierung.

Das Monitoring muss mehr leisten als Standard-Reports der Plattformanbieter. Unternehmen müssen erkennen, wo das System korrekt antwortet, wo es Anliegen falsch entschlüsselt, welche Wissenslücken sichtbar werden und an welchen Stellen Prozesse die gewünschte Lösung verhindern. Fehlerhafte Antworten sind selten reine Modellprobleme. Häufig liegen die Ursachen in veralteten Wissensbeständen, unklaren Regeln, fehlenden Integrationen oder nicht definierten Übergaben.

Gebauer berichtete im Track aus laufenden Projekten von tatsächlichen Automatisierungsraten zwischen 15 und 30 Prozent. Diese Lücke ist selten technisch bedingt. Sie entsteht durch fehlende Governance, unzureichendes Monitoring und mangelnde prozessuale Reife. Damit verändert sich auch die Bewertung von Conversational AI. Eine hohe Automatisierungsquote ist nur dann wertvoll, wenn die automatisierten Antworten korrekt, hilfreich und anschlussfähig sind. Sonst entsteht Scheineffizienz: Das System bearbeitet viele Kontakte, löst aber zu wenige Anliegen wirklich. Die relevante Frage lautet daher nicht nur, wie viele Gespräche automatisiert wurden. Sie lautet, welche Anliegen zuverlässig gelöst wurden und welche Qualität die Kundenerfahrung hatte.

Paul Herbertz, Productmanager bei BarmeniaGothaer, ergänzte dazu die organisatorische Perspektive. Viele KI-Projekte scheitern weniger an der Technologie als an Führungsstruktur, Rollenklärung und Organisation. Für Conversational AI heißt das: Fachbereiche dürfen nicht nur Auftraggeber sein. Sie müssen Partner im Betrieb werden. Sie verantworten Inhalte, Regeln, Prozesse und Qualitätsmaßstäbe mit.

Fazit: Conversational AI braucht Antwortverantwortung

Die Vertrauensfrage bei Conversational Systems mit eingebetteten LLMs ist keine technische Detailfrage. Sie ist eine Managementaufgabe. Unternehmen müssen klären, wo Wissen liegt, wie Antworten geprüft werden, welche Systeme angebunden sind und wer im laufenden Betrieb Verantwortung trägt.

Das Learning aus dem Track zu Chatbots und Conversational Experiences lautet deshalb: Embedded LLMs lösen das Chatbot-Problem nicht allein. Sie erhöhen die Anforderungen an Architektur, Datenqualität, Governance und Betrieb. Die entscheidende Frage ist nicht, ob ein System antworten kann. Entscheidend ist, ob es Anliegen richtig entschlüsselt, Antworten belastbar erzeugt und im Betrieb kontrollierbar bleibt.

Dieser Beitrag ist Teil unserer Reihe Shift/CX Konferenzwoche 2026 — Learnings, in der wir zentrale Beobachtungen aus der Konferenzwoche redaktionell einordnen und für die weitere CX-Diskussion verdichten. Die vollständigen Vorträge sind in der Shift/CX Mediathek abrufbar.