Datenqualität als Voraussetzung für KI: Was vor dem Projektstart geprüft gehört

Die meisten KI-Projekte scheitern nicht am Modell. Sie scheitern an dem, was man dem Modell zu lesen gibt. Ein Assistent, der auf veraltete Preislisten zugreift, gibt veraltete Preise aus. Eine Klassifikation, die auf inkonsistenten Stammdaten trainiert wurde, klassifiziert inkonsistent. Datenqualität ist keine Nebenbedingung von KI-Projekten, sondern ihre Grundlage. Und sie lässt sich nicht nachträglich vom System kompensieren, jedenfalls nicht dauerhaft.

In der Praxis wird das Thema trotzdem regelmäßig übersprungen. Der Projektplan beginnt beim Anwendungsfall, die Daten gelten als gegeben. Erst wenn die ersten Antworten des Systems falsch sind, beginnt die Suche nach der Ursache, und die führt fast immer in den Datenbestand: doppelte Kundensätze, leere Pflichtfelder, drei Schreibweisen für denselben Artikel. Wer diese Prüfung vor den Projektstart zieht, spart sich Wochen an Fehlersuche und eine Menge verlorenes Vertrauen.

Vier Dimensionen, die für KI-Projekte wirklich zählen

Datenqualität hat in der Literatur viele Dimensionen. Für KI-Projekte haben sich vier als entscheidend erwiesen:

• Vollständigkeit: Sind die Felder, auf die sich das System stützen soll, tatsächlich befüllt. Ein Feld, das in der Hälfte der Fälle leer ist, kann keine tragende Rolle im Anwendungsfall spielen.
• Konsistenz: Wird derselbe Sachverhalt überall gleich abgebildet. Unterschiedliche Schreibweisen, Einheiten oder Kategoriesysteme zwischen Abteilungen sind der häufigste Störfaktor.
• Aktualität: Spiegeln die Daten den heutigen Zustand. Veraltete Ansprechpartner, abgelaufene Konditionen und stillgelegte Produkte erzeugen Antworten, die formal korrekt und praktisch falsch sind.
• Zugänglichkeit: Liegen die Daten dort, wo ein System sie erreichen kann, in einem Format, das sich verarbeiten lässt. Wissen in Papierordnern, gescannten PDFs ohne Texterkennung oder in den Köpfen einzelner Mitarbeiter ist für ein KI-Projekt zunächst nicht vorhanden.

Auffällig ist, was in dieser Liste fehlt: Perfektion. Kein gewachsener Datenbestand ist fehlerfrei, und das muss er auch nicht sein. Entscheidend ist, ob die Daten für den konkreten Anwendungsfall gut genug sind. Diese Frage lässt sich nur beantworten, wenn man den Anwendungsfall vorher präzise benannt hat.

Den Datenbestand in wenigen Tagen realistisch einschätzen

Eine belastbare Ersteinschätzung braucht kein monatelanges Audit. Bewährt hat sich ein kompakter Ablauf über wenige Tage. Zuerst wird festgelegt, welche Datenquellen der Anwendungsfall überhaupt berührt: meist sind es zwei bis vier Systeme, nicht die gesamte Landschaft. Dann zieht man aus jeder Quelle eine Stichprobe und prüft sie gegen die vier Dimensionen, mit einfachen Mitteln wie Zählabfragen und manueller Durchsicht.

Zwei Fragen liefern dabei überproportional viel Erkenntnis. Erstens: Wie hoch ist der Anteil leerer oder offensichtlich falsch befüllter Werte in den Feldern, die der Anwendungsfall braucht. Zweitens: Wenn zwei Systeme denselben Sachverhalt führen, wie oft widersprechen sie sich. Wer diese beiden Fragen für die relevanten Felder beantwortet hat, kennt den Zustand seines Datenbestands besser als die meisten Projektteams beim Start.

Ebenso wichtig wie die Zahlen ist das Gespräch mit den Menschen, die täglich mit den Daten arbeiten. Sie wissen, welche Felder seit Jahren niemand pflegt, welche Werte man nicht ernst nehmen darf und wo die inoffizielle Excel-Wahrheit neben dem offiziellen System existiert. Diese Auskünfte tauchen in keiner Abfrage auf und entscheiden trotzdem über den Projekterfolg.

Was vorher behoben werden muss und was das System toleriert

Nicht jeder gefundene Mangel blockiert das Projekt. Die Unterscheidung lohnt sich, weil sie Budget und Zeitplan bestimmt.

Mangel	Vor dem Projekt beheben	Kann das System tolerieren
Leere Pflichtfelder im Kernprozess	Ja	Nein
Widersprüche zwischen führenden Systemen	Ja	Nein
Uneinheitliche Schreibweisen	Teilweise	Oft, mit Normalisierung
Tippfehler in Freitextfeldern	Nein	Ja, in Grenzen
Historische Altdaten ohne Bezug zum Anwendungsfall	Nein	Ja, wenn ausgeklammert

Als Faustregel: Alles, was die fachliche Wahrheit betrifft, muss vor dem Start geklärt sein. Wenn zwei Systeme unterschiedliche Lieferadressen für denselben Kunden führen, kann kein Modell entscheiden, welche stimmt. Alles, was nur die Form betrifft, also Schreibweisen, Formate und kleinere Unsauberkeiten, lässt sich häufig in der Verarbeitung abfangen. Sprachmodelle sind gegenüber formalen Unregelmäßigkeiten erstaunlich robust, gegenüber inhaltlichen Widersprüchen dagegen hilflos: Sie geben dann eine der beiden Versionen selbstbewusst wieder.

Datenbereinigung als eigenen Projektschritt budgetieren

Der teuerste Fehler in der Planung ist, Datenbereinigung als Nebentätigkeit zu behandeln, die das Projektteam nebenher erledigt. Sie ist ein eigener Arbeitsschritt mit eigenem Aufwand, eigener Verantwortung und eigenem Abnahmekriterium. Wer sie nicht einplant, bezahlt sie trotzdem, nur später und teurer, weil sie dann unter Zeitdruck und parallel zur Fehlersuche stattfindet.

Sinnvoll ist, die Bereinigung strikt auf den Anwendungsfall zu begrenzen. Das Ziel ist nicht ein perfekter Datenbestand im ganzen Unternehmen, sondern ein tragfähiger Bestand für das konkrete Vorhaben. Dazu gehört auch, die Ursachen anzugehen: Ein bereinigtes Feld, das im Tagesgeschäft weiter falsch befüllt wird, ist in einem halben Jahr wieder im alten Zustand. Wer Bereinigung ohne angepasste Pflegeprozesse budgetiert, kauft ein Verfallsdatum mit.

Fazit

Datenqualität ist die unbequeme Vorarbeit, die über KI-Projekte entscheidet, bevor die erste Zeile Code geschrieben ist. Die gute Nachricht: Die Prüfung ist überschaubar. Vier Dimensionen, eine Stichprobe je Quelle, zwei Kernfragen und Gespräche mit den Menschen, die die Daten pflegen. Daraus ergibt sich eine klare Trennung zwischen Mängeln, die vor dem Start behoben werden müssen, und solchen, die das System verkraftet. Wer diese Trennung trifft und die Bereinigung als eigenen Schritt budgetiert, startet nicht mit der Hoffnung auf gute Daten, sondern mit dem Wissen darüber. Das ist der Unterschied zwischen einem Projekt, das liefert, und einem, das an seiner Grundlage scheitert.