Gerade in Industrieunternehmen zeigt sich diese Herausforderung der Datenbereitstellung besonders deutlich. Daten liegen in ERP-, MES-, PLM-, CRM-, DMS-, SCADA- und Cloud-Systemen, zusätzlich in Dokumenten, Service-Tickets, E-Mails, Zeichnungen, Prüfberichten, Tabellen und im Erfahrungswissen der Mitarbeitenden. Eine Expertenumfrage zur KI in der Fertigungsindustrie beschreibt genau diese Situation: Zwischen Pilotprojekten und breitem Roll-out liegen häufig Datensilos, organisatorische Hürden und fehlende Strategien. Genannt werden als produktive KI-Felder u.a. Predictive Maintenance, Qualitätskontrolle und Produktionsplanung. Damit rückt eine neue Architekturfrage in den Mittelpunkt: Welcher Ansatz macht Unternehmensdaten KI-fähig?
Der Data Layer der Applikationsanbieter
Viele Anbieter klassischer Unternehmenssoftware verfolgen derzeit einen naheliegenden Ansatz: Sie erweitern ERP-, MES-, PLM- oder CRM-Systeme um eine semantische Datenschicht, häufig ergänzt durch Knowledge Graphs, APIs und zunehmend durch das Model Context Protocol, kurz MCP. Die Logik ist nachvollziehbar. In den operativen Systemen liegen Stammdaten, Aufträge, Stücklisten, Maschineninformationen, Kundenhistorien, Qualitätsdaten, Serviceprozesse oder Projektdokumentationen. Wer diese Systeme ohnehin betreibt, kann sie als vertrauenswürdige Quelle für KI-Assistenten und Agenten öffnen. MCP spielt dabei eine wachsende Rolle, weil es Anwendungen ermöglicht, Large Language Models mit externen Datenquellen und Tools zu verbinden. Die MCP-Spezifikation unterscheidet u.a. Prompts, Resources und Tools; Tools sind dabei ausführbare Funktionen, über die ein Modell Informationen abrufen oder Aktionen ausführen kann.
Der Vorteil dieses applikationszentrierten Ansatzes liegt in der Nähe zu bestehenden Geschäftsprozessen. Berechtigungen, Transaktionslogik und Datenmodelle sind oft bereits vorhanden. Der Nachteil ist die Perspektivverengung. Ein ERP-System versteht die Welt anders als ein MES, ein PLM- oder ein Service-System. Für viele KI-Anwendungsfälle reicht jedoch keine einzelne Systemperspektive. Ein Wartungsagent benötigt beispielsweise Maschinenhistorie, Ersatzteilinformationen, Störungstickets, Handbücher, Schichtprotokolle und Erfahrungswissen. Ein Angebotsagent braucht CRM-Daten, Produktvarianten, frühere Angebote, Lieferzeiten, technische Regeln und Kalkulationslogiken. Wer allein auf den Data Layer eines einzelnen Applikationsanbieters setzt, riskiert neue Silos oberhalb der alten Silos.
Zentrale Datenplattformen und Lakehouse-Architekturen
Ein anderer Ansatz ist die zentrale Datenplattform. Daten aus verschiedenen Quellen werden in einem Data Warehouse, Data Lake oder Lakehouse zusammengeführt, bereinigt, transformiert und für Analytics, Reporting, Machine Learning und KI-Anwendungen bereitgestellt.
Lakehouse-Architekturen versuchen, die Vorteile von Data Lakes und Data Warehouses zu verbinden: Sie speichern strukturierte und unstrukturierte Daten in großem Maßstab und stellen zugleich Funktionen für Qualität, Governance, Tabellenformate und analytische Abfragen bereit. Databricks beschreibt das Lakehouse als Architekturansatz, der Data Warehousing, Analyse und Reporting auf einer gemeinsamen Plattform unterstützt.
Der Vorteil liegt in Skalierbarkeit und analytischer Leistungsfähigkeit. Unternehmen können große Datenmengen historisieren, Datenprodukte bereitstellen und Modelle trainieren. Der Nachteil besteht im Aufwand. Daten müssen integriert, bereinigt, modelliert und laufend gepflegt werden. Ohne klare fachliche Verantwortung entstehen große Plattformprogramme, die technisch leistungsfähig sind, aber in den Geschäftsprozessen zu wenig Wirkung entfalten.
Daten verbinden, ohne alles zu verschieben
Data-Fabric-Ansätze versuchen, Datenzugriff und Governance über verteilte Landschaften hinweg zu vereinfachen. Daten müssen nicht zwingend an einen Ort kopiert werden. Stattdessen entsteht eine integrierende Schicht, die Kataloge, Metadaten, Zugriffskontrolle, Integration, Virtualisierung und Governance verbindet.
IBM beschreibt Data Fabric als Architekturansatz, der Datenzugriff und Data Governance über hybride Multi-Cloud-Landschaften hinweg vereinfachen soll. Eine Data Fabric vermeidet den Zwang, alle Daten in einen einzigen Speicher zu bewegen, und sucht eine Balance zwischen zentralen und dezentralen Elementen. Zu den Kernfähigkeiten gehören u.a. Knowledge Catalog, automatisierte Datenanreicherung, Self-Service-Zugriff, Smart Integration, Governance, Security und Lifecycle-Management.
Data Fabric ist besonders interessant für Unternehmen mit heterogenen Bestandslandschaften. Sie müssen nicht erst alle Systeme ablösen oder alle Daten migrieren. Allerdings löst auch eine Data Fabric nicht automatisch das Semantikproblem. Die technische Verbindung von Datenquellen ist nur der erste Schritt. Entscheidend bleibt, ob Fachbegriffe, Verantwortlichkeiten, Datenqualität, Prozessbezug und Nutzungsrechte geklärt sind.
Datenprodukte statt zentrale Datenhoheit
Data Mesh setzt weniger bei Technologie als bei Organisation an. Fachdomänen sollen Daten als Produkte verantworten. Statt dass eine zentrale Datenorganisation alle Daten sammelt, modelliert und bereitstellt, übernehmen die Fachbereiche Verantwortung für ihre Datenprodukte. Eine zentrale Plattform unterstützt mit Standards, Governance und Self-Service-Infrastruktur.
AWS beschreibt Data Mesh als Paradigma zur Datenverwaltung, bei dem Data Lakes nicht mehr zwingend das Zentrum der gesamten Architektur bilden, sondern als Teil einer Self-Service-Infrastruktur oder zur Umsetzung von Datenprodukten genutzt werden können. AWS unterscheidet Data Mesh auch von Data Fabric: Data Fabric arbeitet eher als Technologieschicht über bestehender Infrastruktur, während Data Mesh stärker organisatorische Änderungen in Richtung eines Serve-and-Pull-Modells verlangt.
Der Vorteil liegt in fachlicher Nähe. Wer die Daten erzeugt und nutzt, übernimmt Verantwortung für Qualität, Bedeutung und Nutzbarkeit. Der Nachteil ist der organisatorische Aufwand. Data Mesh benötigt Data Product Owner, Standards, Governance, Kulturwandel und klare Anreizsysteme. In großen Unternehmen kann das sehr leistungsfähig sein; in kleineren Organisationen kann es überdimensioniert wirken.
Schneller Zugang zu unstrukturiertem Wissen
Für Generative AI und Agentic AI hat sich ein weiterer Ansatz etabliert: Retrieval-Augmented Generation, kurz RAG. Dabei werden Unternehmensdokumente, Wissensdatenbanken, Wikis, Tickets, Handbücher oder andere Quellen so erschlossen, dass ein KI-System relevante Inhalte suchen, auswerten und in Antworten einbeziehen kann. Der Vorteil ist die schnelle Nutzbarkeit von unstrukturiertem Wissen.
Gerade im Maschinenbau, in Serviceorganisationen, Versicherungen, Gesundheitseinrichtungen oder Behörden liegt ein großer Teil des handlungsrelevanten Wissens nicht in Datenbanken, sondern in Dokumenten, Prozessen, E-Mails und Erfahrungsregeln. Enterprise-Agentic-AI-Leitfäden betonen daher, dass führende Unternehmen nicht mit großen autonomen Agentensystemen beginnen sollten, sondern mit fokussierten, messbaren Use Cases, Datenbereitschaft, Retrieval und Governance.
RAG ist jedoch kein Ersatz für Datenmanagement. Ohne Berechtigungskonzepte, Quellenbewertung, Aktualitätsprüfung, Metadaten, Versionierung und Antwortvalidierung drohen falsche oder nicht nachvollziehbare Ergebnisse. Für produktive KI-Anwendungen muss aus einem einfachen Dokumentenindex ein kontrollierter Knowledge Layer werden.
Event-driven Architecture und Operational Data Plane
In der Fertigung, Logistik, Energie oder bei vernetzten Produkten spielt Echtzeit eine besondere Rolle. Sensoren, Maschinen, Steuerungen, Edge-Systeme und Cloud-Plattformen erzeugen kontinuierlich Datenströme. Event-driven Architectures und Operational Data Planes machen solche Ereignisse nutzbar: nicht nur für Dashboards, sondern für vorausschauende Wartung, Qualitätsabweichungen, Produktionssteuerung oder automatisierte Reaktionen.
Dieser Ansatz ist stark, wenn KI zeitnah in operative Abläufe eingreifen soll. Er ist aber technisch anspruchsvoll. Echtzeitdaten benötigen saubere Schnittstellen, Monitoring, Security, robuste Betriebsmodelle und klare Entscheidungen darüber, wann eine KI nur empfiehlt und wann sie Aktionen auslösen darf.
Daten-Governance über Unternehmensgrenzen hinweg
Datenräume unterscheiden sich von den bisher genannten Ansätzen. Sie sind keine interne Datenplattform und kein Ersatz für ERP, MES, PLM, Data Lake oder Knowledge Graph. Ihre Stärke liegt im kontrollierten Datenaustausch zwischen rechtlich eigenständigen Organisationen.
In Datenräumen geht es um Identität, Verträge, Nutzungsbedingungen, Policies, Kataloge, Souveränität und Nachvollziehbarkeit. Die International Data Spaces Association beschreibt im Kontext des Dataspace Connectors Usage Policies, die Rechte, Verbote und Pflichten enthalten können. Technisch werden solche Policies gelesen, klassifiziert, geprüft und zur Laufzeit durchgesetzt.
Datenräume werden besonders relevant, wenn Daten über Unternehmensgrenzen hinweg genutzt werden: in Lieferketten, bei Manufacturing-X, Factory-X, Catena-X, digitalen Produktpässen, ESG-Nachweisen, Qualitäts- und Zertifikatsdaten oder bei gemeinsamen Service- und Wartungsmodellen zwischen Hersteller, Betreiber und Zulieferer.
Für KI und Agentic AI sind Datenräume perspektivisch bedeutsam, weil Agenten künftig nicht nur interne Daten nutzen, sondern auch externe Datenprodukte finden, Nutzungsbedingungen interpretieren, Berechtigungen prüfen und Transaktionen vorbereiten müssen. Allerdings sind Datenräume für rein interne KI-Anwendungen meist nicht der schnellste Einstieg. Sie entfalten ihren Wert vor allem dort, wo Vertrauen, Nachvollziehbarkeit und Regeln zwischen mehreren Organisationen erforderlich sind.
Die Ansätze im Vergleich
Nicht das Modell ist der größte Kostentreiber
Die Kosten unterscheiden sich je nach Ansatz erheblich. Ein einfacher RAG-Pilot auf freigegebenen Dokumenten kann vergleichsweise schnell starten. Eine unternehmensweite Data-Mesh- oder Lakehouse-Strategie kann dagegen eine mehrjährige Implementierung werden. Datenräume verursachen neben Technologieaufwand auch Kosten für Standardisierung, Verträge, Partner-Onboarding, Zertifizierung und Governance.
Die Kosten einer KI-Anwendung entstehen also nicht nur durch Modellnutzung und Lizenzen. Wesentliche Kostenfaktoren sind Datenaufbereitung, Schnittstellen, Datenqualität, Metadaten, Security, Berechtigungen, Testing, Monitoring, Change Management und Betrieb. Auch Gartner weist in seiner AI-Hype-Cycle-Übersicht darauf hin, dass der Fokus von GenAI-Hype zu Grundlagen wie AI-ready Data, AI Agents, AI Engineering und ModelOps wandert. Ohne AI-ready Data und solide Engineering-Grundlagen wachse die Fragilität schneller als der Wert.
Eine scheinbar günstige KI-Erweiterung in einer Bestandssoftware kann demnach teuer werden, wenn sie zu Lock-in, begrenzter Skalierung oder parallelen KI-Applikationen führt. Umgekehrt kann eine teurere Plattforminvestition wirtschaftlich sinnvoll sein, wenn sie mehrere Use Cases trägt, Governance zentralisiert und Datenqualität dauerhaft verbessert.
Welcher Ansatz setzt sich durch?
Wahrscheinlich setzt sich kein einzelner Ansatz durch. Zu unterschiedlich sind Unternehmensgrößen, Branchen, Datenlandschaften, regulatorische Anforderungen und Reifegrade. Realistischer ist eine Schichtenarchitektur.
Operative Systeme für ERP, PLM, CRM und MES sowie DMS bleiben wohl bestehen. Darüber entstehen Lakehouse-, Fabric- oder Mesh-Strukturen, abhängig von Unternehmensgröße und Organisation. Ergänzend werden semantische Schichten, Knowledge Graphs, Datenkataloge und RAG-Systeme aufgebaut. Für Agentic AI kommen MCP, APIs, Tool-Governance, Identitäten, Rechte, Audit Trails und Human-in-the-Loop hinzu. Datenräume ergänzen diese Architektur überall dort, wo Daten über Unternehmensgrenzen hinweg geteilt und kontrolliert genutzt werden müssen.
Der entscheidende Wettbewerb findet daher wahrscheinlich nicht zwischen Data Lake, Data Mesh, Knowledge Graph oder Datenraum statt. Entscheidend ist, welcher Ansatz Daten in nutzbaren Kontext verwandelt. KI benötigt nicht nur Zugriff auf Daten, sondern Verständnis für Bedeutung, Qualität, Herkunft, Berechtigung, Zweck und Prozess.
Fazit
Die Zukunft der Datenarchitektur dürfte hybrid sein. Der applikationszentrierte Data Layer der Legacy-Anbieter könnte eine wichtige Rolle spielen, weil er nah an Transaktionen und Prozessen liegt. Zentrale Plattformen bleiben wohl wichtig für Analytics und Machine Learning. Data Fabric hilft, heterogene Landschaften zu verbinden. Data Mesh stärkt fachliche Verantwortung. RAG und Knowledge Layer machen unstrukturiertes Wissen oft schnell nutzbar. Datenräume unterstützen dabei, Vertrauen über Unternehmensgrenzen hinweg. Der Maßstab für die passende Architektur lautet daher nicht: Welcher Ansatz ist der modernste, sondern welcher Ansatz macht einen konkreten Geschäftsprozess KI-fähig?
Ein praktikabler Weg für Unternehmen bleibt: mit wertvollen Use Cases beginnen, die dafür notwendigen Daten, Dokumente und Wissensquellen identifizieren, Berechtigungen und Governance klären, eine tragfähige Kontextschicht aufbauen und erst dann skalieren. Denn unabhängig von der Achitektur des Datenspeichers, dürften diejenigen KI-Systeme am wirtschaftlichsten sein, die Daten, Wissen und Prozesse am effektivsten in kontrollierten Handlungskontext für Menschen und KI-Agenten übersetzt.
