Man verbringt Wochen damit, einen KI-Chatbot abzustimmen. Die Antworten sind korrekt. Stakeholder geben grünes Licht, und das System geht live. Drei Monate später liegt das System bei etwa einem Drittel der Nutzerfragen mit voller Überzeugung falsch. Niemand hat das Modell geändert, und niemand hat die Prompts angefasst. Die Welt hat sich weiterbewegt, Preise haben sich geändert, eine Richtlinie wurde aktualisiert, eine Produktspezifikation erschien in einer neuen Version, und der zugrunde liegende Wissensspeicher ist nicht mitgezogen.

Das ist kein hypothetisches Szenario. Es ist derzeit einer der häufigsten Fehlermodi in Produktivumgebungen von Enterprise-KI, und die meisten Data-Engineering-Teams haben nicht die richtigen Werkzeuge, um ihn zu erkennen — unabhängig davon, wie das KI-System die Daten abruft. Während Unternehmen von KI-Pilotprojekten zu produktiven Implementierungen im großen Maßstab übergehen — Gartner hat Datenqualität wiederholt als eines der größten Hindernisse für die Einführung von KI identifiziert — entwickelt sich diese Fehlerklasse von einem gelegentlichen Ärgernis zu einem systemischen Risiko.

Der Fehler, der nicht wie ein Fehler aussieht

Einer KI-Anwendung ist es gleichgültig, ob sie aus einem Vektorspeicher, einem Dokumentenindex oder über einen API-Aufruf abruft. Unabhängig vom Mechanismus prüft in einer Standard-Retrieval-Pipeline nichts, ob das, was sie ausliefert, noch korrekt ist. Ein veraltetes Preisdokument wird mit derselben Zuversicht abgerufen wie ein aktuelles, weil das System Relevanz oder Verfügbarkeit bewertet, nicht Korrektheit. Ein Datensatz mit einem stillschweigend fehlenden Feld läuft aus demselben Grund genauso sauber durch wie ein vollständiger.

Der Fehler ist also konstruktionsbedingt unsichtbar. Veraltete oder unvollständige Daten erzielen weiterhin hohe Relevanzwerte oder bestehen jede Prüfung, für die eine Datenpipeline gebaut wurde. Das Modell antwortet mit voller Sicherheit, weil der abgerufene Kontext autoritativ wirkt. Jedes Dashboard, das man beobachtet, bleibt grün. Das System sieht so aus, als würde es funktionieren. Es ist nur falsch.

Ich habe eine ähnliche Variante davon außerhalb des KI-Kontexts in einer Fintech-Pipeline erlebt. Ein vorgelagertes System änderte ein Feld, ohne nachgelagerte Nutzer zu informieren. Die Pipeline fiel nicht aus; sie übertrug lediglich fehlerhafte Werte in Dashboards, weil das System nur prüfte, ob der Job abgeschlossen war, nicht aber, ob die Daten weiterhin korrekt waren. Das Problem fiel erst auf, als ein Kunde eine Inkonsistenz bemerkte. Zu diesem Zeitpunkt waren die fehlerhaften Daten bereits nachgelagert weitergegeben worden.

Ob es sich um ein veraltetes Dokument oder ein stillschweigend fehlendes Feld handelt, die Form des Fehlers ist dieselbe: Die Abwesenheit eines Fehlers ist kein Nachweis für Korrektheit, und ohne geeignete Validierungsschichten kann in der Pipeline nichts das Problem identifizieren. Gleichzeitig steigen die Risiken, weil KI-Agenten von der Beantwortung von Fragen zur Ausführung von Handlungen übergehen — ein Agent, der auf Grundlage veralteter Preise oder einer überholten Richtlinie handelt, könnte eine falsche Transaktion ausführen, nicht nur eine falsche Antwort liefern.

Warum dies ein Data-Engineering-Problem ist

Teams, die auf diesen Fehler stoßen, diagnostizieren ihn häufig falsch — und oft gleich zweimal.

Dem Modell die Schuld geben: Der erste Impuls ist, dem Modell die Schuld zu geben, ein anderes LLM auszuprobieren oder den Prompt anzupassen. Das eigentliche Problem liegt weiter vorgelagert, auf der Data-Engineering-Ebene — derselbe Instinkt wie beim oben beschriebenen Fintech-Fehler: Monitoring, das für die Pipeline gebaut wurde, nicht für die Daten.

Der Retrieval-Schicht die Schuld geben: Sobald das Modell ausgeschlossen ist, besteht der nächste Impuls darin, stattdessen die Retrieval- oder Kontextschicht verantwortlich zu machen und eine bessere zu kaufen. Der Zeitpunkt ist kein Zufall. Wenn Unternehmen diese Systeme in die reale Produktion bringen, tritt genau diese Lücke zutage, und die Reaktion der Anbieter ist überall zu sehen. AWS ist gerade mit einem Knowledge Graph, der aus der Nutzung durch Agenten lernt, in das Rennen um die „context layer“ eingestiegen. Snowflakes neue Produkte Horizon Context und Cortex Sense zielen genau auf das Symptom, mit dem dieser Beitrag eröffnet wurde: Agenten geben selbstbewusst falsche Antworten, weil nichts die ihnen zugrunde liegende Geschäftslogik steuert.

Beides sind echte Antworten auf ein echtes Problem, aber sie setzen eine Ebene darüber an; ein Knowledge Graph hängt weiterhin davon ab, womit er gespeist wird. Das eigentliche Problem liegt weiter vorgelagert, auf der Data-Engineering-Ebene. Teams prüfen, ob ein Job gelaufen ist, nicht ob die Daten, die er bewegt hat, weiterhin wahr sind — ein Instinkt, der viele Jahre älter ist als KI. Monitoring ist für die Pipeline gebaut, nicht für die Daten.

Was tatsächlich fehlt: Data Observability

Data Observability ist ein bekanntes Konzept, dem bei der tatsächlichen Umsetzung nicht genügend Aufmerksamkeit geschenkt wird. Die Kategorie selbst ist in den vergangenen Jahren gereift — Unternehmen wie Monte Carlo Data und andere haben spezialisierte Plattformen dafür aufgebaut, und IBM übernahm Databand im Jahr 2022, um die eigenen Data-Observability-Fähigkeiten zu stärken — dennoch bleibt die Einführung uneinheitlich, insbesondere bei Teams, die erst vor Kurzem begonnen haben, KI-Anwendungen auf bestehender Dateninfrastruktur aufzubauen.

Die relevante Kennzahl ist kein Prozentsatz — es ist Abdeckung: Welcher Anteil kritischer Datensätze hat eine tatsächlich abfragbare Herkunftslinie, statt nur im Kopf einer Person zu existieren?

Uber baute eine spezialisierte Plattform für Datenqualität und Observability, lange bevor Retrieval-Augmented Generation existierte. Die Unified Data Quality-Plattform unterstützt mehr als 2,000 kritische Datensätze und erkennt rund 90% der Datenqualitätsvorfälle, bevor sie nachgelagerte Verbraucher erreichen.

Netflix löste einen anderen Teil desselben Problems, indem das Unternehmen ein unternehmensweites Data-Lineage-System aufbaute, damit jeder nachvollziehen konnte, woher ein Datensatz stammt und was ihn unterwegs verändert hat. Es bildet Abhängigkeiten über Kafka-Topics, ML-Modelle und Experimente hinweg ab, nicht nur Warehouse-Tabellen. Ähnlich wie bei Uber wurde die Plattform für Menschen gebaut, und mit dem Aufstieg von KI-/LLM-Anwendungen ist sie nun noch wichtiger geworden.

Zusammen decken Uber und Netflix zwei der vier Dinge ab, für die es sich zu bauen lohnt. In der Praxis betrachte ich das als vier Dimensionen, die jeweils nach eigenen Maßstäben messbar sind.

Korrektheit: Entspricht jeder Datensatz der vorgesehenen Form und den vorgesehenen Regeln — richtige Feldtypen, keine unerwarteten Nullwerte, Werte im zulässigen Bereich. Tools wie Great Expectations und Soda leisten hier gute Arbeit: automatisierte Validierung auf Zeilen- und Spaltenebene statt manueller Prüfungen, nachdem etwas kaputtgegangen ist. Verfolgt werden sollte der Prozentsatz der Datensätze, die pro Lauf die Validierung bestehen.

Aktualität: Sind die Daten im Verhältnis zu ihrer Quelle noch aktuell, nicht nur zum Zeitpunkt der letzten Prüfung. Verfolgt werden sollte die Zeit seit der letzten erfolgreichen Aktualisierung pro Quelle, mit einem SLA pro Datensatz statt eines pauschalen Schwellenwerts, da manche Quellen stündliche Aktualisierungen benötigen und andere nicht.

Konsistenz: Wird derselbe Fakt überall dort, wo er gespeichert oder indexiert ist, auf dieselbe Weise gelesen? Dies scheitert still — es zeigt sich erst, wenn zwei Systeme, die aus derselben Quelle gespeist werden, einander widersprechen. Eine regelmäßige Gegenprüfung zwischen nachgelagerten Zielen, die eine Abweichungsrate oberhalb eines Schwellenwerts markiert, reicht aus, um es frühzeitig zu erkennen.

Herkunft: Lässt sich jede Ausgabe bis zu ihrer Quelle und zu jeder Transformation zurückverfolgen, die sie durchlaufen hat — genau die Frage, für deren Beantwortung Netflix sein System gebaut hat.

Nichts davon erfordert Infrastruktur, über die die meisten Datenteams nicht ohnehin bereits verfügen. Ich weiß das, weil ich es gebaut habe, nicht nur, weil ich dafür argumentiert habe.

Bei Socure kamen Kundendaten in der Form an, in der der Kunde sie gerade senden wollte, und gelegentlich waren sie stillschweigend falsch. Die Herausforderung bestand darin, ein System zu bauen, in dem fehlerhafte Daten identifiziert werden konnten, bevor sie nachgelagert weitergegeben wurden. Dieselben Prinzipien galten: validieren, was ankommt, verstehen, woher es stammt, und verhindern, dass schlechte Daten zum Problem eines anderen werden.

Great Expectations wurde Teil dieses Fundaments: Schema- und Bereichsvalidierung bei der Aufnahme, SLAs pro Quelle für Aktualität, systemübergreifende Prüfungen auf Konsistenz und Lineage auf Dateiebene. All das stand hinter einem Write-Audit-Publish-Muster, bei dem Daten zunächst in einer Staging-Umgebung landeten, validiert wurden und nur dann nachgelagert weiterwanderten, wenn sie die erforderlichen Prüfungen bestanden.

Das Ergebnis zeigte sich nachgelagert: bessere Genauigkeit auf breiter Front, im Reporting, in den ML-Modellen und im KI-Retrieval, das auf denselben Daten aufbaute.

Was am Montagmorgen zu tun ist

Wenn Sie retrievalbasierte KI-Systeme in Produktion betreiben, lautet die Diagnosefrage nicht, welches Modell als Nächstes ausprobiert oder zu welcher Retrieval-Architektur migriert werden sollte. Es sind vier engere Fragen:

1. Werden die zugrunde liegenden Daten gegen die Standards validiert, die ihre Verbraucher verlangen?
2. Was ist das älteste Inhaltelement, das derzeit mit hoher Sicherheit ausgeliefert wird?
3. Könnten zwei Abschnitte derselben Quelle im selben Retrieval-Ergebnis jemals einander widersprechen?
4. Könnten Sie zurückverfolgen, woher es kam, wenn es sich als falsch herausstellt?

Wenn Sie diese Fragen nicht beantworten können, liegt die Lücke in der Pipeline zwischen Ihren Quellsystemen und dem, woraus Ihr Agent liest. Das ist eine Data-Engineering-Korrektur, kein Modellwechsel und keine Migration zu einem anderen Anbieter.

Ob Sie Reporting-Pipelines, ML-Systeme oder KI-Agenten bauen: Korrektheit, Aktualität, Konsistenz und Herkunft machen Daten vertrauenswürdig. KI legt lediglich Schwächen offen, die im Data Engineering schon immer existiert haben.