FAQ-Chatbot mit eigenen Daten: RAG statt statischer Antworten

Das Problem: FAQ-Bots, die nicht mitwachsen

„Der Chatbot antwortet auf Fragen, die wir vor zwei Jahren mal hatten.“ Diesen Satz höre ich in Projekten regelmäßig, wenn ein bestehender FAQ-Bot zur Debatte steht. Klassische, regelbasierte FAQ-Bots arbeiten mit fest hinterlegten Frage-Antwort-Paaren: Eine Nutzereingabe wird gegen eine begrenzte Liste bekannter Formulierungen abgeglichen, und bei Abweichung — eine andere Wortwahl, ein Tippfehler, eine Frage in zwei Teilen — liefert der Bot entweder gar keine oder eine falsche Antwort. Jede neue Frage, jede geänderte Preisliste, jede aktualisierte Lieferbedingung erfordert manuelle Pflege der Regeln. In der Praxis passiert diese Pflege selten konsequent, und der Bot veraltet schneller, als er genutzt wird.

Dieser Artikel richtet sich an Geschäftsführung, Operations, IT und Fachbereich in kleinen und mittleren Unternehmen, die einen FAQ-Chatbot mit eigenen Unternehmensdaten aufbauen oder einen bestehenden, starren Bot ablösen wollen. Es geht nicht darum, ob ein Chatbot „die Zukunft“ ist, sondern um eine konkrete architektonische Entscheidung: Ein statischer Regel-Bot oder ein Bot, der über Retrieval Augmented Generation (RAG) auf eine gepflegte, durchsuchbare Wissensbasis zugreift und daraus Antworten formuliert, die Varianten einer Frage verstehen und auf aktuellem Wissen basieren.

Meine Kurzposition vorweg: RAG löst das Problem der Varianten- und Aktualitätsschwäche technisch überzeugend, aber es verlagert die eigentliche Arbeit — nämlich die Wissensbasis aktuell und sauber zu halten — nicht weg. Ein RAG-Bot ohne gepflegte Quellen ist nur ein besser klingender veralteter Bot. Wer diesen Punkt überspringt, kauft sich Technik statt eine Lösung.

Begriffe kurz geklärt: Statischer Bot, RAG, Wissensbasis

Statischer FAQ-Bot meint ein regelbasiertes oder auf einfachem Textabgleich beruhendes System mit einer festen Liste von Frage-Antwort-Paaren. Er erkennt nur Formulierungen, die den hinterlegten Mustern hinreichend ähnlich sind, und muss bei jeder inhaltlichen Änderung manuell nachgepflegt werden.

RAG (Retrieval Augmented Generation) ist laut n8n-Dokumentation eine Technik, die einem Sprachmodell zusätzlich zu seinem trainierten Wissen Zugriff auf externe, aktuelle Quellen gibt: Ein Retrieval-Schritt sucht die zu einer Anfrage passenden Textausschnitte aus einer Wissensbasis und reicht sie zusammen mit der Eingabe an das Modell weiter, damit dieses eine Antwort formuliert, die auf diesen Quellen „geerdet“ ist — im Gegensatz zu einer Antwort, die allein aus antrainiertem, möglicherweise veraltetem Wissen stammt.

Wissensbasis / Vektordatenbank ist die Datenschicht hinter dem RAG-System. Referenzdokumente werden in kürzere Textabschnitte (Chunks) zerlegt, per Embedding-Modell in Vektoren überführt und in einer Vektordatenbank gespeichert. Bei jeder Anfrage wird deren Vektor mit den gespeicherten Vektoren verglichen, um die inhaltlich nächsten Chunks zu finden — laut Datenschutzkonferenz eine semantische statt rein wortbasierte Suche.

Der praktische Unterschied für einen Support-Bot: Ein statischer Bot „kennt“ nur, was explizit als Regel hinterlegt wurde. Ein RAG-Bot durchsucht bei jeder Anfrage neu die aktuelle Wissensbasis — Aktualisierungen wirken sofort, ohne dass jemand Regeln umschreiben muss. Mehr zu den technischen Grundlagen findest du auf der Themenseite Kundenservice und Support.

Welche Inhalte braucht der Bot?

Diese Frage wird in Projekten oft mit „alles, was wir haben“ beantwortet — das ist der falsche Ausgangspunkt. Die Datenschutzkonferenz stellt in ihrer Orientierungshilfe zu RAG-Systemen klar heraus: Die Zuverlässigkeit eines RAG-Systems hängt stark von der Qualität, Aktualität und Vollständigkeit der verwendeten Referenzdokumente ab — unvollständige oder veraltete Daten führen zu unrichtigen Ausgaben. Menge ersetzt keine Qualität.

Typische, geeignete Inhalte für einen FAQ-Chatbot mit eigenen Daten:

• Gepflegte FAQ- und Hilfetexte — die bestehende Wissensdatenbank, wenn sie regelmäßig aktualisiert wird.
• Produkt- und Leistungsbeschreibungen in ihrer aktuellen Fassung, nicht als Archiv aller früheren Versionen.
• Prozess- und Richtliniendokumente, etwa Rückgabebedingungen, Lieferzeiten, Eskalationswege.
• Ausgewählte, anonymisierte Support-Verläufe, sofern sie wiederkehrende Muster zeigen und keine unnötigen personenbezogenen Daten enthalten.

Weniger geeignet oder mit besonderer Vorsicht zu behandeln: interne, widersprüchliche oder mehrfach überarbeitete Dokumentversionen ohne klaren „aktuellen Stand“, Dokumente mit sensiblen personenbezogenen Daten ohne belastbare Rechtsgrundlage für die Verarbeitung, sowie Inhalte aus nicht vertrauenswürdigen oder unbekannten Quellen — die Datenschutzkonferenz empfiehlt ausdrücklich, solche Dokumente nicht zu verwenden, weil sie die Transparenzpflichten unterlaufen.

Vor dem technischen Aufbau lohnt sich deshalb ein Datenaufbereitungsschritt: störende Elemente wie Kopf- und Fußzeilen entfernen, Dokumente in Fließtext überführen, personenbezogene Daten dort entfernen oder anonymisieren, wo sie für die Antwort nicht gebraucht werden. Dieser Schritt entscheidet laut Datenschutzkonferenz maßgeblich über die spätere Antwortqualität — mehr dazu im Abschnitt zur Umsetzung.

Wie funktioniert RAG?

Technisch besteht ein RAG-System laut Datenschutzkonferenz aus vier Kernkomponenten: Retriever, Embedding-Modell, Vektordatenbank und dem eigentlichen Sprachmodell. Der Ablauf in vereinfachter Form:

1. Datenaufbereitung: Referenzdokumente werden in Chunks (Textabschnitte) zerlegt. Die Wahl der Chunk-Größe beeinflusst die Antwortqualität direkt — zu kleine Chunks zerreißen Zusammenhänge, zu große verwässern die Relevanz. n8n empfiehlt in der eigenen Dokumentation für die meisten Anwendungsfälle chunk-basiertes Splitting entlang der Dokumentstruktur (etwa nach Markdown- oder Überschriftenebenen) statt reiner Zeichenanzahl.
2. Embedding: Ein Embedding-Modell wandelt jeden Chunk in einen Vektor um, der die inhaltliche Bedeutung repräsentiert. n8n weist darauf hin, dass die Wahl des Embedding-Modells von der Sprache und Komplexität der Dokumente abhängt — größere Modelle bieten laut n8n-Dokumentation besseres semantisches Verständnis, sind aber aufwendiger im Betrieb.
3. Speicherung: Chunks und ihre Vektoren landen in der Vektordatenbank, ergänzt um Metadaten wie Quelle, Datum und gegebenenfalls Zugriffsberechtigung.
4. Retrieval bei jeder Anfrage: Die Nutzereingabe wird mit demselben Embedding-Modell in einen Vektor überführt, der Retriever sucht die semantisch nächsten Chunks in der Datenbank.
5. Erweiterte Anfrage an das Sprachmodell: Nutzereingabe und gefundene Chunks werden gemeinsam an das Sprachmodell übergeben, das daraus die Antwort formuliert.

Wichtig für die Erwartungshaltung: Die Datenschutzkonferenz betont, dass RAG das trainierte Wissen des Sprachmodells selbst nicht verändert — anders als ein Fine-Tuning. RAG beeinflusst nur den Kontext der jeweiligen Anfrage. Der Vorteil dabei: Informationen in der Wissensbasis lassen sich einfach aktualisieren, löschen und beauskunften, während im Sprachmodell selbst trainierte Informationen praktisch nicht gezielt löschbar sind.

Wie zeigt er Quellen?

Das BSI nennt in seiner Übersicht zu Gegenmaßnahmen bei generativen KI-Modellen die Anzeige der konkreten Textausschnitte, auf denen eine Antwort basiert, ausdrücklich als Maßnahme, mit der sich Auswirkungen von Halluzinationen mildern lassen. Technisch ist das bei RAG einfacher umzusetzen als bei einem reinen Sprachmodell: Weil der Retriever ohnehin konkrete Chunks mit Metadaten (Dokumenttitel, Abschnitt, Datum) an das Modell übergibt, lässt sich dieselbe Information in der Antwort mit anzeigen — etwa als Verweis „Quelle: Rückgabebedingungen, Stand März 2026“.

Zwei Einschränkungen gehören zur ehrlichen Einordnung dazu. Erstens: Die Datenschutzkonferenz weist darauf hin, dass sich zwar die erweiterte Anfrage an das Sprachmodell nachvollziehen lässt, nicht aber, wie genau das Modell aus dieser Anfrage seine konkrete Formulierung erzeugt — vollständige Transparenz über die Textgenerierung selbst bleibt begrenzt. Zweitens hilft eine Quellenanzeige nur, wenn die zugrunde liegenden Referenzdokumente selbst sauber verschlagwortet sind. Ohne Titel, Datum und Fundstelle in den Metadaten lässt sich keine belastbare Quellenangabe erzeugen, egal wie gut das Sprachmodell ist.

In der Praxis heißt das: Quellenanzeige ist kein nachträglich aufgesetztes Feature, sondern eine Anforderung an die Datenaufbereitung von Anfang an. Wer Dokumente ohne Datumsangabe oder Versionskennzeichnung importiert, kann später keine verlässliche Quellenangabe nachrüsten.

Wann darf er nicht antworten?

Ein FAQ-Bot mit eigenen Daten sollte nicht raten. Aus den Quellen lassen sich drei belastbare Situationen ableiten, in denen ein Bot erkennbar nicht selbst antworten sollte:

Keine ausreichend nahe Übereinstimmung in der Wissensbasis. Wenn der Retriever keine Chunks findet, deren semantische Nähe zur Anfrage groß genug ist, besteht laut Datenschutzkonferenz das Risiko, dass das Sprachmodell auf sein allgemeines, möglicherweise veraltetes oder falsches Trainingswissen zurückgreift statt ehrlich „das weiß ich nicht“ zu signalisieren — insbesondere bei widersprüchlichen Inhalten neigen Sprachmodelle laut Datenschutzkonferenz dazu, Trainingswissen gegenüber den bereitgestellten Referenzdokumenten zu bevorzugen. Ein Schwellenwert für die minimale Ähnlichkeit und eine klare Fallback-Antwort sind deshalb Pflicht, nicht Kür.

Die Anfrage liegt außerhalb des definierten Zwecks oder der freigegebenen Daten. Die Datenschutzkonferenz beschreibt Zweckbindung als eigenständige Anforderung: Mitarbeitende oder Kund:innen sollen nur auf die für ihren Zweck vorgesehenen Informationen zugreifen können, umgesetzt über Rollen- und Rechtekonzepte auf Ebene der Vektordatenbank. Fragen außerhalb des freigegebenen Datenbestands gehören technisch blockiert, nicht nur höflich abgelehnt.

Zugriffssteuerung darf nicht allein über den Systemprompt laufen. Hier lohnt ein genauer Blick auf eine Nuance, die in vielen Praxisbeschreibungen fehlt: Die Datenschutzkonferenz nennt einen Systemprompt zur Quellenbindung als mögliche technische Maßnahme gegen Halluzinationen — das BSI warnt aber ausdrücklich davor, ein Rechte- und Rollensystem über rein textuelle Instruktionen umzusetzen, weil solche Anweisungen angreifbar sind, etwa durch Prompt-Injection. Beide Quellen passen zusammen, wenn man sie richtig trennt: Ein Systemprompt kann helfen, das Modell auf die referenzierten Quellen zu verpflichten — er ersetzt aber keine echte Zugriffskontrolle auf Datenbankebene. Wer sensible Bereiche nur per Anweisung „das darfst du nicht sagen“ absichert, hat keine Zugriffskontrolle, sondern eine Bitte.

Wenn eine dieser drei Situationen eintritt, sollte der Bot das erkennbar machen und an einen Menschen übergeben statt eine unsichere Antwort zu formulieren. Wie dieser Übergabeprozess konkret aussehen kann, ist ein eigenes Thema — dazu mehr im verlinkten Artikel zum Human Handover im Frontmatter dieser Seite.

Wie wird Wissen aktualisiert?

Technisch trennt sich ein produktiver RAG-Bot sinnvoll in zwei Workflows, wie es auch die n8n-Dokumentation für die eigene RAG-Umsetzung empfiehlt: einen Ingestion-Workflow, der neue oder geänderte Dokumente lädt, in Chunks zerlegt, einbettet und in die Vektordatenbank schreibt, und einen separaten Abfrage-Workflow, der bei jeder Nutzeranfrage die Wissensbasis durchsucht und eine Antwort erzeugt. Diese Trennung erlaubt es, die Wissensbasis unabhängig vom laufenden Bot-Betrieb zu pflegen.

Für die Aktualisierung in der Praxis sind drei Punkte entscheidend:

• Ein definierter Auslöser für die erneute Einbettung. Ob ein Dokument bei jeder Änderung sofort neu verarbeitet wird oder in einem festen Rhythmus (täglich, wöchentlich) — die Datenschutzkonferenz verlangt, dass die verantwortliche Stelle regelmäßig überprüft, ob die Referenzdokumente noch aktuell und vollständig sind. Ohne definierten Rhythmus bleibt das eine gute Absicht statt eines Prozesses.
• Konsistente Embedding-Modelle über Zeit. n8n weist in der eigenen Dokumentation darauf hin, dass für das Einfügen und das Abfragen von Daten dasselbe Embedding-Modell verwendet werden muss, damit die Vektorräume kompatibel bleiben. Ein Modellwechsel erfordert deshalb eine vollständige Neu-Einbettung der bestehenden Wissensbasis, nicht nur der neuen Dokumente.
• Löschung als gleichwertiger Prozess zur Ergänzung. Veraltete oder falsche Inhalte müssen aus der Vektordatenbank und den Referenzdokumenten entfernt werden können — die Datenschutzkonferenz beschreibt das als direkten Vorteil von RAG-Architekturen gegenüber einem Sprachmodell, dessen trainiertes Wissen sich praktisch nicht gezielt löschen lässt. Wer nur ergänzt und nie löscht, baut über Zeit eine widersprüchliche Wissensbasis auf.

Ein Rollen- und Rechtekonzept gehört von Anfang an in diesen Aktualisierungsprozess, nicht als nachträgliche Ergänzung: Wenn ein Dokument im Quellsystem nur für eine Abteilung sichtbar ist, muss diese Einschränkung beim Import in die Vektordatenbank übernommen und bei jeder Abfrage erneut geprüft werden — dazu zählt laut Datenschutzkonferenz eine Mandantentrennung beziehungsweise funktionale Trennung auf Ebene der Vektordatenbank selbst.

Eigene Einordnung: Content-Reifegrad-Matrix

Diese Matrix ist meine eigene Arbeitshilfe aus Projekten, um vor dem technischen Aufbau zu sortieren, welche Inhalte in welcher Reihenfolge in die Wissensbasis gehören. Sie ersetzt keine Einzelfallprüfung.

Content-Typ	Aktualisierungsfrequenz	Strukturierungsaufwand	Eignung für RAG-Import
Gepflegte FAQ-Liste	Hoch (laufend)	Gering — bereits strukturiert	Sehr gut, sollte zuerst importiert werden
Produktbeschreibungen (aktuelle Version)	Mittel (bei Sortimentsänderung)	Gering–mittel	Gut, mit klarer Versionskennzeichnung
Richtlinien- und Prozessdokumente	Niedrig–mittel	Mittel — oft in Fließtext, muss aufbereitet werden	Gut, nach Bereinigung von Altversionen
Vertragsvorlagen mit personenbezogenen Daten	Niedrig	Hoch — Anonymisierung nötig	Nur nach Datenklassifizierung und Rechtsgrundlage prüfen
Roh-Support-Tickets (unbereinigt)	Sehr hoch	Hoch — enthält oft personenbezogene und widersprüchliche Angaben	Ungeeignet ohne vorherige Anonymisierung und Kuratierung
Interne Foren- oder Chat-Verläufe	Hoch	Hoch — unstrukturiert, oft veraltete Diskussionsstände	Meist ungeeignet, hohes Risiko widersprüchlicher Chunks

Der Punkt, den diese Matrix sichtbar macht: Ein hoher Strukturierungsaufwand korreliert nicht automatisch mit hohem Nutzen. Gepflegte FAQ-Texte liefern oft den größten Effekt für den geringsten Aufbereitungsaufwand — ein Grund, warum sie in Projekten zuerst importiert werden sollten, statt gleich mit dem größten, unstrukturiertesten Datenbestand zu starten.

Umsetzung: Vom ersten Test zum produktiven Bot

So gehe ich in Projekten vor:

1. Einen abgegrenzten Anwendungsfall wählen. Ein FAQ-Bot für eine Produktlinie oder einen Support-Bereich ist ein anderes, kleineres Projekt als ein Bot über die gesamte Unternehmenswissensbasis. Klein anfangen erlaubt, Chunking, Embedding-Modell und Fallback-Logik an überschaubaren Daten zu testen.
2. Datenklassifizierung vor der Technikwahl. Welche Dokumente sind unkritisch, welche enthalten personenbezogene oder vertrauliche Daten? Diese Einordnung entscheidet über die Reihenfolge des Imports (siehe Matrix oben) und darüber, ob eine Datenschutz-Folgenabschätzung nötig ist.
3. Ingestion- und Abfrage-Workflow getrennt aufbauen. Nach dem Muster aus der n8n-Dokumentation: ein Workflow für das Laden, Chunking und Einbetten der Dokumente, ein zweiter für die eigentliche Bot-Anfrage. Diese Trennung erleichtert spätere Wartung erheblich.
4. Fallback- und Eskalationsregeln von Anfang an definieren. Ab welcher Ähnlichkeitsschwelle antwortet der Bot nicht mehr selbst? Wer übernimmt die Übergabe? Diese Regeln gehören in die erste Testphase, nicht in eine spätere Ausbaustufe.
5. Zugriffsrechte aus dem Quellsystem übertragen, nicht neu erfinden. Wenn ein Dokument im Ausgangssystem nur für bestimmte Rollen sichtbar ist, muss diese Beschränkung beim Import in die Vektordatenbank mitgegeben werden.
6. Parallelbetrieb mit Feedback-Schleife. Bevor der Bot den bisherigen Kanal ersetzt, läuft er unterstützend daneben, mit einer klaren Möglichkeit für Nutzer:innen, falsche Antworten zu melden — das fließt direkt in die nächste Aktualisierung der Wissensbasis ein.

Zu Aufwand und Kosten lässt sich ohne konkretes Anbieterangebot nur die Struktur benennen, keine feste Zahl. Laufende Kosten entstehen bei Cloud-Modellen und -Embeddings meist nutzungsabhängig, etwa pro Anfrage oder verarbeitetem Token; eine selbst betriebene Vektordatenbank verursacht dagegen überwiegend Infrastrukturkosten unabhängig vom Nutzungsvolumen. Der einmalige Aufbauaufwand hängt stark davon ab, wie viele Dokumenttypen aufbereitet werden müssen (siehe Matrix) und wie gut die Quellsysteme über Schnittstellen erreichbar sind — ein Bot auf Basis einer bereits gepflegten FAQ-Liste ist deutlich schneller aufgebaut als einer, der zuerst Jahre unstrukturierter Support-Tickets bereinigen muss. Belastbare Zahlen ergeben sich erst aus dem konkreten Dokumentenbestand und Anbieterangebot.

Risiken und Grenzen — ehrlich benannt

Stand Juli 2026. Das Folgende ist Orientierung, keine Rechtsberatung — für den konkreten Fall gehören Datenschutzbeauftragte und gegebenenfalls Rechtsberatung an den Tisch.

• RAG repariert kein rechtswidrig trainiertes Modell. Die Datenschutzkonferenz stellt klar, dass ein RAG-System an den grundlegenden Eigenschaften des zugrunde liegenden Sprachmodells nichts ändert — ein Modell, dessen Training rechtlich problematisch war, bleibt das auch mit RAG-Anbindung.
• Halluzinationen werden gemildert, nicht ausgeschlossen. Sowohl BSI als auch Datenschutzkonferenz beschreiben RAG als Maßnahme zur Reduktion, nicht zur vollständigen Vermeidung von Halluzinationen. Bei widersprüchlichen Inhalten kann ein Sprachmodell laut Datenschutzkonferenz dazu neigen, sein Trainingswissen gegenüber den bereitgestellten Referenzdokumenten zu bevorzugen.
• Die Wissensbasis selbst ist ein Angriffsziel. Das BSI weist ausdrücklich darauf hin, dass der Einsatz von RAG das Risiko der „Vergiftung“ hinterlegter Wissensdaten (Data Poisoning) mit sich bringt — eine neue Angriffsfläche, die ein statischer Bot in dieser Form nicht hat.
• Betroffenenrechte bleiben anspruchsvoll umzusetzen. Auskunft, Berichtigung und Löschung müssen laut Datenschutzkonferenz über alle Komponenten des RAG-Systems hinweg möglich sein — nicht nur in der Quelldatenbank, sondern auch in der Vektordatenbank und im Antwortverhalten selbst.
• Zugriffsrechte veralten, wenn niemand sie pflegt. Ein beim Rollout korrektes Rechtekonzept driftet mit jeder Reorganisation und jedem neuen Dokumenttyp auseinander, wenn keine explizite Zuständigkeit dafür existiert.
• Nicht jede Support-Anfrage gehört in einen Chatbot. Komplexe, emotionale oder individuelle Anliegen brauchen weiterhin einen Menschen — ein RAG-Bot macht Wissen schneller durchsuchbar, er ersetzt kein Eskalationskonzept.

Checkliste: Bereit für einen FAQ-Chatbot mit eigenen Daten?

Vorbereitung

• Abgegrenzter Anwendungsfall benannt (nicht „die gesamte Wissensbasis auf einmal“)
• Content-Typen nach Reifegrad sortiert (siehe Matrix) und Importreihenfolge festgelegt
• Datenklassifizierung durchgeführt: unkritisch, personenbezogen, vertraulich

Architektur

• Ingestion- und Abfrage-Workflow als getrennte Prozesse geplant
• Embedding-Modell festgelegt und für Import wie Abfrage konsistent verwendet
• Chunking-Strategie an der Dokumentstruktur ausgerichtet, nicht an fester Zeichenlänge

Antwortverhalten

• Ähnlichkeitsschwelle für „keine ausreichende Übereinstimmung“ definiert
• Fallback- und Übergabe-Logik an einen Menschen festgelegt
• Quellenanzeige vorgesehen, Referenzdokumente entsprechend mit Titel und Datum verschlagwortet

Rechte und Pflege

• Zugriffsrechte aus Quellsystemen auf die Vektordatenbank übertragen
• Rechteprüfung im Abfragepfad verankert, nicht nur beim Import
• Verantwortliche Person und Rhythmus für Aktualisierung und Löschung veralteter Inhalte benannt
• Datenschutz-Folgenabschätzung geprüft, wenn personenbezogene Daten betroffen sind

Betrieb

• Parallelbetrieb mit Feedback-Möglichkeit für Nutzer:innen geplant
• Regelmäßige Prüfung der Referenzdokumente auf Aktualität eingeplant

Wenn du beim Sortieren der eigenen Inhalte ins Stocken gerätst, ist das kein Zeichen, dass die Technik zu kompliziert ist — es zeigt nur, dass die Aufbereitung der eigenen Wissensbasis die eigentliche erste Aufgabe ist. Genau dabei hilft ein strukturierter Blick von außen, etwa in einem Erstgespräch oder im Rahmen einer KI-Beratung.