DMS mit RAG verbinden: Architektur, Rechte & Versionen

Ein DMS enthält häufig genau das Wissen, das Unternehmen mit KI besser zugänglich machen wollen: Richtlinien, Verträge, technische Dokumentation, Angebote, Produktunterlagen, Protokolle und freigegebene Versionen.

Ein DMS einfach zu „vektorisieren“ reicht aber nicht.

Produktionsreifes DMS-RAG muss Dokumentidentität, Versionen, Freigabestatus, OCR/Layout, Metadaten, Berechtigungen, Synchronisierung und Quellenbezug gemeinsam lösen.

Fraunhofer IAO beschreibt RAG 2026 ausdrücklich als Ansatz, um Unternehmensdokumente über generative KI zugänglich zu machen. Auch die WKO positioniert RAG als Verbindung moderner KI mit aktuellem Unternehmenswissen. Quellen: Fraunhofer IAO – Unternehmensdokumente erschließen mit RAG, WKO – Retrieval Augmented Generation.

Die Kurzfassung

Eine robuste Referenzarchitektur sieht eher so aus:

DMS → Connector/API → Parsing/OCR → Dokumentidentität & Version → Metadaten & ACL → Index/Search → Retrieval → LLM → Antwort mit Quelle

Wichtig: Nicht jeder Schritt muss in einem eigenen Produkt liegen. Aber jeder Schritt braucht eine klare Verantwortung.

Warum DMS-RAG schwieriger ist als ein Datei-Upload

Ein Demo-RAG kann mit 20 PDFs funktionieren.

Ein produktives DMS enthält dagegen häufig:

• mehrere Versionen desselben Dokuments,
• Entwürfe und freigegebene Fassungen,
• Scans,
• Tabellen,
• Anhänge,
• Ordner-/Projektmetadaten,
• Benutzer- und Gruppenrechte,
• Retention-/Archivregeln,
• gelöschte oder ersetzte Dokumente.

Die zentrale Frage lautet daher nicht:

„Wie bekomme ich PDFs in eine Vector Database?“

Sondern:

„Wie bleibt die Bedeutung und Governance des DMS im AI-System erhalten?“

1. Remote Retrieval oder eigener Index?

Es gibt zwei Grundmuster.

Variante A – Remote Retrieval

Die AI-Anwendung fragt das DMS oder dessen Search API zur Laufzeit ab.

Vorteile

• weniger Datenkopien,
• aktuelle Quelle,
• Berechtigungen können in der Quelle bleiben,
• weniger eigener Indexbetrieb.

Nachteile

• abhängig von DMS-Suchqualität und API,
• Latenz,
• begrenzte Ranking-/Chunking-Kontrolle,
• schwierigeres Multi-Source-Retrieval.

Variante B – replizierter RAG-Index

Dokumente und relevante Metadaten werden in eine eigene Retrieval-Schicht synchronisiert.

Vorteile

• eigenes Chunking,
• Hybrid Search,
• Reranking,
• Multi-Source-Kombination,
• kontrollierbare Retrieval-Evaluation.

Nachteile

• Synchronisierung,
• ACL-Replikation,
• Delete Propagation,
• zusätzlicher Betriebsaufwand,
• Risiko veralteter Kopien.

Entscheidungsmatrix

| Situation | Tendenz | | --- | --- | | DMS hat starke Search API + Identity | Remote Retrieval prüfen | | mehrere Quellen sollen gemeinsam gesucht werden | eigener/zentraler Retrieval Layer | | sehr spezifisches Chunking nötig | eigener Index | | minimale Datenkopien wichtig | Remote Retrieval | | DMS-Suche ist schwach | eigener Index wahrscheinlicher | | hohe Aktualitätsanforderung | Remote oder sehr robuste Incremental Sync | | individuelle Ranking-/Eval-Anforderungen | eigener Index |

In der Praxis ist auch Hybrid möglich: Metadaten oder Kandidaten kommen aus dem DMS, Detailretrieval aus einem eigenen Index oder umgekehrt.

2. Parsing und OCR sind keine Nebenaufgabe

Wenn der extrahierte Inhalt falsch ist, kann Retrieval nicht korrekt sein.

DMS-Dokumente enthalten häufig:

• gescannte PDFs,
• mehrspaltige Dokumente,
• Tabellen,
• Formulare,
• Kopf-/Fußzeilen,
• eingebettete Anhänge,
• Bilder mit Text.

Typische Fehler

• Tabellenwerte verlieren ihre Spaltenbeziehung.
• Überschriften werden vom Abschnitt getrennt.
• OCR verwechselt Zahlen oder Produktcodes.
• Header/Footer landen in jedem Chunk.
• Seitenreihenfolge wird falsch interpretiert.

Deshalb sollte Parsing als eigene Qualitätsstufe betrachtet werden.

Die Chunking-Entscheidung folgt nach der Extraktion: RAG Chunking Strategien.

3. Dokumentidentität muss stabil bleiben

Ein DMS-Dokument braucht eine stabile Identität über Änderungen hinweg.

Beispiel:

• document_id = 4711
• Version 7 = Entwurf
• Version 8 = freigegeben
• Version 9 = neue gültige Fassung

Der RAG-Index sollte nicht drei unabhängige „Dokumente“ behandeln, wenn fachlich nur Version 9 zulässig ist.

Sinnvolle Felder:

• Document ID,
• Version ID,
• Status,
• Title,
• Document Type,
• Source URL,
• Owner,
• Modified At,
• Valid From / To,
• Retention State.

4. Freigabestatus ist Retrieval-Logik

In vielen DMS existieren Zustände wie:

• Draft,
• Review,
• Approved,
• Archived,
• Superseded.

Ein AI-System sollte beispielsweise nicht automatisch einen Entwurf zitieren, wenn eine freigegebene Version existiert.

Daraus folgt:

Status- und Versionslogik gehört in Filter und Retrieval – nicht nur in die Anzeige.

5. Berechtigungen sind Teil des Indexdesigns

DMS-Berechtigungen können komplex sein:

• Benutzer,
• Gruppen,
• Rollen,
• Ordnervererbung,
• Projektmitgliedschaft,
• Dokumentklassifikation,
• Mandanten.

Ein produktives RAG braucht ein explizites Permission Model.

Typische Ansätze:

Early Binding

ACL-Information wird mit dem Dokument/Chunk indexiert und schon während Retrieval gefiltert.

Late Binding

Die Quelle oder ein Authorisation Service prüft den Zugriff zur Laufzeit.

Hybrid

Ein Teil der Rechte ist im Index, kritische Checks erfolgen zusätzlich gegen das Quellsystem.

Die Details: RAG-Berechtigungen & Security Trimming.

6. Synchronisierung: Änderungen, Versionen und Löschungen

Eine einmalige Vollindexierung ist keine produktive Synchronisierungsstrategie.

Erforderlich sind je nach DMS:

• Change Feed,
• Modified Timestamp,
• Webhooks,
• Delta API,
• Polling,
• Checkpoints.

Für jedes geänderte Objekt muss klar sein:

• neu,
• geändert,
• neu freigegeben,
• archiviert,
• Rechte geändert,
• gelöscht.

Delete Propagation

Ein besonders kritischer Fall:

Dokument wird im DMS gelöscht oder Zugriff entzogen, bleibt aber im RAG-Index.

Dann kann die AI weiterhin Evidenz liefern, die im Quellsystem nicht mehr vorhanden oder zulässig ist.

Löschungen und Rechteänderungen müssen deshalb genauso behandelt werden wie neue Dokumente.

7. Metadaten sind mehr als Filter

Metadaten helfen bei:

• Retrieval,
• Ranking,
• Berechtigungen,
• Zitation,
• Versionierung,
• Debugging.

Beispiel:

Eine Frage enthält „aktuelle Reisekostenrichtlinie Österreich“.

Metadaten können helfen:

• Dokumenttyp = Policy,
• Land = AT,
• Status = Approved,
• Validity = current.

Das reduziert den Suchraum und verbessert Nachvollziehbarkeit.

8. Keyword + Vector Search kombinieren

DMS-Inhalte enthalten oft exakte Begriffe:

• Dokumentnummern,
• Artikelcodes,
• Projekt-IDs,
• Vertragsnummern,
• Personennamen,
• Fachbegriffe.

Deshalb ist reine Vector Search nicht immer ausreichend.

Hybrid Search vs. Vector Search zeigt, wie lexical und semantic retrieval kombiniert werden können.

9. Tabellen und strukturierte Inhalte separat behandeln

Nicht jede Information sollte als Fließtext-Chunk behandelt werden.

Beispiele:

• Preislisten,
• Produktmatrizen,
• Vertragsparameter,
• technische Tabellen.

Wenn die Tabellenstruktur geschäftskritisch ist, kann es sinnvoll sein:

• Tabelle strukturiert zu extrahieren,
• Zeilen als Objekte zu indexieren,
• oder strukturierte Daten über API/SQL abzufragen.

Die Architektur darf RAG und Tool/API-Zugriff kombinieren.

10. Quellenbezug muss bis zum Original reichen

Ein gutes DMS-RAG zeigt nicht nur:

„Quelle: Dokument X“

Sondern idealerweise:

• Dokumenttitel,
• Version,
• Seite/Abschnitt,
• Link ins DMS,
• ggf. Datum/Freigabestatus.

Der Nutzer muss die Aussage am Original prüfen können.

Citation Accuracy gehört deshalb in die Evaluation.

11. DMS-native AI oder eigenes RAG?

Viele DMS-Hersteller erweitern ihre Produkte um Suche oder AI-Funktionen.

Die Frage ist dann nicht automatisch „Custom RAG bauen“.

Prüfen Sie:

| Kriterium | DMS-native AI | Eigenes / zentrales RAG | | --- | --- | --- | | nur DMS-Inhalte | oft stark | möglich | | mehrere Quellen | abhängig vom Produkt | meist flexibler | | Berechtigungen | häufig nativ | muss repliziert/integriert werden | | eigenes Retrieval-Tuning | oft begrenzt | hoch | | Modellfreiheit | produktabhängig | höher | | individuelle Evaluation | produktabhängig | gut kontrollierbar | | Integration in eigene Prozesse | produktabhängig | flexibel | | Vendor Lock-in | höher möglich | Architektur kann modularer sein |

Die richtige Wahl hängt vom konkreten DMS und Use Case ab.

12. DMS-RAG evaluieren

Ein Golden Dataset sollte reale Dokumentfragen enthalten.

Beispiel-Testfälle:

• eindeutige Frage aus aktueller freigegebener Version,
• alte Version darf nicht verwendet werden,
• Nutzer ohne Zugriff,
• Scan mit OCR,
• Tabelle,
• Dokument mit ähnlichem Titel,
• gelöschtes Dokument,
• neue Version nach Synchronisierung,
• Frage ohne belastbare Quelle.

Messen Sie mindestens:

• Retrieval Recall,
• Ranking,
• Groundedness,
• Correctness,
• Citation Accuracy,
• Permission Correctness,
• Freshness.

Methodik: RAG Evaluation.

DMS-RAG-Checkliste

Vor dem Build sollten Sie beantworten können:

1. Welche Dokumenttypen sollen durchsucht werden?
2. Gibt es stabile Dokument-IDs?
3. Wie funktionieren Versionen?
4. Welcher Status ist zitierfähig?
5. Wie werden Rechte abgebildet?
6. Wie werden Änderungen erkannt?
7. Wie werden Löschungen propagiert?
8. Wie gut ist Parsing/OCR?
9. Welche Metadaten sind relevant?
10. Reicht DMS Search oder brauchen wir eigenen Retrieval Layer?
11. Wie gelangen Nutzer zur Originalquelle?
12. Wie wird Qualität laufend getestet?

Anti-Patterns

„Wir exportieren alle PDFs und embedden sie“

Damit gehen Versionierung, Rechte und Löschlogik leicht verloren.

Nur Vollindexierung

Zwischen Rebuilds arbeitet das System mit veralteten Informationen.

Post-Filtering als Security

Unerlaubter Inhalt sollte nicht erst nach Retrieval aussortiert werden, wenn er bereits in nachgelagerte Komponenten gelangt ist.

Jede Tabelle als Text behandeln

Strukturierte Beziehungen können dabei verloren gehen.

DMS-native AI ignorieren

Eigenentwicklung ist nur sinnvoll, wenn sie einen echten zusätzlichen Nutzen bringt.

Nächster Schritt

Wenn Ihr Unternehmen bereits ein DMS besitzt und Dokumentwissen über RAG oder AI Search zugänglich machen möchte, sollten DMS-Logik und AI-Retrieval gemeinsam geplant werden.

Das betrifft nicht nur den Connector, sondern Parsing, Dokumentidentität, Berechtigungen, Versionen, Synchronisierung, Retrieval und Evaluation.

Dafür ist RAG-Implementierung & KI-Integration der passende Einstieg.

Für die übergeordnete Frage, ob DMS-native AI, eine RAG-Plattform oder eine eigene Architektur sinnvoller ist, passt KI-Beratung & AI Solution Architecture.