Der stille Killer von KI-Projekten

Es gibt einen Moment in fast jedem KI-Projekt, den alle kennen, aber kaum jemand offen benennt: Der Prototyp funktioniert, die Demo begeistert, das Budget ist freigegeben – und trotzdem geht das Vorhaben sechs Monate später still und leise unter. Nicht weil das Modell schlecht war. Nicht weil das Team fehlte. Sondern weil niemand rechtzeitig die unbequeme Frage gestellt hat: Auf welchem Datenfundament bauen wir eigentlich?

Die unbequeme Wahrheit lautet: Die meisten KI-Projekte scheitern nicht an Algorithmen, nicht an fehlendem Fachpersonal und nicht an mangelndem Willen zur Digitalisierung. Sie scheitern an einer Datenarchitektur, die für die Anforderungen moderner KI-Systeme schlicht nicht gemacht wurde.

Warum das Problem so lange unsichtbar bleibt

Das Tückische an einer schlechten Datenarchitektur ist ihre Latenz. Die Konsequenzen zeigen sich selten sofort. In frühen Projektphasen – wenn man mit sauberen Beispieldatensätzen, handverlesenen CSVs oder isolierten Datenbankauszügen arbeitet – läuft alles reibungslos. Das Modell lernt, die Metriken stimmen, das Team ist motiviert.

Das Problem entfaltet sich erst später: wenn reale, ungereinigte Produktionsdaten ins Spiel kommen, wenn mehrere Systeme integriert werden müssen, wenn das Modell in eine bestehende Infrastruktur eingebettet werden soll, die historisch gewachsen ist und entsprechend aussieht.

Dann offenbaren sich die eigentlichen Baustellen:

• Daten liegen in inkompatiblen Formaten quer über Abteilungen und Systeme verteilt
• Es gibt keine verlässliche Single Source of Truth – jede Abteilung pflegt ihre eigene Version der Wahrheit
• Historische Daten sind unvollständig, falsch gelabelt oder schlicht nicht vorhanden
• Datenpipelines wurden für Reporting gebaut, nicht für ML-Workloads
• Feature Engineering wird zum Bottleneck, weil niemand weiß, welche Daten wo liegen und wer dafür verantwortlich ist
  
  
  

Der Architektur-Debt, den niemand sieht

Technischer Schulden gegenüber KI-Projekten gibt es eine besondere Form: den Data Architecture Debt. Er entsteht dann, wenn Unternehmen ihre KI-Ambitionen schneller skalieren als ihre Dateninfrastruktur. Dieser Debt akkumuliert sich leise – durch Einzellösungen, die nie harmonisiert wurden, durch Datensilos, die organisch gewachsen sind, durch fehlende Governance-Prozesse und durch die Abwesenheit von Datenverantwortlichen mit echtem Gestaltungsmandat.

Was in der Praxis auffällt: Viele Unternehmen investieren erheblich in Modellentwicklung und vernachlässigen dabei systematisch drei fundamentale Schichten:

1. Data Ingestion & Integration – Wie gelangen Daten überhaupt ins System? Sind die Pipelines robust, skalierbar und dokumentiert?
2. Data Quality Management – Wer ist verantwortlich für Vollständigkeit, Konsistenz und Aktualität der Daten? Gibt es automatisierte Qualitätsprüfungen?
3. Feature Store & Reproduzierbarkeit – Können Features konsistent zwischen Training und Inference reproduziert werden? Gibt es Versionierung?

Fehlen diese Schichten oder sind sie unausgereift, baut man de facto auf Sand.

Was erfolgreiche KI-Projekte anders machen

Unternehmen, die KI nachhaltig in ihre Wertschöpfung integrieren, unterscheiden sich von gescheiterten Projekten nicht primär durch bessere Modelle oder mehr Budget. Sie unterscheiden sich durch eine fundamentale Vorentscheidung: Sie behandeln Daten als strategisches Asset und nicht als notwendiges Übel.

Konkret bedeutet das:

• Data Ownership ist klar geregelt. Es gibt benannte Data Owner pro Domäne, die für Qualität und Verfügbarkeit verantwortlich sind – nicht die IT allein.
• Die Architektur ist ML-first gedacht. Pipelines werden nicht nachträglich für KI angepasst, sondern von Anfang an auf die Anforderungen von Training, Validierung und Inference ausgelegt.
• Es gibt ein zentrales Datenkatalog-System. Data Lineage, Metadaten und Zugriffsrechte sind dokumentiert und zugänglich – nicht irgendwo in den Köpfen einzelner Mitarbeiter.
• Qualitätssicherung ist automatisiert. Data Quality Checks laufen als Teil der Pipeline, nicht als manuelle Stichprobe vor dem nächsten Modell-Run.
• Feedback-Loops sind von Anfang an eingeplant. Wie fließen Signale aus dem Produktivbetrieb zurück in Training und Monitoring?
  
  
  

Der Prototyp-Produktions-Gap

Ein besonders verbreitetes Muster ist der sogenannte Prototyp-Produktions-Gap. Teams bauen beeindruckende Proof-of-Concepts auf der Basis von Daten, die für diesen Zweck manuell aufbereitet wurden. Das Modell performt gut – in der kontrollierten Umgebung. Sobald es in die Produktionsumgebung soll, stößt man auf Realität: heterogene Quellsysteme, fehlende Felder, unerwartete Verteilungsverschiebungen in den Eingangsdaten.

Das ist kein Modell-Problem. Das ist ein Architektur-Problem. Und es lässt sich nur lösen, wenn man es als solches akzeptiert.

Drei Fragen, die jedes KI-Projekt beantworten muss – bevor das erste Modell trainiert wird

Die beste Zeit, eine Datenarchitektur zu überdenken, war gestern. Die zweitbeste ist jetzt – am besten vor dem ersten Modell-Commit. Folgende Fragen sollten in jedem Projekt frühzeitig beantwortet sein:

1. Welche Datenquellen speisen das Modell im Produktivbetrieb – und sind diese Quellen stabil, dokumentiert und kontrollierbar?
2. Wie wird sichergestellt, dass die Daten, mit denen trainiert wird, dieselbe Struktur und Qualität haben wie die Daten, die das Modell später sieht?
3. Wer ist verantwortlich, wenn die Datenqualität im laufenden Betrieb sinkt – und gibt es einen definierten Prozess dafür?
   
   
   

Fazit

KI ist kein Technologieproblem. KI ist ein Datenproblem, das mit Technologie gelöst werden muss. Wer diesen Zusammenhang versteht und Datenarchitektur nicht als lästige Infrastrukturaufgabe, sondern als strategische Kernkompetenz behandelt, hat einen entscheidenden Vorsprung gegenüber allen, die glauben, das nächste Modell-Update werde ihre fundamentalen Datenprobleme lösen.

Es wird das nicht tun. Aber eine solide Datenarchitektur schon.