Kommentar von Stefan Maxones Data Contracts: So bauen Unternehmen stabile Datenfundamente für KI

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 Dashboards zeigen Werte, das KI-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 ETL-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 BI-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.

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 ML-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.

Kommentar von Stefan Maxones

Künstliche Intelligenz – warum digitale Modernisierung oft am Unterbau scheitert

(ID:50799334)