Ein Chatbot, der Produktdetails halluziniert. Ein Support-Assistent, der alles eskaliert. Ein internes Tool, das in Demos perfekt funktioniert, aber versagt, sobald Benutzer es anfassen. Das sind keine Ausnahmefälle – sie sind das Standardergebnis, wenn Sie die Architekturschicht überspringen und direkt zu „Welches Tool sollen wir verwenden?“ springen.
Der Unterschied zwischen einem fehlerhaften KI-Assistenten und einem, der tatsächlich Produktionsverkehr bewältigt, liegt nicht in der Wahl der Plattform. Es geht darum, wie Sie das Problem strukturieren.
Diese Anleitung führt Sie durch den gesamten Stack: von der Definition dessen, was Ihr Assistent tatsächlich tun muss, über die Auswahl von Tools, die zu Ihren Einschränkungen passen (Code, Budget oder Fachwissen), bis hin zu Bereitstellungsmustern, die dem Kontakt mit echten Benutzern standhalten.
Was Sie wirklich bauen
Ein KI-Assistent ist kein Chatbot. Das ist wichtig, denn die Branche verwendet „Chatbot“ für alles, von „einen Claude-Wrapper auf unsere FAQ anwenden“ bis hin zu „autonomer Agent, der Entscheidungen über Kundenrückerstattungen trifft“. Es sind radikal unterschiedliche Systeme.
Ein geschäftlicher KI-Assistent muss drei Dinge tun:
- Kontext verstehen – entweder aus dem Gesprächsverlauf, Dokumenten oder einer Datenbank
- Relevante Antworten generieren – unter Verwendung eines Sprachmodells, das für Ihre Domäne trainiert oder konfiguriert wurde
- Aktionen ausführen oder schweigen – wissen, wann man antwortet, wann man eskaliert, wann man „Ich weiß es nicht“ sagt
Die meisten fehlgeschlagenen Bereitstellungen überspringen eine dieser Komponenten. Sie werden sehen, wie ein Unternehmen einen Support-Assistenten startet, der den Kontext perfekt abrufen kann, aber Müll generiert. Oder einen, der selbstbewusst spricht, aber nicht auf die Kundendaten zugreifen kann, die er benötigt. Oder einen, der im Sandbox-Test funktioniert, aber bei echten Gesprächen halluziniert oder fehlschlägt, weil er nicht auf Ihre tatsächlichen Anwendungsfälle trainiert wurde.
Bevor Sie Tools auswählen, ermitteln Sie Ihre spezifischen Anforderungen:
- Welche Entscheidungen trifft der Assistent und welche Konsequenzen hat es, wenn er falsch liegt?
- Welche Informationen benötigt er, um Fragen zu beantworten? Wo befinden sich diese?
- Wer überprüft die Ausgaben, bevor sie den Kunden erreichen – oder muss er autonom handeln?
- Wie sieht „Fehler“ aus – eine falsche Antwort? Eine verzögerte Antwort? Ein verärgerter Kunde?
Die drei Assistenten-Architekturen
Jeder geschäftliche KI-Assistent passt in eines von drei Mustern. Jedes hat unterschiedliche Tool-Anforderungen, Skalierungsverhalten und Fehlerarten.
Muster 1: Retrieval + Generation (RAG)
Ihr Assistent beantwortet Fragen, indem er relevante Informationen findet und diese an ein Sprachmodell weitergibt. Dies ist das gängigste Muster für Support-, Dokumentations- und FAQ-Assistenten.
So funktioniert es:
- Benutzer stellt eine Frage
- System ruft relevante Dokumente oder Snippets aus Ihrer Wissensdatenbank ab
- Diese Ergebnisse werden mit Anweisungen, wie zu antworten ist, an ein LLM übergeben
- Assistent gibt eine Antwort zurück, die auf Ihren tatsächlichen Inhalten basiert
Der Vorteil: Sie kontrollieren das Quellmaterial. Wenn Ihre Wissensdatenbank falsch ist, ist der Assistent falsch – aber zumindest können Sie es sehen und beheben. Das unterscheidet sich von einem Modell, das vollständig halluziniert.
Das Problem: Retrieval ist schwierig. Semantische Suche funktioniert gut, bis sie es nicht mehr tut. Benutzer formulieren Fragen auf eine Weise, die Ihre Wissensdatenbank nie vorhergesehen hat. Eine Abfrage wie „Kann ich etwas nach 30 Tagen zurückgeben?“ passt möglicherweise perfekt zu Ihrem Rückgaberecht, oder sie passt zu Marketingtexten, die „30-tägiges Rückgaberecht“ in einem völlig anderen Kontext erwähnen.
Reale Fehlerquelle eines Support-Assistenten, den ich entwickelt habe: Das System rief zwar korrekte Dokumente ab, aber in der falschen Reihenfolge. Eine Kundenfrage zu „Wie verfolge ich meine Bestellung?“ rief (1) die Bestellstatusseite, (2) die Versandratenseite, (3) die FAQ zu Rücksendungen ab. Der Assistent kombinierte alle drei und teilte dem Kunden mit, dass Bestellungen über UPS abgewickelt wurden, was nur im Kontext von Versand*schätzungen* und nicht von der Ausführung erwähnt wurde. Der Kunde war verwirrt.
Die Lösung war keine bessere Retrieval. Es war die Rangfolge. Das System musste verstehen, dass Bestellverfolgungsinformationen relevanter waren als Versandtarife, auch wenn beide semantisch übereinstimmten.
Wann RAG verwenden:
- Sie haben Dokumentation, die sich regelmäßig ändert und der Assistent soll auf dem neuesten Stand bleiben
- Genauigkeit ist wichtiger als Geschwindigkeit – Sie können einen kurzen Retrieval-Schritt tolerieren
- Sie möchten prüfen, welche Informationen der Assistent zur Beantwortung einer Frage verwendet hat
Muster 2: Feinabgestimmtes oder Prompt-Engineered LLM
Ihr Assistent beantwortet Fragen mithilfe eines Modells, das speziell für Ihren Anwendungsfall trainiert oder konfiguriert wurde. Kein Retrieval-Schritt. Das Wissen ist im Modell selbst eingebettet.
Beispiele: Ein spezialisierter Verkaufsassistent, der auf Ihren Produktkatalog trainiert ist, ein Support-Mitarbeiter, der auf Ihre Support-Tickets trainiert ist, ein internes Tool, das auf Ihre Dokumentation trainiert ist.
Der Vorteil: Geschwindigkeit und Konsistenz. Keine Latenz beim Retrieval. Das Modell kennt Ihre Domäne gut, da es auf Ihren Daten trainiert wurde.
Das Problem: Sie sind dafür verantwortlich, dieses Wissen auf dem neuesten Stand zu halten. Wenn sich Ihr Produkt ändert, Ihre Preise sich ändern oder Ihre Richtlinien sich verschieben, wird das Modell nicht automatisch aktualisiert. Sie müssen neu trainieren (teuer) oder sich mit Prompt-Engineering behelfen (fragil).
Es gibt auch eine Haftungsfrage: Wenn Ihr Modell etwas generiert, das autoritativ erscheint, aber tatsächlich falsch ist (weil es auf alten Daten trainiert wurde), wer ist verantwortlich?
Wann Fine-Tuning verwenden:
- Ihre Domäne ist hochspezialisiert und bestehende Modelle verstehen Ihre Branchensprache oder Konzepte nicht
- Sie benötigen einen konsistenten Antwortton und Stil über Tausende von Interaktionen hinweg
- Ihre Daten ändern sich langsam – vierteljährliche Updates, nicht täglich
- Sie verfügen über Budget und Infrastruktur zur Verwaltung von Modellversionen
Muster 3: Agenten-Workflow
Ihr Assistent beantwortet nicht nur Fragen. Er führt Aktionen aus: sucht Daten, prüft Systeme, führt Operationen durch und berichtet dann zurück. Dies ist für komplexe Arbeitsabläufe, bei denen eine einfache Textantwort nicht ausreicht.
Beispiel: Ein Kunde fragt „Kann ich mein Abonnement kündigen und eine Rückerstattung erhalten?“ Ein einfacher Assistent gibt die Richtlinie aus. Ein agentenhafter Assistent prüft: Ist das Konto in Ordnung? Gibt es aktive Verpflichtungen? Wie ist der Rückerstattungsstatus? Dann kann er die Kündigung tatsächlich bearbeiten, falls angemessen.
Der Vorteil: Sie automatisieren tatsächliche Geschäftsprozesse, nicht nur die Informationsbeschaffung.
Das Problem: Jede Aktion, die der Assistent ausführen kann, ist eine Haftungsfläche. Wenn er das falsche Konto erstattet, ist das Ihre Verantwortung. Je autonomer der Agent ist, desto rigoroser muss Ihre Sicherheitsebene sein.
Wann Agenten verwenden:
- Der Assistent muss den Systemzustand ändern (Datenbank aktualisieren, Ticket erstellen, Transaktion verarbeiten)
- Sie können sich die Infrastruktur leisten, um Agentenaktionen zu sandboxen und eine Genehmigung vor der Ausführung zu verlangen
- Die Domäne ist ausreichend eingeschränkt, sodass Sie klare Leitplanken definieren können
Tool-Auswahlmatrix
Sobald Sie Ihr Muster kennen, wählen Sie die Tools aus. Die Landschaft teilt sich in zwei Ansätze: No-Code-Plattformen (Sie schreiben überhaupt keinen Code) und API-first-Ansätze (Sie schreiben Code, verwenden aber verwaltete APIs für die Schwerstarbeit).
Diese Anleitung konzentriert sich auf No-Code, daher hier der praktische Vergleich:
