WISSEN > KI INFRASTRUKTUR > DATEN FÜR KI AUFBEREITEN
Autor: Dirk Neumann Geschäftsführer ASSISTRA Cloud Services GmbH 17.08.2026
Wie werden Unternehmensdaten für KI aufbereitet?
Von der Datenquelle über Extraktion und Berechtigungen bis zum Retrieval
Das sollten Sie mitnehmen:
- AI-ready ist kein Dateiformat und keine Storage-Eigenschaft.
Ob Daten für eine KI-Anwendung geeignet sind, entscheidet sich am Anwendungsfall, an Inhalt, Qualität, Metadaten und Berechtigungen.
- Die Aufbereitung beginnt an der Datenquelle.
Vor Embeddings und Vektordatenbanken steht die Frage, welche Daten für den vorgesehenen Zweck überhaupt geeignet und zulässig sind.
- Berechtigungen dürfen unterwegs nicht verloren gehen.
Werden geschützte Dokumente in Chunks und Embeddings überführt, muss die Autorisierung auch für die abgeleiteten Daten gelten.
- Die Datenaufbereitung ist kein einmaliger Import.
Änderungen, Löschungen und neue Berechtigungen an der Quelle müssen in die abgeleiteten Datenbestände zurückwirken.
Wie werden Unternehmensdaten für KI aufbereitet?
Inhaltsverzeichnis
- Der Anwendungsfall bestimmt, was Aufbereitung bedeutet
- Die Auswahl der Quellen entscheidet vor jeder Technik
- Extraktion und Normalisierung verändern die Daten
- Metadaten begrenzen den Suchraum, den Semantik allein nicht begrenzt
- Berechtigungen müssen die gesamte Verarbeitungskette überstehen
- Embeddings erzeugen Repräsentationen, kein Retrieval
- Ohne Rückweg von der Quelle veraltet der Index
- Datenqualität lässt sich nur gegen den Anwendungsfall bestimmen
- RAG, Machine Learning und Training brauchen verschiedene Pipelines
- Die Ingestion ist Teil der Sicherheitsarchitektur
- Storage, Aufbereitung und Modell sind unterschiedliche Ebenen
- Fazit
- Quellen
Unternehmensdaten liegen selten in einer Form vor, in der eine KI-Anwendung sie unmittelbar nutzen kann. Dateien befinden sich auf Fileservern und Cloud-Speichern, Informationen stecken in PDFs und Office-Dokumenten, strukturierte Daten liegen in Datenbanken oder Fachanwendungen. Hinzu kommen Metadaten, Versionen, Zugriffsrechte und unterschiedliche Anforderungen an Aktualität und Datenqualität.
Die Aufbereitung für KI besteht deshalb nicht darin, Daten auf einen anderen Storage zu kopieren. Zwischen Datenquelle und KI-Anwendung entsteht eine Verarbeitungskette, in der Daten ausgewählt, extrahiert, geprüft, strukturiert und für den jeweiligen Anwendungsfall technisch verfügbar gemacht werden. Welche Schritte dabei erforderlich sind, hängt wesentlich vom Ziel ab: Retrieval-Augmented Generation, klassisches Machine Learning und das Training oder Fine-Tuning eines Modells benötigen unterschiedliche Formen aufbereiteter Daten.
Der Anwendungsfall bestimmt, was Aufbereitung bedeutet
Es gibt keine universelle technische Form, in die Unternehmensdaten für „die KI“ umgewandelt werden könnten. Schon die Bezeichnung umfasst unterschiedliche Verfahren mit unterschiedlichen Anforderungen an die Daten.
Bei einem RAG-System sollen Informationen aus Unternehmensdokumenten zur Laufzeit gefunden und einem Large Language Model als Kontext bereitgestellt werden. Lewis et al. beschreiben dieses Verfahren als Kombination aus dem parametrischen Wissen eines vortrainierten Modells und nicht-parametrischem Wissen aus einem durchsuchbaren Index. [1] Bei überwachtem Machine Learning werden dagegen Daten und zugehörige Zielwerte oder Labels benötigt. Beim Training oder Fine-Tuning eines Sprachmodells werden die Daten Teil des Lernprozesses und beeinflussen Modellparameter. [QUERVERWEIS: Was sind Large Language Models?] [QUERVERWEIS: Wie funktioniert Retrieval-Augmented Generation?]
Für dokumentenbasierte Anwendungen lässt sich daraus eine typische Verarbeitungskette ableiten, die von den Datenquellen über Auswahl, Extraktion, Normalisierung, Metadaten und Berechtigungen bis zu Segmentierung und Indexierung reicht. Diese Abfolge ist kein Standardprozess. Einzelne Schritte können je nach Architektur entfallen, anders angeordnet oder um weitere Verarbeitungsschritte ergänzt werden.
[BILD 1: Verarbeitungskette von der Datenquelle zur KI-Anwendung. Horizontale Prozessdarstellung mit den Stationen Datenquellen, Auswahl, Extraktion, Bereinigung und Normalisierung, Metadaten und Klassifizierung, Berechtigungen, Segmentierung, Repräsentation und Indexierung, KI-Anwendung. Die Stationen Berechtigungen und Metadaten farblich abgesetzt, da sie in der Praxis am häufigsten fehlen. Hinweis in der Bildunterschrift, dass die Kette exemplarisch und nicht normativ ist.]
Das NIST AI Risk Management Framework sieht entsprechend vor, Kontext und vorgesehenen Einsatz eines AI-Systems sowie Eignung, Verfügbarkeit und Repräsentativität der verwendeten Daten zu berücksichtigen. Der zu lösende Anwendungsfall steht damit vor der technischen Verarbeitung. [2]
Die Auswahl der Quellen entscheidet vor jeder Technik
Der erste Schritt besteht nicht im Erzeugen von Embeddings, sondern in der Frage, welche Informationen die KI-Anwendung überhaupt benötigt. In Unternehmen liegen relevante Inhalte verteilt in File Services und NAS-Systemen, in Object Storage, in Dokumentenmanagementsystemen, in relationalen und nicht-relationalen Datenbanken, auf Collaboration-Plattformen, in Fachanwendungen, in Data Lakes und Data Warehouses sowie hinter APIs und anderen Datenservices. [QUERVERWEIS: Was ist ein KI-Data-Lake?]
Dabei ist zwischen physischem Speicherort und logischer Informationsquelle zu unterscheiden. Ein PDF kann als Objekt in einem Object Store liegen. Für eine RAG-Anwendung ist jedoch nicht das gespeicherte Objekt entscheidend, sondern der daraus extrahierbare Inhalt sowie der Kontext, in dem dieser Inhalt verwendet werden darf. Damit wird bereits deutlich, warum die Wahl eines bestimmten Storage-Systems Daten nicht automatisch „AI-ready“ macht. [QUERVERWEIS: Object Storage als Datenplattform]
Nicht jeder vorhandene Datenbestand ist für einen bestimmten Anwendungsfall relevant. Das NIST AI RMF nennt bei der Bewertung von Daten unter anderem Verfügbarkeit, Repräsentativität und Eignung. Das begleitende Playbook regt darüber hinaus an, bekannte Fehler, Rauschen und Redundanzen sowie Entstehungszweck und zeitlichen Kontext von Daten zu dokumentieren und zu prüfen, ob die Daten für den vorgesehenen Zweck angemessen sind. [2][3]
Für Unternehmensdaten bedeutet das, dass vor der technischen Verarbeitung zu bestimmen ist, welche Quellen für den konkreten Use Case relevant und zulässig sind. Bei einem internen RAG-System für technische Dokumentation können freigegebene technische Dokumente den Kern bilden, während andere Bestände für diesen Anwendungsfall keinen Informationswert besitzen oder aus organisatorischen beziehungsweise rechtlichen Gründen nicht verarbeitet werden dürfen. Mehr Daten sind deshalb nicht automatisch bessere Daten.
Extraktion und Normalisierung verändern die Daten
Viele Unternehmensinformationen liegen nicht als unmittelbar weiterverarbeitbarer Text vor. Ein Dokument besteht technisch zunächst aus einem Dateiformat; die für eine KI-Anwendung relevante Information kann darin als Fließtext, Tabelle, strukturiertes Feld oder in anderer Form stecken. Eine Ingestion-Pipeline muss deshalb zwischen der Quelldatei, dem Parser oder Extractor, dem extrahierten Inhalt und der daraus erzeugten strukturierten Repräsentation unterscheiden.
Bei strukturierten Daten stellt sich die Lage anders dar. Informationen aus einer Datenbank sind über Tabellen, Felder und Datentypen bereits beschrieben und lassen sich über Queries oder APIs abrufen. [QUERVERWEIS: APIs und MCP in KI-Architekturen]
Entscheidend ist, dass bei der Extraktion keine semantisch relevante Struktur unkontrolliert verloren geht. Eine Tabelle ist nicht lediglich eine Folge unabhängiger Textzeilen; Überschriften, Spaltenbeziehungen und Dokumentstruktur können für die spätere Interpretation den Ausschlag geben.
Nach der Extraktion folgt in der Regel eine Normalisierung. Sie kann technische Repräsentationen vereinheitlichen, nicht benötigte Formatierungsinformationen entfernen, fehlerhafte oder unvollständige Inhalte behandeln, Duplikate erkennen, Metadaten angleichen und Inhalte einer Quelle und Dokumentversion zuordnen. Welche dieser Schritte notwendig sind, hängt von Quelle und Anwendungsfall ab.
Dabei ist Vorsicht geboten, denn jede Bereinigung verändert Daten. Eine vermeintlich überflüssige Information kann für einen anderen Anwendungsfall relevant sein. Nachvollziehbar bleiben sollte deshalb, welche Transformationen zwischen Originaldaten und der von der KI verwendeten Repräsentation stattgefunden haben. Für diese Nachvollziehbarkeit ist das Konzept der Data Provenance einschlägig. Das W3C PROV Data Model beschreibt Provenanceüber Entitäten, Aktivitäten und verantwortliche Akteure und stellt damit ein allgemeines Modell zur Beschreibung der Entstehung und Ableitung von Daten bereit. [4]
Wir leiten daraus für KI-Datenpipelines ein Architekturprinzip ab: Quelldaten und die daraus erzeugten Repräsentationen sollten logisch miteinander verknüpfbar bleiben.
Metadaten begrenzen den Suchraum, den Semantik allein nicht begrenzt
Der Inhalt eines Dokuments ist nur ein Teil der Information. Hinzu kommen Angaben zu Quelle, Dokumenttyp, Erstellungs- und Änderungszeitpunkt, Version, Fachbereich, Sprache, Klassifizierung, Eigentümer, Gültigkeitsstatus und Zugriffsbedingungen. Diese Metadaten lassen sich für Auswahl, Filterung, Governance und Retrieval verwenden. [QUERVERWEIS: Metadaten und Klassifizierung in KI-Umgebungen]
Bei RAG ist das besonders relevant. Eine semantische Suche kann Inhalte anhand ihrer Repräsentation vergleichen. Daraus folgt jedoch nicht, dass jeder semantisch ähnliche Inhalt für jede Anfrage relevant oder zulässig ist. Metadaten ermöglichen zusätzliche Einschränkungen des Suchraums, sodass eine Anfrage konzeptionell aus zwei Bedingungen besteht: aus semantischer Relevanz und aus strukturierten Filterbedingungen. Welche Metadaten dafür erforderlich sind, lässt sich nur aus dem jeweiligen Anwendungsfall ableiten.
Berechtigungen müssen die gesamte Verarbeitungskette überstehen
Bei Unternehmensdaten ist die technische Auffindbarkeit einer Information nicht gleichbedeutend mit der Berechtigung, sie zu lesen.
Angenommen, ein Benutzer besitzt Zugriff auf Dokument A, aber nicht auf Dokument B. Werden beide Dokumente in kleinere Segmente zerlegt und gemeinsam indexiert, darf diese Transformation nicht dazu führen, dass Inhalte aus Dokument B anschließend über die KI-Anwendung zugänglich werden. Die Berechtigung muss deshalb entlang der gesamten Kette betrachtet werden, vom Quelldokument über Chunk und Indexeintrag bis zum Retrieval und zum Kontext des Sprachmodells.
[BILD 2: Berechtigungen entlang der Verarbeitungskette. Fünf Stationen von links nach rechts: Quelldokument, Chunk, Indexeintrag und Embedding, Retrieval, Kontext des LLM. Über jeder Station ein Schloss-Symbol, das anzeigt, an welcher Stelle Autorisierung geprüft werden muss. Die letzte Station rot markiert mit der Aussage, dass eine Prüfung an dieser Stelle zu spät kommt.]
OWASP empfiehlt für RAG-Systeme, Access-Control-Metadaten zusammen mit den einzelnen Chunks zu erhalten und die Autorisierung beim Retrieval durchzusetzen. Berechtigungsänderungen an der Quelle sind dabei ebenfalls zu berücksichtigen. [5] Das Sprachmodell selbst ist nicht die geeignete Instanz für diese Autorisierung: Hat nicht autorisierter Inhalt bereits den Modellkontext erreicht, wurde die Zugriffskontrolle zu spät angewendet. [QUERVERWEIS: Berechtigungen in RAG-Systemen]
Chunking ist ein Architekturparameter, keine Konstante
Ein vollständiges Dokument wird bei RAG nicht zwangsläufig als eine einzige Retrieval-Einheit verwendet. Dokumente lassen sich in kleinere Einheiten zerlegen, die üblicherweise als Chunks bezeichnet werden. Der Grund liegt im Retrieval selbst: Gesucht werden die für eine Anfrage relevanten Informationen, nicht notwendigerweise vollständige Dokumente.
Chunking ist dabei keine rein mechanische Operation. Sehr große Chunks können unterschiedliche Themen enthalten und dadurch die Granularität des Retrievals verringern. Sehr kleine Chunks trennen dagegen leicht wichtigen Kontext von der gefundenen Passage. Eine allgemein optimale Chunk-Größe lässt sich daraus nicht ableiten; sie hängt von Dokumentstruktur, Inhalt, Retrieval-Verfahren und verwendetem Modell ab.
Wir behandeln Chunking deshalb als Architektur- und Evaluierungsparameter, der gegen den konkreten Anwendungsfall gemessen wird, und nicht als Voreinstellung, die einmal gesetzt und danach nicht mehr hinterfragt wird.
Embeddings erzeugen Repräsentationen, kein Retrieval
Für die semantische Suche überführt ein Embedding-Modell Textabschnitte in numerische Vektorrepräsentationen. Die Ähnlichkeit zwischen diesen Vektoren lässt sich anschließend als Bestandteil eines Retrieval-Verfahrens verwenden. Damit entsteht eine weitere abgeleitete Datenebene, die vom Originaldokument über den extrahierten Inhalt und den Chunk bis zum Embedding reicht. [QUERVERWEIS: Embeddings und Vektordatenbanken erklärt]
[BILD 3: Abgeleitete Datenebenen. Vertikale Darstellung mit vier Ebenen: Originaldokument, extrahierter Inhalt, Chunk, Embedding. Rückwärtsgerichtete Verbindungspfeile zeigen, dass jede Ebene auf ihre Quelle zurückführbar bleiben muss. Seitliche Beschriftung: Source Data gegenüber Derived AI Data.]
Das Embedding ersetzt den Originalinhalt nicht. Für die Bereitstellung von Kontext muss das System typischerweise wieder eine Beziehung zwischen gefundenem Indexeintrag und zugehörigem Inhalt herstellen können.
Sicherheitstechnisch sind Embeddings nicht als unkritisch zu betrachten. OWASP führt Vector and Embedding Weaknesses als eigenes Risiko der Top 10 für LLM-Anwendungen (LLM09:2026) und nennt dabei unzureichende Zugriffskontrolle, Datenlecks durch Embedding-Inversion und manipulierte Inhalte. [5][6]
Nach der Verarbeitung müssen Informationen so organisiert werden, dass die KI-Anwendung relevante Inhalte findet. Eine Vektordatenbank ist dabei nur eine mögliche Komponente. Je nach Architektur lassen sich klassische Volltextsuche, strukturierte Metadatenfilter, Vektorsuche, hybride Retrieval-Verfahren und nachgelagertes Reranking kombinieren.
Daraus ergibt sich eine begriffliche Trennung, die in der Praxis häufig verwischt: Ein Embedding erzeugt eine Repräsentation, während Retrieval den Prozess bezeichnet, aus einem Datenbestand relevante Informationen für eine Anfrage auszuwählen. Ebenso ist eine Vektordatenbank noch keine vollständige RAG-Architektur. Zwischen Datenquelle, Index und Sprachmodell liegen weitere Funktionen wie Ingestion, Berechtigungsprüfung, Query Processing, Retrieval, gegebenenfalls Reranking und Context Assembly.
Ohne Rückweg von der Quelle veraltet der Index
Eine verkürzte Darstellung der KI-Datenpipeline endet beim initialen Aufbau des Index. Unternehmensdaten verändern sich jedoch fortlaufend: Dokumente werden neu erstellt, geändert, verschoben, neu klassifiziert, mit anderen Berechtigungen versehen, archiviert oder gelöscht.
Damit entsteht ein Synchronisationsproblem zwischen der Source of Truth und den daraus abgeleiteten Repräsentationen. Wird ein Dokument gelöscht, während seine Chunks und Embeddings im Retrieval-System verbleiben, entspricht der KI-Datenbestand nicht mehr seiner Quelle. OWASP empfiehlt deshalb, Löschungen und Änderungen von Berechtigungen auch auf abgeleitete Daten wie Chunks und Embeddings zu übertragen. [5]
[BILD 4: Rückweg von der Quelle in den Index. Kreislaufdarstellung mit dem Hinweg Quelle zu KI-Index und dem Rückweg über die vier Ereignisse Create, Update, Permission Change und Delete, die jeweils ein Reprocessing und ein Index-Update auslösen. Der Rückweg optisch hervorgehoben, da er in vielen Architekturen fehlt.]
Eine produktive Datenpipeline benötigt daher nicht nur einen Weg von der Quelle in den Index, sondern auch Mechanismen für Anlage, Änderung, Berechtigungswechsel und Löschung. Wie schnell diese Mechanismen greifen müssen, hängt vom Anwendungsfall ab. Ein Wissensbestand, der monatlich aktualisiert wird, stellt andere Anforderungen als Informationen, deren Änderungen kurzfristig in der KI-Anwendung sichtbar sein müssen.
Datenqualität lässt sich nur gegen den Anwendungsfall bestimmen
„Saubere Daten“ ist als technische Anforderung zu unpräzise. Datenqualität muss im Kontext des vorgesehenen Systems bewertet werden. NIST weist ausdrücklich auf die Abhängigkeit von Datenqualität und Repräsentativität hin und empfiehlt, Datenbestände im Hinblick auf den tatsächlichen Anwendungskontext zu evaluieren. [2][3]
Dimension
Prüffrage
Korrektheit
Enthalten die Daten bekannte Fehler?
Vollständigkeit
Fehlen für die Aufgabe notwendige Informationen?
Aktualität
Entspricht der Datenbestand dem benötigten Informationsstand?
Konsistenz
Widersprechen sich unterschiedliche Quellen oder Versionen?
Relevanz
Werden die enthaltenen Informationen für den konkreten Use Case benötigt?
Provenance
Ist nachvollziehbar, woher Informationen stammen und wie sie verarbeitet wurden?
Ein technisch erreichbarer Datenbestand ist damit noch kein geeigneter KI-Datenbestand.
RAG, Machine Learning und Training brauchen verschiedene Pipelines
Bei RAG bleiben Unternehmensinformationen außerhalb der Modellparameter. Sie werden zur Laufzeit gesucht und dem Modell als zusätzlicher Kontext bereitgestellt. Die Pipeline führt von den Dokumenten über Extraktion, Chunking, Metadaten und Berechtigungen zu Embeddings und Index, von dort über Retrieval und Context Assembly zum Sprachmodell.
Bei klassischen ML-Anwendungen sind dagegen strukturierte Merkmale, Zielvariablen, Labels sowie getrennte Trainings-, Validierungs- und Testdaten erforderlich. Die Datenaufbereitung richtet sich hier nach dem jeweiligen Modell und der zu lösenden Aufgabe.
Werden Daten zum Training oder Fine-Tuning verwendet, wirken sie auf den Lernprozess des Modells ein. Das ist architektonisch etwas anderes als RAG: Retrieval stellt Informationen zur Inferenzzeit bereit, während Training und Fine-Tuning Modellparameter verändern. Daraus folgen unterschiedliche Anforderungen an Auswahl, Qualität, Governance und Lebenszyklus der verwendeten Daten.
Die Ingestion ist Teil der Sicherheitsarchitektur
Ein KI-System, das automatisch Daten aus unterschiedlichen Quellen übernimmt, erweitert seine Angriffsfläche. Manipulierte Daten können bereits während der Ingestion in einen später verwendeten Datenbestand gelangen.
NIST behandelt Data Poisoning als eigene Klasse adversarialer Angriffe auf ML- und generative AI-Systeme. Die Datenabhängigkeit dieser Systeme wird damit selbst zum möglichen Angriffsvektor. [7] Für RAG-Systeme kommt hinzu, dass externe oder veränderbare Dokumente später als Kontext eines Sprachmodells dienen. OWASP behandelt deshalb sowohl die Integrität der Wissensbasis als auch Prompt Injection über abgerufene Inhalte (LLM01:2026) als Sicherheitsprobleme. [5][6] [QUERVERWEIS: Ransomware-Schutz und Cyber-Resilienz]
Eine Datenpipeline sollte daher nicht nur beantworten, ob ein Dokument verarbeitet werden kann, sondern auch, woher es stammt, ob es verarbeitet werden darf und ob seinem Inhalt im vorgesehenen Kontext vertraut werden kann.
Storage, Aufbereitung und Modell sind unterschiedliche Ebenen
Für dokumentenbasierte Enterprise-RAG-Anwendungen lässt sich aus den vorangegangenen Abschnitten eine logische Referenzarchitektur ableiten, die von den Unternehmensdatenquellen bis zum Sprachmodell reicht und um einen Rückweg für Änderungen ergänzt wird.
[BILD 5: Referenzarchitektur für dokumentenbasierte Enterprise-RAG-Anwendungen. Vertikale Schichtdarstellung mit den Stationen Enterprise Data Sources, Discovery und Selection, Extraction und Parsing, Normalization und Validation, Metadata Classification und Provenance, Permission Mapping, Chunking, Embedding und Indexing, Search Vector und Hybrid Index, Identity und Authorization, Retrieval, Reranking und Context Assembly, LLM. Seitlich ein Rückkanal von Source Update, Delete und Permission Change über Reprocessing zum Index Update. Die drei Ebenen Storage, Processing und Modell durch Hintergrundflächen voneinander abgesetzt.]
Die Darstellung zeigt zugleich, weshalb Storage, Datenaufbereitung und KI-Modell unterschiedliche Ebenen einer KI-Infrastruktur bilden. Der Storage hält Daten. Die Processing- und Ingestion-Schicht erzeugt daraus für einen bestimmten Anwendungsfall geeignete Repräsentationen. Retrieval-Komponenten wählen Informationen aus. Erst danach verarbeitet das Sprachmodell den bereitgestellten Kontext.
Die Storage-Infrastruktur bleibt dabei relevant. Sie bestimmt, über welche Protokolle und APIs Quelldaten erreichbar sind, wie große Datenbestände verwaltet werden und welche Funktionen für Verfügbarkeit, Schutz und Datenmanagement zur Verfügung stehen. [QUERVERWEIS: Storage für KI-Workloads]
Die semantischen Probleme der Datenaufbereitung löst sie jedoch nicht. Ein Object Store weiß allein aufgrund der Speicherung eines PDFs nicht, welcher Absatz fachlich relevant ist, ob das Dokument noch gültig ist, welche Inhalte gemeinsam einen sinnvollen Chunk bilden oder welche Informationen für eine bestimmte Anfrage benötigt werden.
Umgekehrt sollte eine KI-Pipeline die vorhandene Dateninfrastruktur nicht unnötig duplizieren. Wo immer möglich, sollte definiert sein, welches System die Source of Truth darstellt und welche Daten lediglich daraus erzeugte Repräsentationen sind. Chunks, Embeddings und Retrieval-Indizes sind abgeleitete Daten, deren Lebenszyklus mit dem ihrer Quellen verbunden bleiben muss. [QUERVERWEIS: KI-Infrastruktur: Architektur und Komponenten]
Fazit
Object Storage On-Premises und Cloud Object Storage basieren auf demselben Speichermodell, führen aber zu unterschiedlichen Infrastruktur- und Betriebsarchitekturen. Cloud Object Storage verschiebt Bereitstellung und Betrieb der physischen Storage-Infrastruktur zum Provider und ermöglicht eine bedarfsgerechte Nutzung von Kapazität. Dafür werden Netzwerkverbindung und Provider-Modell Bestandteile der Gesamtarchitektur. On-Premises ObjectStorage hält Infrastruktur und Datenpfade unter eigener Kontrolle, verlangt dafür aber Kapazitätsplanung, Reserve, Betrieb und Lifecycle-Management.
Unsere Projekterfahrung zeigt zudem, dass Entscheidungen nicht ausschließlich aus technischen Performance-Kriterien entstehen. In einem Projekt war die Vorgabe, keine Cloud einzusetzen, ausschlaggebend für eine On-Premises-Architektur. Eine separate Kalkulation für rund 1 PB aus dem Frühjahr 2025 zeigte wiederum, wie stark der gewählte Betrachtungszeitraum das wirtschaftliche Ergebnis beeinflusst. Gleichzeitig gewinnen in aktuellen Kundengesprächen Anforderungen an europäische Lösungen und digitale Souveränität an Bedeutung.
Die entscheidende Frage lautet damit nicht, ob Cloud oder On-Premises besser ist, sondern welche Betriebsform Datenpfad, Kapazität, Betrieb, Souveränität und Wirtschaftlichkeit des konkreten Workloads am besten erfüllt. Unternehmensdaten für KI aufzubereiten bedeutet mehr, als Daten in einen Data Lake, einen Object Store oder eine Vektordatenbank zu verschieben. Die technische Aufgabe besteht darin, aus vorhandenen Quellen einen kontrollierbaren Datenpfad aufzubauen, der Auswahl, Extraktion, Qualitätsprüfung, Kontext, Berechtigung und Repräsentation umfasst und in Retrieval oder Training mündet.
Welche Verarbeitungsschritte notwendig sind, hängt vom Anwendungsfall ab. RAG benötigt andere Datenstrukturen als klassisches Machine Learning oder Modelltraining. Für Unternehmensarchitekturen ist zusätzlich der Lebenszyklus entscheidend: Quelle, Metadaten, Berechtigungen, Chunks, Embeddingsund Indizes sind keine voneinander unabhängigen Datenbestände, und Änderungen an der Quelle wirken auf alles zurück, was daraus abgeleitet wurde.
Damit wird die eigentliche Herausforderung sichtbar. AI-ready Data entsteht nicht durch einen bestimmten Storage-Typ, sondern durch eine kontrollierte Datenpipeline, die Daten für einen konkreten Anwendungsfall auffindbar, interpretierbar, aktuell und gemäß den geltenden Berechtigungen nutzbar macht.
Quellen
[1] Lewis, P.; Perez, E.; Piktus, A.; Petroni, F.; Karpukhin, V.; Goyal, N.; Küttler, H.; Lewis, M.; Yih, W.-t.; Rocktäschel, T.; Riedel, S.; Kiela, D.:Retrieval-Augmented Generation for Knowledge-Intensive NLP Tasks. In: Advances in Neural Information Processing Systems 33 (NeurIPS 2020), S. 9459–9474. DOI: 10.48550/arXiv.2005.11401. Abruf: 7. September 2026. https://doi.org/10.48550/arXiv.2005.11401
[2] Tabassi, E. / National Institute of Standards and Technology (NIST): Artificial Intelligence Risk Management Framework (AI RMF 1.0). NIST AI 100-1, Januar 2023. DOI: 10.6028/NIST.AI.100-1. Belegstellen: MAP 1.1, MAP 2.3. Hinweis: Das Rahmenwerk wird auf Grundlage des White House AI Action Plan vom 23. Juli 2025 überarbeitet; eine revidierte Fassung lag zum Abrufdatum nicht vor. Abruf: 7. September 2026. https://doi.org/10.6028/NIST.AI.100-1
[3] National Institute of Standards and Technology (NIST): AI RMF Playbook. Begleitressource zum AI RMF 1.0, laufend gepflegt; Aktualisierung nach Abschluss der AI-RMF-Revision angekündigt. Belegstelle: MAP 2.3, Abschnitt „Transparency and Documentation“. Abruf: 7. September 2026. https://airc.nist.gov/airmf-resources/playbook/
[4] Moreau, L.; Missier, P. (Hrsg.) / World Wide Web Consortium (W3C): PROV-DM: The PROV Data Model. W3C Recommendation, 30. April 2013. Abruf: 7. September 2026. https://www.w3.org/TR/prov-dm/
[5] OWASP Foundation: Retrieval-Augmented Generation (RAG) Security Cheat Sheet. OWASP Cheat Sheet Series, laufend gepflegtes Dokument ohne Versionsnummer. Belegstellen: Section 1 (Document Poisoning), Section 3 (Context Window Attacks), Section 4 (Access Control Inheritance, Data Deletion and Retention), Section 7 (Index Integrity). Lizenz: CC BY-SA 4.0. Abruf: 7. September 2026. https://cheatsheetseries.owasp.org/cheatsheets/RAG_Security_Cheat_Sheet.html
[6] OWASP GenAI Security Project: OWASP Top 10 for Large Language Model Applications. Edition 2026, veröffentlicht am 4. August 2026. Belegstellen: LLM01:2026 Prompt Injection, LLM09:2026 Vector and Embedding Weaknesses. DOI (Edition 2026): 10.5281/zenodo.22109015. Lizenz: CC BY-SA 4.0. Abruf: 7. September 2026. https://genai.owasp.org/resource/owasp-genai-llm-top-10-2026/
[7] Vassilev, A.; Oprea, A.; Fordyce, A.; Anderson, H.; Davies, X.; Hamin, M. / NIST: Adversarial Machine Learning: A Taxonomy and Terminology of Attacks and Mitigations. NIST AI 100-2 E2025, 24. März 2025. DOI: 10.6028/NIST.AI.100-2e2025. Hinweis: korrigierte PDF-Fassung vom 1. April 2025; Errata-Dokument vom 3. Juni 2025. Abruf: 7. September 2026. https://doi.org/10.6028/NIST.AI.100-2e2025
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
