FAQ-Chatbot mit eigenen Daten: RAG statt statischer Antworten

Das Wichtigste in Kürze: Wie ein FAQ-Chatbot mit eigenen Daten per RAG aktuelle, belegte Antworten liefert: Inhalte, Architektur, Quellenanzeige, Grenzen und Vorgehen für KMU.

Das Problem: FAQ-Bots, die nicht mitwachsen

„Der Chatbot antwortet auf Fragen, die wir vor 2 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. Bei Abweichung, etwa eine andere Wortwahl, ein Tippfehler oder eine zweigeteilte Frage, 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. 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. Es geht um eine konkrete architektonische Entscheidung: ein statischer Regel-Bot oder ein Bot, der über Retrieval Augmented Generation (RAG) auf eine gepflegte, durchsuchbare Wissensbasis zugreift. Solch ein Bot formuliert Antworten, 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

3 Begriffe klären den Unterschied zwischen alter und neuer Architektur.

Statischer FAQ-Bot meint ein regelbasiertes System mit einer festen Liste von Frage-Antwort-Paaren. Er erkennt nur Formulierungen, die den hinterlegten Mustern ähnlich sind. Bei jeder inhaltlichen Änderung muss er 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. So formuliert das Modell eine Antwort, 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 werden sie 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 ist das 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 klar: Die Zuverlässigkeit eines RAG-Systems hängt stark von der Qualität, Aktualität und Vollständigkeit der Referenzdokumente ab. Unvollständige oder veraltete Daten führen zu unrichtigen Ausgaben. Menge ersetzt keine Qualität.

4 typische, geeignete Inhaltstypen 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 sind 3 Fälle:

• Interne, widersprüchliche oder mehrfach überarbeitete Dokumentversionen ohne klaren „aktuellen Stand“.
• Dokumente mit sensiblen personenbezogenen Daten ohne belastbare Rechtsgrundlage.
• 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. Zusätzlich 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?

Ein RAG-System besteht laut Datenschutzkonferenz aus 4 Kernkomponenten: Retriever, Embedding-Modell, Vektordatenbank und 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 die Anzeige der konkreten Textausschnitte, auf denen eine Antwort basiert, ausdrücklich als Maßnahme. Damit lassen sich Auswirkungen von Halluzinationen mildern. Technisch ist das bei RAG einfacher umzusetzen als bei einem reinen Sprachmodell. Der Retriever übergibt ohnehin konkrete Chunks mit Metadaten (Dokumenttitel, Abschnitt, Datum) an das Modell. Dieselbe Information lässt sich in der Antwort mit anzeigen, etwa als Verweis „Quelle: Rückgabebedingungen, Stand März 2026“.

2 Einschränkungen gehören zur ehrlichen Einordnung dazu. Erstens weist die Datenschutzkonferenz darauf hin: Die erweiterte Anfrage an das Sprachmodell lässt sich zwar nachvollziehen, nicht aber, wie genau das Modell daraus seine Formulierung erzeugt. Vollständige Transparenz über die Textgenerierung selbst bleibt begrenzt. Zweitens hilft eine Quellenanzeige nur, wenn die 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 3 belastbare Situationen ableiten, in denen ein Bot erkennbar nicht selbst antworten sollte:

Keine ausreichend nahe Übereinstimmung in der Wissensbasis. Findet der Retriever keine Chunks, deren semantische Nähe zur Anfrage groß genug ist, besteht laut Datenschutzkonferenz ein Risiko. Das Sprachmodell greift dann auf sein allgemeines, möglicherweise veraltetes oder falsches Trainingswissen zurück, statt ehrlich „das weiß ich nicht“ zu signalisieren. Insbesondere bei widersprüchlichen Inhalten neigen Sprachmodelle laut Datenschutzkonferenz dazu, Trainingswissen gegenüber den 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. Das wird über Rollen- und Rechtekonzepte auf Ebene der Vektordatenbank umgesetzt. 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 ist riskant, solche Anweisungen sind angreifbar, 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.

Tritt eine dieser 3 Situationen ein, sollte der Bot das erkennbar machen. Er übergibt dann an einen Menschen, statt eine unsichere Antwort zu formulieren. Wie dieser Übergabeprozess konkret aussieht, ist ein eigenes Thema, dazu mehr im verlinkten Artikel zum Human Handover.

Wie wird Wissen aktualisiert?

Technisch trennt sich ein produktiver RAG-Bot sinnvoll in 2 Workflows, wie es auch die n8n-Dokumentation empfiehlt. Erstens ein Ingestion-Workflow: Er lädt neue oder geänderte Dokumente, zerlegt sie in Chunks, bettet sie ein und schreibt sie in die Vektordatenbank. Zweitens ein separater 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 3 Punkte entscheidend:

• Ein definierter Auslöser für die erneute Einbettung. Ein Dokument wird sofort bei jeder Änderung neu verarbeitet oder nach festem Rhythmus (täglich, wöchentlich); die Datenschutzkonferenz verlangt eine regelmäßige Prüfung, 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 darauf hin: Beim Einfügen und beim Abfragen von Daten muss dasselbe Modell arbeiten, damit die Vektorräume kompatibel bleiben. Ein Modellwechsel erfordert 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 dazu, nicht als nachträgliche Ergänzung. Ist ein Dokument im Quellsystem nur für eine Abteilung sichtbar, muss diese Einschränkung beim Import übernommen werden. Sie wird bei jeder Abfrage erneut geprüft. Dazu zählt laut Datenschutzkonferenz eine Mandantentrennung 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 umfasst 6 typische Content-Typen und 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 Aufwand. Deshalb sollten sie in Projekten zuerst importiert werden, 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. Nutzer:innen können falsche Antworten melden, das fließt direkt in die nächste Aktualisierung der Wissensbasis ein.

Zu Aufwand und Kosten lässt sich ohne Angebot nur die Struktur benennen, keine feste Zahl. Laufende Kosten entstehen bei Cloud-Modellen meist nutzungsabhängig, etwa pro Anfrage oder Token. Eine eigene Vektordatenbank verursacht dagegen meist feste Infrastrukturkosten. Der einmalige Aufbauaufwand hängt stark von 2 Dingen ab: wie viele Dokumenttypen aufbereitet werden müssen (siehe Matrix) und wie gut die Quellsysteme per Schnittstelle erreichbar sind. Ein Bot auf Basis einer gepflegten FAQ-Liste ist schneller fertig als einer, der erst Jahre alter Tickets bereinigen muss. Belastbare Zahlen ergeben sich erst aus dem echten Dokumentenbestand und Angebot.

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: Der Einsatz von RAG bringt das Risiko der „Vergiftung“ hinterlegter Wissensdaten (Data Poisoning) mit sich. Das ist 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?

Die folgenden 5 Blöcke fassen die Punkte aus diesem Artikel zusammen.

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.

Gerätst du beim Sortieren der eigenen Inhalte ins Stocken? Das ist 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.