Warum die Datenfrage nicht weggeht

Mit modernen Sprachmodellen entsteht der Eindruck, das Datenproblem sei kleiner geworden. Modelle verstehen unstrukturierte Texte, ziehen Zusammenhänge aus Kontext und kommen mit unsauberer Sprache erstaunlich gut zurecht. In einem Demo funktioniert das oft eindrucksvoll. In einem produktiven System mit echten Nutzern, echtem Wissen und echten Konsequenzen wird die Datenfrage nicht kleiner — sie verschiebt sich nur.

Statt klassischer Trainingsdaten geht es heute meist um Inhalte, die ein Modell zur Laufzeit zugespielt bekommt: Handbücher, Verträge, Tickets, Produktdokumentation, interne Richtlinien. Das Modell beantwortet eine Frage nicht aus dem Gedächtnis, sondern auf Basis dieser Quellen. Was reingeht, bestimmt, was rauskommt — und genau dafür ist Datenqualität die nicht-verhandelbare Voraussetzung.

In typischen Architekturen rund um RAG-Systeme ist die Wirkung besonders direkt. Die eigentliche Intelligenz steckt nicht im Modell, sondern im Retrieval — und Retrieval auf schlechten Daten produziert verlässlich schlechte Antworten.

Welche Qualitätsdimensionen für KI wirklich zählen

„Datenqualität" ist als Begriff zu groß. Im KI-Kontext lohnt es sich, sie in konkrete Dimensionen zu zerlegen, die im Betrieb unterschiedlich teuer werden, wenn sie fehlen.

Die erste Dimension ist Aktualität. Eine veraltete Richtlinie klingt im Modell genauso überzeugend wie die aktuelle. Wer keine klare Antwort darauf hat, welche Version gerade gilt, baut ein System, das stabil falsche Antworten gibt. Aktualität ist im KI-Kontext kein Datums-Feld, sondern eine Disziplin: Wer schreibt was wann fort, und wie wird die alte Version sauber ersetzt?

Die zweite Dimension ist Eindeutigkeit. Dieselbe Frage wird in mehreren Quellen unterschiedlich beantwortet, weil verschiedene Teams parallel dokumentiert haben. Für einen Menschen ist das Alltag, für ein Modell ist es Gift: es kann nicht entscheiden, welche Quelle die richtige ist, und mischt beide. Antworten klingen plausibel und sind in Wahrheit Mosaike aus Widersprüchen.

Die dritte Dimension ist Struktur. Sehr lange, schlecht gegliederte Dokumente liefern bei der semantischen Suche oft die falschen Abschnitte. Klare Überschriften, eindeutige Abschnitte und konsistente Formatierung sind keine Schönheitsfrage, sondern Voraussetzung für brauchbares Retrieval. Ohne Struktur degeneriert RAG zur Zufallssuche.

Die vierte Dimension ist Belegbarkeit. Eine Antwort, die im Betrieb auf eine konkrete Quelle zurückführen muss, braucht Inhalte, deren Herkunft eindeutig ist. Inhalte ohne klare Autorenschaft, ohne Datum oder ohne Versionsstand sind im Audit-Fall problematisch — und in vielen Unternehmensszenarien überhaupt nicht zulässig.

Die fünfte Dimension ist Berechtigungs-Bewusstsein. Daten in einer KI-Pipeline tragen Berechtigungen mit. Wer sie ignoriert, baut ein System, das Mitarbeitenden Inhalte zeigt, die sie nie hätten sehen sollen. Diese Dimension fällt in vielen Pilotprojekten still aus, weil sie im Demo-Setup keine Rolle spielt — und sprengt das Vorhaben spätestens beim ersten produktiven Rollout.

Warum „erst alle Daten aufräumen" der falsche Reflex ist

Sobald ein Unternehmen versteht, wie wichtig Datenqualität ist, droht der entgegengesetzte Fehler: ein großes, generelles Daten-Aufräumprojekt vor dem ersten KI-Vorhaben. Das klingt verantwortungsvoll und ist in der Praxis regelmäßig der Anfang vom Ende.

Ein generelles Aufräumprojekt hat keinen klaren Maßstab. Wann ist es fertig? Welche Daten sind „gut genug"? Wer entscheidet das? Solche Vorhaben verlieren sich in Aufwand, ohne dass am Ende ein konkreter Use Case messbar besser läuft. Die KI-Roadmap rutscht in die Zukunft, das Vertrauen der Organisation auch.

Der bessere Weg ist umgekehrt: ein konkreter, gut geschnittener Use Case wird ausgewählt und macht die nötigen Datenanforderungen sichtbar. Es wird nur das aufgeräumt und in Form gebracht, was dieser eine Use Case wirklich braucht. Daraus entsteht eine Datenpipeline mit klar definierter Qualität — überprüfbar, messbar, mit erkennbarem Nutzen.

Die Use-Case-getriebene Datenarbeit hat einen weiteren Vorteil: sie wirkt kumulativ. Was für den ersten Use Case sauber aufbereitet wurde, ist für den zweiten oder dritten häufig schon brauchbar. Aus Datenarbeit pro Vorhaben wird mit der Zeit eine echte Datenplattform — ohne sie als großes Programm starten zu müssen.

Was im laufenden Betrieb wirklich Schmerzen erzeugt

Im Betrieb produktiver KI-Anwendungen tauchen bestimmte Datenprobleme so zuverlässig auf, dass es sich lohnt, sie schon vor dem Go-live zu adressieren.

Erstens: Stille Veralterung. Inhalte werden nicht entfernt, sondern liegen weiter im Index, während daneben eine neue Version existiert. Modelle finden beide, gewichten sie nicht zwingend richtig, und die Antwort wird ein Mittelding. Eine klare Lifecycle-Regel — was ersetzt wird, verschwindet aus dem Index — verhindert das.

Zweitens: Duplikate mit kleinen Unterschieden. Vier Versionen derselben Anweisung, jede mit minimalen Abweichungen, sorgen für inkonsistente Antworten. Eine technische Duplikatserkennung allein hilft hier wenig — die inhaltliche Konsolidierung muss redaktionell erfolgen, bevor sie technisch gepflegt wird.

Drittens: Kontextlose Schnipsel. Tabellen, Bullet Points oder Aufzählungen ohne Überschrift wirken im Original verständlich, weil ein Mensch den Kontext im Kopf trägt. Im Retrieval landen sie als isolierte Brocken und verlieren ihre Bedeutung. Inhalte sollten so geschnitten sein, dass jeder sinnvolle Abschnitt für sich verständlich bleibt.

Viertens: Berechtigungsbrüche. Inhalte werden ungefiltert in den Index aufgenommen, obwohl sie nur bestimmten Rollen vorbehalten sind. Spätestens beim ersten produktiven Vorfall wird klar, dass die Berechtigungslogik der Quellsysteme bis in die Antwortschicht hineinwirken muss.

Fünftens: Halluzinationen ohne Belegpflicht. Wenn das Modell keine Quelle gefunden hat, sollte es nicht stattdessen frei antworten. Das ist eine Architekturentscheidung, kein Datenproblem im engeren Sinne, aber sie wird erst durch saubere Belegbarkeit der Daten überhaupt möglich. Wir haben das Thema im Beitrag zu Halluzinationen in LLM-Anwendungen ausgeführt.

Wer in der Datenfrage was verantwortet

Eine produktive KI-Anwendung verschiebt Datenverantwortung. Bisher waren Inhalte verstreut über Teams und Systeme, jeder pflegte „seinen" Bereich, und niemand musste eine konsolidierte Sicht garantieren. Sobald ein Modell auf diese Inhalte zurückgreift und Antworten daraus erzeugt, entsteht eine neue Rolle: jemand muss für die Qualität dieser Antwortgrundlage geradestehen.

Drei Verantwortungen sollten im KI-Kontext ausdrücklich besetzt werden. Erstens fachliche Eigentümerschaft: Wer ist für die inhaltliche Richtigkeit der Quellen zuständig? Zweitens redaktionelle Pflege: Wer kümmert sich tatsächlich um Konsolidierung, Versionsführung und Konsistenz? Drittens technische Aufnahme: Wer betreibt die Pipeline, die diese Inhalte sauber in den Index bringt — und wieder entfernt, wenn sie es sollten?

Diese drei Rollen müssen nicht drei Personen sein, aber sie müssen ausdrücklich benannt werden. Ohne klare Verantwortlichkeiten degeneriert jede Datenpipeline zu einem System, in dem alle leise hoffen, dass jemand anders aufpasst.

Datenqualität messbar machen

Datenqualität wird oft als Bauchgefühl behandelt — „die Daten sind ganz okay" oder „die Daten sind schlecht". Im KI-Kontext lohnt es sich, ein paar konkrete Messpunkte einzuführen, die zeigen, ob sich die Qualität verbessert oder nicht.

Sinnvolle Messpunkte sind: der Anteil der Antworten, in denen das Modell eine klare Quelle nennen kann; der Anteil der Antworten mit „weiß ich nicht", die inhaltlich richtig sind (das System hätte korrekt schweigen sollen); die Übereinstimmung zwischen Antworten und einer kuratierten Referenzmenge an Testfragen; und die Häufigkeit, mit der Quellen mit gegensätzlichen Aussagen gleichzeitig im Kontext auftauchen.

Diese Punkte überschneiden sich mit dem Bereich LLM-Qualitätssicherung: Tests, Metriken und Regressionen sind kein Luxus, sondern die einzige Möglichkeit, objektiv zu sehen, ob die Datenarbeit Wirkung zeigt — oder ob nur subjektiv das Gefühl entstanden ist, „es ist besser geworden".

Typische Fehler im Umgang mit Datenqualität

Der erste Fehler ist, Datenarbeit als einmaligen Aufwand zu planen. Daten ändern sich, Quellen kommen hinzu, Verantwortlichkeiten verschieben sich. Eine Datenpipeline ohne kontinuierliche Pflege degradiert in Monaten, ohne dass es jemand sofort bemerkt.

Der zweite Fehler ist, alle Quellen gleich zu behandeln. Ein gut gepflegtes internes Wiki und ein Sammelordner mit alten PDFs gehören in derselben Pipeline mit unterschiedlichem Gewicht — oder erst gar nicht zusammen. Wer das nicht unterscheidet, drückt die Qualität der besten Quelle auf das Niveau der schlechtesten.

Der dritte Fehler ist, die Datenarbeit ausschließlich technisch zu denken. Indexierung, Embeddings, Vektordatenbank — das ist die einfache Hälfte. Die schwerere ist redaktionell und organisatorisch. Wer sie überspringt, baut ein technisch sauberes System auf einer wackligen Inhaltsbasis.

Der vierte Fehler ist, die Datenfrage erst beim Übergang vom Pilot zur Produktion ernst zu nehmen. Im Pilot reichen ein paar Beispiel-Dokumente. In Produktion reichen sie nicht. Wer den Unterschied erst beim Rollout entdeckt, verschiebt den Live-Termin um Quartale.

Wann externe Unterstützung sinnvoll ist

Eine erste Datenpipeline für ein gut aufgeräumtes Wiki lässt sich heute in wenigen Tagen bauen. Eine produktive Datenpipeline für mehrere Quellen, Berechtigungen, wechselnde Inhalte und mehrere KI-Anwendungen ist eine andere Dimension. Spätestens dort lohnt sich ein Blick von außen — auf Schnitt, Verantwortlichkeiten, Pflegekonzept und Evaluation.

Wir arbeiten mit Unternehmen, die Datenarbeit nicht als Block vor der KI sehen, sondern als Teil ihres KI-Betriebs verstehen. Im Rahmen unseres AI Engineering schneiden wir Datenpipelines so, dass sie zu konkreten Use Cases passen, kumulativ wachsen und vom Team langfristig getragen werden können.