Data Hub als Fundament für KI

Der McKinsey-Bericht State of AI 2025 nennt als zentralen Blocker für das Skalieren von KI die Datenlage: siloartige Tabellen und Legacy-Datenbanken statt sauberer, integrierter und verwalteter Daten. Gartner prognostiziert, dass bis 2026 etwa 60 Prozent der KI-Projekte ohne KI-fähige Daten aufgegeben werden.

Ein robustes Datenfundament ist die Voraussetzung jeder wirksamen KI-Initiative, kein optionaler Ausbau. Wer KI ohne integrierte Datenbasis startet, begrenzt die Modellgenauigkeit von Anfang an.

System: die Datenlücke in Organisationen

Gewachsene IT-Landschaften verteilen Daten über ERP-, CRM- und Produktionssysteme, Tabellenkalkulationen und Sensoren. Diese Fragmentierung verhindert eine umfassende Nutzung und begrenzt das Automatisierungspotenzial. Sie ist der konkrete Mechanismus hinter dem von McKinsey beschriebenen Skalierungsabstand.

• Inkonsistente Schemata und widersprüchliche Datenqualität.
• Fehlende Master-Data-Governance.
• Begrenzte Rechenkapazität in lokalen Umgebungen.
• Proprietäre Schnittstellen und Compliance-Lücken im Audit-Trail.

Problem: warum Einzellösungen nicht skalieren

Hinzu kommt die regulatorische Dimension. Der EU AI Act verlangt für Hochrisiko-Systeme ein vollständiges Data-Lineage-Tracking, also die nachvollziehbare Herkunft jedes Datenpunkts. In einer fragmentierten Landschaft ist diese Nachvollziehbarkeit kaum herstellbar, weil Daten auf dem Weg durch viele Systeme ihre Spur verlieren. Eine zentrale Integrationsschicht ist damit nicht nur eine Frage der Effizienz, sondern zunehmend eine Voraussetzung der Compliance.

Punktuelle Integrationen lösen jeweils ein Symptom, erhöhen aber die Gesamtkomplexität. Ohne eine zentrale Integrationsschicht wächst der Pflegeaufwand schneller als der Nutzen, und jede neue Anwendung verlängert die Kette der Schnittstellen.

Ansatz: der Data Hub als Lakehouse

Die Anbindung bestehender Systeme erfolgt über abgestufte Verfahren. Stammdaten werden im Batch-Verfahren übernommen, transaktionale Daten über Change Data Capture nahezu in Echtzeit gestreamt. Für Legacy-Systeme ohne moderne Schnittstellen kommen Datenbankreplikation, Dateitransfer oder robotergesteuerte Prozessautomatisierung zum Einsatz. Entscheidend ist, dass der Data Hub die Integrationslogik bündelt, statt sie auf jede einzelne Anwendung zu verteilen. Damit sinkt die Zahl der Schnittstellen, die bei jeder Änderung gepflegt werden müssen.

Ein Data Hub dient als zentrale Integrations- und Distributionsschicht für datengetriebene Anwendungen. Die Lakehouse-Architektur kombiniert kosteneffizienten Objektspeicher mit transaktionaler Zuverlässigkeit. Das Schichtenmodell reicht von der Speicherschicht mit offenen Formaten über die Metadaten- und Verarbeitungsschicht bis zur API- und Applikationsschicht.

Die Medallion-Struktur ordnet Daten nach Qualität in drei Stufen. Bronze enthält Rohdaten mit vollständiger Historie und minimaler Transformation. Silver enthält bereinigte und standardisierte Daten mit validierten Schemata. Gold enthält geschäftsfertige Datenprodukte mit Metriken und Dimensionen. Diese Trennung macht Qualität nachvollziehbar und ermöglicht ein durchgängiges Data-Lineage-Tracking, wie es der EU AI Act für Hochrisiko-Systeme verlangt.

Praxis: Anwendungsfälle und Roadmap

Konsolidierte Daten ermöglichen vorausschauende Wartung aus Sensor- und Betriebsdaten, eine vereinheitlichte Kundensicht aus Stammdaten und Interaktionen sowie eine dynamische Ressourcenplanung aus Auftrags- und Kapazitätsdaten. Die Einführung folgt vier Schritten:

1. Assessment und Design: Landschaftsanalyse, Use-Case-Priorisierung und Architektur-Blueprint.
2. Pilot: Kerninfrastruktur, ausgewählte Anbindungen und Wertnachweis.
3. Rollout: Integrationsskalierung, Deployment, Schulung und Betriebsübergang.
4. Optimierung: Monitoring, Performance-Tuning und Erweiterung um weitere Use Cases.

Praxis: drei Anwendungsfälle im Detail

Bei der vorausschauenden Wartung verbindet der Data Hub Sensor- und Betriebsdaten und ermöglicht Ausfallvorhersagen, die ungeplante Stillstände reduzieren. Bei der vereinheitlichten Kundensicht führt er Stammdaten, Interaktionen und Service-Vorgänge zusammen und verbessert die Grundlage für Vertrieb und Bindung. Bei der Ressourcenplanung verknüpft er Auftrags- und Kapazitätsdaten und stützt die Personal- und Materialprognose.

Allen drei Fällen ist gemeinsam, dass sie ohne konsolidierte Daten nicht funktionieren. Der Wert entsteht nicht im einzelnen Modell, sondern in der gemeinsamen Datenbasis, auf die alle drei Anwendungen zugreifen.

Die Reihenfolge der Anwendungsfälle folgt dem Wert und der Datenreife. Sinnvoll ist, mit dem Fall zu beginnen, dessen Daten am saubersten vorliegen und dessen Nutzen am klarsten messbar ist. Dieser erste Fall liefert den Wertnachweis, der die Investition in die weiteren Fälle trägt, und etabliert die Muster für deren Anbindung.

Warum Bitkom 2025 Data Governance zur Priorität erklärt

Der Bitkom-Bericht Daten als Wirtschaftsgut 2025 zeigt, dass Organisationen in Deutschland Datenpotenziale systematisch unterschätzen: Weniger als 30 Prozent der erhobenen Betriebsdaten werden aktiv für Entscheidungen genutzt. Als Hauptursache nennt der Bericht fehlende Governance-Strukturen, nicht fehlende Technologie. Dieser Befund ergänzt die Gartner-Prognose um eine deutsche Perspektive: Die Herausforderung ist nicht, Daten zu erzeugen, sondern sie governiert und nutzbar zu machen.

Bitkom empfiehlt für den Mittelstand eine gestaffelte Data-Governance-Strategie, die mit einer Bestandsaufnahme der vorhandenen Datenquellen beginnt, dann Verantwortlichkeiten definiert und schließlich technische Integrationsschichten aufbaut. Diese Reihenfolge entspricht exakt dem hier beschriebenen Ansatz: Architektur und Governance vor Modell und Anwendung.

Data Hub und ISO 42001: Governance-Anforderungen an Daten

Die ISO 42001 enthält spezifische Anforderungen an Daten, die für KI-Systeme verwendet werden. Abschnitt 8.4 verlangt, dass Organisationen die Herkunft, Qualität und Vollständigkeit der Trainingsdaten sowie der für den Betrieb verwendeten Daten dokumentieren und kontrollieren. Ein Data Hub mit Medallion-Architektur und durchgängigem Data-Lineage-Tracking erfüllt diese Anforderungen strukturell, weil jeder Datenpunkt von der Bronze-Schicht bis zum Gold-Produkt nachvollziehbar ist.

Wer einen Data Hub aufbaut, schafft damit gleichzeitig die technische Grundlage für ISO-42001-Konformität und EU-AI-Act-Compliance. Die drei Investitionen konvergieren auf dieselbe Infrastruktur. Das senkt die Gesamtkosten der Governance und verhindert, dass separate Datenprojekte für regulatorische Zwecke nachträglich aufgesetzt werden müssen.

Datenprodukte statt Datenprojekte

Ein konzeptioneller Wandel, der sich in der Praxis als wirksam erweist, ist die Betrachtung von Daten als Produkte statt als Projekte. Ein Datenprojekt endet, wenn die Aufgabe abgeschlossen ist. Ein Datenprodukt hat einen Owner, eine dokumentierte Schnittstelle, Qualitätszusagen und eine Versionierung, die es über seinen ersten Einsatz hinaus nutzbar macht.

Der Data-Mesh-Ansatz, der von Zhamak Dehghani systematisiert wurde, überträgt Produktmanagement-Denken auf Daten. Jede Domäne der Organisation ist Eigentümerin ihrer Datenprodukte und verantwortlich für Qualität und Bereitstellung. Der Data Hub in einer Lakehouse-Architektur ist die technische Plattform, auf der diese domänengebundenen Datenprodukte konsistent zugreifbar gemacht werden. Die Governance bleibt dezentral bei den Domänen, die Integration zentral im Hub.

Wirtschaftlichkeit: Total Cost of Integration senken

Eine der am häufigsten übersehenen Kennzahlen bei Dateninvestitionen ist die Total Cost of Integration: die Gesamtkosten aller Integrationsbeziehungen über ihren gesamten Lebenszyklus. In einer gewachsenen IT-Landschaft ohne zentrale Integrationsschicht wächst diese Kennzahl überproportional mit jeder neuen Anwendung, weil jede neue Integration eine eigene Wartungslast erzeugt.

Ein Data Hub amortisiert sich ab einer bestimmten Anzahl von Anwendungen, die auf dieselben Datenquellen zugreifen. Für den Mittelstand liegt dieser Break-even typischerweise bei drei bis fünf Anwendungen, die dieselben Stammdaten benötigen. Wer mehr Anwendungen plant oder bereits betreibt, zahlt ohne Hub dauerhaft für redundante Integrationen und deren Fehlerbehebung.

Wirkung: Voraussetzung statt Option

Ein Data Hub ist die strategische Grundlage für KI-Initiativen, nicht eine Erweiterung am Rand. Die Lakehouse-Architektur balanciert Kosteneffizienz, Skalierbarkeit und Governance und schafft die Basis für datengetriebene Wertschöpfung. Vor dem Hintergrund der Gartner-Prognose ist die Investition in die Datenbasis die Bedingung dafür, dass ein KI-Projekt überhaupt den Betrieb erreicht.

Dieser Beitrag ordnet sich der abamix-Service-Linie Foundation zu und verbindet sie mit dem PowerSkill Workflow Automation. Die methodische Grundlage bildet das MOTIVE Framework.

Real-Time versus Batch: wann welche Integrationslogik gilt

Eine der häufigsten Fehlentscheidungen beim Data-Hub-Aufbau ist die Wahl der Integrationsfrequenz. Nicht jeder Use Case braucht Echtzeit-Daten, und Echtzeit-Pipelines sind deutlich teurer in Aufbau und Betrieb als Batch-Pipelines. Ein Prognosemodell für die Wochenplanung benötigt Tagesdaten, keine Sekunden-Streams. Ein Qualitätskontrollsystem an einer Produktionslinie hingegen benötigt tatsächlich Millisekunden-Latenz. Wer diese Unterscheidung nicht trifft und alle Daten über eine Echtzeit-Pipeline zieht, zahlt für Kapazität, die die meisten Use Cases nicht brauchen, und erhöht die Betriebskomplexität unnötig.

Die Faustformel für die Frequenzentscheidung lautet: Welche Zeitverzögerung beim Datenzugang führt zu einer messbaren Verschlechterung der Entscheidungsqualität? Liegt die Antwort bei Stunden oder Tagen, reicht Batch. Liegt sie bei Minuten oder Sekunden, ist Near-Realtime via Change Data Capture sinnvoll. Liegt sie bei Millisekunden, ist ein eigenes Echtzeit-Streaming-System erforderlich, das separat ausgewiesen werden sollte. Diese Entscheidung gehört in die Assessment-Phase des Data-Hub-Aufbaus und hat erhebliche Konsequenzen für das Kostenmodell.

Migration ohne Betriebsunterbrechung: das Strangler-Fig-Muster

Mittelständische Organisationen können ihren Betrieb nicht unterbrechen, um eine neue Datenarchitektur einzuführen. Das Strangler-Fig-Muster, aus der Softwarearchitektur bekannt, überträgt sich direkt auf die Datenmigration: Die neue Integrationsschicht wird parallel zum bestehenden System aufgebaut. Neue Anwendungen werden von Beginn an am Data Hub angebunden. Bestehende Anwendungen werden schrittweise migriert, wenn ihre Anbindungslogik ohnehin überarbeitet wird. Das Altsystem bleibt aktiv, bis alle relevanten Anwendungen auf den Hub umgestellt sind, und wird dann abgelöst.

Dieses Vorgehen verhindert das Risiko einer Großmigration, die den Betrieb gefährdet, und ermöglicht schnelle erste Werterzielung: Der erste Use Case, der am Hub läuft, liefert seinen Nutzen, während der Rest der Migration noch läuft. McKinsey beschreibt diese inkrementelle Vorgehensweise als eines der charakteristischen Merkmale von High Performern: Sie pilotieren in begrenztem Umfang, beweisen den Wert und skalieren auf Basis des Nachweises, statt den gesamten Umbau zu riskieren.

Master Data Management: die Basis für alle Use Cases

Alle KI-Anwendungen, die mehrere Quellsysteme nutzen, sind auf ein funktionsfähiges Master Data Management (MDM) angewiesen. Ohne MDM haben dieselben Entitäten, etwa Kunden, Produkte oder Lieferanten, in verschiedenen Systemen verschiedene IDs, was Zusammenführungen unzuverlässig macht. Ein Kundenmodell, das Stammdaten aus dem CRM mit Transaktionen aus dem ERP verbindet, produziert Duplikate, Lücken und Fehlzuordnungen, wenn kein goldener Datensatz pro Entität existiert.

MDM muss nicht vollständig sein, bevor der erste Use Case startet. Es muss ausreichend sein für die Entitäten, die der erste Use Case benötigt. Für eine Kundenanalyse reicht die Konsolidierung der Kundenstammdaten. Für eine Lieferkettenbewertung reicht die Konsolidierung der Lieferantendaten. Der praktische Ansatz ist Entity-Resolution für den Use Case, nicht umfassendes Enterprise-MDM, das Jahre dauert und hohe Investitionen erfordert. Dieser Fokus ist eine der wirksamsten Maßnahmen, um die Zeit bis zum ersten produktiven Use Case zu verkürzen, ohne die langfristige Architekturvision zu kompromittieren.

Monitoring und Betriebskontinuität: der Data Hub nach dem Go-Live

Ein Data Hub ist kein Projekt, das nach dem Go-Live abgeschlossen ist. Er ist eine Infrastrukturkomponente, die laufenden Betrieb, Monitoring und Weiterentwicklung erfordert. Die häufigsten Betriebsprobleme sind Schemadrift, also Änderungen an Quellsystemstrukturen, die ohne Ankündigung auftreten und Pipelines brechen; Volumenanomalien, also unerwartete Datenmengen, die Verarbeitungskapazitäten überlasten; und Qualitätsdrift, also schleichende Verschlechterung der Eingangsqualität, die sich in fehlerhaften Ausgaben der Anwendungen manifestiert.

Für den Mittelstand empfiehlt sich ein schlankes Monitoring-Setup, das diese drei Risiken abdeckt, ohne umfangreiche Observability-Infrastruktur aufzubauen: automatisierte Schema-Tests bei jeder Pipeline-Ausführung, Volumen-Alerting mit Schwellenwerten und ein täglicher Qualitäts-Summarybericht für die definierten kritischen Felder. Dieses Setup ist mit modernen Datenpipeline-Werkzeugen in wenigen Tagen konfigurierbar und liefert den Betriebsnachweis, den der EU AI Act für die Überwachung von KI-Systemen zunehmend einfordert. Bitkom empfiehlt in seinem Leitfaden zur Datensicherheit 2025, Monitoring und Logging von Datenpipelines als Standard-Bestandteil jedes Dateninvestitionsvorhabens zu behandeln, nicht als optionale Ergänzung.

Skalierbarkeit planen: von drei auf dreißig Quellen

Ein häufiger Planungsfehler beim Data-Hub-Aufbau ist, die Architektur auf den ersten Use Case zuzuschneiden, ohne die spätere Skalierung zu berücksichtigen. Eine Architektur, die für drei Quellsysteme ausgelegt wurde, kann bei zehn Quellen unter Kapazitätsdruck geraten, wenn sie nicht auf horizontale Skalierung ausgerichtet wurde. Lakehouse-Architekturen auf der Basis von Objektspeicher lösen dieses Problem strukturell, weil Speicher und Compute voneinander getrennt sind. Die Speicherkapazität wächst nahezu unbegrenzt und linear mit dem Datenvolumen. Die Rechenkapazität für Verarbeitungsschritte wird unabhängig davon skaliert, und zwar nur dann, wenn ein konkreter Use Case sie benötigt. Diese Trennung macht die Kostenstruktur vorhersehbar und verhindert, dass eine zu eng geplante Infrastruktur in einem Jahr zurückgebaut werden muss.

Für die Architekturplanung empfiehlt Gartner, die Kapazitätsplanung von Anfang an auf das Drei-Jahres-Ziel auszurichten, statt nur die erste Ausbaustufe zu dimensionieren. Das bedeutet nicht, von Beginn an das volle System aufzubauen, sondern die Architektur so zu entwerfen, dass spätere Erweiterungen ohne Umbau der Grundstruktur möglich sind. Für den Mittelstand sind das in der Praxis vor allem drei Fragen: Können zusätzliche Quellsysteme ohne Reengineering angebunden werden? Kann die Verarbeitungskapazität ohne Architekturänderung erhöht werden? Und bleibt die Latenz für bestehende Use Cases stabil, wenn neue Use Cases hinzukommen? Wer diese drei Fragen beim Architekturdesign stellt und beantwortet, baut ein Fundament, das die KI-Initiative über mehrere Zyklen trägt.

Die Investition in einen Data Hub ist damit eine Entscheidung über die Reihenfolge. Wer zuerst die gemeinsame Datenbasis schafft, kann anschließend mehrere Anwendungsfälle auf demselben Fundament umsetzen, ohne für jeden eine eigene Integration zu bauen. Der anfängliche Aufwand zahlt sich über die Wiederverwendbarkeit aus, je mehr Anwendungen auf den Hub zugreifen.

Quellen

• McKinsey & Company: The State of AI in 2025 (November 2025), https://www.mckinsey.com/capabilities/quantumblack/our-insights/the-state-of-ai
• Gartner: Prognose zur Aufgabe von KI-Projekten ohne KI-fähige Daten bis 2026, https://www.gartner.com
• Europäische Kommission: AI Act — Datengovernance und Data-Lineage für Hochrisiko-Systeme, https://digital-strategy.ec.europa.eu/en/policies/regulatory-framework-ai
• ISO: ISO/IEC 42001:2023 — Anforderungen an Daten für KI-Systeme (Abschnitt 8.4), https://www.iso.org/standard/81230.html
• Bitkom e.V.: Daten als Wirtschaftsgut 2025, https://www.bitkom.org
• MIT Project NANDA: The GenAI Divide — State of AI in Business 2025 (Juli 2025), https://nanda.media.mit.edu
• Dehghani, Zhamak: Data Mesh — Delivering Data-Driven Value at Scale (O'Reilly, 2022)