RAG im Unternehmen: Unternehmenswissen sicher mit KI nutzen

Kurzantwort: Was ist RAG im Unternehmen?

Retrieval-Augmented Generation, kurz RAG, ergänzt die Anfrage an ein generatives Sprachmodell um Inhalte, die ein Suchsystem erst im Moment der Nutzung aus freigegebenen Quellen abruft. Das Sprachmodell formuliert die Antwort; das betriebliche Wissen stammt idealerweise aus den gefundenen Dokumentteilen. Dadurch können interne Richtlinien, Handbücher, Prozessbeschreibungen oder Serviceinformationen genutzt werden, ohne sie dem Modell als dauerhaftes neues Wissen anzutrainieren.

Ein typisches RAG-System besteht aus Datenaufbereitung, Embedding-Modell, Such- beziehungsweise Retrieval-Komponente, Wissensspeicher und Sprachmodell. Die Datenschutzkonferenz beschreibt diese Architektur in ihrer Orientierungshilfe vom Oktober 2025 und betont zugleich: RAG verändert nicht, wie das zugrunde liegende Sprachmodell trainiert wurde. Anbieter-, Modell- und Datenschutzprüfung bleiben daher erforderlich.

Für Unternehmen ist RAG vor allem eine Architektur für nachvollziehbaren Wissenszugang. Es ist keine automatische Wahrheitsmaschine, kein Ersatz für Dokumentenverantwortung und keine Berechtigung, aus jeder verfügbaren Datei eine gemeinsame Wissensbasis zu bauen.

RAG dort einsetzen, wo Wissen gesucht und belegt werden muss

RAG eignet sich, wenn Mitarbeitende häufig dieselben Wissensbestände durchsuchen, die Antwort aus vorhandenen Quellen ableitbar ist und ein Quellenverweis fachlich hilft. Typische Anwendungsszenarien sind Prozess- und Richtlinienauskünfte, technischer Service, interne Produktinformationen, Qualitätsdokumentation und Onboarding. Der Nutzen entsteht nicht durch einen möglichst offenen Chat, sondern durch einen klaren Wissensraum und wiederkehrende Fragen.

Weniger geeignet ist RAG als alleinige Grundlage für Berechnungen, verbindliche Freigaben oder Aktionen in Fachsystemen. Bestellstatus, Vertragsversion, Preis, Lagerbestand oder Kundenstammdaten sollten bei Bedarf direkt aus dem führenden System abgefragt werden. Soll der Assistent anschließend in ERP, CRM, DMS oder E-Mail handeln, beginnt ein eigener Integrations- und Autorisierungsprozess; die Wissenssuche erteilt dafür keine Schreibberechtigung.

• geeignet: Antworten aus freigegebenen Dokumenten mit sichtbaren Fundstellen
• bedingt geeignet: Zusammenfassungen widersprüchlicher Quellen mit klarer Kennzeichnung
• direkt abfragen: aktuelle Transaktionen, Stammdaten und berechnete Werte aus führenden Systemen
• separat absichern: externe Kommunikation, Freigaben und schreibende Systemaktionen

Vor dem Import ein Quelleninventar mit Verantwortung anlegen

Die erste Architekturentscheidung betrifft nicht das Sprachmodell, sondern die Quellen. Pro Wissensbestand muss feststehen, wer Inhalt und Gültigkeit verantwortet, welche Version maßgeblich ist, für welche Nutzergruppe er bestimmt ist und wodurch eine Änderung oder Löschung ausgelöst wird. Dubletten, Entwürfe und abgelöste Fassungen werden vor der Indexierung gekennzeichnet oder ausgeschlossen.

Ein schlankes Quelleninventar verbindet Dokument oder Datensatz mit Herkunftssystem, fachlichem Eigentümer, Gültigkeitszeitraum, Sprache, Dokumenttyp, Datenklasse und Zugriffsgruppe. Diese Metadaten begleiten die späteren Textabschnitte. So kann die Suche beispielsweise eine geltende Arbeitsanweisung höher gewichten als einen alten Projektentwurf und eine Antwort auf den erlaubten Mandanten oder Standort begrenzen.

• eindeutige Quellen-ID und Link zum führenden Original
• fachlicher Eigentümer, Freigabestatus und Gültigkeitszeitraum
• Version, Änderungszeitpunkt und Beziehung zu ersetzten Dokumenten
• Datenklasse, Mandant, Organisationseinheit und zulässige Rollen
• Aktualisierungs-, Lösch- und Eskalationsweg

Mit fünf Reifeprüfungen klären, ob Unternehmenswissen KI-tauglich ist

Bevor Dokumente verarbeitet werden, sollte jedes geplante Wissensgebiet eine fachliche Reifeprüfung durchlaufen. Sie verhindert, dass ein technisch funktionierender Assistent lediglich ungeklärte Ablagen schneller durchsucht. Entscheidend ist nicht die Zahl der Dateien, sondern ob eine zulässige Antwort aus verantworteten Quellen ableitbar und für die vorgesehene Nutzergruppe prüfbar ist.

Ein Wissensgebiet ist pilotfähig, wenn die folgenden fünf Fragen konkret beantwortet sind. Bleibt eine davon offen, wird zuerst die Quelle oder der Prozess verbessert. Diese Trennung macht auch die Systemgrenze sichtbar: Dokumentwissen läuft über Retrieval, veränderliche Fachdaten über eine kontrollierte Abfrage des führenden Systems und schreibende Aktionen über einen gesondert autorisierten Workflow.

• Zweck: Welche wiederkehrende Nutzerfrage soll der Assistent beantworten – und welche ausdrücklich nicht?
• Quelle: Welcher Bestand ist verbindlich, wer verantwortet ihn und wie werden Entwürfe oder abgelöste Versionen ausgeschlossen?
• Recht: Welche Identität und Rolle darf Dokument, Treffertext, Metadaten und Quellenlink sehen?
• Qualität: Mit welchen realen Fragen, erwarteten Fundstellen, Ablehnungen und Negativtests wird die Antwort abgenommen?
• Betrieb: Wie erreichen Änderung, Widerruf und Löschung den Index, und wer bearbeitet widersprüchliche oder fehlende Quellen?

Dokumente so aufbereiten, dass Sinn und Herkunft erhalten bleiben

Vor der Suche werden Dokumente extrahiert, bereinigt und in kleinere Sinnabschnitte, sogenannte Chunks, aufgeteilt. Eine starre Trennung nach Zeichenanzahl kann Überschrift, Bedingung und Ausnahme auseinanderreißen. Die DSK weist darauf hin, dass Chunk-Größe, Überlappung und Bereinigung die spätere Qualität beeinflussen. Für Tabellen, Anhänge, Scans und verschachtelte Regelwerke sind deshalb eigene Aufbereitungsstrategien nötig.

Jeder Chunk behält seine Verbindung zu Dokument, Kapitel, Seite oder Abschnitt sowie zu Version und Berechtigung. Nicht benötigte Kopfzeilen, Seitennummern und Navigationsreste werden entfernt; fachlich relevante Tabellenbezüge dürfen dabei nicht verloren gehen. Personenbezogene oder vertrauliche Angaben werden nur übernommen, wenn sie für den festgelegten Zweck erforderlich und zulässig sind.

Berechtigungen bereits vor der Suche durchsetzen

Ein interner Assistent darf nur Inhalte abrufen, auf die die anfragende Person zugreifen darf. Dafür wird die Unternehmensidentität bis zur Suchanfrage weitergegeben und mit den Metadaten der Chunks abgeglichen. Mandant, Rolle, Organisationseinheit, Projekt und besondere Freigaben begrenzen den Suchraum, bevor relevante Inhalte an das Sprachmodell gelangen.

Ein reiner Filter nach der Antwort ist zu spät: Vertrauliche Informationen können dann bereits Teil des Modellkontexts oder technischer Protokolle geworden sein. Auch Suchtreffer, Dokumenttitel, Textvorschauen und Quellenlinks dürfen keine Existenz geschützter Inhalte verraten. Änderungen im Identitäts- oder Quellsystem müssen zeitnah in Index und Berechtigungsabbild ankommen; lokale Kopien benötigen denselben Entzugspfad.

• Nutzeridentität und Rollen bei jeder Anfrage prüfen
• Suchraum vor dem Retrieval nach Quelle, Mandant und Berechtigung filtern
• Dokumenttext, Metadaten und Quellenlink gemeinsam schützen
• Rechteänderungen und Offboarding ohne manuelle Schattenkopien übernehmen
• Berechtigungslecks mit gezielten Negativtests prüfen

Retrieval, Rangfolge und Antwort getrennt messen

Wenn eine Antwort falsch ist, kann die Ursache an drei Stellen liegen: Die richtige Quelle fehlt, die Suche findet den passenden Abschnitt nicht oder das Sprachmodell verwendet den gefundenen Kontext unzutreffend. Deshalb werden Retrieval und Antwortqualität getrennt bewertet. Für jede Testfrage ist bekannt, welche Quelle oder welcher Abschnitt mindestens gefunden werden muss und welche Aussage daraus zulässig ist.

In vielen Unternehmensbeständen reicht eine reine Vektorsuche nicht aus. Exakte Kennungen, Produktnamen, Normverweise oder Fehlercodes profitieren von Stichwortsuche; semantische Fragen von Embeddings. Eine hybride Suche kann beide Trefferlisten verbinden und anschließend neu gewichten. Filter, Anzahl der Treffer und Rangfolge werden nicht pauschal gewählt, sondern gegen repräsentative Fragen und deutsche Fachsprache geprüft.

• Retrieval-Trefferquote: Wird der maßgebliche Abschnitt unter den ersten Treffern gefunden?
• Belegtreue: Ist jede Tatsachenaussage durch die angezeigte Quelle gedeckt?
• Vollständigkeit: Werden relevante Bedingungen und Ausnahmen gemeinsam berücksichtigt?
• Ablehnungsqualität: Verweigert das System eine Antwort, wenn die Grundlage fehlt?
• Berechtigungssicherheit: Bleiben gesperrte Inhalte auch bei indirekten Fragen unsichtbar?

Antworten auf Quellen begrenzen und Unsicherheit sichtbar machen

Ein belastbarer Assistent trennt gefundene Inhalte von der Formulierung. Der Systemrahmen verlangt, dass Tatsachenaussagen aus den bereitgestellten Quellen stammen, Fundstellen angezeigt und Widersprüche benannt werden. Fehlt eine ausreichende Grundlage, lautet das richtige Ergebnis nicht eine plausible Vermutung, sondern eine begründete Ablehnung oder eine Übergabe an die zuständige Stelle.

Quellenverweise werden technisch aus den tatsächlich verwendeten Chunks erzeugt und nicht vom Modell frei erfunden. Nutzende müssen das Original öffnen, Version und Gültigkeit erkennen und die Aussage im Kontext prüfen können. RAG kann Halluzinationen reduzieren, aber nicht ausschließen; die DSK nennt unter anderem Quellenqualität, Datenaufbereitung, Embedding-Eignung und Kontexttreue des Sprachmodells als verbleibende Einflussfaktoren.

Beispielprozess: Technisches Servicewissen mit RAG erschließen

Ein Maschinenbauunternehmen möchte Servicefragen zu Wartung und Störungen schneller beantworten. Als freigegebene Quellen dienen aktuelle Handbücher, Wartungsanweisungen und geprüfte Fehlerbilder. Produktfamilie, Baureihe, Dokumentversion und Zugriffsgruppe werden als Metadaten geführt; veraltete Anleitungen bleiben im DMS nachvollziehbar, werden aber nicht mehr für neue Antworten verwendet.

Eine Servicemitarbeiterin fragt nach der Prüfreihenfolge für einen Fehlercode. Das System übernimmt ihre Identität, begrenzt die Suche auf die freigegebene Baureihe und kombiniert exakte Codesuche mit semantischen Treffern. Die Antwort nennt die vorgesehenen Prüfschritte und verlinkt die verwendeten Abschnitte. Widersprechen sich zwei geltende Quellen oder fehlt die konkrete Variante, stoppt der Assistent und übergibt Frage, Treffer und Kontext an die technische Dokumentation.

Eine Messung aus dem laufenden Auftrag oder der aktuelle Anlagenstatus werden nicht aus alten Dokumenten geschätzt. Dafür ruft eine getrennte Integration das führende Service- oder ERP-System lesend ab. Änderungen am Auftrag bleiben außerhalb des RAG-Systems und benötigen einen ausdrücklich autorisierten Workflow.

Datenschutz und Sicherheit über den gesamten Datenweg prüfen

Stand 18. September 2026 muss die datenschutzrechtliche Bewertung den konkreten Zweck, die betroffenen Daten, Rechtsgrundlagen, Rollen von Anbieter und Unternehmen, Speicherorte, Empfänger, Löschung und Betroffenenrechte berücksichtigen. Die DSK sieht bei RAG Chancen für Aktualisierung, Löschung und Nachvollziehbarkeit, beschreibt aber auch neue Risiken in Referenzdokumenten, Embeddings, Vektordatenbank und Protokollen. Ein lokaler Wissensspeicher macht ein externes Sprachmodell nicht automatisch unproblematisch.

Referenzdokumente sind außerdem nicht vertrauenswürdig, nur weil sie intern gespeichert sind. Manipulierte oder unkontrolliert importierte Inhalte können Antworten beeinflussen. Importwege, Dateitypen, Herkunft und Freigabe werden daher geprüft; Dokumenttext darf keine Systemrechte verändern. Welche datenschutzrechtlichen, arbeitsrechtlichen oder weiteren Anforderungen gelten, ist im Einzelfall zu klären. Dieser Beitrag bietet fachlich-technische Orientierung und keine Rechtsberatung.

Aktualisierung, Löschung und Modellwechsel als Betrieb organisieren

Die Wissensbasis ist kein einmaliger Import. Änderungen im Quellsystem lösen eine kontrollierte Neuverarbeitung aus; ersetzte oder gelöschte Inhalte verschwinden auch aus Chunks, Embeddings, Zwischenspeichern und Suchindizes. Nach einem Fehler muss erkennbar sein, welche Dokumentversion, Suchkonfiguration und Modellversion eine Antwort beeinflusst haben, ohne pauschal vollständige vertrauliche Prompts zu protokollieren.

Ein Wechsel von Embedding-Modell, Chunking, Ranking oder Sprachmodell kann das Verhalten deutlich verändern. Solche Änderungen laufen deshalb durch denselben Testbestand wie die Erstabnahme. Monitoring beobachtet erfolglose Suchen, häufige Ablehnungen, widersprüchliche Quellen, Berechtigungsfehler und Nutzerkorrekturen. Fachverantwortliche entscheiden anschließend, ob Quelle, Suchlogik oder Antwortregel angepasst wird.

• Quelländerung, Rechteänderung und Löschung automatisiert in den Index übertragen
• Versionen von Parser, Chunking, Embedding, Ranking und Sprachmodell dokumentieren
• Antworten stichprobenartig auf Belegtreue und Aktualität prüfen
• Störungen, Rückfallprozess und verantwortliche Stelle festlegen
• Änderungen erst nach Regressionstests kontrolliert freigeben

RAG in sechs Schritten vom Wissensfall zum produktiven Assistenten führen

Ein gutes Pilotprojekt beginnt mit einer begrenzten Nutzergruppe, einem fachlich verantworteten Quellenraum und Fragen, deren richtige Beantwortung überprüfbar ist. Nicht die Zahl importierter Dokumente, sondern sichere und belegte Antworten auf einen klaren Arbeitsfall bestimmen den Umfang.

• 1. Nutzergruppe, Fragen, erlaubte Antworten und Übergaben definieren
• 2. Quellen, Eigentümer, Versionen, Datenklassen und Rechte inventarisieren
• 3. Aufbereitung, Chunking, Metadaten und Aktualisierung für Dokumenttypen entwerfen
• 4. Suche, Berechtigungsfilter, Rangfolge, Quellenbelege und Ablehnung implementieren
• 5. Retrieval, Antwort, Rechte, Aktualität und Grenzfälle mit festen Tests abnehmen
• 6. Betrieb, Monitoring, Löschung, Änderungsfreigabe und fachliche Pflege organisieren