Bitol-Projekt hat am 8. September 2026 den Open Data Contract Standard (ODCS) v3.2.0 zusammen mit dem Open Data Product Standard (ODPS) v1.1.0 veröffentlicht. Wieso ist das interessant?
ODCS 3.2: Datenverträge jetzt auch für KI verständlich
Datenverträge sollen Produzenten und Konsumenten verlässlich darüber informieren, welche Daten bereitgestellt werden, wie sie strukturiert sind und welche Qualitäts- und Serviceanforderungen gelten. Dieses Prinzip bleibt auch mit dem Open Data Contract Standard (ODCS) 3.2 erhalten. Trotzdem markiert die neue Version einen wichtigen Entwicklungsschritt: Der Standard beschreibt nicht mehr nur, welche Daten vorhanden sind, sondern zunehmend auch, was sie bedeuten, wie sie verwendet werden sollen und welche Grenzen dabei gelten.
Der Schwerpunkt verschiebt sich damit von einem reinen Datenvertrag hin zu maschinenlesbarem Kontext für KI, semantische Systeme und Automatisierung.
Das ist relevant, weil sich die Zielgruppe eines Datenvertrags verändert. Bisher wurde ein Vertrag vor allem von Data Engineers, Data Stewards, Plattformteams und Validierungswerkzeugen gelesen. Künftig gehören auch AI Agents, Copilots, Text-to-SQL-Systeme, semantische Schichten und automatisierte Governance-Dienste zu den Konsumenten. Diese Systeme benötigen mehr als Spaltennamen und Datentypen. Sie müssen wissen, wie Begriffe fachlich zu verstehen sind, welche Berechnungen zulässig sind, wie Daten miteinander verbunden werden dürfen und wann eine Antwort riskant oder schlicht falsch wäre.
Ein Feld namens ‘Revenue’ mit dem Datentyp ‘decimal’ ist technisch eindeutig, aber fachlich unzureichend. Handelt es sich um Brutto- oder Nettoumsatz? Ist die Kennzahl bereits währungsbereinigt? Darf sie nach einzelnen Kundinnen und Kunden aufgeschlüsselt werden? Ist sie für den Jahresabschluss geeignet oder nur für operative Trendanalysen? Wir Menschen klären solche Fragen über Dokumentationen, Meetings und Erfahrungswissen. Ein AI Agent verfügt über diesen impliziten Kontext nicht. ODCS 3.2 schafft Strukturen, um mehr davon direkt mit dem Datenvertrag auszuliefern.
Was in ODCS 3.2 neu ist
1. Der neue context-Block: Gebrauchsanweisung für Daten
Der neue optionale context-Block ergänzt Nutzungsanweisungen, verifizierte Aussagen und Einschränkungen. Das ist eine zentrale Neuerung für KI, weil fachlicher Kontext maschinenlesbar wird und Fehlinterpretationen reduziert.
2. Semantische Modellierung: Von Spalten zu Geschäftsbegriffen
Eigenschaften lassen sich nun als measure, dimension oder normale Spalte klassifizieren und um Synonyme ergänzen. Das ist für BI und KI sehr relevant, weil Bedeutung und zulässige Nutzung portabler werden.
3. Vektoren als eigener Datentyp: Embeddings werden erklärbar
ODCS 3.2 führt einen logischen Vektortyp ein, der unter anderem Dimension, Modell und Distanzmetrik von Embeddings beschreiben kann. Für RAG und semantische Suche ist das wichtig, für klassische Analytics dagegen eher ein Spezialfeature.
4. Enumerationen und Maps: Komplexere Strukturen präziser beschreiben
Enumerationen definieren erlaubte Werte, Maps beschreiben flexible Schlüssel-Wert-Strukturen. Das ist eine sinnvolle, aber eher evolutionäre Ergänzung für Validierung und moderne Datenformate.
5. Mehr Operationalisierung: Verträge werden portabler und wartbarer
Variablen, Deprecation-Kennzeichnungen und stabile Beziehungs-IDs erleichtern Betrieb und Weiterentwicklung von Verträgen. Die Funktionen sind technisch unspektakulär, für produktive Nutzung aber wichtig.
6. Erweiterte Infrastrukturunterstützung: Näher an realen Plattformlandschaften
Neue Servertypen für Apache Iceberg, SAP HANA, Exasol, Teradata und Actian sowie Angaben zur Zeichenkodierung erweitern die technische Reichweite. Das ist für Nutzer dieser Plattformen relevant, insgesamt aber eher ein Kompatibilitäts- als ein strategisches Feature.
Vom Data Contract zum Context Contract?
Der Begriff Context Contract beschreibt die strategische Bedeutung dieser Erweiterungen gut, auch wenn ODCS weiterhin ein Data-Contract-Standard bleibt.
Ein klassischer Datenvertrag definiert vor allem:
- Datenangebot: Tabellen, Felder, Datentypen, Formate und Bereitstellung.
- Qualität und Service: Prüfregeln, Fehlergrenzen, Aktualisierungsrhythmus und SLAs.
- Zweck: Für welche fachlichen Zwecke und Anwendungsfälle das Datenprodukt vorgesehen ist.
- Governance: Owner, Nutzungsbedingungen, Policies sowie Vorgaben für Zugriff und Schutz.
Ein Context Contract ergänzt insbesondere:
- Bedeutung: Fachliche Definitionen und Berechnungslogiken, etwa für „Nettoumsatz“.
- Interpretation: Synonyme, Beziehungen und erlaubte Aggregationen, etwa „Sales“ = Summe des Nettoumsatzes.
- Handlungsanweisungen: Konkrete Hinweise, wie Menschen und KI die Daten korrekt verwenden sollen.
- Verifizierter Kontext: Geprüfte Aussagen und Beispiele, an denen sich automatisierte Systeme orientieren können.
Damit wird Kontext nicht mehr nur als Begleitdokumentation behandelt. Er wird Teil einer standardisierten, versionierbaren und maschinenlesbaren Schnittstelle. Genau das ist für AI Agents entscheidend: Sie verfügen nicht automatisch über das Erfahrungswissen einer Organisation. Wenn Kontext ausschließlich in Präsentationen, Wiki-Seiten oder den Köpfen einzelner Fachleute steckt, bleibt er für automatisierte Systeme schwer zugänglich.
ODCS 3.2 ist damit noch kein eigenständiger „Context Contract“, öffnet den Data Contract aber gezielt für maschinenlesbaren Kontext. Er ist also ein Data Contract mit Kontext-Erweiterung. Der Standard stellt dafür die Struktur bereit; ihren Wert entfaltet sie erst, wenn Unternehmen sie mit verlässlichen Inhalten füllen und ihre Systeme diese auswerten.
Business Impact
Verlässlichere KI-Ergebnisse
AI Agents und Text-to-SQL-Systeme können bessere Abfragen erzeugen, wenn sie Kennzahlen, Synonyme, Beziehungen und Nutzungsgrenzen kennen. Der größte Nutzen liegt nicht nur in einer höheren technischen Genauigkeit, sondern in weniger fachlich plausiblen, aber inhaltlich falschen Antworten.
Schnellere Nutzung und Wiederverwendung von Daten
Neue Mitarbeitende, Analystinnen und Analysten sowie Entwicklungsteams müssen weniger Kontext über persönliche Übergaben rekonstruieren. Datenprodukte lassen sich schneller verstehen und über verschiedene Werkzeuge hinweg wiederverwenden. Das reduziert Abhängigkeiten von Schlüsselpersonen.
Portablere Semantik
Geschäftsdefinitionen sind heute häufig an ein bestimmtes BI-Tool, einen Katalog oder eine proprietäre semantische Schicht gebunden. Ein offener Vertrag kann einen Teil dieser Semantik näher an die Daten bringen und zwischen Plattformen transportierbar machen. Das senkt Wechselkosten und stärkt die Kontrolle über das eigene Wissen.
Automatisierbare Governance
Maschinenlesbare Constraints, Deprecation-Informationen, Qualitätsregeln und Verantwortlichkeiten ermöglichen automatisierte Prüfungen. Governance kann früher im Entwicklungs- und Bereitstellungsprozess greifen, statt erst bei einer manuellen Kontrolle oder nach einem Vorfall.
Bessere Steuerung von Datenprodukten
Durch die Verbindung technischer, semantischer und operativer Metadaten können Unternehmen genauer beurteilen, welche Datenprodukte für Analytics und KI tatsächlich einsatzbereit sind. Ein formal vorhandenes Datenprodukt ist nicht automatisch ein vertrauenswürdiges oder AI-ready Datenprodukt.
Was Unternehmen tun müssen, um Data Contracts mit Kontext zu nutzen
Die Vorteile entstehen nicht durch ein Schema-Update allein. ODCS ist eine deklarative Spezifikation und keine Ausführungsplattform. Ein Constraint im Vertrag verhindert noch keine unerlaubte Abfrage, solange die beteiligten Systeme ihn nicht interpretieren und durchsetzen.
1. Mit einem klaren Anwendungsfall starten
Wählen Sie ein wichtiges Datenprodukt, das bereits von einem BI- oder KI-System genutzt wird. Legen Sie eine konkrete Frage fest, etwa „Wie hoch war der Nettoumsatz im letzten Quartal?“, und messen Sie Fehler sowie manuellen Korrekturaufwand.
2. Festlegen, wer den Kontext liefert und pflegt
Benennen Sie für jedes Datenprodukt eine fachlich verantwortliche Person. Diese definiert gemeinsam mit Data Stewards und Data Engineers die Begriffe, Berechnungen, erlaubten Nutzungen und Einschränkungen. Sie prüft den Kontext außerdem bei fachlichen oder technischen Änderungen, damit er nicht veraltet.
3. Kontext für Werkzeuge nutzbar machen
Kataloge, semantische Schichten und KI-Plattformen müssen die Angaben aus dem Data Contract importieren und verarbeiten können. Prüfen Sie zunächst einen vollständigen Weg vom Contract über den Katalog bis zum AI Agent.
4. Jede Regel mit einer technischen Kontrolle verbinden
Dokumentieren Sie Regeln nicht nur im Data Contract, sondern legen Sie fest, welches System sie prüft oder durchsetzt. Qualitätsvorgaben werden beispielsweise durch automatisierte Tests kontrolliert, Zugriffsregeln durch das Berechtigungssystem und Nutzungsbeschränkungen durch eine Policy Engine oder ein AI Gateway. Starten Sie mit wenigen Regeln, die sich eindeutig prüfen und bei Verstößen blockieren oder melden lassen.
Fazit
ODCS 3.2 entwickelt den Datenvertrag zu einer potenziellen Kontextschnittstelle für Menschen und Maschinen weiter. Fachliche Definitionen, Berechnungsregeln und Nutzungsgrenzen können KI-Systemen helfen, Daten zuverlässiger zu interpretieren.
Das ist ein wichtiger Schritt, aber keine Sofort-Lösung. Die Angaben bleiben zunächst deklarativ und entfalten erst dann Wirkung, wenn Plattformen sie auswerten, technisch durchsetzen und dauerhaft aktuell halten.
Technisch ist das realistisch, organisatorisch jedoch anspruchsvoll: Unternehmen müssen Verantwortliche benennen und verlässlichen Kontext pflegen. Sinnvoll ist deshalb ein gezielter Einstieg mit wenigen wichtigen Datenprodukten und konkreten KI-Anwendungsfällen.
Die Kontext-Erweiterungen in den Data Contracts ersetzen weder semantische Modellierung noch Governance oder Datenqualität. Sie können diese Disziplinen aber über eine offene, maschinenlesbare Schicht mit BI-Werkzeugen, Plattformen und AI Agents verbinden. Dem Aufbau komplexerer Agenten-Architekturen rücken wir damit einen Schritt näher.
