Ihre Daten sind der Vorsprung: Warum Unternehmen eine eigene digitale Schicht brauchen

Den meisten Unternehmen fehlen nicht die Daten. Das Problem ist, dass dieselben Daten an fünf Stellen liegen und an jeder Stelle etwas anders interpretiert werden.

Der Kunde steht im CRM, die Bestellung im ERP, das Angebot liegt als PDF vor, eine wichtige Notiz befindet sich in einer E-Mail und der letzte tatsächliche Status in einer Excel-Datei bei der Person, die den Prozess seit Jahren zusammenhält. Fragt die Geschäftsführung, wie viel dieser Kunde in diesem Jahr tatsächlich bezahlt hat, braucht die Antwort drei Systeme und einen Mitarbeiter, der weiß, welcher Angabe zu trauen ist.

Das ist kein Problem kleiner Unternehmen. Die zehnte Ausgabe des MuleSoft Connectivity Benchmark unter 1.050 IT-Verantwortlichen in Unternehmen mit mindestens 1.000 Mitarbeitenden nennt einen Durchschnitt von 897 Anwendungen pro Organisation, von denen lediglich 29 Prozent miteinander verbunden sind. Neunzig Prozent der Befragten sagen, dass Datensilos im Unternehmen geschäftliche Probleme verursachen.

Dieser Text geht in die Tiefe einer einzigen Schicht. Die Gesamtkarte der Unternehmensschichten habe ich im Beitrag Wie ich heute ein Unternehmen bauen würde, das keine Armee an Verwaltungskräften braucht beschrieben. Hier geht es ausschließlich um Daten: wer sie besitzt und wo die Wahrheit liegt.

KI ist nur so verlässlich wie die Infrastruktur darunter

Ein Modell kann hervorragend zusammenfassen, klassifizieren oder den nächsten Schritt vorschlagen. Enthalten jedoch zwei Systeme einen unterschiedlichen Preis, einen abweichenden Bestellstatus oder einen doppelten Kundendatensatz, kann die KI nicht bestimmen, welcher Datensatz verbindlich ist. Sie nimmt den, den sie bekommt, oder den, der überzeugender klingt. Beides ist kein Entscheidungskriterium.

Das NIST AI Risk Management Framework 1.0 vom Januar 2023 stellt die Eigenschaft Valid & Reliable, also Gültigkeit und Verlässlichkeit, als Fundament unter die übrigen Eigenschaften vertrauenswürdiger KI und ergänzt, dass Vertrauenswürdigkeit nur so stark ist wie ihre schwächsten Eigenschaften. Ein Modell auf Daten, denen Sie selbst nicht trauen, ist ein Generator für schnellere Fehler.

Ein Unternehmen muss deshalb den Source of Truth für zentrale Entitäten definieren: Kunde, Produkt, Preis, Bestellung, Rechnung, Verfügbarkeit, Benutzer und Berechtigungen. Das ist die Vereinbarung darüber, welches System für eine bestimmte Angabe verbindlich ist und woher die übrigen sie nur lesen. Keine Technologie, eine Entscheidung.

Dass es sich dabei nicht um ein Randthema handelt, zeigt die Untersuchung Salesforce State of Data and Analytics, erhoben im Sommer 2025 und veröffentlicht im November 2025: 84 Prozent der Verantwortlichen für Daten und Analytics sagen, ihre Datenstrategie brauche einen vollständigen Umbau. Sie schätzen zugleich, dass 19 Prozent der Unternehmensdaten in Datensilos liegen oder anderweitig unbrauchbar sind und 26 Prozent nicht vertrauenswürdig.

Wie eine Entscheidung über die verbindliche Quelle aussieht

Für jede Entität sind vier Fragen zu beantworten. Welches System besitzt sie? Wer darf in sie schreiben und über welche Schnittstelle? Was ist ihre eine ID über alle Systeme hinweg? Und wie sieht der Abgleich aus, wenn zwei Datensätze auseinanderlaufen?

Das klingt banal, ist aber meist die schwerste Stunde des Projekts. Ein Modellbeispiel: Den Preis besitzen drei Personen und jede hat in ihrem Kontext recht, der Vertrieb hat eine Ausnahme, der Onlineshop eine Preisliste und die Buchhaltung das, was auf der Rechnung hinausgegangen ist. Wird dieses Gespräch nicht am Tisch geführt, entscheidet es später die Integration. Zufällig und schlecht.

Die Regulierung drückt in dieselbe Richtung. Artikel 10 der EU-Verordnung über künstliche Intelligenz verlangt für Hochrisikosysteme Datensätze, die relevant, hinreichend repräsentativ und so weit wie möglich fehlerfrei sowie im Hinblick auf den beabsichtigten Zweck vollständig sind. Ohne Panikmache: Das gilt erst ab dem 2. Dezember 2027 beziehungsweise ab dem 2. August 2028, je nach Systemtyp, und die meisten unternehmerischen Anwendungen fallen nicht unter hohes Risiko.

Ein gemeinsames Datenmodell vereinfacht das gesamte Ökosystem

Wenn ein Kunde eine eindeutige ID besitzt, eine Bestellung einen klaren Lebenszyklus hat und jedes System weiß, woher es Preis oder Verfügbarkeit liest, werden Integrationen einfacher. Ein Lead von der Website entsteht im CRM, wird angereichert, einem Vertriebsmitarbeiter zugeordnet und später mit Angebot, Bestellung und Rechnung verbunden, ohne dass jemand dasselbe viermal abtippt.

Die Ökonomie dahinter ist schlichte Arithmetik und kein Forschungsergebnis. Wenn Sie Systeme jeweils untereinander verbinden, sind es bei fünf Systemen zehn Verbindungen, bei zehn Systemen fünfundvierzig. Jede Verbindung ist Code, den jemand geschrieben hat, den jemand pflegt und der irgendwann kaputtgeht. Mit gemeinsamem Vokabular und gemeinsamen Identifikatoren ist ein zusätzliches Werkzeug eine einzige Anbindung und nicht neun weitere.

Zhamak Dehghani hat in ihrem im Mai 2019 auf martinfowler.com veröffentlichten Text über Data Mesh die Schwächen zentralisierter Datenplattformen benannt: Die Fähigkeit, alle Daten an einer Stelle zu verarbeiten und in Einklang zu bringen, sinkt mit der wachsenden Zahl an Quellen und Konsumenten, und die Aufteilung der Plattform nach technischen Schritten statt nach fachlichen Domänen erzeugt eine enge Kopplung, bei der eine neue Anforderung eine Änderung über die gesamte Strecke verlangt. Brauchbar ist vor allem ihre Messlatte „Daten als Produkt“: Ein Datensatz soll auffindbar, adressierbar, vertrauenswürdig und abgesichert sein.

Der Anbieter sagt in der Regel nicht das Unangenehme: Die meisten mittelständischen Unternehmen brauchen kein Data Mesh, das ist ein Konzept für Organisationen mit mehreren Datenteams. Ein kleineres Unternehmen holt den Großteil des Werts aus drei günstigen Schritten. Ein sauber aufgesetztes CRM als Eigentümer des Kunden. Eine dokumentierte ID. Ein Export, der sich jederzeit starten lässt.

Eine Schicht kann Kunden, Team und KI gleichzeitig versorgen

Ein sauber konzipierter Daten- und API-Layer, also die Schnittstelle, über die Systeme einander Daten nach vereinbarten Regeln übergeben, kann gleichzeitig Kundenportal, internes Dashboard, Preislogik, Reporting, Website-Personalisierung und KI-Assistent bedienen. Das Unternehmen muss nicht jedes Mal eine neue Insel bauen.

Die Probe ist einfach. Nehmen Sie eine Geschäftsregel, etwa die Berechnung des Rabatts für einen Stammkunden, und zählen Sie, an wie vielen Stellen sie heute hinterlegt ist. Sind es fünf, dann ist jede Änderung fünf Änderungen und fünf Gelegenheiten, dass die Versionen auseinanderlaufen. Ist es eine einzige, dann ist ein neuer Kanal kein Projekt, sondern ein Bildschirm. Genau deshalb lohnt es sich, ein Unternehmen als ein einziges Produkt zu betrachten und nicht als Abteilungen, die sich gegenseitig Dateien zuschicken.

Sicherheit ist Teil des Architekturdesigns

Nicht jeder Benutzer und nicht jeder KI-Prozess braucht Zugriff auf alles. Sensible Daten gehören getrennt, Zugriffe protokolliert und Datenflüsse so entworfen, dass sich im Nachhinein erklären lässt, wer auf was zugegriffen hat und warum.

Das ist keine Meinung, das ist Standard. Die NIST Special Publication 800-207 zur Zero-Trust-Architektur vom August 2020 hält im dritten von sieben Grundsätzen fest, dass Zugriff pro Sitzung und mit den geringsten Privilegien gewährt wird, die zur Erledigung der Aufgabe nötig sind. Der siebte Grundsatz verlangt, so viele Informationen wie möglich über den Zustand von Geräten, Netzwerk und Kommunikation zu sammeln und daraus die Sicherheitslage zu verbessern. Protokollierung ist also keine Schikane, sondern ein Eingangswert für Entscheidungen.

Bei KI ist es zusätzlich sinnvoll zu minimieren, welche Daten das Modell überhaupt erhält. Mehr Kontext bedeutet nicht automatisch ein besseres System. Die OWASP Top 10 for LLM Applications 2025 führen den Abfluss sensibler Informationen gleich an zweiter Stelle und empfehlen Datenbereinigung, strenge Zugriffskontrollen nach dem Prinzip der geringsten Privilegien und wörtlich die Begrenzung des Modellzugriffs auf externe Datenquellen. In dieselbe Richtung zielt der Grundsatz der Datenminimierung in Artikel 5 DSGVO: Daten sollen dem Zweck angemessen und erheblich sowie auf das notwendige Maß beschränkt sein.

Das sechste Risiko derselben Liste, übermäßige Handlungsvollmacht (Excessive Agency), beschreibt, was bei schnellen Piloten entsteht: Ein Agent erhält mehr Funktionen, Berechtigungen und Freiheit, als er für die Aufgabe braucht. Begrenzen Sie Erweiterungen und deren Berechtigungen auf das Nötigste. Bei Aktionen mit hoher Auswirkung verlangen Sie eine Freigabe durch einen Menschen. Die Autorisierung erzwingen Sie in den nachgelagerten Systemen und nicht im Modell. Das Modell ist keine Sicherheitsgrenze, das Modell ist ein Client.

Das zeigt auch der Cost of a Data Breach Report 2025, durchgeführt vom Ponemon Institute und gesponsert von IBM, mit einer Stichprobe von 600 Organisationen. Dreizehn Prozent von ihnen meldeten eine Kompromittierung ihrer KI-Modelle oder Anwendungen, und von diesen 13 Prozent, nicht von allen Unternehmen, gaben 97 Prozent an, keine Zugriffssteuerung für KI im Einsatz gehabt zu haben. Eine von fünf Organisationen meldete eine Kompromittierung durch Shadow AI, und Unternehmen mit hohem Anteil daran hatten durchschnittliche Kosten, die um 670.000 USD höher lagen als bei Unternehmen mit niedrigem Anteil oder ohne, bei einem globalen Durchschnitt von 4,44 Millionen USD.

Shadow AI entsteht dabei nicht aus Böswilligkeit, sondern dann, wenn der offizielle Weg zu den Daten langsam ist und sich jemand einen schnelleren sucht. Ein Verbot funktioniert nicht, ein besserer offizieller Weg schon.

Wann sich eine eigene Datenschicht nicht lohnt

Eine eigene Datenschicht ist eine Investition mit fixem Aufwand, die nicht jedes Unternehmen braucht. Meine Arbeitsregel, also eine Erfahrungseinschätzung und kein Forschungsergebnis: Schreibt dieselbe Entität nur ein System und lesen die übrigen daraus, muss nichts gebaut werden, es genügt, es aufzuschreiben. Schreiben zwei Systeme hinein und klärt die Differenz gelegentlich ein Mensch von Hand, reicht eine native Integration oder eine Automatisierung ohne Code. Eine eigene Schicht ergibt erst dann Sinn, wenn dieselbe Entität von drei oder mehr Systemen geschrieben wird und wenn das Unternehmen einen Prozess hat, der sich nicht fertig kaufen lässt, weil er sein Wettbewerbsvorteil ist.

Die günstigeren Wege gehören zuerst geprüft. Eines der doppelten Werkzeuge abschalten. Die native Integration einschalten, die in der Lizenz ohnehin bezahlt ist. Eine reine Leseschicht für das Reporting bauen statt einer bidirektionalen Synchronisation, denn die meisten Fragen des Managements sind Lesevorgänge und keine Schreibvorgänge. Weniger bewegliche Teile sind meist die bessere Lösung als eine cleverere Synchronisation, worum es im gesamten Beitrag Ihr Unternehmen braucht nicht mehr Software. Es braucht weniger Chaos geht.

Modelle ändern sich. Die eigene digitale Schicht bleibt

Das beste KI-Modell von heute muss in zwei Jahren nicht mehr das beste sein. Ein SaaS-Anbieter kann Preis, API oder Produktstrategie ändern. Ein Unternehmen mit eigenem Datenmodell, eigener Integrationslogik und eigenen Schnittstellen kann Dienste austauschen, ohne den gesamten Prozess zu zerlegen. Das ist die einzige Verhandlungsposition gegenüber einem Anbieter, die auch ohne Anwalt funktioniert.

Die Regulierung hat hier geholfen. Der europäische Data Act, die Verordnung (EU) 2023/2854, ist am 11. Januar 2024 in Kraft getreten und gilt seit dem 12. September 2025. Nach Angaben der Europäischen Kommission schafft er einen Rahmen, der Kunden erlaubt, Daten mitzunehmen und den Cloud-Anbieter zu wechseln, und untersagt unfaire Vertragsklauseln, die das Teilen von Daten behindern. Der Vertrag gibt Ihnen das Recht zu gehen. Die Architektur entscheidet, was der Weggang kostet.

Den praktischen Eigentumstest lohnt es sich bei jedem neuen Werkzeug vor der Unterschrift zu stellen. Wenn wir es morgen abschalten würden, in welcher Zeit bekommen wir die Daten in einer brauchbaren Struktur heraus? Die Antwort, man könne das nach CSV exportieren, genügt nicht. Die Frage ist, ob im Export die Beziehungen zwischen den Datensätzen, die Änderungshistorie, die Anhänge und die Identifikatoren erhalten bleiben. Ein Werkzeug, das Daten ohne Beziehungen zurückgibt, gibt Ihnen Ihre Daten nicht zurück.

Daraus ergibt sich die Trennlinie. Selbst besitzen lohnt sich beim Datenmodell, bei den Identifikatoren, den Geschäftsregeln, der Integrationslogik und den Schnittstellen. Mieten lässt sich fast alles andere: E-Mail, Buchhaltung, Speicher, Lager, Zahlungsanbieter und die Modelle selbst. Niemand mit Verstand baut heute ein eigenes CRM von null oder schreibt ein eigenes Sprachmodell. Das Ziel ist nicht, Software zu besitzen, sondern die Wahrheit, die diese Software verarbeitet.

Den Vorsprung bei KI wird nicht das Unternehmen mit den meisten Abonnements haben, sondern das Unternehmen, das weiß, wo seine Daten liegen, was sie bedeuten und wie sie sicher durch seine Prozesse fließen.

Eine Datenschicht lässt sich nicht als Position in einer Preisliste bestellen. Sie lässt sich zuerst diagnostizieren: Entitäten, Eigentümer, Datenflüsse und jene Stellen kartieren, an denen die Wahrheit auseinandergeht. Erst aus einer solchen Karte lässt sich sagen, ob das Unternehmen ein Projekt braucht, eine einzelne Integration oder nur ein abgeschaltetes Werkzeug und eine aufgeschriebene Vereinbarung. Die Reihenfolge ist wichtiger als das Budget: zuerst der Prozess, dann das Entfernen des Überflüssigen und ganz zum Schluss die Technologie.

Was Sie mitnehmen sollten

• Bevor Sie das nächste Modell oder Werkzeug kaufen, schreiben Sie auf eine Seite, welches System Kunde, Produkt, Preis, Bestellung und Rechnung besitzt. Einigt sich das Team nicht innerhalb einer Stunde, haben Sie gerade das eigentliche Projekt gefunden.
• Fragen Sie bei jedem neuen Werkzeug vor der Unterschrift, wie Sie die Daten samt Beziehungen und Historie wieder herausbekommen. Der Data Act gibt Ihnen das Recht zu gehen, den Preis des Weggangs bestimmt Ihre Architektur.
• Geben Sie einem KI-Prozess nur die Daten, die er für seine Aufgabe benötigt, und erzwingen Sie die Autorisierung in den Zielsystemen, nicht im Modell. Bei Aktionen mit hoher Auswirkung lassen Sie einen Menschen in der Schleife.
• Schreiben nur ein oder zwei Systeme dieselbe Entität, bauen Sie keine eigene Schicht. Dokumentieren Sie die Verantwortung und schalten Sie die native Integration ein.
• Messen Sie den Erfolg nicht an der Zahl der Integrationen, sondern an der Zeit, in der Ihr Unternehmen eine geschäftlich wichtige Frage verlässlich beantworten kann, ohne eine bestimmte Person fragen zu müssen.