Ein KI-Chatbot fürs Unternehmen: was reingehört
Ein Chatbot ist kein Sprachmodell mit Logo. Was ein KI-Pilot für Unternehmen wirklich braucht — und wo die Daten dabei bleiben.
· 5 Min. Lesezeit
Wer „KI-Chatbot für Unternehmen” sucht, meint selten ein Chatfenster, das nett antwortet. Gemeint ist meist: ein System, das die eigenen Dokumente, Produktdaten oder Support-Fälle kennt und darauf verlässlich antwortet — nicht ein allgemeines Sprachmodell mit dem Firmenlogo davor.
Die Suche danach kommt meist aus einem konkreten Anlass: ein Support-Team, das dieselben zwanzig Fragen immer wieder beantwortet, ein Vertrieb, der Angebote aus denselben Textbausteinen zusammensetzt, oder ein internes Wiki, das niemand mehr durchsucht, weil es zu unübersichtlich geworden ist. In allen drei Fällen ist die eigentliche Aufgabe nicht „ein Chatbot bauen”, sondern das vorhandene Wissen so aufzubereiten, dass ein System zuverlässig darauf zugreifen kann.
Warum „einfach ein Sprachmodell einbinden” meistens nicht reicht
Ein Sprachmodell weiß nichts über die interne Preisliste, den aktuellen Lagerbestand oder die Kündigungsfrist im eigenen Vertrag. Es kann sehr überzeugend etwas Falsches dazu sagen — nicht aus böser Absicht, sondern weil es darauf trainiert ist, eine plausibel klingende Antwort zu liefern, auch wenn ihm die eigentliche Information fehlt. Der Unterschied zwischen einem Demo-Chatbot und einem, der im echten Betrieb funktioniert, liegt fast immer darin, wie gut er an die eigenen Daten angebunden ist — nicht daran, welches Modell im Hintergrund läuft. Ein beeindruckender Demo-Moment mit einem Standardmodell und ein System, das nach drei Monaten Support-Anfragen noch verlässlich beantwortet, sind zwei unterschiedliche Projekte, auch wenn sie auf den ersten Blick gleich aussehen.
Was ein funktionierender Pilot braucht
Eine saubere Datenquelle. Bevor ein Modell etwas beantworten kann, muss klar sein, welche Dokumente, Datenbanken oder Systeme als Wahrheit gelten. Unklare oder widersprüchliche Quellen ergeben unklare oder widersprüchliche Antworten, ganz unabhängig vom Modell. In den meisten Unternehmen ist genau das die eigentliche Vorarbeit: alte, doppelte oder widersprüchliche Versionen eines Dokuments auszusortieren, bevor überhaupt ein Modell darauf losgelassen wird.
Retrieval statt Auswendiglernen. Wir setzen auf RAG — Retrieval-Augmented Generation: Das Modell bekommt zur Antwortzeit die relevanten Ausschnitte aus den eigenen Dokumenten mitgeliefert, statt zu raten, was es vor Monaten gelernt haben könnte. Dafür werden Dokumente in eine Vektordatenbank überführt, in der sich inhaltlich ähnliche Abschnitte wiederfinden lassen, auch wenn die Formulierung der Nutzerfrage anders lautet als die im Dokument. Das macht Antworten nachvollziehbar und aktuell, ohne das Modell neu zu trainieren, wenn sich eine Preisliste ändert — ein aktualisiertes Dokument reicht, nicht ein neuer Trainingslauf.
Eine Grenze, wo das System nicht mehr rät. Ein guter Chatbot sagt „das weiß ich nicht” statt eine plausible, aber falsche Antwort zu erfinden. Diese Grenze zu bauen ist mehr Arbeit als das eigentliche Chatfenster: Sie bedeutet, aus den gefundenen Textausschnitten zu erkennen, ob überhaupt eine belastbare Antwort möglich ist, und im Zweifel an einen Menschen zu übergeben statt zu improvisieren.
Eine Antwort auf die Datenfrage, bevor sie gestellt wird. In DACH-Unternehmen kommt die Frage nach Kundendaten in einem KI-System früh und zu Recht. Wir arbeiten ausschließlich mit API-Anbietern, die vertraglich zusichern, keine Kundendaten zum Training zu verwenden, oder mit Modellen, die in der EU gehostet sind. Diese Entscheidung steht am Anfang eines Projekts, nicht als nachträgliche Absicherung.
Wie ein Pilot bei uns abläuft
Die meisten Piloten sind auf drei bis fünf Wochen angelegt und enden mit einem funktionierenden Prototyp und echten Zahlen — wie viele Fragen er beantwortet, wie oft er richtig lag, wo er noch an Menschen weiterleiten muss. Das ist bewusst kurz gehalten: Ein KI-Projekt, das erst nach einem halben Jahr zeigt, ob die Idee trägt, ist kein Pilot mehr, sondern eine Wette.
Am Ende eines Piloten steht eine Entscheidung, keine automatische Weiterführung: Trägt die Idee, mit welchen Anpassungen, und lohnt sich der nächste Schritt in Richtung Produktivsystem. Nicht jeder Pilot führt zu einem Rollout, und das ist kein Fehlschlag des Piloten — es ist genau die Frage, die ein kurzer, klar abgegrenzter Test beantworten soll, bevor größere Ressourcen gebunden werden.
| Baustein | Zweck |
|---|---|
| Datenquelle klären | definiert, worauf das System antworten darf |
| RAG-Anbindung | hält Antworten aktuell, ohne Neu-Training |
| Antwortgrenze | verhindert plausible Falschantworten |
| No-Training-Zusage / EU-Hosting | klärt die Datenfrage vor dem Start |
| Fester Pilotzeitraum | liefert Zahlen statt einer Dauerbaustelle |
Wo das Ganze läuft
Für viele Bausteine — von der Datenaufbereitung bis zur Vektorsuche — reicht eine schlanke, edge-nahe Infrastruktur, etwa Cloudflare Workers AI mit einer angebundenen Vektordatenbank, ohne dass dafür ein separater Server betrieben werden muss. Das hält einen Piloten schnell aufsetzbar und ebenso schnell wieder abschaltbar, falls die Zahlen am Ende des Pilotzeitraums nicht überzeugen. Erst wenn ein Pilot zum Produktivsystem wird und mit bestehender Infrastruktur — einem CRM, einem Data Warehouse — zusammenspielen muss, stellt sich neu die Frage, wo genau das System am besten laufen sollte.
Was danach kommt
Ein Pilot, der funktioniert, ist noch kein Produktivsystem. Monitoring, ein Rechte- und Rollenmodell, die Anbindung an bestehende Systeme wie ein CRM oder Ticketsystem — das ist der Schritt danach, und er profitiert von denselben Prinzipien wie jede andere Integration: Warteschlangen, Überwachung, ein klarer Verantwortlicher, wenn etwas schiefläuft. Auch die Frage, wer im Unternehmen die Antworten des Systems stichprobenartig prüft, sobald es produktiv läuft, gehört in diesen Schritt — ein Pilot wird von einem kleinen Team eng begleitet, ein Produktivsystem läuft ohne diese Nähe weiter und braucht dafür eine eigene Kontrolle.
Die Regel, nach der wir KI-Projekte planen
Ein Chatbot, der nicht sagen kann, woher eine Antwort kommt, gehört nicht in den produktiven Einsatz — egal wie gut er klingt.
Wer wissen will, ob die eigenen Daten und Prozesse für einen sinnvollen Piloten reichen, bekommt die ehrlichste Antwort in einem Gespräch. Mehr zum Vorgehen steht bei KI & Automatisierung.