Data Contracts (Datenverträge)

Data Contracts (Datenverträge) sind verbindliche, versionierte Schnittstellen-Definitionen zwischen Datenproduzenten und Datenkonsumenten. Sie legen fest, welches Schema (z. B. Felder, Datentypen), welche Datenqualität (z. B. Vollständigkeit, Aktualität) und welche Regeln (z. B. Nullwerte, Wertebereiche) garantiert werden – ähnlich wie ein API-Vertrag, nur für Daten.

Was bedeutet „Data Contract“ genau?

Ein Data Contract beschreibt „was geliefert wird“ (Schema), „wie gut es sein muss“ (Qualitätskriterien) und „wie Änderungen passieren“ (Versionierung, Deprecation). Ziel ist, dass Downstream-Systeme nicht plötzlich brechen, wenn sich eine Tabelle, ein Event oder ein Export ändert. In KI-Setups ist das besonders wichtig, weil fehlerhafte oder driftende Daten schnell zu schlechteren Antworten, falschen Automationen oder Compliance-Problemen führen.

Wie funktioniert ein Data Contract in der Praxis?

• 1) Definition: Produzent und Konsument einigen sich auf Felder, Datentypen, Semantik (Bedeutung) und Beispiele.
• 2) Qualitätsregeln: z. B. „customer_id ist immer vorhanden“, „timestamp ist UTC“, „country ist ISO-3166-1 alpha-2“.
• 3) Validierung: Automatische Checks in Pipelines/Workflows (z. B. beim Laden in DWH, beim Event-Ingest, vor dem Export).
• 4) Versionierung & Change-Management: Breaking Changes nur mit neuer Version, Übergangsfristen und klarer Kommunikation.
• 5) Monitoring: Laufende Überwachung von Schema- und Qualitätsverletzungen, inkl. Alerts.

Warum sind Data Contracts wichtig – besonders für KI, LLMs und Automatisierung?

LLM-Anwendungen sind extrem abhängig von konsistenten Inputs. Schon kleine Schemaänderungen (z. B. „last_name“ wird zu „surname“) können RAG-Pipelines, Extraktionsprozesse oder Agenten-Workflows unbemerkt verschlechtern. Data Contracts reduzieren dieses Risiko, indem sie Erwartungen maschinenlesbar machen und frühzeitig prüfen.

• RAG & Wissensquellen: Wenn Chunking/Metadaten (z. B. source, doc_id, updated_at) stabil bleiben, funktionieren Retrieval und Zitierlogik zuverlässiger (siehe RAG (Retrieval-Augmented Generation) und Chunking (Text-Chunking).
• Structured Outputs: Wenn ein LLM Daten extrahiert (z. B. Rechnungsfelder), hilft ein klarer Zielvertrag inklusive Datentypen und Pflichtfeldern (siehe Structured Outputs (JSON Schema) und Schema Validation (JSON-Schema-Validierung).
• Automation (z. B. n8n): Workflows brechen seltener, wenn Eingangs- und Ausgangsdaten vertraglich fixiert und validiert werden (siehe n8n und Automatisierung (Automation).

Beispiele für Data Contracts

• Event-Tracking: Ein „order_created“-Event muss order_id (string), total_amount (number >= 0), currency (ISO-4217) enthalten; max. 5 Minuten Verzögerung.
• CRM-Export für KI-Support: Felder wie ticket_text (nicht leer), language (de/en), created_at (UTC) – damit ein ChatGPT-basierter Assistent korrekt klassifiziert und antwortet.
• Feature-Daten für Modelle: Garantierte Skalierung/Range, keine unerwarteten Nulls, definierte Aktualität – reduziert Daten- und Modellprobleme (siehe MLOps).

Was kostet die Einführung von Data Contracts?

Die Kosten hängen weniger von Lizenzen als von Prozessreife ab: Anzahl Datenquellen, Änderungsfrequenz, kritische Use Cases (KI/Compliance), Tooling (Validierung/Monitoring) und Governance. Typisch ist ein Start mit 1–3 kritischen Datenprodukten (z. B. Events, DWH-Tabellen, RAG-Metadaten) und anschließendes Skalieren. Der größte Hebel ist meist die Vermeidung von Ausfällen, Debugging-Zeit und fehlerhaften KI-Entscheidungen.