# RAG im Unternehmen: Unternehmenswissen, Rechte und DSGVO

> RAG mit Unternehmensdaten planen: Datenquellen, Zugriffsrechte, DSGVO und Antwortqualität prüfen. Mit Abnahmekriterien und Checkliste für den Chatbot-Start.

- URL: https://newlifedigital.de/blog/rag-im-unternehmen-wissensdatenbank/
- Autor: Simon Maiwald (https://newlifedigital.de/team/simon-maiwald/)
- Veröffentlicht: 2026-07-15
- Aktualisiert: 2026-10-20

**Kurzantwort:** RAG verbindet ein Sprachmodell mit kontrolliertem Unternehmenswissen. Vor der Antwort sucht die Anwendung passende Inhalte, prüft die Zugriffsrechte und liefert dem Modell nur freigegebene Textstellen. Der Nutzen entsteht nicht durch eine Vektordatenbank allein, sondern durch saubere Quellen, nachvollziehbare Antworten, Tests und einen verlässlichen Betrieb.

Für einen einzelnen Dateiupload reicht oft ein vorhandenes KI-Werkzeug. Ein unternehmensweites Wissenssystem ist eine andere Aufgabe: Mehrere Datenquellen ändern sich, Nutzer besitzen unterschiedliche Rechte und falsche Antworten können operative Folgen haben. Dieser Beitrag grenzt die RAG-spezifische Wissensschicht von der allgemeinen [LLM-Integration in Unternehmenssoftware](/blog/llm-integration-unternehmenssoftware/) ab.

## Was bedeutet RAG im Unternehmen?

**Kurzantwort:** Retrieval-Augmented Generation, kurz RAG, ergänzt die Eingabe eines Sprachmodells um aktuell gefundene Inhalte aus einer externen Wissensbasis. Das ursprüngliche RAG-Paper beschreibt die Verbindung aus parametrischem Modellwissen und nicht parametrischem Speicher. Im Unternehmen gehören zusätzlich Identität, Rechte, Quellenpflege, Protokollierung und Evaluation zur Lösung.

Der Begriff geht auf die Arbeit von [Lewis et al. zu Retrieval-Augmented Generation](https://arxiv.org/abs/2005.11401) zurück. Vereinfacht besteht eine Unternehmenslösung aus zwei Schritten:

1. **Retrieval:** Eine Suche findet passende Abschnitte in freigegebenen Quellen.
2. **Generation:** Ein Sprachmodell formuliert aus Frage und gefundenem Kontext eine Antwort.

RAG trainiert dem Modell nicht automatisch neues Wissen an. Die Unternehmensdaten bleiben in einer separaten Wissensschicht und werden zur Laufzeit abgerufen. Dadurch lassen sich Inhalte aktualisieren, ohne für jede Dokumentänderung ein Modell neu zu trainieren.

Das löst drei Probleme jedoch nicht von selbst:

- Eine schlechte Quelle bleibt auch im Vektorindex eine schlechte Quelle.
- Ein gefundener Text ist nicht automatisch für den fragenden Nutzer freigegeben.
- Eine sprachlich plausible Antwort ist nicht automatisch durch die Quelle gedeckt.

RAG kann das Risiko unbelegter Antworten reduzieren und Quellen sichtbar machen. Es ist keine Garantie gegen Halluzinationen. Für die Gesamtarchitektur aus Anwendung, Modellen und Schnittstellen ist unsere Seite zur [ChatGPT-, Claude- und LLM-Integration](/leistungen/chatgpt-integration-unternehmen/) der passende nächste Einstieg.

Vertiefungen zu einzelnen Entscheidungen: [RAG oder Fine-Tuning?](/blog/rag-oder-fine-tuning/), [RAG-Chatbot und DSGVO](/blog/rag-chatbot-dsgvo/) sowie [Unternehmenswissen aus SharePoint und Confluence anbinden](/blog/sharepoint-confluence-ki-wissen-anbinden/).

## Wann RAG besser passt als ein einfacher Dateiupload

**Kurzantwort:** Ein Dateiupload passt zu einer abgegrenzten Aufgabe mit wenigen, bewusst ausgewählten Dokumenten. RAG wird relevant, wenn Wissen laufend aktualisiert wird, aus mehreren Systemen stammt, für viele Nutzer verfügbar sein soll oder unterschiedlichen Zugriffsrechten unterliegt. Dann braucht die Organisation eine steuerbare Wissensschicht statt einer persönlichen Ablage.

Die Entscheidung hängt nicht von der Anzahl der PDFs allein ab. Entscheidend ist, ob das Wissen als betrieblicher Bestand geführt werden muss.

| Situation | Einfacher Dateiupload | RAG-Anwendung |
|---|---|---|
| einmalige Analyse ausgewählter Dokumente | passend | meist unnötig |
| wiederkehrende Fragen zu wechselnden Inhalten | manuelle Aktualisierung | synchronisierte Quellen sinnvoll |
| mehrere Nutzer mit verschiedenen Rollen | schnell unübersichtlich | Berechtigungsfilter erforderlich |
| Antwort muss auf Originalstellen verweisen | je nach Werkzeug | als Produktanforderung planbar |
| Nutzung in CRM, DMS oder Fachsoftware | kaum integriert | über definierte Schnittstellen möglich |
| Qualitäts- und Freigabeprozess | häufig personengebunden | zentral mess- und steuerbar |

Ein gutes RAG-Projekt startet deshalb nicht mit „Wir indexieren alles“. Es startet mit einem klaren Arbeitsprozess: Wer stellt welche Frage, aus welchen Quellen darf die Antwort kommen und was passiert, wenn keine belastbare Quelle gefunden wird?

## Welche Datenquellen sich eignen

**Kurzantwort:** Gute RAG-Quellen sind fachlich verantwortlich, aktuell, strukturell erreichbar und mit eindeutigen Zugriffsrechten versehen. Häufig eignen sich DMS, Wiki, Intranet, freigegebene Produktdaten sowie ausgewählte CRM- oder ERP-Inhalte. Ungepflegte Netzlaufwerke, private Postfächer und Dubletten verschlechtern die Antwortqualität und erhöhen Datenschutz- und Betriebsrisiken.

Vor der technischen Anbindung braucht jede Quelle einen fachlichen Eigentümer. Diese Person oder Rolle entscheidet, welche Inhalte verbindlich sind, wie Aktualisierungen erfolgen und wann Dokumente entfernt werden.

| Datenquelle | Typischer Nutzen | Vor der Indexierung klären |
|---|---|---|
| DMS und Vertragsablage | Richtlinien, Vorlagen, Verträge | Version, Gültigkeit, Mandanten- und Projektzugriff |
| Wiki und Intranet | Prozesse, Handbücher, interne FAQs | Verantwortliche, Freigabestatus, veraltete Seiten |
| CRM und ERP | Kunden-, Produkt- oder Auftragskontext | Feldrechte, Aktualität, Zweck der Verarbeitung |
| Ticketsystem | gelöste Fälle und Supportwissen | personenbezogene Daten, Qualitätsstatus, Aufbewahrung |
| Datenbank oder Fach-API | strukturierte, aktuelle Fakten | erlaubte Felder, Abfragelogik, Last und Fehlerfälle |

In einer Steuerkanzlei können beispielsweise Fachanweisungen, interne Prozessbeschreibungen und freigegebene Mandatsvorlagen sinnvoll sein. Mandantenakten dürfen dagegen nicht in einem gemeinsamen Wissensraum landen. Wie wir solche Prozesse fachlich eingrenzen, zeigt die Branchenseite [KI und Software für Steuerkanzleien](/branchen/steuerkanzleien/).

Für jede Quelle sollte ein kleines Register existieren:

- fachlicher und technischer Eigentümer
- Zweck und zulässige Nutzergruppen
- Datenklassen und personenbezogene Inhalte
- Aktualisierungs- und Löschweg
- maßgebliche Version oder Gültigkeitsdatum
- Verhalten bei nicht erreichbarer Quelle

Diese Vorarbeit wirkt unspektakulär. Sie entscheidet aber, ob das System verlässliches Wissen liefert oder nur veraltete Dokumente schneller zusammenfasst.

## Architektur: Berechtigungen vor der Antwort prüfen

**Kurzantwort:** Ein sicheres RAG-System übernimmt die Identität des Nutzers und filtert Suchtreffer, bevor ein Textabschnitt das Sprachmodell erreicht. Berechtigungen sollten aus dem führenden Quellsystem stammen oder eindeutig zentral verwaltet werden. „Deny by default“, dokumentbezogene Metadaten und Tests gegen unzulässige Zugriffe gehören in den Kern der Architektur.

Der wichtigste Grundsatz lautet: **Das Sprachmodell darf niemals entscheiden, ob ein Nutzer ein Dokument sehen darf.** Diese Entscheidung fällt deterministisch in der Anwendung und vor der Generierung.

Ein belastbarer Ablauf sieht so aus:

1. Der Nutzer meldet sich über die Unternehmensidentität an.
2. Die Anwendung ermittelt Rollen, Gruppen und gegebenenfalls Mandanten- oder Projektkontext.
3. Die Suche filtert Kandidaten anhand dieser Rechte.
4. Nur zulässige Abschnitte werden an das Sprachmodell übergeben.
5. Die Antwort verweist auf freigegebene Originalquellen.
6. Anfrage, verwendete Quellen und Systementscheidung werden angemessen protokolliert.

Die Rechte müssen mit den Inhalten wandern. Beim Import erhält jedes Dokument Metadaten für Quelle, Eigentümer, Version, Datenklasse und erlaubte Gruppen. Wird ein langes Dokument in kleinere Abschnitte zerlegt, dürfen diese Abschnitte ihre Berechtigungsinformationen nicht verlieren.

Besonders kritisch sind Änderungen: Verlässt ein Mitarbeiter ein Projekt oder wird ein Dokument gesperrt, muss diese Änderung auch in Suche, Cache und Index wirksam werden. Ein Link auf die Originalquelle ist hilfreich für die Nachvollziehbarkeit, ersetzt aber keinen Filter. Schon der Text in der generierten Antwort kann vertraulich sein.

## Evaluation: Suche und Antwort getrennt testen

**Kurzantwort:** RAG-Qualität besteht aus mehreren messbaren Teilen: Findet die Suche die richtige Quelle, bleibt die Antwort beim gefundenen Kontext, enthält sie die erforderlichen Kernaussagen und verweigert sie unbelegbare Fragen? Ein festes Eval-Set prüft diese Dimensionen getrennt und wird bei jeder relevanten Systemänderung erneut ausgeführt.

Das Paper [Ragas: Automated Evaluation of Retrieval Augmented Generation](https://arxiv.org/abs/2309.15217) trennt unter anderem die Relevanz des gefundenen Kontexts, die treue Nutzung dieses Kontexts und die Qualität der erzeugten Antwort. Für ein Unternehmen reicht eine automatische Kennzahl allein trotzdem nicht aus. Fachverantwortliche müssen definieren, was eine akzeptable Antwort im konkreten Prozess bedeutet.

Ein praxistaugliches Eval-Set enthält:

- reale, anonymisierte oder synthetisch nachgebildete Nutzerfragen
- die zulässigen Referenzquellen
- erwartete Kernaussagen, nicht nur eine einzige Musterformulierung
- Fragen, für die das System bewusst keine Antwort geben darf
- veraltete oder widersprüchliche Dokumente
- Berechtigungstests für verschiedene Rollen und Mandanten
- Fälle mit Tippfehlern, Abkürzungen und interner Fachsprache

Die Auswertung sollte mindestens fünf Ebenen unterscheiden:

| Ebene | Leitfrage |
|---|---|
| Retrieval | Wurden die fachlich passenden Abschnitte gefunden? |
| Berechtigung | Waren alle verwendeten Inhalte für den Nutzer zulässig? |
| Quellentreue | Ist jede wesentliche Aussage durch den Kontext gedeckt? |
| Antwortnutzen | Beantwortet das Ergebnis die Frage vollständig und verständlich? |
| Abbruchverhalten | Sagt das System klar, wenn Wissen fehlt oder widersprüchlich ist? |

Ein Modell- oder Promptwechsel ist nur eine mögliche Änderung. Auch neue Dokumente, anderes Chunking, ein Embedding-Wechsel oder eine neue Suchgewichtung können Ergebnisse verschieben. Deshalb gehört das Eval-Set als wiederholbares Freigabe-Gate in den Betrieb.

## RAG-Chatbot und DSGVO: RAG ist nicht automatisch datenschutzkonform

**Kurzantwort:** DSGVO-Konformität hängt vom gesamten Verarbeitungspfad ab, nicht vom Begriff RAG. Zu klären sind Zweck, Rechtsgrundlage, Datenminimierung, Speicherfristen, Empfänger, Auftragsverarbeitung und Betroffenenrechte. Zugriffe, Index, Caches und Logs brauchen passende Schutzmaßnahmen. Besonders sensible Quellen sollten erst nach Datenschutz- und Risikoprüfung angebunden werden.

Der offizielle [Text der Datenschutz-Grundverordnung](https://eur-lex.europa.eu/eli/reg/2016/679/oj/eng) nennt in Artikel 5 unter anderem Zweckbindung, Datenminimierung, Speicherbegrenzung sowie Integrität und Vertraulichkeit. Artikel 25 verlangt Datenschutz durch Technikgestaltung und datenschutzfreundliche Voreinstellungen. Artikel 32 fordert ein dem Risiko angemessenes Schutzniveau und regelmäßige Wirksamkeitsprüfungen. Die [DSK-Orientierung zu generativen KI-Systemen mit RAG-Methode](https://www.datenschutzkonferenz-online.de/media/oh/DSK_OH_RAG.pdf) konkretisiert die datenschutzrechtlichen Besonderheiten für genau diese Architektur.

Für ein RAG-System folgen daraus konkrete Arbeitsaufträge:

- **Nur erforderliche Quellen anbinden.** Eine technisch erreichbare Ablage ist nicht automatisch eine zulässige Datenquelle.
- **Personenbezogene Inhalte klassifizieren.** Das gilt auch für Dokumenttext, Metadaten, Suchanfragen und Feedback.
- **Löschung durchgängig planen.** Entfernte Daten dürfen nicht unbemerkt in Index, Cache, Backup oder Protokoll fortleben.
- **Provider und Unterauftragnehmer prüfen.** Vertrag, Verarbeitungsort, Datenverwendung und technische Schutzmaßnahmen müssen zum Einsatz passen.
- **Protokolle begrenzen.** Vollständige Fragen und Antworten können selbst vertrauliche oder personenbezogene Daten enthalten.
- **Rechte restriktiv voreinstellen.** Neue Nutzer oder Quellen erhalten nicht automatisch breiten Zugriff.
- **Risiken dokumentieren.** Ob eine Datenschutz-Folgenabschätzung erforderlich ist, muss für den konkreten Verarbeitungsvorgang geprüft werden.

RAG kann Datenschutz unterstützen, weil Quellen, Zugriffe und Löschwege kontrollierbar gestaltet werden können. Es kann Datenschutz aber ebenso verschlechtern, wenn vormals getrennte Wissensbestände ohne Zweck- und Rechteprüfung zusammengeführt werden. Der [DSGVO-Leitfaden für ChatGPT und Claude im Unternehmen](/blog/dsgvo-konforme-ki-integration-2026/) führt die organisatorischen Prüfschritte zusammen; die strategische Einordnung finden Sie im Pillar [KI im Mittelstand](/themen/ki-im-mittelstand/). Wie Sie einen RAG-Chatbot vor dem Start datenschutzrechtlich prüfen, beschreibt der Ratgeber [RAG-Chatbot und DSGVO](/blog/rag-chatbot-dsgvo/) Schritt für Schritt.

## Was RAG im Unternehmen kostet

**Kurzantwort:** Der fünftägige NLD-Discovery-Sprint kostet 4.900 Euro netto und liefert eine Live-Demo, Bewertung und Entscheidungsempfehlung. Ein produktiver Custom-Build wird danach anhand von Datenquellen, Integrationen, Berechtigungen und Betriebsanforderungen individuell zum Festpreis angeboten. Laufende Infrastruktur- und Modellkosten werden anhand des erwarteten Nutzungsmusters separat kalkuliert.

Für den Build entsteht ein belastbarer Festpreis erst nach Prüfung von Scope, Daten und Betriebsanforderungen. Die Discovery gibt dafür die Entscheidungsgrundlage; die Beauftragung des Builds bleibt optional.

Bei RAG treiben vor allem diese Faktoren den Aufwand:

- Anzahl und technische Qualität der Datenquellen
- vorhandene Schnittstellen und Änderungsereignisse
- Rollen, Mandanten und Granularität der Berechtigungen
- Aufbereitung, Klassifikation und Dublettenbereinigung
- Umfang des fachlichen Eval-Sets
- Anforderungen an Hosting, Protokollierung und Verfügbarkeit
- Lösch-, Freigabe- und Eskalationsprozesse

Die laufenden Kosten bestehen nicht nur aus dem Sprachmodell. Hinzu kommen Suche oder Vektorspeicher, Hosting, Datenübertragung, Monitoring, regelmäßige Synchronisation und Pflege. Eine pauschale Monatszahl wäre ohne Dokumentvolumen, Änderungsrate, Anfragezahl und Kontextgröße nicht seriös.

## POC-Checkliste: RAG in einem Prozess beweisen

**Kurzantwort:** Ein guter RAG-POC beweist nicht, dass ein Chatfenster Text erzeugt. Er prüft einen konkreten Arbeitsprozess mit echten Quellen, realistischen Nutzerrollen und einem vorab definierten Eval-Set. Am Ende steht eine Build-, Änderungs- oder Stop-Entscheidung mit dokumentierten Qualitäts-, Datenschutz-, Integrations- und Betriebsergebnissen für den verantwortlichen Fachbereich.

Vor dem Start sollten diese Punkte beantwortet sein:

1. **Use-Case:** Welche konkrete Entscheidung oder Recherche soll schneller und verlässlicher werden?
2. **Nutzer:** Welche Rollen fragen das System, und welche Inhalte dürfen sie jeweils sehen?
3. **Quellen:** Welche wenigen, fachlich verantworteten Datenbestände reichen für den Beweis?
4. **Aktualität:** Wie gelangen Änderungen und Löschungen in den Index?
5. **Antwortgrenze:** Wann muss das System ablehnen, nachfragen oder an einen Menschen übergeben?
6. **Evaluation:** Welche realen Fragen, Referenzquellen und verbotenen Zugriffe bilden das Testset?
7. **Datenschutz:** Welche personenbezogenen Daten, Verträge und Löschpflichten sind betroffen?
8. **Betrieb:** Wer verantwortet Quellenqualität, Rechte, Monitoring und Freigaben nach dem POC?
9. **Decision-Gate:** Welche Erkenntnisse rechtfertigen Build, Nachbesserung oder Stopp?

Der POC sollte absichtlich auch schwierige Fälle enthalten: fehlende Quellen, widersprüchliche Versionen, einen Nutzer ohne Berechtigung und eine Frage außerhalb des Wissensbestands. Nur so zeigt sich, ob die Anwendung im Alltag sicher scheitert. Die Abgrenzung zur nächsten Betriebsstufe erklärt [POC-First vs. Pilot-First](/blog/poc-first-vs-pilot-first/).

## Die pragmatische Entscheidung

RAG lohnt sich nicht, weil ein Unternehmen viele Dokumente besitzt. Es lohnt sich, wenn ein klarer Prozess regelmäßig auf verteiltes Wissen zugreifen muss und Aktualität, Berechtigungen sowie Nachvollziehbarkeit produktseitig gelöst werden sollen.

Der sinnvolle Einstieg ist klein: ein Prozess, wenige verantwortete Quellen, reale Rollen und ein ehrliches Testset. Wenn dieser Beweis trägt, werden weitere Quellen und Nutzergruppen kontrolliert ergänzt. Wenn die Datenlage oder der Geschäftsfall nicht trägt, ist ein früher Stopp das richtige Ergebnis.

[RAG-Use-Case und Datenlage im Discovery-Sprint prüfen →](/kontakt/?source=rag-wissensdatenbank)

---

*Geschrieben von [Simon Maiwald](/team/simon-maiwald/), Gründer von New Life Digital im MAFINEX Mannheim. NLD plant und baut KI-Integrationen für den Mittelstand mit klaren Daten-, Rechte- und Qualitätsgrenzen.*