Was kostet ein RAG-System? Daten, Entwicklung und Betrieb

Worum es geht — und für wen

„Wir haben das Wissen doch alles da — im Wiki, im Laufwerk, in alten Angeboten. Kann eine KI das nicht einfach beantworten?” So oder ähnlich beginnen die meisten Gespräche über RAG-Systeme. Die Idee ist gut: Statt einem Sprachmodell blind zu vertrauen, bekommt es bei jeder Frage die passenden Auszüge aus deinen eigenen Dokumenten mitgeliefert und antwortet auf dieser Grundlage. Interner Wissensassistent, Support-Antworten aus der eigenen Doku, Angebotsrecherche — das sind typische Einsatzfälle.

Die Kostenfrage ist dabei schwerer zu beantworten, als Anbieter-Landingpages suggerieren. Nicht, weil die Technik teuer wäre — die Modell- und Infrastrukturkosten sind bei KMU-Volumina meist der kleinste Posten. Sondern weil der Aufwand fast vollständig von Dingen abhängt, die vor dem ersten Prompt liegen: dem Zustand deiner Dokumente, der Frage, wer was sehen darf, und wie gründlich du prüfst, ob die Antworten stimmen.

Dieser Artikel richtet sich an Geschäftsführung, Operations, IT und Fachbereiche in KMU, die ein RAG-Projekt budgetieren wollen. Er zerlegt die Kosten in fünf Blöcke, zeigt an einem Rechenmodell mit offengelegten Annahmen, wie sich ein Pilot kalkulieren lässt — und benennt ehrlich, wo die Bandbreiten herkommen.

Begriffe kurz sortiert: Was ein RAG-System technisch ist

RAG steht für Retrieval Augmented Generation. Die Datenschutzkonferenz (DSK), das Gremium der deutschen Datenschutzaufsichtsbehörden, hat im Oktober 2025 eine Orientierungshilfe zu RAG-Systemen veröffentlicht und definiert dort die vier Kernkomponenten: ein Embedding-Modell, das Textabschnitte in Vektoren überführt, eine Vektordatenbank, die diese Vektoren speichert, ein Retriever, der zur Nutzerfrage die inhaltlich nächsten Abschnitte findet, und das generative Sprachmodell, das aus Frage plus gefundenen Abschnitten die Antwort formuliert.

Vorgeschaltet ist die Datenaufbereitung: Deine Referenzdokumente werden bereinigt und in kürzere Abschnitte („Chunks”) aufgeteilt. Die DSK betont, dass genau dieser Schritt die Qualität der späteren Antworten maßgeblich beeinflusst — störende Elemente wie Kopf- und Fußzeilen sollten entfernt, Chunks als möglichst abgeschlossene Sinnabschnitte geschnitten werden. Die n8n-Dokumentation, stellvertretend für die Workflow-Plattformen, mit denen solche Systeme häufig gebaut werden, empfiehlt für die meisten Fälle Chunk-Größen von etwa 200 bis 500 Token mit Überlappung und trennt sauber zwischen zwei Workflows: der Ingestion (Dokumente laden, aufteilen, einbetten, speichern) und der Abfrage (Frage einbetten, relevante Chunks holen, Antwort generieren).

Zwei Abgrenzungen, die für die Kostenschätzung wichtig sind: RAG ist kein Nachtraining — das Sprachmodell selbst wird nicht verändert, die Wissensbasis lässt sich jederzeit aktualisieren und einzelne Einträge lassen sich gezielt löschen. Und RAG ist kein fertiges Produkt, sondern ein Architekturmuster: Es steckt in SaaS-Angeboten („Chat mit deinen Dokumenten”) genauso wie in individuell gebauten Systemen. Dieser Artikel betrachtet vor allem den individuellen Aufbau, weil dort die Kostenfrage am offensten ist.

Welche Kostenblöcke hat RAG?

Fünf Blöcke, grob in der Reihenfolge des Projektverlaufs:

1. Datenaufbereitung. Dokumentenbestand sichten, Veraltetes und Doppeltes aussortieren, Formate vereinheitlichen, Bereinigung und Chunking einrichten. Hierhin gehört auch die Klärung, welche Dokumente überhaupt hinein dürfen — inklusive Datenschutz-Sicht, wenn personenbezogene Daten enthalten sind.
2. Entwicklung. Ingestion-Workflow, Abfrage-Workflow, Anbindung an die Oberfläche (Chat, Intranet, Ticketsystem), Berechtigungslogik, Fehlerbehandlung, Quellenanzeige in den Antworten.
3. Modell- und Infrastrukturkosten. Embedding-Aufrufe (einmalig für den Bestand, laufend für Neues), LLM-Aufrufe pro Anfrage, Vektordatenbank, Hosting der Workflow-Umgebung.
4. Evaluation. Testfragen-Katalog, systematisches Prüfen der Antworten gegen die Quelldokumente, Nachjustieren von Chunking, Retrieval und Prompt, Wiederholung nach jeder Änderung.
5. Betrieb. Wissensbasis aktuell halten, Monitoring, Nutzerfeedback auswerten, Modell- und Plattform-Updates nachziehen.

Die verbreitete Fehlannahme ist, dass Block 2 und 3 das Budget dominieren. In meinen Projekten ist es fast immer umgekehrt: Die Blöcke 1, 4 und 5 — also Datenarbeit, Qualitätssicherung und Pflege — machen zusammen den größeren Teil aus. Sie bestehen überwiegend aus Menschenzeit, nicht aus Technik, und sie lassen sich nicht wegoptimieren, ohne dass die Antwortqualität leidet.

Wie beeinflussen Dokumente und Rechte den Aufwand?

Das ist der eigentliche Kostenhebel — in beide Richtungen.

Dokumentenqualität. Die DSK formuliert es nüchtern: Die Zuverlässigkeit von RAG-Systemen hängt stark von Qualität, Aktualität und Vollständigkeit der Referenzdokumente ab; unvollständige oder veraltete Daten führen zu unrichtigen Ausgaben. In der Praxis heißt das: Ein RAG-System macht den Zustand deiner Dokumentation gnadenlos sichtbar. Liegen drei Versionen derselben Prozessbeschreibung im Laufwerk, davon zwei veraltet, wird der Retriever irgendwann die falsche finden — und die Antwort klingt trotzdem überzeugend. Der Aufwand für das Sichten und Bereinigen skaliert deshalb weniger mit der Menge der Dokumente als mit ihrer Unordnung. Ein gepflegtes Wiki mit klarer Struktur ist in Tagen angebunden; ein historisch gewachsenes Ablage-Laufwerk kann Wochen an Fachbereichszeit kosten, bevor sich die Anbindung lohnt.

Formate. Sauberes Markdown oder HTML ist schnell verarbeitet. Eingescannte PDFs, Tabellen in Fließtext-Dokumenten, Screenshots von Anleitungen — all das braucht zusätzliche Verarbeitungsschritte und erhöht die Fehlerquote beim Chunking.

Rechte und Berechtigungen. Der zweite große Hebel. Wenn alle Nutzenden dieselbe Wissensbasis sehen dürfen, ist die Architektur einfach. Sobald das nicht gilt — Gehaltsthemen nur für HR, Kundenverträge nur fürs Key-Account, Mandantendaten getrennt — brauchst du ein Rechte- und Rollenkonzept auf Ebene der Vektordatenbank und der Referenzdokumente. Die DSK beschreibt das ausdrücklich als notwendige Maßnahme: Zugangsbeschränkungen und Mandantentrennung müssen im RAG-Subsystem umgesetzt werden, weil sich im Sprachmodell selbst nicht steuern lässt, wer welche Informationen sehen darf. Technisch ist das lösbar — aber es zieht sich durch alles: Ingestion muss Berechtigungen mitführen, der Retriever muss filtern, und die Evaluation muss zusätzlich prüfen, dass niemand Antworten aus Dokumenten bekommt, die er nicht sehen dürfte. Als grobe Faustregel aus meinen Projekten: Ein sauberes Berechtigungskonzept kann den Entwicklungs- und Testaufwand gegenüber der „alle sehen alles”-Variante etwa verdoppeln. Deshalb lohnt die frühe Gegenfrage: Braucht der Pilot wirklich differenzierte Rechte — oder startest du mit einem Dokumentenbestand, den ohnehin alle sehen dürfen?

Personenbezogene Daten. Enthalten die Referenzdokumente personenbezogene Daten, braucht die Verarbeitung eine Rechtsgrundlage, und die DSK erwartet, dass nicht erforderliche personenbezogene Daten vor der Einbettung entfernt oder anonymisiert werden. Das ist kein reines Compliance-Thema, sondern ein Aufwandsposten in Block 1 — und ein Grund, früh den Datenschutzbeauftragten einzubeziehen. (Stand Juli 2026; keine Rechtsberatung — für die datenschutzrechtliche Bewertung im Einzelfall sind die Orientierungshilfe der DSK und dein Datenschutzbeauftragter die richtigen Anlaufstellen.)

Welche Modellkosten entstehen?

Modellkosten fallen an zwei Stellen an, und beide sind gut kalkulierbar, sobald du dein Volumen kennst:

Einmalig: Einbettung des Bestands. Jeder Chunk wird einmal durch das Embedding-Modell geschickt. Embedding-Modelle sind pro Token deutlich günstiger als generative Modelle; selbst für zehntausende Seiten liegt dieser Posten üblicherweise weit unter dem, was eine einzige Stunde Beratung kostet. Er fällt erneut an, wenn du das Embedding-Modell wechselst — dann muss der gesamte Bestand neu eingebettet werden. Das ist der Grund, die Modellwahl am Anfang bewusst zu treffen: Die n8n-Dokumentation weist etwa darauf hin, dass kleinere Embedding-Modelle schneller und günstiger sind, größere wie text-embedding-3-large dafür komplexe Inhalte besser abbilden. Für deutschsprachige Dokumente kommt die Anforderung der DSK dazu, ein Modell zu wählen, das mit deutschsprachigen Texten umgehen kann — sonst findet der Retriever weniger relevante Abschnitte.

Laufend: Kosten pro Anfrage. Jede Nutzerfrage kostet ein Embedding (winzig) plus einen LLM-Aufruf, dessen Preis vor allem von der Menge des mitgeschickten Kontexts abhängt — also davon, wie viele und wie große Chunks du pro Anfrage anreicherst. Konkrete Tokenpreise nenne ich hier bewusst nicht: Sie ändern sich zu schnell, als dass eine Zahl in diesem Artikel verlässlich bliebe. Die Preislisten der Anbieter sind öffentlich; rechne mit deinem erwarteten Volumen selbst nach. Die Größenordnung aus der Praxis: Bei einem internen Assistenten mit ein paar hundert Anfragen pro Tag liegen die reinen API-Kosten typischerweise im niedrigen zwei- bis dreistelligen Eurobereich pro Monat — und damit fast immer unter den Hosting- und deutlich unter den Personalkosten.

Infrastruktur. Dazu kommen Vektordatenbank und Workflow-Umgebung. Beides gibt es als Cloud-Dienst mit monatlicher Gebühr oder selbst gehostet — n8n etwa lässt sich self-hosted betreiben, gängige Vektordatenbanken wie PGVector laufen auf einem vorhandenen Postgres. Self-Hosting senkt die laufenden Lizenzkosten und kann datenschutzrechtlich attraktiv sein — die DSK hebt hervor, dass die RAG-Methode oft den Einsatz kleinerer, gegebenenfalls on-premise betriebener Sprachmodelle ermöglicht, sodass keine personenbezogenen Daten an Online-Betreiber großer Modelle übertragen werden müssen. Es verschiebt aber Aufwand in den Betrieb: Updates, Backups und Absicherung liegen dann bei dir.

Was kostet Evaluation?

Evaluation ist der Block, der in Angeboten am häufigsten fehlt — und im Betrieb am teuersten wird, wenn er gefehlt hat.

Ein RAG-System kann an mehreren Stellen gleichzeitig falsch liegen: Das Chunking zerschneidet Sinnzusammenhänge, der Retriever findet die falschen Abschnitte, das Sprachmodell ignoriert den mitgelieferten Kontext und antwortet aus seinem Trainingswissen. Die DSK benennt genau diese Punkte als bleibende Herausforderungen und empfiehlt unter anderem einen Systemprompt, der das System anweist, ausschließlich anhand der referenzierten Quellen zu antworten. Ob das in deinem Fall funktioniert, weißt du erst, wenn du es misst.

Praktisch heißt Evaluation: Der Fachbereich sammelt echte Fragen aus dem Alltag — inklusive der schwierigen, mehrdeutigen und der Fälle, in denen die richtige Antwort „das steht nirgends” lautet. Für jede Frage wird festgehalten, was die korrekte Antwort wäre und aus welchem Dokument sie stammen müsste. Dann wird systematisch geprüft: Stimmt die Antwort? Stimmt die zitierte Quelle? Antwortet das System auch dann ehrlich, wenn die Wissensbasis nichts hergibt? Nach jeder Änderung an Chunking, Retrieval oder Prompt läuft der Katalog erneut.

Als Budgetposten: Rechne für einen Piloten mit mehreren Personentagen, verteilt auf Fachbereich (Testfragen, Bewertung) und Umsetzer (Nachjustieren) — in meinem Rechenmodell unten sind es fünf Tage, bei Berechtigungsprüfungen entsprechend mehr. Das wirkt viel für „Testen”. Aber Evaluation ist bei RAG kein Abnahmeschritt, sondern der Mechanismus, der aus einem Demo-Effekt ein verlässliches Werkzeug macht. Ohne sie merkst du Qualitätsprobleme erst, wenn Mitarbeitende dem System nicht mehr vertrauen — und dann ist die Akzeptanz schwer zurückzugewinnen.

Rechenmodell: Pilot „interner Wissensassistent” mit offenen Annahmen

Damit die Bandbreiten greifbar werden, hier ein Rechenmodell für einen typischen Piloten. Alle Zahlen sind Annahmen, keine Messwerte — sie machen die Kalkulation nachvollziehbar, damit du sie mit deinen eigenen Werten überschreiben kannst.

Annahmen: Wissensbasis aus einem einzelnen, halbwegs gepflegten Bestand (z. B. QM-Handbuch plus Prozessdoku, niedriger vierstelliger Seitenumfang). Alle Pilot-Nutzenden dürfen alle Dokumente sehen (keine differenzierten Rechte). Umsetzung auf einer Workflow-Plattform mit Cloud-Vektordatenbank. Externer Tagessatz 900–1.400 €, wie er für erfahrene Freelancer und kleine Agenturen in Deutschland üblich ist. Interne Zeit ist mit aufgeführt, weil sie real ist — auch wenn sie nicht auf der Rechnung steht.

Kostenblock	Extern (Tage)	Intern (Tage)	Extern (€, bei 900–1.400 €/Tag)
Scoping, Dokumentensichtung, Datenschutz-Klärung	2–3	2–4	1.800–4.200
Datenaufbereitung & Ingestion-Workflow	3–5	1–2	2.700–7.000
Abfrage-Workflow, Oberfläche, Quellenanzeige	4–6	1	3.600–8.400
Evaluation (Testkatalog, 2 Testrunden, Nachjustieren)	3–5	2–3	2.700–7.000
Übergabe, Doku, Einweisung	1–2	1	900–2.800
Summe Pilot	13–21	7–11	11.700–29.400

Dazu laufend (Annahmen: einige hundert Anfragen/Tag, Cloud-Betrieb): API- und Modellkosten im niedrigen zwei- bis dreistelligen Eurobereich pro Monat, Vektordatenbank und Workflow-Plattform je nach Anbieter und Volumen typischerweise ein niedriger bis mittlerer dreistelliger Betrag pro Monat, plus etwa ein bis zwei interne Personentage pro Monat für Pflege der Wissensbasis und Auswertung des Feedbacks.

Was das Modell nach oben treibt: differenzierte Berechtigungen (Entwicklung und Evaluation grob verdoppeln), unaufgeräumte oder gescannte Dokumentbestände (Block 1 und 2 wachsen zuerst), Anbindung mehrerer Quellsysteme mit automatischer Synchronisation, On-Premise-Betrieb inklusive eigener Modell-Infrastruktur. Ein Vollausbau mit mehreren Quellen, Rechtekonzept und sauberem Betriebsmodell liegt deshalb schnell beim Zwei- bis Dreifachen des Piloten. Was es nach unten drückt: ein einzelner, gepflegter Dokumentenbestand, ein klar umrissener Nutzerkreis — oder die ehrliche Erkenntnis, dass ein fertiges SaaS-Werkzeug für deinen Fall reicht und du gar kein individuelles System brauchst.

Wann lohnt ein Pilot?

Ein Pilot ist die richtige Antwort, wenn drei Bedingungen zusammenkommen: Es gibt einen klar umrissenen Dokumentenbestand, der als Wissensbasis taugt. Dieselben Fragen binden heute wiederholt Arbeitszeit — im Support, im Vertriebsinnendienst, beim Onboarding. Und eine Person im Fachbereich hat tatsächlich Zeit, Testfragen zu liefern und Antworten zu bewerten.

Der Pilot beantwortet dann die Frage, die sich vorab nicht seriös beantworten lässt: Sind deine Dokumente gut genug, dass die Antworten verlässlich werden? Das ist der eigentliche Erkenntnisgewinn — nicht die Demo. Deshalb gehört in jeden Pilot ein definiertes Abbruchkriterium: Wenn die Evaluationsrunden zeigen, dass die Wissensbasis grundlegend überarbeitet werden müsste, ist „erst Doku aufräumen, dann RAG” das richtige Ergebnis, kein gescheitertes Projekt.

Gegen einen Piloten — oder für einen späteren Zeitpunkt — spricht: wenn das Wissen vor allem in Köpfen statt in Dokumenten steckt, wenn der erhoffte Nutzen auf komplexem Schlussfolgern über viele Dokumente hinweg beruht (die DSK benennt als systembedingte Schwäche, dass logisch zusammengehörige, aber semantisch entfernte Informationen vom Retriever unvollständig gefunden werden), oder wenn niemand die Pflege der Wissensbasis übernehmen wird. Ein RAG-System ohne Pflegeverantwortliche veraltet ab dem ersten Tag.

Umsetzung: In welcher Reihenfolge vorgehen

1. Anwendungsfall schärfen. Eine Nutzergruppe, eine Frageklasse, ein Dokumentenbestand. „Chat über alles” ist kein Pilot-Scope.
2. Dokumente sichten, bevor irgendetwas gebaut wird. Stichprobe ziehen: Sind die Inhalte aktuell, eindeutig, digital sauber lesbar? Hier entscheidet sich das halbe Budget.
3. Rechtefrage explizit klären. „Dürfen alle Pilot-Nutzenden alles sehen?” — die Antwort verändert Architektur und Kosten grundlegend, also gehört sie vor die Angebotsphase.
4. Datenschutz früh einbinden. Prüfen, ob personenbezogene Daten in die Wissensbasis gelangen, und die Orientierungshilfe der DSK als Referenz nutzen.
5. Klein bauen, mit Quellenanzeige. Jede Antwort soll zeigen, aus welchem Dokument sie stammt — das schafft Vertrauen und macht Fehler diagnostizierbar.
6. Evaluieren, nachjustieren, erst dann ausrollen. Testkatalog vor dem ersten Nutzerkontakt, Wiederholung nach jeder Änderung.
7. Betrieb organisieren. Pflegeverantwortung, Feedback-Kanal, fester Rhythmus für die Aktualisierung der Wissensbasis.

Wenn du für Schritt 1 bis 3 einen Sparringspartner willst: Genau dafür ist meine KI-Beratung gedacht — und wer intern Kompetenz aufbauen will, findet in den Schulungen das passende Format. Weitere Kostenartikel zu KI-Projekten sammelt die Übersicht Kosten & ROI.

Risiken und Grenzen — ehrlich benannt

• Überzeugend falsche Antworten. RAG reduziert Halluzinationen, verhindert sie aber nicht — die DSK stellt klar, dass unrichtige Ausgaben trotz RAG nicht vollständig ausgeschlossen werden können. Quellenanzeige und Evaluation sind Pflicht, kein Nice-to-have.
• Die Wissensbasis veraltet. Ohne Pflegeprozess beantwortet das System in einem Jahr Fragen mit dem Stand von heute. Budgetiere Betrieb als Dauerkosten, nicht als Restposten.
• Rechte lassen sich nicht nachrüsten wie ein Feature. Wer mit „alle sehen alles” startet und später Mandantentrennung braucht, baut Ingestion, Retrieval und Tests substanziell um. Die Entscheidung gehört an den Anfang.
• Komplexes Schlussfolgern bleibt schwach. Wenn die richtige Antwort erst aus der Kombination mehrerer, semantisch weit auseinanderliegender Stellen entsteht, stößt das Muster an Grenzen. Für solche Fälle sind andere Ansätze oder ein Mensch die bessere Antwort.
• Keine Garantie auf Rechtskonformität. Ein RAG-System ist datenschutzrechtlich im Einzelfall zu bewerten; die DSK-Orientierungshilfe ist Orientierung, kein Freibrief. Stand Juli 2026.

Checkliste: Bist du bereit für eine belastbare Kostenschätzung?

• Der Anwendungsfall ist auf eine Nutzergruppe und eine Frageklasse eingegrenzt
• Der Dokumentenbestand ist benannt und eine Stichprobe auf Aktualität geprüft
• Die Rechtefrage ist beantwortet: alle sehen alles — oder Rollenkonzept nötig?
• Geklärt, ob personenbezogene Daten in die Wissensbasis gelangen (Datenschutz einbezogen)
• Erwartetes Anfragevolumen grob geschätzt (Anfragen pro Tag, Nutzerzahl)
• Cloud vs. Self-Hosting als Präferenz diskutiert, inklusive Betriebskonsequenzen
• Eine Person im Fachbereich hat Zeit für Testfragen und zwei Evaluationsrunden zugesagt
• Pflegeverantwortung für die Wissensbasis nach dem Go-live ist benannt
• Ein Abbruchkriterium für den Piloten ist definiert
• Budgetrahmen deckt alle fünf Blöcke — nicht nur die Entwicklung

Wenn du die Hälfte davon noch nicht beantworten kannst, ist das kein Hindernis, sondern der Arbeitsplan für das Erstgespräch.