Warum R&D-Daten ins Lakehouse gehören – und warum Agenten sie dort brauchen

Das Setup

Bei cellcentric, einem Joint Venture von Daimler Truck und der Volvo Group, entwickeln und bauen wir Wasserstoff-Brennstoffzellensysteme für schwere Nutzfahrzeuge. Unsere Arbeit ist stark von R&D, Engineering und Daten geprägt. Die Fragen, die unsere Teams stellen, lassen sich selten über ein einziges Quellsystem beantworten. Sie umfassen Produkthierarchien, Fertigungshistorien, Nacharbeiten, Laborergebnisse, Testtelemetrie und Domänenwissen.

Das ist die zentrale Herausforderung für industrielle AI in der R&D. Ein Agent ist nur dann nützlich, wenn er logische Schlüsse über denselben governed Kontext ziehen kann, den auch ein Engineer benötigt, um einer Antwort zu vertrauen: woher die Daten stammen, was sie bedeuten, wie vollständig sie sind, welche Einschränkungen wichtig sind und ob der Benutzer sie überhaupt sehen darf. Diesen in einen AI-bereiten Kontext zu verwandeln, beginnt mit dem Data Engineering noch vor der Modellauswahl.

Aus diesem Grund haben wir die letzten vier Jahre damit verbracht, unsere Datenbasis auf Azure und Databricks aufzubauen. Unity Catalog war von Anfang an Teil der Architektur. Lakehouse Federation hat On-Premises-SQL-Quellen in das Lakehouse-Muster integriert. Delta Sharing half uns dabei, Daten über Grenzen hinweg auszutauschen. Databricks Asset Bundles boten uns einen produktionsreifen Pfad für Pipelines und Datenprodukte. Das Ergebnis ist der Data Hub: unsere governed Kontextschicht für Daten und AI, mit einer Benutzeroberfläche für Mitarbeitende und einem MCP-Server für Agenten.

Der Data Hub begann als Plattform für Datenprodukte. Rückblickend ist genau dieses Fundament der Grund, warum er so gut als AI-Plattform funktioniert.

Der Fuel Cell Passport

Dieses Fundament lässt sich am besten anhand eines einzelnen Datenprodukts erklären: dem Fuel Cell Passport. Er führt fünf Enterprise-Quellsysteme zusammen, darunter SAP S/4HANA, zwei MES-Systeme für Fertigung und Nacharbeit, eine Labordatenbank und eine IoT-Telemetrieplattform. Er modelliert sieben Hierarchieebenen vom Gesamtsystem bis hin zur Rohstoffcharge, wird täglich aktualisiert und nutzt ein zustandsbasiertes temporales Modell, sodass Teams sowohl Fragen zur Konfiguration zu einem bestimmten Zeitpunkt als auch zur vollständigen Nacharbeitshistorie beantworten können. Tägliche Datenqualitätsprüfungen überwachen, ob das Produkt vollständig genug ist, um Untersuchungen in den Bereichen Engineering, Qualität und Fertigung zu unterstützen. Der Name spiegelt die Rückverfolgbarkeits- und Lebenszykluskonzepte eines Produktpasses wider, aber der Fuel Cell Passport ist ein internes Engineering-Datenprodukt – kein regulatorisches Compliance-Artefakt wie der EU Digital Product Passport (DPP), obwohl dieselbe Grundlage für die Rückverfolgbarkeit einen solchen unterstützen würde.

Das klingt nach einer klassischen Lakehouse-Erfolgsgeschichte: Quellen integrieren, Domäne modellieren, Zugriff steuern, Daten wiederverwendbar machen. Für AI liegt der strukturelle Kern im verknüpften Kontext: ein governed Produkt um die modellierten Daten herum.

Kontext als Qualitätsmetrik

Unity Catalog liefert uns die governed Struktur: Tabellen, Spalten, Ownership, Lineage, Klassifizierungen und Berechtigungen. Der Data Hub fügt die Produktschicht hinzu. Ein Datenprodukt kombiniert Ownership, Lebenszyklusstatus, Domänenzuordnung, verknüpfte governed Assets und Kontexteinträge, die erklären, wofür das Produkt gedacht ist und wie es verwendet werden sollte.

Diese Unterscheidung ist für AI entscheidend. Agenten benötigen mehr als nur Schema-Metadaten und mehr als nur ein Dokument. Sie müssen verstehen, welche geschäftlichen Fragen ein Datenprodukt unterstützt, wie die wichtigen Tabellen zusammenhängen, welche Einschränkungen eine Rolle spielen und welche begleitenden Assets damit verwendet werden sollten. Wir speichern diesen reichhaltigeren Kontext dauerhaft in der Datenprodukschicht, einschließlich umfangreicher Markdown-Katalogeinträge, die bereits während des Entwicklungsprozesses geschrieben werden, solange der Projektkontext noch frisch ist.

Dies hat unsere Denkweise über Datenqualität verändert. Vollständigkeit und Aktualität sind zwar nach wie vor wichtig, reichen aber nicht mehr aus. Für AI-bereite Daten ist die Kontextabdeckung (Context Coverage) zu einer erstklassigen Qualitätsmetrik geworden.

In unserem Marketplace trägt jedes Datenprodukt ein Badge für die Kontextabdeckung. Es zeigt an, ob Tabellenbeschreibungen vorhanden sind und wie viel Dokumentation auf Spaltenebene für die verknüpften Tabellen des Produkts existiert. Das Badge hat die Metrik sichtbar und umsetzbar gemacht. Die Abdeckung stieg, weil die Engineers die Lücke direkt auf der Produktoberfläche sehen konnten, auf der die Daten konsumiert werden.

Die Metrik ist kein Beleg dafür, dass jede semantische Unklarheit gelöst wurde. Sie ist ein praktischer Indikator (Proxy), der fehlenden Kontext früh genug sichtbar macht, um ihn zu beheben. Historisch gesehen hat sich die Kontextabdeckung verbessert, weil das Badge die Dokumentation von einer nachträglichen Aufräumarbeit in etwas verwandelt hat, das Engineers als Teil der Bereitstellung sehen, messen und verbessern konnten.

Heute haben wir 27 veröffentlichte Datenprodukte, alle mit einer reichhaltigen Markdown-Dokumentation. Veröffentlichte Produkte weisen im Durchschnitt eine Spaltenkommentar-Abdeckung von 90 % auf, wobei die meisten Spaltenkommentare während der Data-Engineering-Arbeit AI-unterstützt erstellt und vor dem Merge vom Engineer überprüft wurden. Der Katalogeintrag fügt eine weitere Kontextschicht hinzu: eine ausführliche Markdown-Zusammenfassung des Entwicklungs-Workflows, der Domänenentscheidungen, der Tabellenbeziehungen, der Einschränkungen und der vorgesehenen Wege zur Nutzung des Produkts.

Die entscheidende Veränderung besteht darin, dass die Dokumentation Teil des Engineering-Workflows wird und anschließend als strukturierter Produktkontext für den nächsten Menschen oder Agenten zur Verfügung steht, der logische Schlüsse aus den Daten ziehen muss.

Eine UI für Menschen, ein MCP für Agenten

Der Data Hub ist die Schicht, die dieses Substrat nutzbar macht. Für menschliche Nutzer ist er ein Marktplatz und eine Workbench. Mitarbeitende können Datenprodukte entdecken, Owners und den Lebenszyklusstatus einsehen, verknüpfte Dashboards und Apps öffnen, über Unity Catalog gesteuerte (governed) Daten abfragen und eine Chat-Schnittstelle für die Erkundung in natürlicher Sprache nutzen. Für AI-Clients wird derselbe Kontext über MCP bereitgestellt. Jeder MCP-fähige Coding-Agent oder -Assistent kann auf dieselben Unity Catalog-Metadaten und denselben Datenproduktkontext zugreifen, die auch der Data Hub verwendet.

Das Governance-Modell

Die Architektur ist bewusst um ein einziges Betriebsmodell herum aufgebaut. Die Identität wird durchgängig weitergegeben. Der Datenzugriff bleibt governed. Modell- und Tool-Aufrufe sind beobachtbar. Traces und Evaluierungen fließen in Verbesserungen ein.

Dies funktioniert nur, weil Governance von Anfang an in die Plattform integriert wurde. Produktions-Ownership, Deployment und Konsum sind getrennte Bereiche. Engineers ändern Pipelines und Produktdefinitionen durch überprüften Code und governed Deployment-Pfade. Konsumenten, einschließlich Agenten, erhalten keine Schreibidentitäten für die Produktion. Sie greifen über den Data Hub, Dashboards, Genie, SQL-Tools oder MCP unter Verwendung der Identität des authentifizierten Benutzers auf Daten zu, wobei Unity Catalog die endgültige Autorisierungsentscheidung trifft.

Diese Unterscheidung ist es, die den Zugriff von Agenten kontrollierbar (governable) macht. Ein Agent kann logische Schlüsse über denselben Produktkontext ziehen, den auch ein Benutzer sieht, und er kann Tools im Namen des Benutzers aufrufen. Er kann jedoch kein Produktions-Writer werden oder Unity Catalog mit gemeinsamen Backend-Anmeldeinformationen umgehen. Wenn dem Benutzer der Zugriff auf eine Tabelle, eine maskierte Spalte oder eine governed View fehlt, stößt der Agent an dieselbe Grenze. Dieses Betriebsmodell ermöglicht es uns, Agenten den Zugriff auf Daten zu erlauben, ohne einen zweiten, weniger restriktiven Pfad um die Plattform herum zu schaffen.

Die Identität beginnt in Azure AD und fließt über den Data Hub in Databricks mittels OAuth 2.0-Token-Austausch – dem On-Behalf-Of-Token-Weitergabemuster, das Databricks in seiner Agent-Governance-Architektur beschreibt. Ein Benutzer, der eine Tabelle über die UI abfragt, ein Agent, der ein SQL-Tool aufruft, und ein Genie-Workspace, der als governed Tool-Aufruf gestartet wird, agieren alle innerhalb derselben Berechtigungsgrenze. Wenn der Benutzer nicht auf die zugrunde liegenden Daten zugreifen kann, kann dies auch der im Namen dieses Benutzers handelnde Agent nicht. Das ist das Zugriffsmodell, das den Data Hub nützlich macht, ohne dass er zu einem parallelen Governance-System wird.

Auf der AI-Seite betreiben wir benutzerdefinierte Agenten auf Databricks Model Serving, nutzen Claude über Foundation Model APIs und rufen Genie-Workspaces als governed Tools auf, wo es sinnvoll ist. Die MCP-Architektur ist von Grund auf hybrid ausgelegt: Von Databricks verwaltetes MCP bietet governed Zugriff auf Databricks-Funktionen wie Genie-Tool-Aufrufe, und unser eigenes MCP liefert die reichhaltigere Kontextschicht – Unity Catalog-Metadaten, Datenproduktobjekte und Katalog-Markdown – sowie die geschäftsspezifischen Tools, die Agenten darüber hinaus aufrufen. Agenten benötigen beides.

Observability und Evaluierung

Mit Observability wird die Architektur betriebsbereit. Unity AI Gateway leitet jetzt den Traffic von Foundation-Modellen in unserer Umgebung weiter. Mit einer kleinen Änderung am Modell-Client fließen die Modellaufrufe des Data Hubs durch eine einzige Governance- und Observability-Ebene, bei der Nutzungsverfolgung und Inference-Tabellen aktiviert sind. Da Anfragen und Antworten in Delta-Tabellen von Unity Catalog landen, können sie mit denselben SQL-Mustern analysiert werden, die wir bereits für Geschäftsdaten verwenden.

MLflow-Tracing bietet uns die nächste Ebene der Sichtbarkeit. Wir standardisieren Traces über unsere Agent-Adapter hinweg, sodass jede Interaktion als strukturierter Ausführungspfad überprüft werden kann: Modellaufrufe, Tool-Aufrufe, Zwischenschritte und finale Antworten. Auf diesen Traces führen wir ein Framework zur kontinuierlichen Evaluierung aus – mit Scorern für deterministische Korrektheit und SQL-Grounding, Cache-bewussten Kosten-Scorern und LLM-Judge-Scorern mit Ausrichtung auf Domain-Experten. Das Ziel geht über das Testen von Agenten-Änderungen hinaus. Die Kontext-Ebene selbst muss evaluiert werden: Markdown kann von Pipelines und Tabellendefinitionen abweichen, System-Prompts entwickeln sich weiter, Tool-Verträge ändern sich und Domain-Annahmen veralten. Traces und Evals ermöglichen es uns, den Agenten, die Tools und den Kontext, auf den er sich stützt, gemeinsam zu testen, bevor sie das Verhalten in der Produktion beeinflussen.

Zum ersten Mal verfügt das Unternehmen über einen einzigen, kontrollierten Einstiegspunkt für Mitarbeitende, um zu entdecken, welche Datenprodukte existieren, und mit ihnen in natürlicher Sprache zu interagieren – unterliegend denselben Zugriffskontrollen wie die zugrunde liegenden Daten.

Dasselbe Muster, direkt im Entwicklungszyklus

Dasselbe Muster hat auch unsere Arbeitsweise beim Entwickeln verändert.

Unser Engineering-Workflow umfasst jetzt Agenten direkt im Entwicklungszyklus. Das genaue Coding-Tool ist weniger wichtig als das Muster: Ein Engineer arbeitet in einer KI-gestützten Entwicklungsumgebung, die mit Databricks-Funktionen und unserem eigenen Kontext-Ebene-MCP verbunden ist. Wenn der Engineer an einem Datenprodukt arbeitet, kann der Agent relevante Metadaten aus Unity Catalog prüfen, die bestehende Produktdokumentation lesen, den Kontext des umliegenden Projekts verstehen und beim Erstellen von Pipelines, Tests, Tabellenbeschreibungen und Markdown-Katalogeinträgen helfen. Der Engineer bleibt für Review und Merge verantwortlich, aber der Agent ist genau dann zur Stelle, wenn der Kontext am reichhaltigsten ist.

Dieses Timing ist entscheidend. Eine im Nachhinein geschriebene Dokumentation ist oft unvollständig, da sich der Projektkontext bereits weiterentwickelt hat. Eine während der Entwicklung geschriebene Dokumentation erfasst die Gedankengänge, Definitionen und Einschränkungen, die die Daten später nützlich machen – und wird, sobald sie überprüft und freigegeben wurde, zum Kontext für den nächsten Workflow.

Bei vielen unserer R&D- und Prozessentwicklungs-Workflows dauert das, was früher Wochen an systemübergreifender Datenintegration, KPI-Definition und Pipeline-Erstellung erforderte, heute nur noch wenige Tage. Die Verbesserung zeigt sich weniger in einer einzelnen Automatisierungszahl, sondern vielmehr in einer kürzeren Zeitspanne von der Untersuchungsanfrage bis zum nutzbaren Datenprodukt: weniger manuelle Übergaben zwischen Domain-Experten und Data Engineers, weniger wiederholte Quellsystem-Integrationen, schnellere Einigung auf KPI-Definitionen und eine frühere Überprüfung von Einschränkungen, solange der Kontext noch frisch ist. Einige Kategorien, insbesondere komplexe Untersuchungen aus mehreren Quellen, die eine sorgfältige fachliche Prüfung erfordern, bedeuten nach wie vor erheblichen Aufwand – sie sind nur wesentlich schneller abgeschlossen. Der nachhaltige Nutzen ist kumulativ: Jedes Produkt fügt der Plattform geprüften Geschäftskontext hinzu, sodass die nächste Untersuchung bereits auf einem besser erklärten Fachbereich aufbauen kann.

Databricks macht nun Teile dieses Musters als Produkt verfügbar. Die Unity AI Gateway Coding CLI, ucode, leitet Coding-Tools über das AI Gateway und bindet MCP-Server in den Entwickler-Workflow ein. Genie Code bringt agentenbasiertes Coding und Datenarbeit direkt in die Databricks-Oberflächen.

Wie es als Nächstes weitergeht

Für uns besteht die nächste Welle darin, Agenten sowohl für den betrieblichen Kontext rund um die Daten als auch für die Tabellen selbst zu sensibilisieren. Bei einer Qualitäts- oder Fertigungsuntersuchung sollte ein Agent in der Lage sein, einen Trend abzurufen, die mit dem Produkt verknüpften Datenqualitätsprüfungen einzusehen und zugehörige Maschinenalarmprotokolle aus demselben Zeitfenster einzubinden. Die Antwort kann dann den Hinweis enthalten, den ein Engineer erwarten würde: Der Trend zeigt in diese Richtung, aber dieser Ausschnitt ist mit Vorsicht zu genießen, da die Vollständigkeit bemängelt wurde und der Betriebskontext abnormal war.

Dasselbe Prinzip gilt für wiederkehrende Aufgaben. Heute ist Prozesswissen über Runbooks, Wiki-Seiten, lokale Prompts, Skripte, Teamkonventionen und undokumentierte Gewohnheiten verstreut. Ein Skills Marketplace bietet diesem Wissen dieselbe Plattformbehandlung wie Datenprodukten: Ownership, Review, Versionierung, Lebenszyklusstatus und einen zentralen Ort, an dem Agenten die freigegebene Arbeitsweise finden. In diesem Kontext bündelt ein Skill die Anweisungen, freigegebenen Tools, Vorlagen, Guardrails und Evaluierungsprüfungen, die einem Agenten mitteilen, wie eine wiederkehrende Aufgabe in unserer Umgebung ausgeführt werden soll. Konkret würde er im Marketplace neben den Datenprodukten existieren, die er betrifft, wie Code versioniert und überprüft werden und namentlich aufgerufen werden, sodass der Agent jedes Mal denselben freigegebenen Pfad einschlägt. Ein Skill könnte ein domänenspezifisches Databricks Asset Bundle in einem Remote-Repository erstellen oder einen Engineer bei der Registrierung eines IoT-Geräts und der Umwandlung unstrukturierter Maschinenprotokolle in eine Bronze-Pipeline unterstützen.

Das ist die übergeordnete Richtung für den Data Hub: die gleiche Lektion aus dem Lakehouse-Fundament ziehen, zuerst den Kontext kontrollieren und dies sowohl auf die Daten anwenden, die Agenten abfragen, als auch auf die Arbeit, bei deren Ausführung sie helfen.

Das Fazit

Deshalb gehören R&D-Daten in das Lakehouse. Industrielle AI benötigt kontrollierten Kontext: die Daten, die Bedeutung, die Berechtigungen, die Traces und die Feedbackschleife in einer einzigen Architektur.

Für cellcentric bedeutet die praktische Umsetzung von industrieller AI, Agenten diesen Kontext auf Basis eines bewährten Lakehouse-Fundaments zur Verfügung zu stellen. Unity Catalog, Datenprodukte, Identität, Observability und Agenten-Workflows arbeiten zusammen, damit Menschen und Agenten sicher mit R&D-Daten arbeiten können. Das ist für uns mehr als nur eine Best Practice. So gestalten wir die nächste Generation des datengestützten Engineerings.

(Dieser Blogbeitrag wurde mit KI-gestützten Tools übersetzt.) Originalbeitrag