Assistra Logo

WISSEN > KI INFRASTRUKTUR > METADATEN & KLASSIFIZIERUNG

Autor: Dirk Neumann                Geschäftsführer ASSISTRA Cloud Services GmbH                            17.08.2026

Metadaten und Klassifizierung für KI
Warum Embeddings strukturierte Beschreibungen nicht ersetzen


Das sollten Sie mitnehmen:
 

  1. Metadaten und Embeddings beantworten unterschiedliche Fragen.
    Embeddings bilden Inhalte als Vektoren ab und stützen Ähnlichkeitssuche, Metadaten beschreiben strukturierte Eigenschaften einer Ressource.
  2. Klassifizierung ordnet Ressourcen definierten Kategorien zu.
    Kontrollierte Vokabulare halten diese Zuordnung über Systemgrenzen hinweg maschinell auswertbar.
  3. Metadaten steuern den Retrieval-Prozess.
    Strukturierte Filter grenzen ein, welche Dokumente eine semantische Suche überhaupt berücksichtigen darf.
  4. Klassifizierung ist keine Zugriffskontrolle.
    Die Kennzeichnung „vertraulich“ beschreibt eine Eigenschaft; durchsetzen muss sie eine Autorisierungsarchitektur.
  5. Metadaten benötigen einen Lebenszyklus.
    Ändert sich ein Quelldokument, veralten Chunks, Embeddings und Suchindex ohne konsequente Nachführung.
  6. Metadatenqualität begrenzt die Retrieval-Qualität.
    Uneinheitliche Werte führen dazu, dass ein technisch korrekter Filter die fachlich falsche Menge beschreibt.

Metadaten und Klassifizierung für KI

Inhaltsverzeichnis

Unternehmensdaten werden für KI-Anwendungen nicht allein dadurch nutzbar, dass sie gespeichert und technisch erreichbar sind. Ein KI-System muss Daten finden, voneinander unterscheiden, ihrem fachlichen Kontext zuordnen und je nach Architektur entscheiden können, welche Informationen für eine konkrete Anfrage überhaupt in Betracht kommen. 

Metadaten beschreiben eine Ressource, nicht ihren Inhalt 

Metadaten sind strukturierte Informationen über eine Ressource. Ein Dokument besteht damit aus zwei logisch unterscheidbaren Informationsebenen: dem eigentlichen Inhalt — Text, Bild, Tabelle — und einer Beschreibungsebene, die diesen Inhalt charakterisiert, ohne ihn zu ersetzen. 

Die Dublin Core Metadata Initiative definiert für diese Beschreibungsebene standardisierte Begriffe, unter anderem für Titel, Ersteller, Datum, Thema, Typ und Quelle. Für das Element dc:subject im Namespace /elements/1.1/ nennt die Spezifikation Keywords, Schlüsselbegriffe oder Klassifikationscodes als typische Ausprägungen und empfiehlt die Verwendung eines kontrollierten Vokabulars. Das gleichnamige dcterms:subject formuliert enger und empfiehlt, das Thema über eine URI zu referenzieren, die möglichst aus einem kontrollierten Vokabular stammt. 

[BILD 1: Zwei Beschreibungsebenen einer Ressource. Links der Inhalt (Textseite, angedeutet), rechts ein Feldblock mit Metadaten. Verbindung als Zuordnung, nicht als Ableitung. Keine Pfeilkette, keine Prozessdarstellung.] 

In Unternehmensumgebungen lassen sich Metadaten grob nach ihrer Funktion gliedern: 

Kategorie 

Beispiele 

Technisch 

Dateiformat, Größe, Änderungsdatum 

Identifikation 

Dokument-ID, Objekt-ID, Quelle 

Inhaltlich 

Thema, Dokumenttyp, Produkt 

Organisatorisch 

Abteilung, Projekt, Mandant 

Zeitlich 

Erstellungsdatum, Gültigkeitszeitraum 

Herkunft 

Quellsystem, Ersteller, Verarbeitungsschritt 

Governance 

Klassifikation, Aufbewahrungskategorie 

Zugriff 

Informationen über Zugriffsrechte oder Sicherheitsstatus 

Nicht jedes System benötigt alle diese Informationen. Entscheidend ist, welche Eigenschaften für Retrieval, Governance und den jeweiligen Anwendungsfall tatsächlich gebraucht werden. 

Ein häufiger Ausgangspunkt für Unternehmensdaten sind File Services. Dort existieren bereits technische Metadaten wie Dateiname, Pfad oder Zeitstempel. Diese Informationen können für KI-Anwendungen nützlich sein, beschreiben den fachlichen Inhalt aber nur begrenzt. Aus einem Dateinamen wie Q3-2026-final-v3.pdf lässt sich nicht zuverlässig ableiten, ob es sich um einen Finanzbericht, eine Produktdokumentation oder einen Projektstatus handelt. Eine strukturierte Beschreibung dagegen hält fest, dass es sich um einen Quartalsbericht des Geschäftsbereichs Vertrieb für Q3 2026 handelt, verfasst in deutscher Sprache, im Status „freigegeben", stammend aus dem Dokumentenmanagement. Damit entstehen explizite Eigenschaften, auf die eine Anwendung gezielt zugreifen kann. 

Klassifizierung ordnet Ressourcen definierten Kategorien zu 

Klassifizierung weist Ressourcen Kategorien eines definierten Schemas zu. Eine Organisation kann Dokumente etwa nach Dokumenttyp gliedern und dabei zwischen Vertrag, Rechnung, technischer Dokumentation, Präsentation und Richtlinie unterscheiden. Eine zweite, davon unabhängige Dimension beschreibt den Informationsstatus und reicht von öffentlich über intern und vertraulich bis streng vertraulich. 

Beide Klassifikationen beantworten unterschiedliche Fragen. Genau deshalb sollte eine Datenarchitektur nicht versuchen, sämtliche Eigenschaften eines Dokuments in einer einzigen Kategorie abzubilden. Dokumenttyp, organisatorische Zuordnung, zeitliche Gültigkeit und Vertraulichkeit sind voneinander unabhängige Dimensionen, und sie ändern sich unabhängig voneinander. 

[BILD 2: Klassifikationsdimensionen als unabhängige Achsen. Zwei bis drei orthogonale Achsen mit je vier bis fünf Kategorien (Dokumenttyp, Vertraulichkeit, Gültigkeit); ein Dokument als Punkt mit Koordinaten auf allen Achsen. Zeigt: ein Dokument trägt mehrere Klassifikationen gleichzeitig.] 

Kontrollierte Vokabulare verbessern dabei die Interoperabilität. Dublin Core empfiehlt für die Eigenschaft dcterms:type ausdrücklich ein kontrolliertes Vokabular wie das DCMI Type Vocabulary. Das Data Catalog Vocabulary des W3C formuliert für dieselbe Eigenschaft schärfer: Der Wert soll aus einem gut gepflegten und breit anerkannten Vokabular stammen, und die Spezifikation nennt neben DCMI Type auch die Scope Codes aus ISO 19115-1, die DataCite Resource Types und die Inhaltstypen von re3data als geeignete Kandidaten. 

Metadaten entstehen im Ingestion-Prozess und begleiten jeden Chunk 

In einer vereinfachten RAG-Architektur durchlaufen Unternehmensdaten zunächst einen Ingestion-Prozess: Aus dem Quellsystem werden Inhalt und Metadaten extrahiert, das Dokument wird in kleinere Einheiten zerlegt, für diese Einheiten werden Embeddingsberechnet, und beides landet in einem Such- beziehungsweise Vektorindex. 

[BILD 3: Ingestion-Pipeline als horizontale Prozesskette. Stationen: Quellsystem, Extraction, Dokument mit Metadaten, Chunking, Embedding-Berechnung, Such-/Vektorindex. Metadaten als durchlaufendes Band unterhalb der Kette, das an jeder Station anliegt.] 

Beim Chunking entsteht eine Architekturfrage, die später schwer zu korrigieren ist: welche Metadaten zum Dokument gehören und welche zum einzelnen Chunk. Wird ein achtzigseitiges Handbuch in zweihundert Chunks zerlegt, sind Eigenschaften wie Quelle, Dokument-ID oder Dokumenttyp für alle Fragmente identisch. Andere Eigenschaften beziehen sich auf einzelne Abschnitte und lassen sich nicht sinnvoll vom Dokument erben. 

Eine mögliche logische Repräsentation eines Chunks umfasst deshalb beide Ebenen: 

Ebene 

Felder 

Chunk-spezifisch 

chunk_id, text, embedding 

Vom Dokument geerbt 

document_id, source, document_type, department 

Zeitlich 

created_at, valid_until 

Governance 

classification 

Damit bleiben die aus einem Dokument erzeugten Fragmente mit ihrem Ursprung und ihrem weiteren Kontext verbunden. Grundlagen der RAG-Architektur 

Provenance macht Herkunft nachvollziehbar — auch die der Metadaten 

Für KI-Anwendungen ist häufig nicht nur relevant, was eine Information enthält, sondern woher sie stammt. Das W3C stellt dafür mit PROV-O ein standardisiertes Modell bereit. Es unterscheidet zwischen Entity, Activity und Agent und kann Beziehungen wie Erzeugung, Nutzung und Ableitung von Daten repräsentieren. Auch DCAT 3 führt PROV-O unter den komplementären Vokabularen, deren Eigenschaften den Workflow beschreiben können, aus dem ein Datensatz hervorgegangen ist. 

[BILD 5: Provenance-Kette nach PROV-O. Entities (Originaldokument, extrahierter Text, Chunk, Embedding) abwechselnd mit Activities (Extraction, Chunking, Embedding-Berechnung). Entity- und Activity-Knoten visuell unterscheiden. Kein Zeitstrahl.] 

Die Provenance-Information beschreibt damit nicht den semantischen Inhalt eines Chunks, sondern seine Entstehungs- und Verarbeitungsgeschichte. Für KI-Datenarchitekturen ist diese Trennung wichtig: Ein aus einem Dokument erzeugter Chunk sollte auf seine Quelle zurückgeführt werden können, sobald die Anwendung Nachvollziehbarkeit oder Quellenreferenzen benötigt. 

Dasselbe Prinzip gilt für die Metadaten selbst, denn auch sie können falsch, veraltet oder automatisch erzeugt sein. Eine weitergehende Architektur speichert deshalb nicht nur, dass ein Dokument dem Fachbereich finance zugeordnet ist, sondern auch, woher diese Zuordnung stammt: aus dem Quellsystem übernommen, mit Zeitstempel — oder von einem Klassifikator erzeugt, mit Angabe der Klassifikatorversion. Wenn eine Klassifizierung Auswirkungen auf Retrieval oder Governance hat, wird ihre Herkunft selbst zur nachvollziehbarkeitsrelevanten Information. NIST ordnet die Dokumentation von Metadaten und Eigenschaften verwendeter Datensätze im AI Risk Management Framework ausdrücklich den AI-Design-Aufgaben der Lifecycle-Phasen Application Context und Data and Input zu. 

Klassifizierung beschreibt, Autorisierung setzt durch 

Besonders wichtig ist die Trennung zwischen Beschreibung und Durchsetzung. Ein Metadatenfeld classification = confidentialklassifiziert eine Information. Daraus folgt technisch aber noch nicht, dass nur bestimmte Benutzer auf sie zugreifen können. 

Die DCMI definiert mit dcterms:accessRights eine eigene Eigenschaft für Informationen darüber, wer auf eine Ressource zugreifen kann beziehungsweise welchen Sicherheitsstatus sie besitzt. DCAT übernimmt diese Eigenschaft, weist aber ausdrücklich darauf hin, dass Definitionen von Begriffen außerhalb des DCAT-Namespace dort nur der Bequemlichkeit halber wiedergegeben werden und nicht normativ sind — maßgeblich bleibt die DCMI-Spezifikation. Auch dieses Feld beschreibt jedoch lediglich einen Zustand. Die eigentliche Autorisierung muss von der dafür vorgesehenen Sicherheitsarchitektur durchgesetzt werden. 

Für RAG bedeutet das, dass Klassifizierung und Autorisierung zwei getrennte Aufgaben bleiben. Metadaten können eine Zugriffskontrolle unterstützen, ersetzen aber keine Identity-, ACL- oder Policy-Mechanismen. Die technische Umsetzung der Benutzer- und Berechtigungsprüfung ist deshalb ein eigenes Architekturproblem und sollte getrennt von der fachlichen Klassifizierung betrachtet werden. Berechtigungen und Zugriffskontrolle in RAG-Systemen 

Metadaten stammen aus drei unterschiedlichen Quellen 

Metadaten entstehen auf verschiedenen Ebenen einer Datenarchitektur, und die Unterscheidung dieser Ebenen ist für die spätere Nachvollziehbarkeit entscheidend. 

Im Quellsystem bereits vorhandene Metadaten 

Dateiname, Zeitstempel, Dokument-ID, Ersteller, Dokumenttyp oder Projektzuordnung liegen in vielen Systemen bereits vor und lassen sich unverändert übernehmen. 

Während der Ingestion extrahierte Metadaten 

Bestimmte Eigenschaften lassen sich aus dem Dokument oder seiner Struktur gewinnen. Parser können vorhandene Dokumenteigenschaften oder strukturierte Felder auslesen und in das Zielschema überführen. 

In der Pipeline erzeugte Metadaten 

Eine Verarbeitungspipeline kann neue Informationen erzeugen oder bestehende normalisieren: vereinheitlichte Dokumenttypen, normalisierte Datumsangaben, die Zuordnung zu einem kontrollierten Vokabular oder Referenzen zwischen Quelldokument und Chunk. 

Zwischen aus der Quelle übernommenen und nachträglich erzeugten Metadaten muss unterschieden werden. Andernfalls bleibt später unklar, ob eine Information Bestandteil des ursprünglichen Datensatzes war oder durch eine Verarbeitungskomponente ergänzt wurde — mit entsprechenden Folgen für ihre Belastbarkeit. 

Ohne Lebenszyklus veralten die abgeleiteten Indizes 

Eine zentrale technische Herausforderung entsteht, sobald Unternehmensdaten nicht statisch sind. Ein Dokument kann geändert, verschoben, neu klassifiziert, ersetzt oder gelöscht werden. Existiert zusätzlich ein KI-Index, entstehen mehrere abgeleitete Repräsentationen desselben Inhalts: extrahierter Text, Chunks, Embeddings, Suchindex. Ändert sich die Quelle, stellt sich für jede dieser Repräsentationen die Frage, ob und wann sie nachgeführt wird. 

[BILD 6: Abgeleitete Repräsentationen und Nachführung. Quelldokument oben, darunter gestaffelt extrahierter Inhalt, Chunks, Embeddings, Suchindex. Eine Änderung am Quelldokument als Markierung, die nach unten propagiert; Stellen ohne Nachführung als offene Kante kennzeichnen.] 

Ein klassisches Beispiel ist die Gültigkeit. Eine abgelöste Version 1 und eine aktuelle Version 2 desselben Dokuments liegen unter Umständen beide weiterhin undifferenziert im Retrieval-Index. Eine semantische Suche kann dann auch die alte Version finden, ohne dass etwas offensichtlich fehlschlägt. 

Metadaten wie Version, Status oder Gültigkeitszeitraum ermöglichen es, solche Unterschiede explizit abzubilden. Die Anwendung muss diese Informationen anschließend allerdings auch tatsächlich in ihrer Retrieval-Logik auswerten. Metadaten allein lösen das Problem nicht — sie machen es lösbar. AI Data Lake 

Metadatenqualität begrenzt die Retrieval-Qualität 

Metadatenbasierte Filter können nur Eigenschaften berücksichtigen, die korrekt und konsistent vorhanden sind. Filtert eine Anwendung auf department = engineering, im Datenbestand existieren aber nebeneinander die Werte Engineering, engineering, ENG, Technology und Tech, dann beschreibt das technisch korrekte Filterkriterium nicht die fachlich gewünschte Menge. 

Das Problem liegt in diesem Fall nicht bei der Vektorsuche, sondern im Datenmodell beziehungsweise in der Qualität der Metadaten. Kontrollierte Vokabulare und definierte Schemata reduzieren solche Mehrdeutigkeiten. Genau aus diesem Grund empfehlen etablierte Metadatenmodelle für bestimmte Eigenschaften kontrollierte Vokabulare, statt freien Text zuzulassen. Die Aufbereitung der Daten ist damit keine Eigenschaft der darunterliegenden Speicherschicht, sondern eine eigene Aufgabe: AI-ready Data ist keine Storage-Eigenschaft. 

Ein Metadatenmodell entsteht aus dem Anwendungsfall, nicht aus Vollständigkeit 

Ein generisches Modell kann folgende Ebenen unterscheiden: 

Ebene 

Beispiele 

Identität 

document_id, chunk_id 

Quelle 

source_system, source_uri 

Dokument 

title, document_type, language 

Organisation 

department, project 

Zeit 

created_at, modified_at, valid_from, valid_until 

Governance 

classification, retention_category 

Provenance 

extraction_method, source_document 

Retrieval 

embedding_model, index_version 

Nicht jedes dieser Felder ist für jede Architektur erforderlich. Ein möglichst umfangreiches Schema ist keineswegs automatisch die bessere Lösung, denn zusätzliche Metadaten erzeugen zusätzlichen Aufwand für Erfassung, Normalisierung, Validierung, Synchronisation, Versionierung und Governance. Ein Feld, das nie für Retrieval, Governance, Nachvollziehbarkeit oder Betrieb verwendet wird, erzeugt Kosten ohne entsprechenden Nutzen — und kann, wenn es unbemerkt veraltet, sogar schaden. 

Das konkrete Schema sollte sich deshalb aus einer einzigen Leitfrage ableiten: Welche Eigenschaften benötigt die Anwendung, um Daten eindeutig zu identifizieren, korrekt einzugrenzen, ihren Ursprung nachzuvollziehen und ihren Lebenszyklus zu verwalten? Maßgeblich ist nicht die Zahl der erfassten Metadaten, sondern die Klarheit ihrer Semantik und Verwendung. Storage-Workloads und Datenpfad in KI-Umgebungen 

Elf Fragen vor dem Aufbau der KI-Datenpipeline 

Vor dem Aufbau einer KI-Datenpipeline sollten mehrere Fragen beantwortet sein: Welche Datenquellen sollen einbezogen werden? Welche Metadaten existieren dort bereits, und welche davon müssen in den KI-Index übernommen werden? Welche zusätzlichen Metadaten müssen während der Ingestion entstehen? Welche Felder werden für Retrieval-Filter benötigt, welche für Provenance und Quellenreferenzen? Welche Klassifikationen besitzen ein kontrolliertes Vokabular? Wie werden Änderungen am Quelldokument erkannt, wie werden Metadaten und abgeleitete Chunks aktualisiert, und wie werden gelöschte oder ungültige Informationen aus dem Retrieval entfernt? Und schließlich: Welche Informationen beschreiben Zugriffsrechte, und welches System setzt diese tatsächlich durch? 

Damit wird die Metadatenarchitektur zu einem Bestandteil der gesamten Datenpipeline und nicht zu einer nachträglichen Ergänzung des Vektorindex. KI-Infrastruktur: Architektur und Komponenten 

Fazit 

Metadaten und Klassifizierung bilden eine strukturierte Beschreibungsebene zwischen den ursprünglichen Unternehmensdaten und ihrer Verwendung durch KI-Anwendungen. Embeddings können semantische Ähnlichkeit repräsentieren, beantworten aber nicht zuverlässig strukturierte Fragen nach Quelle, Dokumenttyp, Gültigkeit oder organisatorischer Zuordnung. 

Die technische Herausforderung besteht nicht darin, möglichst viele Metadaten zu erzeugen. Entscheidend sind ein definiertes Schema, konsistente Werte, nachvollziehbare Herkunft und ein Lebenszyklus, der Änderungen der Quelldaten bis in die abgeleiteten Suchstrukturen berücksichtigt. 

Damit werden Metadaten nicht selbst zur KI. Sie schaffen eine strukturierte Datenbasis, mit der Retrieval- und KI-Systeme Informationen gezielter auswählen und deren Kontext nachvollziehbarer verarbeiten können. 

Quellen

Dublin Core Metadata Initiative: DCMI Metadata Terms. DCMI Recommendation, Ausgabedatum 20.01.2020. https://www.dublincore.org/specifications/dublin-core/dcmi-terms/ (abgerufen am 07.09.2026) 

W3C: Data Catalog Vocabulary (DCAT) — Version 3. W3C Recommendation, 22.08.2024. https://www.w3.org/TR/vocab-dcat-3/(abgerufen am 07.09.2026) 

W3C: PROV-O: The PROV Ontology. W3C Recommendation, 30.04.2013. https://www.w3.org/TR/prov-o/ (abgerufen am 07.09.2026) 

NIST: Artificial Intelligence Risk Management Framework (AI RMF 1.0). NIST AI 100-1, Januar 2023, DOI 10.6028/NIST.AI.100-1. Herangezogen: Appendix A, Beschreibung der AI-Design-Tasks. https://www.nist.gov/publications/artificial-intelligence-risk-management-framework-ai-rmf-10 (abgerufen am 07.09.2026) 

OpenSearch Project: Filtering vector search results. Technische Herstellerdokumentation, herangezogen als Implementierungsbeispiel für Filterung während beziehungsweise nach einer Vektorsuche. Die Aussage zur Filterreihenfolge im Abschnitt „Metadatenfilter und Vektorsuche beantworten verschiedene Fragen" stützt sich allein auf diese Quelle; ein herstellerunabhängiger Beleg lag zum Redaktionsschluss nicht vor. Andere Suchsysteme können abweichende Verfahren implementieren. https://docs.opensearch.org/latest/vector-search/filter-search-knn/index/ (abgerufen am 07.09.2026) 

Welche Entscheidung steht bei Ihnen an?

Sie möchten eine bestehende Infrastruktur bewerten, eine neue Architektur planen oder eine konkrete technische Fragestellung klären? Sprechen Sie mit uns über Ihre Anforderungen.

Spezialist für moderne Dateninfrastruktur

Information icon

Wir benötigen Ihre Zustimmung zum Laden der Übersetzungen

Wir nutzen einen Drittanbieter-Service, um den Inhalt der Website zu übersetzen, der möglicherweise Daten über Ihre Aktivitäten sammelt. Bitte überprüfen Sie die Details in der Datenschutzerklärung und akzeptieren Sie den Dienst, um die Übersetzungen zu sehen.