Jeder, der mit Daten arbeitet, kennt diesen Anruf. Eine Zahl in einem Bericht ist falsch, und jemand muss herausfinden, warum, bevor das Meeting beginnt. Die Untersuchung, die folgt, ist fast immer dieselbe: Welcher Feed, welche Ladung, welche Spalte, wie weit hat sich der Fehler ausgebreitet, und was tun wir dagegen?

Seit zwanzig Jahren werden die Werkzeuge in einem Teil dieser Aufgabe stetig besser: im Bemerken. Regeln fangen ab, was jemand vorhergesehen hat. Observability fängt ab, was sich bewegt hat. Doch zwischen dem Alert und der Korrektur stehen immer noch ein Mensch, eine Warteschlange und sehr oft ein Montagmorgen.

Dieser Artikel fragt, ob das so bleiben muss. Können Daten sich selbst reparieren? Die ehrliche Antwort lautet: teilweise, unter Bedingungen, die sich aufschreiben lassen. Und diese Bedingungen erweisen sich als interessanter als die Automatisierung selbst.

Datenqualität und Data Observability: Zwei Disziplinen, keine reicht allein

Datenqualität ist der Grad, in dem Daten für den Zweck geeignet sind, für den sie verwendet werden, gemessen an einer Erwartung, die jemand aufschreiben musste. Sie ist eine Eigenschaft der Daten selbst: Werte, Schlüssel, Beziehungen. Sie ist zweckgebunden, denn eine Abflugzeit, die für einen Monatsbericht genau genug ist, reicht für die Anmeldung eines Flughafen-Slots nicht aus. Und sie ist deklarativ. Eine Regel findet immer nur das, woran jemand bereits gedacht hat.

Data Observability ist die Fähigkeit, den Zustand und das Verhalten Ihrer Daten anhand der Signale zu verstehen, die sie aussenden, ohne im Voraus zu wissen, was schiefgehen wird. Aktualität, Volumen, Schema, Verteilung und Lineage werden aus der Historie gelernt, statt vom Fachbereich vorgegeben zu werden. Deshalb skaliert Observability auf jede Tabelle. Genau darin liegt aber auch ihre Grenze: Observability kann Ihnen sagen, dass sich etwas verändert hat, niemals aber, dass etwas falsch ist.

Keine der beiden Disziplinen schließt die andere ein. Nehmen Sie eine Blockzeit von 92 Minuten auf einer Strecke, die normalerweise 148 Minuten dauert. Die Zeilenzahlen sind normal, die Tabelle ist aktuell, das Schema hat sich nicht geändert, und der Wert liegt bequem innerhalb jedes globalen Bereichs. Er besteht jede Prüfung und ist trotzdem falsch. Genau diese Lücke beschreibt unser Artikel über Daten, die falsch aussehen, aber Ihre Regeln bestehen, und den vollständigen Vergleich der beiden Disziplinen finden Sie in Data Observability vs. Datenqualität.

Was ist autonome Datenqualität?

Autonome Datenqualität ist die kontinuierliche, überwiegend KI-gestützte Fähigkeit, Datenqualitätsprobleme mit minimalem menschlichem Eingreifen zu erkennen, zu untersuchen, zu bewerten und zu beheben. Vier Verben, und die letzten drei sind es, die sie von den Werkzeugen unterscheiden, die die meisten Teams bereits haben:

• Erkennen: Etwas hat sich weit genug bewegt, um Aufmerksamkeit zu verdienen.

• Untersuchen: Welcher Feed, welche Ladung, welche Spalte.

• Bewerten: Wie schwerwiegend es ist und was davon abhängt.

• Beheben: Quarantäne, Zurückhalten oder erneuter Lauf, und genau protokollieren, was getan wurde.

Fast jedes Produkt auf dem Markt hört heute nach dem ersten Verb auf. Wie Observability passt sich autonome Datenqualität an: Schwellenwerte und Prioritäten folgen den Daten, statt an dem Tag einzufrieren, an dem jemand sie festgelegt hat. In der Praxis ist sie der Versuch, aus den Signalen der Observability genau die Qualitätsarbeit zu erzeugen, für die früher Regeln nötig waren.

Warum das gerade jetzt möglich wird

Zwei Dinge ändern sich gleichzeitig. Das erste ist die Form der Datenplattform. Das zentrale Data Warehouse, betrieben von einem Team, das sich darauf geeinigt hatte, was ein Kunde oder ein Passagier ist, weicht Datenprodukten mit eigenen Verantwortlichen, Verträgen und Release-Zyklen. Qualität muss nun an jeder Grenze halten, die die Daten überqueren, nicht nur dort, wo sie ankommen, und niemand verantwortet mehr die gesamte Kette.

Das zweite ist die Ankunft von Agenten auf dieser Plattform. Einem Agenten muss man nicht sagen, wie. Man muss ihm sagen, was, und wie weit er gehen darf. Nehmen Sie ein routinemäßiges Neuladen. Heute sucht ein Engineer die Stored Procedure und ihre Parameter, die Quell-API mit Authentifizierung und Paging, schreibt Retry- und Fehlerbehandlung und schreibt alles neu, sobald ein Partner seinen Export ändert. Mit einem Agenten wird die Anweisung zu einem Satz: Lade die Boarding-Daten von gestern für einen Flug neu. Der Agent findet Procedure und API im Katalog, ordnet die Aufrufe, wiederholt sie bei Bedarf und prüft die Zeilenzahl selbst.

Das ist ein anderes Integrationsmodell als alles, was wir bisher gebaut haben. Wir werden weniger Zeit damit verbringen festzulegen, wie ein Neuladen abläuft, und mehr Zeit damit festzulegen, was neu geladen werden darf, von wem und ohne Rückfrage.

Ein Flugabschnitt, fünf verschiedene Antworten

Um das greifbar zu machen, nehmen wir Alpenwing Airways, eine fiktive mittelgroße europäische Fluggesellschaft, deren Probleme vollkommen real sind. Sieben Systeme beschreiben denselben Flug: Buchungen, Departure Control, die operative Flughafendatenbank, Wartung, Crew-Einsatzplanung, Revenue Accounting und elf Feeds von Codeshare-Partnern. Keines davon ist falsch. Sie wurden zu unterschiedlichen Zeiten für unterschiedliche Aufgaben gebaut, und im Data Warehouse werden ihre Widersprüche sichtbar. So geht ein Agent mit fünf Alerts zu einem einzigen Flugabschnitt um: WG 402 von Wien nach Warschau.

1. Ein Partner-Feed wechselt über Nacht von IATA- auf ICAO-Flughafencodes

Die durchschnittliche Länge der Spalte für den Abflughafen springt bei einer Quelle von 3,00 auf 4,00, und 1.284 Zeilen fallen durch die Prüfung auf zulässige Werte. Sonst hat sich an diesem Feed nichts bewegt. Ein Data Steward hat die Zuordnung LOWW zu VIE vor Monaten freigegeben, das veröffentlichte ICAO-Register bestätigt sie, und die Korrektur ist umkehrbar. Einfacher wird es nicht, und dieser Fall liegt nah an dem, was heute schon möglich ist.

2. Der Flug boardet 36 Passagiere in ein Flugzeug mit 180 Sitzen

Ein Sitzladefaktor von 0,20 auf einer Strecke, die in zwei Jahren nie unter 0,72 gefallen ist, während jeder andere Abschnitt an diesem Tag normal aussieht. Für genau diesen Fall gibt es ein freigegebenes Muster: den Abschnitt neu laden und ihn dann gegen eine zweite, unabhängige Zählung aus dem Buchungssystem prüfen. Die Lineage zeigt, dass drei Marts und der tägliche Operations-Bericht davon abhängen, also hält der Agent sie zurück, bis die Zählung bestätigt ist.

3. Departure Control zählt 168 Passagiere, die Flughafendatenbank 171

Ein geplanter Abgleich schlägt um drei Passagiere fehl, und die Observability sieht überhaupt nichts: 168 ist eine normale Zahl, 171 ebenfalls. Der Unterschied erweist sich als Definitionsfrage. Ist ein Kleinkind, das auf dem Schoß reist, ein Passagier? Kein Katalogeintrag beantwortet das, und kein freigegebenes Muster deckt es ab. Der Agent kann die gesamte Analyse übernehmen. Die Definition bleibt eine menschliche Entscheidung.

4. Der Feed der operativen Flughafendatenbank kommt drei Stunden zu spät

Der Feed trifft normalerweise vor 02:30 Uhr ein. Um 05:40 Uhr ist er immer noch nicht da, und der Operations-Bericht ist für 06:00 Uhr geplant. Keine Datenqualitätsregel schlägt an, denn die Daten sind nicht falsch, sie fehlen einfach. Abhängige Ladeprozesse bei verspäteter Lieferung zurückzustellen, ist ein freigegebenes Muster. Also nutzt der Agent Lineage und Ladeprotokoll, um genau die Berichte zurückzuhalten, die sonst mit den Zahlen von gestern laufen würden, und sonst nichts.

5. Die Zielstadt kommt als Freitext an

Wiedeń, Viena und Wien bedeuten alle Wien. Die Zahl der unterschiedlichen Werte springt an einem Tag von 41 auf 63, und 2.140 Zeilen passen zu keiner Referenzliste. Das offene Internet hilft zu erfahren, dass Wiedeń das polnische Wort für Wien ist, aber allein reicht es nie aus. Eine Zuordnung ist nur gegen eine deklarierte Domäne sicher: die 94 Flughäfen, die Alpenwing tatsächlich anfliegt. Hier geht es darum, wohin sich die Technologie entwickelt, nicht darum, wo sie heute steht.

Die vier Prüfungen, die entscheiden, ob ein Agent allein handeln darf

Jedes dieser Szenarien durchläuft dasselbe Tor, gebaut aus vier überprüfbaren Fragen. Keine davon ist die eigene Zuversicht des Modells. Diese ist nicht kalibriert und sollte nie der Grund sein, ein Data Warehouse zu verändern.

• Wurde genau dieses Muster schon einmal freigegeben? Hat ein Steward es einmal freigegeben, ist das zehnte Auftreten ein Nachschlagen statt einer Ermessensentscheidung. Es ist das stärkste einzelne Signal, aber weder notwendig noch hinreichend.

• Ist die Aktion umkehrbar? Quarantäne, Zurückhalten, erneute Anforderung und Neuladen lassen sich alle rückgängig machen. Einen Wert an Ort und Stelle zu überschreiben, nicht. Umkehrbare Aktionen verdienen deutlich mehr Freiheit.

• Ist die Quelle maßgeblich und datiert? Ein veröffentlichtes Register mit Veröffentlichungsdatum rechtfertigt ein Handeln. Eine plausible Antwort ohne Quellenangabe nicht, so überzeugt sie auch klingen mag.

• Wie groß ist der Wirkungsradius? Eine einzelne Zeile in Quarantäne ist etwas anderes als eine Dimension, mit der jeder Mart verknüpft ist, und das wiederum ist etwas anderes als eine Zahl, die bereits an eine Aufsichtsbehörde gemeldet wurde.

Genauso wichtig ist die Reihenfolge, in der ein Agent seine Quellen befragt. Zuerst kommt Ihre eigene Wissensbasis: der Katalog, die Lineage, die Verträge und die Bibliothek freigegebener Muster. An zweiter Stelle stehen veröffentlichte Register. Das offene Internet dient nur der Orientierung, und das eigene Gedächtnis des Modells ist die schwächste Quelle von allen, denn eine Antwort, die niemand nachgeschlagen hat, ist von einer recherchierten nicht zu unterscheiden. Ein Agent, der seine Quelle nicht nennen kann, darf nicht handeln.

Wie viel Freiheit der Agent erhält, wird pro Domäne und pro Datenprodukt festgelegt, niemals einmal für das ganze Unternehmen. Eine regulierte Bank erlaubt vielleicht nur Vorschläge, die jeweils auf eine namentlich benannte Freigabe warten. Bei den operativen Daten einer Airline dürfen umkehrbare Aktionen möglicherweise allein laufen, während alles Unumkehrbare vorgeschlagen wird. Ein Marketing-Datenprodukt lässt die meisten Korrekturen vielleicht unbeaufsichtigt laufen und prüft sie wöchentlich in der Gesamtschau. Und unabhängig von der Einstellung trägt jede Aktion ihre Belege mit sich, jede Aktion lässt sich einzeln zurückrollen, und freigegebene Muster werden überwacht und laufen ab, denn die Welt kann sich unter einem Muster verschieben, das früher richtig war.

Was autonome Datenqualität immer noch nicht kann

Die Grenzen haben sich verschoben. Verschwunden sind sie nicht, und drei davon sind dauerhaft.

• Sie kann keine Quelle der Wahrheit erfinden. Ob ein Passagier tatsächlich eingestiegen ist, hält der Boarding-Scan fest und sonst nichts. Sind beide Kopien einer Zahl gemeinsam falsch, bestätigt der Abgleich sie bereitwillig, denn er vergleicht, statt zu verifizieren.

• Sie kann den Zweck nicht definieren. Ob ein Kleinkind als Passagier zählt, welches System maßgeblich ist und ob die Historie nachträglich korrigiert werden darf, nachdem eine Zahl an eine Aufsichtsbehörde gemeldet wurde, sind geschäftliche Entscheidungen. Jemand muss sie verantworten, und zwar schriftlich.

• Sie repariert nicht die Quelle. Ein Feed, der für immer stillschweigend repariert wird, ist ein Feed, der an der Quelle nie repariert wird, weil der Lieferant den Schmerz nie spürt. Deshalb muss jede automatische Korrektur trotzdem gemeldet werden.

Was mit dem Data Steward passiert

Jedes Datenteam kennt den Montagmorgen: einundvierzig Alerts vom Wochenende in der Warteschlange, von denen drei echte Probleme sind. Autonome Datenqualität lässt diesen Stapel nicht verschwinden. Sie entfernt den wiederholbaren Teil davon.

Wegfallen wird, denselben Alert zum vierzigsten Mal zu lesen, einem Partner wegen eines Feeds hinterherzulaufen, der schon wieder kaputt ist, und Ladeprozesse um sieben Uhr morgens von Hand neu zu starten. An ihre Stelle treten die Pflege der Bibliothek freigegebener Lösungsmuster, die Entscheidung, was ein mehrdeutiger Wert tatsächlich bedeutet, die Prüfung der Entscheidungen des Agenten in der Gesamtschau und die Festlegung, wie viel Freiheit jedes Datenprodukt erhält. Der Data Steward hört auf, einzelne Probleme zu beheben, und beginnt zu entscheiden, wie Probleme behoben werden. Das ist eine anspruchsvollere Rolle, als die meisten Stewards sie heute innehaben, näher an Governance als am Tagesbetrieb. Niemand wird ersetzt. Ersetzt wird die Arbeit, die schlecht skaliert hat.

Fazit: Präzedenz, Umkehrbarkeit und Belege, nicht Zuversicht

Ein Allzweck-Agent mit Datenbank-Zugangsdaten ist keine autonome Datenqualität. Ohne Katalog weiß er nicht, ob eine Spalte einen Code oder eine Bezeichnung enthält, und er rät mit voller Überzeugung. Ohne Lineage kann er weder einen erneuten Lauf eingrenzen noch einen Wirkungsradius beurteilen. Ohne Musterbibliothek ist jedes Auftreten das erste, nichts summiert sich, und der Steward bekommt nie Zeit zurück. Ohne diese drei hat ein Sprachmodell in der Nähe Ihres Data Warehouse nichts zu suchen.

Deshalb gehört autonome Datenqualität in die Datenqualitätsplattform und nicht daneben. Das Fundament muss bereits vorhanden sein: digna Data Anomalies lernt ohne manuelle Schwellenwerte, wie normal aussieht, digna Data Validation setzt auditierbare Regeln auf Datensatzebene durch, digna Timeliness lernt Ankunftsmuster zusätzlich zu den Zeitplänen, die Sie festlegen, digna Schema Tracker erkennt strukturelle Änderungen, und digna Data Analytics verfolgt, wie sich die Kennzahlen selbst im Zeitverlauf entwickeln. All das läuft In-Database, ohne dass Daten Ihre Umgebung verlassen. Der Vertrauensgradient, das Autonomie-Tor, die Beweiskette und die Musterbibliothek, die hier beschrieben sind, geben die Richtung vor, in die digna sich entwickelt.

Können Daten sich selbst reparieren? Nicht von allein. Aber mit Präzedenz, Umkehrbarkeit und Belegen lässt sich ein wachsender Teil davon beheben, ohne auf den Montag zu warten.

Lernen Sie das Fundament kennen, auf dem autonome Datenqualität aufbaut.

digna lernt über jede Tabelle hinweg, wie normal aussieht, In-Database, in der Cloud oder On-Premise, ohne manuelle Schwellenwerte, die gepflegt werden müssen. Das ist die Belegschicht, die ein Agent braucht, bevor man ihm zutrauen kann zu handeln.

Persönliche Demo buchen → Die digna-Plattform entdecken

Häufig gestellte Fragen

Was ist autonome Datenqualität?

Autonome Datenqualität ist die kontinuierliche, überwiegend KI-gestützte Fähigkeit, Datenqualitätsprobleme mit minimalem menschlichem Eingreifen zu erkennen, zu untersuchen, zu bewerten und zu beheben. Die meisten Werkzeuge hören heute bei der Erkennung auf; autonom sind die Untersuchung, die Folgenabschätzung und eine protokollierte, umkehrbare Korrektur.

Wie unterscheidet sich autonome Datenqualität von Data Observability?

Data Observability lernt Basiswerte für Aktualität, Volumen, Schema und Verteilung und meldet, dass sich etwas verändert hat. Autonome Datenqualität nutzt diese Signale als Auslöser, untersucht dann die Ursache, bewertet, was von den Daten abhängt, und ergreift eine begrenzte Maßnahme wie Quarantäne, Zurückhalten oder Neuladen.

Wann darf ein KI-Agent Daten selbstständig korrigieren?

Vier Prüfungen entscheiden darüber: ob genau dieses Muster schon einmal freigegeben wurde, ob die Aktion umkehrbar ist, ob die Quelle maßgeblich und datiert ist und wie groß der Wirkungsradius ist. Die eigene Zuversicht des Modells ist nie eine dieser Prüfungen, denn sie ist nicht kalibriert.

Welchen Quellen sollte ein Datenqualitäts-Agent vertrauen?

Zuerst der eigenen Wissensbasis: Katalog, Lineage, Verträge und freigegebene Muster. An zweiter Stelle stehen veröffentlichte Register wie die Codelisten von IATA oder ICAO. Das offene Internet dient nur der Orientierung, und das unbelegte Gedächtnis des Modells ist die schwächste Quelle. Ein Agent, der seine Quelle nicht nennen kann, sollte nicht handeln.

Wird autonome Datenqualität den Data Steward ersetzen?

Nein. Sie entfernt den repetitiven Teil der Arbeit, etwa das erneute Lesen desselben Alerts oder das manuelle Neustarten von Ladeprozessen. Der Steward kümmert sich stattdessen um freigegebene Lösungsmuster, entscheidet, was mehrdeutige Werte bedeuten, und legt fest, wie viel Freiheit jedes Datenprodukt erhält. Das ist näher an Governance als am Tagesbetrieb.