Zum Hauptinhalt springen

The Data Economist Blog (DE) | Etablierung einer Data Inspired & Digital Culture

Governance zu digitalisieren ist keine Option mehr

Wie Data Contracts Datenprodukte maschinenlesbar machen und KI-Systemen den Kontext geben, den sie für verlässliche Entscheidungen brauchen

In den meisten Unternehmen ist Governance ein dokumentarischer Prozess. Qualitätsregeln stehen in Wikis, Verantwortlichkeiten in Organigrammen, Nutzungsbedingungen in PDFs, die kein System automatisch prüft. Für überschaubare Datenlandschaften war dieses Modell pragmatisch. Für die nächste Generation von KI-Systemen ist es strukturell unzureichend: KI-Agenten lesen keine Wikis. Sie benötigen maschinenlesbare Kontextinformation direkt am Datenprodukt, Herkunft, Qualitätsstatus, semantische Definitionen, Zugriffsregeln, Aktualitätsgarantien. Organisationen, die diese Kontextschicht heute aufbauen, investieren in mehr als bessere Dokumentation. Sie schaffen die operative Grundlage für skalierbare KI.

Von zentraler Kontrolle zu verteilter Verantwortung

Klassische Data Governance konzentriert Entscheidungen über Daten bei einem zentralen Team. Ein CDO-nahes Gremium definiert Richtlinien, Data Stewards in den Fachbereichen sollen diese einhalten, ein Datenkatalog dokumentiert, was wo liegt. Dieses Modell funktioniert, solange die Datenlandschaft überschaubar und stabil ist.

In modernen Datenorganisationen, in denen Dutzende Teams täglich neue Datensätze erzeugen und Schemata kontinuierlich weiterentwickeln, stößt die Kapazität jedes zentralen Governance-Teams an strukturelle Grenzen. Zhamak Dehghani, die das Data-Mesh-Konzept geprägt hat, benennt den Kern: Klassische Governance versucht ihren Zweck durch Zentralisierung von Entscheidungen zu erreichen und strebt nach einer globalen, kanonischen Datendarstellung bei minimalem Spielraum für Veränderungen. Diese Starrheit steht im Widerspruch zur Realität dynamischer Datenlandschaften.

Dateninspirierte Organisationen lösen dieses Spannungsfeld, indem sie Governance-Verantwortung in die Domänen verlagern, die die Daten am besten kennen, und gleichzeitig sicherstellen, dass globale Standards automatisiert eingehalten werden. Jedes Domänenteam kennt seine Daten, ihre Herkunft, ihre Grenzen und ihre Konsumenten besser als jede zentrale Einheit. Wird dieses Wissen in einem Data Contract formalisiert, entsteht verlässliche Governance als Eigenschaft des Datenprodukts: prüfbar, versioniert und für alle Konsumenten zugänglich.

Datenprodukte: Metadaten als strategisches Designprinzip

Der Unterschied zwischen einem Datensatz und einem Datenprodukt ist eine strategische Entscheidung, keine technische. Ein Datensatz existiert, weil ein System ihn erzeugt. Ein Datenprodukt existiert, weil eine Domäne entschieden hat, welchen spezifischen Geschäftszweck es für welche Konsumenten erfüllt.

Metadaten sind in diesem Modell kein ergänzender Kommentar, sondern das strukturelle Rückgrat. Sie teilen Konsumenten mit, wofür ein Produkt geeignet ist, wie verlässlich es ist und unter welchen Bedingungen es genutzt werden darf. Drei Beispiele zeigen die Tragweite: Eine Logistikdomäne stellt Emissionsdaten ihrer Transportflotte nicht als Rohdatensatz bereit, sondern als nach CSRD-Anforderungen strukturiertes Datenprodukt mit zertifiziertem Qualitätsstatus und semantisch definierten Feldern. Das ESG-Reporting-Team konsumiert es direkt, ohne manuelle Aufbereitung. Eine Customer-Experience-Domäne stellt kuratierte Kundensignale als „Customer Churn Signals" bereit, inklusive Qualitätsgarantien und Service Level Agreement zur Aktualisierungsfrequenz. KI-Agenten konsumieren dieses Produkt auf Basis seines Data Contracts, ohne die CRM-Rohdaten interpretieren zu müssen. Eine Finance-Domäne stellt einen IFRS-konformen „Financial Closing"-Datensatz bereit, dessen Qualitätsstatus Abschlussprüfer und Controlling gleichermaßen nutzen können, ohne separate Abstimmungsprozesse.

Das gemeinsame Muster: Datenprodukte mit klaren Metadaten ermöglichen autonomes Onboarding. Konsumenten, ob Menschen oder Maschinen, finden alle notwendigen Informationen im Produkt selbst.

Der Data Contract: Governance, die sich selbst durchsetzt

Ein Data Contract ist ein maschinenlesbares Dokument, das die Spielregeln für ein Datenprodukt direkt bei diesem Datenprodukt hinterlegt. Die präziseste Analogie liefert die Softwareentwicklung: APIs haben implizites Schnittstellenwissen in explizite, maschinenlesbare Spezifikationen überführt. Ein Data Contract überträgt dieses Prinzip auf Daten. Er ist die Schnittstellenbeschreibung eines Datenprodukts.

Der Open Data Contract Standard v3 (ODCS v3), entwickelt unter der Linux Foundation AI & Data als offener, herstellerunabhängiger Standard, definiert bis zu elf Komponenten: Fundamentals mit Zweck und Nutzungskontext, Schema und Datenstruktur, Data Quality mit ausführbaren Qualitätsregeln, Team und Verantwortlichkeiten, Terms of Use, Service Level Agreement zu Aktualität und Verfügbarkeit, Security und Zugriffsrechte, Infrastructure, Pricing, Business Rules und Custom Properties.

Was den Standard operativ wirkungsvoll macht, ist die Verbindung von Spezifikation und Ausführung. Das Data Contract CLI, eine Open-Source-Referenzimplementierung, leitet aus einem einzigen YAML-Dokument automatisch Qualitätstests ab, befüllt Datenkataloge, provisioniert Infrastrukturkomponenten und erzeugt Compliance-Nachweise. Qualitätsregeln sind nicht beschrieben, sondern als ausführbare Prüfbedingungen hinterlegt: testbar bei jedem Pipeline-Lauf, bei jedem Schema-Update, bei jeder Änderung am Datenprodukt. Governance vollzieht sich als automatisierte Steuerung, nicht als nachgelagerter Prüfprozess.

Für regulatorische Anforderungen aus DSGVO und EU AI Act entstehen Nachweise als automatisches Betriebsprodukt. Schema-Änderungen werden im Pull-Request-Workflow gegen bestehende Konsumenten-Vereinbarungen geprüft, bevor sie in Produktion gelangen. Was bisher Wochen der Abstimmung erforderte, entsteht als versionierbares, testbares Artefakt.

Metadaten als KI-Kontext: Die entscheidende Kontextschicht

Nahezu 78 Prozent der Unternehmen setzen Generative KI bereits in mindestens einer Geschäftsfunktion ein. Gleichzeitig berichten mehr als 80 Prozent, dass ihre KI-Initiativen keinen messbaren Ergebnisbeitrag leisten. McKinsey bezeichnet diesen Widerspruch als das GenAI-Paradox. Die strukturelle Ursache liegt in der Datenbereitschaft: Unternehmen investieren in Modelle und Orchestrierungsschichten, während die Daten, auf denen KI-Systeme operieren sollen, ohne klare Semantik, ohne dokumentierte Herkunft und ohne maschinenlesbare Qualitätsgarantien vorliegen. Gartner benennt fehlende GenAI-fähige Daten als den häufigsten Grund für gescheiterte KI-Deployments.

KI-Agenten, autonome Systeme, die Aufgaben selbstständig planen und ausführen, arbeiten in zwei grundlegenden Modi: Wissensabruf und Handlung. Für beide ist nicht nur die Qualität der Daten entscheidend, sondern der Kontext, der ihnen Bedeutung verleiht.

Im Abruf-Modus nutzen Agenten Retrieval-Augmented Generation (RAG): Bei jeder Anfrage durchsuchen sie einen bereitgestellten Wissenskorpus und binden relevante Informationen als Kontext ein. Die Präzision dieser Methode hängt direkt davon ab, ob indexierte Datenprodukte Metadaten mitführen, die dem Agenten helfen zu verstehen, welche Quelle für welche Anfrage relevant und vertrauenswürdig ist. Ein Data Contract liefert genau diese Metadaten: Zweck, Aktualität, Qualitätsstatus, Zugriffsregeln und autoritative Definitionen. Ein RAG-System, das auf Data-Contract-beschriebene Datenprodukte zugreift, weiß, welcher Quelle wie viel Vertrauen zuzumessen ist, und produziert entsprechend verlässlichere Antworten.

Das Model Context Protocol (MCP), das sich 2025 als Standard für KI-native Schnittstellen etabliert hat, definiert, wie ein Agent auf eine Datenquelle zugreift. Der Data Contract definiert, was er dort vorfindet und unter welchen Bedingungen er es nutzen darf. Beide zusammen bilden die vollständige Schnittstellenbeschreibung eines Datenprodukts für das Agenten-Ökosystem. Ein Datenprodukt mit ODCS-Contract ist für einen KI-Agenten das, was eine API-Spezifikation für einen Softwareentwickler ist: die maschinenlesbare Grundlage, auf der er eigenständig handeln kann.

Die Skalierbarkeit eines KI-Systems hängt direkt von der Vollständigkeit dieser Kontextschicht ab. Ein AI Operating System, das zehn Agenten orchestriert, kommt mit informeller Konfiguration noch aus. Wenn dasselbe System hundert Agenten über Dutzende Domänen auf Hunderte von Datenprodukten koordiniert, wird informelle Konfiguration zum Engpass. Nur Datenprodukte, die ihre eigene Kontextinformation mitführen, können von einem AI OS autonom entdeckt, bewertet und orchestriert werden. Data Contracts sind deshalb keine Ergänzung zur KI-Strategie, sondern ihre operative Voraussetzung.

Die Qualitätsstufen dateninspirierter Architekturen, Raw, Kuratiert und Zertifiziert, existieren zunächst als organisatorisches Konzept. Ein KI-Agent, der autonom entscheiden soll, welche Stufe für welche Aufgabe geeignet ist, benötigt diese Information in maschinenlesbarer Form. Der Data Contract kodifiziert diesen Qualitätsstatus so, dass das AI Operating System ihn lesen, auswerten und für Aufgaben-Routing-Entscheidungen verwenden kann. Ein Agent, der eine regulatorische Analyse erstellt, wird auf Zertifiziert-Daten geroutet. Ein Agent, der Echtzeit-Monitoring betreibt, erhält den Near-Real-Time-Stream aus der Kuratiert-Stufe. Diese Steuerung setzt voraus, dass jedes Datenprodukt seinen Qualitätsstatus im Contract dokumentiert.

Strategische Handlungsempfehlungen

Was Unternehmen jetzt konkret angehen müssen, lässt sich in vier Prioritäten fassen.

Quellsystem-Verantwortung verankern. Die verlässlichsten Data Contracts entstehen in den Teams, die die Daten täglich erzeugen. Sie kennen Entstehungsbedingungen, Ausnahmefälle und Grenzen besser als jede nachgelagerte Einheit. Datenproduzenten-Verantwortung muss dort angesetzt werden, wo Daten tatsächlich entstehen, in ERP-, CRM- und transaktionalen Systemen, nicht erst im Analytics-Layer.

Contract-First als verbindlichen Standard einführen. Jedes neue Datenprodukt beginnt mit einem gemeinsamen Workshop zwischen Produzenten- und Konsumenten-Teams, der Semantik, Qualitätserwartungen und Nutzungsbedingungen klärt, bevor eine einzige Zeile Code geschrieben wird. Das Ergebnis ist ein versionierter Contract im Git-Repository, aus dem alle technischen Folgekomponenten automatisch abgeleitet werden.

Automatisierung als Skalierungsstrategie nutzen. Das Data Contract CLI ermöglicht es, aus einem YAML-Dokument automatisch Tests, Katalogeinträge, Infrastrukturkomponenten und Compliance-Nachweise abzuleiten. Governance, die manuell gepflegt wird, ist keine Skalierungsstrategie für KI-Zeitalter-Datenlandschaften.

Metadatenqualität als strategische Investition behandeln. Datenqualität ist eine notwendige, aber keine hinreichende Bedingung für KI-fähige Datenprodukte. Was KI-Systeme zusätzlich brauchen, ist Kontext: semantische Definitionen, Herkunftsangaben, Qualitätsstufen und Zugriffsregeln in maschinenlesbarer Form. Unternehmen, die diesen Kontext heute aufbauen, beschleunigen ihren KI-Rollout und reduzieren die Fehlerquote in produktiven KI-Systemen gleichzeitig.

Governance, die sich selbst durchsetzt, ist keine Zukunftsvision. Sie ist die logische Konsequenz aus der Entscheidung, Daten als Produkte zu behandeln und Data Contracts als ihr strukturelles Steuerungsinstrument zu nutzen. Die Tooling-Reife ist vorhanden. Entscheidend ist die organisatorische Konsequenz.

ODCS v3 — Data Contract Explorer · The Data Economist

The Data Economist  ·  Data Contract Explorer
ODCS v3 — Komponenten eines Data Contracts
Komponente anklicken, um das YAML-Beispiel zu sehen
© The Data Economist  ·  Marco Geuer

Lust auf einen Deep Dive? Dann fordere mein White Paper an. Vernetz dich einfach mit mir und senden eine Nachricht mit dem Betreff "WP digitale Governance" auf LinkedIn, oder über das Kontaktformular, um das White Paper zu erhalten. Ich freue mich auf den Austausch!“

Weitere interessante Artikel:

Data Governance, Data Strategy, Data Products, Data Management, Data & AI Strategy, AI Governance, Data & AI Governance, Meta Data Management, Data Architecture

  • Geändert am .
  • Aufrufe: 17