Der häufigste Grund für das Scheitern von KI-Projekten in Unternehmensumgebungen ist nicht die Modellwahl, das Compute-Budget oder das Engineering-Talent. Es ist die Datenqualität. Bei gescheiterten KI-Projekten lässt sich die Ursache typischerweise auf denselben Ort zurückführen: Die Organisation hat die Lücke zwischen vorhandenen Daten und zweckgeeigneten Daten unterschätzt. Branchenforschung zeigt konsistent, dass die Mehrheit der KI-Projektmisserfolge einen Datenqualitätsursprung hat.
Warum Datenqualität für KI anders ist
Traditionelle BI- und Reporting-Systeme tolerieren unvollkommene Daten, weil Menschen die Ausgabe interpretieren und Urteilsvermögen anwenden. Ein Dashboard mit 98 % vollständigen Umsatzdaten ist nützlich, selbst wenn 2 % der Datensätze eine Kostenstellen-Codierung fehlt. Ein maschinelles Lernmodell, das auf demselben Datensatz trainiert wurde, lernt die fehlende Kostenstelle als Feature — und könnte systematisch falsch vorhersagen für die 2 % der Fälle, in denen es am meisten darauf ankommt. KI verstärkt Datenqualitätsprobleme, anstatt sie zu absorbieren.
Die Mindest-Datenqualitätsanforderung für KI ist höher als für Reporting, höher als für Analytics und höher als die meisten Enterprise-Daten-Teams anfangs glauben. Unser Framework existiert, um diese Lücke sichtbar zu machen, bevor ein Modell in die Produktion geht.
Das Fünf-Dimensionen-Datenqualitäts-Framework
Dekas Datenqualitäts-Framework bewertet fünf Dimensionen für jeden Datensatz in einem KI-Projekt:
1. Vollständigkeit
Welcher Prozentsatz der erforderlichen Felder enthält Werte? Vollständigkeit ist die sichtbarste Dimension und typischerweise die erste, die bewertet wird. Wir berechnen Vollständigkeit auf Feld-, Datensatz- und Entitätsebene — ein Datensatz kann auf Feldebene 100 % vollständig sein, aber eine ganze Entitätsbeziehung fehlt. Tools: Great Expectations Profiling, benutzerdefinierte SQL-Assertionen in dbt.
2. Genauigkeit
Spiegeln die Werte die Realität wider? Genauigkeit ist die schwierigste Dimension, ohne Referenzdatensatz zu bewerten. Unser Ansatz: Kreuzvalidierung gegen vertrauenswürdige Sekundärquellen (ERP-Daten vs. Kontoauszüge, Sensordaten vs. physikalische Messungen), stichprobenbasierte manuelle Verifikation mit Fachexperten und statistische Anomalieerkennung für numerische Spalten.
3. Konsistenz
Werden äquivalente Konzepte systemübergreifend konsistent dargestellt? Konsistenzfehler sind in Enterprise-Landschaften endemisch, wo derselbe Kunde in drei Systemen "ACME GmbH", "ACME Germany" und "ACME DE" sein könnte. Wir bauen Entity-Resolution-Pipelines, um Identitäten zu normalisieren, bevor das Training beginnt.
4. Aktualität
Wie frisch sind die Daten im Verhältnis zum Geschäftsprozess, den sie modellieren? Ein Kundenchurn-Modell, das auf 18 Monate alten Verhaltensdaten trainiert wurde, produziert Vorhersagen für eine Kundenpopulation, die nicht mehr existiert. Wir definieren Aktualitätsanforderungen pro Feature-Gruppe und implementieren Freshness-SLAs mit automatisiertem Monitoring.
5. Gültigkeit
Entsprechen die Daten erwarteten Formaten, Bereichen und Geschäftsregeln? Gültigkeitsprüfungen umfassen: Schema-Konformität, Wertebereichsvalidierung, referenzielle Integrität und Geschäftsregel-Assertionen (z. B. "Rechnungsdatum muss nach Bestelldatum liegen"). Wir kodieren Gültigkeitsregeln als dbt-Tests und Great-Expectations-Checkpoints, die in der CI/CD-Pipeline bei jeder Datenaktualisierung ausgeführt werden.
Bewertungsmethodik und Remediation
Unser Bewertungsprozess dauert für ein typisches Enterprise-Datensatz-Portfolio zwei bis vier Wochen. Wir profilieren Quelldaten, berechnen Dimensions-Scores, ordnen jeden Befund einem spezifischen KI-Anwendungsfall-Risiko zu und priorisieren Remediation nach Impact-to-Effort-Verhältnis. Remediation-Strategien reichen von Quellsystem-Fixes (bevorzugt) über Imputationsstrategien (akzeptabel für Features mit geringem Impact) bis zur Anwendungsfall-Eingrenzung (wenn eine Dimension nicht bereinigt werden kann, passen wir den KI-Umfang an, um das betroffene Feature zu vermeiden).
Governance-Modell
Datenqualität ist keine einmalige Bewertung — sie verschlechtert sich kontinuierlich, während sich Quellsysteme ändern, Geschäftsprozesse entwickeln und Datenvolumen wachsen. Wir implementieren ein Datenqualitäts-Governance-Modell mit: automatisierten Qualitätsprüfungen, die bei jeder Pipeline-Ausführung laufen, Qualitäts-Score-Dashboards, die sowohl für das Daten-Team als auch für Business-Stakeholder sichtbar sind, einem Datenqualitäts-SLA pro KI-Anwendungsfall (Mindest-Acceptable-Score für das Erlauben von Modell-Retraining) und einem definierten Eskalationsprozess, wenn die Qualität unter den SLA-Schwellenwert fällt. Das Governance-Modell ist bewusst schlank gehalten — es muss vom Client-Team nachhaltig betrieben werden können, nachdem Dekas Engagement endet.
Diesen Leitfaden für die nächste interne Prüfung nutzen
Offene Entscheidungen, Nachweisverantwortliche und Prüftermine sollten vor der Wahl eines Umsetzungswegs festgehalten werden.