Dokument-Metadaten und Tagging für die Suche (Retrieval)

Ein KI-Assistent, der 30.000 Dokumente ohne Metadaten durchsucht, findet die Preisliste von 2019 genauso leicht wie die von 2026. Ein kurzes Metadatenschema (Typ, Produkt, Kunde, Gültigkeit, Verantwortliche(r), Sprache), teils von einem kleinen Sprachmodell befüllt und von Menschen geprüft, lässt den Assistenten filtern, bevor er rankt. Diese Arbeit ist unspektakulär, entscheidet aber oft darüber, ob ein RAG-Assistent nützlich oder peinlich ist.

Problem & Nutzen

• Wer: jedes KMU, das einen Assistenten über seine eigenen Dokumente (Angebote, Verträge, Handbücher, Qualitätsdokumente) einsetzen will. Dateien liegen in Ordnern, die nach Person, Projekt oder Jahr benannt sind; niemand weiß, welche Version gültig ist.
• Heute: Die Suche stützt sich auf Ordnerpfade und Dateinamen. Metadatenfelder in SharePoint oder im DMS sind vorhanden, aber leer, weil das Befüllen von Hand mühsam ist und niemand dafür zuständig ist.
• Warum KI hilft: Ein kleines Modell liest die ersten Seiten und schlägt Typ, Produkt, Kunde, Gültigkeit und Sprache vor. Menschen bestätigen die unsicheren Fälle. Die Metadaten dienen dann als Filter („nur gültige Verträge für Kunde X“) und als Ranking-Signal, was falsche oder veraltete Antworten verringert.
• Nutzen: bessere Antworten von RAG-Assistenten, schnellere manuelle Suche und eine Grundlage für Zugriffsregeln und Aufbewahrung. Wir nennen keine Prozentwerte; messen Sie die eigene Trefferquote an einem Testsatz (siehe Kennzahlen).

Varianten

• Ordner zuerst: Tags per Regeln aus Pfad und Dateiname ableiten; keine KI, am günstigsten, deckt in der Praxis oft 30-50 Prozent des Schemas ab.
• DMS-basiert: Paperless-ngx-Korrespondenten, Dokumenttypen, Tags und benutzerdefinierte Felder, befüllt durch Zuordnungsregeln plus einen LLM-Schritt.
• Microsoft 365: SharePoint-Spalten, Inhaltstypen und verwaltete Metadaten; optional KI-Autofill.
• Metadaten auf Chunk-Ebene: Tags werden auf jeden Text-Chunk im Vektorindex kopiert, damit der Retriever filtern kann. Nicht Gegenstand: Datenkataloge (DATA-007) und Aufbewahrungslabels (KNOW-025).

So funktioniert es

Dokumente (Freigabe / SharePoint / DMS)
  -> Textextraktion (nativer Text, OCR für Scans)
  -> Regeln aus Pfad und Dateiname (Kundenordner, Jahr)
  -> kleines LLM mit JSON-Schema schlägt fehlende Felder + Konfidenz vor
  -> Konfidenz >= Schwellenwert: zurückschreiben | darunter: Prüfwarteschlange
  -> Metadaten nach SharePoint / Paperless-ngx / Vektorindex
  -> Retrieval-Filter + Ranking im Assistenten

• Zuerst das Schema: 5-8 Felder, geschlossene Wertelisten für Typ und Produkt, Freitext nur für den Kunden. Zu Kategorienschemata siehe PREP-019.
• Eingeschränkte Ausgabe: Das Modell muss JSON liefern, das zum Schema passt (Structured Outputs in Ollama oder vLLM), sodass ungültige Tags gar nicht erst entstehen.
• Mensch-in-der-Schleife (Human-in-the-Loop): Eine prüfende Person sieht Dokument, vorgeschlagene Tags und Sicherheitswert; Korrekturen werden zu Testdaten (PREP-018).
• Gültigkeit: KI-extrahierte Daten werden mit einfachen Regeln geprüft (gültig ab vor gültig bis); „ersetzt durch“-Verknüpfungen bleiben eine menschliche Aufgabe.

Datenaufbereitung

Welche Daten: die Dokumente selbst, das Metadatenschema, Kunden- und Produktlisten aus ERP oder CRM als zulässige Werte sowie 50-100 von Hand getaggte Beispiele als Testsatz.

Wo sie liegen: Dateiablagen, SharePoint und OneDrive, Google Drive, Nextcloud, Postfach-Exporte, ein DMS und Scans.

Typische Lücken: Scans ohne Text, nahezu doppelte Versionen („final_v3_NEU“), Dokumente ohne Datum, Kundennamen in fünf Schreibweisen, enthaltene personenbezogene Daten, zu weit gefasste Berechtigungen.

Aufbereitungsschritte: 1. Schema und zulässige Werte mit zwei Abteilungen abstimmen (halbtägiger Workshop). 2. Dubletten und offensichtlichen Ballast entfernen; festlegen, welche Version als gültig gilt (PREP-009). 3. Scans per OCR in Text überführen (PREP-006); Kunden- und Produktnamen aus ERP-Exporten übernehmen (PREP-005). 4. 50-100 Dokumente von Hand taggen, als Testsatz und für Few-Shot-Prompts. 5. Berechtigungen vor dem Indexieren korrigieren (PREP-023) und Vertraulichkeitsstufen festlegen (PREP-024).

Werkzeuge: Excel oder eine SharePoint-Liste für das Schema, Paperless-ngx, n8n oder Power Automate, Docling oder die OCR des DMS, ein Skript für Dubletten.

Grober Aufwandsanteil: hoch, etwa die Hälfte des Projekts. Schema, Bereinigung und Prüfung dauern länger als der Modelllauf. Siehe GUIDE-003.

Umsetzungswege

Welcher Weg für wen

• KMU - Weg C: Verträge, Personal- und Kundendokumente sind sensibel, und ein einfacher Open-Source-Stack (Paperless-ngx oder n8n plus ein kleines Ollama-Modell) läuft mit einer Administratorin bzw. einem Administrator auf HW1/HW2. Derselbe Server bedient später RAG (PREP-013), Klassifikation und Zusammenfassungen (Baukasten-Effekt).
• Großunternehmen - Weg B: große, gemischte Ablagen in Microsoft 365 oder Google Workspace; Cloud-KI-Dienste in einer EU-Region plus Microsoft-Graph-Konnektoren fügen sich in die bestehende Governance ein. Weg A (Purview, SharePoint Premium) passt, wo Lizenzen bereits vorhanden sind.
• Entwickler - Weg C: Open-Weight-Modelle, Docling und eine Vektordatenbank geben Kontrolle über Schema und Filter.

Weg A — Kaufen (Standardsoftware)

• Microsoft 365: SharePoint-Inhaltstypen und verwaltete Metadaten, Microsoft-Purview-Vertraulichkeitslabels und automatische Kennzeichnung, SharePoint Premium (früher Syntex; Microsoft hat diese Produktfamilie mehrfach umbenannt, prüfen Sie daher aktuellen Namen und Preis) für Autofill und Dokumentverarbeitung. EU-Hosting über die EU Data Boundary.
• DMS-Produkte (EU-Anbieter): DocuWare, d.velop, ELO, Ceyoniq mit eingebauter Klassifikation; EU-Hosting und AVV prüfen.
• A wählen, wenn: Sie diese Werkzeuge bereits lizenziert haben und die Dokumenttypen Standard sind.

Weg B — Auf Cloud-KI-Diensten aufbauen

• Modelle: Mistral (EU-Anbieter) oder Azure OpenAI / Google Gemini / Claude in EU-Regionen, mit Structured Outputs.
• Orchestrierung: n8n oder Power Automate liest Dateien über Graph- oder Drive-APIs, ruft das Modell auf und schreibt Spalten zurück.
• B wählen, wenn: viele Ablagen, ein eigenes Schema, keine sensiblen Kategorien oder ein AVV mit Verarbeitung in der EU vorliegt.

Weg C — Selbst betreiben (Open Source)

• Stack: Paperless-ngx (benutzerdefinierte Felder, automatische Zuordnung), n8n selbst betrieben, Docling oder OCR, Ollama oder vLLM mit einem kleinen Open-Weight-Modell (zum Beispiel aus der Klasse Qwen oder Mistral Small); Embeddings über ein offenes Modell.
• Hardware: HW1 bewältigt einige tausend Dokumente über Nacht mit einem kleinen Modell; HW2 für schnellere Läufe und längere Dokumente.
• Aufwand: 3-5 Tage Einrichtung, danach Prüfung. Nextcloud-Nutzer können Tags über Flows und die Integrationen des Nextcloud Assistant ergänzen.

Weg D — Eigenes Training

Ein kleines Klassifikationsmodell nur dann feintunen, wenn Tausende geprüfter Dokumente vorliegen und das Schema stabil ist; lohnt sich meist nicht.

Stand der Technik (2026)

• Kleine, auf Anweisungen trainierte Modelle extrahieren Typ, Daten und Parteien aus sauberem Text zuverlässig; schemagesteuerte Dekodierung beseitigt Formatfehler.
• Metadatenfilter plus Hybridsuche (Stichwort und Vektor) ist in RAG-Frameworks und Vektordatenbanken Standard und verbessert die Genauigkeit gegenüber reiner Vektorsuche.
• Grenzen: Das Modell rät die Gültigkeit aus dem Kontext, verwechselt ähnliche Kunden, tut sich mit Scans schwer und kann nicht wissen, dass ein Dokument zurückgezogen wurde. Lassen Sie bei Verträgen oder regulierten Dokumenten nie allein die KI über „gültig“ entscheiden.

Gemeinsame Bausteine & Kombinationen

• Gleicher Stack: PREP-013 (Wissensbasis für RAG), PREP-014 (KI-taugliches Verfassen), PREP-015 (Terminologielisten), PREP-019 (Kategorienschemata), DOC-008 Klassifikation im Posteingang.
• Vorgelagert: PREP-006, PREP-009. Nachgelagert: PREP-023 (Berechtigungen), RAG-Assistenten.
• Hardware: ein HW1/HW2-Server für alle Aufgaben mit kleinen Modellen.

Aufwand, Kosten & Kennzahlen

• Weg C: etwa 3-5 Tage Einrichtung, 5-10 Tage Prüfung für 10.000-30.000 Dokumente (Planungsschätzung, kein Benchmark).
• Weg A: Lizenzkosten; Konfiguration 2-5 Tage.
• Weg B: API-Kosten pro Token, beim Tagging gering, plus 3-5 Tage Integration.
• Kennzahlen: Anteil der Dokumente mit vollständigen Metadaten, Tag-Genauigkeit gegenüber dem von Hand getaggten Testsatz, Anteil der an die Prüfung weitergeleiteten Dokumente, Trefferqualität (Precision) des Assistenten vorher und nachher, Zeit bis zum Auffinden eines Dokuments.

Menschen & Veränderung

Früh einbinden: Abteilungsleitungen (Schema und Verantwortliche), Endanwender (Prüfende), IT, Datenverantwortliche und die Datenschutzbeauftragte bzw. der Datenschutzbeauftragte. Betriebsrat: hängt vom Einzelfall ab. Tagging liest Dokumente, nicht Verhalten, doch eine Prüfwarteschlange protokolliert, wer was getaggt hat; für § 87 Abs. 1 Nr. 6 BetrVG genügt die objektive Eignung zur Überwachung (BAG), vereinbaren Sie dies daher in einer Betriebsvereinbarung. § 90 Abs. 1 Nr. 3 verlangt die rechtzeitige Unterrichtung, wenn Arbeitsverfahren mit KI geplant werden; nach § 80 Abs. 3 kann der Betriebsrat einen Sachverständigen hinzuziehen. Öffentliche Stellen beteiligen den Personalrat (GUIDE-004).

Datenschutz: Dokumente enthalten Kunden- und Beschäftigtendaten; prüfen Sie Rechtsgrundlage, AVV (Art. 28 DSGVO) für Cloud-Modelle und eine Datenschutz-Folgenabschätzung (DSFA, Art. 35), wenn Personalakten ausgewertet werden (GUIDE-005). KI-Kompetenz: Art. 4 KI-Verordnung (AI Act) in der Fassung der Verordnung (EU) 2026/1744 verlangt Maßnahmen zur Förderung der KI-Kompetenz der Beschäftigten; weisen Sie die Prüfenden ein (GUIDE-006).

Pilot und Ton: Beginnen Sie mit einer Abteilung und einem Dokumenttyp, stellen Sie es als „weniger Suchen“ dar, benennen Sie eine Fürsprecherin oder einen Fürsprecher und halten Sie jeden Tag überschreibbar (GUIDE-008). Bedenken: „Die KI entscheidet, was mein Dokument ist“ - sie schlägt nur vor.

Risiken, Regulierung & Compliance

• KI-Verordnung (AI Act): minimales Risiko. Wenn Metadaten Personalauswahlentscheidungen steuern, können ab 2. Dez. 2027 die Hochrisiko-Regeln greifen (Anhang III); verwenden Sie Tags dafür nicht.
• DSGVO: Tags können selbst personenbezogene Daten sein (Kundennamen); halten Sie sie in Ihren eigenen Systemen und erfassen Sie die Verarbeitung im Verzeichnis.
• Risiken: falsche „gültig“-Kennzeichen, Offenlegung vertraulicher Dokumente über neue Filter, Tag-Drift. Gegenmaßnahmen: Prüfwarteschlange, in den Index übernommene Berechtigungen, regelmäßige Stichproben (GUIDE-011, GUIDE-013).

Erste Schritte

1. Einen Anwendungsfall wählen (zum Beispiel Vertragsassistent) und das Schema mit der Abteilung festlegen.
2. 50-100 Dokumente von Hand taggen.
3. Regeln plus ein kleines Modell auf 500 Dokumenten laufen lassen; mit dem Testsatz vergleichen.
4. Sicherheitsschwellen festlegen und die Prüfwarteschlange mit zwei Prüfenden starten.
5. Tags in den Index schreiben und das Retrieval mit und ohne Filter testen (GUIDE-009).

Quellen

1. Microsoft - Managed metadata in SharePoint - https://learn.microsoft.com/sharepoint/managed-metadata
2. Microsoft - EU Data Boundary for the Microsoft Cloud - https://learn.microsoft.com/privacy/eudb/eu-data-boundary-learn
3. Paperless-ngx - Documentation - https://docs.paperless-ngx.com/
4. Ollama - Structured outputs - https://docs.ollama.com/capabilities/structured-outputs
5. n8n - Documentation (self-hosting) - https://docs.n8n.io/hosting/
6. Regulation (EU) 2024/1689 (AI Act) - https://eur-lex.europa.eu/eli/reg/2024/1689/oj
7. Regulation (EU) 2016/679 (GDPR) - https://eur-lex.europa.eu/eli/reg/2016/679/oj