Datenverträge vs. Observability für KI

Vertrauen in KI beruht auf zwei unterschiedlichen Disziplinen: Erwartungen zu deklarieren und die Realität zu überprüfen. Datenverträge adressieren die erste. Data Observability adressiert die zweite.

Die Verwechslung beider Ansätze ist nachvollziehbar. Beide befassen sich mit Qualität, Metadaten, Incidents und Governance. Beide können Schemata validieren, fehlende Werte identifizieren und Verantwortliche benennen. Sie greifen jedoch zu unterschiedlichen Zeitpunkten im Lebenszyklus und beantworten unterschiedliche Fragen. Ein Vertrag fragt: „Darf sich diese Datenquelle auf diese Weise ändern?“ Observability fragt: „Ist das Verhalten dieser Datenquelle in der Produktion weiterhin gesund?“

Mit der Operationalisierung von KI hat diese Unterscheidung an Gewicht gewonnen. Der Bericht Data Products and Data Contracts in 2026 von BARC und Actian zeigt, dass 43 % der befragten Organisationen in den nächsten 12 Monaten den Ausbau von Data Observability priorisieren, während 28 % die Einführung von Verträgen planen und 26 % deren Durchsetzung stärken wollen. Die richtige Lesart ist nicht Substitution, sondern Ergänzung: Der Markt versucht, Vorhersehbarkeit an der Quelle mit kontinuierlicher Erkennung im Datenfluss zu verbinden. Quelle: BARC/Actian, 2026.

Das Problem, das jeder Ansatz löst

Ein Datenvertrag ist eine explizite Vereinbarung zwischen Produzent und Konsument. Er definiert die Schnittstelle eines Daten-Assets. Er kann Spalten, Typen, Schlüssel, Nullbarkeitsregeln, zulässige Werte, Aktualisierungsfrequenz, Verantwortliche, Sensibilitätsklassifizierung, Geschäftssemantik und eine Evolutionsrichtlinie festlegen.

Stellen Sie sich eine Bestelltabelle vor, die zur Nachfrageprognose verwendet wird. Der Vertrag kann festlegen, dass order_id eindeutig ist, dass order_date eine definierte Zeitzone verwendet, dass status zu einer kontrollierten Liste gehört und dass die Aktualisierung alle fünfzehn Minuten erfolgt. Ändert ein Team status ohne Versionierung von Text in einen numerischen Code, muss der Vertrag die Änderung blockieren oder kennzeichnen, bevor Konsumenten betroffen sind.

Data Observability ist die Fähigkeit, das Verhalten von Daten, Pipelines und Assets im Betrieb zu messen und zu erklären. Sie verfolgt Volumen, Aktualität, Verteilung, Lineage, Kosten, Fehler, Verzögerungen und Downstream-Auswirkungen. Sie stützt sich nicht nur auf bekannte Regeln. Sie sucht auch nach statistischen Abweichungen und unerwarteten Zusammenhängen.

Im selben Bestelldatensatz kann Observability erkennen, dass das Volumen in einer Region um 38 % gesunken ist, die Aktualisierung 47 Minuten verspätet ist, sich der Durchschnittswert abrupt verändert hat oder drei Dashboards und ein Support-Agent unvollständige Daten erhalten. Selbst wenn das Schema unverändert bleibt, kann der Betrieb beeinträchtigt sein.

Dieser Unterschied ist für KI entscheidend. Eine im Juli 2026 veröffentlichte Untersuchung auf Basis des Data Streaming Report von Confluent mit 4.625 IT-Führungskräften in 14 Ländern ergab, dass 72 % unzureichende Infrastruktur für Echtzeitverarbeitung als Hindernis für die KI-Einführung nennen. Die Studie verzeichnete außerdem unbefristete Verzögerungen oder Abbrüche bei nahezu der Hälfte der Projekte für agentische KI. In vielen Fällen ist nicht das Modell der Engpass. Das Problem ist nicht verfügbarer, verspäteter, fragmentierter oder nicht governter Kontext. Quelle: IBM zum Confluent-Bericht, 2026.

Direkter Vergleich: Prävention versus Erkennung

Die Tabelle macht einen häufig übersehenen Punkt sichtbar: Konformität zu validieren ist nicht dasselbe wie Gesundheit nachzuweisen. Eine Tabelle kann den Schema-Vertrag vollständig erfüllen und dennoch leer, verspätet oder verzerrt sein. Ebenso kann eine Plattform Dutzende Anomalien erkennen, ohne unterscheiden zu können, ob es sich um eine legitime Variation oder eine Änderung handelt, die gegen eine Geschäftsregel verstößt.

Der Vertrag liefert die Absicht. Observability liefert die Evidenz.

Die Architekturperspektive

In der Architektur fungieren Verträge als stabile Schnittstellen zwischen Domänen. Sie reduzieren Kopplung, weil der Konsument bei jeder Integration weder Struktur noch Semantik der Daten neu ableiten muss. Das produzierende Team übernimmt Verantwortung für ein veröffentlichtes Versprechen. Das konsumierende Team kann Tests automatisieren und die Weiterentwicklung planen.

Die reifste Form eines Vertrags beschränkt sich nicht auf eine Schemadatei. Sie verbindet technische Spezifikation und Geschäftskontext. Sie umfasst Felddefinition, Granularität, Herkunft, Berechnungsregel, Klassifizierung personenbezogener Daten, Verfügbarkeitsfenster, SLO, Owner und Deprecation-Richtlinie. Dadurch können eine Tabelle, ein Event-Topic oder ein Endpoint als betreibbares Produkt behandelt werden.

Eine im Juli 2026 veröffentlichte Arbeit zu Datenverträgen in Lakehouse-Umgebungen schlägt vor, sie als Typen zu behandeln, die an verschiedenen Punkten des Ausführungszyklus interpretiert werden können. In diesem Modell enthalten Annotationen Typen, Einschränkungen, Dokumentation und Lineage und ermöglichen damit eine konsistentere Validierung zwischen Sprachen und Engines. Die Richtung ist relevant: Verträge hören auf, passive Dokumentation zu sein, und werden Teil der Ausführung. Quelle: arXiv, 2026.

Observability erfordert dagegen Instrumentierung. Sie hängt von Collectors, Ausführungslogs, Katalogmetadaten, Qualitätshistorie, Pipeline-Events und einem Lineage-Graphen ab. Ihr Wert steigt, wenn sie das technische Signal mit der geschäftlichen Konsequenz verbindet: Welches Modell, welcher Bericht, welche Journey oder welche Entscheidung wurde beeinträchtigt?

Eine reife Observability-Architektur überwacht nicht nur Jobs. Sie korreliert Assets. Wenn das CRM ein Feld nicht mehr sendet, sollte die Plattform nicht nur die fehlerhafte Pipeline zeigen, sondern auch, welche Vertriebsmetriken, Kampagnensegmente und Empfehlungen des Assistenten beeinträchtigt wurden. Das verkürzt die Zeit zwischen Alert und Entscheidung.

Operativer Vergleich: Wer macht was

Verträge erfordern Abstimmung. Jemand muss entscheiden, welche Semantik kanonisch ist, welche Toleranz akzeptabel ist und wie Änderungen kommuniziert werden. Diese Arbeit ist weniger technologisch, als sie erscheint. Sie erfordert klare Ownership.

Der Produzent pflegt die Spezifikation und verantwortet die Kompatibilität. Der Konsument formalisiert Abhängigkeiten und kritische Kriterien. Die Plattform stellt Mechanismen für Validierung, Registrierung, Versionierung und Blocking bereit. Governance definiert Mindeststandards und Ausnahmen.

Observability erfordert hingegen kontinuierlichen Betrieb. Schwellenwerte müssen kalibriert, nützliche Anomalien von erwarteten Variationen unterschieden, Eskalationen etabliert, Incidents korreliert und die Abdeckung überprüft werden. Ein Tool ohne Response-Prozess erzeugt nur Alerts. Ein Prozess ohne Telemetrie ist auf manuelle Untersuchung angewiesen.

Mit KI-Agenten steigt der operative Druck tendenziell. Ein Agent kann mehrere Quellen abfragen, Aktionen ausführen und Antworten in kurzen Zyklen erzeugen. Wenn sich eine Quelle ändert, zeigt sich der Effekt möglicherweise nicht als technischer Fehler. Er kann als inkonsistente Empfehlung, unzulässiger Rabatt, fehlerhafte Priorisierung oder kontextlose Antwort auftreten.

Daher sollten Verträge für KI-Konsum relevante Regeln enthalten: freigegebene Herkunft, Vertraulichkeitsklassifizierung, zulässiger Zweck, Mindestaktualität, Granularität, Abdeckung und Aufbewahrungsrichtlinie. Observability sollte Abfragen, abgerufenen Kontext, Latenz, Asset-Versionen und Qualitätsindikatoren der Antwort verfolgen.

In einer auf Finanzdienstleistungen fokussierten Untersuchung von 2026 gaben 89 % der Befragten an, Observability zur Berichterstattung über Geschäftsauswirkungen zu nutzen. Allerdings maßen nur 27 % operativen und geschäftlichen Metriken die gleiche Bedeutung bei. Die Zahl ist sektorspezifisch, weist aber auf eine wiederkehrende Lücke hin: Technische Fehler zu überwachen, ohne zu quantifizieren, welche Entscheidungen, Kunden oder Umsätze betroffen sind, begrenzt die strategische Priorisierung. Quelle: Dimensional Research/Elastic, 2026.

Wo Verträge allein scheitern

Verträge ersetzen kein statistisches Monitoring. Sie eignen sich hervorragend, um bekannte Anforderungen auszudrücken. Sie sind schwach darin, Verhalten vorauszusehen, das niemand spezifiziert hat.

Betrachten Sie eine Transaktionsquelle, deren Schema, Frequenz und zulässige Werte unverändert bleiben. Eine Kampagne kann den Kundenmix abrupt verändern. Ein Quellfehler kann gültige Transaktionen duplizieren. Eine Integration kann Datensätze verzögern, ohne den formalen SLA zu überschreiten. Ein Modell kann Daten mit einer von der Historie abweichenden Verteilung erhalten. Nichts davon verletzt zwangsläufig eine einfache Vertragsregel.

Eine weitere Grenze ist Überdetaillierung. Riesige Verträge, die alle denkbaren Hypothesen abdecken sollen, werden zur Bürokratie und veralten schnell. Das Ziel ist nicht, jedes Asset in eine hundertseitige Spezifikation zu verwandeln. Es geht darum, die Verpflichtungen zu deklarieren, deren Verletzung relevante Auswirkungen verursacht.

Beginnen Sie mit kritischen Assets: Umsatz-, Identitäts-, Bestands-, Berechtigungs-, Risiko- und Servicedaten sowie dem von KI verwendeten Kontext. Definieren Sie wenige starke Invarianten. Beispiel: Eindeutigkeit eines Schlüssels, maximale Aktualitätsgrenze, Statusdomäne, PII-Richtlinie und verantwortlicher Owner. Erweitern Sie anschließend entsprechend der tatsächlichen Nutzung.

Wo Observability allein scheitert

Observability ohne Vertrag arbeitet tendenziell im archäologischen Modus. Sie erkennt, dass sich etwas verändert hat, kann aber nicht schnell beantworten, ob die Änderung akzeptabel, erwartet oder kritisch ist.

Ein Anstieg des Event-Volumens um 20 % kann ein Duplizierungsfehler oder die Wirkung einer neuen Kampagne sein. Eine Spalte mit mehr Nullwerten kann auf einen Erfassungsfehler oder auf eine vom Business genehmigte Prozessänderung hinweisen. Ohne deklarierte Erwartung muss das Tool die Bedeutung aus der Historie ableiten. Das ist nützlich, aber für Entscheidungen mit hohem Risiko nicht ausreichend.

Es gibt auch wirtschaftliche Kosten. Detaillierte Profile zu erfassen, Logs aufzubewahren und Lineage im großen Maßstab zu analysieren, kann Verarbeitungs- und Speicherkosten erhöhen. Die Untersuchung von Dimensional Research ergab, dass 71 % der Befragten mit unerwarteten Kosten oder Überschreitungen bei Observability-Tools konfrontiert sind. Die praktische Schlussfolgerung lautet nicht, Transparenz wahllos zu reduzieren. Sie lautet, Instrumentierung nach Kritikalität, Wirkung und Untersuchungsbedarf auszurichten.

Priorisieren Sie tiefe Telemetrie für Journeys, die Umsatz, regulatorisches Risiko oder Kundenerlebnis bewegen. Für periphere Daten reichen Basissignale und kürzere Aufbewahrung. Betrachten Sie das Observability-System als Produkt: Abdeckung, Kosten pro vermiedenem Incident, Erkennungszeit, Alert-Präzision und Geschäftsauswirkung sollten gemessen werden.

Ein kombiniertes Modell für vertrauenswürdige Daten

Die beste Abfolge ist einfach, auch wenn sie Disziplin erfordert.

1. Klassifizieren Sie Assets nach ihrer Wirkung

Teilen Sie Daten in vier Gruppen ein: kritisch für automatisierte Entscheidungen, kritisch für menschliche Abläufe, wichtig für Analysen und peripher. Wenden Sie nicht auf alles dasselbe Niveau an Verträgen und Monitoring an.

2. Schreiben Sie minimal tragfähige Verträge

Deklarieren Sie für jedes kritische Asset Owner, Konsumenten, Zweck, Schema, Qualitätsregeln, Aktualität, Sensibilität und Evolution. Halten Sie eine explizite Richtlinie für inkompatible Änderungen fest: versionieren, informieren, Übergangszeitraum einhalten und Konsumenten testen.

3. Überführen Sie Verpflichtungen in ausführbare Kontrollen

Jede relevante Regel muss an einem Punkt testbar sein: an der Quelle, in der Pipeline, vor der Veröffentlichung oder beim Konsum. Ein Vertrag schafft nur dann Vertrauen, wenn er eine Verletzung verhindern, blockieren oder weiterleiten kann.

4. Instrumentieren Sie das Verhalten, das der Vertrag nicht vorhersehen kann

Überwachen Sie Volumen, Verzögerung, Verteilung, Vollständigkeit, Kosten, Fehler und Abhängigkeiten. Verknüpfen Sie jeden Alert mit betroffenen Konsumenten und Prozessen. Eine Abweichung ohne Wirkung kann warten. Eine Abweichung, die eine kritische Entscheidung speist, erfordert sofortige Reaktion.

5. Schließen Sie den Lernkreislauf

Jeder relevante Incident sollte etwas aktualisieren: Vertrag, Observability-Regel, Dokumentation, statistischen Grenzwert oder Änderungsprozess. Wenn sich die Ursache wiederholt, hängt die Architektur noch zu stark von manueller Untersuchung ab.

Centriu kann diese Disziplin unterstützen, indem es operative Signale, Geschäftskontext und Governance-Routinen verbindet. Die Tool-Auswahl folgt jedoch erst nach dem Design der Verantwortlichkeiten. Ohne Owner, Kriterien und Response-Workflows beschleunigt die Plattform lediglich die Sichtbarkeit von Unordnung.

Wann welcher Ansatz sinnvoll ist

Setzen Sie Datenverträge ein, wenn das Hauptrisiko in inkompatiblen Änderungen, semantischer Unklarheit oder fehlender Verantwortlichkeit zwischen Produzent und Konsument liegt. Sie sind besonders sinnvoll bei domänenübergreifenden Integrationen, wiederverwendbaren Datenprodukten, geteilten Events, regulierten Quellen und Kontexten, die automatisierte Entscheidungen speisen.

Setzen Sie Data Observability ein, wenn das Hauptrisiko Degradation in der Produktion ist: Verzögerungen, Volumenrückgänge, Duplikate, anomale Verteilungen, Pipeline-Fehler, unerwartete Kosten oder Kaskadeneffekte. Sie ist unverzichtbar für hochfrequente Datenflüsse, Echtzeitoperationen, KI mit Kontext-Retrieval und Ketten mit vielen Konsumenten.

Setzen Sie beide ein, wenn Daten Umsatz, Risiko, Kundenerlebnis oder die Autonomie von Agenten tragen. Der Vertrag definiert die akzeptable Grenze. Observability zeigt, ob die Realität weiterhin innerhalb dieser Grenze liegt. Dann ist jeder Ansatz sinnvoll.