Einer der häufigsten Sätze, den wir im Einstiegs-Workshop mit Kunden hören: „Wir haben Tausende von Dokumenten, Datenbanken, eine Historie von Serviceprotokollen, E-Mails von Kunden — Daten haben wir auf jeden Fall." Technisch ist das richtig. Doch sobald wir fragen, wie ein repräsentativer Datensatz aussieht und woher er genau stammt, kommen die Dinge ans Licht: Dateien in drei verschiedenen SharePoint-Versionen gespeichert, Datensätze mit widersprüchlichen Werten, als Bilder eingescannte Dokumente ohne OCR, Excel-Tabellen mit Spaltennamen, die nur derjenige versteht, der sie 2018 angelegt hat.
Datenvorbereitung ist laut mehreren Studien der entscheidende Unterschied zwischen KI-Projekten, die messbaren Mehrwert geliefert haben, und solchen, die als aufgegebene Piloten geendet sind. Dieser Artikel handelt nicht davon, welche Modelle man einsetzen soll. Er handelt davon, was getan werden muss, bevor man überhaupt zu den Modellen gelangt.
Warum „wir haben Daten" ≠ „die Daten sind bereit"
KI-Datenbereitschaft hat eine andere Definition als „Daten sind irgendwo gespeichert". Ein Modell — egal ob RAG-Pipeline oder Fine-tuning — benötigt Daten in einem bestimmten Zustand:
- Maschinenlesbar: Text aus PDFs, Bildern und Tabellen in strukturierter Form extrahiert
- Konsistent: gleiche Entitäten einheitlich benannt (Kunde „ACME GmbH" vs. „Acme DE" vs. „ACME Germany" sind für das Modell drei verschiedene Entitäten)
- Relevant und bereinigt: ohne Duplikate, ohne veraltete Versionen, ohne internen „Lärm" (Testdatensätze, Sandbox-Daten, Entwurfsdokumente)
- Korrekt annotiert oder strukturiert: das Modell muss wissen, was die Daten repräsentieren, und nicht nur Rohtext sehen
- Zugänglich und verwaltbar: klare Eigentümerschaft, Versionierung, Gültigkeitsdatum, Zugriffsrechte
Der Cisco AI Readiness Index berichtet, dass nur ca. 34 % der Unternehmen ihre Datenbereitschaft für KI-Deployment als ausreichend einschätzen. Aus unserer praktischen Erfahrung klingt diese Zahl noch optimistisch — die meisten Projekte verbringen das erste Drittel des gesamten Engagements genau mit der Datenvorbereitung, nicht mit den Modellen.
Phase 1: Inventar — was haben wir überhaupt
Vor jeder technischen Entscheidung muss eine Bestandsaufnahme der vorhandenen Datenquellen erfolgen. In der Praxis bedeutet das, folgende Fragen zu beantworten:
Wo liegen die Daten physisch?
- Datenbanken (PostgreSQL, MySQL, MSSQL, Oracle)
- Netzwerklaufwerke und Dokumentensysteme (SharePoint, Google Drive, NAS)
- ERP / MES / SCADA-Systeme (SAP, Infor, Siemens WinCC, Ignition)
- E-Mails und Kommunikationswerkzeuge
- Als Bilder eingescannte Papierdokumentation
- Maschinen-Logs und Sensordaten (MQTT, OPC-UA, industrielle Datenbanken wie InfluxDB)
Jede Quelle hat ein anderes Format, eine andere Aktualisierungsfrequenz, einen anderen Strukturierungsgrad und andere Zugriffsrechte. Die Liste aller Quellen ist das erste Artefakt eines Datenpipeline-Projekts.
Wie ist die Qualität?
Für jede Quelle abschätzen:
- Prozentuale Vollständigkeit der Pflichtfelder (wie viele Datensätze haben alle Pflichtfelder ausgefüllt?)
- Formatkonsistenz (sind Datumsangaben immer im gleichen Format? Stammen Kategorien aus einem festen Schlüsselverzeichnis oder sind es Freitexte?)
- Duplikation (gibt es Datensätze, die dieselbe Entität mehrfach repräsentieren?)
- Aktualität (wann wurde ein Datensatz zuletzt geprüft? Gibt es veraltete Versionen?)
Dieses Audit muss nicht perfekt sein — das Ziel ist, kritische Probleme zu identifizieren, die das Projekt blockieren würden, nicht hundertprozentige Sauberkeit vor dem Start zu erreichen.
Wer ist Eigentümer der Daten?
Für jede Quelle: Wer ist für den Inhalt verantwortlich? Wer ist berechtigt, den Zugriff zu ändern? Wer kann sagen, was ein Datensatz bedeutet? Ohne klare Dateneigentümerschaft kann ein KI-Projekt in abteilungsübergreifenden Streitigkeiten darüber steckenbleiben, wer genehmigt, dass seine Datenbank für Training oder Retrieval genutzt wird.
Phase 2: Extraktion und Normalisierung
Sobald die Quellen bekannt sind, folgt die technische Arbeit: Daten in eine einheitliche Form bringen, mit der die Pipeline arbeiten kann.
Extraktion aus strukturierten Quellen
Aus relationalen Datenbanken und ERP-Systemen ist die Extraktion vergleichsweise geradlinig — SQL-Abfragen, API-Aufrufe, CSV-Export. Entscheidend ist, Folgendes zu definieren:
- 1.Welche Tabellen / Felder für den jeweiligen Use-Case relevant sind (nicht das gesamte ERP exportieren)
- 2.Wie hoch die Aktualisierungsfrequenz ist (einmal täglich als Batch oder Streaming von Änderungen über CDC — Change Data Capture)
- 3.Wie technische Feldnamen auf menschenlesbare Bezeichnungen gemappt werden (Spalte
ord_stat_cd→ „Bestellstatus")
Extraktion aus unstrukturierten Quellen
Dokumente, E-Mails, technische Zeichnungen und eingescannte Formulare sind anspruchsvoller. Notwendige Schritte:
- OCR für eingescannte Dokumente: Werkzeuge wie Tesseract, Azure AI Document Intelligence oder Google Document AI können Text aus Bildern und PDFs extrahieren. Die OCR-Ausgabequalität beeinflusst direkt die Qualität der Modellantworten.
- Chunking: Lange Dokumente müssen vor der Vektorisierung in kleinere Segmente aufgeteilt werden. Naives Chunking nach 512 Token mit Schnitt mitten im Satz ist eine häufige Fehlerquelle in RAG-Pipeline-Qualität. Besser ist das Chunking nach logischen Einheiten (Absätze, Abschnitte, Tabellen).
- Metadaten-Extraktion: Jeder Chunk muss Metadaten tragen — woher er stammt, Entstehungsdatum, Aktualität, Autor, gegebenenfalls Kategorie. Diese Metadaten dienen der Filterung beim Retrieval und der Quellenangabe in der Antwort.
Entitätsnormalisierung
Dasselbe Unternehmen in drei verschiedenen Schreibweisen ist für ein Vektormodell drei verschiedene Entitäten mit ähnlichem Embedding — für Fuzzy-Suche oder Filter jedoch ein Problem. Entity Resolution — die Vereinheitlichung verschiedener Schreibweisen derselben Entität — wird manchmal manuell vorgenommen (Kundenstamm), manchmal halbautomatisch (Fuzzy-Matching auf Firmennamen) und manchmal mithilfe von LLM (wenn die Datensätze in natürlicher Sprache vorliegen).
Phase 3: Bereinigung und Qualitätsvalidierung
Datenbereinigung ist ein iterativer Prozess. Es ist nicht möglich, sie einmal perfekt durchzuführen — es entstehen neue Daten, Formate ändern sich, neue Fehlermuster tauchen auf.
Konkrete Schritte, die wir in der Praxis sehen
- Duplikatentfernung: Identifikation von Datensätzen, die dieselbe Information mit unterschiedlichen Kennzeichnungen repräsentieren
- Behebung von Formatfehlern: Datumsangaben in verschiedenen Formaten, numerische Werte mit im Feld eingetragener Einheit, Telefonnummern mit unterschiedlichen Vorwahlformaten
- Umgang mit fehlenden Werten: Ergänzung wo möglich, explizite Kennzeichnung wo fehlend, Ausschluss wo ein Datensatz ohne Pflichtfeld nicht verwendbar ist
- Filterung irrelevanter Daten: Testdatensätze, Sandbox-Umgebungen, interne Notizen, Dokumente mit Klassifizierung „Entwurf" oder „Archiv"
- Aktualitätsprüfung: Bei Wissensdatenbanken und RAG-Pipelines ist veraltete Information manchmal schlechter als keine Information. Preislisten von vor zwei Jahren, technische Datenblätter abgekündigter Produkte — diese müssen entweder ein explizites Datum in den Metadaten tragen oder ausgeschlossen werden.
Die Bereinigung für die Vorbereitung eines Fine-tuning-Datensatzes hat zudem eine besondere Schicht: Jedes Trainingsbeispiel muss die korrekte Form eines Eingabe-Ausgabe-Paares haben, die Ausgabe muss korrekt sein (kein „unser Best-Effort-Schätzwert"), und der Datensatz muss die wesentlichen Themen der Domäne gleichmäßig abdecken. Lücken im Datensatz übertragen sich direkt als blinde Flecken ins Modell.
Phase 4: Struktur und Zugriffsrechte
Einer der am häufigsten unterschätzten Aspekte der Datenvorbereitung ist die Frage, wer was sehen darf. In einer Enterprise-Umgebung gibt es mehrere Zugriffsschichten:
- Handelsverträge und Preise, die nur das Vertriebsteam einsehen darf
- HR-Datensätze, die nur die HR-Abteilung einsehen darf
- Technische Dokumentation, die intern öffentlich ist, aber nicht an Kunden gelangen darf
- Regulatorische Dokumentation, die auditierbar sein muss und ohne Aufzeichnung nicht geändert werden darf
Wenn Sie ein RAG-System deployen, das ohne Rücksicht auf diese Rechte Zugriff auf die gesamte Wissensdatenbank hat, und ein Mitarbeiter aus dem Vertrieb nach den Herstellungskosten fragt (die nur der Produktionsleiter einsehen darf) — wird das System antworten. Das ist kein Feature, das ist ein Sicherheitsvorfall.
Die richtige Lösung: Zugriffsrechte müssen auch in die Vektordatenbank übertragen werden. Jedes Dokument oder jeder Chunk muss Metadaten darüber tragen, wer darauf zugreifen darf. Beim Retrieval wird nicht nur nach Relevanz gefiltert, sondern auch danach, ob der aufrufende Benutzer Zugriff hat. Das ist eine nicht-triviale Architektur, aber beim Deployment in regulierten Branchen (DSGVO, Geschäftsgeheimnis) ist sie Pflicht.
Phase 5: Pipeline und Aktualität
Eine KI-Datenpipeline ist kein einmaliger Vorgang — sie ist ein kontinuierlicher Prozess. Unternehmensdaten ändern sich täglich. Neue Bestellungen, neue Dokumente, geänderte Preise, aktualisierte technische Datenblätter.
Typen von Pipeline-Architekturen
- Batch-Pipeline (einmal täglich / wöchentlich): Extraktion, Bereinigung und Re-Indexierung der Wissensdatenbank in regelmäßigen Abständen. Geeignet für die meisten dokumentenbasierten RAG-Systeme — eine Toleranz von 24-stündiger „Staleness" ist bei den meisten Use-Cases akzeptabel.
- Streaming / Near-Real-Time: Änderungen im Quellsystem werden innerhalb von Minuten in die Vektordatenbank propagiert. Notwendig für Use-Cases, bei denen Daten schnell veralten (Ticketing-Systeme, Live-Inventar, Handelssignale). Erfordert eine CDC-Architektur (Change Data Capture).
- Human-in-the-Loop-Verifikation: Bei sensiblen Daten (medizinische Protokolle, juristische Dokumente, Sicherheitshandbücher) durchläuft jede Änderung der Wissensdatenbank eine menschliche Genehmigung, bevor sie im Retrieval-Index erscheint.
Die Wahl der Architektur hängt von der Änderungsfrequenz in den Quelldaten und der Toleranz des Use-Cases gegenüber Veraltung ab. Für die meisten B2B-Unternehmens-Use-Cases reicht eine Batch-Pipeline aus — einfacher zu betreiben, kostengünstiger, ausreichend aktuell.
Monitoring der Datenqualität
Die Pipeline muss Alerting auf Datenanomalie haben: plötzlicher Rückgang der Dokumentanzahl (mögliche Löschung des Quell-Repositories), Anstieg des Anteils leerer Felder (Formatänderung im Quellsystem), Duplikate über einem Schwellwert (Ausfall der Deduplizierung). Ohne Monitoring werden Datenprobleme erst dann sichtbar, wenn das Modell schlechte Antworten liefert — und es ist nicht immer trivial, die Ursache bis zur Quelle zurückzuverfolgen.
Phase 6: Governance und Dokumentation
Das ist der Teil, den technische Teams ungern tun — ohne den ein KI-Projekt bei der Skalierung jedoch auseinanderfällt.
Was dokumentiert sein muss
- Data Dictionary: Für jede Datenquelle und jedes relevante Feld — was es ist, in welchem Format, wer es besitzt, wann es zuletzt geprüft wurde
- Lineage: Woher die Daten kamen, welche Transformationen sie durchlaufen haben, wo sie sich jetzt befinden — die Fähigkeit, einen bestimmten Modelloutput bis zu einem bestimmten Quelldokument zurückzuverfolgen
- Change-Log der Wissensdatenbank: Jede Änderung im Retrieval-Index muss aufgezeichnet werden — was hinzugefügt, was geändert, was entfernt wurde und wann
- Zugriffsrechte und ihre Historie: Für DSGVO-Compliance und bei Audits ist eine Historie notwendig, wer wann auf was Zugriff hatte
Diese Anforderungen sind nicht KI-spezifisch — es sind Data-Governance-Standards, die reife Unternehmen für jedes kritische System haben. KI macht sie nur sichtbarer, weil Modelloutputs direkt sichtbar sind und Entscheidungen beeinflussen.
Typische Fallen, die wir in der Praxis sehen
Bevor wir zum Fazit kommen, einige Muster, die sich wiederholen:
- „Wir geben ihm den gesamten SharePoint": Volumen ist nicht das Problem, Relevanz schon. Ein Modell, das 50.000 Dokumente inklusive Präsentationen aus dem Jahr 2015, Testdateien und Protokolle interner Besprechungen indexiert, wird eine niedrigere Retrieval-Genauigkeit erzielen als ein Modell, das 2.000 sorgfältig ausgewählte und bereinigte Dokumente indexiert. Weniger und besser ist fast immer besser als mehr und minderwertig.
- „Das lösen wir später": Datenqualität lässt sich in KI-Projekten nicht „später" reparieren. Wenn Sie ein RAG-System mit schlechten Daten in Produktion bringen, werden Benutzer das Vertrauen schnell verlieren — und Vertrauen ist viel schwieriger zurückzugewinnen als aufzubauen.
- „Unsere Daten sind sensibel, aber das stört uns nicht": DSGVO und das Gesetz zum Schutz von Geschäftsgeheimnissen gelten auch für KI-Systeme. Wenn Ihre Wissensdatenbank personenbezogene Daten, Verträge mit NDA oder vertrauliche Geschäftsinformationen enthält, müssen Sie eine rechtskonforme Grundlage für deren Verarbeitung auch in der KI-Pipeline haben.
- „Wir tunen auf dem, was wir haben": Wie wir im Artikel zur Vorbereitung des Fine-tuning-Datensatzes beschrieben haben, produziert unzureichendes Volumen oder schlechte Domänenabdeckung in den Trainingsdaten ein Modell, das mit Überzeugung falsch antwortet — was schlechter ist als ein Modell, das sagt „Ich weiß es nicht". Datenzulänglichkeit ist eine Voraussetzung für Fine-tuning, keine Wunschannahme.
Praktische Einstiegsschritte
Wenn Sie beginnen wollen, ohne sich in der Theorie zu verlieren:
- 1.Wählen Sie einen Use-Case, nicht „das gesamte Unternehmen". Ein konkretes Problem (Beantwortung technischer Kundenanfragen, Suche in der Servicedokumentation, Angebotsgenerierung aus dem Katalog) hat einen begrenzten Datenumfang.
- 2.Kartieren Sie die Datenquellen für diesen Use-Case — wo sie liegen, welches Format sie haben, wer sie besitzt, wie aktuell sie sind.
- 3.Führen Sie ein Datenaudit an einer Stichprobe durch — nehmen Sie 100 zufällige Datensätze und beurteilen Sie die Qualität manuell. Die meisten Probleme werden sichtbar.
- 4.Definieren Sie die Mindestqualität für das Produktions-Deployment — nicht „perfekt", sondern „gut genug für den jeweiligen Use-Case".
- 5.Entwerfen Sie die Pipeline — Batch oder Streaming, Zugriffsrechte, Monitoring.
- 6.Iterieren Sie: Der erste Index wird unvollkommen sein. Bewerten Sie die Qualität der RAG-Antworten, identifizieren Sie die häufigsten Ursachen für schlechte Antworten, korrigieren Sie Daten oder Pipeline, und wiederholen Sie.
Häufige Fragen
Wie viele Daten brauchen wir für ein RAG-System?
Für ein funktionsfähiges RAG-System gibt es keine Untergrenze für die Dokumentanzahl — selbst 50 gut aufbereitete Dokumente können hervorragende Ergebnisse liefern, wenn sie den relevanten Domänenbereich abdecken. Wichtiger als die Quantität ist die Abdeckung: Wenn Benutzer Fragen stellen, auf die die Wissensdatenbank keine Antwort enthält, wird das Modell dies entweder eingestehen (gut konfigurierter Guardrail) oder eine Antwort erfinden (schlechter Zustand). Inventarisieren Sie die Fragen, die das System beantworten können muss, und prüfen Sie, ob diese aus den verfügbaren Daten beantwortbar sind.
Können wir interne Daten für Fine-tuning ohne rechtliche Risiken verwenden?
Das hängt von der Art der Daten ab. Interne technische Handbücher, SOP-Dokumente und historische Datensätze ohne personenbezogene Daten sind typischerweise unproblematisch — sie gehören dem Unternehmen und enthalten keine personenbezogenen Daten (PII). Datensätze mit Kundendaten, Verträgen oder personenbezogenen Daten von Mitarbeitern erfordern eine Rechtsgrundlage nach DSGVO (Einwilligung, berechtigtes Interesse, Vertragserfüllung) auch für die Verarbeitung in der KI-Pipeline. Wir empfehlen, vor dem Aufbau eines Trainingsdatensatzes aus regulierten Daten den Datenschutzbeauftragten zu konsultieren.
Wie lange dauert die Datenvorbereitung?
In der Praxis sehen wir eine Spanne von zwei Wochen (eine klar definierte Quelle, gute interne Dokumentation, kooperative Dateneigentümer) bis zu sechs Monaten (Daten auf drei verschiedene Systeme verteilt, keine existierende Data Governance, interne politische Hürden beim Zugriff). Ein durchschnittliches Projekt verbringt 30–40 % der Gesamtzeit mit der Datenvorbereitung. Wenn ein Kunde behauptet, das in einer Woche zu schaffen, ist es entweder ein sehr kleiner Scope oder eine Unterschätzung des Problemausmaßes.
Brauchen wir einen Data Engineer oder reicht ein KI-Entwickler?
Für einfachere Use-Cases (PDF-Dokumente, einfacher SharePoint-Export) kann ein KI-Entwickler die grundlegende Extraktion und das Chunking bewältigen. Für komplexere Szenarien — Streaming-Pipeline aus ERP-Systemen, CDC-Architektur, Entitätsnormalisierung über mehrere Quellen hinweg, DSGVO-konforme Lineage — ist ein erfahrener Data Engineer erforderlich. Die Unterschätzung dieser Rolle ist eine der häufigsten Ursachen für Verzögerungen bei KI-Projekten.
Müssen die Daten auf Deutsch vorliegen, oder funktioniert auch Englisch?
Für ein RAG-System auf Unternehmensdokumente ist die Sprache der Dokumente primär — Embedding-Modelle werden mehrsprachig eingesetzt (Modelle wie BGE-M3 decken 100+ Sprachen ab), das Retrieval funktioniert in beiden Sprachen gut. Für Fine-tuning ist die Sprache der Trainingsdaten entscheidend — wenn Sie ein Modell wollen, das in professionellem Deutsch mit unternehmensspezifischer Terminologie antwortet, müssen die Trainingsbeispiele auf Deutsch mit dieser Terminologie vorliegen.
*Wenn Sie die Vorbereitung Ihrer Unternehmensdaten für ein KI-Projekt angehen und unnötige Fehler vermeiden wollen, gehen wir das Datenaudit gerne gemeinsam durch und entwerfen eine Pipeline-Architektur, die zu Ihrem Use-Case passt. Kontaktieren Sie uns für eine unverbindliche Beratung.*