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

Die meisten RAG-Fehler entstehen vor dem Retrieval. Das Dokument war veraltet. Die OCR hat eine Tabelle übersehen. Die Quelle hatte keine verantwortliche Person. Die Berechtigungsmetadaten gingen verloren. Ein gelöschter Vertrag blieb im Vektorspeicher. Ein gescanntes PDF enthielt verborgenen Text, den niemand überprüft hatte. Das System antwortete selbstbewusst, weil die Ingestion-Pipeline „Text ist vorhanden“ mit „Wissen kann sicher verwendet werden“ gleichsetzte.

Sichere Dokumentenaufnahme ist die Quellenkontrolle für Unternehmenswissen. Sie entscheidet, was in das Retrieval-System gelangt, wer es sehen darf, wie die Aktualität verfolgt wird, wie die Löschung funktioniert und wie fehlerhafte Eingaben erkannt werden.

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

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

Die Ingestion-Pipeline

Eine Produktions-Pipeline sollte klare Stufen haben:

1. Quellregistrierung.
2. Datenklassifizierung.
3. Dateisicherheitsprüfungen.
4. Textextraktion und OCR.
5. Strukturerhalt.
6. Anreicherung mit Metadaten.
7. Berechtigungsabbildung.
8. Chunking und Embedding.
9. Qualitätsprüfungen.
10. Indexveröffentlichung.
11. Aufbewahrung und Löschung.

Die genauen Tools können variieren. Die Kontrollpunkte sollten jedoch gleich bleiben.

Stufe 1: Quellregistrierung

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

Für jede Quelle sollten Sie aufzeichnen:

• Quellname,
• führendes System,
• für die Quelle verantwortliche Person,
• für die Daten verantwortliche Person,
• erlaubte Benutzer oder Rollen,
• Dokumenttypen,
• Vertraulichkeitsstufe,
• Aufbewahrungsregel,
• Aktualisierungshäufigkeit,
• Löschverhalten,
• Prüfplan.

Beispiele für Quellen:

• öffentliches Hilfe-Center,
• internes Support-Handbuch,
• Vertriebsunterlagen,
• Kundenverträge,
• HR-Richtlinien,
• Engineering-Runbooks,
• Produktdokumentation,
• Meeting-Transkripte.

Diese Quellen sollten nicht alle in denselben Index mit denselben Berechtigungen landen.

Stufe 2: Datenklassifizierung vor der Extraktion

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

Nützliche Klassen:

Klassifizierung ist nicht nur Compliance-Papierkram. Sie entscheidet, ob Inhalte an eine gehostete Embedding-API gesendet, in einer gemeinsam genutzten Vektordatenbank gespeichert, in Protokolle aufgenommen oder für Evaluationsbeispiele verwendet werden dürfen.

Stufe 3: Dateisicherheitsprüfungen

Dokumente können bösartig oder schlicht defekt sein.

Vor der Extraktion:

• Prüfen Sie den Dateityp anhand einer Positivliste,
• Erzwingen Sie Dateigrößenbeschränkungen,
• Scannen Sie auf Malware, wenn Ihr Umfeld dies erfordert,
• Lehnen Sie verschlüsselte Dateien ab, sofern kein freigegebener Entschlüsselungspfad vorhanden ist,
• lehnen Sie Dateien mit nicht unterstützten eingebetteten Objekten ab,
• Normalisieren Sie Dateinamen,
• Speichern Sie den Hash der Originaldatei,
• Protokollieren Sie, wer die Datei hochgeladen oder angebunden hat.

Dies ist besonders wichtig, wenn Benutzer ohne Administratorrechte Dokumente hochladen können. Eine auf Administratoren beschränkte Aufnahme senkt das Risiko, beseitigt es aber nicht.

Antiviren- und Content-Disarm-Kontrollen sind in den meisten RAG-Stacks nicht automatisch enthalten. Wenn nicht vertrauenswürdige Benutzer Dateien hochladen können, setzen Sie vor dem Parsen eine echte Dateisicherheitsschicht ein.

So sieht diese Schicht in der Praxis aus, nach zunehmendem Schutzbedarf geordnet: mindestens ein signaturbasierter Scanner der ClamAV-Klasse; das Parsen in einem isolierten Container ohne ausgehenden Netzwerkzugriff – Parser für PDF- und Office-Formate weisen seit Langem CVEs auf und sind daher selbst als Angriffsfläche zu behandeln; und bei tatsächlich nicht vertrauenswürdigen Eingaben Content Disarm and Reconstruction (CDR), das eine saubere Kopie neu aufbaut, statt der Originaldatei zu vertrauen. Die meisten KMU-Pipelines benötigen die ersten beiden Maßnahmen. Ergänzen Sie CDR, wenn Außenstehende Dokumente einreichen können.

Stufe 4: Textextraktion und OCR

PDFs sind in der Praxis kein einheitliches Format. Einige enthalten auswählbaren Text, andere sind Scans. Manche enthalten Spalten, Tabellen, Fußnoten, Formulare, Kommentare, Stempel oder verborgene Textebenen.

Wählen Sie den Extraktionsweg anhand des Dokumenttyps: einen textorientierten Extraktor für digital erzeugte PDFs (Klasse PyMuPDF oder pdfplumber), einen layoutbewussten Konverter für strukturierte Dokumente (Klasse Docling oder Unstructured – Tabellen und Lesereihenfolge bleiben deutlich besser erhalten) und OCR nur für echte Scans (Tesseract als selbst gehostete Ausgangslösung; einen Cloud-OCR-Dienst bei schlechter Scanqualität, sofern die Datenklassifizierung dies zulässt).

Übernehmen Sie keinen universellen Schwellenwert für die OCR-Konfidenz aus einem Blogbeitrag. Kalibrieren Sie ihn anhand einer Stichprobe Ihrer eigenen Dokumente. Sinnvoll sind zwei Schwellenbereiche: Unterhalb der unteren Grenze wird die Seite abgelehnt, zwischen beiden Grenzen wird sie zur menschlichen Prüfung vorgemerkt und oberhalb der oberen Grenze wird sie weiterverarbeitet. Die geeigneten Grenzen hängen von Ihrem Scanner, dem Alter der Dokumente und der Sprache ab.

Ein Hinweis speziell für unseren Markt: Estnische OCR ist schwieriger als englische OCR. Tesseract liefert ein estnisches Modell, doch die Genauigkeit bei õ/ä/ö/ü, älteren maschinengeschriebenen Archiven und gemischten estnisch-russischen Dokumenten schwankt so stark, dass Sie vor der Auswahl einer Engine einen Pilotvergleich mit einer repräsentativen Stichprobe Ihres eigenen Archivs durchführen sollten. Für estnische Unternehmen kostet dieser Pilotversuch einen halben Tag und verhindert später ein Viertel der unbemerkten Retrieval-Fehler.

Verfolgen Sie die Extraktionsqualität:

• Extraktionsmethode,
• OCR-Konfidenz,
• Seitenanzahl,
• extrahierte Zeichenanzahl,
• Tabellenextraktionsstatus,
• erkannte Sprache,
• Seiten ohne Text,
• Parserwarnungen.

Extraktionen von geringer Qualität 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 gelesen,
• Tabellenzeilen werden falsch zusammengeführt,
• Überschriften werden in jedem Chunk wiederholt,
• gescannte Seiten fehlen vollständig,
• handschriftliche Notizen werden ignoriert,
• eine verborgene Textebene widerspricht dem sichtbaren Scan,
• OCR konvertiert Kontonummern falsch.

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

Stufe 5: Struktur erhalten

RAG-Systeme benötigen mehr als nur Text. Sie benötigen genug Struktur, um nützliche, quellbasierte Antworten zu erzeugen.

Beibehalten Sie:

• Titel,
• Überschriftenpfad,
• Abschnittsnummer,
• Seitennummer,
• Tabellenbeschriftungen,
• Listengrenzen,
• Dokumentversion,
• Geltungsdatum,
• Quell-URL oder Speicherpfad.

Erstellen Sie Chunks zusammen mit Überschriften und Seitenverweisen. Ein Chunk mit dem Satz „Das Folgende gilt“ ist ohne die vorausgehende Überschrift ein schwacher Nachweis.

Für Tabellen entscheiden Sie, ob Sie:

• die Tabelle als Markdown beibehalten,
• sie in strukturiertes JSON konvertieren,
• sowohl Text als auch strukturierte Zeilen speichern,
• sie bis zu einem besseren Parser auslassen.

Tun Sie nicht so, als sei die Tabellenextraktion gelöst, wenn Ihr Anwendungsfall von exakten Preisen, Datumsangaben, Grenzwerten oder Schwellenwerten abhängt.

Stufe 6: Metadaten anreichern

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:..."
}

Anhand der Metadaten setzt die Anwendung nach dem Retrieval Richtlinien durch. Ohne sie erhält das Modell Text losgelöst von den Regeln, die seine sichere Verwendung ermöglichen.

Stufe 7: Berechtigungsabbildung

Berechtigungen müssen abgebildet und durchgesetzt werden, bevor Retrieval-Ergebnisse das Modell erreichen.

Gutes Muster:

1. Der Benutzer stellt eine Frage.
2. Die Anwendung leitet aus der Authentifizierung Tenant, Benutzer, Rollen, Gruppen und Datenberechtigungen ab.
3. Der Retriever filtert mögliche Chunks anhand der Berechtigungen.
4. Das Ranking erfolgt innerhalb der erlaubten Chunks.
5. Das Modell erhält nur erlaubte Chunks.

Schlechtes Muster:

1. Breit abfragen.
2. Alle wahrscheinlichen Chunks an das Modell senden.
3. Der Prompt sagt: „Antworte nur mit Chunks, auf die der Benutzer zugreifen darf.“

Beim schlechten Muster wurden die Daten bereits im Modellkontext offengelegt.

Wenn die Quellberechtigungen komplex sind, beginnen Sie mit einem engeren Zugriff. Es ist besser, eine Antwort nicht zu finden, als ein vertrauliches Dokument offenzulegen.

Stufe 8: Chunking und Embedding

Chunking ist eine Sicherheits- und Qualitätsentscheidung, nicht nur eine Frage der Suchoptimierung.

Richtlinien:

• Halten Sie Chunks innerhalb der Berechtigungsgrenzen.
• Fügen Sie öffentlichen und vertraulichen Text nicht in einen Chunk zusammen.
• Fügen Sie Überschriften und Quellverweise hinzu.
• Vermeiden Sie riesige Chunks, die unabhängige Abschnitte enthalten.
• Vermeiden Sie winzige Chunks, die den Kontext verlieren.
• Erstellen Sie die Embeddings neu, wenn sich Quelltext oder Metadaten ändern.
• Speichern Sie Embedding-Modell und Version.

Prüfen Sie bei sensiblen Quellen, ob Ihr Embedding-Anbieter, Vektorspeicher und Ihre Protokolle für diese Datenklasse freigegeben sind.

Stufe 9: Qualitätskontrollen

Führen Sie vor der Freigabe einer Quelle für das produktive Retrieval folgende Prüfungen durch:

• für alle Dokumente sind verantwortliche Personen benannt,
• alle Chunks enthalten Berechtigungsmetadaten,
• veraltete Dokumente sind markiert,
• Seiten mit fehlgeschlagenen Extraktionen werden ausgeschlossen oder zur Prüfung gestellt,
• Beispielfragen liefern die erwarteten Quellen,
• nicht autorisierte Benutzer erhalten keine geschützten Chunks,
• gelöschte Dokumente verschwinden aus der Suche,
• Quellenangaben verweisen auf gültige Fundstellen,
• verdächtige Anweisungen in Dokumenten werden als Inhalt isoliert, nicht befolgt.

Der letzte Punkt ist wichtig. Dokumente können Prompt-Injection enthalten. Die Ingestion-Pipeline sollte solche Texte nicht vollständig entfernen, da Benutzer manchmal wissen müssen, was ein Dokument aussagt. Das Laufzeitsystem muss sie jedoch als nicht vertrauenswürdigen Dokumentinhalt behandeln.

Stufe 10: Aufbewahrung und Löschung (hier wird Artikel 17 der DSGVO praktisch)

RAG-Systeme behalten oft Daten länger bei, als das Quellsystem es tut.

In dieser Stufe wird das Recht auf Löschung nach Artikel 17 der DSGVO von einer Richtlinienaussage zu einer technischen Anforderung: Wenn ein Löschantrag eingeht, ist „Wir haben die Quelldatei gelöscht“ keine vertretbare Antwort, solange an anderer Stelle der Pipeline Kopien fortbestehen. Die Löschung muss Folgendes umfassen:

• Originaldatei-Cache,
• extrahierter Text,
• Chunks,
• Embeddings,
• Zusammenfassungen,
• Vorschaubilder oder gerenderte Seiten,
• Evaluationsbeispiele,
• Protokolle, soweit gesetzlich vorgeschrieben,
• Sicherungen gemäß Richtlinie.

Wenn ein Dokument gelöscht oder der Zugriff darauf entzogen wird, darf das Retrieval keine Chunks daraus mehr zurückgeben. Idealerweise unterstützt das System die unwiderrufliche Löschung sensibler Quellen und eine dokumentierte Aufbewahrung von Sicherungen.

Verfolgen Sie:

• deletedAt,
• deletedBy oder Quellereignis,
• Löschgrund,
• Status der nachgeschalteten Bereinigung,
• Prüfergebnis.

Verlassen Sie sich nicht auf „Wir haben es aus der Benutzeroberfläche gelöscht.“ Vektorspeicher und Caches werden leicht übersehen.

Stufe 11: betriebliche Verantwortung

Für jede Quelle muss eine verantwortliche Person und ein Prüfintervall festgelegt sein.

Für jede Quelle definieren Sie:

• wer die Aufnahme genehmigt,
• wer Änderungen der Berechtigungen genehmigt,
• wer veraltete Dokumente prüft,
• wer Extraktionsfehler behandelt,
• wer auf Löschungsanfragen reagiert,
• wer Retrieval-Fehler untersucht.

Wenn niemand für eine Quelle verantwortlich ist, gehört sie nicht in ein produktives RAG-System.

Das Fazit

Sichere RAG-Ingestion ist im besten Sinne unspektakulär. Sie macht das Retrieval vorhersehbar.

Die Kernkontrollen:

• Quellen registrieren,
• Daten klassifizieren,
• Dateien vor dem Parsen prüfen,
• Extraktionsqualität messen,
• Struktur beibehalten,
• Metadaten anhängen,
• Berechtigungen vor dem Retrieval durchsetzen,
• nicht autorisierten Zugriff testen,
• Löschung unterstützen,
• Verantwortliche benennen.

Gute Antworten entstehen aus guten Quellen. Sichere Antworten entstehen durch gute Quellenkontrollen.