KOMMENTAR VON STEFAN MAXONES DATA CONTRACTS: SO BAUEN UNTERNEHMEN STABILE
DATENFUNDAMENTE FÜR KI
31.03.2026 Von Stefan Maxones 5 min Lesedauer
KI-Projekte scheitern selten am Modell – häufig an Datenstrukturen, die sich
still verändern. Data Contracts und versionierte Datenmodelle schaffen die
Stabilität, die Analytics und Künstliche Intelligenz (KI) dauerhaft brauchen.
Ein Unternehmen migriert sein ERP-System auf eine neue Plattform. Die
Datenpipelines laufen weiter, die zeigen Werte, das -Modell für die
Absatzprognose liefert Ergebnisse. Erst Wochen später fällt auf, dass die
Prognosen systematisch abweichen. Die Ursache ist unspektakulär: Ein Statusfeld
im Auftragssystem wurde im Zuge der Migration fachlich neu interpretiert.
Technisch korrekt, semantisch verändert. Das Modell hatte auf Basis der alten
Bedeutung trainiert – und produzierte nun Aussagen, die auf einer anderen
Wirklichkeit basierten. Kein Fehler im Modell. Kein Fehler in der Pipeline. Kein
Fehler im Schema. Dennoch war das System nicht mehr verlässlich.
DAS EIGENTLICHE PROBLEM LIEGT TIEFER
Solche Situationen sind in Projekten keine Ausnahme. Sie entstehen nicht durch
technisches Versagen, sondern durch eine strukturelle Lücke in der Art, wie
Datenplattformen heute gebaut werden. Datenmodelle definieren Felder, Typen und
Tabellen. Was sie selten definieren, ist die fachliche Bedeutung hinter diesen
Strukturen – und wie mit ihr umzugehen ist, wenn sie sich verändert.
Das hat lange funktioniert, solange Daten vor allem für Reporting genutzt
wurden. Ein Analyst, der eine Kennzahl in einem Dashboard sieht, kann fragen,
was dahinter steckt. Ein KI-Modell kann das nicht. Es lernt aus dem, was es
bekommt – und es hat keine Möglichkeit zu erkennen, dass sich die Bedeutung
seiner Eingaben verändert hat.
Genau hier beginnt das, was man Semantik-Drift nennen kann: Datenstrukturen
bleiben formal stabil, ihre inhaltliche Bedeutung verschiebt sich schrittweise.
Felder werden anders befüllt. KPIs werden neu berechnet. Quellen ändern ihre
Granularität. Keine dieser Änderungen verursacht einen sichtbaren Fehler –
zusammen untergraben sie die Verlässlichkeit der Systeme, die auf diesen Daten
aufbauen.
WARUM KLASSISCHE BI-ARCHITEKTUR NICHT AUSREICHT
Viele Datenplattformen sind historisch um -Prozesse und Reporting-Schichten
gebaut. Dieses Modell hat eine charakteristische Schwäche: Es bindet fachliches
Wissen implizit in Transformationslogiken. Was ein Feld bedeutet, wie eine
Kennzahl berechnet wird, welches System als führendes System gilt – all das
steckt in Abfragelogiken, Pipeline-Konfigurationen und Kommentaren, die
irgendwann niemand mehr vollständig überblickt.
Solange Daten primär für die menschliche Auswertung genutzt werden, ist das
handhabbar. Analysten kennen den Kontext, fragen nach, interpretieren.
KI-Systeme tun das nicht. Sie benötigen strukturierte, stabile und explizit
definierte Grundlagen – über den gesamten Zeitraum ihres Betriebs.
Das stellt eine Anforderung an die Architektur, die klassische -Modelle nicht
erfüllen: Daten müssen nicht nur vorhanden und technisch korrekt sein, sondern
auch fachlich stabil, nachvollziehbar versioniert und klar verantwortet.
DATA CONTRACTS: DATENPRODUKTE WIE SCHNITTSTELLEN BEHANDELN
In der Softwareentwicklung ist das Problem bekannt. APIs werden nicht einfach
verändert – sie werden versioniert. Abhängige Systeme werden informiert.
Änderungen folgen definierten Prozessen. Das Prinzip dahinter ist einfach: Wer
eine Schnittstelle anbietet, übernimmt Verantwortung für ihre Stabilität.
Data Contracts übertragen dieses Prinzip auf Datenprodukte. Ein Data Contract
ist eine explizite, maschinenlesbare Vereinbarung über die Eigenschaften eines
Datensatzes. Er definiert nicht nur das Schema – also Feldnamen und Typen –
sondern auch die fachliche Semantik, die Versionierung, das verantwortliche Team
und die vereinbarten Qualitätseigenschaften.
Ein einfaches Beispiel: Ein Datensatz enthält das Feld order_status. Im Schema
steht: String, nullable. Das sagt wenig. Ein Data Contract würde ergänzen,
welche Werte zulässig sind, was sie fachlich bedeuten, seit wann diese
Definition gilt und wer bei Änderungen informiert werden muss. Wenn sich die
Bedeutung von order_status verändert – wie im Einstiegsbeispiel –, ist das keine
stille Anpassung mehr, sondern ein versionierter Vorgang mit definierten
Konsequenzen für abhängige Systeme.
Das verändert die Architektur grundlegend. Nicht in der Infrastruktur, sondern
in der Art, wie Verantwortung für Daten organisiert wird.
VERSIONIERUNG ALS STANDARDPROZESS
Der entscheidende Schritt ist, Änderungen an Datenmodellen wie Änderungen an
Software-Schnittstellen zu behandeln. Das bedeutet: Datenmodelle werden nicht
einfach angepasst – sie werden versioniert. Bestehende Konsumenten laufen auf
der alten Version weiter, bis eine Migration geplant und durchgeführt wurde.
Neue Versionen werden angekündigt, dokumentiert und in definierten Zeiträumen
eingeführt.
JETZT NEWSLETTER ABONNIEREN
TÄGLICH DIE WICHTIGSTEN INFOS ZU BIG DATA, ANALYTICS & AI
Geschäftliche E-Mail
Bitte geben Sie eine gültige E-Mailadresse ein.
Abonnieren
Mit Klick auf „Newsletter abonnieren“ erkläre ich mich mit der Verarbeitung und
Nutzung meiner Daten gemäß Einwilligungserklärung (bitte aufklappen für Details)
einverstanden und akzeptiere die . Weitere Informationen finde ich in unserer .
Die Einwilligungserklärung bezieht sich u. a. auf die Zusendung von
redaktionellen Newslettern per E-Mail und auf den Datenabgleich zu
Marketingzwecken mit ausgewählten Werbepartnern (z. B. LinkedIn, Google, Meta).
Aufklappen für Details zu Ihrer Einwilligung
Stand: 08.12.2025
Es ist für uns eine Selbstverständlichkeit, dass wir verantwortungsvoll mit
Ihren personenbezogenen Daten umgehen. Sofern wir personenbezogene Daten von
Ihnen erheben, verarbeiten wir diese unter Beachtung der geltenden
Datenschutzvorschriften. Detaillierte Informationen finden Sie in unserer .
EINWILLIGUNG IN DIE VERWENDUNG VON DATEN ZU WERBEZWECKEN
Ich bin damit einverstanden, dass die Vogel IT-Medien GmbH,
Max-Josef-Metzger-Straße 21, 86157 Augsburg, einschließlich aller mit ihr im
Sinne der §§ 15 ff. AktG verbundenen Unternehmen (im weiteren: Vogel
Communications Group) meine E-Mail-Adresse für die Zusendung von Newslettern und
Werbung nutzt. Auflistungen der jeweils zugehörigen Unternehmen
können abgerufen werden.
Der Newsletterinhalt erstreckt sich dabei auf Produkte und Dienstleistungen
aller zuvor genannten Unternehmen, darunter beispielsweise Fachzeitschriften und
Fachbücher, Veranstaltungen und Messen sowie veranstaltungsbezogene Produkte und
Dienstleistungen, Print- und Digital-Mediaangebote und Services wie weitere
(redaktionelle) Newsletter, Gewinnspiele, Lead-Kampagnen, Marktforschung im
Online- und Offline-Bereich, fachspezifische Webportale und E-Learning-Angebote.
Wenn auch meine persönliche Telefonnummer erhoben wurde, darf diese für die
Unterbreitung von Angeboten der vorgenannten Produkte und Dienstleistungen der
vorgenannten Unternehmen und Marktforschung genutzt werden.
Meine Einwilligung umfasst zudem die Verarbeitung meiner E-Mail-Adresse und
Telefonnummer für den Datenabgleich zu Marketingzwecken mit ausgewählten
Werbepartnern wie z.B. LinkedIN, Google und Meta. Hierfür darf die Vogel
Communications Group die genannten Daten gehasht an Werbepartner übermitteln,
die diese Daten dann nutzen, um feststellen zu können, ob ich ebenfalls Mitglied
auf den besagten Werbepartnerportalen bin. Die Vogel Communications Group nutzt
diese Funktion zu Zwecken des Retargeting (Upselling, Crossselling und
Kundenbindung), der Generierung von sog. Lookalike Audiences zur
Neukundengewinnung und als Ausschlussgrundlage für laufende Werbekampagnen.
Weitere Informationen kann ich dem Abschnitt „“ in der Datenschutzerklärung
entnehmen.
Falls ich im Internet auf Portalen der Vogel Communications Group einschließlich
deren mit ihr im Sinne der §§ 15 ff. AktG verbundenen Unternehmen geschützte
Inhalte abrufe, muss ich mich mit weiteren Daten für den Zugang zu diesen
Inhalten registrieren. Im Gegenzug für diesen gebührenlosen Zugang zu
redaktionellen Inhalten dürfen meine Daten im Sinne dieser Einwilligung für die
hier genannten Zwecke verwendet werden. Dies gilt nicht für den Datenabgleich zu
Marketingzwecken.
Recht auf Widerruf
Mir ist bewusst, dass ich diese Einwilligung jederzeit für die Zukunft
widerrufen kann. Durch meinen Widerruf wird die Rechtmäßigkeit der aufgrund
meiner Einwilligung bis zum Widerruf erfolgten Verarbeitung nicht berührt. Um
meinen Widerruf zu erklären, kann ich als eine Möglichkeit das unter abrufbare
Kontaktformular nutzen. Sofern ich einzelne von mir abonnierte Newsletter nicht
mehr erhalten möchte, kann ich darüber hinaus auch den am Ende eines Newsletters
eingebundenen Abmeldelink anklicken. Weitere Informationen zu meinem
Widerrufsrecht und dessen Ausübung sowie zu den Folgen meines Widerrufs finde
ich in der .
Das klingt nach Mehraufwand – und das ist es kurzfristig auch. Mittelfristig
reduziert es jedoch den deutlich größeren Aufwand, der durch stille Änderungen
entsteht: ungeplante Modellneukalibrierungen, unerklärliche Abweichungen in
Auswertungen, aufwendige Root-Cause-Analysen in komplexen Datenketten.
In Projekten zeigt sich: Der Anteil der Zeit, der für die Nachverfolgung
impliziter Änderungen aufgewendet wird, ist erheblich. Data Contracts machen
diesen Aufwand sichtbar – und damit planbar.
PRAXISFÄLLE: WO DRIFT ENTSTEHT
Semantik-Drift entsteht in sehr unterschiedlichen Kontexten. In der Praxis
lassen sich einige typische Muster beobachten.
* Bei ERP-Migrationen werden Datenfelder technisch übernommen, aber fachlich
neu interpretiert. Das betrifft besonders Statusfelder, Klassifikationen und
Bewegungsarten – genau die Felder, auf denen KI-Modelle für Prognose oder
Anomalieerkennung häufig basieren.
* In Analytics-Plattformen ändern sich KPI-Definitionen im Controlling oder
Vertrieb. Wenn ein Feature eines ML-Modells auf einer solchen Kennzahl
basiert, verändert sich das Modellverhalten – ohne dass ein Fehler
protokolliert wird.
* In industriellen Umgebungen entsteht Drift oft noch früher: in der Messkette
selbst. Ein Sensortausch, eine veränderte Abtastrate oder ein angepasster
Filterparameter im Historian verändern die physikalische Aussagekraft der
Daten, ohne das Schema zu berühren. Für ein KI-Modell bedeutet das faktisch
eine neue Version des Datenprodukts – auch wenn sich im Datensatz formal
nichts verändert hat.
Alle drei Muster haben gemeinsam: Die Änderung war fachlich begründet und
technisch korrekt. Das Problem entstand nicht durch Fehler, sondern durch
fehlende Verträge.
ARCHITEKTURFOLGEN: VON PIPELINES ZU DATENPRODUKTEN
Der Einsatz von Data Contracts verändert, wie Datenplattformen strukturiert
werden. Anstatt Daten als Outputs von Pipelines zu behandeln, werden sie als
Produkte betrachtet – mit klaren Eigenschaften, Verantwortlichkeiten und
Lebenszyklen.
In der Praxis bedeutet das eine Schichtung, bei der zwischen Datenquellen, einer
Integrationsschicht, stabilen Datenprodukten und dem -Layer klar unterschieden
wird. Data Contracts greifen an den Übergängen: Sie definieren, was eine Schicht
der nächsten garantiert – und unter welchen Bedingungen diese Garantie noch
gilt.
Moderne Datenplattformen, ob auf Basis von Cloud-Diensten,
Lakehouse-Architekturen oder hybriden Infrastrukturen, unterstützen dieses
Modell zunehmend technisch. Die eigentliche Herausforderung liegt jedoch selten
in der Toolwahl, sondern in der organisatorischen Verankerung: Data Contracts
erfordern, dass Teams Verantwortung für ihre Datenprodukte übernehmen – und dass
diese Verantwortung in Prozessen und Governance-Strukturen verankert ist.
FAZIT: ARCHITEKTUR ENTSCHEIDET – NICHT DAS MODELL
KI-Systeme sind stabiler als ihr Ruf – wenn das Fundament stimmt. Die meisten
Probleme, die in der Praxis als Modellprobleme behandelt werden, sind
Architekturprobleme. Sie entstehen, weil Datenstrukturen implizit veränderlich
sind, weil Semantik in Transformationslogiken verschwindet und weil niemand
Verantwortung für die Stabilität von Datenprodukten übernimmt.
Data Contracts sind kein neues Tool und kein Framework, das man kaufen kann. Sie
sind ein Architekturprinzip: Daten wie Schnittstellen behandeln, Änderungen wie
Softwareversionen managen und Verantwortung explizit zuweisen.
In modernen Datenarchitekturen sind Datenprodukte letztlich nichts anderes als
APIs — nur dass viele Unternehmen sie noch immer nicht wie APIs behandeln.
WAS IST EIN DATA CONTRACT?
Ein Data Contract ist eine explizite, idealerweise maschinenlesbare Vereinbarung
über die Eigenschaften eines Datenprodukts. Er definiert typischerweise:
- Schema: Felder, Datentypen, Nullable-Regeln
- Semantik: fachliche Bedeutung der Felder und zulässige Wertebereiche
- Version: aktuelle Version, Änderungshistorie, Deprecation-Regeln
- Owner: verantwortliches Team oder System
- SLA: Aktualität, Verfügbarkeit, Qualitätsschwellen
Data Contracts entstammen ursprünglich der API-Entwicklung und werden zunehmend
auf Datenplattformen übertragen. Bekannte Referenzarchitekturen sind das
Data-Mesh-Konzept (Zhamak Dehghani) sowie der Open Data Contract Standard
(ODCS), der eine herstellerneutrale Spezifikation für maschinenlesbare Data
Contracts definiert.
(ID:50799334)