Data Lakehouses werden zur Grundlage für Enterprise-KI

Auch in der Unternehmensarchitektur sind Lakehouses äußerst elegant und smart. arthitecture | shutterstock.com



Data Lakehouses haben sich zum Goldstandard moderner Unternehmens-Datenplattformen entwickelt. Sie vereinen die Vorteile eines Data Lake – die kostengünstige Speicherung unterschiedlichster Datentypen – mit der Zuverlässigkeit, Struktur und Governance eines klassischen Data Warehouse.



Da sie Informationen aus verschiedenen Bereichen eines Unternehmens zentral zusammenführen und gleichzeitig Sicherheits- und Audit-Funktionen bereitstellen, eignen sie sich auch hervorragend als Basis für Enterprise-KI-Systeme. Tatsächlich sind sie inzwischen so weit verbreitet und leistungsfähig, dass sich nahezu alle großen Anbieter von Data Lakes und Data Warehouses zu Lakehouse-Anbietern entwickelt haben. Snowflake beispielsweise startete ursprünglich als Data-Warehouse-Anbieter und hat sich durch mehrere Jahre der Weiterentwicklung und zahlreiche Übernahmen zu einer vollständigen Data-Lakehouse-Plattform entwickelt.



Grundlage der zukünftigen KI-Landschaft



Auch Docusign nutzt diese Plattform nun, um seine Ambitionen im Bereich Agentic AI voranzutreiben. So werden beispielsweise Daten aus Salesforce übernommen und anschließend zum Training eines internen KI-Vertriebsagenten verwendet, erläutert Shivi Verma, Senior Manager of Engineering bei Docusign. Darüber hinaus trainiert das Unternehmen Machine-Learning-Modelle, um seinen Kunden präzisere Ergebnisse liefern zu können.



Die Informationen werden außerdem über RAG-Embedding-Pipelines an Large Language Models (LLMs) weitergegeben. Gleichzeitig untersucht Docusign den Einsatz des Model Context Protocol (MCP), sobald diese Technologie weiter ausgereift ist.



Ein zentrales Thema beim Bereitstellen der Lakehouse-Daten ist für Docusign jedoch die Sicherheit und Governance. „Wir gehen dabei äußerst vorsichtig vor“, sagt Verma. „Jeder Anwendungsfall durchläuft eine strenge Sicherheitsprüfung sowie Diskussionen mit technischen und fachlichen Stakeholdern, um sicherzustellen, dass wir weder gegen Sicherheitsvorgaben noch gegen Compliance-Anforderungen verstoßen.“



Diese Sicherheitskontrollen greifen sowohl beim Import der Daten in Snowflake als auch beim späteren Export. Besonders strenge Regeln gelten für den Zugriff auf sensible Informationen wie Kundendaten.



„Zunächst stellen wir nur Daten mit einem niedrigen Risikoprofil bereit“, erklärt Verma. Dazu gehören beispielsweise öffentlich verfügbare Informationen wie Inhalte der Unternehmens-Website oder Produktinformationen.



Docusign ist mit diesem Ansatz keineswegs allein. „Wir sehen inzwischen eine Lakehouse-Nutzung von 65 Prozent bei den Kunden von Gartner“, sagt Gartner-Analyst Prasad Pore. „Das ist innerhalb kurzer Zeit ein außergewöhnlich hoher Wert.“



Und die Zukunft der Lakehouses sieht seiner Einschätzung nach noch vielversprechender aus.



„Lakehouses entwickeln sich zur Grundlage der zukünftigen KI-Landschaft“, sagt Pore. Gleichzeitig erweitern die Anbieter ihre Plattformen gezielt um KI-Funktionen.



Ein klassisches Lakehouse-Konzept umfasst beispielsweise keine Vektordatenbanken, die für RAG-basierte KI-Systeme eine zentrale Rolle spielen.



„Viele Lakehouse-Anbieter haben inzwischen Funktionen zur Vektorindizierung integriert“, erklärt Pore. „Databricks und Microsoft Fabric verfügen bereits über eingebaute Vektor-Funktionalitäten.“ Kleinere Anbieter könnten diese Möglichkeiten allerdings noch nicht bieten.



Auch die Unterstützung für MCP, den Standard zur Verbindung von KI-Agenten mit Datenquellen und Systemen, unterscheidet sich je nach Anbieter und gehört bislang nicht zum traditionellen Funktionsumfang eines Lakehouses.



Eine Frage der Wahl



Ein Data Lakehouse ist nicht die einzige Möglichkeit für Unternehmen, ihren KI-Systemen den geschäftlichen Kontext bereitzustellen, den sie für einen sinnvollen Einsatz benötigen.



So können Unternehmen beispielsweise Vektordatenbanken oder entsprechende Datenpipelines manuell aus einzelnen Datenquellen aufbauen oder eine Data Fabric einsetzen, um die Verbindung zwischen den Systemen herzustellen.



„Eine Data Fabric kann sich direkt mit den ursprünglichen Datenquellen verbinden. Das eignet sich gut für schnelle Analysen“, erklärt Gartner-Analyst Pore. „Allerdings belastet man dadurch die Quellsysteme zusätzlich, was für diese Anwendungen und Maschinen nicht ideal ist.“



Wichtig dabei: Microsoft Fabric ist zwar eine Lakehouse-Plattform, jedoch keine Data-Fabric-Plattform im Sinne der Gartner-Definition.



Ein weiterer Nachteil direkter Verbindungen besteht darin, dass die Datenmodelle der operativen Systeme meist nicht für analytische Zwecke optimiert sind und ihre Nutzung häufig teuer ist. „Der direkte Zugriff auf Quellsysteme ist nicht effizient“, so Pore.



Hinzu kommt, dass für Data Lakehouses bereits etablierte Verfahren zur Verwaltung von Zugriffsrechten existieren.



„Ein Lakehouse vereinheitlicht Daten, Wartung, Sicherheit und Governance physisch an einem Ort“, erklärt Pore. „Gerade für die Einführung von KI ist das von entscheidender Bedeutung. Als unternehmensweite ‘Single Source of Truth’ ist ein Lakehouse der moderne Weg, ein zentrales Daten-Repository aufzubauen.“



Vom Data Lake zum Lakehouse



Das Beratungsunternehmen Lemongrass begann bereits vor rund zehn Jahren mit einem klassischen Data Lake und entwickelte es vor etwa vier Jahren schrittweise zu einem Lakehouse weiter.



„Damals war das Lakehouse-Konzept noch längst nicht so verbreitet“, erinnert sich Kausik Chaudhuri, Chief Innovation Officer bei Lemongrass.



Deshalb entwickelte das Unternehmen eigene Lakehouse-Funktionen auf Basis seines Amazon-S3-Data-Lakes. Nun, da das Lakehouse zunehmend KI-Anwendungen unterstützt, steht bereits die nächste Modernisierung an.



„Derzeit arbeiten wir an einer Lösung für Incident- und Change-Management“, erläutert Chaudhuri.



Die ursprünglichen Daten liegen in ServiceNow. Würde man sie direkt aus dem Lakehouse extrahieren, um sie in einem KI-System zu nutzen, wären die Kosten zu hoch. „Deshalb überlegen wir jetzt, einen MCP-Server aufzubauen, der diese Daten gezielt abfragt“, fügt er hinzu.



Gleichzeitig plant Lemongrass den Wechsel von den selbst entwickelten Lakehouse-Erweiterungen zu einer Standardlösung.



„Als wir begonnen haben, war Lemongrass vor allem ein Verfechter von AWS, weshalb viele unserer Werkzeuge auf AWS aufgebaut wurden“, erklärt Chaudhuri. „Jetzt denken wir darüber nach, diesen Ansatz zu ändern, weil KI deutlich mehr Möglichkeiten eröffnet.“



Allerdings bietet inzwischen auch AWS selbst umfassende Lakehouse-Funktionalitäten. „Die Daten liegen bereits dort. Wir müssen das Rad also nicht neu erfinden.“



Darüber hinaus stellt AWS direkte Anbindungen an Anthropic Claude und weitere KI-Modelle bereit. Da diese Modelle ebenfalls innerhalb der AWS-Infrastruktur betrieben werden, fallen keine Egress-Gebühren an.



Lemongrass plant, die Modernisierung im dritten Quartal dieses Jahres zunächst mit einem Proof of Concept (PoC) zu beginnen. Dabei müsse aber besonders sorgfältig müsse entschieden werden, welche Daten und in welchem Umfang sie aus dem Lakehouse an KI-Modelle übertragen werden.



„Wir schicken keine Kundendaten an ein LLM“, betont Chaudhuri. „Und ich lese auch nicht 10.000 Datensätze aus und sende sie an Claude – das würde den Token-Verbrauch explodieren lassen. Schon vor einigen Jahren haben wir erkannt, dass wir bankrottgehen könnten, wenn wir den Token-Verbrauch nicht sorgfältig kontrollieren.“



Für manche Anwendungsfälle muss das LLM nach der Implementierung der Lösung überhaupt keine Kundendaten mehr sehen. Beispielsweise erstellten Mitarbeiter früher manuell Statusberichte über Kunden für den eigenen Gebrauch – ein zeitaufwendiger Prozess. Ein LLM könnte diese Aufgabe zwar übernehmen, hätte dabei jedoch Zugriff auf sensible Kundendaten. Außerdem liefern generative KI-Modelle aufgrund ihrer nicht deterministischen Arbeitsweise jedes Mal leicht unterschiedliche Ergebnisse.



Ein weiteres Beispiel sind Formulare, die Kunden später unterschreiben sollen. Auch hier könnte ein LLM bei jeder Anfrage ein neues Formular generieren.



„Deshalb haben wir Claude stattdessen gebeten, ein Programm zu schreiben, das diese Eingaben verarbeitet und daraus den Bericht erzeugt“, erklärt Chaudhuri. Die eigentliche Berichts- oder Formularerstellung erfolgt anschließend durch klassische, deterministische Software. Dadurch bleiben Kundendaten geschützt, während Berichte schnell und kostengünstig erzeugt werden können.



Andere Unternehmen setzen KI dagegen bereits intensiv ein, um ihre Datenbestände besser auszuschöpfen.



Laut einem aktuellen Databricks-Bericht, der auf Daten von 20.000 Unternehmen basiert, stieg der Anteil der von KI-Agenten erzeugten Datenbanken innerhalb von zwei Jahren von 0,1 Prozent auf 80 Prozent. Heute erstellen KI-Agenten bereits 97 Prozent aller Datenbank-Branches.



Sicherheit und Governance



Eine der größten Herausforderungen für Unternehmen besteht darin, herauszufinden, wie sie mit Sicherheits- und anderen damit verbundenen Fragen umgehen sollen, wenn KI-Agenten auf Data Lakehouses zugreifen.



In der Vergangenheit wurden Daten hauptsächlich an Dashboards weitergeleitet, in denen die Sicherheits- und Zugriffskontrollen fest programmiert waren. Oder die Daten gingen an Datenanalysten, die im Rahmen ihrer eigenen Zugriffsrechte arbeiteten. Die ersten KI-Anwendungen basierten überwiegend auf Retrieval-Augmented Generation (RAG). Dabei extrahiert klassische, deterministische Software die benötigten Daten und fügt sie in den Prompt eines Large Language Models für einen konkreten Anwendungsfall ein. Die Entwickler konnten die Sicherheitsregeln dabei individuell für jeden Workflow festlegen.



Mit dem Aufkommen agentischer KI und MCP-Servern (Model Context Protocol) verändert sich dieses Modell grundlegend: KI-Agenten können nun selbstständig entscheiden, welche Daten sie benötigen, und diese eigenständig abrufen.



Nach Ansicht von Genpact-Manager Arellano müssen Unternehmen deshalb neue Konzepte entwickeln, um die Identitäten von KI-Agenten zu verwalten, den Zugriff auf Daten zu kontrollieren, Prüfpfade zu erstellen sowie Prompts und Inhalte zu filtern.



„Agenten benötigen ihre eigenen Zugangsdaten“, erklärt er. Beispielsweise dürfen KI-Agenten unter Umständen niemals Zugriff auf Patientenakten erhalten. „Ebenso wichtig sind Audit Trails, um lückenlos nachvollziehen zu können, was der Agent getan hat.“



Arellano zufolge bieten einige Lakehouse-Anbieter, darunter Databricks, diese Funktionalität an. Zusätzlich können Unternehmen Tools von Anbietern wie Okta, Palo Alto oder Zscaler integrieren.



Die neue semantische Grenze



Die nächste Entwicklungsstufe des Lakehouse ist der Semantic Layer. Gartner schätzt, dass universelle semantische Ebenen bis 2030 zur unverzichtbaren Infrastruktur gehören werden.



„Der Aufbau einer universellen semantischen Schicht ist heute eine Pflichtaufgabe für Verantwortliche im Bereich Daten und Analytics, die KI-Projekte leiten oder unterstützen“, erklärt Gartner. „Nur so lassen sich Genauigkeit verbessern, Kosten kontrollieren, technische KI-Schulden deutlich reduzieren, Multi-Agenten-Systeme aufeinander abstimmen und kostspielige Inkonsistenzen verhindern, bevor sie sich ausbreiten.“



Es reicht nämlich nicht aus, einer KI lediglich Zugriff auf Daten zu geben. Sie muss auch verstehen, was diese Daten für das Unternehmen tatsächlich bedeuten. Die semantische Ebene bildet genau dieses Geschäftswissen ab, das normalerweise nicht in einer strukturierten Datenbank formalisiert ist.  Beispielsweise kann der Begriff „Kunde“ oder „Bestellung“ in verschiedenen Unternehmenssystemen jeweils etwas anderes bedeuten.



„Früher war die semantische Ebene zwar wünschenswert, aber nicht unbedingt notwendig, da Datenwissenschaftler wussten, welche Datenquellen sie abfragen wollten“, erläutert Amit Kinha, Vorstandsmitglied der FinOps Foundation und Field-CTO bei DoiT International, einem Cloud-Beratungsunternehmen.



Für KI-Agenten gilt das jedoch nicht mehr. „Ohne eine semantische Schicht weiß ein Agent möglicherweise gar nicht, wo er nach den benötigten Daten suchen soll”, so Kinha. Oder noch schlimmer: „Er führt fehlerhafte Joins aus oder löst Prozesse aus, die die Kosten explodieren lassen.“



Deshalbwerde die semantische Schicht künftig entscheidend dafür sein, Data Lakehouses effektiv für KI einzusetzen.



Mitlernendes System



Die semantische Schicht kann darüber hinaus Teil eines Lern- und Feedbackprozesses werden. Kevin Martelli, Consulting AI Solution Development Leader bei EY Americas, beschreibt folgendes Beispiel: Angenommen, in einem Unternehmen müssen Zahlungen über 500.000 Dollar vom CFO genehmigt werden. Ein KI-Agent fordert die Genehmigung eines Mitarbeiters an.



Der Mitarbeiter erkennt jedoch: „Ich soll diese Rechnung freigeben, aber ich weiß, dass Beträge über 500.000 Dollar zusätzlich die Zustimmung des CFO benötigen.“



Diese Information kann anschließend dauerhaft gespeichert werden. „Sie kann innerhalb der Sitzung genutzt und anschließend als Prozessdokument oder Ereignisprotokoll wieder im Lakehouse abgelegt werden“, erklärt Martelli. Dadurch lernten agentische Systeme mit jeder Nutzung hinzu.



„Genau dadurch wird das System im Laufe der Zeit immer wertvoller – denn am ersten Tag wird man niemals alles perfekt modellieren können.“



Die semantische Schicht befindet sich allerdings noch in einer frühen Entwicklungsphase, wobei die verschiedenen Lakehouse-Anbieter unterschiedliche Ansätze verfolgen.



„In der Branche wird derzeit intensiv darüber diskutiert, wie Data Lakehouses und semantische Schichten zusammenwachsen und wo diese Schicht künftig eigentlich angesiedelt sein sollte“, erklärt Matt Arellano, SVP für Daten und KI bei der Digital-Transformation-Beratungsfirma Genpact. Einige Anbieter integrieren semantische Funktionen direkt in ihre Lakehouse-Plattformen oder kaufen entsprechende Spezialunternehmen hinzu. Andere Unternehmen setzen stattdessen auf spezialisierte Drittanbieter.



„Die Kunden tun sich damit schwer“, so Arellano. „Sie alle versuchen herauszufinden, welche Kombination aus Werkzeugen und Prozessen langfristig die richtige ist.“



Steven Karan, Vice President für KI-Transformation bei Capgemini Australien und Neuseeland, sieht im Lakehouse eine Entwicklung hin zu einer zentralen Orchestrierungsschicht.



„Unternehmen konzentrieren sich mittlerweile weniger auf klassische Analysen und Berichte, sondern vielmehr auf KI-gesteuerte Anwendungen und agentenbasierte Systeme“, erklärt er. „Die effektivsten Architekturen, die ich heute sehe, kombinieren einen Lakehouse-Kern mit spezialisierten Serverschichten.“



Dazu gehören Vektordatenbanken für KI, Streaming-Plattformen für Echtzeitdaten und operative Datenbanken für Anwendungen mit geringer Latenz.



Das Lakehouse diene nicht mehr nur der Analytik, fügt er hinzu. Es sei die Grundlage für Unternehmensdaten und KI. „Seine Aufgabe besteht heute weniger darin, alle anderen Systeme zu ersetzen, sondern vielmehr darin, sie miteinander zu verbinden, zentral zu steuern und zu überwachen. Damit soll sichergestellt werden, dass Unternehmen schneller innovieren können, ohne die Kontrolle über ihre Daten zu verlieren.“ (mb)



Dieser Artikel basiert auf einem Beitrag von CIO.com.