Gleb Mezhanskiy hat Jahre damit verbracht, Instruments zu entwickeln, um Unternehmensdaten sauber zu machen. Im März 2026 teilte der CEO von Datafold seinem Publikum mit, dass sich der Aufwand nie so ausgezahlt habe wie die Softwareüberwachung für Unternehmen wie Datadog. Seine Argumentation verändert nun die Definition von Qualität durch Datenführer bis in die zweite Hälfte des Jahres 2026 hinein.
Ein CEO eines Anbieters nennt die Branche eine Enttäuschung
Mezhanskiy legte den Fall in einem Beitrag vom 5. März mit dem Titel „Information Engineering im Jahr 2026: 12 Vorhersagen“ dar. Vorhersage elf argumentiert, dass Datenteams aufhören werden, der Datenqualität hinterherzujagen, weil KI-Agenten sich stattdessen um den Kontext kümmern. Er schrieb, dass jahrelange Investitionen und technische Anstrengungen nie zu einem bahnbrechenden Erfolg geführt hätten, der mit dem Aufstieg von Datadog im Bereich Software program-Überwachung vergleichbar sei. Seiner Aussage nach hat sich die Datenqualität von einem Einzelposten zu Jahreszielen zu etwas entwickelt, mit dem Groups nach besten Kräften umgehen.
Die Behauptung verdient einen Vorbehalt, bevor sie weiter verbreitet wird. Mezhanskiy leitet ein Unternehmen in einem überfüllten Umfeld, und seine Ansicht spiegelt die Sichtweise eines einzelnen Anbieters wider, nicht einen Branchenkonsens. Monte Carlo gab an, 236 Millionen US-Greenback eingeworben zu haben, während Bigeye eine Gesamtfinanzierung von 73,5 Millionen US-Greenback meldete. Datafold kündigte separat eine Serie A in Höhe von 20 Millionen US-Greenback an. Zusammen gaben die drei Unternehmen eine Finanzierung von mindestens 329,5 Millionen US-Greenback bekannt, die sich auf Qualität, Zuverlässigkeit und Beobachtbarkeit verteilte und nicht auf eine einzige Kategorie. Die Bezeichnung „Misserfolg“ hängt davon ab, welcher Maßstab verwendet wird, und Mezhanskiy wählte einen Maßstab, der seine Vorhersage begünstigt.
Warum Daten dem Software program-Playbook widerstehen
Mezhanskiys größte Stärke hat nichts mit Finanzierungsrunden zu tun. Er argumentiert, dass Daten schwieriger zu testen sind als Software program, weil sich die Grundwahrheit ständig verschiebt. Eine Anmeldung gelingt entweder oder nicht. Ein „aktiver Benutzer“ kann drei verschiedene Dinge bedeuten, je nachdem, ob Advertising and marketing, Produkt oder Finanzen danach fragen, und keine Checks auf Spaltenebene können Meinungsverschiedenheiten über Definitionen ausräumen. Fügen Sie einer verrauschten Pipeline weitere Warnungen hinzu, und der Wert jeder neuen Warnung sinkt schnell.
Der Vergleich hält als Spektrum besser als als harte Linie. Sicherheitsteams sind jeden Tag auf der Suche nach mehrdeutigen Signalen, und viele KI-gesteuerte Software program liefert Ergebnisse, die niemand mit Sicherheit überprüfen kann. Software program-Grundwahrheit ist nicht immer so sauber, wie Mezhanskiys Darstellung nahelegt. Was Daten auszeichnet, ist das Ausmaß der Mehrdeutigkeit: Ein einziges Lager kann Dutzende widersprüchlicher Definitionen für dasselbe Geschäftskonzept enthalten, und ein Softwareteam sieht sich selten am selben Nachmittag mit so vielen Abspaltungen konfrontiert.
Was KI-Agenten brauchen
Hier ist der Teil von Mezhanskiys Argumentation, der es wert ist, trotz der damit verbundenen Vorbehalte ernst genommen zu werden. Ein Agent, der aus einem Lager abruft, benötigt mehr als eine validierte Spalte. Es braucht eine Abstammung, die zeigt, woher eine Zahl stammt, die Transformationslogik dahinter, eine Dokumentation, die erklärt, warum eine Fallback-Tabelle existiert, und eine Ontologie, die Geschäftseinheiten wie Kunde, Bestellung und Produkt verbindet. Mezhanskiy nennt die Kombination einen Kontextgraphen, und Datafold verkauft nun einen solchen neben seinen herkömmlichen Qualitätstools.
Es lohnt sich direkt zu sagen: Mezhanskiy ist kein neutraler Erzähler. Sein Unternehmen profitiert, wenn Käufer ihre Ausgaben von der Qualitätsüberwachung auf die Kontextebene verlagern, die seine Vorhersage beschreibt, und der finanzielle Einsatz verschwindet nicht, nur weil das zugrunde liegende Argument vernünftig ist. Das Argument hat immer noch eine Grenze: Der Kontext hilft einem Agenten, eine Zahl richtig zu interpretieren, aber er verwandelt eine beschädigte, veraltete oder voreingenommene Zahl nicht in eine sichere Zahl. Die Abstammung teilt einem Agenten mit, woher die Daten stammen, und nicht, ob die Daten überhaupt Vertrauen verdient haben.
Wie risikobasierte Datenqualität in der Praxis aussieht
Der nützlichste Beweis in dieser Debatte ist keine Vorhersage. Es handelt sich um ein Muster, das sich bereits in der Artwork und Weise zeigt, wie Groups Datenverträge erstellen. Der von Bitol unter Apache 2.0 über die LF AI and Information Basis veröffentlichte Open Information Contract Customary definiert ein herstellerneutrales YAML-Format, das Schemata, Qualitätsregeln, Eigentumsverhältnisse, Supportkanäle und Servicelevel abdeckt. Groups verwenden den Customary, um zu formalisieren, was ein Datensatz verspricht, ohne sich an die Plattform eines Unternehmens zu binden.
Eine Handvoll Betriebsgewohnheiten trennen Groups davon, wie sie aus Verträgen Nutzen ziehen, von Groups, die Papierkram hinzufügen:
- Übertragen Sie die Verantwortung auf das Workforce, das einen Datensatz erstellt, und nicht auf das Workforce, das ihn drei Pipelines weiter unten verbraucht.
- Speichern Sie Verträge als Code in der Versionskontrolle und nicht als Folienstapel, den niemand mehr öffnet.
- Führen Sie Prüfungen im CI oder in der Pipeline selbst durch, damit ein Verstoß erkannt wird, bevor er ein Dashboard oder einen Agent erreicht.
Die Leitlinien von Monte Carlo fordern Kunden dazu auf, die Verträge schlank zu halten und sich auf Pipelines zu konzentrieren, die echtes Geschäftsgewicht tragen, und nicht auf jeden Tisch im Lager. Soda und Atlan unterstützen das gleiche Muster durch YAML-Dateien, Git-Workflows und Regeldurchsetzung und stellen ihre Instruments nicht als Anforderung dar: Beide betrachten die Automatisierung als eine Annehmlichkeit, die über einer Disziplin liegt, die ein Workforce mit einem Texteditor und einer CI-Pipeline ausführen könnte.
Der Gegenbeweis
Marktforscher unterstützen keinen Kollaps der Ausgaben für Datenqualität. Mordor Intelligence schätzt, dass der Markt für Datenqualitätstools von 3,27 Milliarden US-Greenback im Jahr 2026 auf 7,39 Milliarden US-Greenback im Jahr 2031 wachsen wird, was einer durchschnittlichen jährlichen Wachstumsrate von 17,7 Prozent entspricht. Behandeln Sie die Zahl als kommerzielle Schätzung und nicht als geprüfte Gesamtsumme. Verschiedene Forschungsunternehmen definieren die Kategorie unterschiedlich und stoßen auf nicht übereinstimmende Zahlen, was für einen derart fragmentierten Markt regular ist und mehr über inkonsistente Definitionen als über den zugrunde liegenden Pattern aussagt.
Die sicherere Lektüre lautet: Die Ausgaben steigen weiter, während die Definition von Qualität umfassender wird. Für diesen Artikel wurden keine Belege überprüft, die zeigen, dass sich die Budgets von der Qualitätsüberwachung hin zu Kontextdiagrammen verlagern. Die 2026 State of Information Engineering Survey von Joe Reis, die Ende 2025 über einen Zeitraum von zwei Wochen unter 1.101 Praktikern durchgeführt wurde, bringt eine einfache Aussage zum Ausdruck: Qualität ist bei niemandem auf der Sorgenliste gelandet. 34 Prozent der Befragten gaben an, dass die Datenqualität oder -zuverlässigkeit die Teamzeit stark belastet, und etwas mehr als zehn Prozent nannten sie den größten organisatorischen Engpass. Die Befragten sind vorwiegend in Nordamerika und Europa befragt und konzentrieren sich auf Nordamerika und Europa. Reis beschreibt die Prozentsätze als Richtwerte und nicht als endgültig. Trotz Vorbehalten deutet die Umfrage auf Groups hin, die durch Qualitätsarbeit überlastet sind, und nicht auf Groups, die sich davon abwenden.
Ein Framework zur Tiering-Datenqualität
Der praktische Schritt besteht nicht darin, sich zwischen Mezhanskiys Vorhersage und den Umfragedaten zu entscheiden. Es geht darum, damit aufzuhören, jeden Datensatz so zu behandeln, als ob er das gleiche Maß an Prüfung verdient. Ein vierstufiges Modell bietet Datenverantwortlichen einen Ausgangspunkt für die Entscheidung, wo strenge Verträge hingehören und wo eine einfachere Dokumentation sinnvoll ist.
Stufe 0 deckt Einnahmen und aufsichtsrechtlich kritische Daten ab: Abrechnungssysteme, Finanzberichts-Feeds und Compliance-Einreichungen. Jeder Datensatz erhält hier einen formellen Vertrag, automatisierte Prüfungen in CI, einen benannten Eigentümer und eine Bereitschaftsseite, wenn etwas fehlschlägt.
Stufe 1 deckt kunden- und produktkritische Daten ab: Dashboards, die Kunden direkt sehen, Kennzahlen, die Führungskräfte extern melden, und Funktionen des maschinellen Lernens, die kundenorientierte Vorhersagen liefern. Jeder Datensatz erhält weiterhin einen formellen Vertrag mit geplanten Überprüfungen und einer an den Eigentümer weitergeleiteten Warnung, allerdings ohne dass um 2 Uhr morgens irgendjemand angerufen wird
Stufe 2 deckt interne und betriebliche Daten ab: Advert-hoc-Berichte, interne Analysen und Experimentiertabellen. Eine einfache Dokumentation und eine erhaltene Abstammungslinie sind hier wichtiger als ein formeller Vertrag, da ein Fehler innerhalb eines Groups bleibt.
Stufe 3 deckt explorative Daten ab: einmalige Exporte, Scratch-Tabellen und Prototyp-Datensätze. Es gilt kein Vertrag, es gibt keine Qualitätsgarantie und jeder Datensatz trägt ein klares Etikett, auf dem dies steht.
Drei Fragen platzieren die meisten Datensätze richtig.
Würde eine falsche Nummer einen finanziellen Verlust, ein rechtliches Risiko oder ein Drawback bei der Einreichung der behördlichen Unterlagen auslösen?
Stufe 0. Wird der Datensatz einer kundenorientierten Oberfläche oder einer außerhalb des Unternehmens gemeldeten Metrik zugeführt?
Tier 1, es sei denn, das finanzielle oder regulatorische Risiko hat es bereits auf Tier 0 gebracht. Verlässt sich mehr als ein Workforce bei Entscheidungen auf den Datensatz, ohne dass externe oder regulatorische Interessen damit verbunden sind?
Stufe 2. Alles, was übrig bleibt, einschließlich einmaliger Exporte und Prototypen, wird standardmäßig auf Stufe 3 gesetzt.
Sobald ein Datensatz einen Vertrag erhält, benötigt das Dokument unabhängig vom Format sechs Felder:
- Schema und Datentypen für jedes Feld, das ein Verbraucher berühren könnte, mit Angabe von Nullable-Feldern und erwarteten Bereichen.
- Frische- und Verfügbarkeitsziele werden als Zahl und nicht als Beschreibung angegeben: innerhalb von vier Stunden aktualisiert, an 99,5 Prozent der Werktage verfügbar.
- Qualitätsschwellenwerte und die Prüfungen, die sie durchsetzen: Vollständigkeit, Eindeutigkeit und alle für den Datensatz spezifischen Geschäftsregeln.
- Ein benanntes Produzententeam, ein benanntes Verbraucherteam und ein Eskalationspfad für den Fall, dass die beiden nicht einverstanden sind.
- Ein Änderungsmanagementprozess, der beschreibt, wie Schemaänderungen angekündigt werden und wie lange Verbraucher Zeit haben, sich anzupassen.
- Ein namentlich genannter Supportkanal, bei dem ein Verbraucher ein Drawback meldet und eine Reaktionszeitzusage erhält.
Stellen Sie sich als anschauliches Beispiel ein Abonnementunternehmen vor, das seine monatlich wiederkehrende Umsatztabelle der Stufe 0 zuordnet. Die sechs Felder könnten lauten:
- Schema: customer_id (Zeichenfolge, nicht null), mrr_amount (dezimal, null oder größer), billing_period (Datum).
- Aktualität: Wird innerhalb von vier Stunden nach jedem Abrechnungslauf aktualisiert.
- Qualitätsprüfungen: Vollständigkeit bei 99,9 Prozent oder höher, Eindeutigkeit durchgesetzt für customer_id plus billing_period.
- Verantwortung: Das Billing Platform-Workforce erstellt die Tabelle, Finance Reporting nutzt sie und Streitigkeiten werden innerhalb von 15 Minuten an den Datentechniker auf Abruf weitergeleitet.
- Änderungsmanagement: Schemaänderungen werden zwei Wochen im Voraus im Kanal #data-contracts angekündigt.
- Assist: Ein benannter Posteingang verpflichtet zu einer Antwort innerhalb eines Werktages.
Ein Rubbeltisch, der eine einmalige Kohortenanalyse speist, benötigt nichts davon. Die Kosten für das Schreiben von sechs Feldern für jede Tabelle im Warehouse sind genau der Grund, warum die meisten Vertragsprogramme ins Stocken geraten, und es gibt Tiering, um die Kosten auf die Daten zu beschränken, wo sie sich amortisieren.
Datenverantwortliche, die dieses Modell verfolgen, sollten die Auswirkungen von Vorfällen, die Erkennungszeit, die Menge an Fehlalarmen und Vertragsverstöße nach Stufen im Auge behalten und nicht einen einzigen unternehmensweiten Qualitätsfaktor, der verbirgt, wo der tatsächliche Schaden entsteht. Ein Verstoß der Stufe 0 und ein Verstoß der Stufe 3 sind nicht dasselbe Ereignis, und ein Dashboard, das sie gleich behandelt, wird das Sign, das Führungskräfte am meisten brauchen, unterdrücken.
Wo die Tierung zusammenbricht
Zwei Fehlermodi treten quick sofort auf, wenn ein Workforce ein Stufenmodell übernimmt, und keiner betrifft das Framework selbst.
Das erste ist das Stufenkriechen. Jedes Workforce glaubt, dass seine Daten am wichtigsten sind, und ein Modell ohne Durchsetzungsmechanismen tendiert dazu, alles innerhalb eines Jahres als Tier 0 zu kennzeichnen. Die Lösung ist eher verfahrenstechnischer als technischer Natur: Leiten Sie Tier-0-Nominierungen über die Finanzabteilung, die Rechtsabteilung oder die Funktion weiter, die das regulatorische Risiko besitzt, und verlangen Sie einen angegebenen Dollarbetrag oder eine Compliance-Zertifizierung, bevor ein Datensatz das Label erhält.
Der zweite Fehlermodus knüpft direkt an Mezhanskiys Argumentation an. Eine Ebenenzuweisung bleibt im Kopf einer Particular person oder auf einer Wiki-Seite, es sei denn, jemand schreibt sie in Metadaten, die ein Agent oder eine Abfragemaschine lesen kann. Ein KI-Agent, der aus einem Lagerhaus greift, kann nicht erkennen, dass es sich bei einer Tabelle um einen Tier-3-Scratch-Datensatz handelt, es sei denn, die Zuweisung erfolgt mit der Tabelle selbst, über Tags, einen Katalogeintrag oder das Kontextdiagramm, das Mezhanskiys Unternehmen verkauft. Überspringen Sie den Tagging-Schritt, und ein Agent kann aus einer nicht überprüften Prototypentabelle eine Frage der Stufe 0 beantworten. Das Ergebnis verwandelt einen Datensatz mit geringem Einsatz in eine Entscheidung mit hohem Einsatz, und niemand bemerkt es, bis etwas kaputt geht.
Für die Ebenen ist außerdem ein Überprüfungsrhythmus erforderlich, da das Risikoprofil eines Datensatzes selten unverändert bleibt. Eine Kohortenanalyse, die für eine Vorstandssitzung erstellt wurde, kann sich innerhalb von zwei Quartalen in eine wiederkehrende Kennzahl verwandeln, die ein CFO extern zitiert. Zu diesem Zeitpunkt ist der Datensatz stillschweigend von Tier 3 auf Tier 1 übergegangen, ohne dass jemals ein Vertrag damit verbunden struggle. Eine vierteljährliche Re-Tiering-Überprüfung, die von demjenigen durchgeführt wird, der die Datenplattform betreibt, erkennt Abweichungen, bevor eine Metrik extern veröffentlicht wird.
Datenteams geben bei der Qualität nicht auf. Sie geben zu, dass die allgemeine Absicherung schon immer eine Fiktion struggle, und diese Fiktion wurde teurer, als KI-Agenten anfingen, in denselben Lagerhäusern zu arbeiten, die früher Menschen von Hand babysitteten. Starke Programme im Jahr 2026 werden schriftlich entscheiden, wo schlechte Daten echten Schaden anrichten, sich energisch behaupten und genügend Kontext hinterlassen, damit Menschen und Maschinen alles andere mit offenen Augen angehen können.