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

Ein RAG-System ist nur so gut wie der Weg zwischen Quellsystem und Antwort. In Demos werden ein paar PDFs hochgeladen, Embeddings erzeugt und anschließend plausible Antworten präsentiert. In Unternehmen sieht die Realität anders aus: Wissen liegt in SharePoint, einem DMS, ERP und CRM, in Datenbanken, Fileshares, Wikis, Ticketsystemen und Fachanwendungen – mit unterschiedlichen Eigentümern, Berechtigungen und Aktualisierungszyklen.

Genau dort entscheidet sich, ob aus einem RAG-Prototyp ein belastbares System wird.

Dieser Leitfaden zeigt, wie ich RAG-Datenquellen anbinden würde, wenn das System später produktiv, nachvollziehbar und betreibbar sein soll. Der Fokus liegt nicht auf einem bestimmten Framework, sondern auf der Architektur zwischen Quelle, Ingestion, Retrieval und Antwort.

Die kurze Antwort: So wird eine Datenquelle RAG-fähig

Für fast jede Datenquelle müssen sieben Fragen beantwortet werden:

1. Was ist die kanonische Quelle? Welches System besitzt das Original?
2. Wie kommen Änderungen ins RAG? Batch, Polling, Event, Webhook oder API?
3. Wie wird ein Dokument eindeutig identifiziert? Damit Updates keine Duplikate erzeugen.
4. Welche Berechtigungen gelten? Nutzer, Gruppen, Mandanten und vertrauliche Bereiche.
5. Welche Metadaten bleiben erhalten? Quelle, Typ, Datum, Owner, Status und Fachkontext.
6. Wie werden Löschungen verarbeitet? Entfernte Inhalte dürfen nicht im Index weiterleben.
7. Wie testen wir die Antwortqualität? Mit realen Fragen statt nur technischer Indexierung.

Wenn eine dieser Fragen ungeklärt bleibt, ist der Connector nicht fertig – selbst wenn bereits Vektoren in einer Datenbank liegen.

RAG ist eine Datenpipeline, kein PDF-Upload

Ein produktives Retrieval-Augmented-Generation-System besteht vereinfacht aus zwei Wegen.

Ingestion-Pfad:
Quelle → Extraktion → Parsing → Normalisierung → Chunking → Metadaten → Embeddings/Index → Berechtigungen

Query-Pfad:
Nutzer → Identität/Rechte → Anfrage → Retrieval → Filter → Reranking → Kontext → LLM → Antwort + Quellen

Die Vector Database ist nur ein Baustein. Probleme entstehen häufig davor: beim Erkennen von Änderungen, beim Parsing komplexer Dokumente, bei falscher Dokumentidentität oder bei verlorenen Zugriffsrechten.

Für die Gesamtarchitektur lesen Sie ergänzend RAG richtig aufsetzen: Architektur, Retrieval und Production Readiness.

SharePoint an RAG anbinden

SharePoint ist eine typische Enterprise-Quelle, weil dort Dokumente, Teamwissen und Metadaten zusammenkommen. Gleichzeitig ist die Anbindung anspruchsvoller als ein Ordner voller PDFs.

Eine robuste Integration sollte mindestens berücksichtigen:

• Sites, Libraries und Ordnerstrukturen
• stabile Dokument-IDs statt Dateinamen als Identität
• Versionen und Änderungszeitpunkte
• Benutzer- und Gruppenberechtigungen
• gelöschte oder verschobene Dokumente
• Office-Dateien, PDFs und gegebenenfalls Seiteninhalte
• fachliche Metadaten wie Abteilung, Dokumenttyp oder Status

Der zentrale Architekturpunkt ist permission-aware retrieval. Ein Mitarbeiter aus Bereich A darf über die KI nicht plötzlich Informationen aus Bereich B erhalten, nur weil beide Dokumente im selben Vektorindex liegen.

Dafür werden Berechtigungsinformationen typischerweise beim Ingest als filterbare Metadaten übernommen. Beim Retrieval wird dann vor oder während der Suche auf den aktuellen Nutzerkontext eingeschränkt.

Wichtig: Rechte ändern sich. Ein einmal importierter ACL-Stand reicht nicht dauerhaft. Die Berechtigungssynchronisierung gehört deshalb zum Betriebsmodell.

Für die konkrete Microsoft-365-Architektur gibt es jetzt den Deep-Dive SharePoint an RAG anbinden. Die Zugriffskontrolle über ACLs, Gruppen, Revocation und Query-Filter behandle ich separat unter RAG-Berechtigungen & Security Trimming.

DMS: Dokumente, Versionen und Lebenszyklus ernst nehmen

Bei Dokumentenmanagementsystemen ist das fachliche Dokument oft wichtiger als die Datei selbst.

Ein DMS kann beispielsweise kennen:

• Dokumentstatus wie Entwurf, freigegeben oder archiviert
• Dokumentklasse und Aktenzuordnung
• Gültigkeitszeiträume
• Versionen
• Aufbewahrungsregeln
• Rollen und Gruppen
• Beziehungen zwischen Dokumenten

Diese Informationen sollten nicht beim Export verloren gehen. Für RAG sind sie wertvolle Retrieval-Metadaten.

Ein Beispiel: Bei der Frage nach einer internen Richtlinie sollte nicht die drei Jahre alte Version gewinnen, nur weil ihr Chunk semantisch etwas besser zur Formulierung passt. Gültigkeit und Version müssen in das Retrieval einfließen können.

ERP: Nicht jede Information gehört in einen Vektorindex

ERP-Systeme enthalten stark strukturierte und oft hochaktuelle Daten: Aufträge, Bestände, Preise, Buchungen, Stammdaten oder Produktionsinformationen.

Der Reflex „wir indexieren das ERP in RAG“ ist deshalb häufig falsch.

Für Dokumentation, Handbücher, Prozessbeschreibungen oder relativ stabiles Stammdatenwissen kann Retrieval gut passen. Für Fragen wie „Wie hoch ist der aktuelle Lagerbestand von Artikel X?“ ist dagegen häufig eine kontrollierte Live-Abfrage über API oder Tool sinnvoller.

Eine robuste Architektur trennt daher:

• Wissensretrieval für unstrukturierte oder semistrukturierte Inhalte
• strukturierte Abfragen/Tools für exakte, aktuelle Systemdaten

Das LLM kann beide Wege orchestrieren. Entscheidend ist, dass eine exakte Zahl nicht aus einem möglicherweise veralteten Text-Chunk „erraten“ wird.

CRM: Kontext ja, Datenminimierung ebenfalls

CRM-Systeme kombinieren strukturierte Felder mit Freitext: Unternehmen, Kontakte, Aktivitäten, Notizen, Angebote und Kommunikationshistorie.

Für RAG können beispielsweise sinnvoll sein:

• freigegebene Produkt- und Kundeninformationen
• dokumentierte Gesprächszusammenfassungen
• interne Account-Notizen mit klaren Rollenrechten
• Angebots- und Projektdokumentation

Gleichzeitig steigt hier die Bedeutung von Datenschutz, Zweckbindung und Rollenmodellen. Nicht alles, was technisch abrufbar ist, sollte automatisch in einen Retrieval-Index übernommen werden.

Die Architektur sollte deshalb nicht fragen: „Was können wir indexieren?“, sondern „Welche Informationen braucht dieser Use Case wirklich?“

SQL-Datenbanken: Retrieval oder Query?

Relationale Datenbanken stellen dieselbe Grundfrage wie ERP-Systeme.

Wenn Nutzer nach exakten, aktuellen Datensätzen fragen, ist eine kontrollierte Query oft sinnvoller als semantisches Retrieval. Wenn dagegen große Textfelder, Knowledge-Artikel oder historische Dokumentinformationen enthalten sind, kann RAG der passendere Zugriff sein.

In vielen produktiven Systemen entstehen deshalb zwei Werkzeuge:

• Retrieval über Dokument-/Vektorindex
• strukturierte Datenabfrage über definierte Tools, Views oder APIs

Das reduziert Halluzinationsrisiken und hält Verantwortlichkeiten klar.

Fileshares und Netzlaufwerke

Fileshares wirken einfach, bringen aber eigene Probleme mit:

• unklare Eigentümer
• Dubletten
• verschachtelte Ordner
• alte Dateiversionen
• inkonsistente Dateinamen
• historisch gewachsene ACLs
• temporäre Dateien
• sehr unterschiedliche Dateiformate

Vor dem ersten Embedding lohnt sich daher eine Inventur. Welche Verzeichnisse sind fachlich relevant? Welche sind Archive? Wo liegen Kopien derselben Information?

Ein RAG-System sollte kein bestehendes Informationschaos nur schneller durchsuchbar machen.

Confluence, Wikis und Knowledge Bases

Wikis sind für RAG attraktiv, weil Inhalte bereits textuell und verlinkt vorliegen. Dennoch sollten Seitentitel, Space, Hierarchie, Labels, Autor, Aktualisierungsdatum und Berechtigungen erhalten bleiben.

Besonders wichtig ist die Aktualität: Wenn ein Wiki alte und neue Prozessbeschreibungen parallel enthält, braucht Retrieval genügend Signale, um den richtigen Kontext zu bevorzugen.

Interne Links können zusätzlich als Strukturinformation dienen. Sie ersetzen semantisches Retrieval nicht, helfen aber beim Verständnis zusammengehöriger Inhalte.

APIs und Fachanwendungen

Nicht jedes System braucht einen fertigen „RAG Connector“. Wenn eine Fachanwendung eine stabile API bietet, kann eine schlanke eigene Ingestion oft kontrollierbarer sein als ein schwergewichtiger Universal-Connector.

Dabei sollten Sie definieren:

• welche Objekte gelesen werden
• welche Felder in den Index gelangen
• wie Pagination funktioniert
• wie Rate Limits behandelt werden
• wie Änderungen erkannt werden
• wie Fehler und Teilimporte sichtbar werden
• wie Löschungen propagiert werden

Ein Connector ohne Monitoring wird im Betrieb früher oder später zu einem stillen Datenqualitätsproblem.

Parsing: Die Datei ist nicht der Inhalt

PDF, Word, PowerPoint, HTML oder gescannte Dokumente müssen zunächst sinnvoll in Text und Struktur übersetzt werden.

Dabei gehen schnell wichtige Informationen verloren:

• Tabellen
• Überschriftenhierarchie
• Seitenbezug
• Listen
• Fußnoten
• Bildbeschriftungen
• Spaltenlayouts
• OCR bei Scans

Für Retrieval zählt deshalb nicht nur, ob Text extrahiert wurde, sondern ob die fachliche Struktur erhalten bleibt.

Ein guter Test ist banal: Kann ein Mensch aus dem extrahierten Ergebnis noch erkennen, welche Zahl zu welcher Tabellenzeile gehört? Wenn nicht, wird auch das RAG-System Probleme bekommen.

Chunking: nicht nach fixer Zeichenzahl denken

Chunks sollten semantische Einheiten repräsentieren. Ein pauschales „alle 800 Zeichen schneiden“ kann Absätze, Tabellen oder Prozessschritte auseinanderreißen.

Sinnvoller sind je nach Dokumenttyp:

• Abschnitts- und Überschriftenstruktur
• Tabellen als eigene Einheiten
• Dokumenttyp-spezifische Regeln
• moderate Überlappung, wenn Kontextgrenzen sonst verloren gehen
• Parent-Child-Modelle für kleine Suchchunks und größeren Antwortkontext

Die richtige Chunking-Strategie lässt sich nicht isoliert bestimmen. Sie muss gegen reale Fragen evaluiert werden.

Metadaten sind ein Retrieval-Feature

Metadaten werden oft als Nebenprodukt betrachtet. In Enterprise RAG sind sie Teil der Suchlogik.

Typische Felder:

| Metadatum | Nutzen | |---|---| | Quellsystem | Herkunft und Debugging | | Dokument-ID | Updates und Deduplizierung | | Titel | Ergebnisdarstellung | | URL/Pfad | Quellenlink | | Owner/Abteilung | fachlicher Kontext | | Dokumenttyp | Filterung | | Erstellt/geändert | Aktualität | | Status/Gültigkeit | richtige Version | | ACL/Gruppe | Berechtigungsfilter | | Mandant | harte Datentrennung |

Ohne stabile Dokument-ID wird Synchronisierung schwierig. Ohne Quellen-URL wird eine Antwort schlecht überprüfbar. Ohne ACL wird Retrieval zum Sicherheitsrisiko.

Synchronisierung: Full Reindex ist kein Betriebsmodell

Bei einem Pilot mit 200 Dokumenten kann ein kompletter Neuimport akzeptabel sein. Bei produktiven Datenquellen sollte die Pipeline inkrementell arbeiten.

Sie muss unterscheiden können:

• neues Objekt
• geändertes Objekt
• unverändertes Objekt
• verschobenes Objekt
• gelöschtes Objekt
• geänderte Berechtigung

Idealerweise ist jeder Ingest-Lauf nachvollziehbar: Was wurde verarbeitet? Was ist fehlgeschlagen? Welche Quelle ist seit Stunden oder Tagen nicht mehr synchron?

Löschungen sind genauso wichtig wie neue Dokumente

Eine häufig übersehene Anforderung: Wenn ein Dokument in der Quelle gelöscht oder der Zugriff entzogen wird, muss es auch aus dem Retrieval verschwinden.

Sonst entsteht ein Zombie Index: technisch funktioniert die Suche, aber sie enthält Informationen, die nicht mehr existieren oder nicht mehr sichtbar sein dürften.

Delete Propagation und Permission Revocation gehören daher zu den Abnahmekriterien.

Berechtigungen: Security Trimming gehört ins Retrieval

Bei internen Unternehmensdaten ist es gefährlich, Rechte erst nach der Antwort zu prüfen.

Der Retrieval-Prozess sollte nur Kandidaten liefern, die der Nutzer sehen darf. Abhängig von Architektur und Datenquelle kann das über Nutzer-, Gruppen-, Rollen- oder Mandantenfilter geschehen.

Zusätzlich sollte geklärt sein:

• Woher kommt die Nutzeridentität?
• Wie werden Gruppen aufgelöst?
• Was passiert bei Rechteänderungen?
• Gibt es Service Accounts mit zu breiten Rechten?
• Werden Berechtigungen gecacht?
• Wie wird Mandantentrennung technisch erzwungen?

Das ist ein Architekturthema, kein Prompt-Problem.

Hybrid Search und Reranking

Semantische Vektorsuche ist nützlich, aber nicht für jede Anfrage ausreichend.

Produktive Retrieval-Pipelines kombinieren häufig mehrere Signale:

• semantische Ähnlichkeit
• Keyword-/Volltextsuche
• Metadatenfilter
• Aktualität
• fachliche Priorität
• Reranking der Kandidaten

Welche Kombination sinnvoll ist, zeigt die Evaluation. Nicht jede zusätzliche Retrieval-Stufe verbessert automatisch die Qualität.

Quellenbezug: Antworten müssen überprüfbar sein

Für internes Wissen ist eine Antwort ohne nachvollziehbare Quelle deutlich weniger wertvoll.

Speichern Sie deshalb bereits bei der Ingestion genug Information, um später auf das Original zurückzuführen:

• Dokumenttitel
• Quellsystem
• URL oder Objekt-ID
• Abschnitt oder Seite, soweit technisch zuverlässig
• Version/Datum

Das erhöht nicht nur Vertrauen. Es macht auch Fehleranalyse erheblich schneller.

Evaluation beginnt vor der ersten Datenquelle

Bevor ein Connector gebaut wird, sollten reale Fragen gesammelt werden.

Beispielsweise:

• „Welche aktuelle Reisekostenregel gilt für Österreich?“
• „Welche Freigaben braucht ein Angebot über Betrag X?“
• „Welche technischen Voraussetzungen hat Produkt Y?“
• „Wer darf Prozess Z genehmigen?“

Daraus entsteht ein kleines Golden Set mit erwarteten Quellen und Antworten.

Dann lässt sich messen:

• Wurde die richtige Quelle gefunden?
• War sie unter den Top-K?
• War die gefundene Version aktuell?
• Wurden Rechte korrekt angewendet?
• War die Antwort durch die Quellen gedeckt?
• Hat das System bei fehlender Evidenz sauber abgebrochen?

Damit wird aus „fühlt sich gut an“ ein technischer Qualitätsprozess.

Eine sinnvolle Zielarchitektur

Für viele Unternehmen ergibt sich ein Muster:

Quellsysteme
SharePoint · DMS · ERP · CRM · SQL · Wiki · Fileshares · APIs

↓

Ingestion Layer
Connectoren · Change Detection · Parsing · Normalisierung · ACLs · Metadaten

↓

Knowledge Layer
Dokumentstore · Suchindex · Vector Store · Metadaten · Versionen

↓

Retrieval Layer
Identity · Permission Filter · Hybrid Search · Reranking · Context Assembly

↓

AI / Application Layer
LLM · Tools/APIs · Quellenanzeige · Fachworkflow · Evaluation · Monitoring

Die konkrete Technologie kann austauschbar bleiben. Wichtiger sind die Systemgrenzen und die Datenverträge zwischen diesen Ebenen.

Build vs. Buy bei RAG-Connectoren

Fertige Connector-Plattformen können den Start beschleunigen. Eigenentwicklung kann sinnvoll sein, wenn Rechte, Datenmodell, Spezialformate oder Betriebsanforderungen sehr spezifisch sind.

Bewerten würde ich mindestens:

• unterstützte Quellen
• Berechtigungsmodell
• Change Detection
• Delete Propagation
• Datenresidenz
• Fehlerbehandlung
• Observability
• Export-/Exit-Möglichkeiten
• Kosten bei wachsendem Datenvolumen

Der Connector sollte ein austauschbarer Teil der Architektur bleiben – nicht die Architektur selbst.

Was ich vor der Implementierung klären würde

Wenn Sie RAG in ein bestehendes Unternehmen integrieren, starten Sie nicht mit einer Tool-Liste. Starten Sie mit einem Arbeitsblatt:

1. Use Case und Nutzer
2. reale Fragen
3. Quellsysteme
4. Datenklassen
5. Owner
6. Berechtigungen
7. Aktualitätsanforderung
8. Dokumentvolumen und Änderungsrate
9. Quellenbezug
10. Akzeptanzkriterien

Erst danach lohnt es sich, Connector, Parser, Vector Database oder Framework auszuwählen.

RAG-Datenquellen produktiv anbinden

Wenn die Quellsysteme feststehen, geht es nicht um „einen Connector installieren“, sondern um einen kontrollierten Daten- und Retrieval-Pfad.

Ich unterstütze Unternehmen bei der RAG-Implementierung und KI-Integration: von SharePoint, DMS, ERP, CRM und Datenbanken über Berechtigungen und Retrieval bis zur Evaluation und Integration in vorhandene Anwendungen.

Für die vorgelagerte Architekturentscheidung ist die KI-Architekturberatung der passendere Einstieg. Bei sensiblen Daten und Hosting-Fragen finden Sie unter Private AI und souveräne KI die Betriebsmodelle im Vergleich.

Sie haben bereits konkrete Datenquellen und wollen wissen, wie daraus ein belastbarer RAG-Pilot wird?
→ RAG-Implementierung besprechen

Die technische Einordnung zu Datenschutz und Compliance ersetzt keine Rechtsberatung.