Sichere Dokumentenaufnahme für RAG: PDFs, OCR, Metadaten und Aufbewahrung

RAG-Fehler können bereits vor dem Retrieval entstehen: durch veraltete Dokumente, übersehene Tabellen, Quellen ohne Verantwortliche, verlorene Berechtigungsmetadaten, nicht gelöschte Vektoren, widersprüchliche verborgene Texte oder unsichere Dateien.

Die sichere Dokumentenaufnahme bildet die Quellenkontrolle für das Unternehmenswissen. Sie bestimmt, was in das Retrieval-System gelangt, wer darauf zugreifen darf, wie die Aktualität verfolgt wird, wie Löschvorgänge funktionieren und wie problematische Eingaben erkannt werden.

Dieser Artikel behandelt die Aufnahmeschicht: PDFs, OCR, Metadaten, Berechtigungen, Aufbewahrung und betriebliche Prüfungen.

Darf ein Nutzer im Quellsystem nicht auf ein Dokument zugreifen, darf er im RAG-System auch nicht auf dessen Chunks, Embeddings, Zusammenfassungen oder zwischengespeicherte Antworten zugreifen. Berechtigungsmetadaten sind unverzichtbar.

Die Aufnahmepipeline

Eine produktive Pipeline sollte klar definierte Stufen haben:

1. Quellregistrierung.
2. Datenklassifizierung.
3. Dateisicherheitsprüfungen.
4. Textextraktion und optische Zeichenerkennung (OCR).
5. Strukturerhaltung.
6. Metadaten zuordnen.
7. Berechtigungen abbilden.
8. Text in Chunks aufteilen und Embeddings erstellen.
9. Qualitätsprüfungen.
10. Veröffentlichung des Indexes.
11. Aufbewahrung und Löschung handhaben.
12. Betriebliche Verantwortung festlegen.

Die konkreten Tools können variieren. Die Kontrollpunkte sollten nicht.

Stufe 1: Quellregistrierung

Nehmen Sie nicht wahllos Ordner auf, nur weil sie sich leicht anbinden lassen.

Für jede Quelle sind folgende Angaben zu erfassen:

• Quellname,
• führendes System (System of Record),
• für die Quelle verantwortliche Person,
• für die Daten verantwortliche Person,
• zugelassene Benutzer oder Rollen,
• Dokumenttypen,
• Sensitivitätsstufe,
• Aufbewahrungsregel,
• Aktualisierungshäufigkeit,
• Löschverhalten,
• Prüfplan.

Beispielquellen:

• öffentliches Hilfezentrum,
• internes Support-Playbook,
• Vertriebsunterlagen,
• Kundenverträge,
• Personalrichtlinien,
• technische Betriebsanleitungen,
• Produktdokumentation,
• Meeting-Transkripte.

Diese Quellen sollten nicht alle im selben Index mit denselben Berechtigungen landen.

Stufe 2: Daten vor der Extraktion klassifizieren

Klassifizieren Sie die Quelle, bevor das Modell oder der Embedding-Anbieter den Inhalt sieht.

Nützliche Klassen:

Die Klassifizierung ist mehr als eine Compliance-Formalität. Sie bestimmt, ob Inhalte an eine gehostete Embedding-API gesendet, in einer gemeinsamen Vektordatenbank gespeichert, in Protokolle aufgenommen oder für Evaluierungsbeispiele verwendet werden dürfen.

Stufe 3: Dateisicherheit prüfen

Dokumente können bösartig oder schlicht beschädigt sein.

Vor der Extraktion:

• Dateityp anhand einer Positivliste prüfen,
• Dateigrößenbeschränkungen durchsetzen,
• auf Malware scannen, wo Ihre Umgebung dies erfordert,
• verschlüsselte Dateien ablehnen, es sei denn, es gibt einen genehmigten Entschlüsselungspfad,
• Dateien mit nicht unterstützten eingebetteten Objekten ablehnen,
• Dateinamen normalisieren,
• Hash der Originaldatei speichern,
• dokumentieren, wer die Datei hochgeladen oder verbunden hat.

Dies ist besonders wichtig, wenn Nutzer ohne Administratorrechte Dokumente hochladen können. Eine Aufnahme ausschließlich durch Administratoren verringert zwar einen Angriffsweg, macht kompromittierte, bösartige, zu große oder fehlerhafte Dokumente aber nicht sicher. Auch die Aufnahme über Konnektoren und URLs erfordert freigegebene Ursprungsadressen, Kontrollen für Weiterleitungen und DNS, eine eng begrenzte Authentifizierung, Ratenbegrenzungen sowie SSRF-Tests.

Wenn nicht vertrauenswürdige Nutzer Dateien hochladen können, setzen Sie vor dem Parsen eine Dateisicherheitsschicht ein. Verwenden Sie die gepflegte OWASP-Checkliste für Dateiuploads als Ausgangspunkt und erstellen Sie ein Bedrohungsmodell für die gewählten Parser und den Speicherpfad. Nutzen Sie für das umfassendere Retrieval-Bedrohungsmodell, einschließlich Poisoning, Berechtigungslecks, Prompt-Injection und unsicherer Ausgabe, zusätzlich das OWASP RAG Security Cheat Sheet.

Zu den möglichen Schutzmaßnahmen gehören aus dem Dateiinhalt geprüfte Positivlisten für Dateitypen, Grenzwerte für Größe und Archiventpackung, zufällige Speichernamen, Signaturprüfungen, isolierte Parsing-Prozesse ohne ausgehenden Netzwerkzugriff und mit Ressourcenbegrenzungen sowie Content Disarm and Reconstruction, wenn das Bedrohungsmodell dies rechtfertigt. Kein einzelner Scanner kann die Sicherheit einer Datei garantieren.

Stufe 4: Textextraktion und OCR

In der Praxis sind PDFs kein einheitliches Format. Einige enthalten auswählbaren Text. Andere sind Scans. Manche verfügen über Spalten, Tabellen, Fußnoten, Formulare, Kommentare, Stempel oder versteckte Textebenen.

Wählen Sie den Extraktionspfad anhand des Dokumenttyps: Vergleichen Sie textorientierte Extraktoren für digital erstellte PDFs, layoutbewusste Konverter für strukturierte Dokumente und OCR-Verfahren für Scans. Die Wahl des Tools muss sich an gemessener Layout- und Tabellengenauigkeit, Sprachunterstützung, Lizenz, Patch-Prozess und Datengrenze orientieren.

Übernehmen Sie keinen universellen OCR-Konfidenzschwellenwert aus einem Blogbeitrag. Kalibrieren Sie ihn anhand einer Stichprobe eigener Dokumente. Sinnvoll sind zwei Grenzwerte: Unterhalb des niedrigeren wird die Seite sofort abgelehnt, dazwischen wird sie zur menschlichen Prüfung vorgemerkt und oberhalb des höheren automatisch weiterverarbeitet. Die geeigneten Werte hängen vom Scanner, vom Alter der Dokumente und von der Sprache ab.

Für estnische und mehrsprachige Archive nehmen Sie Diakritika, ältere maschinengeschriebene Seiten, Tabellen, Stempel sowie estnisch-russische Beispiele in den Benchmark auf. Stellen Sie sicher, dass das ausgewählte OCR-System über die erforderlichen Sprachdaten verfügt, und messen Sie anschließend die Zeichen-, Wort-, Feld- und Tabellengenauigkeit an repräsentativen Seiten. Versprechen Sie keine universelle Pilotdauer.

Erfassen Sie zur Extraktionsqualität:

• Extraktionsmethode,
• OCR-Konfidenz,
• Seitenanzahl,
• extrahierte Zeichenzahl,
• Status der Tabellenextraktion,
• erkannte Sprache,
• Seiten ohne Text,
• Parserwarnungen.

Schlecht extrahierte Inhalte dürfen nicht unbemerkt in den Index gelangen. Leiten Sie sie zur Prüfung weiter oder kennzeichnen Sie sie mit geringer Konfidenz.

Häufige Probleme:

• Spalten werden in der falschen Reihenfolge eingelesen,
• Tabellenzeilen wurden falsch zusammengeführt,
• in jedem Chunk wiederholte Kopfzeilen,
• vollständig fehlende gescannte Seiten,
• handschriftliche Notizen ignoriert,
• versteckte Textschicht, die dem sichtbaren Scan widerspricht,
• falsche Erkennung von Kontonummern durch OCR.

Vergleichen Sie bei wichtigen Dokumenten die gerenderte Seite stichprobenartig mit dem extrahierten Text.

Stufe 5: Struktur erhalten

RAG-Systeme benötigen mehr als Text. Sie brauchen ausreichend Struktur, um nützliche, durch Quellen belegte Antworten zu erzeugen.

Bewahren Sie:

• Titel,
• Überschriftenpfad,
• Abschnittsnummer,
• Seitenzahl,
• Tabellenüberschriften,
• Listengrenzen,
• Dokumentversion,
• Datum des Inkrafttretens,
• Quell-URL oder Speicherpfad.

Teilen Sie den Text so in Chunks auf, dass Überschriften und Seitenverweise erhalten bleiben. Ein Chunk mit dem Satz „Das Folgende gilt“, aber ohne die vorangehende Überschrift, ist ein schwacher Beleg.

Für Tabellen entscheiden Sie sich dafür, ob Sie:

• die Tabelle als Markdown beibehalten,
• sie in strukturiertes JSON konvertieren,
• sowohl Text als auch strukturierte Zeilen speichern,
• sie ausschließen, bis ein besserer Parser verfügbar ist.

Behaupten Sie nicht, die Tabellenextraktion sei gelöst, wenn Ihr Anwendungsfall auf genaue Preise, Datumsangaben, Grenzwerte oder Schwellenwerte angewiesen ist.

Stufe 6: Metadaten zuordnen

Jeder Chunk sollte Metadaten enthalten, die beim Retrieval erhalten bleiben:

{
  "sourceId": "policy-2026-expenses",
  "documentId": "doc_123",
  "tenantId": "tenant_a",
  "visibility": "internal",
  "allowedRoles": ["finance", "leadership"],
  "sensitivity": "confidential",
  "sourceOwner": "Finance",
  "version": "2026-02",
  "lastReviewedAt": "2026-02-10",
  "effectiveFrom": "2026-03-01",
  "page": 7,
  "headingPath": ["Travel", "Hotel limits"],
  "contentHash": "sha256:..."
}

Metadaten liefern Eingaben für die Durchsetzung von Richtlinien, setzen diese aber nicht selbst durch. Die Anwendung muss die vertrauenswürdige Herkunft der Metadaten prüfen und die Autorisierung bei Veröffentlichung, Retrieval, Zwischenspeicherung, Quellenangabe, Generierung und Export durchsetzen.

Stufe 7: Berechtigungen abbilden

Berechtigungen müssen durchgesetzt werden, bevor Retrieval-Ergebnisse das Modell erreichen. Prüfen Sie sie außerdem erneut bei Antworten, Quellenangaben, Zwischenspeicherung und Exporten, wenn sich Identität oder Richtlinie geändert haben könnten.

Gutes Muster:

1. Der Nutzer stellt eine Frage.
2. Die Anwendung leitet Mandant, Nutzer, Rollen, Gruppen und Datenberechtigungen aus der Authentifizierung ab.
3. Der Retriever filtert Kandidaten-Chunks nach Berechtigungen.
4. Das Ranking erfolgt innerhalb der zulässigen Chunks.
5. Das Modell erhält nur die zulässigen Chunks.

Unsicheres Muster:

1. Breiter Abruf ohne vorherige Berechtigungsfilterung.
2. Leiten Sie alle wahrscheinlichen Chunks an das Modell weiter.
3. Der Prompt lautet: „Antworte ausschließlich mit den Chunks, auf die der Nutzer zugreifen kann.“

Dieses unsichere Muster hat die Daten bereits im Modellkontext offengelegt.

Wenn die Berechtigungen des Quellsystems komplex sind, beginnen Sie enger. Es ist besser, eine Antwort nicht zu liefern, als ein vertrauliches Dokument offenzulegen.

Stufe 8: Chunking und Embedding

Die Aufteilung in Chunks ist eine Sicherheits- und Qualitätsentscheidung und nicht nur eine Frage der Suchoptimierung.

Richtlinien:

• Halten Sie Chunks innerhalb der Berechtigungsgrenzen.
• Fügen Sie öffentliche und vertrauliche Texte nicht zu einem einzigen Chunk zusammen.
• Schließen Sie Überschriften und Quellenangaben ein.
• Vermeiden Sie große Blöcke, die unzusammenhängende Abschnitte enthalten.
• Vermeiden Sie zu kleine Chunks, die den Kontext verlieren.
• Embeddings neu erstellen, wenn sich Quelltext oder Metadaten ändern.
• Speichern Sie das Embedding-Modell und die Version.

Prüfen Sie bei sensiblen Quellen, ob der Embedding-Anbieter, die Vektordatenbank und die Protokolle für diese Datenklasse freigegeben sind.

Stufe 9: Qualitätsprüfungen

Bevor Sie eine Quelle in den produktiven Abruf übernehmen, führen Sie Prüfungen durch:

• alle Dokumente haben Verantwortliche,
• alle Chunks verfügen über Berechtigungsmetadaten,
• veraltete Dokumente werden markiert,
• Seiten mit fehlgeschlagener Extraktion werden ausgeschlossen oder überprüft,
• beispielhafte Fragen rufen die erwarteten Quellen ab,
• nicht autorisierte Nutzer erhalten keine besonders geschützten Chunks,
• gelöschte Dokumente verschwinden aus der Suche,
• die Quellenangaben verweisen auf gültige Quellorte,
• verdächtige Anweisungen in Dokumenten werden als Inhalt isoliert und nicht ausgeführt.

Der letzte Punkt ist entscheidend. Dokumente können Prompt-Injection enthalten. Die Aufnahmepipeline sollte solchen Text nicht pauschal und unbemerkt entfernen, denn Nutzer müssen möglicherweise wissen, was in einem Dokument steht, und die Entfernung kann Nachweise beschädigen. Die Laufzeit muss abgerufene Inhalte als Daten behandeln, verhindern, dass sie Toolzugriff gewähren oder Richtlinien ändern, Toolargumente unabhängig prüfen und für folgenschwere Auswirkungen eine menschliche Genehmigung verlangen.

Stufe 10: Indexversion atomar veröffentlichen

Lassen Sie nicht zu, dass teilweise indizierte Dokumente oder eine Mischung aus alten und neuen Berechtigungen in den aktiven Index gelangen. Erstellen Sie einen Kandidatenindex oder einen versionierten Namespace, und führen Sie dann Folgendes durch:

1. das Quell- und Versionsmanifest sowie die Inhaltshashes einfrieren;
2. Dokumentzahlen, Extraktionsfehler, Berechtigungsabdeckung, Duplikatsrichtlinie, Embedding-Modell und -Revision sowie repräsentative autorisierte und nicht autorisierte Abfragen prüfen;
3. die Kandidatenversion, die Quellversionen, das Testergebnis, die genehmigende Person und das Rollback-Ziel dokumentieren;
4. atomar einen Alias oder Anwendungszeiger auf die genehmigte Version umschalten, sofern der Store dies unterstützt;
5. Retrieval- und Antwort-Caches ungültig machen oder versionieren und
6. nach der Freigabe Fehler, Zugriffsablehnungen, leere Retrieval-Ergebnisse und Anfragen an veraltete Versionen überwachen.

Kann der Vektorspeicher Versionen nicht atomar umschalten, führen Sie auf Anwendungsebene einen Veröffentlichungsstatus ein, der unvollständige Datensätze ausschließt, und testen Sie parallele Lesezugriffe während der Umschaltung. Der Entzug von Berechtigungen und die dringende Löschung einer Quelle dürfen nicht auf eine vollständige Neuerstellung warten: Erzwingen Sie die aktuelle Autorisierung außerhalb des Indexes, sperren Sie die betroffene Quelle sofort, leeren Sie relevante Caches und schließen Sie die Bereinigung abgeleiteter Daten über den Lebenszyklus-Workflow ab.

Ein Rollback sollte den letzten genehmigten Indexzeiger wiederherstellen, ohne widerrufene Zugriffe oder gelöschte Daten wieder freizugeben. Prüfen Sie, dass der Rollback keine ersetzte ACL (Access Control List), kein gelöschtes Dokument, keine vergiftete Quelle und keine veraltete zwischengespeicherte Antwort wiederherstellt.

Stufe 11: Aufbewahrung und Löschung

RAG-Systeme speichern Daten häufig unbeabsichtigt länger als das Quellsystem.

DSGVO-Artikel 17 definiert ein Recht auf Löschung mit Bedingungen und Ausnahmen. Qualifizierte Rechtsberatung muss die geltende Verpflichtung und jede rechtmäßige Aufbewahrung bestimmen. Das System benötigt dennoch ein Inventar und einen Lebenszyklusprozess für jede Kopie und jeden abgeleiteten Inhalt:

• ursprünglicher Dateicache,
• extrahierter Text,
• Chunks,
• Embeddings,
• Zusammenfassungen,
• Vorschaubilder oder gerenderte Seiten,
• Bewertungsstichproben,
• Protokolle mit einer genehmigten Grundlage für die Minimierung und Aufbewahrungsdauer,
• Backups mit dokumentiertem Ablaufdatum und Wiederherstellungsverhalten.

Wenn ein Dokument gelöscht oder der Zugriff entzogen wird, dürfen Retrieval- und Antwort-Caches es nach Ablauf der dokumentierten Frist nicht mehr ausgeben. Der Löschworkflow muss abgeleitete Speicherorte abdecken und verhindern, dass eine alte Sicherung oder ein verzögerter Aufnahmeauftrag den Datensatz wieder einspielt.

Zu protokollieren sind:

• deletedAt,
• deletedBy oder Ereignis im Quellsystem,
• Löschgrund,
• Status der Bereinigung in nachgelagerten Systemen,
• Prüfergebnis.

Verlassen Sie sich nicht auf die Aussage „Wir haben es aus der Benutzeroberfläche entfernt.“ Vektorspeicher und Caches sind leicht zu vergessen.

Stufe 12: operative Verantwortung

Jede produktive Quelle benötigt eine verantwortliche Person sowie einen Prüfauslöser oder -rhythmus, der sich aus ihrer Änderungsrate und ihren Auswirkungen ergibt.

Definieren Sie für jede Quelle Folgendes:

• wer die Aufnahme genehmigt,
• wer Berechtigungsänderungen genehmigt,
• wer veraltete Dokumente prüft,
• wer Extraktionsfehler bearbeitet,
• wer auf Datenlöschanfragen reagiert,
• wer Retrieval-Fehler untersucht.

Wenn eine Quelle keinen Verantwortlichen hat, sollte sie nicht in einem produktiven RAG-System sein.

Quellengovernance, keine Garantien

Sichere Dokumentenaufnahme für RAG ist gezielte Quellengovernance. Sie macht Retrieval-Verhalten und Fehler besser beobachtbar und testbar, garantiert aber nicht, dass generierte Antworten korrekt oder sicher sind.

Die Kernkontrollen:

• Quellen registrieren,
• Daten klassifizieren,
• Dateien vor dem Parsen prüfen,
• die Extraktionsqualität messen,
• Struktur erhalten,
• Metadaten zuordnen,
• Berechtigungen vor dem Retrieval durchsetzen,
• unbefugten Zugriff testen,
• das Löschen unterstützen,
• Verantwortlichkeiten zuweisen.

Quellenqualität und Quellkontrollen sind notwendige Voraussetzungen für Antwortqualität und Sicherheit, aber keine Garantien. Validieren Sie Retrieval, Autorisierung, Grounding, Ablehnungsverhalten, Toolnutzung und Lebenszyklusverhalten durchgängig.