RAG-Datenquellen anbinden: SharePoint, DMS, ERP, CRM & Datenbanken

Bei Enterprise RAG ist das initiale Einlesen von Dokumenten selten die eigentliche Schwierigkeit. Entscheidend ist, ob Dokumentidentität, Berechtigungen, Aktualität, Versionen und Löschungen über den gesamten Lifecycle korrekt erhalten bleiben.

Ein Vektorindex kann technisch perfekt befüllt sein und trotzdem unzuverlässige oder unzulässige Antworten liefern: wenn eine alte Richtlinie neben der neuen Version weiterlebt, ein verschobenes Dokument als zweites Objekt auftaucht oder eine entzogene Berechtigung erst Tage später im Retrieval ankommt.

Embeddings lösen keine Lifecycle-Probleme. Eine belastbare RAG-Ingestion beginnt mit Identität, Berechtigungen, Lifecycle und Provenance – erst danach mit Chunking und Indexierung.

Für die übergeordnete RAG-Architektur mit Retrieval und Evaluation siehe RAG richtig aufsetzen: Architektur, Retrieval und Production Readiness.

Warum „Connector anbinden“ die Aufgabe unterschätzt

Ein Connector beweist zunächst nur, dass Daten gelesen werden können. Für eine bestehende Unternehmensanwendung muss er mehr leisten: Er muss erkennen, welches fachliche Dokument sich geändert hat, welche Version gültig ist und wer es aktuell sehen darf. Er muss auch erklären können, warum ein Inhalt im Index liegt – und ihn entfernen, wenn die Quelle ihn löscht oder nicht mehr erreichbar ist.

Das ist kein einmaliger Import, sondern ein Datenvertrag zwischen Quellsystem, Ingestion und Retrieval. Dateiname und URL sind darin oft nur Attribute. Beide können sich ändern, ohne dass ein neues fachliches Dokument entsteht.

Ein Dokument-Lifecycle statt Einmal-Ingestion

Eine produktive Pipeline verarbeitet mindestens diese Zustände:

• Create: Ein neues Objekt wird mit Herkunft, kanonischer Identität, Version und ACLs angelegt.
• Update: Inhalt oder relevante Metadaten ändern sich; die betroffenen Chunks und Indexeinträge werden ersetzt.
• Move oder Rename: Pfad und Titel ändern sich, die fachliche Identität bleibt erhalten.
• Permission change: Inhalt bleibt gleich, aber der abrufbare Nutzerkreis ändert sich sofort im Retrieval.
• Delete: Alle zugehörigen Dokument-, Versions- und Chunk-Einträge verschwinden aus dem Index.
• Restore: Ein wiederhergestelltes Objekt wird als aktueller Lifecycle-Stand kontrolliert erneut aufgenommen.
• Source unavailable oder stale: Fehlen Änderungen aus einer Quelle, ist das ein sichtbarer Betriebszustand – kein stilles „weiter wie bisher“.

Delete-Propagation ist ein Production-Readiness-Kriterium. Wenn gelöschte Dokumente oder entzogene Rechte im Retrieval weiterwirken, ist die Pipeline nicht produktionsreif – unabhängig von der Qualität des Embedding-Modells.

Identität: von der Quelldatei zum Chunk

Dateiname oder URL allein sind häufig keine stabile Identität. Dieselbe SharePoint-Datei kann umbenannt und mehrfach verschoben werden. Ein DMS kann eine neue Dateiversion unter derselben fachlichen Akte führen. Dieselbe Information kann zusätzlich aus einer Produktdatenbank oder einem CRM stammen.

Eine belastbare Pipeline trennt deshalb mehrere Ebenen:

Die Canonical Document ID ist keine kosmetische Zusatzspalte. Sie verhindert, dass ein Move als neues Dokument behandelt wird, ermöglicht Deduplizierung und hält die Verknüpfung zwischen Quelle, Version und Chunk nachvollziehbar. Wo mehrere Systeme dieselbe Information führen, muss fachlich klar sein, welches System Source of Truth ist; ein hoher semantischer Similarity-Score entscheidet das nicht.

ACLs gehören in das Ingestion-Datenmodell

Berechtigungen sind kein späterer Filter nach einer bereits erzeugten Antwort. Sie gehören in das Datenmodell der Ingestion-Pipeline und müssen bis zum Retrieval erhalten bleiben.

Das umfasst die aus der Quelle stammenden ACLs ebenso wie das Mapping auf Identitäten der Unternehmensanwendung: Nutzer, Gruppen, Rollen und gegebenenfalls Mandanten. Retrieval darf nur Kandidaten liefern, die im aktuellen Nutzerkontext zulässig sind. Dieses Security Trimming muss auch dann funktionieren, wenn Gruppenmitgliedschaften oder Dokumentrechte sich ändern, ohne dass sich ein einziges Zeichen im Dokument ändert.

Ein Service Account mit breiten Leserechten vereinfacht den Import, ersetzt aber keine Zugriffskontrolle im Zielsystem. Die detaillierte Perspektive auf ACL-Mapping, Revocation und Retrieval-Filter behandelt RAG-Berechtigungen & Security Trimming.

Konkretes Enterprise-Szenario: Servicewissen mit mehreren Quellen

Eine bestehende Service-Anwendung soll Mitarbeitenden Antworten mit Quellen liefern. Das Wissen liegt in SharePoint, einem DMS und einer Produktdatenbank beziehungsweise im CRM:

• SharePoint enthält Arbeitsanweisungen, die ein Team verschiebt und aktualisiert.
• Das DMS führt freigegebene Dokumente mit mehreren Versionen und Status.
• Produktdatenbank oder CRM liefern freigegebene Produkt- und Account-Kontexte.
• Unterschiedliche Nutzergruppen dürfen unterschiedliche Bereiche sehen.

Eine Datei wird in SharePoint umbenannt, später in eine andere Library verschoben und danach aktualisiert. Die source-native ID hält sie als dasselbe Objekt zusammen; die neue Version ersetzt ihre alten Chunks. Parallel existiert eine freigegebene DMS-Version derselben Richtlinie. Die Anwendung muss anhand einer expliziten Canonical Identity und des definierten Source of Truth entscheiden, welche Information führend ist – nicht beide blind parallel indexieren.

Ändert sich nur die Berechtigung, bleibt der Inhalt unverändert, aber die ACLs müssen aktualisiert werden. Wird die Datei gelöscht oder ein Zugriff entzogen, dürfen keine zugehörigen Chunks mehr abrufbar sein. Ist die Quelle seit dem letzten erfolgreichen Lauf nicht erreichbar, braucht Betrieb und Anwendung einen erkennbaren Stale-Status statt einer scheinbar aktuellen Antwort.

Architecture View: die Reihenfolge ist eine Sicherheits- und Qualitätsentscheidung

RAG-Ingestion: Lifecycle vor Embeddings

1. 01

   Source Systems

   SharePoint, DMS und Produktdatenbank oder CRM als fachliche Quellen

2. 02

   Connector & Change Detection

   Create, Update, Move, Permission Change, Delete, Restore und Stale-Status erkennen

3. 03

   Identity & ACL Mapping

   Source-native IDs, Canonical Identity, Versionen, Provenance sowie Nutzer-, Gruppen- und Mandantenrechte

4. 04

   Parsing & Normalization

   Text, Struktur, Tabellen, Status und fachliche Metadaten kontrolliert erhalten

5. 05

   Chunking & Indexing

   Nur aktuelle, eindeutig zuordenbare Inhalte in Such- und Vektorindex überführen

6. 06

   Permission-aware Retrieval

   Aktuellen Nutzerkontext anwenden, zulässige Evidenz liefern und auf die Quelle zurückverweisen

Die zentrale Aussage dieser Reihenfolge: Eine Änderung im vorderen Teil der Kette muss kontrolliert bis zu allen betroffenen Indexeinträgen durchlaufen. Ein Index ist kein zweites Quellsystem, sondern eine abgeleitete, jederzeit erklärbare Sicht auf die führenden Daten.

Parsing und Normalisierung vor Chunking

Eine Datei ist nicht automatisch brauchbarer Retrieval-Inhalt. PDFs, Office-Dokumente, HTML und Scans verlieren beim Parsing leicht Tabellen, Überschriften, Seitenbezüge oder Freigabestatus. Wird diese Struktur beschädigt, repariert auch sorgfältiges Chunking sie nicht.

Normalisierung ordnet deshalb Inhalt und Metadaten in ein konsistentes Dokumentmodell ein: Titel, Quelle, Status, Gültigkeit, Version, ACLs und Provenance bleiben mit dem extrahierten Inhalt verknüpft. Erst dann lässt sich entscheiden, welche semantischen Einheiten als Chunks sinnvoll sind und welche aktuelle Version indexiert werden darf. Für die Ausgestaltung dieser Stufe siehe RAG-Chunking: Strategien für bessere Antworten.

Managed Connector oder Custom Pipeline: nach Semantik entscheiden

Ein Managed Connector ist attraktiv, wenn die Quelle standardisiert ist und er die tatsächliche Semantik transparent abbildet: ACLs werden korrekt übernommen, Lifecycle Events zuverlässig erkannt, Update- und Delete-Verhalten ist dokumentiert und Fehler beziehungsweise Stale-Zustände sind beobachtbar. Dann spart er Implementierungs- und Betriebsaufwand, ohne die entscheidenden Datenverträge zu verstecken.

Eine Custom Pipeline ist sinnvoll, wenn proprietäre Quellen, komplexe Business-Logik, besondere Normalisierung oder ein ungewöhnliches Permission-Modell beteiligt sind. Das gilt auch, wenn mehrere Quellen zu einer Canonical Identity zusammengeführt werden oder kontrollierte Provenance für die bestehende Anwendung nötig ist. Custom bedeutet dabei nicht, Search oder Embeddings neu zu erfinden; häufig genügt ein schmaler Integrationsadapter an der fachlichen Grenze.

Die breitere Entscheidung über Verantwortlichkeiten und austauschbare RAG-Schichten ordnet Enterprise RAG: kaufen, bauen oder hybrid? ein.

Die Architekturentscheidung vor der Indexoptimierung

Eine belastbare RAG-Ingestion sollte nicht mit Embeddings beginnen. Zuerst müssen Identität, Berechtigungen, Lifecycle und Provenance stabil sein. Erst danach lohnt es sich, Chunking, Hybrid Search oder Indexierung gegen reale Fragen zu optimieren.

Wenn Delete-Propagation und Permission-Updates nicht zuverlässig funktionieren, ist die Pipeline nicht production-ready – unabhängig von der Qualität des Embedding-Modells. Für SharePoint- und DMS-spezifische Ausgestaltung helfen die Deep Dives SharePoint an RAG anbinden und DMS mit RAG verbinden.

Wenn die Datenquellen, Rechte und Lifecycle-Regeln für Ihre Anwendung bereits konkret sind, unterstütze ich bei der RAG-Implementierung und KI-Integration. Wenn zunächst Source of Truth, Integrationsgrenzen und Betriebsmodell geklärt werden müssen, ist die KI-Architekturberatung der passendere Einstieg.

Die technische Einordnung zu Datenschutz und Compliance ersetzt keine Rechtsberatung.